当 AI 接管 70% 代码审查工作，剩下的 30% 才是 “地狱模式”

2024 年初，“Vibe Coding（氛围编程）” 一度成为开发者社区的热词。无论是初创公司验证商业模式，还是大型企业探索新业务场景，Vibe Coding 都以其 “快速验证想法” 的特性被广泛采用。只需一个简单的提示词（prompt），AI 就能生成数十行甚至上百行代码，这种 “即想即得” 的效率让开发者兴奋不已。

但狂欢之下，隐忧渐显。在大型企业的复杂项目中，Vibe Coding 的 “不可控性” 被无限放大：不同提示词生成的代码风格迥异、依赖关系混乱、与现有代码库兼容性差…… 这些问题导致大量代码停留在 “验证想法” 的阶段，难以跨越到生产环境。

据 Gartner 2024 年调研报告显示，超过 68% 的企业表示 “AI 生成的代码向生产环境迁移时，需要 50% 以上的重写工作量”。

这种 “从提示词到生产” 的断裂，正是亚马逊云科技研发 Kiro 的核心动因。亚马逊云科技观察到一个矛盾：企业既需要 AI 的高效来推进业务迭代，又需要代码的可控性来保障生产交付。传统的 AI 代码生成工具很多都是更侧重 “生成速度”和代码“产量”，往往忽视了软件工程的核心规范，而 Kiro 的出现，也在尝试改变这一状况。

Kiro 是一款独立的 IDE，它利用了 Anthropic 的 Claude Sonnet 4.0 和 3.7 模型，并计划根据用户需求支持更多模型。与专注于亚马逊云科技生态系统内代码级协助的 Amazon Q Developer 不同，Kiro 与云无关，无需亚马逊云科技账户。开发者可以通过 Google、GitHub 或亚马逊云科技 SSO 进行身份验证，从而使其可供更广泛的受众使用。

当 AI 开始大规模生成代码，整个行业都在思考：代码交付完成后，对于 AI 生成的代码该如何审查？目前业内的通常做法是什么？亚马逊云科技一位产品经理在与 InfoQ 的对话中提到，当前 AI 在代码审查中的应用还主要停留在基础层面，像代码规范、安全检查、性能优化等等，而对于更具挑战性的业务逻辑功能正确性审查，AI 尚无法胜任，仍需依靠人工。但他也坦言，目前行业内还没有很明确的数据来证实 AI 在代码审查这件事上能做到什么程度，有的只是不同企业的一些内部数据。

与此同时，随着众多 AI 辅助编程和代码工具融入 IDE，传统的代码审查方式是否会被改变？我们一直沿用的传统代码审查方法在这个时代是否仍然适用，又有哪些地方需要调整？带着这些行业共同关注的疑问，我们与这位产品经理展开了深度对话，试图从他们的实践与洞察中，探寻 AI 代码审查的现状、挑战与未来方向。

以下为对话访谈实录，InfoQ 做了不改变原意的编辑。

InfoQ： Kiro 官网上的那句“从原型到生产”，我们如何理解这句话？

亚马逊云科技：在 2 月份的时候，氛围编码（Vibe Coding）一度非常热门。Vibe Coding 在企业中被广泛使用，因为它能够快速验证想法。然而，这种代码的生成过程存在一定的不可控性。例如，您输入一个 prompt，它会生成一堆代码，再输入另一个提示，又会生成另一堆代码。这种方式虽然在制作原型时非常高效，但在实际的大型企业项目中，情况就有所不同了。这些项目往往已经积累了大量的代码，企业更希望 AI 能够精准地控制输出，并且能够真正投入到生产环境中，而不仅仅是停留在原型阶段。因此，现在对 AI 的要求已经越来越高了。 正是基于这样的需求，Kiro 融入了一种名为“规范驱动开发”的理念。

在 Kiro 中，您输入的不是直接生成代码的提示，而是先厘清需求。接着，Kiro 会生成技术设计和详细的执行计划。在这个过程中，人类开发者可以随时参与并进行纠正。只有在这些步骤都完成之后，才会开始编写代码。这种方式更接近于真正的软件工程。

传统的软件开发生命周期是用于交付产品的，我们的目标是打造一款能够真正实现产品级交付的集成开发环境（IDE）。通过这种方式，Kiro 不仅能够满足快速原型开发的需求，还能确保代码能够顺利地从原型阶段过渡到生产阶段，从而实现“从原型到生产”的完整流程。

AI 审查代码现在只是初级阶段

InfoQ：在整个代码交付完成后，对于 AI 生成的代码，我们是如何进行审查的？目前业内通常的做法是什么？而 Kiro 又是如何处理这一问题的呢？

亚马逊云科技：目前整个业界在代码审查方面普遍采用的是混合模式。也就是说，还没有完全依赖纯 AI 的审查方式。据我观察，绝大部分企业都已经开始采用 AI 进行代码审查，但主要是将 AI 作为初筛工具。对于一些核心环节，尤其是业务逻辑方面，仍然需要人工参与审查。我认为 AI 在代码风格评估、潜在漏洞检查等方面是比较适合的。目前来看，大部分企业都处于这种混合模式。当然，也有一些企业可能还没有开始使用 AI 进行代码审查。

InfoQ：目前 AI 在代码审查中的应用还主要停留在基础层面，例如语法错误和编译错误的检查。而对于更具挑战性的业务逻辑功能正确性审查，AI 还无法胜任，仍然需要依靠人工。对吗？

亚马逊云科技：是的，AI 在处理复杂问题方面仍有局限性，目前主要还是在语法、代码规范、安全漏洞、代码复杂度优化等方面表现较好。

InfoQ：那大概 AI 能完成多少审核工作，人工又能完成多少审核工作，两者之间的比例是怎样的？还有哪些是 AI 做不到、需要人来完成的？

亚马逊云科技：这个我只能分享我们所听到的一些数据。就拿我们接触过的一些团队来说，无论是亚马逊内部的还是外部的，我们听到的情况是，他们引入了一些 AI 审查工具之后，AI 可能会提出 10 个建议，其中大概有 7 个是人类可以接受的，可能还有 3 个是人类觉得没必要改的。目前我还没有看到一个业界非常精准的大规模统计，这可能还没有。

InfoQ：就是说其实还没有很明确的数据来证实 AI 在代码审查这件事上能做到什么程度。那现在有很多 AI 辅助编程和代码工具的 IDE，它们会不会改变我们传统的代码审查方式呢？我们传统的代码审查方法在这个时代是否仍然适用？有没有需要调整的地方？

亚马逊云科技：我觉得肯定有部分是适用的。就像刚才提到的业务逻辑部分，尤其是我们现在做的很多软件是微服务架构的。如果仅靠 AI，在当前的仓库中，比如你修改了 API，其他依赖它的服务可能无法被 AI 审查，除非额外给它注入知识。这种情况下，恐怕还是需要依赖人类。不过，已经有非常多的部分是 AI 能够完成的了。所以，我认为传统的方法依然有适用的部分。我觉得人类在审查上的重点已经从原来的代码规范错误、语法错误转向了业务逻辑错误，从原来的风格审查——比如每个团队都有自己写代码的风格——转向了架构设计的审查。我觉得审查的重点是有变化的。

借助 AI 工具，项目经理“秒变”总架构师

InfoQ：AI 已经能够替代一些基础性的工作了。那么现在有这么多代码工具，它们真正的核心底层能力到底是什么？它们的产品与别家的区别在哪里？比如我们的 Kiro，它与其他产品的本质区别是什么？它的核心竞争力又是什么呢？

亚马逊云科技：各家的产品都有各自的特点，我认为 Kiro 最大的特点是生产级别的工程质量。使用 Kiro 的 Spec 模式进行新特性开发的时候，会发现 Kiro 生成的代码工程质量更高。有些开发者，使用相同的项目，相同的提示词比较过 Kiro 和其他产品生成的代码，他们告诉我们，它生成的代码模块化更好，错误处理、单元测试更完整，代码更易读、易维护。这样的工程质量对于后续的人类审核也更容易一些。当然开发者也反馈，Kiro 的 Spec 需要等待得更久一些，惊喜感来得晚一些。

InfoQ：尽管 AI 代码审查工具已经可以做很多常规工作，但相信它还是有一定的瓶颈的。您目前观察到的这类 AI 代码审查工具还有哪些瓶颈？对于这些问题，有没有什么应对措施？ Kiro 是怎么做的？

亚马逊云科技：我觉得 AI 审查工具目前面临的最大问题并不是工具本身的能力不足，而是在进行代码审查时，依赖开发者的知识。然而，很多开发团队在协作过程中，知识并没有有效地沉淀下来，AI 也就无法获取这些信息。这是我们与企业和开发者交流时发现的最突出的问题。

因此，未来一定会出现一种趋势，那就是我们需要在知识准备上下更大功夫，比如在代码生成之前，做好更完善的设计，更清晰地撰写需求文档，以及更细致地进行任务分解。这也是为什么像 Kiro 这样的 AI 代码工具会推出规范驱动开发这样的理念，它就是为了让知识准备做得更好，从而为后续流程带来便利。我们可以期待，当知识都沉淀下来之后，AI 代码审核工具可以有效地利用这些知识，帮我们审核高阶的业务逻辑错误。

我还观察到另一个趋势：过去，代码审查大多是在 CI/CD 环节进行的，比如开发者写完代码后，提交给同事进行审查，这是常见的做法。但现在，很多团队开始引入本地审查，即开发者在本地利用 AI 工具先进行扫描，然后再提交入库。在 Kiro 里，我们引入了 Agent Hooks 的概念，这是一种通过监听 IDE 事件来自动触发工作流的机制。一个常见的用法就是，当开发者保存代码文件的时候，自动通过 Agent 来完成本地代码审查，保证团队代码质量的一致性。

AI 生成代码带来的风险，目前无法完全避免

InfoQ：我们之前了解到，一些调查认为 AI 生成的代码可能比人类编写的代码更安全。但另一方面，AI 代码审查工具虽然能够帮助发现漏洞，却也可能引入一些风险。它既有优势，也有劣势。那么，我们应该如何利用它的优势，同时规避它带来的风险呢？

亚马逊云科技：AI 生成的代码确实有可能带来不安全的代码，这是目前无法完全避免的。因此，业界的常见做法是在代码生成之后加入安全审核环节。目前，已经有一些专业的工具可以用于这一目的。例如，像 SonarQube 这样在业界非常知名的工具，以及一些创业公司开发的工具，比如 Qodo，它们都专注于解决这一问题。其实，代码安全问题在 AI 出现之前就已经存在了，人类编写的代码也可能产生不安全的问题，这一领域已经发展了相当长的时间。

InfoQ：现在 AI 生成的代码量很大，但审查速度可能跟不上代码生成的速度。是否应该调整代码审查的方式，比如采用更小的 PR，或者引入新的代码审查工具和流程，以适应 AI 代码生成的特点？因为如果审查速度跟不上，工具的效率可能就无法充分发挥。是这样吗？

亚马逊云科技：确实如此。首先，我建议在生成代码时尽量拆分为较小的粒度，不要一次性生成过多代码，比如 1 万行代码。无论是 AI 审核还是后续的人类审核，处理如此大量的代码都会比较吃力，尤其是人类审核者可能会成为瓶颈。

最好是将 PR 限制在较小的功能范围内，尽量减少变更的范围，这样人类审核者会更轻松一些。 其次，现在很多工具已经具备了将需求拆分成更小单元的能力。

例如，Kiro 可以将一个完整的需求拆分成多个小单元，然后针对每个小单元生成代码。过去，我们通常是在完成一个完整功能后才提交代码，但现在 AI 工具可以帮助我们将任务拆分得更细，完成一个小单元后就可以提交代码进行审核。

第三，我认为未来的开发范式也会发生变化。以 Kiro 为例，它有一个非常实用的功能叫 Agent Hooks，它可以自动捕获 IDE 中的事件。例如，当你编写完一段 Java 代码并保存时，Agent Hooks 可以自动触发预置的代码审核 Agent，在后台运行并提出修改建议。这种功能可能会改变我们的开发习惯，将审核过程融入到开发过程中。

InfoQ：现在有一些 AI 代码审查工具采用了分层审查的逻辑，先让 AI 进行初步自检，然后再交给人类审查，通常是先由初级工程师审查，再由资深工程师审查。您怎么看这种流程？

亚马逊云科技：在没有 AI 的时候，人类就已经采用类似的分层审查方式了。过去没有 AI 自检时，通常是初级程序员先审查，资深程序员再审查，对于初级程序员来讲这是一个学习的过程。这种做法比较通用。

现在我觉得可以降低人类审查的频率。以前我们开发先拉一个代码分支，在这个分支上提交代码，每次提交都由人类审核。有了 AI 审核之后，我认为可以在分支级别做代码合并的时候再由人类介入审查，控制好分支的大小不要过大。这是一种工作方式的变化。

其次，我观察到一些趋势：在开发项目过程中，规范会不断变化，这是非常常见的。我也看到一些企业会将新的规范总结出来后，用 AI 扫描存量代码。这与传统的代码合并流程不同，它是对整个代码库进行定期扫描，并在系统中直接发起类似于代码合并的操作。这样可以保持整个代码库的质量在较高水平，而这是过去人类很难做到的，因为让人类去审核整个代码库是非常困难的。但现在有了 AI。

InfoQ：这有点像解决以前留下的技术债问题，对吧？

亚马逊云科技：是的，代码风格和规范会随着时间推移发生变化。批量审核在过去不太可行，费时费力，也没人愿意做。但现在 AI 可以快速且系统化地完成这项工作。

InfoQ：那目前这项技术是不是已经比较成熟了？技术债问题一直是让人头疼的难题，AI 现在能解决大部分了吗？

亚马逊云科技：是的，我觉得可以解决大部分问题。

InfoQ：有没有一些具体的案例呢？

亚马逊云科技：是这样的，客户会自定义代码审查规范。他们会隔一段时间用这个规范扫描整个代码仓库。扫描时并不是一次性扫描整个仓库，因为上下文信息可能不够，而是按照小模块进行扫描，让 AI agent 自己去获取上下文。扫描完成后，它会在后台运行，然后以代码合并的方式在系统中发起建议，并分配给程序员，让他们选择是否接受。大致流程就是这样。

InfoQ：也就是说，一旦接受了这样的代码合并，那么以前代码库中留存的代码就会变得更好，更易于管理，对吧？

亚马逊云科技：应该是这样的。比如新的命名规范需要强制修改，或者公司政策上有要求，AI 基本上都可以完成这些任务。

未来会增加哪些功能？

InfoQ：关于 AI 代码审查工具，您认为未来应该增加哪些功能，才能更好地帮助团队减轻负担呢？

亚马逊云科技：我个人觉得目前 AI 审查工具的一个普遍缺陷是比较依赖人类提前写好审核规则。目前我看到的工具大多都存在这个问题。但我们期望的是，比如 AI 给出 10 条建议，我们可能只接受 7 条，剩下的 3 条没有接受。我们希望 AI 能够学习人类的偏好，因为有时候 AI 检测出一些低优先级的建议，人类可能不会采纳。如果 AI 能学习我们的行为习惯，并且有一个反馈机制，那它就能更好地匹配我们的需求。

InfoQ：您提到的提前写好规则，这个规则是否也可以利用 AI 来生成初版呢？

亚马逊云科技：可以让 AI 生成一个初版规则。比如让 AI 学习当前代码，然后生成规则，但通常情况下，生成的规则肯定会遗漏一些内容。这是第一个问题。第二个问题是，随着项目的推进，规则会不断变化，需要审核的内容也会不断变化。所以，我们希望未来的 AI 工具能够增量学习。

InfoQ：您提到让代码审查工具具备理解人类偏好能力，这是否需要底层大模型做出改变呢？

亚马逊云科技：我不认为需要底层大模型做出改变。而是要把这些知识记录下来。目前一些工具，比如开源项目，通常是与 CI/CD 结合的，比如在 GitHub 上提交代码审核时，它可以在代码合并评论部分留下一些评论，但人类是否采纳了这些建议，它并没有记录下来，规则也不会动态变化。我认为有一些技术上是可以实现的。

比如 AI 给出建议后，人类根据建议修改代码，然后更新代码合并。其实，通过比较第一次提交和第二次提交的差异，AI 可以学习这些差异，并将其内化为工具的知识库的一部分。

未来，当调用 AI Agent 进行审核时，可以从知识库中提取这些知识。

InfoQ：您觉得目前有哪些团队已经在尝试 AI 与人类协作的模式？您有没有一些案例可以分享？他们的经验教训是什么？

亚马逊云科技：亚马逊本身已经在大量尝试这种模式了。首先，亚马逊的研发团队采用 AI 审核已经有一段时间了。他们的做法是在代码合并流程中加入一个 Agent。我们内部有一个 Git 仓库，可以配置这样一个 Agent。它的模式是，你可以在自己的仓库里维护代码审核规则，同时它也有默认规则。根据普遍反馈，默认规则生成的内容只能满足基本需求，所以一定需要额外的规则来满足项目自定义的审核要求。他们分享给我们的数据显示，准确率大概在 70% 左右，所以他们还是比较满意的。我们的经验教训是什么呢？审核依赖于你对审核条件的更新。千万不要生成规则后就永远不管它，而应该随着项目的变化不断更新审核要求。我认为这应该成为团队的一个机制，将其纳入每个项目的回顾环节。

InfoQ：您对未来代码审查流程的演变有什么看法？您觉得未来几年代码审查流程会有哪些变化？是否会实现完全自动化？还是说在未来至少 3 到 5 年里，仍然以人工审查为主，尤其是比较复杂的业务逻辑审查？

亚马逊云科技：我觉得先不说 3 到 5 年，先看 1 到 2 年。目前我看到的范围内，AI 审查可能处于 2023 年 AI 代码生成的阶段，大家还都在刚开始尝试，没有大量应用，但我认为接下来会大量应用。所以，未来一到两年内，大家一定会朝着这个方向转变。至于能否实现完全自动化，我个人觉得不太现实。完全自主、完全没有人类参与，可能存在难度。尤其是对于一些比较复杂的业务逻辑和比较严谨的系统，比如金融类系统，我觉得不太可能完全自动化。技术上或许有可能，但制度上可能也跟不上。就像自动驾驶一样，即使技术很好，但依然需要人类掌控方向盘。

第二，我认为开发者的技能会发生较大变化。以前我们审核代码时，主要关注规范、语法错误、风格和可能的性能提升，这些现在 AI 都可以替代。但以前我们审核时可能不会关注引入新代码后对架构的影响。现在，人们需要关注这些内容，关注点发生了变化。也就是说，这对工程师的能力提出了更高要求。目前，工程师可能把 70% 的时间花在写代码上，30% 的时间花在审查上。未来，这个比例可能会倒过来，甚至可能完全不写代码，只有审查工作。

InfoQ：这种情况其实之前也采访过一些专家，他们也提到过。那作为一名开发者或工程师，尤其是初级工程师，可能被替代的可能性比较大。那怎么提升自己的能力，不被这样的潮流淘汰呢？

亚马逊云科技：我觉得第一是要不断学习复杂的项目。第二是调整关注点。第三是要熟练掌握各种 AI 工具。你要清楚 Agent 的边界，它能做什么，不能做什么，你要在它不擅长的地方努力。也就是说，要提升自身除了编程能力以外的其他能力，比如更偏主观性的东西，以及理解业务的能力。