← 返回
IT技术

实践中的能动 AI 工程：AI 工程师与前置部署工程师如何使用 Claude Code、Codex 和 G 进行构建

✍️ zhirenhun 📅 2026/9/6 👁 158 阅读 ⏱ 76 分钟
实践中的能动 AI 工程：AI 工程师与前置部署工程师如何使用 Claude Code、Codex 和 G 进行构建

一份实用的三工具指南，面向 AI 原生软件开发生命周期（SDLC）：规划、设计、构建、测试、部署、维护，针对 Agentic 编码重新构想。

2025 年 3 月，一个名为 METR 的小型非营利研究小组发布了一张图表，令许多工程领导者比平时更加坐直。

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

这一曲线并不是指自动完成功能略有改进：而是指代理从“完成一个函数”跨越到“完成一个特性”，并在当前趋势下迈向“完成一个冲刺”。

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

Stack Overflow 2025 年开发者调查给出了类似的习惯使用数据：84% 的开发者现在使用或计划使用 AI 工具，较去年的 76% 有所提升，约有一半的专业开发者每天会使用一次（Stack Overflow）。

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

这种不匹配正是本文的主题。Anthropic 的 Applied AI 团队在 2026 年发布了一套名为 AI 原生 SDLC 的框架，围绕一个核心观察：当代理编写和修改代码的速度超过人类审查拉取请求的速度时，软件交付的瓶颈并不会消失，而只是转移位置（Anthropic）。

本指南将逐阶段（规划、设计、构建、测试、部署、维护）讲解该框架，并展示如何使用您可获得的任意 Agentic 编码工具（Claude Code、OpenAI Codex 或 Gemini CLI）实现每个阶段。您将看到三种工具的配置文件、Markdown 工件模板以及 CI 工作流，此外还有一个实际示例，说明单个前线部署的工程师如何利用这一模式来承担以前需要五人团队才能完成的工作。

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

目录

先决条件

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

安装您计划使用的任意工具：

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

下面看看三者各自提供了什么：

你不需要三个都用。选公司已经付费的那一个，或者免费额度足以满足项目需求的那一个，然后在指南的后续内容中沿着对应的列走下去即可。

什么是 AI 原生的 SDLC？

下图展示了六个阶段如何连接成一个连续的系统，而不是一系列孤立的步骤。后续章节会解释每个阶段如何把一份有分量的具名交付物传递给下一阶段，而最后一个阶段会直接回到起点形成闭环，而非止步于部署。

这张图是关于软件开发生命周期（SDLC）的流程图，包括计划、设计、开发、测试、部署和维护六个阶段

图 1：AI 原生软件开发生命周期（SDLC）被画成一个封闭的六边形循环，而非一条直线流水线。六个阶段——规划、设计、构建、测试、部署、维护——沿外圈顺时针排列。每个阶段传递给下一阶段的交付物（intent.md、spec.md、plan.md，外加代码和测试结果、review.md、bands.yaml）位于循环内部，紧挨着它所经过的箭头。最值得留意的细节是从维护指回规划的那支双线箭头：正是它把六个独立阶段变成了一个自我触发的循环，而不是六个恰好挨在一起的改进项。

沿着箭头走一遍：

传统的 SDLC 图通常画成瀑布式或水平流水线。这张图之所以画成圆环，是因为它的核心思想就是让运营数据自动成为下一轮规划的输入，而不是躺在无人问津的仪表盘里，直到下一次外出规划会才被翻出来。

工程师们围绕一个成立五十年的假设构建了传统的六阶段软件开发生命周期——计划、设计、构建、测试、部署和维护：编写和实现代码是整个过程中最昂贵、最耗时的部分。

Anthropic 的 Applied AI 团队在 2026 年发布其 AI 原生 SDLC 框架时明确命名了这一假设，并围绕该假设不再成立时会发生什么构建了整个模型（Anthropic）。该框架保留了软件工程师已经熟知的相同六个阶段名称。不同之处在于每个阶段如何产生和消费工作。

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

Anthropic 的原话很好地捕捉了设计意图：

"每个阶段都会提交一个下一个阶段可以读取的工件。意图、规格、计划、差异和审查结果共同构成了审计轨迹。" (Anthropic)

除了合规之外，该审计轨迹还有其他重要意义。当代理能够在几分钟内生成可工作的 diff 时，软件是否优秀取决于其所依据的计划是否良好，以及在交付前是否有人根据需求检查了其输出。

工件使得这种检查成为可能，且不会减慢代理的速度：一份规格文档审阅只需十分钟，可以被缓存、重复使用，并且像代码一样进行差异比较。口头交接则无法做到这一点。

代码变得廉价后瓶颈转移的位置

Anthropic 将其框架中相关章节命名为 "代码不再是瓶颈"，然后在接下来的一行解释原因：

"组织已经开始使用 AI 以一年前难以想象的速度编写代码，但围绕代码的流程并没有以同样的速度变化。" (Anthropic)

这个观察值得慢慢梳理，因为它是框架中改变你如何安排一天的部分，而不仅仅是你购买的工具。下面的图表对这种在冲刺日历时间中的重新分配进行了量化。

图 2：两个堆叠的时间线，绘制为相同的总宽度，展示了冲刺日历时间如何被重新分配。顶部条形图代表传统 SDLC，将时间划分为六个大致相等的段落。底部条形图代表 AI 原生 SDLC，保持 Plan、Design 和 Deploy 宽度不变（标注为“保持人类节奏”）而 Build 和 Test 被压缩成更细的斜条（标注为“压缩至小时”）。两个条形图故意保持相同的总长度：重点不是一切都变得更快。而是以前用于 Build 的时间现在必须去其他地方，而那个地方是 Plan 和 Review。

上图展示了传统 SDLC 与 AI 原生 SDLC 的时间分配对比。在传统模型中，Build 条形图主导了图表：冲刺日历时间的大部分用于编写和调试代码，而 Plan、Test 和 Deploy 相比之下较窄。在 AI 原生版本中，Build 缩减为一条细斜条，代理能够在以前安排启动会议所需的时间内生成一个可工作的实现，而 Plan、测试/评审 和 Deploy 的条形图则扩展以填补 Build 曾经占据的空间。图表的总宽度几乎没有变化。变化的是哪些阶段现在承担了限速工作。

Anthropic 的框架也指出了同样的三个阶段：

"瓶颈转移到了构建阶段左右的步骤。这主要是计划、评审/测试 和部署，它们仍然以人类速度运行。" (Anthropic)

这是一个具体且可证伪的主张，值得认真对待，而不是当作口号轻易否定。构建阶段的速度提升会以三种具体且可避免的方式破裂：

这里的论点是，围绕代理的阶段（而非代理本身）是 AI 原生 SDLC 获得其名称的地方。具备代理能力的编码工具并不是问题。本指南的其余部分将 Plan、Design、Test、Deploy 和 Maintain 与团队历史上为 Build 保留的同样工程严谨性相对待，因为约束现在就在这里。

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）
可重用的提示/扩展系统 Subagents（拥有自己的上下文窗口，受限工具）加上 Skills，基于文件夹并自动调用（Anthropic，Anthropic） Skills，取代了现在已被弃用的自定义提示词。
MCP 服务器独立处理外部工具访问。(OpenAI) 扩展将提示、MCP 服务器、斜杠命令、钩子和子代理打包成一个可安装的单元 (Google) Approval/sandbox model 权限模式：手动、自动和计划模式，可通过 Shift+Tab 切换 (Anthropic) 两个独立的轴：沙箱模式（只读、工作区写入、完全危险访问）和审批策略（不受信任、按需、永不） (OpenAI) 审批模式：默认、auto_edit、yolo (--yolo 或 Ctrl+Y)，以及仍在成熟中的计划模式 (Google) 第一方 CI 操作 anthropics/claude-code-action，由 @claude 提及或计划事件触发 (Anthropic) openai/codex-action 在 CI 作业内运行 codex exec，可应用补丁或发布评论 (OpenAI) google-github-actions/run-gemini-cli，由 PR 和议题事件触发 (Google) 原生 PR 代码审查 代码审查：一个托管的多代理服务，带有本地 /code-review 命令和带严重性标签的内联注释 (Anthropic) /review 在 CLI 中，@codex review 在 GitHub 上，或启用 “自动审查” 设置，以在每个新 PR 上标记 P0/P1 问题 (OpenAI) 面向 GitHub 的 Gemini Code Assist，可通过已检入的 .gemini/config.yaml 文件在五个审查维度上进行配置 (Google) 始终在线的聊天界面 Slack 中的 Claude 标签，是一个共享的组织身份，用于将编码意图路由到网页上的 Claude Code (Anthropic) 官方 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

## Requested by
Name, role, date

## What they said
Paste the raw request. Do not clean it up yet. If it came from a support
ticket, a Slack thread, or an incident, link it.

## What problem this solves
One or two sentences, written after the raw request above, translating it
into a problem statement. This is the first place interpretation is allowed.

## Why now
What triggered this request. If it came out of an incident, name the
incident record it traces back to.

## Constraints already known
Anything the requester specified: deadline, budget, systems that cannot
change, regulatory requirement.

## Explicitly out of scope
What this request does not include, stated as what it does.

以下是正在发生的情况：

填写请求时，同样的模板仍然保持如此简短：

# intent.md

## Requested by
Maria, independent contractor and beta user, 2026-08-14

## What they said
"I have to check four different calendars every morning before I can tell
a client when I'm free. I've double-booked myself twice this month."

## What problem this solves
Contractors working across multiple clients cannot see a unified view of
their own availability without giving each client's calendar system
access to the others.

## Why now
Direct customer feedback during the private beta, not a production
incident.

## Constraints already known
Beta ships in six weeks. No budget for a dedicated calendar-sync vendor.

## Explicitly out of scope
Two-way sync or write access to any client's calendar. Read-only overlay only, for this release.

基于此意图编写的规格将明确技术形状：首先支持哪些日历提供者，叠加层如何处理冲突的时区，以及当提供者的 API 不可用时会发生什么。你会发现，留给 Build 进行即兴发挥的解释空间非常小。这就是在触碰设计文档之前（更不用说代码了）先写下意图的全部目的。

每种工具都提供不同的机制来完成这一阶段，而不会让代理直接跳到编码。Claude Code 的 Plan 模式是一个专门的、只读权限模式，专为这种场景构建：代理可以研究代码库并提出方案，但在你切换出该模式之前（通过 Shift+Tab 切换），它不能编辑文件或运行命令（Anthropic）。

Codex 将同样的想法分为两个独立的设置，而不是一个模式切换：一个沙盒设置控制代理在技术上能够触及的内容（只读、工作区写入或完全危险访问），以及一个批准策略控制何时需要停止并询问（不受信任、按需或从不）（OpenAI）。

在 Plan 期间将沙盒设置为只读，可以获得与 Claude Code 的 Plan 模式相同的保证，只不过是在不同的层面上强制执行。Gemini CLI 具有一个 plan 批准模式，具有相同的只读意图，尽管 Google 自身的文档指出它相对于其他批准模式仍在成熟阶段（Google），因此在你根据自己的仓库验证其行为之前，应将其视为方向性参考而非硬性保证。

无论使用哪种工具运行 Plan 阶段，其输出应为已填写的 intent.md 以及一次简短的往返，以确认代理对问题的总结符合请求者的意图。这一确认步骤是前一节警告过的该阶段的人速部分，当代理的总结已经听起来正确时，很容易想要跳过它。由于代理快速产生了听起来合理的总结而跳过这一步，正是瓶颈转移论点预测的失败模式：快速、自信，但错误。

如何运行设计阶段

设计阶段是指 intent.md 变为 spec.md 的过程，该文件命名了解决方案的技术形状、所涉及的接口，以及在代理开始编写实现代码之前必须有人签 off 的权衡。

Anthropic 的框架将这一阶段描述为“需求和设计融入同一次会议”（Anthropic），这相较于传统流程是一种有意义的变革——在传统流程中，产品规格说明和技术设计文档往往由不同的人在几天前分别编写，随后召开会议以求统一。

一个有用的 spec.md 模板能够使这种融合显式化，而非偶然发生：

# spec.md

## Source
Link to the intent.md this spec answers.

## Approach
Plain description of the technical approach: which systems change, which
stay the same, and why this approach over the obvious alternative.

## Interfaces affected
API endpoints, database schemas, public function signatures. Anything
another team or another service depends on.

## Open concerns
Anything the agent or the author is not confident about. This section
exists specifically so uncertainty gets written down instead of quietly
resolved by whichever choice was easiest to implement.

## Explicitly rejected alternatives
What else was considered and why it lost. This is what keeps the next
person from re-litigating a decision six months from now.

## Sign-off
Who reviewed this and on what date.

“开放问题”和“明确拒绝的替代方案”部分在这里发挥作用。当被要求生成设计文档时，代理默认会将其选择的方法呈现为显而易见。在这个阶段，人工审阅者的工作范围窄但具体：首先阅读这两个部分，因为错误的假设更可能隐藏在这里，而不是代理最有信心的文档部分。

三种工具以与支持 Plan 相同的方式支持此阶段：在规格草拟过程中保持会话处于只读或计划式模式，仅在人类阅读了“开放问题”部分并解决或明确接受每个条目后，才切换到可写文件的模式。机制各不相同（Claude Code 的 Plan 模式、Codex 的只读沙盒、Gemini CLI 的计划批准模式），但三种工具的纪律是相同的：在有人审查其开放问题之前，不会从规格中实现任何内容。

一个可实施的建议是将其纳入您的流程：将规格与代码一起进行版本控制，就像您为模型卡和其所记录的模型进行版本控制一样。仅存在于聊天记录中的 spec.md 不是一个制品。提交到仓库中的 spec.md，与其描述的实现位于同一个拉取请求中，这是您的测试和部署阶段以后可以引用的制品。

如何运行构建阶段

构建是大家已经将其与智能体编码工具关联的阶段，也是在这个框架中变化最少的阶段，因为这些工具本来就是为了很好地完成这一部分而构建的。

变化在于，构建现在从批准的 plan.md 运行，而不是从临时提示运行，这使得快速代理能够指向正确的目标，而不是一个有趣但错误的目标。

plan.md 列出将要更改的具体文件、更改发生的顺序以及确认每个更改的测试：

# plan.md

## Source
Link to spec.md this plan implements.

## Files to change, in order
1. `src/models/user.py`: add the `last_login_at` field
2. `src/api/auth.py`: update login handler to set the new field
3. `tests/test_auth.py`: add coverage for the new field
4. `migrations/0042_add_last_login.py`: schema migration

## Tests that must pass before this plan is considered done
- Existing auth test suite, unmodified tests still green
- New test: login sets last_login_at to the current UTC timestamp
- New test: last_login_at is null for a user who has never logged in

## Rollback
How to revert if this ships broken: a single migration down-step and a
git revert of the three code changes, no data backfill required.

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

# CLAUDE.md

## Commands
- Run tests: `pytest tests/ -x -q`
- Run linter: `ruff check src/`
- Start local server: `python manage.py runserver`

## Codebase layout
Django monolith. Business logic lives in `src/services/`, not in views or
models. Views call services; services call models. Do not put business
logic directly in a view.

## Standards
- All new API endpoints require a corresponding entry in `openapi.yaml`
- Database migrations are one change per file, never bundled
- No new dependencies without an entry in `docs/decisions/`

## Test coverage
Every new function in `src/services/` needs a corresponding test in
`tests/services/`. Coverage below 85% fails CI.

如果您的项目已经统一使用 AGENTS.md 作为跨供应商格式，上面的文件几乎就是直接移植：结构相同，内容相同，仅文件名不同，Codex 会在从其主目录逐级向下遍历到项目根目录时自动读取该文件（OpenAI）。

GEMINI.md 版本的内容与此相同，Gemini CLI 会将其与全局的 ~/.gemini/GEMINI.md 以及它发现的任何子目录级文件进行拼接，因而单一仓库可以在公司范围的约定文件之上叠加每个服务的覆盖（Google）。

无论您选择哪种文件名，内容（命令、架构、约定、测试规则）才是决定代理输出是否贴近您的代码库还是仅是通用教程的关键。

可复用的行为超越单个内存文件是三种工具更明显分歧的地方。Claude Code 将其划分为两种机制：Subagents，在独立的上下文窗口中运行且工具访问受限，用于诸如“审查此 diff 以检测 SQL 注入”之类的狭窄任务；以及 Skills，基于文件夹的包，Claude 在相关时会自动调用，它们吸收了以前的自定义斜杠命令（Anthropic，Anthropic）。

Codex 正在就同一理念进行中期迁移：其较旧的自定义提示机制如今被明确标记为已废弃，转而采用 Skills，Codex 可以隐式调用并在仓库中跨团队共享（OpenAI）。

Gemini CLI 在这三种工具中采用了最广泛的做法，将提示、MCP 服务器、自定义斜杠命令、钩子和子代理打包成一个可安装的 Extension，而不是将每种机制保持为独立配置的功能（Google）。

这些方案并没有绝对的优劣之分。Claude Code 和 Codex 提供了更细粒度的控制，让您能够决定各机制的具体职责。Gemini CLI 提供了一个可安装、可共享的完整包，这在团队需要让五位工程师统一约定时尤为重要——如果要同时管理五项各自配置的功能，容易导致偏差。

这三种工具均可通过 Model Context Protocol 连接外部系统、数据库、工单跟踪器和设计工具。该协议由 Anthropic 创建并开源，作为 Claude Code 的原生一等公民部分，现已成为真正的跨供应商标准。Codex 通过其自身的 MCP 客户端提供支持，而 Gemini CLI 则通过 OAuth 2.0 为远程服务器提供支持。

MCP 值得被视为每个项目只需配置一次的基础设施，而非工具特有的功能，正是因为现在所有三种工具都支持它。

如何运行测试阶段

Anthropic 将此阶段描述为“贯穿实施的持续评估”（Anthropic），这与传统模式形成有意的对比——在传统模式中，测试是一个在 Build 完成后才开始的阶段。

当代理能够在几分钟内生成 diff 时，等待单独的测试阶段意味着测试前的队列增长速度会超过任何团队的审查能力。解决办法是将验证作为代理生成的每次提交的属性，而不是人类事后记得运行的门槛。

这也是 DORA 报告中令人不太满意的发现变得相关的阶段：在 90% 的采用率旁边，大约十分之三的开发者仍然表示他们对 AI 生成的代码信任度低（DORA）。当测试是快速 Build 阶段之后才被加上的独立阶段时，这种不信任是合理的——因为在有人需要信任代码之前，尚未有人验证代码。但一旦验证在每次提交时运行，而不是等待人类去安排，它就会变成一个可解决的工程问题，而不是一个持续的风险。

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

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

以下是正在发生的情况：

Codex 和 Gemini CLI 没有像 Claude Code 那样成熟的通用本地钩子框架的文档（如果你已经依赖在自己的笔记本电脑上中途停止代理的话）。这更不是缺失的功能，而是流水线中的一个不同点：两种工具主要围绕 CI 而不是本地生命周期事件系统来构建其持续验证的故事，因此 Codex 和 Gemini CLI 的 /review 以及 PR 触发的审查产品（下文 Deploy 部分会介绍）在 diff 达到拉取请求时会捕捉到同一类问题。

如果你今天在本地运行 Codex 或 Gemini CLI，实际的替代方案是通过 Git 本身连接的 pre-commit 钩子，它会调用 Claude Code 钩子所调用的相同测试命令。这在工具链的不同层面上为你提供了几乎相同的保证。

无论使用哪种工具，此阶段应留下的制品是附加在 plan.md 中它所验证的特定提交上的测试结果，这样三个阶段后的审查者可以看到哪个测试证明了哪个主张，而不是仅仅相信可能在测试上周代码的绿色勾选标记。

如何运行部署阶段

Anthropic 将此阶段描述为 “代理审查的层次，人工审查仅保留用于受监管和关键代码”，其中 “治理是在 AI 行动时通过钩子作为批准门来强制执行的。”（Anthropic）

“layers” 一词确实有效：该框架并不提出用代理审查取代人工审查。它提出将自动化审查作为更早、更便宜的层次进行堆叠，以便人类关注经受自动化审查的发现，而不是从头开始捕获一切。

三家供应商现在都提供了一等 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: "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 和议题事件上触发，在完整项目上下文中异步运行，而非作为同步阻塞检查（谷歌）：

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 是一项托管服务，能够并行运行多个专门的代理来审查 diff。它包含一个独立的验证步骤，在任何内容以内联 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 进行配置，这是一个与管控 Build 的内存文件分离的配置面。它会发布一条汇总评论以及在五个审查维度上的内联评论：正确性、效率、可维护性、安全性，以及一个涵盖测试、可伸缩性和错误日志的杂项汇总项（Google）。

人工审核的切入点应在这些自动化层级交给人工时出现，该点的位置应取决于变更的影响范围，而非一刀切的规则。对数据库迁移、认证流程或涉及支付的任何更改，都应要求人工批准，即便自动审查结果再干净。

通过所有自动化层的文档修改或配置值的微小升级，是自动合并的合适候选。Anthropic 将 diff 本身视为审计轨迹的一部分：“提交链也是审计轨迹：谁提出了什么需求，代理产生了什么内容，以及谁批准了它”（Anthropic）。

这就是有用的心智模型：diff 的完成并不是在代理停止编写代码时，而是在它积累了人类进行快速、明智批准决策所需的审查证据时。

如何运行维护阶段

维护阶段正是制品驱动开发得名之处，因为此时循环闭合。Anthropic 将其描述为：“代理监控实时部署。任何被突破的控制带会被诊断，并以新的 intent.md 写回循环。”（Anthropic）

没有写回这一步，Maintain 只是在监控，和团队十年来一直使用的同一套仪表盘没有区别。有了它，生产事故会直接成为下一次 Plan 阶段会议的输入，而不是只读一次就被搁置的事后报告。

一种实际做法是采用带状配置，定义指标可接受范围以及超出范围时如何处理：

# 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

以下是发生的情况：

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

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

如上所述，目前尚未有第一方的 Google 等价物；只有第三方和社区构建的桥梁将 Gemini CLI 与 Slack 连接起来。对于基于 Gemini 的 Maintain 阶段，实际的解决办法是通过现有的值班呼叫工具的 webhook 进行自动化路由，而不是等待聊天提及（在你陷入事件中并寻找不存在的机器人之前设置这一点是值得的）。

追溯从一次违规到下一个规划周期的完整写回机制，它看起来就像下面的图所示：

这张图是关于artifact-driven feedback loop的技术图表

图 3：单向管道被绘制为一个闭环。从左到右、从上到下阅读， intent.md 喂入 spec.md , spec.md 喂入 plan.md , plan.md 喂入一个代理构建，该构建流入自动化测试和审核门槛，然后是 Deploy，然后是 Monitoring。虚蓝色返回箭头，标记为“触发下一个周期”，是大多数团队流程所缺失的部分：它将监控中的违规直接路由回一个新生成的 intent.md , 而不是在 Deploy 结束时闭合环路，正如传统的管道图所示。

上面的图示是本节全部内容的收获：它追踪了 bands.yaml 中的一次单一违规，经过 open_incident，进入事件记录，进入新生成的 intent.md，并回到本指南开头的计划阶段。从维护回到计划的这条箭头，是当今多数团队工程流程所缺失的一环，即便是已经在构建阶段引入 agentic 编码工具的团队也不例外。

如果在构建阶段只买一个快速的 agent，却不构建这个反馈箭头，你只能得到快速的代码（以及每个团队已经在使用的那种慢速、手动的 incident‑to‑roadmap 流程）。这条箭头才是让六个阶段形成闭环的关键，而不是仅仅相邻存在的六项独立改进。

一名工程师如何应对五人团队

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

GitHub 2025 Octoverse 报告显示，过去一年加入 GitHub 的开发者中，近 80% 在第一周内就使用了 Copilot，这表明 AI 辅助开发正逐渐成为新工程师职业生涯的默认入口，而不仅仅是多年经验后才叠加的高级技巧（GitHub）。

将此与 Stack Overflow 的发现结合起来——大约一半的专业开发者每天都在使用 AI 工具（Stack Overflow）——可以看出，认真考虑使用此技术栈进行 solo 或两人创业的工程师并非小众群体，这几乎是新晋开发者的中位数。

下面通过一个实际例子说明：当一个人或创始二人组负责全部六个阶段时，它们的样子会是怎样的——一名独立工程师为自由承包者构建调度工具，目标是在六周内交付付费测试版。

计划阶段：

计划 取代了产品经理将客户对话转化为规格的工作。创始人与三位承包者交谈，了解现有调度工具让他们感到沮丧的原因，将原始笔记粘贴到 intent.md 中，并进行一次 计划模式 会议，将三段零散的冗长对话汇总为一个问题陈述：承包者需要能够看到所有客户日历的叠加视图，而无需向每个客户授予平台管理员权限。

这十五分钟的会议就能取代一个两人团队在客户访谈和需求文档上花费一周的时间。

设计阶段：

设计 替代了架构师的白板会议。同样的会议仍然处于只读模式，产生 spec.md：日历叠加服务，对每个客户的日历提供方进行 OAuth，单一统一视图，明确拒绝实时同步，而是采用五分钟轮询间隔用于 beta，因为实时同步最可能导致六周截止日期被突破。在 spec 中写入 “明确拒绝：实时同步，因为时间线” 正是阻止创始人在第五周在压力下重新争论该决定的原因。

构建阶段：

构建 替代了完整的工程团队。通过 plan.md 按顺序命名日历集成、认证流程和统一视图组件，一个具备代理能力的编码工具根据 CLAUDE.md（或 AGENTS.md、GEMINI.md) 实现每个部分，其中编码了创始人一次性做出的技术栈决策：使用哪个日历库、哪种认证模式以及业务逻辑放置位置。读这份指南的每个人都已经预期这一步会很快完成。beta 是否能按时交付取决于其周围的部分。

测试阶段：

测试 替代了 QA 工程师。因为一个钩子在每次文件编辑后运行测试套件，创始人无需在演示前一天调试一周未经测试的代理输出。在 Build 开始之前将测试标准写入 plan.md，而不是事后测试，这种纪律正是专职 QA 工程师会坚持的。

部署阶段：

部署 替代了发布经理。GitHub Action 在每个拉取请求上运行自动化代码审查，并在涉及 OAuth 流程或计费的内容上设置人工门禁，使创始人能够获得 Anthropic 框架所述的分层审查，而无需第二位工程师配合。创始人仍会亲自阅读每个涉及金钱或凭据的 diff。

维护阶段：

维护 替代了 SRE 值班轮班。一个 bands.yaml 监控 API 错误率和轮询任务成功率，直接连线到创始人的手机而不是共享的值班工具（没有人轮流使用），这就是该规模公司完整的 incident response 功能。当轮询任务的错误率在凌晨 2 时超出其阈值时，产生的 incident 记录将成为下周的第一个 intent.md，而不是创始人周一只记得一半的 bug。

判断仍然和以前一样重要。消失的是曾经需要团队才能解决的协同开销：提交的文件现在明确记录了之前由专家团队分别隐含地携带的内容。

这就是使用 AI 原生 SDLC 进行引导的论点：制品驱动的开发让一个人的专业知识能够覆盖以前需要多个岗位协作才能完成的工作。

在全面采用 Agentic AI 原生 SDLC 前的飞行检查清单

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

计划与设计

构建

测试

部署

维护

结论

你现在已经掌握了围绕 agentic 编码工具重构软件团队生命周期的可行心智模型，并且还有三种具体的实现方式。六个阶段（Plan、Design、Build、Test、Deploy、Maintain）的名称并未改变，改变的是每个阶段所产出的制品以及生成该制品的工具。

本指南中每个阶段的共同线索与开头所暗示的 METR 任务翻倍曲线相同：限制软件交付速度的因素已经发生变化，无论你的流程是否已经跟上。那些仍然把 Build 视为瓶颈的团队，将继续优化那个已经不再是问题的阶段。

接下来要探索的内容

访问我的 GitHub，以探索我使用 AI 原生代理工程流程构建和共享的 30+ 个开源软件解决方案和开发者工具。

——

🧑‍💻

zhirenhun

一个热爱技术的程序员，喜欢分享前沿AI知识和开发经验。

📌 相关推荐

如何使用 Gemini 和 Vercel 无服务器函数构建 AI 聊天机器人 🚀
2026/9/8
AI 接待员工作原理：AI 电话代理的架构
2026/9/7
使用 OpenTelemetry 实现 Claude Code 可观测性
2026/9/6
← 返回文章列表