AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
Linux Wireless Maintainer Takes Firm Stance Against AI/LLM Generated Slop Patches In addition to the Linux kernel staging area now rejecting AI/LLM-generated patches except for real security fixes, the Linux wireless networking code is also seeing some shifts around how it will deal with AI/LLM generated patches. Johannes Berg who serves as maintainer of the Linux kernel's 802.11, mac80211, WWAN, rfkill, and wireless networking drivers (among other kernel code), has announced a shift in how he will be viewing patches generated by AI/LLMs like syzbot generated patches. If a "three second review" of such AI generated patches doesn't immediately make clear to him of a genuine fix, the patches will be ignored. He laid out his new policy for Linux wireless patches in a post on the LKML: "I'm going to state, for the record, that I'm going to make judicious use of ability to ignore patches, and apply it to pretty much all syzbot-AI-generated patches unless a 3-second review says "obviously right". In particular, I will absolutely *not* "comment on the patches as usual" and argue with an LLM that can bullshit out code faster than another computer can even deliver it to me by email. Whoever is currently pretending to be the human in the loop *absolutely* needs to think about the patches, and if that's happening it's probably no longer an AI-generated-sent-by-syzbot but you're going to rewrite it and send it properly. (IOW: get lost, syzbot)" In response about syzbot, it was clarified every AI-generated patch by Syzbot is pre-reviewed and approved by a human. Syzbot also does not send automatic replies and does not automatically submit submit newer versions of patches. In turn, Syzbot is now being disabled for sending AI-assisted patches covering the Linux wireless subsystem. Johannes also shared more perspective on how he views the influx of AI/LLM patches: "The system, in a case like this, is almost certainly going to provide a very narrow, targeted fix (with an annoying wall of text explaining exactly that), but I think that at least the human in the loop should actually take a step back from that and ask what the semantics of the code should be ... I've played this game with Slawomir's first patch myself, but that clearly cannot scale if the original intermediary doesn't want to do that. Maybe it's something you can even tell the LLM to do, somehow, so the first draft is better. In this case, for example, why the hell did it decide that it made any sense to have multiple branches of the same switch statement - and there are even only two! - implement the same validation? At the very least I'd expect the "human engineer" to take that step back. This is why I'm refusing these patches, because clearly nobody actually even bothers to look at the semantics of the code before or during the patching. Does pulling out the check outside of the switch change the order of errors? Yes. Does that matter? No, the new order of errors for NL80211_TDLS_ENABLE_LINK would actually - if you think about it (!) - make a lot more sense! Am I surprised the LLM doesn't do that when you tell it to make a targeted fix? Absolutely not. But I really cannot make that judgement call myself for every single issue like that, if I could, see above, I could be doing all of this myself. Need the contributors to do that. Slawomir did that after I prompted (pun intended!) him to do that, and it didn't work out so well and we had a good discussion about it, but again, I can't provide that support all time. ... Even the targeted fixes are still fixes, so I understand from your perspective this still made sense, but from mine it just absolutely cannot scale, both in terms of long-term maintenance (sprinkling checks all over the code disregarding the architecture) and also in terms of review bandwidth etc." Thus the new three second rule moving forward for evaluating new Linux wireless patches generated by AI/LLMs.