AI 代码谁负责 merge？Generated Code is Real Code

Agent 可以帮你提速，但不能替你承担风险——merge 按钮永远在人手里

「反正是 AI 写的，凑合 merge 吧。」

2026 年，这句话在不少团队里已经不再是玩笑，而是一种真实的工作压力：PR 变多了、变大了、生成速度比 review 快得多，于是有人开始把 merge 当成「走流程」。

JetBrains 在 2026 年 4 月的一篇官方博文里，给了一个很硬的立场：

Generated code should be treated like real code.（生成出来的代码，应该被当作真正的代码来对待。）

这意味着：能读、能审、能改、能回滚、能评估对代码库的影响——标准不能降。

同一段博文还有一句更直白的话：

Agents can help you move fast — but they can't carry the risk for you.（Agent 能帮你加速，但不能替你承担风险。）

所以这篇文章要回答的问题很简单：AI 代码谁负责 merge？

答案也很直接：点 merge 的那个人，以及他背后的团队。

一、为什么「AI 写的」不是免责理由？

1. 法律与职业责任：merge 即背书

无论代码是人敲的还是 Agent 生成的，一旦进入主分支、部署上线，责任人都是批准合并的工程师和团队。

IBM 早年培训里有一句话，在 AI 时代反而更贴切：

A computer can never be held accountable. That's your job as the human in the loop.（计算机无法被追责，回路中的人才是。）

GitHub 在讨论 AI 时代 code review 时也强调：开发者永远拥有 merge 按钮的所有权——不是形式上的点击权，而是 对结果的背书义务。

2. JetBrains 的「真实代码」标准

JetBrains 认为，专业 IDE 面向的是 长期维护的代码，不是一次性扔掉的 demo。

因此对 AI 生成代码的底线期望很「无聊」，但恰恰最重要：

换句话说：生成方式变了，质量门槛没变。

3. 「反正是 AI 写的」到底在逃避什么？

常见借口背后，其实是三类偷懒：

1. 逃避理解：「我没细看，但 AI 应该没问题」

2. 逃避验证：「没跑测试，反正 CI 会拦」

3. 逃避归属：「出事了算模型的锅」

Mozilla AI 一篇关于 code ownership 的文章点得很准：当你 prompt 模型、扫两眼 diff 就 merge，你不再是作者，而是 审查者、架构师、集成者——但 责任并没有跟着角色一起移交出去。

二、协作悖论：用得多，敢放手的人少

Anthropic《2026 Agentic Coding Trends Report》里有一个常被引用的数据：

• 开发者约 60% 的工作会用到 AI

• 但能 完全委托 给 AI 的任务只有 0–20%

这不是矛盾，而是行业真相：AI 是日常协作伙伴，不是自动员工。

有效协作需要设置、监督、验证，尤其在高风险场景。工程师会把 易验证、低风险 的任务更多委托出去；把 概念难、设计依赖强 的工作留给自己。

所以 merge 的责任模型很清晰：

• 可以 让 AI 写绝大部分实现

• 不可以 把 merge 决策也委托给 AI

• 必须 由人证明「我懂这段改动、我接受它的风险」

三、merge 之前，谁该做什么？

可以把一次 AI 辅助 PR 的责任拆成 四层，缺任何一层都不该点 merge。

第 1 层：作者——证明它 work，而不是承诺它 work

Addy Osmani 在 2026 年初总结过一条铁律：

If you haven't seen the code do the right thing yourself, it doesn't work.

他建议团队采用 PR Contract（PR 契约），作者合入前至少说清楚四件事：

1. What/Why：1–2 句话说明意图

2. Proof it works：测试通过、手动验证步骤、截图或日志

3. Risk + AI role：风险等级；哪些部分是 AI 生成

4. Review focus：希望 reviewer 重点看哪里（架构？安全？边界条件？）

核心不是填表，而是：如果你填不出来，说明你还不够格请求别人 approve。

第 2 层：工具——先拦 IDE 能拦的问题

JetBrains 另一篇 2026 年 5 月的博文标题就很刺：

Stop Sending IDE-Catchable AI Code Errors to Review（别把 IDE 能抓的错误扔给 reviewer）

AI 提高了 PR 产量，也改变了缺陷画像：更多语法问题、类型错误、未使用变量、明显坏味道——这些 本该在本地消灭，不应占用人类 reviewer 的带宽。

建议流程：

Agent 生成 → IDE 检查/静态分析 → 本地测试 → 再开 PR

merge 负责人不是垃圾回收站。

第 3 层：Reviewer——看 AI 看不透的东西

AI review bot 可以扫掉 70–80% 的低垂果实，但 Graphite 创始人 Greg Foster 说得很清楚：

I don't ever see AI agents becoming a stand-in for an actual human engineer signing off on a pull request.

人类 reviewer 应聚焦：

• 架构一致性：是否破坏现有模式

• 业务上下文：是否解决正确问题

• 安全面：鉴权、支付、密钥、不可信输入

• 可维护性：六个月后的 on-call 能否看懂

• 知识传递：作者能否讲清楚为什么这样写

OCaml 维护者曾拒绝一个 1.3 万行 的 AI 生成 PR——代码未必全错，但 没人有足够带宽审完，且审 AI 代码比审人写代码更耗神。

教训：AI 能洪水般产代码，团队必须管理产量。

第 4 层：组织——用制度固定责任链

团队级 merge 责任，建议写进三条硬规则：

1. No merge without human sign-off（必须有人类签字）

2. No large AI dump PRs（禁止巨型 AI 倾倒式 PR）

3. High-risk paths need named owner（支付/鉴权/数据路径要有具名负责人）

四、数据告诉我们：merge 马虎的代价在变大

几个 2025–2026 年常被引用的观察值（不同样本，宜作趋势参考而非绝对标准）：

另有研究指出：AI 生成代码在 逻辑错误、XSS 等类别上，频率可能显著高于人工代码——具体倍数因项目而异，但方向一致：审查不能省。

JetBrains 在 GITEX 2025 分享里也提到：开发者最担心的不是失业，而是 信任——要的是可靠、可维护、安全的输出，没有质量的速度毫无意义。

五、三种 merge 心态，只有一种负责任

❌ 心态 A：「AI 写的，我不背锅」

• merge 时说不清改动逻辑

• 出线上事故推给「模型幻觉」

• 团队知识断层，on-call 成本飙升

⚠️ 心态 B：「我扫了一眼，应该没事」

• 看了 diff 但没跑、没测

• 把 review 当成礼貌性流程

• 短期省时间，长期还债

✅ 心态 C：「我批准，我负责」

• 能解释改动意图和边界

• 有测试/验证证据

• 知道回滚路径

• 对高风险路径额外加人审

JetBrains 的原话适合贴在 PR 模板里：

Someone still has to be responsible for that code. Someone still has to read it before it merges.

六、一套可落地的「AI 代码 merge 清单」

合入前 10 项，建议打印在团队 wiki：

作者自检

• [ ] 我能用 2 分钟向同事讲清这次改动

• [ ] 本地/CI 测试通过，关键路径手动验过

• [ ] 标明了哪些 hunks 来自 AI 生成或 AI 改写

• [ ] PR 足够小（建议 < 400 行有效变更；超大变更已拆分）

• [ ] IDE/静态分析告警已清零或逐项解释

Reviewer 检查

• [ ] 架构与现有模式一致，无重复造轮子

• [ ] 安全敏感路径已人工过一遍

• [ ] 作者能回答「为什么不用另一种实现」

• [ ] 观测/日志/回滚策略对得上风险等级

组织底线

• [ ] 有明确 human sign-off，不是 bot 自动 merge

• [ ] 生产事故责任归属到工程流程，不推给「工具」

七、和 Agent 系列的关系：指挥官必须对战果负责

如果你一直在跟本号的 Agent 系列，可以把本文当成 「指挥者责任」 的实操篇：

Agent 时代的能力模型，不是「会 prompt」，而是「敢对自己的 merge 签字」。

八、结论

「Generated Code is Real Code」不是口号，是 工程纪律：

• AI 改变的是 代码的生产方式

• 没有改变 代码进入主分支的质量标准

• 更没有改变 人对系统的最终责任

谁负责 merge？

你。

Agent 可以写代码、写测试、写 PR 描述、甚至做第一轮 review——但 merge 按钮背后那份风险，只有人能签。

资料来源

• JetBrains《Our 2026 Direction: AI and Classic Workflows in JetBrains IDEs》：https://blog.jetbrains.com/ai/2026/04/our-2026-direction-ai-and-classic-workflows-in-jetbrains-ides/

• JetBrains《Stop Sending IDE-Catchable AI Code Errors to Review》：https://blog.jetbrains.com/ai/2026/05/stop-sending-ide-catchable-ai-code-errors-to-review/

• JetBrains《5 Ways AI Will Shake Up Software Development in 2026》：https://www.linkedin.com/pulse/5-ways-ai-shake-up-software-development-2026-jetbrains-rnsyc

• Anthropic《2026 Agentic Coding Trends Report》：https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf

• Addy Osmani《AI writes code faster. Your job is still to prove it works》：https://addyosmani.com/blog/code-review-ai/

• Mozilla AI《Owning Code in the Age of AI》：https://blog.mozilla.ai/owning-code-in-the-age-of-ai/

• GitHub Blog《Code review in the age of AI: Why developers will always own the merge button》：https://github.blog/ai-and-ml/generative-ai/code-review-in-the-age-of-ai-why-developers-will-always-own-the-merge-button/

文中涉及的安全缺陷比例、PR 体积变化等数据来自不同研究机构与厂商样本，适用于理解趋势，不宜直接当作你团队的精确基线。