AI编程时代：代码审查员的核心价值与实操框架

随着 AI Agent 能够以比任何人类开发者都更快的速度编写代码，并且我们通过一次提示就能获得成百上千行代码，仔细进行代码审查的需求比以往任何时候都更加迫切。代码审查仍然是确保代码遵循工程规范、架构原则，同时保证长期可维护性和可扩展性的主要机制。

在我之前关于 vibe coding 陷阱和幻觉的文章中，我分享了关于认知负荷如何从代码生成转移到代码审查的观点，以及为什么我认为这个话题应该吸引越来越多的开发者关注。在这篇文章中，我描述了在一年多积极使用编码 Agent 之后，我是如何看待代码审查方法的。

作者主动进行代码审查

在请求同行审查之前，作者应该像审查他人代码一样对生成的代码进行主动审查。在 AI 出现之前，开发者通常理解每一行代码，因为他们积极参与了代码编写。如今，开发者往往是在指导实现，而不是亲自编写每一个细节。鉴于此，进行明确的自我审查变得尤为重要，以确保 Agent 生成的内容符合预期。

这可以被理解为合乎逻辑的一步，但由于 Agent 正在编写全面的实现，而且生成代码的语法看起来非常有说服力，因此很容易相信 Agent 输出的所有内容都是正确的，而不够关注细节。首先需要检查的是生成的代码是否与产品中的架构原则一致，以及代码是在解决正确的问题还是在发明新问题。

另一个步骤是尝试用尽可能少的代码完成相同的功能。由于 LLM 默认生成的代码往往更多，有时比应有的更复杂，我们需要检查是否所有这些代码都是必要的。在大多数情况下，代码可以简化，我们应该尽可能地坚持简化。当然，一开始你会处于需要来回提示才能得到预期输出的情况，但这也是一个学习如何引导 Agent 适应你需求的过程。

在这个过程中，你会发现一些适合你工作流的模式，这样你就可以为 Agent 定义技能。通过这种方式，下次你需要执行一些重复性任务时，你已经有了预定义的输入。技能和规则都可以用来简化代码生成过程。但是，技能和规则都不能消除仔细代码审查的必要性。毕竟，作者仍然对提交的每一行代码负责。

一旦开发者准备好打开 Pull Request，另一个步骤通常会作为 CI 流水线的一部分自动执行。在这里，AI Agent 会对发布的代码进行自动审查，能够发现一些非常有趣的边界情况、潜在的安全风险或缺失的空值检查。同时，它仍然缺乏项目的完整业务和历史背景。它可能会推荐一些技术上合理但不适合产品或现有架构的更改。

在这里，开发者再次应该密切关注自动审查者的反馈，检查审查是否有意义以及是否值得实施。同样，我们可以期待大量的建议，这取决于 Pull Request 的大小。大型 AI 生成的 Pull Request 通常会触发大量自动审查评论。这也是尽可能保持更改小而集中的另一个原因，以便能够仔细审查它们。

如果之前的所有步骤都正确执行，那么这个阶段不应该花费太多时间，因为大部分信心应该已经来自作者自己的审查和自动审查。这个阶段基本上与 AI 之前的传统代码审查相似。关于这方面的深入见解可以在我之前关于代码审查的文章中找到，如果你还没有看过，现在可能是阅读的好时机。

但是，如果之前的一些步骤做得不好，特别是第一步，那么代码审查者就处于一个不太令人感激的位置，因为代码质量的所有责任现在都转移到了他身上。首先，这里的问题是提出 Pull Request 的开发者可能不理解他所编写的代码，这后来在遇到意外异常或维护时会产生更多问题。作者的名字附在提交记录上，但他们无法自信地解释为什么某些部分的实现存在或它们如何工作。

回顾过去几年整个 AI 运动，如果处理不当，我注意到一个令人担忧的现象。团队以前所未有的速度生成代码，但与此同时，高级工程师越来越将时间花在审查和验证 AI 生成的更改上，而不是自己编写新的实现。在这种情况下，AI 加速了代码生成，但不一定加速了软件交付。

要点与结论

AI 无疑改变了工程工作力的投入方向。编写代码正在变得越来越自动化，但理解、验证和维护同样的代码仍然是人类的责任。那些认识到这一转变并相应调整审查流程的团队，可以比那些只关注更快生成代码的团队从 AI 中获益更多。随着时间的推移，如果不加以注意，那段代码将变得难以维护，甚至可能变得不可能维护。

我学到的最重要的一课是让每个 Pull Request 的代码量尽可能少，因为这样开发者更容易审查，同行也更容易查看。大型 Pull Request 对作者和审查者都没有帮助。它们只会增加不确定性，降低对交付产品的信心。