--- title: 260307-AI 写代码更快，你的工作是证明它能用 description: AI 并没有杀死代码审查，而是让举证责任变得明确。通过手动验证和自动化测试等证据来交付变更，然后使用审查来评估风险、意图和责任。独立开发者依靠自动化来跟上 AI 的速度，而团队则使用审查来建立共享上下文和所有权。 author: Addy Osmani source: https://addyosmani.com/blog/code-review-ai/ date: '2026-03-07' category: 04-engineering-practices tags: - AI辅助开发 - 代码审查 - 工程实践 - 测试驱动 - 软件质量 --- # AI 写代码更快，你的工作是证明它能用 **作者：Addy Osmani** **原文：[查看原文](https://addyosmani.com/blog/code-review-ai/)** > ## 摘要 > > AI 并没有杀死代码审查，而是让举证责任变得明确。通过手动验证和自动化测试等证据来交付变更，然后使用审查来评估风险、意图和责任。独立开发者依靠自动化来跟上 AI 的速度，而团队则使用审查来建立共享上下文和所有权。 **AI 并没有杀死代码审查，而是让举证责任变得明确。通过手动验证和自动化测试等证据来交付变更，然后使用审查来评估风险、意图和责任。独立开发者依靠自动化来跟上 AI 的速度，而团队则使用审查来建立共享上下文和所有权**。 如果你的 pull request 不包含它能正常工作的证据，你并不是在更快地交付——你只是把工作推到了下游。 到 2026 年初，[超过 30% 的高级开发者](https://www.infoworld.com/article/4049949/senior-developers-let-ai-do-more-of-the-coding-survey.html)表示自己主要在交付 AI 生成的代码。真正的挑战不在“能不能生成”，而在于如何把这些产出验证到可交付的程度。[有研究](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)指出，如果缺少足够的约束与验证，逻辑层面的错误会明显增加。这也解释了为什么工作流会分化：独立开发者常用测试套件托底，以“推理速度”推进；团队则还要依赖人工审查来补足上下文、责任和合规要求。无论是哪一种，AI 都只是加速器，真正定义质量差异的仍然是验证机制——由谁做、验证什么、在什么时候做。 正如我之前所说：如果你没有亲眼看到代码正确运行，它就还不能算“可用”。AI 让这条规则变得更重要，而不是更宽松。 ## **开发者如何使用 AI 进行审查** - **临时 LLM 检查**：在提交前将差异粘贴到 Claude、Gemini 或 GPT 中进行快速的 bug/风格扫描。 - **IDE 集成**：使用 Cursor、Claude Code 或 Gemini CLI 等工具在编码期间获得内联建议和重构。 - **PR 机器人和扫描器**：GitHub Copilot 或自定义代理在 PR 中标记问题；与 Snyk 等静态/动态分析配合使用以确保安全。 - **自动化测试循环**：使用 AI 生成并运行测试，强制执行 >70% 的覆盖率作为门槛。 - **多模型审查**：通过不同的 LLM 运行代码（例如，Claude 用于生成，专注于安全的模型用于审计）以捕获偏差。 工作流程和思维方式因你是独立开发还是在团队中工作（其他人维护你的代码）而大不相同。 ## **独立开发 vs. 团队：快速比较** ![独立开发 vs 团队代码审查](/images/articles/localized/04-engineering-practices/ai-writes-code-faster-your-job-is-to-prove-it-works/01.jpg) ## **独立开发者：以"推理速度"交付** **越来越多的独立开发者选择把审查重点放在关键路径上，再用测试体系兜底，以更快速度交付功能。** 这种工作流程把 Coding Agents 视为高效的执行者：它们可以在很大程度上独立处理大规模重构，而你把注意力放在关键节点的审查上。正如 [Peter Steinberger 承认的](https://blog.kilo.ai/p/senior-engineers-use-ai-now)：_"我不再读太多代码了。我看着流并有时查看关键部分，但大多数代码我不读。"_ 真正的瓶颈开始从“打字速度”转向[推理时间](https://steipete.me/posts/2025/shipping-at-inference-speed)——也就是等待 AI 生成结果。 **但这里有个前提：如果没有强测试体系，所谓的速度提升很快就会蒸发。** 先把安全网搭起来。如果你跳过审查，你并没有消灭工作量，只是把问题延后了。那些能高速使用 AI 的人，并不是盲目信它的人，而是那些先建立了验证系统、能在问题进生产前把它拦住的人。 这并不意味着独立开发者就会鲁莽行事。负责任的人会把**广泛的自动化测试**当作安全网——目标通常是较高覆盖率（比如 >70%），再配合 AI 生成那些能实时抓 bug 的测试。现代 Coding Agents 在设计复杂的端到端测试方面，往往出奇地好用。 **对于独立开发者来说，改变游戏规则的是与语言无关的、数据驱动的测试**。 如果全面，它们让代理可以用任何语言构建（或修复）实现，并在过程中进行验证。我用 AI 起草的 spec.md 开始项目，批准它，然后循环：编写 → 测试 → 修复。 至关重要的是，独立编码者仍然对最终产品进行**手动测试和批判性推理**。运行应用，点击 UI，自己使用功能。当涉及更高风险时，阅读更多代码并添加额外检查。尽管行动迅速，但当你看到丑陋的代码时就修复它，而不是让混乱积累。 即使在种种前沿范式中：[_你的工作是交付你已证明能工作的代码_](https://simonwillison.net/2025/Dec/18/code-proven-to-work/)_。_ ## **团队：AI 转移审查瓶颈** **在团队环境中，AI 是代码审查的强大助手，但*不能取代*质量、安全和可维护性所需的人类判断。** 当多个工程师协作时，错误的成本和代码寿命都会被放大。团队已经开始使用基于 AI 的审查机器人对 PR 做第一轮筛查，但最后仍需要人工签字。正如 [Graphite 的 Greg Foster](https://devclass.com/2025/03/19/graphite-debuts-diamond-ai-code-reviewer-insists-ai-will-never-replace-human-code-review/) 所说：_"我从来没有见过 AI 系统能替代真实工程师来签署 pull request。"_ **最大的实际问题不是 AI 审查者遗漏了风格问题——而是 AI 增加了数量并将负担转移到人类身上**。 [PR 变得更大](https://jellyfish.co/blog/ai-assisted-pull-requests-are-18-larger/)（随着 AI 采用的增加，增加了约 18%），[每个 PR 的事件增加了约 24%，变更失败率增加了约 30%](https://www.cortex.io/post/ai-is-making-engineering-faster-but-not-better-state-of-ai-benchmark-2026)。当输出增长速度快于验证能力时，审查就成为速率限制器。正如 Foster 所指出的：_"如果我们交付的代码从未被其他人类实际阅读或理解，我们就在冒巨大的风险。"_ 在团队中，AI 会产生大量输出，因此要强制执行渐进主义：将代理输出分解为可消化的提交。人工签字不会消失——它正在演变为专注于 AI 遗漏的内容，比如路线图对齐和 AI 无法掌握的机构上下文。 ### **安全：AI 的可预测弱点** **人工监督绝对不可协商的一个领域是安全**。 [大约 45% 的 AI 生成代码包含安全缺陷](https://www.veracode.com/blog/ai-generated-code-security-risks/)。[逻辑错误出现的频率是人工编写代码的 1.75 倍，XSS 漏洞出现的频率高 2.74 倍](https://dl.acm.org/doi/10.1145/3716848)。 除了代码问题，[代理工具和 AI 集成的 IDE 创造了新的攻击路径](https://www.tomshardware.com/tech-industry/cyber-security/researchers-uncover-critical-ai-ide-flaws-exposing-developers-to-data-theft-and-rce)——提示注入、数据泄露，甚至 RCE 漏洞。AI 扩大了攻击面，因此混合方法获胜：AI 标记，人类验证。 **规则：如果代码涉及身份验证、支付、密钥或不受信任输入，就必须在合并前增加人工威胁建模审查和安全工具检查。** ### **审查作为知识转移** **代码审查也是团队共享系统上下文的方式。如果 AI 编写代码而没有人能解释它，值班就会变得昂贵**。 当开发者提交他们不完全理解的 AI 生成代码时，他们正在破坏使团队具有弹性的知识转移机制。如果原作者无法解释代码为什么有效，值班工程师如何在凌晨 2 点调试它？ [OCaml 维护者拒绝 13,000 行 AI 生成的 PR](https://devclass.com/2025/11/27/ocaml-maintainers-reject-massive-ai-generated-pull-request/) 凸显了这个问题。代码不一定差，但没有人有足够带宽去审查如此巨大的变更；审查 AI 生成的大体量代码，往往反而更费力。教训是：**AI 可以用代码把你淹没，但团队必须主动控制变更规模，避免把瓶颈转移到审查环节。** ### **让 AI 审查工具发挥作用** 用户对 AI 审查工具的体验明显不一。积极的一面是，团队报告在某些情况下捕获了 95% 以上的 bug——空指针异常、缺少测试覆盖率、反模式。消极的一面是，一些开发者将 AI 审查评论视为"文本噪音"——没有增加价值的通用观察。 **教训：AI 审查工具需要周到的配置**。 调整敏感度级别，禁用无用的评论类型，并建立明确的选择加入/退出政策。正确配置后，[AI 审查者可以捕获 70-80% 的低垂果实](https://graphite.dev/guides/what-is-ai-code-review)，让人类专注于架构和业务逻辑。 许多团队鼓励**更小的、可堆叠的 pull request**，即使 AI 可以一次完成巨大的变更。[尽早并经常提交](https://medium.com/@addyosmani/my-llm-coding-workflow-going-into-2026-52fe1681325e)——将每个独立的变更视为单独的提交/PR，并附有清晰的消息。 重要的是，**团队必须守住人类责任的硬边界。** 无论 AI 贡献了多少，最终责任仍然在人。正如一句老话所说：_“计算机不能承担责任，承担责任的是处在回路中的人。”_ **无论是独立开发还是在团队中，新兴的最佳实践是[将 AI 生成的代码视为有用的草稿](https://addyo.substack.com/p/treat-ai-generated-code-as-a-draft)，*必须*进行验证。** 最成功的团队已经在一个简单的框架上达成一致： ### **PR 契约** 1. **什么/为什么**：用 1-2 句话说明意图。 2. **它能工作的证明**：测试通过，手动步骤（截图/日志）。 3. **风险 + AI 角色**：层级以及哪些部分是 AI 生成的（例如，高=支付）。 4. **审查重点**：1-2 个需要人工输入的领域（例如，架构）。 这不是官僚主义，而是对审查者时间的尊重，也是对作者责任的硬约束。如果你连这几项都说不清，就说明你还没有把这次变更理解到足以请求别人批准的程度。 ### **核心原则** **坚持“先证明，再声称”**。把“能工作的代码”作为最低标准。要求 AI 在生成后执行代码或运行单元测试，并附上日志、截图或结果。**没有新的测试或可验证演示的 PR，不应提交。** **将 AI 用作第一轮审查者，而不是最终仲裁者**。 将 AI 审查输出视为建议——一个对话，其中一个 AI 编写代码，另一个审查它，人类协调修复。将 AI 审查视为拼写检查，而不是编辑器。 **将人工审查集中在 AI 遗漏的内容上**。 变更是否引入了安全漏洞？它是否复制了现有代码（AI 的常见缺陷）？方法是否可维护？**AI 分类简单的东西；人类处理困难的东西**。 **强制执行增量开发**。 将工作分解为小块——AI 更容易生产，人类更容易审查。带有清晰消息的小提交作为检查点。**永远不要提交你无法解释的代码**。 **保持高测试标准**。 [那些从 Coding Agents 中获得最多收益的人](https://medium.com/@addyosmani/my-llm-coding-workflow-going-into-2026-52fe1681325e)有强大的测试实践。要求 AI 起草测试——它擅长生成你可能想不到的边缘情况测试。 ## **展望未来：瓶颈已经转移** **AI 正在将代码审查从逐行把关转变为更高级别的质量控制——但人类判断仍然是安全关键组件**。 我们看到的是工作流程的演变，而不是消除。代码审查现在涉及审查 AI 和作者之间的*对话*或*计划*，就像审查代码差异本身一样。人类审查者的角色变得更像编辑或架构师：专注于重要的事情，并信任自动化进行平凡的检查。 对于独立开发者来说，前方的道路令人兴奋——新工具将进一步简化开发。即便如此，明智的开发者也会"信任但验证"。 在大型团队中，预计对 AI 治理的重视会越来越多。公司将正式制定关于 AI 贡献的政策，要求签字确认代码已由员工审查。"AI 代码审计员"等角色将出现。企业平台将演变为提供更好的多存储库上下文和自定义策略执行。 **无论工具如何演进，核心原则都不变**：代码审查的职责仍然是确保软件满足要求，并且安全、健壮、可维护。AI 不会改变这些基本原则，只是改变了我们抵达这些目标的路径。 瓶颈已经从“写出代码”转向“证明代码有效”。AI 时代最好的审查者会接受这种变化：让 AI 加速机械工作，同时牢牢守住责任边界。正如越来越多工程师总结的那样，现代编码的关键词不是“感觉差不多”，而是[_“证明它能用”_](https://blog.kilo.ai/p/senior-engineers-use-ai-now)。 代码审查没有死，但它正在变得更加**战略性**。无论你是在凌晨 2 点部署的独立黑客，还是签署关键系统变更的团队负责人，一个真理都成立：*人类*最终对 AI 交付的内容负责。 拥抱 AI，但永远不要忘记**仔细检查工作**。 --- _我很高兴地分享，我与 O'Reilly 发布了一本新的 [AI 辅助工程书籍](https://beyond.addy.ie/)。如果感兴趣，书籍网站上有一些免费提示。_