Agentic AI Engineering in Practice: How AI Engineers and Forward-Deployed Engineers Build with Claude Code, Codex, and Gemini

实践中的智能代理AI工程：AI工程师与前线部署工程师如何使用Claude Code、Codex和Gemini进行开发

2026年9月4日

/

#开发者工具

Rudrendu Paul

一份关于原生AI软件开发生命周期（SDLC）的实用三工具指南：规划、设计、构建、测试、部署、维护，重新构想为智能代理编码模式。

2025年3月，一个名为METR的非营利研究小组发布了一张图表，让许多工程领导者坐直了身子。

通过回溯六年来的模型发布记录，METR测量了AI代理能够独立完成的软件任务长度，他们将这一指标定义为熟练的人类专业人士完成相同任务所需的时间，并发现自2019年以来，这个数字每七个月大约翻一番（METR）。

这条曲线并不是关于自动补全功能的微小改进：它标志着代理能力从"完成一个函数"跃迁到"完成一个功能"，按当前发展轨迹，正逐步达到"完成一个冲刺周期（sprint）"的水平。

采用数据已经反映出这种转变。Google Cloud和DORA在2025年发布的《AI辅助软件开发现状报告》发现，90%的开发者现在在工作中使用AI，超过80%的人表示AI提高了他们的生产力，尽管大约三分之一的人仍然报告对模型生成的代码信任度较低（DORA）。

Stack Overflow的2025年开发者调查显示，习惯性使用AI工具的比例类似：84%的开发者现在使用或计划使用AI工具，较前一年的76%有所上升，约一半的专业开发者每天都会使用AI工具（Stack Overflow）。

AI辅助编码跳过了新奇阶段，已成为软件编写的新常态。与此同时，大多数团队仍未更新他们为前一默认模式构建的软件开发生命周期。

这种不匹配正是本文探讨的重点。Anthropic的应用AI团队于2026年发布了一个名为"原生AI SDLC"的框架，其核心观察是：一旦代理编写和修改代码的速度超过人类审查拉取请求的速度，软件交付的瓶颈不会消失，而是转移到了其他环节（Anthropic）。

本指南将逐步讲解该框架（规划、设计、构建、测试、部署、维护），并展示如何使用您可访问的任意智能编码工具（Claude Code、OpenAI Codex或Gemini CLI）实现每个阶段。您将看到三种工具的配置文件、Markdown制品模板和CI工作流程，以及一个完整示例，展示单个前线工程师如何使用此模式覆盖过去需要五人团队完成的工作量。

本指南是一个框架的三种实现方式：基于配置文件和命令输出的实践者操作手册。

目录

• 先决条件

• 什么是原生AI SDLC？

• 代码成本降低后瓶颈的转移方向

• Claude Code、Codex和Gemini CLI：一个框架，三种术语体系

• 如何执行规划阶段

• 如何执行设计阶段

• 如何执行构建阶段

• 如何执行测试阶段

• 如何执行部署阶段

• 如何执行维护阶段

• 一位工程师如何覆盖五人团队的工作（规划阶段、设计阶段、构建阶段、测试阶段、部署阶段、维护阶段）

• 全面采用智能代理原生AI SDLC前的检查清单

• 结论

• 下一步探索方向

先决条件

开始之前，请确保您具备以下条件：

• 已安装一个智能编码命令行工具：Claude Code、OpenAI Codex 或 Gemini CLI。您只需安装其中一个即可跟随教程。下方各部分会为每个工具提供对应的命令或文件。

• Node.js 18 或更高版本（通过 node --version 验证），因为这三个工具均以 npm 包形式分发。

• Git 2.30 或更高版本（通过 git --version 验证）。

• 启用 GitHub Actions 的 GitHub 仓库，因为部署和维护部分会使用 CI 工作流。

• 熟悉基础的 CI/CD 概念：拉取请求、分支保护以及构建流水线的作用。您不需要深入掌握 GitHub Actions。

安装您计划使用的工具：

npm install -g @anthropic-ai/claude-code
npm install -g @openai/codex
npm install -g @google/gemini-cli

每个工具的功能如下：

• claude-code 会在您的路径中添加 claude 命令，该命令可在本地仓库中运行智能会话，支持权限模式、子代理和技能。

• codex 会在路径中添加 codex 命令，包含其自己的沙箱环境和审批模型，并提供云端任务模式。

• gemini-cli 会在路径中添加 gemini 命令，基于可安装单元的扩展功能，集成提示、MCP 服务器和斜杠命令。

您不需要安装所有三个工具。选择雇主已付费的工具，或选择免费层级符合项目需求的工具，并按照对应的列继续阅读本指南。

什么是 AI 原生的 SDLC？

下图展示了六个阶段如何构成一个连续系统，而非孤立步骤。以下部分将解释每个阶段如何向下一阶段传递一个重要的命名工件，最终阶段会直接返回到起点，而非在部署后停止。

图1：AI原生软件开发生命周期（SDLC）被绘制为闭合的六边形循环，而非直线流水线。六个阶段（计划、设计、构建、测试、部署、维护）按顺时针方向排列在外部。每个阶段传递给下一阶段的工件（intent.md、spec.md、plan.md 加上代码、测试结果、review.md、bands.yaml）位于循环内，靠近其移动的箭头。从维护返回计划的双箭头是需要首先注意的细节：它将六个独立阶段转化为一个自我触发的循环，而非六个并列的改进步骤。

如果您沿着箭头方向追踪：

• 计划阶段会向下一阶段传递一个 intent.md 文件。

• 设计阶段会向构建阶段传递一个 spec.md 文件。

• 构建阶段会向测试和部署阶段传递 plan.md，最终传递一个差异文件。

• 部署阶段会向维护阶段传递一个包含审查结果的合并拉取请求。

• 当生产环境出现问题时，维护阶段会编写新的 intent.md 并重新开始循环。这个闭合循环本身就是创新的核心，而不仅仅是单个阶段。

传统 SDLC 图表通常被绘制为瀑布模型或水平流水线。这个图表被绘制为圆环，因为其核心理念是操作数据会自动成为下一个规划输入，而非停留在无人查看的仪表板上，直到下一次规划会议。

工程师们构建的传统六阶段软件开发生命周期（计划、设计、构建、测试、部署、维护）基于一个持续了五十年的假设：编写和实现代码是流程中最昂贵、最耗时的部分。

Anthropic 的应用人工智能团队在 2026 年发布其 AI 原生 SDLC 框架时明确指出了这一假设，并围绕该假设失效时会发生的情况构建了整个模型（Anthropic）。该框架保留了软件工程师已熟悉的六个阶段名称。不同之处在于每个阶段如何生成和消耗工作内容。

Anthropic 将这一机制称为工件驱动开发。每个阶段都会提交一个持久化、版本控制、机器可读的文档供下一阶段读取：无需会议、无需 Slack 聊天线程，也无需依赖某人脑海中的共识。

• Plan 阶段生成 intent.md，用请求者自己的话描述问题的纯文本说明。
• Design 阶段生成 spec.md，包含需求和约束条件，并在文档中标记任何未决问题。
• Build 阶段生成 plan.md，包含实施计划，命名将要修改的文件、修改顺序以及验证这些修改的测试，随后附上代码差异（diff）。
• Test 和 Deploy 阶段生成包含多层自动化审查结果的拉取请求（pull request）。
• Maintain 阶段生成事件记录，当生产环境中某些指标超出预期阈值时，这些记录会反馈到新的 intent.md 中。

Anthropic 的表述很好地体现了该设计意图：

"每个阶段都会提交一个下一阶段可读取的工件。意图（intent）、规格（spec）、计划（plan）、差异（diff）和审查结果共同构成了审计追踪。"（Anthropic）

这种审计追踪的重要性不仅限于合规性。当代理能够在几分钟内生成可运行的代码差异时，软件质量的决定因素是它所依据的计划是否优质，以及在发布前是否有人将其输出与需求进行了核对。

工件使得在不降低代理效率的情况下进行核对成为可能：一份规格文档只需十分钟进行审查，可以像代码一样进行缓存、复用和差异比对。而口头交接则无法做到这一点。

代码成本降低后瓶颈的转移

Anthropic 将其框架中相关部分的标题定为 "代码不再是瓶颈"，并在下一行解释原因：

"组织已经开始以一年前难以想象的速度使用 AI 编写代码，但围绕代码的流程却没有以相同的速度演变。"（Anthropic）

这一观察值得深入思考，因为它改变了你组织日常工作的方法，而不仅仅是选择什么工具。下图用数字展示了这一重新分配在冲刺周期日历时间中的分布情况。

图 2：两个堆叠的时间线，宽度相同，显示冲刺周期日历时间如何重新分配。顶部条形图 "传统 SDLC" 将时间分为大致相等的六个部分。底部条形图 "AI 原生 SDLC" 保持计划（Plan）、设计（Design）和部署（Deploy）阶段的宽度（标注为 "保持人类节奏"），而构建（Build）和测试（Test）阶段则压缩为更窄的部分（标注为 "压缩至数小时"）。两个条形图的总长度相同是有意为之：重点不是一切都变快了，而是原本用于构建的时间现在必须转移到其他地方，而那个地方就是计划（Plan）和审查（Review）。

上图展示了传统软件开发生命周期（SDLC）与AI原生版本在时间分配上的对比。在传统模型中，构建阶段占据主导地位：一个冲刺周期的大部分日历时间都用于编写和调试代码，而计划、测试和部署阶段则相对薄弱。在AI原生版本中，构建阶段被压缩为一个细小的部分——智能代理可以在过去安排启动会议所需的时间内生成可运行的实现，计划、测试/评审和部署阶段的条形图则扩展至构建阶段原本占据的空间。图表的总宽度几乎保持不变。发生变化的是现在哪些阶段承担了限制速度的工作。

Anthropic的表述方式将这三个阶段定义为：

“瓶颈转移到构建阶段左右两侧的步骤。这主要涉及计划、评审/测试和部署阶段，这些阶段仍然以人类速度运行。”（Anthropic）

这是一个具体且可证伪的主张，值得认真对待而非简单视为口号。构建阶段的速度提升会在三个方面以可避免的方式失效：

• 快速构建，模糊计划：由于“错误”与“发布”之间的时间间隔缩短，智能代理以高速自信地实现错误方案，反而会比人类缓慢犯下相同错误更糟糕。
• 快速构建，未扩展的测试与评审：没有人重新设计评审流程以应对快速代理产生的大量变更，因此要么评审质量下降，要么评审人员成为新的瓶颈，当人类需要阅读代码差异时，速度优势就会消失。
• 快速构建，人工部署：人类仍需手动将构建结果通过三个环境进行推进，因此智能代理的产出速度会超过组织的吸收能力。

此处的论点是：围绕智能代理的阶段，而非代理本身，才是AI原生SDLC体现其价值的核心。智能代理编码工具本身并非问题所在。本指南的其余部分将用历史上团队对构建阶段所保持的工程严谨性，同样对待计划、设计、测试、部署和维护阶段，因为现在约束条件已转移到这些环节。

Claude Code、Codex 和 Gemini CLI：同一框架，三种术语体系

以下每个阶段都会为您提供Claude Code、Codex和Gemini CLI的命令或文件对照：这只有在您了解每种工具对即将使用的机制的命名方式后才能实现。三家供应商都提供了真正具备能力的智能代理编码工具，最适合您的工具通常是您雇主授权的工具，或其免费层级与您的工作负载匹配的工具。

下表是阅读分阶段内容时需要反复参考的参考指南。

| 功能 | Claude Code | OpenAI Codex | Gemini CLI | |------|-------------|--------------|------------| | 记忆/上下文文件 | CLAUDE.md，位于项目根目录，~/.claude/ 或 .claude/（Anthropic） | AGENTS.md，从Codex主目录向下遍历至项目根目录（OpenAI） | GEMINI.md，跨全局、项目和子目录层级拼接（Google） | | 可复用提示/扩展系统 | 子代理（拥有独立上下文窗口、受限工具）加上Skills（基于文件夹、自动调用）（，Skills已取代过时的自定义提示。MCP服务器单独处理外部工具访问。 | 扩展包将提示、MCP服务器、斜杠命令、钩子和子代理整合为一个可安装单元（ | | 审批/沙箱模式 | 权限模式：手动、自动和计划模式，通过Shift+Tab切换（ | | |

两个独立的轴：沙盒模式（只读、工作区写入、危险全访问）和审批策略（不可信、按需、从不）

审批模式：默认、自动编辑、yolo（--yolo 或 Ctrl+Y），以及仍在成熟中的计划模式

第一方 CI 操作

anthropics/claude-code-action，由 @claude 提及或计划事件触发

openai/codex-action，在 CI 作业中运行 codex exec 并可应用补丁或发布审查

google-github-actions/run-gemini-cli，由 PR 和问题事件触发

原生 PR 代码审查

代码审查：一个托管的多代理服务，带有本地 code-review 命令和带严重性标签的内联注释（CLI 中的 /review，GitHub 中的 @codex review，或“自动审查”设置，可在每个新 PR 中标记 P0/P1 问题）

GitHub 的 Gemini 代码协助，可通过提交的 .gemini/config.yaml 文件在五个审查维度上进行配置

始终开启的聊天界面

Slack 中的 Claude 标签：一个共享的组织身份，将编码意图路由到网页上的 Claude Code

官方 Codex Slack 应用：在频道中的 @Codex，创建云任务并回发结果

Slack

截至本文撰写时，尚未确认存在第一方原生 Slack 身份。目前仅存在第三方桥接方案

当你将这些机制并排对比时，有几处特别突出。这三款工具现在都收敛于相同的核心理念：代理在执行任何操作前读取的纯文本内存文件、可重用提示和工具的打包系统、决定代理自主程度的审批层，以及用于在 CI 中运行代理的第一方 GitHub Action

一旦构建不再是限制因素，每个供应商都必须构建相同的周边基础设施，否则其工具会变得快速但难以管理

这三款工具不对称的唯一位置是最后一行。Claude Code 和 Codex 各自提供了一个官方的、由供应商构建的 Slack 存在，带有持久标签身份，可将频道提及转换为异步编码任务。截至本研究，Gemini CLI 尚未有文档记载的等效方案（仅社区构建的桥接方案将其连接到 Slack）

如果你的维护阶段工作流依赖代理直接从聊天提及中获取事件，那么这属于需要规划的能力建设缺口，而非偏好问题

由于这削弱了“你必须选择一个工具并永远使用它”的观念，再补充一个互操作性要点值得强调：Claude Code 自身的内存文档描述了通过 @AGENTS.md 引用或符号链接导入现有 AGENTS.md 文件的方法，因此 Claude Code 会话可以读取 Codex 会话已使用的相同惯例文件（Anthropic）

AGENTS.md 本身已成为跨供应商的开放标准，采用范围远超 Codex，并由 OpenAI 之外的组织维护。一个团队若在 AGENTS.md 上标准化其惯例文件，并让 Claude Code 导入该文件，即可获得大部分共享内存文件的好处，无论当天工程师个人更偏好哪种工具

如何运行计划阶段

计划阶段在任何代码被修改之前回答一个问题：用拥有该问题的人的原话，问题是什么？

Anthropic 的框架将此阶段生成的产物称为 intent.md，其命名刻意保持低调。它不是一个已经通过解决方案反向推导出验收标准的 Jira 任务。它更接近于一份记录：请求者用他们自己的语言描述的需求，在工程师或代理开始解释之前就被原封不动地记录下来。

以下是一个你可以提交到仓库并重复用于所有新工作的最小 intent.md 模板：

# intent.md

## 请求人
姓名、角色、日期

## 他们说了什么
粘贴原始请求。暂时不要进行清理。如果来自支持工单、Slack 聊天或事件，请附上链接。

## 这解决了什么问题
一两句话，写在上述原始请求之后，将其转化为问题陈述。这是第一次允许进行解释的地方。

## 为什么现在
触发此请求的原因。如果来自事件，请注明它追溯的事件记录。

## 已知的约束条件
请求者指定的任何内容：截止日期、预算、无法更改的系统、监管要求。

## 明确超出范围的内容
用"它不包含什么"来表述此请求不包含的内容。

以下是实际发生的情况：

• "他们说了什么"部分刻意保持原样，这样下一阶段可以在请求传播之前发现误读
• 将"他们说了什么"与"解决了什么问题"分开，迫使解释步骤只发生一次，以书面形式完成，而不是由下一个阅读请求的人在脑海中进行
• "为什么现在"字段是与"维护"阶段形成闭环的关键：来自生产事件的意图应明确说明这一点，并链接回触发它的事件记录

当用于具体请求时，同样的模板保持简短：

# intent.md

## 请求人
Maria，独立承包商和测试用户，2026-08-14

## 他们说了什么
"我每天早上必须检查四个不同的日历才能告诉客户我的空闲时间。这个月我已经两次被重复预订了。"

## 这解决了什么问题
跨多个客户工作的承包商无法在不向其他客户日历系统开放权限的情况下，看到自己统一的空闲时间视图。

## 为什么现在
私人测试期间的直接客户反馈，而非生产事件。

## 已知的约束条件
测试版将在六周后发布。没有预算聘请专门的日历同步供应商。

## 明确超出范围的内容
任何客户日历的双向同步或写入权限。本次发布仅限只读叠加层。

从这个意图文档撰写的规格说明将明确技术形态：首先支持哪些日历提供商、叠加层如何处理时区冲突、以及当提供商 API 不可用时会发生什么。请注意 Build 阶段几乎不需要进行任何解释。这正是在接触设计文档甚至代码之前就写下意图的全部意义。

每个工具都提供了不同的机制来处理这个阶段，防止代理直接跳到代码编写。Claude Code 的 Plan 模式专为此场景设计：这是一个专用的只读权限模式，代理可以研究代码库并提出方案，但必须切换出此模式（通过 Shift+Tab（Anthropic））后才能编辑文件或运行命令。

Codex 将相同的理念拆分为两个独立的设置，而不是通过一个模式切换来实现：一个沙盒设置，用于控制代理在技术上能够接触的范围（只读、工作区写入或危险全访问）；以及一个审批策略，用于控制代理何时需要停止并请求确认（不信任、按需或从不）（OpenAI）。

在 Plan 阶段将沙盒设置为只读模式，可以得到与 Claude Code 的 Plan 模式相同的保证，但执行层级不同。Gemini CLI 有一个与只读意图相同的计划审批模式，但 Google 官方文档指出该模式与其他审批模式相比仍处于成熟过程中（Google），因此在验证其行为与您自己的代码库匹配之前，应将其视为方向性参考而非硬性保证。

无论使用哪种工具运行 Plan 阶段会话，输出结果都应包含填写完整的 intent.md 文件，以及一段简短的对话确认代理对问题的总结与请求者的意图一致。该确认步骤就是前面部分提醒你注意的阶段中需要人工参与的部分，当代理的总结看起来已经正确时，人们很容易跳过这一步。由于代理快速生成看似合理的总结而跳过确认，正是瓶颈转移论预测的失败模式：快速、自信但错误。

如何执行设计阶段

设计阶段是将 intent.md 转换为 spec.md 的过程，spec.md 是一份定义解决方案技术形态、涉及的接口以及在代理开始编写实现代码前需要签署权衡的文档。

Anthropic 的框架将该阶段描述为“需求与设计合并为一个会话”的过程（Anthropic），这与传统流程中产品规格和技术设计文档通常由不同人员在不同日期编写，并通过中间会议协调的模式形成显著差异。

一个有用的 spec.md 模板会明确体现这种合并而非偶然发生：

# spec.md

## 来源
指向该规格所回答的 intent.md 的链接。

## 方案
技术方案的平实描述：哪些系统会改变，哪些保持不变，以及为何选择该方案而非显而易见的替代方案。

## 受影响的接口
API 端点、数据库模式、公共函数签名。任何其他团队或服务依赖的内容。

## 开放性顾虑
代理或作者不确定的任何内容。该部分的存在目的就是将不确定性明确写下来，而不是通过最容易实现的选择悄悄解决。

## 明确被拒绝的替代方案
考虑过的其他方案及其被放弃的原因。这正是防止六个月后其他人重新争论决策的关键所在。

## 审批
谁在何时审查了该文档。

“开放性顾虑”和“明确被拒绝的替代方案”这两个部分承担着关键作用。当要求代理生成设计文档时，代理默认会将其选择的方案呈现为显而易见。此时人类审核者的任务虽然范围狭窄但非常具体：优先阅读这两个部分，因为错误假设更可能隐藏在这里，而非代理最自信的文档部分。

所有三种工具都以相同的方式支持这一阶段，就像它们支持“计划”阶段一样：在规范草案编写期间，将会话保持在只读或计划模式下，然后在人类阅读完“开放问题”部分并解决或明确接受每个项目后，切换到仅能写入文件的模式。实现机制有所不同（Claude Code 的计划模式、Codex 的只读沙盒、Gemini CLI 的计划审批模式），但三者在规范上完全一致：在有人审查完开放问题之前，不会根据规范实施任何内容。

在构建流程时需要注意的一个实用建议是：将规范与代码一同版本化，就像你会将模型卡与它描述的模型一同版本化一样。仅存在于聊天记录中的 spec.md 不是可追溯的产物。将 spec.md 提交到仓库中，并与它描述的实现位于同一拉取请求中，这样你的测试和部署阶段后续可以引用它。

如何运行构建阶段

构建阶段是每个人都已经与智能体编码工具关联的阶段，同时在这个框架中，构建阶段的变化最小，因为这些工具本身已经设计得能够很好地完成这一部分工作。

变化的是，构建阶段现在从已批准的 plan.md 运行，而不是从临时提示运行，这正是让快速智能体保持正确目标方向的关键所在，而不是被有趣但错误的目标分散。

plan.md 会指定将要修改的具体文件、变更顺序以及验证每个变更的测试：

# plan.md

## 来源
链接到此计划所实现的 spec.md。

## 按顺序修改的文件
1. `src/models/user.py`：添加 `last_login_at` 字段
2. `src/api/auth.py`：更新登录处理器以设置新字段
3. `tests/test_auth.py`：为新字段添加覆盖率
4. `migrations/0042_add_last_login.py`：模式迁移

## 在计划被视为完成之前必须通过的测试
- 现有的认证测试套件，未修改的测试仍保持绿色
- 新增测试：登录时将 last_login_at 设置为当前 UTC 时间戳
- 新增测试：从未登录过的用户的 last_login_at 为 null

## 回滚
如果此功能发布后出现故障，回滚方式为：执行一次迁移降级步骤，并通过 git revert 回退三个代码变更，无需数据回填。

每个工具在接触这些内容之前读取的内存文件决定了智能体如何编写代码，而不仅仅是计划本身。仓库根目录下的 CLAUDE.md 可能如下所示：

# CLAUDE.md

## 命令
- 运行测试：`pytest tests/ -x -q`
- 运行代码检查：`ruff check src/`
- 启动本地服务器：`python manage.py runserver`

## 代码库结构
Django 单体应用。业务逻辑位于 `src/services/`，而不是视图或模型中。视图调用服务，服务调用模型。不要在视图中直接放置业务逻辑。

## 标准
- 所有新 API 端点都需要在 `openapi.yaml` 中有对应的条目
- 数据库迁移每个文件只变更一次，绝不打包
- 新增依赖项必须在 `docs/decisions/` 中有对应记录

## 测试覆盖率
`src/services/` 中每个新函数都需要在 `tests/services/` 中有对应的测试。覆盖率低于 85% 会导致 CI 失败。

如果您的项目已经标准化为 AGENTS.md，因为它是一种跨供应商格式，那么上面的文件几乎可以直接移植：结构相同、内容相同、仅文件名不同，Codex 会自动读取它，当它从 Codex 主目录遍历到您的项目根目录（OpenAI）时。

GEMINI.md 文件的版本内容相同，Gemini CLI 会将其与全局的 ~/.gemini/GEMINI.md 文件以及在子目录层级中找到的文件进行拼接，因此单体仓库可以将公司级规范文件与按服务划分的覆盖文件进行分层（Google）。

无论您提交的是哪个文件名，内容（命令、架构、规范、测试规则）才是决定代理输出结果是否符合您的代码库风格还是通用教程风格的关键因素。

在单个内存文件之外实现可重用行为时，这三种工具的差异更加明显。Claude Code 将其分为两种机制：Subagents（子代理），它们在自己的上下文窗口中运行，并通过受限的工具访问执行特定任务（如“审查此差异以查找SQL注入”）；以及 Skills（技能），基于文件夹的包，当Claude认为相关时会自动调用，这些技能吸收了之前自定义的斜杠命令（Anthropic, Anthropic）。

Codex 正在向这一理念迁移：其较旧的自定义提示机制现已明确弃用，取而代之的是 Skills，Codex 可以隐式调用 Skills 并通过仓库在团队中共享（OpenAI）。

Gemini CLI 采取了最广泛的方案，将提示、MCP 服务器、自定义斜杠命令、钩子和子代理打包成一个可安装的扩展，而不是将每种机制作为单独配置的功能（Google）。

这三种方案没有绝对优劣。Claude Code 和 Codex 提供了更精细的控制，可以明确指定每种机制的功能。Gemini CLI 提供了一个统一的安装包，这对团队来说很重要，因为当团队的问题是让五位工程师遵循相同规范时，管理五个独立配置的功能容易导致规范偏离。

这三种工具都通过模型上下文协议（Model Context Protocol）连接到外部系统、数据库、工单跟踪工具和设计工具。该协议由 Anthropic 创建并作为 Claude Code 的原生、一级功能开源（Anthropic），此后已成为真正的跨厂商标准。Codex 通过自己的 MCP 客户端支持该协议，Gemini CLI 则通过 OAuth 2.0 支持远程服务器。

由于所有三种工具现在都支持 MCP，因此应将其视为需要为每个项目配置一次的基础设施，而非特定工具的功能。

如何运行测试阶段

Anthropic 将这一阶段描述为“持续评估贯穿实现过程”（Anthropic），这与传统模型中测试作为构建完成后才开始的阶段形成鲜明对比。

当代理可以在几分钟内生成差异时，等待单独的测试阶段会导致测试队列的增长速度超过任何团队的审查能力。解决方案是将验证作为代理生成的每个提交的属性，而非依赖人类记住后续运行的门禁。

这也是 DORA 报告中不太令人满意的发现变得相关的地方：在 90% 的采用率数字背后，大约三分之一的开发者仍表示对 AI 生成的代码缺乏信任（DORA）。当测试是作为快速构建阶段后附加的独立阶段时，这种不信任是合理的，因为没有人验证代码时却需要信任它。但一旦验证在每次提交时自动运行，而不是等待人类安排，这个问题就变成了可解决的工程问题，而非持续的风险。

Claude Code 通过钩子（Hooks）实现这一功能：在特定生命周期事件（如代理在编辑文件或运行命令前后）自动触发的 shell 命令（Anthropic）。在 .claude/settings.json 中，一个在每次文件编辑后运行测试套件并阻止代理在失败时继续执行的钩子配置如下：

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

• PostToolUse 在代理完成 Edit 或 Write 工具调用后触发钩子，而非之前，因此检查的是磁盘上的实际变更。

• pytest -x 会在首次失败时停止，使反馈循环更短，而不是输出需要代理解析的完整失败报告。

• 如果该命令返回阻塞退出码，代理将无法继续执行 plan.md 中计划的下个文件，直到测试套件重新通过。

Codex 和 Gemini CLI 并未提供与 Claude Code 同样成熟度的通用本地钩子框架（如果你已经习惯在自己的笔记本电脑上中途停止代理会话，这会是一个明显缺失的功能）。这并非功能缺失，而是流程中的不同环节：这两款工具主要围绕 CI 构建持续验证方案，而非本地生命周期事件系统，因此 Codex 和 Gemini CLI 的 /review 以及 PR 触发的审查产品（见下文 Deploy 部分）会在代码变更到达 Pull Request 时捕获相同类型的问题。

如果你目前在本地使用 Codex 或 Gemini CLI，实际替代方案是通过 Git 本身配置一个 pre-commit 钩子，调用与 Claude Code 钩子相同的测试命令。这在工具链的不同层级提供了大部分相同的功能保证。

无论使用何种工具，该阶段应留下的成果是：与 plan.md 中特定提交关联的测试结果，这样三阶段后的审查者可以看到是哪个测试验证了哪个主张，而非仅仅依赖可能验证上周代码的绿色对勾。

如何执行部署阶段

Anthropic 将这一阶段描述为“多层智能审查体系，将人工审查保留给受监管和关键代码”，其中“治理规则在 AI 执行过程中强制实施，钩子作为审批关卡”（Anthropic）。

“多层”这一表述是准确的：框架并未提议用智能审查取代人工审查，而是建议将自动化审查作为更早、成本更低的层级叠加，使人工审查聚焦于通过自动化审查的发现，而非从零开始检查所有内容。

目前三家供应商均提供官方 GitHub Action，无需从零构建 CI 集成。Claude Code 的 anthropics/claude-code-action 可响应 PR 或 issue 中的 @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: "Review this diff against spec.md and plan.md for this PR."

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: "review this diff against the linked spec.md and flag P0/P1 issues"

Gemini 的 google-github-actions/run-gemini-cli 在相同 PR 和 issue 事件中触发，通过完整项目上下文异步运行，而非同步阻塞检查（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: "Review this pull request for correctness, efficiency, and maintainability."

除原始 CI 动作外，每个供应商都提供专用代码审查产品及独立配置界面。Claude Code 的 Code Review 是托管服务，可并行运行多个专用代理分析差异。它包含独立验证步骤，在任何人工内联 PR 评论（通过 @claude review 或本地 /code-review 命令触发）前过滤误报（Anthropic）。

Codex 的审查界面包括 CLI 组合器的 /review 命令、GitHub PR 中的 @codex review 提及，或"自动审查"设置（在每个新 PR 上自动触发，无需提及）。GitHub 模式下，其刻意限制仅标记最严重的 P0/P1 问题，而非所有风格性细节（OpenAI）。

与其他两者不同，GitHub 的 Gemini Code Assist 主要通过提交的 .gemini/config.yaml 文件配置，这与管理构建的内存文件是独立的配置界面。它会发布包含摘要评论和五个审查维度（正确性、效率、可维护性、安全性及涵盖测试、可扩展性和错误日志的杂项）的内联评论（Google）。

人工审核环节应位于这些自动化层向人工交接的位置，该交接点应取决于变更的影响范围，而非统一规则。数据库迁移、认证流程或涉及支付的任何变更都应需要人工批准，即使自动化审查看起来完美无缺。

文档修复或配置值升级且通过所有自动化层的变更，是自动合并的合理候选。Anthropic 将差异本身视为审计轨迹的一部分："提交记录链也是审计轨迹：谁申请了什么，代理生成了什么，以及谁批准了它"（Anthropic）。

这是有用的思维模型：当代理停止编写代码时，差异并未完成。差异在积累足够的人工审查证据以支持快速、知情的批准决策时才完成。

如何运行维护阶段

Maintain 是赋予基于制品开发名称的阶段，因为这就是闭环形成的地方。Anthropic 将其描述为“代理监控实时部署。任何被突破的控制带都会被诊断，并作为新的意图写回循环中。”（Anthropic）

没有这个回写步骤，Maintain 只是监控，与团队过去十年运行的仪表板没有区别。有了它，生产事故会直接成为下一次 Plan 阶段会议的输入，而不是被阅读一次后归档的事故复盘文档。

一种实用的编码方式是采用 bands 风格的配置，定义指标的可接受范围以及突破范围时的处理方式：

# 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

• 每个指标都有一个 bands（可接受范围），而不是单一阈值，这使您能同样轻松地捕捉到指标值过低或过高的情况。

• write_intent: true 是将突破自动转化为新 Plan 阶段循环启动机制，生成一个草案 intent.md，标注被突破的指标、服务并链接到事故。

• 并非所有突破都应该开启新意图。低优先级服务的每日活跃用户下降可能需要为了可见性开启事故，但不需要启动新的规划工作，这就是为什么该标志是显式而非隐式设置的。

代理接收到页面或提及的位置在这里至关重要：这是三个工具不等价的唯一场景。Claude Tag 为组织在 Slack 中提供一个共享的 @Claude 身份，异步地在频道中工作，并将提及的编码任务路由到网页版 Claude Code。这使得“有人在事故频道中用失败指标提及机器人”成为开箱即用的 Maintain 阶段模式。（Anthropic）

OpenAI 提供了直接等价方案：官方 Codex Slack 应用，当在频道或线程中提及 @Codex 时，会创建云任务，在相关仓库中工作，并将结果发布回原提及线程中。（Slack）

如上所述，目前尚无 Google 的第一方等价方案；目前只能通过第三方和社区构建的桥梁连接 Gemini CLI 与 Slack。基于 Gemini 的 Maintain 阶段实际解决方案是通过现有值班 paging 工具的 webhook 路由自动化，而不是等待聊天提及（在事故处理中需要时提前设置好比临时寻找不存在的机器人更有效）。

从一次突破到下一个规划周期，追踪整个回写机制，其流程如图所示：

图3：以封闭回路形式绘制的一向流水线。从左到右、从上到下，intent.md 生成 spec.md，spec.md 生成 plan.md，plan.md 驱动代理构建，构建结果流入自动化测试和评审关卡，随后进入部署阶段，最后进入监控阶段。虚线蓝色的返回箭头标注为"触发下一次循环"，这是大多数团队流程中缺失的关键环节：它将监控异常直接反馈至新生成的 intent.md，形成闭环而非在部署阶段终止，这与传统流水线图示的终点设计形成对比。

上述图表集中体现了本节所有内容的价值：它追踪了 bands.yaml 中的单个违规项如何通过 open_incident 进入事件记录，再生成新的 intent.md，最终返回至本指南最初启动的计划阶段。从"维护"阶段返回"计划"阶段的那条箭头，正是当前大多数工程团队流程中缺失的关键环节，即使是那些在构建阶段已采用智能编码工具的团队也是如此。

在未构建这条反馈箭头的情况下单纯购买快速代理工具，你只能获得快速代码（以及与所有团队目前拥有的相同缓慢人工事件到路线图流程）。正是这条箭头让六个阶段形成循环，而非六个并列的独立改进环节。

一位工程师如何覆盖五人团队的工作

以上所有内容都假设团队规模足够大，能够配备专职的计划人员、评审人员、发布管理人员和值班人员。但越来越多阅读本文的工程师并不具备这样的团队配置。

GitHub 2025 年 Octoverse 报告发现，近 80% 的 GitHub 新用户在加入后的第一周内使用了 Copilot，这表明 AI 辅助开发正逐渐成为新工程师职业发展的默认起点，而非建立在多年经验之上的高级技术（GitHub）。结合 Stack Overflow 的发现——约一半的专业开发者已每天使用 AI 工具（Stack Overflow）——认真考虑使用该技术栈启动单人或双人初创公司的工程师已不再是边缘案例，这几乎就是新开发者群体的中位数。

当一个人或创始团队独自运行所有六个阶段时，这些阶段的具体表现形式如下：以一位独立工程师开发自由职业者日程管理工具为例，目标是在六周内发布付费测试版。

计划阶段：

计划阶段取代了产品经理将客户对话转化为规格说明的工作。创始人与三位自由职业者讨论现有日程工具为何令人沮丧，将原始笔记粘贴到 intent.md 中，然后运行计划模式会话，将三个零散的对话转化为一个明确的问题陈述：自由职业者需要在不授予每个客户平台管理员权限给其他客户的情况下，查看所有客户日历的叠加视图。

这个15分钟的会话取代了两人团队在客户访谈和需求文档上花费一周时间的工作量。

设计阶段：

设计取代了架构师的白板会议。同样的会议仍以只读模式进行，最终生成 spec.md：一个日历叠加服务，针对每个客户端的日历提供商实现 OAuth 认证，提供统一视图，并明确拒绝实时同步方案，转而采用每五分钟轮询间隔（因为实时同步最可能耽误六周截止期限）。在 spec 中明确写入“因时间线原因明确拒绝实时同步”这一条，正是防止创始人在第五周因压力重新讨论该决策的关键。

构建阶段：

构建取代了完整的工程团队。plan.md 按顺序定义了日历集成、认证流程和统一视图组件后，智能编码工具会根据 CLAUDE.md（或 AGENTS.md、GEMINI.md）中编码的栈决策（如日历库选择、认证模式、业务逻辑位置）逐一实现每个模块。每位读者都已预料到这一部分会进展迅速。Beta 版是否按时发布，取决于其外围部分的执行情况。

测试阶段：

测试取代了 QA 工程师。由于每次文件修改后都会触发测试套件运行，创始人无需在演示前夜调试一周未测试的智能体输出。在构建开始前就将测试标准写入 plan.md 的纪律性，正是专职 QA 工程师会坚持的准则。

部署阶段：

部署取代了发布经理。GitHub Action 对每个 Pull Request 运行自动化代码审查，对涉及 OAuth 流程或计费的变更设置人工审核关卡，使创始人无需额外工程师配合即可获得 Anthropic 框架描述的多层审查机制。涉及资金或凭证的代码变更，创始人仍会亲自逐行审阅。

维护阶段：

维护取代了 SRE 值班轮换。bands.yaml 监控 API 错误率和轮询任务成功率，直接通过手机推送告警而非共享值班工具，构成了该规模公司的完整事件响应体系。当凌晨 2 点轮询任务错误率突破阈值时，生成的事件记录会成为下周第一个 intent.md，而非创始人到周一只能模糊回忆的 bug。

判断力的重要性与以往无异。消失的是过去需要团队协作的协调成本：现在提交的文件明确记录了过去需要专家团队在各自头脑中隐性承载的内容。

这就是采用原生 AI 开发流程（SDLC）的论据：以制品驱动的开发方式，使一个人的专业能力能覆盖过去需要分摊到多人职位上的工作范围。

全面采用原生智能体 AI 开发流程前的预检清单

在重构团队工作流之前，请按阶段完成以下检查项：

计划与设计阶段

• [ ] 仓库中已存在 intent.md 模板，所有新工作均从填写完整的模板开始
• [ ] 存在包含"开放问题"章节的 spec.md 模板，构建前需人工阅读该章节
• [ ] 在需求转化为 spec 前，至少有除请求者外的另一人确认智能体对意图的总结

构建阶段

• [ ] 存在内存文件（CLAUDE.md、AGENTS.md 或 GEMINI.md），已提交到版本控制，用于命名命令、架构和规范，而非仅作为占位符文本。

• [ ] plan.md 在开发开始前明确命名具体文件、变更顺序和测试内容。

测试

• [ ] 钩子（hook）、预提交检查或等效的本地门禁会自动运行测试套件，并在测试失败时阻止流程继续。

• [ ] 测试结果会与验证它的具体提交关联，而非仅在聊天中报告通过或失败。

部署

• [ ] 每个拉取请求都会触发第一方 CI 动作（Claude Code、Codex 或 Gemini）运行自动化代码审查。

• [ ] 对于涉及身份验证、支付、数据迁移或基础设施的变更，无论自动化审查结果如何，都必须显式获得人工批准。

• [ ] 如果启用自动合并，其范围应限定在特定的低风险类别，而非默认所有绿色检查都自动合并。

维护

• [ ] 监控配置会为业务关键指标定义可接受的范围，而非平台暴露的每个指标。

• [ ] 至少最高严重级别的违规类别会自动草拟新的 intent.md，形成从计划阶段到实施阶段的闭环。

• [ ] 即使是负责执行其他阶段的同一个人，也需对本阶段生成的事件进行阅读和处理。

结论

你现在已具备围绕智能体编码工具重构软件团队生命周期的思维模型，并掌握了三个具体实施方案。六个阶段（Plan、Design、Build、Test、Deploy、Maintain）的名称保持不变，变化的是每个阶段产出的成果及其对应的工具。

• intent.md 在任何解释发生前（无论是 Claude Code 的 Plan 模式、Codex 的只读沙盒还是 Gemini CLI 的计划审批模式）都已捕获问题。

• spec.md 和 plan.md 通过为智能体提供已由人工审查的目标，将它的速度转化为资产而非负担。

• 钩子、CI 动作和原生代码审查产品用持续验证取代了测试阶段，将验证过程编织到每个提交中，而非在最后附加。

• 分层审查将人类判断置于最有价值的位置：在可能造成大规模影响的变更门禁处，而非每个差异的每一行代码处。

• 带有指标范围的监控配置形成闭环，将生产事件直接转化为下一个周期的 intent.md，而非无人重新开启的事故复盘。

本指南所有阶段的共同主线与 METR 的任务翻倍曲线最初暗示的一致：软件交付速度的限制已发生变化，无论你的流程是否跟上。继续将 Build 视为瓶颈的团队，将持续优化那个已不再是问题的阶段。

下一步探索方向

• Anthropic 的 AI 原生 SDLC 操作手册，本指南所实现的六阶段框架的原始资料

• DORA 的《2025 年 AI 辅助软件开发现状报告》，提供开篇钩子所依赖的采用率和信任数据

• METR 关于 AI 任务长度翻倍的研究，提供七个月翻倍曲线的完整方法论

• Claude Code 的文档中心，从内存文件页面开始，扩展到权限模式、钩子和子代理等主题

• OpenAI Codex 关于代理审批和安全性的文档，了解沙箱与审批策略分离的完整细节

• Gemini CLI 的配置参考，了解其当前审批模式和扩展系统的最新状态

访问我的 GitHub，探索我使用原生智能体AI工程流程构建并分享的 30+ 开源软件解决方案和开发者工具

我是应用AI/机器学习和营销测量科学领域的领导者，拥有15年以上在财富500强企业构建和扩展应用AI及机器学习产品的经验。我专注于因果推理、实验设计、智能体AI系统和企业级AI战略，应用场景涵盖零售媒体网络（RMN）、广告、广告技术、营销技术、消费品（CPG）和电子商务领域。我是Springer Nature、Elsevier、ICML（顶级AI/机器学习会议）和IEEE的出版作者，也是多家领先AI/机器学习和分析出版物的常驻撰稿人（个人观点）

如果这篇文章对你有帮助，请分享它

免费学习编程。freeCodeCamp 的开源课程已帮助超过40,000人成为开发者。立即开始

ADVERTISEMENT