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