过去一年，关于“AI 生成代码到底能不能进生产、能不能进开源主干”的讨论，很多时候都被说得太虚。有人把它讲成效率神话，有人把它讲成版权灾难，还有人干脆把问题简化成“能不能用 Copilot”。Linux 内核最近给出的答案，反而是目前我看到最有工程味的一种：可以用，但别装作是工具在负责，责任还是你自己的。

内核文档已经新增了两份相关说明。一份是 AI Coding Assistants，明确要求 AI 代理不能替人添加 Signed-off-by，因为 Developer Certificate of Origin 只能由人来作出法律上的确认；提交者必须审阅 AI 生成代码、确认许可合规、自己签署提交，并对结果承担全部责任。另一份是 Kernel Guidelines for Tool-Generated Content，核心态度也很直接：对工具生成内容要透明披露，生成越多，维护者就越有理由提高审查强度，甚至直接拒收。

这件事真正重要的，不是“允许 AI”，而是“允许的边界被写清了”

很多团队现在最大的问题，不是有没有人在偷偷用 AI，而是组织层面没有一套能落地的规则。结果就会变成一种很奇怪的局面：写的人把 AI 当加速器，审的人把提交当雷区，出了问题以后再回头追责，却发现责任链条根本没定义清楚。

Linux 内核这次没有走“全面封禁”路线，也没有走“默认接受”路线，而是做了一个更成熟的选择：把工具使用纳入既有开发流程。文档要求 AI 相关贡献继续遵循标准内核开发流程、许可规则和补丁提交流程；同时引入 Assisted-by 标签，用来标记具体使用了什么 AI 工具、什么模型版本，以及哪些专门分析工具参与了生成过程。这个格式很朴素，但意义很大——它把原本隐形的生成过程，变成了可讨论、可审查、可追溯的信息。

对开发者来说，这不是一个“更放心摸鱼”的信号，而是一个“别再把草稿当成果”的信号

我很赞同内核社区这里的基本判断：AI 生成代码不是原罪，真正的问题是“你是否理解自己提交的东西”。文档里写得很清楚，提交者需要理解整个提交内容，能够回应 review；如果你做不到，那就不要提交。如果硬要交，维护者完全可以不做详细 review 直接拒绝。

这对今天大量依赖 AI 编程的开发者是个很现实的提醒。现在不少人已经习惯了这样的工作流：先让模型生成一大段，再靠测试跑通，最后带着“反正能用”的心态合进去。这个工作流在个人原型、小工具、一次性脚本里问题还不算特别大，但一旦进入长期维护系统、多人协作仓库或者高风险代码库，代价会迅速放大。你节省下来的也许只是 20 分钟的编码时间，换来的却可能是未来几周的 review 摩擦、责任不清和维护债务。

对个人开发者，这反而是一种利好

很多独立开发者看到这类规则，第一反应会是：完了，AI 编程要被管起来了。我的判断相反。真正受影响最大的，不是认真使用 AI 的个人开发者，而是那些把“会调模型”误当成“可以省掉工程责任”的人。

对个人开发者来说，AI 最有价值的场景从来不是“替你签字”，而是帮你压缩探索成本：快速读代码、起草实现、补测试、生成迁移方案、梳理重构路径。只要你自己仍然保留最终判断权，AI 就是在放大单兵能力。Linux 内核现在给出的规则，本质上是在告诉所有人：你可以把 AI 当高级工具链，但不能把它当责任外包商。这个边界一旦接受，很多实际决策反而会更简单——哪些代码可以大胆用 AI 起稿，哪些部分必须自己逐行吃透，哪些提交必须补充说明，都会清晰很多。

接下来更值得关注的，不是模型能力，而是协作规范会不会跟上

我认为这件事对更广泛的软件行业有两个启发。

第一，2026 年真正稀缺的已经不是“会不会用 AI 写代码”，而是“团队能不能定义 AI 代码的责任边界”。谁负责审阅，如何披露生成过程，什么场景允许直接采用，什么场景必须额外测试，这些问题不解决，模型越强，组织越混乱。

第二，未来高质量团队的差异不会主要体现在“禁不禁 AI”，而会体现在“有没有一套低摩擦但高约束的 AI 协作规范”。Linux 内核的做法值得借鉴的地方，就在于它既承认工具已经进入工作流，也坚决不把质量标准让给工具。

我的结论

这件事值得开发者重度关注，但不需要过度解读成“Linux 开始拥抱 AI”这种空洞叙事。更准确地说，这是顶级开源项目在给 AI 编程补齐一条最关键的基础设施：责任规则。

如果你在团队里推动 AI 编程落地，现在就值得做三件事：给 AI 参与代码设披露规则，给关键模块设更高的人审门槛，给所有提交者明确“你提交，你负责”。这三件事看上去不性感，但它们比再换一个更会写代码的模型更重要。

AI 会继续进入开发流程，这一点已经没有悬念。真正有悬念的是，谁能在效率提升之前，先把责任体系搭好。Linux 内核这次给出的答案很朴素，但大概率是对的。