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