人工智能工程在实践中的应用：人工智能工程师与现场部署工程师如何利用Claude Code、Codex及Gemini来进行开发工作

在这个阶段，DORA报告中那些不太乐观的发现也就显得尤为重要了：尽管有90%的开发人员表示采用了相关技术，但仍有大约三分之二的开发者表示他们对人工智能生成的代码缺乏信任。DORA报告中提到了这一现象。当测试被安排在快速开发流程之后的一个独立阶段进行时，这种不信任情绪是可以理解的——因为在代码尚未经过验证的情况下，开发者就必须依赖这些代码来开展工作。然而，一旦每次代码提交后都会自动进行验证，而不再需要等待人工安排测试时间，这个问题就变成了一个可以通过工程手段解决的难题，而不再是一种持续存在的风险。

Claude Code通过“钩子”机制实现了这一功能：这些shell命令会在特定的生命周期事件发生时自动执行，比如在代理程序修改文件或运行命令之前或之后。Anthropic中详细介绍了这一机制。例如，在.claude/settings.json文件中，可以这样配置一个钩子：在每次文件被修改后执行测试套件，如果测试失败，则阻止代理程序继续执行后续操作：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "pytest tests/ -x -q --timeout=60"
          }
        ]
      }
    ]
  }
}

具体来说，这个机制的工作原理如下：

• PostToolUse钩子在代理程序完成“编辑”或“写入”操作之后才会被执行，因此它会检查磁盘上发生的变更。
• pytest -x命令会在遇到第一个失败案例时立即停止测试，这样就可以及时获取反馈信息，而不会生成一份完整的失败报告让代理程序去解析。
• 如果测试失败，这个命令会返回一个终止代码，从而阻止代理程序继续处理plan.md文件中列出的下一个文件，直到所有测试都通过为止。

Codex和Gemini CLI并没有提供与Claude Code同样成熟的本地钩子框架（如果你曾经尝试过在自己的笔记本电脑上手动停止代理程序的执行，就会明白这一点）。这与其说是一个缺失的功能，不如说是一种不同的开发流程设计：这两款工具主要依靠持续集成系统来实施代码验证，而不是依赖本地的生命周期事件触发机制。因此，Codex和Gemini CLI的/review功能以及由PR请求触发的审核流程，其实也能解决类似的问题——只不过这些机制是在代码提交到仓库之后才起作用的。

如果你目前正在本地使用Codex或Gemini CLI，那么一个实际的替代方案就是利用Git本身的预提交钩子来执行与Claude Code中的钩子相同的测试命令。这样，你就可以在工具链的不同层面上实现类似的验证功能。

无论使用哪种工具，这一阶段都应该生成一份与特定代码提交相关的测试结果，并将这些结果记录在plan.md文件中。这样一来，后续的审核人员就能清楚地了解是哪些测试验证了哪些内容，而不会盲目信任那些可能代表上周代码状态的绿色标记。

如何运行部署阶段

Anthropic将这一阶段描述为“多层自动化审查机制，其中对于受监管或至关重要的代码，仍会由人类进行审核”；在这个过程中，“当AI执行相关操作时，治理规则会被严格执行，而各种审批流程则起到了把关的作用。”（Anthropic）

“多层”这一表述确实很贴切：该框架并不是建议用自动化审查完全取代人工审核，而是主张将自动化审查作为前置且成本较低的环节，这样人类就可以专注于那些经过自动化检查后仍需要人工审核的部分，而无需从头开始检查所有内容。

目前，这三家供应商都提供了自己开发的GitHub Action插件，因此你不必从头开始构建CI集成流程。Claude Code提供的anthropics/claude-code-action插件可以响应PR或问题中包含的@claude标签，或者根据你配置的日程安排在任何GitHub事件中自动运行（Anthropic）：

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: “请根据spec.md和plan.md文件审查这段代码差异。”

Codex提供的对应插件openai/codex-action会在CI任务执行过程中直接运行codex exec命令，这意味着该插件拥有完整的CLI功能，并非仅用于审核；根据你的配置，它还可以应用补丁或发布审核评论（OpenAI）：

name: Codex Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  codex-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: openai/codex-action@v1
        with:
          openai_api_key: ${{ secrets.OPENAI_API_KEY }}
          command: "请根据链接的spec.md文件审查这段代码差异，并标记出P0/P1级别的问题"

Gemini提供的google-github-actions/run-gemini-cli插件也会在相同的PR和问题事件触发时运行，而且它会利用完整的项目上下文异步执行审核任务，而不是进行同步阻塞式的检查（Google）：

name: Gemini Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  gemini-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: google-github-actions/run-gemini-cli@v1
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: “请审查这段PR代码，检查其正确性、效率及可维护性。”

除了这些基础的CI插件之外，这三家供应商还都提供了具有各自配置界面的专用代码审核工具。Claude Code的Code Review是一项托管服务，它可以同时让多个专门的自动化审核工具并行处理代码差异；此外，它还包含一个单独的验证步骤，用于在任何内容被提交给人类审核之前，先过滤掉可能出现的误报结果。这个验证步骤可以通过@claude review命令或本地的/code-review命令来触发（Anthropic）。

Codex的审核机制主要包括两种方式：一是通过CLI composer中的`/review`命令；二是通过在GitHub的PR中添加`@codex review`标签；三是对于未添加相关标签的新PR，系统会自动执行审核流程。在GitHub模式下，Codex会专门筛选出最严重的P0级和P1级问题进行标记，而不会关注那些风格上的小问题（来源：OpenAI）。

与前两种审核机制不同，Gemini Code Assist for GitHub主要是通过配置文件`/.gemini/config.yaml`来设置审核规则的。这个文件与用于控制构建过程的配置文件是相互独立的。该工具会在五个方面生成审核评论：正确性、效率、可维护性、安全性，以及涵盖测试、可扩展性和错误日志记录等内容的综合评价（来源：Google）。

当自动化审核流程无法处理某些问题时，就需要由人工进行干预。具体而言，哪些变更需要人工审批，应该根据这些变更对系统产生的影响程度来决定，并没有统一的规则可以适用。例如，任何涉及数据库迁移、认证流程或支付相关的变更，无论自动化审核的结果如何，都应要求人工批准。

对于那些通过了所有自动化审核环节的文档修改或配置值调整，它们完全可以被自动合并到代码库中。Anthropic将这种差异记录视为审计追踪的一部分，它认为：“提交历史本身就构成了审计追踪——谁提出了哪些请求，代理程序生成了什么结果，以及最终是谁批准了这些变更”（来源：Anthropic）。

我们可以这样理解这个流程：自动化审核并不会在代理程序停止编写代码时就结束，而是会在它收集到足够的信息后才会完成审核过程，这样人类就可以基于这些信息快速而明智地做出审批决定。

如何运行维护阶段

“维护阶段”正是“以工件为导向的开发流程”这一名称的由来之处，因为在这个阶段，整个开发循环才会真正闭合。Anthropic将这个阶段描述为：“代理程序会监控生产环境中的部署情况。一旦发现任何超出预设范围的异常情况，就会生成新的`intent.md`文件，并将其重新纳入审核流程中”（来源：Anthropic）。

如果没有这个“反馈机制”，维护阶段就只是简单的监控工作，这与团队多年来一直使用的传统监控工具并无区别。但有了这个反馈机制，生产环境中出现的任何问题都会直接成为下一轮规划阶段的输入内容，而不会只是一份被阅读一次后就束之高阁的事后分析报告。

一种实用的配置方式是使用“区间控制”模型来规定各项指标的可接受范围，以及当这些指标超出范围时应采取的措施：

# monitoring/bands.yaml

- metric: p99_latency_ms
  service: checkout-api
  band: [0, 400]
  on_breach:
    severity: high
    action: open_incident
    write_intent: true

- metric: error_rate_pct
  service: checkout-api
  band: [0, 1.0]
  on_breach:
    severity: critical
    action: page_oncall
    write(intent: true

- metric: daily_active_users
  service: onboarding-flow
  band: [800, null]
  on_breach:
    severity: medium
    action: open_incident
    write_intent: false

以下是具体的运作机制：

• 每项指标都有一个可接受的范围，而不是一个固定的阈值。这种设计使得我们能够同样容易地发现那些数值过低的情况，也能及时察觉到数值过高的现象。

• write_intent: true这一机制会自动将一次违规行为转化为一个新的规划阶段的开始，系统会生成一份intent.md文件，其中会明确指出出现问题的指标、相关服务以及事件的详细信息。

• 并非所有的违规行为都应该触发新的规划流程。对于那些影响较小的服务而言，如果每日活跃用户数量有所下降，虽然可能需要记录这一事件以便关注情况，但并不一定需要启动新的规划工作。因此，这个选项是明确规定的，而不是默认生效的。

在这里，“代理程序接收信息的位置”其实非常重要：正是这个环节使得这三款工具之间存在差异。Claude Tag为组织在Slack中提供了一个统一的@Claude身份标识，该功能可以在频道中异步运行，并会将相关的编码任务转发到网上的Claude Code平台。因此，“有人在事件频道中提到出现问题的指标，然后让机器人处理这个问题”这种操作方式，本身就是一种现成的维护阶段处理流程（更多信息请参见Anthropic）。

OpenAI也提供了类似的解决方案：他们推出了官方的Codex Slack应用，在该应用中，如果在频道或讨论帖中使用@Codex标签，系统就会创建一个云任务，在相应的代码仓库中执行相关操作，并将结果再次发布到原来的讨论帖中（更多信息请参见Slack）。

如上所述，目前谷歌还没有自己的类似解决方案；目前只有第三方工具或社区开发的方案才能将 Gemini CLI与Slack连接起来。对于基于 Gemini的维护阶段流程来说，一个实际可行的解决方法是通过现有的待命通知系统的Webhook来自动执行相关操作，而不需要等待有人在聊天中提到这个问题（建议在事件发生之前就设置好这个机制，以免在事件处理过程中才去寻找相关的工具）。

如果追踪整个从违规行为到下一个规划周期的流程，就会看到如下所示的图表：

图3：实际上，这个流程更像是一个封闭的循环。从左到右、自上而下看，intent.md会生成spec.md，spec.md会生成plan.md，plan.md会用于构建代理程序，随后进入自动化测试和审核环节，然后进行部署，最后进行监控。那条标有“触发下一个周期”的虚线蓝色箭头，正是大多数团队流程所缺失的部分——它将监控结果直接反馈到新生成的intent.md文件中，从而完成整个循环过程，而不会像传统的流程图那样在部署环节结束。

上图展示了本章节中所有环节的运作流程：它追踪了从bands.yaml文件中的某处漏洞，经过open_incident流程，生成事件记录，进而创建新的intent.md文件，最终又回到本指南最初提到的“计划阶段”这一过程。那条从“维护阶段”返回“计划阶段”的箭头，正是当今大多数团队的工程流程中所缺失的部分——即便那些在“构建阶段”采用了自动化编码工具的团队也不例外。

如果只购买用于“构建阶段”的自动化工具，而不建立这种反馈机制，虽然可以快速编写代码，但各个团队依然会沿用那种繁琐的手动流程，将事件信息转化为路线图。正是这条箭头使得这六个阶段构成了一个完整的循环，而不仅仅是一些彼此相邻、独立进行的改进过程。

一名工程师如何管理一个五人的团队

上述内容假设团队规模足够大，因此有专人负责规划、审核、发布管理和应急响应工作。但实际上，越来越多的工程师所处的团队并不符合这种配置。

GitHub在2025年发布的Octoverse报告显示，在过去一年中加入GitHub的开发者中，近80%的人在入职第一周就使用了Copilot工具。这一数据说明，人工智能辅助开发正逐渐成为新工程师职业生涯的起点，而不再是一种需要多年经验才能掌握的高级技术。

再加上Stack Overflow的调查结果——大约有一半的专业开发者每天都在使用人工智能工具，由此可见，那些考虑独自创业或组建两人团队并采用这种技术栈的工程师，并不是个例，他们其实代表了大多数新入职的开发者。

下面以一个具体例子来说明当一个人或两个人共同完成这六个阶段时，整个流程会是怎样的：比如一名工程师正在为独立承包商开发调度工具，目标是在六周内推出付费测试版。

计划阶段：

计划阶段取代了产品经理将客户需求转化为具体规格书的工作。创始人会与三位承包商讨论现有调度工具存在的问题，然后将这些讨论记录整理到intent.md文件中，通过“计划模式”会议将这些零散的信息整合成一个明确的问题陈述：承包商需要能够看到所有客户的日历信息，但同时不能让任何一位客户的管理员访问其他客户的日历数据。

这个耗时15分钟的会议，相当于一个两人团队花费一周时间进行客户访谈和编写需求文档所完成的工作量。

设计阶段：

设计阶段取代了架构师在白板上进行设计的环节。同样的会议过程，在只读模式下进行，最终会生成spec.md文件：这个文件详细规定了系统需要实现的功能，包括日历信息的叠加显示、与各客户日历服务提供商的OAuth集成机制，以及统一的界面展示方式。同时，明确拒绝了实时同步功能，而是选择了每5分钟进行一次数据更新的方式——因为实时同步很可能会导致项目无法在六周内完成。

在规格书中明确写明“由于时间安排的原因，放弃了实时同步功能”，这一规定能够确保创始人在第五周面临压力时，不会重新考虑这个决定。

构建阶段：

构建过程实际上取代了整个工程团队的作用。通过使用plan.md文件来明确指定日历集成功能、认证流程以及统一视图组件的实现细节，这种基于代理的编码工具会根据CLAUDE.md（或AGENTS.md、GEMINI.md）文件来执行相应的开发工作。这些文件记录了创始人最初做出的各项技术决策：应该使用哪个日历库、采用哪种认证模式，以及业务逻辑应存储在何处。阅读本指南的读者应该已经预料到，这一阶段的开发速度会相当快。而Beta版本的能否按时发布，其实取决于其他相关环节的进展情况。

测试阶段：

测试工作同样取代了传统的质量保证工程师的角色。由于每次修改文件后都会自动运行测试套件，因此创始人在演示前的晚上根本不需要去调试那些尚未经过测试的代码结果。在开始构建开发之前，就将测试标准详细记录在plan.md文件中，而不是等到开发完成后才进行测试——这种做法正是专业质量保证工程师会坚持要求的。

部署阶段：

部署过程实际上取代了发布管理者的职能。GitHub Actions会自动对每一份拉取请求进行代码审查，而对于那些涉及OAuth认证流程或计费功能的修改，还会由专人进行特别审核。这样一来，即使没有其他工程师协助，创始人也能按照Anthropic框架的要求完成各项审批工作。不过，创始人仍然会亲自审阅所有与资金或敏感信息相关的代码变更。

维护阶段：

维护工作不再需要依赖轮值值班的运维团队。通过bands.yaml文件来监控API错误率及任务执行成功率，并将这些数据直接发送到创始人的手机上，这种机制就足以满足这家规模公司的应急响应需求。如果凌晨2点时任务执行失败率的数值超出了预设范围，相应的故障记录就会成为下周的第一份intent.md文件，而创始人也无需等到周一才能回忆起具体问题所在。

判断力依然像过去一样重要。不同的是，过去需要整个团队来协调完成的工作，现在已经通过代码本身得到了明确的规定：每个被提交的代码文件都清楚地记录了原本需要由多个专家分别负责处理的各项细节。

这就是为什么说，采用基于人工智能的SDLC框架是可行的——以工件为导向的开发模式可以让一个人的专业知识覆盖过去需要多人分工才能完成的工作范围。

在全面采用基于人工智能的SDLC框架之前，请先检查以下内容：

在根据这一框架重新设计团队工作流程之前，请先完成以下分阶段需要检查的事项：

规划与设计阶段

• [ ] 仓库中必须存在intent.md模板，每项新的开发工作都应从填写完整的该模板开始。

• [ ] 必须有spec.md模板，并且其中要包含“待解决的问题”部分，以便在开始构建开发之前由专人进行审阅。

• [ ] 除了提出请求的人之外，至少还必须有另一位人员确认代理程序对开发目标的总结内容，之后才能将其正式纳入规范文件中。

构建阶段

• [ ] 必须存在一个配置文件（如CLAUDE.md、AGENTS.md或GEMINI.md），并将其提交到版本控制系统中。该文件应明确指定命令、架构及相关规范，而不仅仅是包含占位符文本。

• [ ] plan.md文件需明确列出在开始实施之前需要处理的特定文件、变更顺序以及测试内容。

测试阶段

• [ ] 必须设置钩子脚本、提交前检查机制，或类似的本地验证流程，以便在测试失败时自动阻止后续操作。

• [ ] 测试结果应与对应的提交记录关联起来，而不仅仅是在聊天中简单地标注“通过”或“失败”。

部署阶段

• [ ] 必须使用第三方CI工具（如Claude Code、Codex或Gemini），对每一份拉取请求进行自动审核。

• [ ] 对于涉及权限管理、支付功能、数据迁移或基础设施变更的代码，无论自动化审核的结果如何，都必须经过人工审批才能继续部署。

• [ ] 如果启用了自动合并功能，也仅应将其应用于低风险场景，而不能默认应用于所有通过审核的代码。

维护阶段

• [ ] 监控配置应针对对企业而言真正重要的指标进行设置，而不仅仅是平台本身提供的所有指标。

• [ ] 对于严重程度最高的违规事件，系统必须自动生成新的intent.md文件，从而将问题反馈回规划阶段。

• [ ] 必须有人负责处理这一阶段产生的各种问题，即使这个人也是负责其他阶段工作的人员。

结论

现在，你已经掌握了如何利用智能编码工具来重构软件团队的开发流程，并了解了三种具体的实现方法。这六个阶段（规划、设计、构建、测试、部署、维护）的名称并没有发生变化，真正发生变化的是每个阶段产生的成果以及生成这些成果所使用的工具。

• intent.md文件能够在任何人对问题进行解读之前，就将其捕捉下来——无论这种解读是在Claude Code的规划模式下进行的，还是在Codex的只读沙盒环境中完成的，又或者是通过Gemini CLI的规划审批流程来实现的。

• spec.md文件和plan.md文件将开发人员的工作效率转化为实际价值，因为它们为开发人员提供了明确的目标，并且这些目标已经经过了人工审核。

• 钩子脚本、CI工具以及代码审查机制取代了传统的测试环节，实现了持续性的验证过程。这些流程被集成到每一次代码提交中，而不仅仅是在最后阶段才进行。

• 分层审核机制将人类的判断力应用在那些真正需要发挥价值的地方——也就是那些可能产生广泛影响的变更场景中，而不是对每一行代码都进行逐一审查。

• 区间式监控配置有助于形成闭环，使生产过程中出现的问题的信息能够直接用于下一个开发周期的规划工作，而不会被遗忘或忽略。

本指南中每个阶段所遵循的核心原则，其实就是METR最初提出的“任务完成速度倍增曲线”所体现的理念：无论你的开发流程是否已经跟上发展步伐，限制软件发布速度的因素其实早已发生了变化。那些仍然将“构建环节”视为瓶颈的团队，只会不断优化那个已经不再构成问题的环节而已。

接下来可以探索的内容

• Anthropic提出的AI原生SDLC开发框架，这是本指南所采用的六阶段开发模型的主要来源

• DORA发布的2025年人工智能辅助软件开发现状报告，其中包含了相关的数据与分析结果

• METR关于AI任务完成速度倍增的研究

  ，详细介绍了这一现象背后的计算方法与逻辑

• Claude Code的文档中心，内容涵盖内存管理相关功能、权限设置模式以及子代理机制等

• OpenAI发布的关于智能体审批与安全性的官方文档

  ，详细说明了沙箱测试环境与审批流程的分离机制

• Gemini CLI的配置参考指南

  ，其中介绍了当前版本中的审批模式与扩展系统功能

欢迎访问我的GitHub账户，了解更多我使用这种AI原生工程流程开发并分享的开源软件解决方案及开发者工具。