文章总结： LinusTorvalds对AI辅助内核开发的态度从保留转向务实立规。2026年4月，Linux7.0发布时，官方文档中加入了AI辅助开发的规范，要求开发者在使用AI工具时进行透明标注，并对代码质量负责。 综合评分： 90 文章分类： 渗透测试,代码审计,应急响应,漏洞分析,威胁情报,恶意软件,安全意识,实战经验,SRC活动,软文广告,产品介绍,AI安全,二进制安全,CTF,WEB安全,红队,内网渗透,IoT安全,移动安全,安全建设,安全工具,技术标准,政策法规,供应链安全,漏洞预警,解决方案,数据安全,应用安全,网络安全,办公安全,终端安全,云安全,区块链安全,安全培训,安全运营,社会工程学,安全招聘,数据泄露,车联网安全,逆向分析,爬虫,免杀,安全开发,漏洞POC,安全大事件,娱乐吃瓜,其他
Linus Torvalds谈AI辅助内核开发：不是妥协，而是务实立规
原创
秀逗猫 秀逗猫
秀逗猫
2026年4月16日 10:27 北京
在小说阅读器读本章
去阅读
一、Linus 对 AI 辅助开发的态度，曾经历过明显的保留
在2024年的公开访谈中，Linus Torvalds 曾表达过强烈的保留态度：
「内核有几千万行代码，每一行都关系到全球服务器的稳定运行。你觉得我会让一个连’为什么这么写’都解释不清的AI去碰它吗？」
他也曾在多个场合将 AI 生成的代码称为「slop」——垃圾。他并不否认 AI 是有趣的工具，但对「AI 直接写内核代码」持明显保留态度。
然而，随着 AI 工具在开发者中的快速普及，以及内核社区中越来越多“偷偷使用 AI 但未标注”的情况出现，Linus 和维护团队的态度也逐步转向务实管理。2026年4月12日，随着 Linux 7.0 正式发布，Linux 内核官方文档库也同步上线了一份新文件：《AI assistance when contributing to the Linux kernel》（https://docs.kernel.org/process/coding-assistants.html）。
这份文档很短，但信息量很大。
二、从「谨慎保留」到「务实立规」
要理解这份规范的意义，需要把时间线稍微拉长一点。
早期阶段：保留但开放
这一阶段大约从2023年持续到2024年。
Linus 本人并非完全排斥 AI。他在公开演讲中表示，AI 更适合用于代码审查、bug 定位、风格检查等辅助任务，而非直接生成关键代码。他的核心担忧是：
「写代码和理解代码是两回事。AI可以生成看起来正确的代码，但它不’理解’代码。」
在 Linus 看来，内核代码的价值不只是「能跑」，更在于可审计、可维护、可追溯。人类开发者写的代码，背后是设计意图和权衡取舍；AI 生成的代码，则像是「根据训练数据中 10 万次相似场景生成的概率输出」。
这个阶段，内核社区对 AI 的态度可以总结为：不鼓励、不禁止、持续观察。
2025年：问题开始显现
随着 GitHub Copilot、Claude Code 等工具的普及，社区开始面对一个现实问题：开发者已经在使用 AI 辅助开发了。
据内核维护者 Greg Kroah-Hartman 在 LKML（Linux Kernel Mailing List）上的反馈，社区发现有人在提交中使用了 AI 辅助，但 commit message 中没有任何标注。
这个问题在开源社区中并非 Linux 独有。据媒体报道，2026 年初，Node.js 项目就出现了一个引发广泛讨论的案例：一位开发者提交了约 1.9 万行由 Claude Code 生成的代码，用于实现文件系统 API 的各种变体。社区围绕「审核成本」「设计意图缺失」「维护责任」等问题展开了激烈辩论。
2026年初：官方规范出台
经过数月的社区讨论，Linux 内核维护团队在2026年4月，随着 Linux 7.0 的发布，正式将这份指南纳入文档体系。
这份文档的核心立场，可以概括为两个原则：
- AI 不能签署 Signed-off-by——只有人类才能对代码的原创性和许可证合规性负法律责任
- 使用 AI 必须透明标注——通过
Assisted-by标签让审查者知情
这不是「开放使用」，而是「有条件的接纳」——条件还很严格。
三、规范核心内容
硬规则一：Signed-off-by 只能是人类的
在 Linux 内核的提交流程中，Signed-off-by 标签对应的是 DCO（Developer Certificate of Origin，开发者原创证书）。签署这个证书意味着：
「我声明这段代码的作者是我，或我有合法权利提交它，且代码遵循 GPL-2.0-only 许可证。」
DCO 是有法律效力的声明。AI 工具显然无法履行这一承诺。因此，规范中明确要求：
AI 工具绝对不能添加 Signed-off-by 标签。只有人类可以签署。
这意味着：即使代码 100% 由 AI 生成，提交者依然对代码的原创性、许可证合规性负全部责任。
硬规则二：使用 AI 必须标注
如果开发过程中使用了 AI 辅助，必须在 commit message 中添加 Assisted-by 标签：
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
# 例如
Assisted-by: Claude:claude-3-opus coccinelle sparse
标签格式包含三层信息：
- AI 工具名称（如 Claude、Copilot）
- 模型版本（如 claude-3-opus）
- 使用的其他辅助工具（如静态分析工具 coccinelle、sparse）
注意：基础开发工具（如 git、gcc、make）不需要列出。
官方文档中的解释是：
「我不是要羞辱用 AI 的人。但审查者有权知道这段代码的’上下文’。如果我知道这是 AI 辅助的，我会更仔细地检查边缘情况和边界处理。」
这不是歧视，这是知情权——开源协作的基本伦理。
硬规则三：出了问题，人类全责
这是最「硬」的一条，没有任何模糊地带：
- AI 生成的代码有漏洞？提交者的责任。
- AI 生成的代码许可证不兼容？提交者的责任。
- AI 幻觉出 GPL 不兼容的代码？还是提交者的责任。
想甩锅给 OpenAI 或 Anthropic？文档中已经提前堵死了这条路：
「这些 AI 公司的服务条款明确声明：模型输出不构成任何保证。你用了他们的工具，就要承担后果。」
四、如何理解这一规范？
不是「妥协」，而是「务实」
有人将这份规范解读为「Linus 向 AI 妥协了」。这个说法值得商榷。
回顾 Linus 的一贯风格：他不关心「技术政治」，无论是「AI 要毁灭世界」还是「AI 要拯救一切」，在他看来都是噪音。他只关心一件事——代码能不能工作，维护成本高不高，社区能不能健康发展。
当社区中出现「偷偷用 AI、不标注」的情况时，Linus 的反应不是「禁止」，而是 「既然拦不住，那我们就定规则」。
这和他处理其他技术争议的方式一脉相承：面对现实，制定规则，继续掌控局面。
规范的设计逻辑
这份规范的设计逻辑很清晰：
1. 不假设 AI 代码一定有问题
2. 但要求 AI 使用透明化
3. 透明化的目的是：让审查者知情，让责任可追溯
4. 责任归人类，是为了确保「有人对代码负责」
审核效率的问题，规范选择不直接回答——因为这不是规范能解决的技术问题，而是社区流程和工具链需要持续演进的领域。
五、关于「审核能否跟上」的思考
有读者提出一个很实际的问题：「AI 写得那么快，人真的审得过来吗？」
这个问题值得认真思考。
现实存在的挑战
首先，不能回避这个现实。以下是社区估算的典型场景对比：
| 场景 | AI 生成速度 | 人类审核时间 | | — | — | — | | 500 行驱动函数 | 5-10 分钟 | 30-60 分钟 | | 完整 fs API 变体 | 1-2 小时 | 2-4 小时 | | 大规模 PR（参考 Node.js 案例） | 数天 | 数十人·周 |
效率差距是客观存在的。 AI 时代，审核环节成为流水线瓶颈的趋势也是真实的。
Linux 社区的回应逻辑
但 Linux 内核的这份规范，选择了一个务实的角度来回应这个问题：
与其讨论「审核能否跟上」，不如确保「出了问题能找到人」。
这是什么意思？
开源代码审查的核心目的，不只是「检查每一行代码有没有问题」，更是 「确保代码可维护、责任可追溯」。如果每行代码都要 100% 理解后才能合并，那 Linux 内核几千万行代码早就停滞了。
Assisted-by 标签 + 人类全责的规范组合，实际上是在建立一种信任机制：
- 审查者有权知道代码是否涉及 AI 辅助
- 提交者对代码负责，无论来源是人还是 AI
- 这让「地毯式审核」变成「有针对性的重点审核」
社区在探索的其他方向
当然，行业也在探索其他解法，比如：
- 分层审核：CI 自动化检查（风格、许可证、安全扫描） → AI 辅助逻辑审查 → 人工深度审查（仅限关键路径）
- 结构化上下文：要求 AI 生成代码时附带「设计意图文档」，说明边界条件、约束假设等
- AI 审核 AI：用大模型检测 AI 生成代码的潜在问题（但这本身也有局限性）
这些方向都有价值，但也都还在演进中。Linux 内核的这份规范，并没有声称自己解决了审核效率的问题——它只是建立了一个目前可以运作的信任机制。
六、对普通开发者的启示
说了这么多大项目的事，对普通开发者有什么启发？
1. 审查能力比写代码更重要
AI 时代，「能写代码」的门槛在降低。但「能审查代码、判断质量」的价值在上升。
用 AI 生成代码后，你需要能回答：
- 这段代码的逻辑是否正确？
- 有没有隐藏的边界情况？
- 这个方案的设计意图是什么？
如果你用 AI 写代码，但自己审不了——那风险是隐形的。
2. 透明标注是专业素养
在 commit message 中标注 AI 使用，不只是一个「规定」，更是一种对协作者负责的态度。
就像食品包装要标注配料一样——不是为了羞辱谁，而是让使用者做出知情的判断。
3. 责任永远是人的
无论工具怎么变，「这段代码是谁负责的」这个问题不会消失。
在按下 Submit 之前，问自己三个问题：
- 我理解这段代码吗？
- 我检查过许可证合规性吗？
- 我准备好为它的未来负责了吗？
如果任何一个答案是「否」，就别提交。
七、结语
Linux 内核的这份 AI 使用规范，不是「开放」，也不是「禁止」，而是一种务实的中间路线——
承认现实，建立规则，确保有人负责。
对于整个开源社区来说，这也许提供了一种参考：面对不可阻挡的技术趋势，与其情绪化地争论「要不要」，不如具体地讨论「怎么做」。
对于正在使用 AI 编程工具的开发者来说，这个故事也提出了一个值得思考的问题：
当你享受着 AI 带来的效率提升时，是否认真想过：如果这段代码出了问题，你该负什么责？
行动建议： 如果你在用 AI 辅助开发，不妨参考 Linux 内核的做法——严格审查每一行代码，确保真正理解；透明标注 AI 使用，对协作者负责。 这不是在给自己添麻烦，而是在建立长期的专业信誉。
参考链接
- Linux 内核官方 AI 使用规范：https://docs.kernel.org/process/coding-assistants.html
- Developer Certificate of Origin (DCO)：https://developercertificate.org/
你在用 AI 写代码吗？有没有遇到过审核或责任相关的问题？欢迎在评论区分享。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：秀逗猫 秀逗猫 秀逗猫《Linus Torvalds谈AI辅助内核开发：不是妥协，而是务实立规》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论