夜雨聆风
Linux 给 AI 开发立规矩了:工具可以用,但这 4 条工程底线不能丢
规范地址：https://docs.kernel.org/process/coding-assistants.html
哈喽，大家好，我是 01墨客。
这两天我看到一篇文章，讲的是 Linux 内核正式给 AI 辅助开发立规矩了。
说实话，我第一反应不是“AI 终于被官方接纳了”，而是另外一句话：真正成熟的工程团队，果然从来不在“禁不禁用工具”上浪费太多时间。
他们更关心的，是更硬、更现实的问题。
比如：这段代码是谁提交的？谁审过？谁能解释？出了问题谁来背？12
而这恰恰也是很多团队现在最缺的东西。
我们今天聊 AI 写代码，表面上在聊效率，实际上经常踩坑的地方，却是责任链模糊、过程不可追溯、质量标准被悄悄放水。工具还没出大问题，流程先塌了。
Linux 这次给出的规则很短，但味道特别重。
因为它没有陷入“AI 神化”或者“AI 恐慌”，而是直接把问题拍在桌上：AI 可以用，但工程纪律不能松。1
一、为什么很多团队一上 AI，就容易把开发流程带歪
这事真的太常见了。
一个团队刚上 AI 编码工具，前两周大家都觉得爽：写得快了，补样板代码更省事了，查 API 也更方便了。结果一个月后开始出问题，谁也说不清某段逻辑到底是谁拍板的，为什么这么改，为什么没人复查。
最后就会出现一种特别魔幻的场景：代码是 AI 生成的，提交是人提的，Review 是走过场的，线上事故出来以后，所有人都说“这不是我本意”。
听着熟不熟？
这就像公司新买了一台高速打印机，结果大家开始拿它打印没审核过的合同。打印机当然更快了，但合同出事，难道能怪打印机吗？
Linux 这次立规矩，其实就是把这件事讲透了：工具可以提高产能，但不能稀释责任。
原因一：很多团队把“AI 参与”误当成“AI 背锅”
Linux 官方文档写得非常直接：AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).1
翻成人话就是，AI 不能签这个字。
因为 Signed-off-by 不是一个装饰标签，它背后对应的是 Developer Certificate of Origin，也就是开发者对代码来源、授权与提交资格的正式确认。2
谁签，谁就要承担那份法律和工程责任。
这一下就把很多模糊地带砍掉了。你可以用 AI，但你不能把“我用了 AI”变成“所以这段代码不完全算我的”。
原因二：没有可追溯记录，AI 只会让协作更乱
Linux 没有选择一刀切禁止 AI，而是要求使用 AI 时加上 Assisted-by 标签，并写明 AI 工具名、模型版本，必要时还要写上配合使用的分析工具。1
官方给出的格式是这样的：
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]甚至还给了示例：
Assisted-by: Claude:claude-3-opus coccinelle sparse这背后真正重要的，不是“留个备注”这么简单，而是团队以后遇到问题时，能知道这段代码是在什么工具、什么模型、什么辅助分析条件下产出的。
你别小看这一步。
很多线上问题不是改不回来，而是根本追不回去。
原因三：最危险的不是 AI 出错，而是团队偷偷降低标准
Linux 官方文档虽然篇幅不长，但态度非常明确：人类提交者必须审查所有 AI 生成代码，确保满足许可要求，并对贡献承担全部责任。1
这句话真正厉害的地方在于，它没有给 AI 开后门。
不会因为“这是 AI 帮忙写的”就少查几行，也不会因为“模型现在很强”就默认它没问题。审核标准不变，质量门槛不变，责任归属也不变。
这才叫工程系统。
不是靠情绪做判断，而是靠规则兜底。
二、解决方案总览：普通团队到底该从 Linux 这套规范里学什么
如果你现在也在团队里推动 AI 编码工具，我的建议是，先别急着讨论“全员上不上”“要不要统一某个模型”。
真正更该先定下来的，是你们团队的AI 开发纪律。
我把 Linux 这套思路，拆成两条最适合普通团队落地的路线。
|
|
|
|
|
| 路线一：先建立责任链与标注规范 |
|
|
|
| 路线二：把 AI 纳入正式研发流程与质量门禁 |
|
|
|
如果你问我先做哪条。
我会说，先路线一，后路线二。
因为很多团队现在连“用了什么模型、谁审过、谁担责”都还没说清楚，就已经在讨论 Agent 自动提 PR 了。这个顺序，说真的，有点本末倒置。
三、路线一：先把最小可用的 AI 开发规范立起来
这条路线特别适合已经在用 AI、但流程还比较散的团队。
核心目标只有一个：别让 AI 先把协作秩序搞乱。
Step 1：先规定“AI 不能替代责任签字”
Linux 的做法特别值得直接借鉴。Signed-off-by 这种代表责任确认的签名，只能由人来完成。12
对应到普通团队，你不一定也叫 Signed-off-by，但至少要明确：凡是进入主分支、生产环境或正式交付的代码，必须有明确的人类责任人。这个责任人不是“挂名 reviewer”，而是能解释设计意图、能承担回滚与修复责任的人。
Step 2：规定凡是用了 AI，都必须留下可追溯记录
这一点，我建议你们团队不要偷懒。
Linux 要求 Assisted-by，本质上就是在建立 AI 参与记录。1 你们内部完全可以做一个更适合自己的版本，比如在 PR 模板里增加以下字段：
AI-Assisted: YesModel: Claude 3.7 SonnetUsage: 生成单元测试 / 重构样板代码 / 辅助解释旧逻辑Reviewer Check: 已逐段确认你会发现，只要把这几个字段加进去，很多“说不清”的问题立刻就少一半。
不是因为 AI 突然变安全了，而是因为你终于能追踪它了。
Step 3：把“逐行理解”写进团队共识，而不是停留在口头上
很多团队嘴上也会说“AI 生成代码要自己看过”。
但问题在于，这句话经常只是礼貌性提醒，不是流程要求。真正有效的做法，是把它写进代码评审清单里，比如要求提交者确认以下三件事：我理解这段改动；我验证过关键路径；我确认不存在明显的许可或安全风险。
Linux 官方文档明确要求人类提交者审查全部 AI 生成代码，并确保其满足许可要求，同时承担全部责任。1
这条看起来朴素，其实杀伤力最大。
因为它逼着开发者从“复制答案的人”，重新变回“理解系统的人”。
成本分析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
风险评估
|
|
|
|
|
|
|
|
|
|
|
|
四、路线二：把 AI 真正纳入研发流水线，而不是当临时外挂
如果你的团队规模更大，或者已经把 AI 用到核心业务开发里，那只做记录就不够了。
你们要做的，是把 AI 变成一个被流程约束的生产环节。
Step 1：把 AI 使用场景分级
不是所有代码都该让 AI 同等参与。
我更建议把任务拆成三层。第一层是低风险任务，比如测试样板、脚手架、日志补全、文档整理；第二层是中风险任务，比如普通业务逻辑改造与重构建议；第三层是高风险任务，比如权限、计费、交易、内核、基础设施与安全相关代码。
低风险可以放开试，中高风险必须强化人审，关键链路甚至应该限制 AI 直接产出进入主干。
Linux 的思路其实也是这个味道：不是简单反对 AI，而是先守住那条不能模糊的责任边界。12
Step 2：把 AI 记录接进 PR、审查与测试门禁
如果你们已经有 CI/CD，就别让 AI 使用记录只停留在文档里。
更成熟的做法是，把 AI 字段写进 PR 模板，把风险说明接进 review checklist，再把测试覆盖、静态扫描、安全检查和许可证检查接进自动化门禁。这样一来，AI 就不再是“谁爱怎么用就怎么用”的私人外挂，而是进入一个看得见、查得到、拦得住的系统。
Step 3：把“质量不因工具变化而放松”变成硬指标
我很认同 Linux 这次给行业上的示范意义。
它没有说“AI 这么先进了，所以我们把要求降一点”。恰恰相反，它在工具升级时，反而把责任和规范写得更清楚了。1
普通团队也该学这一点。你可以接受 AI 提高了编码速度，但不能接受测试更少、Review 更弱、上线更草率。否则看起来像效率提升，实际上只是把风险从开发阶段挪到了线上。
稳定性对比
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
五、关键注意事项
注意点一：别把“允许使用 AI”理解成“默认可信”
Linux 官方文档允许 AI 参与内核开发，但同时强调必须遵循标准开发流程，并由人类提交者负责审查与签署责任链。1
这说明一件事：允许，不等于豁免。
很多团队一听“可以用”，潜意识就会自动补成“那大概问题不大”。这一步最危险。
注意点二：真正需要规范的，不是 AI 本身，而是人怎么使用 AI
模型会变，供应商会变，价格会变，甚至今天的主流工具半年后就可能换一波。
但工程里最该稳定下来的，是那几条基本纪律：谁负责、怎么记录、如何审查、出了问题怎么追。把这几条立住了，换工具也不慌。
注意点三：不要让“高效率”成为压缩评审时间的借口
AI 最大的诱惑，就是让人误以为“既然写得快了，整个流程都该更快”。
但代码生成更快，不代表理解更快、验证更快、上线风险更低。真正成熟的团队，反而会在产能上升以后，把更多精力投到测试、审查和架构一致性上。
注意点四：规范不是为了束缚开发者，而是为了保护团队协作
很多人一听“规范”两个字就皱眉，觉得麻烦。
可你一旦经历过线上事故追不回责任、历史提交解释不清、接手人不知道代码怎么来的那种场景，就会明白：规范不是官僚主义，它是团队协作的保险丝。
Linux 这套规则之所以值得学，不是因为它看起来硬核，而是因为它把那些原本容易扯皮的地方，提前钉死了。
六、总结
一句话帮你选方案：如果你们团队现在已经在零散使用 AI，那就先把“责任人 + AI 使用记录 + 审查确认”这三件事立起来；如果 AI 已经深度进入研发流程，那就进一步把它纳入 PR、测试与上线门禁，别再把它当野生外挂。
我这次看完 Linux 的官方规则，最大的感受其实很简单。
真正强的团队，从来不是“最会追新工具”的团队，而是哪怕工具变了，责任链、审查标准和工程纪律依然稳得住的团队。
AI 当然会越来越强。
但最后能把系统做稳、把线上扛住、把团队协作跑顺的人，依旧得是那个愿意签字、愿意解释、愿意负责的开发者。12
如果你所在的团队也在推 AI 编码，我很想知道，你们现在最缺的到底是什么：是工具不够强，还是规范还没立起来？
欢迎在评论区聊聊你们团队的真实情况。
如果这篇文章对你有启发，也欢迎点个赞、点个在看，顺手转发给还在纠结“AI 到底该不该进研发流程”的朋友。
参考文章
[1]: https://docs.kernel.org/process/coding-assistants.html “AI Coding Assistants — The Linux Kernel documentation”
[2]: https://docs.kernel.org/process/submitting-patches.html “Submitting patches: the essential guide to getting your code into the kernel — The Linux Kernel documentation”
[3]: https://mp.weixin.qq.com/s/EQf5325H9H-WQPLAhkNg3g “Linus 一锤定音！Linux 官宣 AI 辅助规则，质量绝不妥协。网友：工具可以用，但锅自己背”