Linux 内核，开始把 AI 的责任边界写进文档

今天另一个很值得记录的题，是 Linux 内核仓库里那份关于 AI coding assistants 的正式文档。它不长，甚至可以说相当克制，但正因为克制，反而很有信号意义。

很多人讨论 AI 写代码时，注意力都放在能力层面：能不能写、写得好不好、会不会引入 bug、会不会降低门槛。Linux 这份文档的重点却不在这里。它没有花很多笔墨去评价 AI 能力，而是先把一个更成熟的问题放到了前面：当 AI 进入正式贡献流程以后，责任究竟由谁承担，法律语义如何成立，贡献记录该怎样表达。

文档里最关键的一句，其实不是"可以使用 AI"，而是"AI agents MUST NOT add Signed-off-by tags"。这句话背后的意思很明确：在 Linux 的贡献体系里，Signed-off-by 对应的是 Developer Certificate of Origin，不是一种礼貌性的署名，而是一种带法律与责任含义的认证。只有人类提交者才能做出这种声明。换句话说，AI 可以帮你写、帮你改、帮你分析，但它不能替你承担义务，也不能替你完成承诺。

这件事看起来平淡，实际上非常重要。因为它把 AI 在工程流程中的位置讲清楚了。AI 不是一个"新同事"，更不是一个可以自然继承责任主体资格的参与者。它更像一种高能力工具，甚至是一种会主动生成内容的复杂工具。工具可以提高效率，但责任不能随着效率一起外包出去。最终负责 review、许可证兼容、语义正确性和提交真实性的，仍然是那个人类开发者。

我觉得 Linux 这份文档的成熟之处，就在于它没有陷入那种常见的虚假二选一：要么全面拥抱 AI，要么全面禁止 AI。现实世界里，这两个极端都不太有操作性。真正可执行的治理方式，通常不是争论"能不能用"，而是定义"用了以后谁负责、怎么披露、哪些边界不能跨过去"。

文档里还提到一个有趣的点：建议用 Assisted-by 标签记录所使用的 AI 工具、模型版本，以及特定分析工具。这也不是一个表面上的礼节问题，而是可追踪性问题。软件工程一旦进入多人协作和长期维护，最怕的不是曾经用过什么工具，而是以后没人知道当时用了什么工具。如果某类 AI 工具在某段时间里倾向于引入某种模式的错误，或者某个模型版本后来被发现有严重代码归因风险，那么保留这种辅助信息，至少能让后续分析更有依据。

当然，这也意味着开源社区开始默认接受一件事：AI 辅助编程不是偶发现象，而是需要被纳入正式流程治理的常态现象。一个技术一旦进入文档层，就说明社区已经不再只把它当成个人习惯，而是把它看成会影响整体协作秩序的变量。Linux 在这里做的，并不是拥抱潮流，而是在做一件更朴素的事：把含糊地带变少，把责任链写清楚。

这对普通开发团队的启发其实很直接。很多团队现在已经在默默使用 AI，但流程层还是空白的。谁可以用、哪些仓库可以用、生成代码需要什么级别的 review、要不要披露、出了许可证问题算谁的、提交记录怎么保留，这些事情往往都没写。平时看起来没事，一旦真的出问题，就会发现每个人脑子里的默认规则都不一样。

所以比起争论"我们团队要不要上 AI coding"，更成熟的问题可能是：如果已经有人在用，我们的责任边界有没有定义清楚。至少有三件事值得明确。第一，AI 生成内容不能降低 review 标准，反而应该提高。第二，法律与许可证声明必须由人承担，不能让自动化流程代签。第三，要有基本的可追溯性，未来出了问题，知道该回看哪里。

从更长的时间看，我认为这类文档会越来越多。不是因为大家突然对 AI 更保守了，而是因为技术一旦进入生产系统，就必须被制度化。制度化的意义，从来不是为了打压效率，而是为了让效率不会顺手把责任结构一起冲垮。

Linux 这份文档真正传递的信号很朴素：AI 可以进入工作流，但不能进入责任真空。谁提交，谁负责。谁签字，谁承担后果。至于 AI，它可以很强，但它还不是法律主体，也不是伦理主体。把这件事写清楚，反而是工程世界对 AI 最现实的一种欢迎方式。