AI 能写代码，谁来验证：AI 编码时代的自动化验证实践

AI 编码智能体时代的自动化软件验证

我们正处于 AI 的巅峰时期，越来越多开发者在没有亲自编写（甚至有时也没有亲自审查）代码的情况下就直接交付代码。根据Faros 于 2026 年开展的一项研究，该研究分析了 4,000 个团队中 22,000 名开发者长达两年的遥测数据，在 AI 采用率较高的组织中，工程吞吐量正在增长，而缺陷、返工、审查负担以及生产事故的增长速度则更快。

数据十分惊人：Faros 报告称每位开发者的缺陷增加了 54%，PR 的中位审查时间增加了大约五倍，每个 PR 的事故数量是之前的三倍多，比较的是 AI 采用率较低和较高的两个时期。这些是相关性，并不能证明 AI 是造成所有这些结果的原因。随后发布的 Q3 报告也发现，一些早期的影响正在减弱，而验证、修复和运营成本却在下游持续累积。

我们需要放慢脚步，去理解并改进我们正在做的事情。不能指望一个小团队去认真审查海量的 AI 生成差异。在 AI 如今输出代码的速度下，即便是普通的审查流程也难以跟上。

那么，我们如何在不牺牲软件质量、可靠性和可维护性的前提下，保持 AI 辅助开发的速度？

答案很简单：自动化软件验证。借助我们作为 AI 工程师用来以惊人速度输出代码的那些巧妙工具、技能和框架，我们也能构建出精密的测试与验证自动化。

构建能够带来有充分依据的信任与信心的自动化软件验证，才是前进的方向。这并不是因为任何系统都能保证无缺陷软件，而是因为我们需要更多的方法，在问题抵达用户之前就发现它们。

目前有哪些可用的方案？

目前有几种相关的概念正在流传。

Superpowers

其中一个已经流行起来的概念是Superpowers，它是一套与编码智能体及受支持的框架配合使用的智能体开发方法论与技能集合。它鼓励你的智能体表现得更像一名纪律严明的软件工程师，而不是立刻就动手写代码。

例如，它有助于厘清究竟要构建什么，而不是凭空假设。它强调规划、测试驱动开发、调试和评审，包括让独立的智能体来审查工作成果。

这是一个很好的开始。但是，根据任务的不同，遵循整套方法论可能会拖慢开发速度，而且它仍然无法取代为代码的正确性与安全性建立信心所需的更广泛的检查。没有任何单一的插件能让软件无缺陷或无漏洞。

RoboRev

另一个有趣的框架是RoboRev，它来自广受欢迎的 pandas 库的开发者 Wes McKinney。RoboRev 将持续进行的 AI 代码审查引入到了本地开发循环中。

这个想法很有吸引力：就像面对面的同行评审一样，我们可以让另一个 LLM 来审查我们的第一个 LLM 所写的代码。让一个独立、且可能使用不同模型的审查者来检查，或许能发现写作智能体遗漏的错误或架构问题。这提供了另一种视角，但并不能保证审查就是公正或正确的。

在典型的 RoboRev 设置中，你提交代码后，本地守护进程会使用配置好的编程代理自动审查提交。它会浮现出审查结果，你可以将其反馈给当前的 LLM 和编程工具，在上下文还新鲜时修复问题。

RoboRev 还支持跟进式审查工作流和针对性审查任务。其魅力在于，验证成为编码流程的一部分，而不是你最后才想起来要做的事情。它的文档介绍了可用的命令和集成。

但代码审查这个概念并不新鲜。2026 年，Claude、Codex、GitHub Copilot、Cursor、Greptile、CodeRabbit 和 Qodo 等服务商都提供 AI 辅助代码审查。

全部解释一遍即便是最沉迷于网络的工程师也会睡着，所以我们只聚焦于几个主要的。

Claude Code Review

Anthropic 的托管式 Code Review是一款重量级的 PR 审查器。当在 GitHub pull request 上触发时，它会并行派出多个专门代理来调查变更，寻找逻辑错误、安全漏洞、回归问题以及遗漏的边界情况等。

其目标是更深入的审查，耗时和成本都可能比快速本地审查更高。截至 2026 年 10 月，Anthropic 将此托管服务列为 Team 和 Enterprise 计划的研究预览版，采用独立的按使用量计费方式。

还有一个由 Anthropic 维护的、用于 Claude Code 的/code-review 插件。它可以从你的编码工作流中运行审查，并将结果发布到 PR。这与托管式审查服务是不同的工作流，所以在深度、设置或定价方面，我并不把它们视为完全相同。在假设审查已包含之前，请检查你的计划和使用条款。

OpenAI Codex Review

Codex code review 采用了类似的方法，根据仓库的上下文和说明审查 pull request。你可以在已连接的 GitHub PR 上用 @codex review 请求审查，或配置自动审查。Codex 还支持在 PR 创建前审查本地变更。

你可以更详细地描述你想要检查的内容：diff、PR、安全问题或是否符合规范。如果审查发现问题，你可以要求 Codex 准备修复方案，检查产生的变更，然后重新审查。这提供了一个有用的审查-修复循环，不过审查和实现仍需要独立验证。

GitHub Copilot Code Review

GitHub 的方法是最简单、最省心的之一。你可以配置Copilot Code Review自动审查 PR，遵循仓库说明，并提出可应用或传递给 Copilot 编程代理的修复建议。

尽管它很顺畅，但如果你盲目接受它的反馈，就会引发问题。Copilot 通常会留下评论而不是批准的审查，不过 GitHub 在某些设置中支持配置批准。无论如何，自动审查并不等同于安全的合并决策。

一个权衡是，审查体验比 DIY 代理工作流更受管控：你可以自定义其说明，但无法像调用自己的编程代理那样直接进行每次运行的模型配置。

Cursor Bugbot

Cursor Bugbot 会自动审查 GitHub PR，寻找逻辑错误和其他问题，并允许你在 Cursor 中根据这些发现采取行动。它的Autofix 功能还可以通过云端代理提出修复建议。

它最大的优势是对已经在使用 Cursor 的团队而言非常便捷。代价是模型选择和评审编排的大部分工作由 Cursor 处理，而不是以完全可定制的工作流形式开放出来。Cursor 表示它结合使用了前沿模型和自研模型。

只靠一个评审者是不够的

我喜欢让一个强大的编码模型来写代码，再让另一个独立的强模型来评审它。不同模型可以带来不同的视角，但模型多样性并非灵丹妙药：两个智能体可能对同一个错误答案达成一致，可能忽略同一个需求，也可能信心十足地标记出一个根本并不存在的 bug。

务实的结论是，把 AI 评审与不依赖 LLM 判断的检查结合起来。理想情况下，还要让人类对最终决策负责，尤其是在高风险变更上。

好的，代码评审我们聊过了。但要让我们更有信心地相信代码符合规范、不引入 bug 或漏洞、不会意外泄露密钥，我们还有更多事情可做。

接下来我们就来谈这些内容。

AI 与自动化软件开发时代的 CI/CD 流水线

这里给出了一套全面的验证流水线，它以现有能力为超集构建。每一个步骤都可以增加我们对代码按预期工作的信心，但并非所有团队都需要每一项检查，同时也没有哪一组检查能够证明软件是完美的。这种更宏观的理念在软件工程中早已成熟，并与诸如 NIST 的安全软件开发框架之类的框架相契合。

不喜欢大段文字？本节末尾有整条流水线的示意图。

代码质量与构建检查

代码风格检查（Linter）：检查代码是否存在风格违规和常见错误。
格式化检查：确保缩进、空格等格式符合我们的规范。
类型检查：如果使用的是 TypeScript 这样的强类型语言，验证类型是否使用正确。
编译/构建检查：确保应用能够成功编译或构建。

自动化测试

单元测试：测试各个功能单元是否按预期工作。
集成测试：测试多个组件能否协同工作，例如涉及 API、数据库和支付服务商的支付流程。
端到端（E2E）测试：从头到尾地验证整个应用中重要的用户工作流。

安全与依赖检查

静态应用安全测试（SAST）：扫描源代码中与潜在安全漏洞相关的模式。
密钥扫描：查找代码仓库中意外包含的密码、密钥或敏感凭证。
依赖项漏洞扫描：查找包依赖中已知的漏洞。
依赖项新鲜度与支持状态：识别可能需要关注的过时或已停止支持的包。

智能体代码评审

通用 bug 扫描：借助 AI 智能体查找并标记可能的 bug。
安全导向的评审：借助 AI 智能体调查基于规则的扫描器可能抓不到的潜在安全风险。
对照规范的评审：检查最新的 PR 或特性分支是否实现了所要求的行为，包括重要的边界场景。

基础设施与数据库检查

容器与基础设施配置扫描：查找容器与云基础设施中的不安全设置或配置错误。
数据库迁移验证：评估架构变更是否可以安全部署，是否可能导致数据丢失或停机，或使回滚变得困难。

架构 & 可维护性审查

臃肿、复杂性与架构简化检查：利用 AI 智能体识别不必要的代码、过度工程化、过度的复杂性以及简化的机会。

其他值得记住的检查

根据应用程序的需要，可加入性能与负载测试、可访问性检查、隐私与合规检查，以及软件许可证 / 供应链检查。一次安全的部署仍可能运行缓慢、难以访问，或错误地处理数据。这些检查不必在每次提交时运行，但应在整个流程中占有一席之地。

综合来看，我们应如何配置这些检查？

我们讨论过的大多数验证模式已是数十年来形成的成熟实践，主要平台也早已提供工具将其自动化。GitHub Actions、GitLab CI/CD 和 Jenkins 是常用的编排方式。

以 GitHub Actions 为例。开发者在仓库内的 YAML 文件中定义自动化工作流。这些工作流可由推送代码、发起拉取请求或合并变更来触发。随后 GitHub 启动执行环境（一个 runner，运行器）并执行工作流的各个步骤。

这些步骤通常包括安装依赖，并运行确定性检查，如代码检查工具、测试和安全扫描器。它们越来越多地也可以调用 AI 智能体进行更复杂、不确定的审查。参见 GitHub Actions 文档以及官方的 Codex GitHub Action。

简化后的工作流可能如下所示，见 .github/workflows/verification.yml：

name: Code Verification

on:
  pull_request:

permissions:
  contents: read

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: ./ci/quality.sh

  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: ./ci/tests.sh

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: ./ci/security.sh

  infrastructure:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: ./ci/infrastructure.sh

  agent-review:
    # This example skips external forks and Dependabot-triggered runs;
    # bot reviews need separate setup.
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
          persist-credentials: false

      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          permission-profile: ':read-only'
          prompt: |
            Review the changes in this PR relative to
            base commit ${{ github.event.pull_request.base.sha }}.
            Use git diff to inspect the changes.

            Check for:
            1. Logic bugs and missed edge cases
            2. Security vulnerabilities
            3. Compliance with the project specification
            4. Unnecessary complexity or overengineering

            Report actionable findings with file paths
            and line numbers. Do not modify files.

这是一个示意性的工作流，并非可直接套用的 CI 配置。其中的 ./ci/*.sh 脚本只是占位符，代替你将在仓库中编写的脚本。智能体任务会执行审查，但不会自动把结果发布回 PR；这需要额外的报告步骤。在真实项目中，还应将第三方 Action 固定到可信的提交 SHA，限制权限，并仔细将代码与不可信的贡献者以及可访问 API 密钥的工作流隔离开。GitHub 和 OpenAI 都发布了安全 PR 工作流指南和 Codex Action 安全指南。

请注意，使用智能体审查时，你可以在 GitHub Actions 中配置自己的 LLM 提供商与凭据。官方 Codex Action 使用 OpenAI API 密钥；若使用其他提供商，则需要该提供商对应的集成。

然而，对每个 PR 都运行完整流水线可能会很昂贵，特别是对实行持续集成且每天有大量 PR 的团队而言。一些检查和智能体审查耗时按分钟计而非秒计，AI 调用的成本也会不断累积。

更快捷、更方便的做法是先运行廉价的检查，将较重的检查留给后续阶段或高风险变更。

此时，提交前、提交后/推送后、拉取请求、预生产和生产阶段就派上用场了。

理想情况下，在成熟的测试工作流中，我们会按阶段和变更的风险等级对检查进行分类。

还是不想看文字？本节末尾还有另一张图在等着你。

提交前

这是代码在本地提交之前的阶段。

此阶段应进行的工作：格式化、代码检查、类型检查、有针对性的单元测试、在足够快时的构建检查，以及密钥扫描。其中一些可以通过 Git 钩子运行；其他的可以直接在你的编辑器或编码智能体工具链中运行。

提交后 / 推送

这是代码已提交并推送到远程仓库之后的阶段。

此阶段应进行的工作：更广泛的单元测试和集成测试、SAST，以及依赖项漏洞扫描。本地的提交后审查工具也可以在每次提交后提供快速反馈。

拉取请求（PR）

这是对提议的更改进行审查和验证，然后再合并到主分支的地方。

此阶段应进行的工作：相关的自动化测试、智能体缺陷扫描、智能体安全审查、规范合规性审查，以及架构/复杂度评估。更全面的检查应保留给高风险的更改。使用仓库规则集要求关键检查在合并前通过。

预生产 / 部署

这是代码在发布到生产环境之前进行验证的地方。

此阶段应进行的工作：在适当的情况下进行完整的集成测试和 E2E 测试、基础设施配置扫描、数据库迁移验证、部署冒烟测试，以及最终的安全检查。对于有风险的发布，考虑使用预发布或金丝雀部署，以及经过测试的回滚计划。

生产 / 部署后

这是代码已部署并在生产环境中运行之后的阶段。

此阶段应进行的工作：应用健康检查、错误监控、性能监控、安全监控、冒烟测试、异常检测，以及在安全的情况下进行自动回滚。

大型科技公司如何运行 AI 软件工厂

一些大型企业多年来一直在摸索这一主题，因为他们既有能力胜任的人才，又有充足的资金来最大化 token 消耗。正如 Adam Faik 在如何构建 AI 原生软件工厂中所阐述的，Uber、Shopify、DoorDash、Spotify 和 Stripe 都让我们得以一窥在这个不断演进的软件工厂生命周期中，当前的技术水平在哪里。

简而言之，团队通常会有一个网关或前门来路由他们的请求，这些请求通过适当的权限和治理进行资格验证，然后被推入一个高度自动化的流水线。该流水线可以访问代码、公司上下文和所需的内部工具，以研究请求、确定规范、提出方案、构建产品、测试产品，并提供相应的证明。差异、截图、测试、自动化审查以及大量的分析数据，然后在代码真正合并或推送到生产之前由开发人员进行审查。

换句话说，开发人员越来越专注于提出需要解决的问题，对如何解决提供一些意见，并让智能体工作流处理大部分的实施和验证工作。完成后，开发人员在 PR 合并或生产推送之前充当名义上的审查者和最终的把关者。当然，自主程度因公司而异，人类仍然会在沿途的重要决策中参与其中。

这个过程还有更多内容,特别是关于安全、隔离环境、验证和成本方面,以及许多我略去的细节,但我想Adam 的文章对于任何对这些 AI 软件工厂如何配置和大规模运行方式感兴趣的人来说,都值得一读。

我使用的实用智能体软件开发工作流

所以,对于读到这里的读者,请允许我通过一个 PR 来把这个案例讲清楚。

本节末尾附有一张汇总我整个流程的示意图。

假设我有一个新的需求:为我的应用创建一个个人资料页面,让用户可以查看和更新自己的资料。

使用一个强大的编程模型(在我的设置中通常是 Claude),我会尽可能详细地说明这个个人资料页面应该做什么以及长什么样。

我的智能体工作流会返回一份规格说明。我们来回沟通几次,我仔细审阅,然后不断更新直到满意。接着我会让智能体制定一份实施计划,将其分解成有策略性、实用且顺序合理的步骤,这些步骤在逻辑上可以划分为若干次提交。

我还会让它把这份计划交给另一个顶级模型(例如 Codex)过一遍,看看是否有遗漏或可以改进的地方。最终的计划会包含我们打算构建的单元测试、集成测试和端到端测试。

我审阅这份计划,必要时进行迭代,然后批准。

到了这一步,我的主编程智能体会按步骤或按提交开始执行计划。每完成一步,它会让另一个强大的模型来审阅这些变更。

如果这次变更影响重大,例如涉及支付或敏感的生产流程,我也会在此期间逐一审阅每次提交。否则,我可能等到整个功能完成后再进行深入的人工审查。

一旦编程智能体收到改进建议——无论是来自第二个 LLM 还是来自我——它就会采纳这些变更并进入下一步。

这个过程按提交依次进行,涉及前端、后端或任何其他必要代码的修改。在此期间,智能体会酌情运行单元测试、集成测试和端到端测试。对于我构建和维护的软件来说,这些测试中的许多都相对便宜且运行迅速。如果有失败的,它会被标记出来,我们再进行修正。

最后,当我们到达最后一次提交时,我会让另一个模型根据原始规格来审查整个变更——所有提交和所有差异——并标记出任何遗漏之处。如果有标记出的问题,我们会调查并修复。否则,就进入下一阶段。

现在我们来到了 PR 阶段。我们已经根据规格实现、审查并反复审查了代码,并在此过程中运行了测试以确保一切仍然正常。

然后我会亲自审查完整的差异,给予与变更重要性相称的关注。变更越重要,审查就越仔细。我还会运行其他自动化检查:SAST、依赖扫描、智能体漏洞审查和智能体安全审查。其中一些使用 AI 智能体,另一些则使用确定性工具。

最后,我会让构建该功能的智能体提出一些简短易行的手动测试,让我可以确认变更是否有效。

我会在本地或测试环境中启动代码,运行这些检查,如果一切通过就部署到生产环境。

如果变更非常复杂或涉及敏感数据,我还可能在生产环境中运行一组有限且安全的冒烟测试,但不会暴露真实用户数据,也不会进行破坏性变更。

Diagram of Mihai’s workflow in three phases: plan (feature request, spec, plan); implement, repeated per commit (the agent implements a commit, a separate AI reviews it, tests run, findings get fixed); and verify and release (a whole-change review against the spec, human PR review alongside CI and security checks, a manual smoke test, then deploy and monitor)

这个流程让我和我的团队能够快速交付代码，同时建立起信心——我们所交付的东西符合规范，并且经过了有意义的测试和安全检查。并非完美的信心（软件永远无法保证没有 bug 或不可能被攻破），但比盲目合并智能体生成的任何东西要有信心得多。

这其实才是重点：如果 AI 让编写代码变得廉价，那么验证就必须成为我们构建软件方式中一等公民的部分。

如果你对我如何运行这个轻量级工作流框架感到好奇，请告诉我，我很乐意与你分享。

下次再见，祝你的测试全部通过，上下文窗口永远用不完。

~Mihai

资料来源与参考

以下资料支持上文提及的研究发现、产品能力以及 CI/CD 与安全指导。产品功能、方案可用性和定价可能会有变化。

Faros — The Acceleration Whiplash（2026 年 Q2）： 2026 AI 工程报告。研究范围、吞吐量、评审负载、缺陷与事故。
Faros — The Speed Trap（2026 年 Q3）： 最新报告要点。关于后期 AI 采纳模式与下游成本的细节解读。
Superpowers（Jesse Vincent / obra）： GitHub 仓库。基于技能的开发工作流、规划、TDD、调试与评审。
RoboRev： 官方网站和文档。本地持续代码评审、Git hooks、评审生命周期。
Wes McKinney： GitHub 个人主页。pandas 创建者，Kenn Software 创始人。
Anthropic： 为 Claude Code 设置 Code Review。托管式评审架构、资格要求、定价与触发条件。
Anthropic： Claude Code /code-review 插件。插件功能与工作流。
OpenAI： 使用 Codex 评审 GitHub pull request 和 Codex PR 评审帮助。PR 评审、提示词与后续操作。
GitHub： 使用 GitHub Copilot 代码评审。自动评审、建议的更改、评审状态与定制化。
Cursor： Bugbot 和 Bugbot Autofix。PR 评审与辅助修复。
NIST： 安全软件开发框架（SSDF），SP 800-218。贯穿软件开发生命周期的安全实践。
GitHub： GitHub Actions 文档、仓库规则集以及安全使用 pull_request_target。工作流、状态检查与信任边界。
OpenAI： Codex GitHub Action 和安全指导。Action 配置、只读权限与密钥处理注意事项。
Adam Faik，The AI Thinker： 如何构建 AI 原生软件工厂（2026 年 10 月）。介绍 Uber、Shopify、DoorDash、Spotify、Stripe 等公司如何规模化运行编码智能体，从需求接收到合并的全过程。