AI 写的代码，到底能不能进开源仓库？

如果只把它当成一个道德问题，答案会很无聊：有人说 AI 是工具，不该歧视；有人说 AI 生成内容不可信，应该一刀切。可我更关心的是另一个更工程化的问题：当维护者看不出贡献者是否真正理解这段代码时，代码审查还成立吗？

这几天 Hacker News 上一条关于 Godot 的讨论冲到了几百 points：Godot will no longer accept AI-authored code contributions。原始报道来自 PC Gamer，标题里那句很刺耳：“We can’t trust heavy users of AI to understand their code enough to fix it”。

我不想把这篇写成“Godot 禁止 AI”的新闻复述。真正值得拆的是：Godot 这类大型开源项目为什么会把 AI 贡献视为维护风险，以及这个判断对企业内部使用 Claude Code、Copilot、Cursor、Codex 这类工具有什么启发。

Godot 真正担心的不是“用了 AI”，而是责任链断掉

先看事实。

Godot 主仓库当前的 PR 模板里已经写明：Use of AI must be disclosed and should include a description of how it was used。也就是说，它至少要求贡献者披露 AI 使用方式。与此同时，一个仍在讨论中的 PR 试图把模板改得更明确：新增 Author disclosure 小节，要求如果 PR 中有不是作者自己写的部分，或者使用了 AI，就具体说明 AI 被用于哪里。这个 PR 的动机写得很直白：过去一个月里，明显由 AI 生成的 PR 里，至少一半没有披露；审查者不得不花时间调查 PR 和作者来判断 AI 使用情况，浪费维护者精力。见 godotengine/godot#119894。

提案仓库的态度更硬一些。godotengine/godot-proposals#13956 试图在 README 中加入规则：proposal 必须由人类写成，不允许用 AI/LLM 写 proposal；理由是 AI 写的提案难读，而且经常编造事实和不可行的解决方案。补丁里的原文甚至建议：如果英文不舒服，可以先用母语写，再用专门的翻译软件翻译，不要用聊天机器人代写。

这不是保守派对新工具的本能排斥。Godot 本身是一个非常活跃、复杂度很高的项目：GitHub API 显示 godotengine/godot 有 11 万以上 stars，最近一次 push 就在 2026-07-02，open issues 超过 1.8 万。维护这种项目，最大的稀缺资源不是“代码行数”，而是能长期解释、修复、回滚、演进代码的人。

说白了，开源项目缺的从来不是更多 diff，而是可靠的责任链。

AI 生成代码最容易破坏的正是这条链：贡献者提交了一个看起来能编译的补丁，但当 reviewer 追问边界条件、性能影响、平台兼容性、为什么不用现有抽象时，贡献者可能回答不上来。代码如果合进去，未来 bug 还是维护者背锅。

为什么“能跑测试”不够？

很多团队现在有一个默认假设：AI 生成代码只要 CI 过、测试过，就可以合并。坦白说，这个假设在小型业务系统里有时够用，但放到基础设施或大型开源项目里很危险。

测试验证的是“已知输入下的行为”，代码审查还要验证三件更难的事：

第一，设计是否符合项目的长期架构。AI 很擅长局部补丁，但不一定知道一个引擎为什么十年前就避开了某个抽象，或者某个平台后端为什么有一堆看起来丑但不能删的兼容逻辑。

第二，作者是否能继续维护。一个人自己写出来的代码，哪怕不完美，通常能解释取舍；AI 代写的代码如果作者没有消化，review 就会变成维护者单方面逆向工程。用人话说就是：你把作业交上来了，但老师发现你自己也不知道怎么做的。

第三，事实是否可靠。Godot proposals 的补丁里特别提到 AI-written proposals “often invent facts and solutions that won’t work”。这点我非常认同。LLM 在写 proposal 时经常把“听起来合理”当成“项目里真实存在”，比如虚构配置项、虚构性能瓶颈、虚构历史讨论。代码也一样，尤其在大型 C++/引擎/编译器项目里，幻觉不是一句错话，而可能是一条维护成本很高的技术债。

这也是为什么我觉得“AI 代码检测器”不是正解。检测器只能猜这段文本像不像 AI 写的，解决不了作者是否理解的问题。真正该审查的是责任能力，而不是来源纯洁性。

开源维护者的成本模型变了

过去，维护者面对低质量 PR，主要问题是“写得差”。现在多了一个新问题：“写得像那么回事，但语义上不负责任”。

这很麻烦。

传统低质量 PR 往往一眼能看出来：格式乱、测试缺、issue 没读、需求没对齐。AI 生成 PR 则可能格式很好、措辞礼貌、甚至覆盖了测试，但里面混着微妙错误。审查者需要花更多时间确认：这是不是项目已有机制的重复实现？是不是修了一个症状但绕开了根因？是不是引入了不可维护的抽象？

Godot PR #119894 的描述里有一句很关键：reviewer 的一半时间会花在 investigating the PR and author to determine AI usage。注意，不是说“AI 代码一定差”，而是“不披露会让 reviewer 增加额外调查成本”。

这点对企业团队也成立。你当然可以让工程师用 AI 提速，但如果公司没有披露、审查、测试和所有权规则，代码审查会慢慢变成一种猜谜游戏：这段代码到底是作者理解后写的，还是模型一次性吐出来的？出了问题谁会修？

我在之前写 Open Design 能否把编码 Agent 变成设计引擎 时也提过类似问题：Agent 真正进入工程流程后，关键不只是生成能力，而是沙盒、预览、约束和回滚链路。放到代码贡献里，约束就变成了 disclosure、ownership、test plan 和 reviewer 能追问的设计说明。

企业内部应该怎么定规则？

我不建议企业照搬“禁止 AI 代码”。大多数业务团队没有 Godot 这种公共维护压力，而且 AI 编程工具确实能显著提高样板代码、迁移脚本、测试补齐、文档重写的效率。

但也别走到另一端，把 AI 当成无限外包的初级程序员。比较现实的做法，是把 PR 分成几类处理。

低风险场景可以放宽：文档修订、测试 fixture、重复性 CRUD、脚本迁移、类型标注、日志和错误信息整理。这里 AI 的价值很高，风险可被测试覆盖。

中风险场景要求披露和解释：核心业务逻辑、权限判断、数据迁移、并发控制、性能敏感路径。作者需要在 PR 里说明 AI 用在了哪里、自己验证了什么、哪些地方不确定。这里的关键不是羞辱“用了 AI”，而是让 reviewer 知道该把注意力放在哪。

高风险场景应该接近 Godot 的态度：安全边界、加密、支付、数据库事务、基础设施控制面、公共 API 兼容层、跨平台底层代码。可以用 AI 辅助阅读和生成候选方案，但最终设计说明、威胁模型、回滚方案、测试计划必须由人负责。

如果团队已经在用 Claude Code 或类似工具，我会建议在 PR 模板里加四个问题：

  1. 是否使用了生成式 AI？用于代码、测试、文档、调研还是重构？
  2. 哪些关键逻辑由作者重新审阅并能解释？
  3. 增加了哪些测试，覆盖了哪些边界条件？
  4. 如果线上出问题，回滚路径是什么？

这四个问题比“你是不是 AI 写的”更有用。它们把讨论从身份判断拉回工程责任。

“短绳子”比“全自动”更适合现在的 AI 编程

HN 上同一天还有一篇文章叫 The short leash AI coding method for beating Fable，热度没 Godot 高，但观点很贴近这个问题：让 AI 编程时要短绳控制，不要放任它长距离自主修改。这个说法我挺喜欢。

短绳子的本质，是把 AI 当成高吞吐的局部助手，而不是不需要监督的远程贡献者。你让它改一个函数、补一个测试、解释一个调用链，然后马上验证；不要让它一次性横跨十几个文件做“架构级重构”，最后提交者自己也说不清发生了什么。

这和我之前写 Vibe Coding 让你跳过学习，这个开源项目偏要让你亲手写代码 的判断是一致的：AI 最大的问题不是帮你省时间，而是让你误以为可以跳过理解。个人学习如此，团队协作更是如此。

我的判断：披露不是形式主义，是降低审查不确定性

我不认为未来开源会普遍禁止 AI 贡献。相反，很多高质量贡献会越来越多地使用 AI：生成测试、解释代码、找 edge case、写迁移脚本、做机械重构。问题在于，维护者必须知道自己在审查什么。

Godot 事件的价值，不是给大家一个“AI 禁令模板”，而是提醒我们：代码贡献不是文本提交，背后有维护责任。AI 可以参与生产代码，但不能成为责任主体。

所以我会把这件事总结成一句话：AI 生成代码能不能进仓库，取决于人是否重新接管了理解、验证和维护责任。

如果没有这一步，AI 代码再像人写的，也只是把维护成本从提交者转移给 reviewer。对大型开源项目来说，这不是效率提升，而是新的供应链噪音。

参考信源