devgo.cn如果你最近在关注 AI 辅助编程的边界，Linux 内核社区刚刚做了一个极具风向标意义的决定：从 2026 年 10 月 8 日在捷克布拉格举行的维护者峰会（Maintainers Summit，内核维护者们的年度线下碰头会）开始，向内核提交代码时不再强制要求使用 "Assisted-by" 标签。换句话说，内核开发者递交代码时，无需再主动声明这部分代码是不是 AI 帮忙写的。这个决定背后最直接的声音来自 Linux 之父 Linus Torvalds，他的原话很直白：禁止使用 AI 就像禁止使用文本编辑器一样，是极其愚蠢的规定。他认为，从事内核开发的人知道自己在做什么，工具只是工具，关键在写代码的人。
这件事之所以值得关注，是因为 Linux 内核可能是世界上对代码质量要求最苛刻的开源项目之一。它运行在从手机到超级计算机的几乎所有设备上，一个补丁的失误可能影响数十亿用户。过去两年，随着 AI 编程助手（比如 GitHub Copilot、Claude Code 这类能根据自然语言指令自动生成代码的工具）的普及，内核社区一直在争论：AI 生成的代码要不要特殊标记？支持标记的人认为，AI 代码可能引入难以察觉的细微错误，标记出来方便审查者格外小心；反对的人则认为，这本质上是对开发者的不信任，而且 AI 辅助和人类写代码的界限越来越模糊，强行区分没有实际意义。
这次峰会直接拍板取消了强制声明，算是给这场争论画了一个阶段性的句号。但更有意思的是，就在这个决定公布后不久，Linus 本人就递交了一组用 Claude Code 开发的补丁——结果这组补丁被发现存在竞态条件（race condition，指多个线程或进程同时访问共享资源时，由于执行顺序不确定而导致的逻辑错误），内存回收部分也被认为有问题。最后这组补丁的后续开发被转交给了一位人类开发者 Kiryl Shutsemau 接手。
这个翻车案例其实比决定本身更有信息量。它说明了两件事：第一，即使是 Linus 这种级别的开发者，用 AI 写内核代码也会踩坑，AI 生成代码在复杂并发场景下的可靠性依然存疑；第二，内核社区的态度是"不禁止但也不盲信"——你可以用 AI，但代码质量审查的流程不会因为你是 AI 写的就放松，出了问题照样打回重做。
对我们普通开发者来说，这个决定和这个案例能直接迁移到自己的日常工作中。如果你所在团队还在纠结"要不要允许用 AI 写代码"，Linux 内核的选择是一个很好的参考：与其花精力去强制声明、去设防，不如把精力放在代码审查机制上。AI 代码不是洪水猛兽，但它确实需要更严格的 review（代码审查，即让其他开发者检查代码逻辑和质量的流程）。特别是涉及并发、内存管理、状态机这类容易出隐蔽 bug 的场景，AI 生成代码后一定要有人类开发者仔细过一遍，甚至建议跑一些压力测试。另一个值得注意的坑是：AI 工具生成的代码往往看起来结构清晰、注释完整，但"看起来对"和"真的对"之间隔着大量边界条件和时序问题，这次 Linus 的补丁就是活生生的例子。
所以，别把 AI 辅助编程当成自动驾驶，它更像是一个能帮你快速写出初稿的实习生——方向感好的时候效率惊人，但在关键路径上，你还是得自己把关。内核社区用行动表明：工具自由，但质量责任永远在人。这个思路，放到任何技术团队都适用。
内容与图片版权归原作者所有 · 原文: https://www.solidot.org/story?sid=85641