Linus 让 Claude Code 写内核补丁，这事最该看的不是 AI 会不会写 C
内容提要
Linus Torvalds 在指导下使用 Claude Code 编写 Linux 内核补丁，代码、测试和邮件初稿均由 AI 完成。文章指出，关键不在于 AI 能否写 C，而在于人仍掌握方向与取舍。AI 可承担机械工作，但审查、测试和维护责任不能外包。团队应将 AI 视为无责任感的初级同事，从低风险任务入手，确保可 diff、可复现、可回滚，再接触核心代码。
延伸解读
“在我的指导下”是关键边界
文章强调，Linus 描述中“在我的指导下”这句话划清了责任边界。Claude Code 可能完成了代码、测试和邮件初稿等机械工作，但方向、取舍和最终签字仍由人负责。这提醒团队，AI 生成的补丁再漂亮，也不能替代审查者对上下文的理解和判断。
内核场景放大 AI 代码风险
Linux 内核不像业务项目有框架和类型检查兜底，一个小改动可能触及文件系统、内存管理、并发路径和硬件兼容性。编译通过和作者机器上的测试只是门槛，远不足以证明安全。因此，AI 参与内核补丁时，审查流程必须更严格，不能因代码“像人写的”就放松。
把 AI 当无责任感的初级同事
文章建议将 AI 视为速度快但无责任感的初级同事：它可以铺实现、写测试，但人必须按正常流程走——读 diff、跑测试、解释改动原因。解释不清就不合并。尤其底层库、数据迁移、权限、缓存一致性和并发代码，不能因生成快就省审查。
从低风险任务开始落地
若团队想引入 Claude Code 类工具，应从测试补齐、脚手架、文档草稿、小范围重构等低风险区域入手，确保每步可 diff、可复现、可回滚。流程跑顺后再碰核心路径，避免直接改支付、权限或核心存储链路，否则是在给未来埋雷。
Q&A
Linus Torvalds 用 Claude Code 写内核补丁，这件事的关键点是什么？
关键不在于 AI 能否写 C 代码，而在于人仍然掌握方向和取舍。Claude Code 在 Linus 指导下完成了代码、测试和邮件初稿，但方向、判断和最终签字仍由人负责。
为什么说 AI 生成的补丁不能直接进 Linux 内核主线？
内核补丁不是生成一段 C 代码就能进主线，真正麻烦的是补丁背后的判断：改哪里、为什么改、怎么证明没破坏老路径、谁承担合并后的维护成本。内核场景对错误容忍度低，一个小改动可能影响文件系统、内存管理、并发路径和硬件。
团队应该把 AI 编程工具当成什么角色来用？
把 AI 当成一个很快但没有责任感的初级同事。它可以先铺一版实现、做重复劳动、写测试，但人必须按正常流程走：自己读 diff、自己跑测试、自己解释为什么这样改，解释不清楚就别合。
AI 参与编码后，代码审查流程需要做哪些调整？
审查不能只看“写得像不像人”，越像成熟工程师写的越容易让人放松。不能默认 AI 产出的东西已被某种神秘能力检查过。尤其底层库、数据迁移、权限、缓存一致性和并发相关代码，不能因为生成速度快就省掉审查。
团队想引入 Claude Code 这类工具，应该从哪些任务开始？
先从低风险区域开始，比如测试补齐、脚手架、文档草稿、小范围重构。每一步都要能 diff、能复现、能回滚。等流程跑顺了，再碰更靠近核心路径的代码，不要一上来就改支付、权限或核心存储链路。
AI 编程工具真正改变的是什么？
真正改变的不是“谁按键盘”，而是团队怎么分配注意力。生成代码会变便宜，审查、测试和维护会显得更贵。谁把后半段流程做扎实，谁才真的能从工具里赚到时间。
