AI 原生软件开发生命周期手册 - 如何借助 AI，逐阶段改造软件开发生命周期

AI 原生 SDLC 实战手册

原文｜Anthropic 官方博客

作者｜Louis Claxton

发布日期｜2026 年 8 月 21 日

原文链接｜The AI-Native SDLC Playbook

译者｜刘多肉

中文修订版｜2026 年 8 月 24 日

如何借助 AI，逐阶段改造软件开发生命周期

代码已经不再是瓶颈

许多组织已经开始使用 AI 编写代码，速度在一年前还难以想象。围绕代码的开发流程却没有同步变化。

不少工程团队仍在沿用原来的审批节点、代码评审、团队交接和内部政策。这些环节正在拖慢 Claude Code 等智能体编程工具带来的效率提升。

软件开发生命周期，也就是 SDLC，指软件从一个想法走向生产环境的完整过程。多数组织采用的流程都包含六个阶段，分别是计划、设计、开发实现、测试、部署和维护。

在传统模式下，每个阶段彼此分开，并由不同角色负责。产品经理编写需求，技术架构师把需求转化为设计，工程师完成开发，受监管企业的 QA 团队负责验证，发布团队完成上线，运维团队监控生产环境。工作通过文档、工单和审批记录在各阶段之间传递。

传统 SDLC 设置了大量流程，目的是确保每一步都有明确责任并受到控制。这套流程形成于一个特定时期，当时最耗时、成本最高的环节是编写和实现代码。如今，这个前提已经发生变化。PRD、工作量估算和产品安全评审，原本都是为了让参与者在持续数周、数月甚至数个季度的开发过程中保持一致。

传统 SDLC 还默认每一步都由人完成。目前，从 AI 中获得最大价值的组织，已经开始按照智能体式 AI 的能力重新设计流程，同时把人的判断保留在关键环节。

本文总结了 Anthropic 应用 AI 团队在组织内部将 Claude 融入 SDLC 各阶段的实践。这些做法也来自团队与客户合作时积累的经验，目的是加快开发速度，让整个流程更高效。

当代码不再是瓶颈，而开发实现的速度超过传统流程能够承受的节奏时，会出现三个结果。

瓶颈转移到开发实现前后的环节，主要包括计划、评审与测试、部署。这些环节仍按人的速度运行。
原有控制措施开始脱离现实，甚至难以执行。代码由人编写时，逐行人工评审还有可行性。当大部分代码差异都由 AI 智能体生成后，这种方式很快就会跟不上。
治理成本继续上升，因为例外事项仍要等待每周或每月才召开一次的会议和委员会处理。

开发实现已经不再是限制因素。它可以缩短到几个小时，前后依赖人工的阶段却仍然保持原来的周期。

以安全审查为例。安全团队通常按照人工开发的产出规模配置人员。当智能体让代码产出成倍增长时，结果只有两种。评审队列越来越长，或者代码在审查不充分的情况下上线。受监管组织无法接受其中任何一种，因此安全检查和政策检查也必须跟上智能体的速度。

要充分获得智能体式 AI 带来的效率提升，同时保证使用安全，传统 SDLC 必须像开发实现环节一样接受系统性的改造。

什么是 AI 原生 SDLC

AI 原生 SDLC 保留原有的控制目标，同时采用适合 AI 智能体的新执行和强制机制。流程不再是一次走完的直线，而是一个持续循环，AI 被嵌入每个环节。

各阶段之间的交接可以自动完成，后续流程也能由上一阶段的产物自动触发，从而减少传统 SDLC 中大量依赖人工、效率低下的交接工作。

两种模式的变化

下表列出了传统 SDLC 与 Claude 支持的 AI 原生 SDLC 两端的典型状态。多数组织目前处在两者之间。

阶段	传统 SDLC	AI 原生 SDLC
计划	委员会收集需求，再经过研讨会和多轮审批整理，最后由人写成文档	Claude 直接汇总一手来源中的痛点，写入 `intent.md`。这份文件既便于人阅读，也能供机器据此行动
设计	分析师编写规格，设计师再根据规格完成设计	智能体在一次工作会话中完成需求分析和设计，过程受 skills 中的组织标准约束，结果纳入 Git 版本管理
开发实现	测试和代码由人编写，文档通常在主要开发完成后补写	测试和代码由 AI 生成，组织知识通过纳入版本管理、机器可读的 `CLAUDE.md` 和 skills 维护
测试	QA 在阶段边界设置检查	持续 eval 贯穿开发实现过程
部署	人逐行评审代码，治理依赖评审周期，执行标准经常不一致	由多层智能体完成专项审查，受监管代码和关键代码仍由人评审。治理要求在 AI 执行动作时立即生效，hooks 负责执行审批检查
维护	人监控生产环境并寻找 bug	智能体监控线上部署。指标一旦超出控制区间，系统便完成诊断，并把结果作为新的 `intent.md` 写回循环

右栏各阶段有一条共同主线，也就是纳入版本控制的产物。每个阶段结束时都会把一份产物写入版本控制系统。下一阶段从读取这份产物开始。

这些产物包括 intent.md、spec.md、plan.md、代码差异及其测试、带有评审结果的 PR，以及事故记录。前几个阶段主要使用 Markdown 文件，因为产品负责人和智能体可以共同阅读和修改同一份文件。从开发实现阶段开始，主要产物变成代码及其相关记录。

提交记录串在一起，也就形成了审计记录。它说明谁提出了什么要求，智能体产出了什么，又由谁批准。凡是需要判断的决定，最终责任始终由人承担。在智能体式 SDLC 中，人的注意力会跟随需要评审的产物向后移动。

每个阶段都会提交一份可供下一阶段读取的产物。意图、规格、计划、代码差异和评审结果共同组成完整的审计记录。

实施做法

这些做法是本手册的核心。它们分布在计划、设计、开发实现、测试、部署和维护六个非线性阶段，合起来覆盖完整的软件开发生命周期。

每项做法都会说明以下内容。

发生了什么变化
如何开始
具体实施步骤
治理方面需要考虑什么
如何衡量是否有效

这些步骤彼此独立，组织可以根据自身需要，在不同时间优先改造不同阶段。每项做法都会在"前置条件"中说明依赖关系，原文的依赖图进一步展示了这些关系。

一个阶段以提交产物结束，这次提交会启动下一阶段。被接受的 intent.md 会触发需求和设计流程，批准后的 spec.md 会触发 plan mode，合并后的 PR 会触发流水线，生产指标超出控制区间后则会生成下一份 intent.md，循环由此继续。

刚开始时，每一步都由人手动输入提示词。最终状态是一套持续运行的循环，每一份被接受的产物都会触发下一个检查节点。人的注意力集中在这些节点，只需审核智能体标出的事项，不必从头处理每个阶段。

图中的做法按所属阶段排列，箭头表示建议采用顺序，两者并不完全相同。没有箭头指向的浅褐色做法不依赖其他做法，可以直接开始。其余做法需要先采用指向它们的前置做法。

01｜计划

想法不必继续等待别人整理成文档。发起人只需用自己的话把意图记录一次，形成纳入版本管理的产物，下一阶段便可以据此行动。

把想法写成 `intent.md`

intent.md 用来启动软件开发流程。它可以从不同入口产生。某个人提出想法，团队收到一张工单，或者告警暴露出一起事故。事故入口会在第六阶段"维护"中说明。

有人提出想法时，可以先与 Claude 讨论，并生成一份 Markdown 格式的初步规格说明。在传统 SDLC 中，同一个人还要说服产品团队成员协助整理，或者代为写成正式文档。

Claude 生成的规格草案便于人阅读，可以纳入版本管理，也能被下一阶段直接使用。团队把它保存为 intent.md。

无论意图来自事件触发器还是智能体，后续步骤都相同。产品负责人需要在提交前评审并修正智能体编写的 intent.md。

传统做法

一个想法要经过待办事项、用户故事、故事点和需求梳理会议，才会有人开始行动。每次交接都会转移所有权，最终送到工程团队手中的内容，往往已经与发起人的本意隔了好几层。

AI 原生做法

发起人与 Claude 讨论，把结果写成 intent.md。这是一份使用发起人自己的语言写成的规格草案，说明想要什么、为什么需要，以及有哪些约束。重复性流程可以编码成 skills。

如何开始

前置条件

无。

基础设施

组织需要让非工程人员也能使用 Claude，例如通过 claude.ai 或 Cowork。还需要一份统一的 intent.md 模板，以及一个共享、纳入版本管理并由产品负责人持续关注的存放位置。

对于单个产品，最简单的做法是在产品代码库中建立 intent/ 目录。这样，意图产物和由它产生的代码会放在一起。只有当一项意图涉及多个代码库时，单独建立 intent 代码库带来的额外成本才有价值。在 monorepo 中，它仍然只是一个目录。第三阶段的"遗留系统与权威记录"会说明这个位置如何与 Jira 或现有需求工具配合。

平台团队或工程团队只需进行一次搭建。技术成员需要建立存放位置，并决定谁可以写入，因为贡献者可能来自组织内的不同部门。

代码库建好后，没有 Git 使用经验的贡献者也不必直接操作 Git。Claude 可以通过 GitHub 等版本控制系统的连接器，从 claude.ai 或 Cowork 代为提交 Markdown 文件。

执行步骤

发起人用自己的话向 Claude 描述问题。可以说明目前做不到什么、谁会受到影响、理想结果是什么，以及哪些内容不在范围内。无需使用正式措辞。
与 Claude 讨论，直到想法足够具体。Claude 会提出分析师通常会问的问题，包括范围、用户、约束和成功标准。
让 Claude 按组织模板把结果写成 intent.md。模板可以编码为 skill，由技术成员搭建并由负责人批准。模板可以覆盖问题、期望结果、受影响的用户和系统、约束以及待澄清问题。
发起人修正 Claude 理解错误的地方。
把 intent.md 提交到共享位置。作者和时间戳会进入记录，产品负责人从这里接手。

示例

markdown 复制代码

# Intent: claims status self-service

Author: J. Ortiz (claims operations)
Status: draft

## Problem

客户会打电话到客服中心询问理赔进度。客服人员大约三分之一的通话时间都用在单纯的状态查询上。

## Proposed outcome

客户可以在门户中查看理赔状态、下一步操作和预计日期。

## Affected users and systems

理赔客服人员、门户团队、claims-core API。

## Constraints

不能在门户会话中引入新的个人敏感信息。只能使用现有身份认证方式。

## Open questions

第三方定损员是否也需要访问权限？

治理考虑

证据就是已经提交的 intent.md。文件包含作者、时间戳和完整修订历史，这些信息都记录在 intent 存放位置的 Git 历史中。

产品负责人负责批准。是否让这项意图进入第二阶段，会体现为合并该产物，或者关闭相关评审。

如何衡量

先行指标

衡量第一次讨论到提交 intent.md 的时间。作者和时间戳可以直接从存放位置的 Git 历史中读取。预期结果是把过去持续数周的需求引导和梳理周期缩短到几小时。

滞后指标

衡量产品负责人允许进入第二阶段的 intent.md 所占比例，原文把它称为 survival rate。接受决定会体现为合并产物，拒绝决定则体现为关闭评审。

还要统计同一项变更提交第一份 spec.md 以后，intent.md 又被修改了多少次。

02｜设计

需求分析和设计合并到一次会话中完成。政策要求在编写规格时就得到应用，不必等到几周后的评审阶段才发现问题。

合并需求分析与设计

产品负责人批准意图后，Claude 会根据被接受的 intent.md 生成需求与设计规格。组织的品牌、安全、合规和 UX skills 会在这个过程中提供约束。

产品负责人负责评审规格，但不必亲自编写。最终目标是得到一份工程团队可以据此制定计划的规格，其中已经标出需要关注的问题。

前端开发最能说明这种做法。intent.md 被接受后，产品负责人可以在 Claude Design 测试版中根据它生成设计稿。经过多轮调整并确认满意后，再把设计稿导出给 Claude Code 实现。

传统做法

需求分析与设计由两个团队分阶段完成。分析师先把想法整理成正式需求，设计师再根据需求完成设计。这样的分工可以明确责任，却会拖慢速度，也会在交接过程中损失信息。

AI 原生做法

两个阶段在一次由提示词引导的会话中完成。Claude 根据 intent.md 生成需求与设计规格，组织的 skills 为它提供约束，需要关注的问题也会被明确标出。

如何开始

前置条件

已经完成 intent.md
品牌、安全、合规和 UX 政策已经写成 skills

基础设施

一位可以使用 Claude 的产品负责人，无需具备工程技能。

执行步骤

产品负责人开启一个会话，加载组织的 skills，并附上 intent.md。
提示词需要引用 intent.md，明确点出约束，并要求 Claude 标出需要关注的问题。团队可以先手动执行，再把提示词做成组织级 slash command。之后还可以把接受 intent.md 设为触发条件。文件合并时，系统启动一个非交互任务，加载组织的 skills，并通过 pull request 提交 spec.md。第五阶段的 CI/CD 做法会介绍这条流水线。完成自动化后，产品负责人第一次介入就是评审规格。
同一位产品负责人需要对照最初的想法评审规格。规格有没有解决原来提出的问题。intent.md 中的待澄清问题已经得到解答，还是留待后续处理。
优先处理 Claude 标出的问题。分析师原本也会把这类问题转交专人处理。工程团队看到规格以前，产品负责人需要与相应的政策负责人逐项解决。
把 spec.md 与 intent.md 一起提交。这两份文件共同记录目标和已经作出的决定。
产品负责人决定规格和意图是否可以进入开发实现。组织认定为高风险的事项需要咨询技术负责人。这个判断始终由人作出。接受规格会启动第三阶段的 plan mode。

示例提示词

text 复制代码

阅读附件中的 intent.md，编写一份需求与设计规格，说明如何把它集成到现有代码库中。

应用当前可用的 skills，确保方案符合品牌、安全和 UX 标准。

把完整内容写入 spec.md，使工程团队可以据此制定计划。

明确说明所有需要关注的问题，尤其是无法同时满足相互冲突的政策要求时。

治理考虑

政策要求在规格形成时便会被读取和应用，无需等到几周后的评审阶段才发现问题。组织的 skills 会成为规格的约束。

规格、生成规格的提示词，以及当时生效的 skill 版本，都会留在版本控制记录中。产品负责人批准规格，并把标出的问题交给对应的政策负责人处理。

如何衡量

先行指标

衡量同一项变更中，从提交 intent.md 到提交 spec.md 的时间。两个 Git 时间戳可以直接提供数据，并可与过去的需求加设计周期对比。

滞后指标

衡量开发实现开始后的需求返工。统计同一项变更提交第一份 plan.md 以后，spec.md 又发生了多少次提交。Git 日志可以直接提供数据。

03｜开发实现

没有经过批准的计划，就不开始实现。组织知识会变成智能体能够读取的文件，防护规则也会以代码形式执行，不再只依赖人的习惯。

默认从 Claude Code plan mode 开始

工程师在 plan mode 中启动 Claude Code 会话，把第二阶段批准的 spec.md 交给 Claude。Claude 随后会向工程师提问，双方持续修改计划，直到工程师满意。

传统做法

工程师读完设计便开始写代码。如何实施改动、需要修改哪些文件、需要增加哪些测试，通常只存在工程师脑中，情况好一些时会写在工单评论里。其他人无法提前评审这些内容。

评审者第一次看到的是已经完成的代码差异。到了这个时候，返工已经变得缓慢。

AI 原生做法

工作从一份书面计划开始。Claude 在 plan mode 中生成计划。这个模式允许它读取代码库，但不能修改任何内容。

工程师在代码生成以前修正计划，批准后的版本以 plan.md 提交，后续阶段会用它核对实际结果。

如何开始

前置条件

如果已经存在意图产物，需要提供 intent.md 或 spec.md。拥有 CLAUDE.md 也会有所帮助。

基础设施

能够访问代码库的 Claude Code。

执行步骤

工程师在 plan mode 中开启 Claude 会话。
把 intent.md 和 spec.md 交给 Claude，要求它制定实施计划。计划需要说明将修改哪些文件、工作顺序，以及使用哪些测试验证结果。
继续追问计划。这个改动可能破坏什么，哪一步风险最高，Claude 没有采用哪些备选方案。
持续修改，直到一位从未看过这段会话的工程师只读计划也能完成实现。
把批准后的计划提交为 plan.md。它会成为审计记录的一部分。第五阶段的 PR 评审会拿最终代码差异与计划核对。
接受计划，让 Claude 开始实现。计划足够扎实时，实现通常可以一次完成。
实际实现偏离计划时，在同一次提交中更新 plan.md。团队可以考虑使用 hook 强制两者保持同步。

`plan.md` 示例

markdown 复制代码

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change

portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work

1. 在现有身份认证后增加状态端点。
2. 让面板调用该端点。
3. 把面板接入门户导航。

## Risks

claims-core API 的速率限制是每秒 50 个请求，面板必须使用缓存。

## Proof

test_status.py 覆盖四种理赔状态，截图与批准的设计稿一致。

治理考虑

设计评审会在任何代码生成以前完成。此时改变方向只需编辑一份文档。plan mode 本身会强制执行这一点，因为工程师接受计划以前，Claude 无法编辑文件。

计划及其修订记录都会保存，接受计划的人也会被记录。常规改动由工程师批准，组织认定为高风险的改动则交给技术负责人或架构师。

如何衡量

先行指标

统计第一次实现便能合并的变更比例，以及计划获批到 PR 合并所需的时间。所需数据都在 PR 元数据中。

滞后指标

统计每项变更经历的返工轮数，数据同样来自 PR 元数据。还要观察合并后的代码差异与已提交的 plan.md 保持一致的比例。

Claude Code auto mode

Claude Code 也可以在 auto mode 中运行。工程师经过多轮调整并批准计划后，Claude 会逐项应用改动，不再为每次编辑单独请求许可。

随着后续做法中的防护规则逐渐成熟，auto-accept 会成为常规工作的默认选择。这些防护包括经过调校的 CLAUDE.md、编码政策的 skills、阻止不安全动作的 hooks，以及 Claude 能够自行运行的测试套件。

适合 auto-accept 的工作通常有三个特点。spec.md 范围清楚，影响范围较小，相关代码已经有测试覆盖。

工作方式也会随之变化。用户无需继续看着智能体逐次编辑和审核每个动作，可以在较长的自主会话结束后直接评审产物。auto-accept 与 worktrees 配合，还能支持个人和团队并行工作。它也是让 SDLC 自主运行，并在第六阶段完成循环的基础。

遗留系统与权威记录

这一节适用于流程产生的每一份产物。

现有 SDLC 很可能已经在跟踪这些产物，只是没有使用 Markdown 文件。工作项可能保存在 Jira 中，需求可能保存在内置法规追踪能力的工具里，设计放在 Figma 中，变更审批则由变更委员会记录。

这些系统很难被取代。审计人员和监管机构已经接受它们，其他团队也依赖它们。AI 原生 SDLC 因此必须适应现有环境。

转向 AI 原生 SDLC 时，需要为流程产生的每一份产物指定一个权威记录系统。其他系统只能保留副本，或者保存指向原件的链接。不同产物可以采用不同的配置。

以代码库为权威记录

Markdown 产物是权威记录，遗留系统引用具体提交中的文件。对于工程团队主导的组织，这通常是最简洁的配置。所有记录都在一个工具中，也采用同一套时间戳作为依据。

以遗留系统为权威记录

Jira、ServiceNow 或需求工具保存权威记录，Markdown 产物只是工作副本。Claude 在会话开始时读取记录，并在生成规格或计划的同一次会话中，通过 MCP 连接器把结果写回遗留系统。

最低要求是建立双向链接

所有产物都记录对应的事项编号，所有遗留记录也保存 Markdown 文件的提交 SHA。转型初期可以从双向链接开始，但组织需要接受暂时存在两处权威记录的事实。

遗留系统和以 Markdown 为主的系统可以共存。两者之间至少要有链接，或者明确指定其中一个作为权威记录。

`CLAUDE.md`

CLAUDE.md 为 Claude 提供新成员入职时需要了解的上下文，包括团队惯例、常用命令、系统架构，以及团队最常遇到的错误。

过去保存在人脑和 Wiki 中的知识，会变成智能体每次会话开始时读取的文件。整个团队共同维护这份文件，每当出现错误便继续更新。

如何开始

前置条件

无。

基础设施

一个代码库，已经安装的 Claude Code，以及一位熟悉代码库的工程师。

执行步骤

在代码库中运行 /init。Claude 会根据它发现的内容生成初版 CLAUDE.md。
把生成的文件精简到新成员第一天真正需要的内容。保留构建、测试和 lint 命令，真正重要的惯例，以及 Claude 经常犯错的地方。
把 CLAUDE.md 提交到代码库根目录，让全团队共享同一个版本。对它的修改也要像代码一样接受评审。
可以采用一条简单规则。Claude 第二次犯同一个错误时，把纠正方法写进 CLAUDE.md。
把文件控制在一页以内。Claude 会在每次会话开始时读取全部内容，过时信息只会浪费上下文空间。

`CLAUDE.md` 示例

markdown 复制代码

# Payments service

## Commands

- Build: make build
- Test: make test（单元测试），make itest（集成测试，需要 Docker）
- Lint: make lint（CI 中也会运行，推送前必须修复）

## Conventions

- Java 21、Spring Boot 3。不要新增 Lombok。
- 金额一律使用 BigDecimal，不能使用 double。
- 每个端点都需要在 src/itest 中添加集成测试。

## Architecture

- api/ 保存 REST 控制器，core/ 保存领域逻辑，adapters/ 负责连接外部系统。
- Kafka 事件在 schemas/ 中定义。不能编辑生成的类。

## Things Claude gets wrong

- 不要升级依赖版本，平台团队负责这项工作。
- 遗留的 v1/ 包已经冻结，改动应放入 v2/。

治理考虑

CLAUDE.md 纳入版本管理，因此智能体使用的指令可以接受评审和审计。团队惯例通过这份文件生效，每次修改都记录在 Git 历史中，并由代码所有者在 PR 评审中批准。

如何衡量

先行指标

统计 Claude 重复犯下本应由 CLAUDE.md 避免的错误的频率。对 CLAUDE.md 的纠正和修改也应在 Git 历史中追踪。

滞后指标

统计团队新成员加入以后，第一份 PR 获得合并所需的时间。数据来自 PR 历史。

用 skills 保存组织知识

组织可以通过 skills 把内部知识转化为实际操作。指令会变得明确，纳入版本管理，在整个组织中广泛使用，并在政策变化时集中更新。

一条实用原则是，把需要始终得到一致执行的组织知识写成 skill。属于 CLAUDE.md 或一条普通提示词的内容，无需单独写成 skill。

如何开始

前置条件

没有硬性前置条件。CLAUDE.md 会有所帮助，因为它把智能体的工作知识保存在代码库中，但 skill 并不依赖它。

基础设施

一项已经指定负责人，并拥有书面权威来源的政策。

执行步骤

挑选一项目前执行最不一致的规范或经验。它可以是一条安全标准、一项 API 设计惯例，或者一条品牌规则。
把它写成 skill。一个 skill 是包含 SKILL.md 的目录，文件的 frontmatter 说明何时触发，正文说明需要执行什么。工程师根据政策负责人的权威资料编写，也可以让 Claude 协助。
把 skill 放在代码库的 .claude/skills/<name>/ 中，使它随代码一起分发。也可以通过插件在整个组织中分发。
测试 skill 能否触发。使用不同说法要求 Claude 执行相关任务，并确认它每次都会加载 skill。
政策发生变化时，更新 skill，并由政策负责人批准改动。
工程师会在下一次会话中自动获得新版本。

`.claude/skills/secure-api-review/SKILL.md` 示例

markdown 复制代码

---
name: secure-api-review
description: 应用 API 安全标准。创建或修改外部端点、评审 API 代码或生成 OpenAPI 规格时使用。
---

# Secure API review

创建或修改 API 端点时，执行以下检查。

1. 身份认证。每个端点都需要网关 JWT，/health 以外不允许匿名路由。
2. 输入验证。按照 OpenAPI schema 验证请求体，并拒绝未知字段。
3. 审计。每个改变状态的端点都要发出审计事件，其中包含 actor、action、entity 和 timestamp。
4. 数据分类。schema 中标记为 pii 的字段不能出现在日志或错误信息里。

运行 scripts/check-endpoints.sh，并在总结中附上输出。

治理考虑

skill 属于建议性控制。它能提高 Claude 在编写代码时应用政策的概率，但没有机制能够强制每次会话都遵守。

必须始终成立的政策还需要一个确定性机制，例如阻止相关动作的 hook，或者在 PR 阶段再次核对政策的专项审查。skill 可以减少违规，hook 则让违规变得极难发生。

skill 的调用会记录在会话轨迹中，政策负责人也要像评审代码一样评审 skill 的修改。

如何衡量

先行指标

衡量政策负责人批准政策变更，到更新后的 skill 获得合并所需的时间。数据来自 skill 目录对应的 PR。

滞后指标

统计 PR 评审中引用该政策的问题数量。skill 开始在代码编写阶段应用政策后，这个数字应逐渐接近零。

如果数字没有下降，通常有两个原因。skill 没有触发，或者它的文本已经偏离正式政策。

用 hooks 建立开发实现阶段的防护规则

skill 提供建议性控制，hook 则在背后提供确定性约束。Claude 在实现阶段执行的大多数动作都是编辑文件和运行 shell 命令，因此 hooks 在这个阶段触发得最频繁。

开发实现阶段的 hooks 可以执行以下操作。

阻止编辑受保护路径，例如生成的类或已经冻结的包
编辑文件后运行格式化器和 linter，避免格式或代码风格偏差不断累积
防止凭据进入代码差异

凡是必须无例外执行的政策，都应在对应 skill 后面增加 hook。hook 会在每个匹配的动作上运行，因此开发实现阶段的 hooks 应当足够快，并且只检查发生改动的文件。完整测试套件等较重的检查更适合在提交或 PR 阶段运行。

需要人工批准的 hook 应放在第五阶段的审批节点中。开发实现期间频繁弹出审批提示，会让人重新进入所有并行会话的关键路径。

并行会话与子智能体

一位工程师可以同时推进多项工作。

并行会话是另一个完整的 Claude Code 实例。它在自己的 Git worktree 中处理独立任务。各个会话彼此不了解，唯一的共同点是由同一位工程师负责协调。

子智能体在单个会话内部运行。它是一个范围受限的助手，拥有独立的上下文窗口和工具权限，适合处理多个任务中反复出现的工作，例如验证应用能否按预期运行。

并行会话可以增加一位工程师同时推进的任务数量，子智能体则让每个会话保持专注。工程师负责协调并评审所有结果。

传统做法

一位工程师一次只做一项任务，每天或每周都有大量时间用来等待构建、测试和评审。等待期间可以切换任务，但上下文切换很累，很少有人愿意频繁这样做。

AI 原生做法

一位工程师同时运行多个 Claude 会话。每个会话都在独立 worktree 中完成自己的任务。重复出现的工作交给拥有独立上下文和工具限制的子智能体。工程师的工作逐渐转向协调，最终变成搭建和监控自动循环。

如何开始

前置条件

需要 CLAUDE.md，因为所有会话都会读取这份文件。第四阶段介绍的反馈循环也很有帮助。会话能够自行验证结果以后，工程师需要投入的监督会减少。

基础设施

一个 Git 代码库。worktrees 用来提供隔离。权限设置也要经过调校，避免会话在执行组织认定为安全的命令时不断等待批准。

执行步骤

工程师把工作拆成会修改不同文件的任务。plan mode 生成的计划可以帮助判断哪些工作彼此独立。需要修改同一文件的任务应放在同一个会话中依次执行。
每项并行任务都使用自己的 worktree。例如在一个终端中运行 claude --worktree feature-auth，在另一个终端中运行 claude --worktree fix-rate-limit。worktree 是位于独立分支的独立工作副本，可以避免不同会话同时修改同一文件。
从两到三个会话开始比较合适。实际数量取决于一个人能否认真评审每一路结果。只有评审速度能够跟上时，才继续增加会话。
把重复工作定义成子智能体。定义文件放在 .claude/agents/ 目录下，使用 Markdown 编写，并包含名称、适用场景说明和允许使用的工具。常见例子包括删除不必要复杂设计的代码简化器、运行应用并检查行为的验证器，以及探索代码库并汇报结果的调研智能体。最后一种做法可以避免占用主会话的上下文。把这些定义提交到 Git，让整个团队共享。

`.claude/agents/verifier.md` 示例

markdown 复制代码

---
name: verifier
description: 在会话报告完成以前运行应用，并检查改动是否生效
tools: Bash, Read
---

使用 make run 启动应用。检查发生改动的行为，以及与它最接近的两条流程。

报告运行了什么、观察到什么，以及任何不符合 plan.md 的行为。

不要修复问题，只需报告。

治理考虑

会话越多，产出也越多，因此控制措施必须来自代码库中的配置。hooks 和权限设置会对所有会话生效。每个会话执行过的操作都会被记录，并归因到启动它的工程师。

如何衡量

先行指标

在评审质量不下降的前提下，统计每位工程师同时运行的会话数。数据可以从 OpenTelemetry 导出中获得。还要统计一天中用于协调任务的时间比例，并与等待时间比较。

滞后指标

统计每位工程师每周合并的变更数量，并结合 PR 历史中的返工率一起观察。

04｜测试

每个会话都要在人看到结果以前检查自己的工作。用来引导智能体的配置，也要像智能体编写的代码一样接受回归测试。

为 Claude 建立反馈循环

始终为 Claude 提供一种验证结果的方法，可以是测试、构建，也可以是截图差异对比。会话需要在工程师看到结果以前自行检查，并修复自己的错误。

反馈循环和第三阶段介绍的验证器子智能体用途不同。反馈循环贯穿整个任务，运行次数由工作本身决定。验证器子智能体则是封装最终检查的一种方式。会话认为工作完成后，它会在一个全新的上下文窗口中执行检查，使最终判断不受生成代码时已有假设的影响。

传统做法

代码是否可用，往往很晚才有信号。CI 要几分钟后才给出结果，测试人员可能几天后才介入，问题甚至可能几周后才在生产环境暴露。

当代码由智能体生成时，迟到的反馈意味着必须有人检查它的全部产出，这个人随后就会成为瓶颈。

AI 原生做法

会话需要在人看到结果以前自行检查。运行测试，完成构建，截取页面。Claude 持续修改，直到检查通过。工程师收到的结果已经过这一轮验证。

运行会话的工程师负责搭建反馈循环，下面的步骤也面向这些工程师。

如何开始

前置条件

无。

基础设施

测试套件和构建流程都应支持一条命令在本地运行。对于 UI 工作，还必须让 Claude 能看到结果，可以使用浏览器工具，也可以通过 MCP 接入截图工具。

执行步骤

如果检查工作需要连续运行多条命令，还依赖一些环境知识，就把这些步骤封装成一个统一命令或构建目标，例如 make test 或 npm test。检查失败时，命令必须以非零状态码退出。
在 CLAUDE.md 的 Commands 部分列出每条命令，并给出正常输出示例。
设定可以量化的目标，让 Claude 无需询问便能自行检查。例如 test_status.py 中的所有测试都要通过，截图要与附件中的设计稿一致，或者端点要返回 200 并包含新字段。
修复 bug 时，先编写一个会失败的测试。让 Claude 把 bug 复现成测试，运行测试，并确认它会因为预期原因失败。先提交这项测试，再让 Claude 在不修改测试的前提下修复代码。最后一步介绍的测试文件 hook 可以强制执行这项限制。测试在修复以前已经存在，智能体也无法重写它，这就能证明 bug 确实消失了。
UI 工作要通过视觉检查完成反馈循环。为 Claude 提供浏览器或截图工具，再提供设计稿，让它反复执行实现、截图、对比和调整。进行两到三轮很正常，每一轮都应让结果有所改善。
把验证列入完成标准。相关指令写在 CLAUDE.md 中。Claude 报告任务完成以前必须运行测试，并展示输出。
反馈循环本身也需要保护。修复代码的智能体不能削弱针对这段代码的检查。可以用 hook 阻止智能体在修复任务中编辑测试文件。另一种做法是在评审中检查代码差异，拒绝任何修改测试的变更。

`CLAUDE.md` 中的验证配置示例

markdown 复制代码

## Verifying your work

- Build: make build（必须以 "Build succeeded" 结束）
- Test: make test（所有测试必须通过，不能跳过或删除失败的测试）
- Lint: make lint（零警告）

报告任务完成以前，运行上面三项检查并粘贴输出。
测试失败时修复代码，不能修改测试。

治理考虑

需要强制执行的内容

任务报告完成以前必须通过验证。修复期间，智能体不能编辑测试文件。组织需要保证这两项要求时，可以把它们实现为 hooks。

可以作为证据的内容

Claude 实际运行并粘贴的 make test 输出、构建日志或截图差异。证据直接来自工具链。

记录位置

记录会保存在会话日志中，OpenTelemetry 导出会把它转发到组织的可观测性系统。PR 的检查记录也会保留相关信息，评审者和日后的审计人员都能看到。

批准人

评审 PR 的代码所有者。自动化检查的证据已经附上，评审者便可以把注意力放在变更意图和风险上。

如何衡量

先行指标

统计智能体编写的变更在 CI 中首次运行便通过的比例。现有 CI 系统通常已经支持这项数据。

滞后指标

统计每个 PR 的评审时间，数据来自 PR 元数据。测试开始捕获过去需要评审者发现的问题后，这项时间应当下降。还要从事故跟踪系统中统计变更失败率。

在 CI 中持续运行 eval

eval 是传统阶段性 QA 在 AI 原生流程中的对应做法。实际形式是一套评测集，每当智能体配置发生变化时便会运行。

团队更换模型或改写提示词后，eval 套件可以判断智能体能否继续按照相同标准完成工作。

eval 应被视为持续变化的测试集。随着模型进步，过去能够区分效果的用例会逐渐失去区分度。团队需要根据持续监控发现的问题补充新用例。

不同场景可以采用不同运行方式。有些团队会按固定周期离线运行 eval，无需在每次变更后执行。下面的步骤针对持续 eval。

如何开始

前置条件

CLAUDE.md，以及本阶段介绍的反馈循环。

基础设施

能够非交互运行 Claude Code 的 CI，以及一枚拥有足够预算运行 eval 的 API key。

执行步骤

平台工程师从近期工作中收集 20 到 50 个真实任务，并记录预期或可接受的结果。
把每个任务写成一条 eval。它由提示词和判断结果是否可接受的检查组成，例如测试通过、lint 无错误、行为没有变化、政策得到遵守。
eval 套件在 CI 中以非交互方式运行。它需要按计划定时执行，也要在 CLAUDE.md、skills 或 hooks 发生任何变化时执行。这些配置负责引导智能体，理应接受与代码相同的回归测试。
把评测结果设为配置变更的合并检查。如果 skill 修改导致通过率下降，必须先经过评审才能合并。
每起生产事故都要增加一条 eval，由负责该事故的团队编写，并作为回归测试永久留在套件中。

`.github/workflows/agent-evals.yml` 示例

yaml 复制代码

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

治理考虑

eval 为 QA 提供了一项能够跟上智能体产出速度的检查。通过率阈值会作为合并检查强制执行，每次运行都会留下记录，团队可以比较不同时期的结果。拥有该配置变更的团队负责批准。

如何衡量

先行指标

观察 eval 通过率随时间的变化。套件会在每次运行时报告结果。还要统计一起生产事故变成永久 eval 所需的时间。

滞后指标

比较 CI 中捕获的回归问题和生产环境中发现的回归问题。生产数据来自事故跟踪系统。

05｜部署

评审会双向进行，治理要求在智能体执行动作时立即生效。智能体可以完成生产审批节点以前的所有工作，但不能自行越过这一节点。

让 AI 进入 PR 评审循环

Claude 既可以评审别人提交的内容，也可以接受别人对它的评审。它按照组织政策检查新提交的 PR，同时处理自己创建的 PR 中收到的评审意见。

这样一来，工程师在 PR 评审中可以专注于行为，最终只需判断两件事。改动是否符合意图，风险是否可以接受。

传统做法

评审能力按照人工产出规模配置。一个 PR 需要等待评审者读完全部内容，评审质量会随着评审者的负荷变化。提交者不断催促评审人员，积压仍会继续增加。

AI 原生做法

所有 PR 都接受同一组专项审查，发现的问题按照严重程度排序。人的注意力会移到更高一层，判断变更有没有实现计划中的目标，以及风险是否可以接受。

如何开始

前置条件

第三阶段更新后的 CLAUDE.md
专项审查需要执行书面政策时使用的 skills
已经定义好的子智能体

基础设施

代码库需要安装 Claude 集成。管理员可以启用托管的 Code Review 服务，目前处于研究预览阶段。团队也可以在自己的 CI 中运行 claude-code-action。需要时，模型调用可以通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 完成。后面的 CI/CD 做法会说明部署选项。

同时建议启用分支保护规则，要求代码所有者批准。

执行步骤

托管 Code Review 服务是最快的起点。管理员启用服务并选择代码库即可。需要控制流水线，或者希望模型调用继续使用组织现有的云服务合同和账户体系时，可以在自己的 CI 中使用 claude-code-action 运行评审。后面的 CI/CD 做法会说明相关连接方式。
技术负责人在代码库根目录编写 REVIEW.md，把评审政策分成组织关心的专项审查。常见内容包括 bug 与逻辑错误、安全与漏洞、是否符合规格 spec.md、实施计划 plan.md 和设计原则。REVIEW.md 还要定义什么算 Important，什么只算 Nit，以及哪些内容不需要报告。
技术负责人设定人工介入标准。评审发现本身不会批准或阻止 PR，分支保护仍然要求代码所有者批准。平台工程师如果希望根据发现结果阻止合并，可以读取检查任务发布的机器可读严重程度计数。
评审者或提交者在评审意见中提及 @claude 后，Claude 会处理意见并推送修复。PR 讨论串会同时记录请求和改动。这个修复循环通过 claude-code-action 运行。在托管服务中，评论 @claude review 会请求一次新的评审。对于 Claude 自己创建的 PR，还可以让它持续处理问题，直到 PR 满足合并条件。团队可以把这套循环做成自定义 slash command，扫描尚未解决的评审意见和失败检查，处理问题并推送修复，直到 PR 全部通过，只等待代码所有者批准。
评审发现要反馈到 CLAUDE.md。同一个错误第二次被评审发现时，在本次评审中把纠正方法写入 CLAUDE.md。评审流程会读取 CLAUDE.md，因此下一个 PR 开始便能发现这类错误。评审还要指出哪些改动让 CLAUDE.md 变得过时。
技术负责人每月调整一次配置。通过给评审发现评分来改进评审者，在 REVIEW.md 中限制 Nit 数量，并排除生成文件路径和 CI 已经强制检查的内容。

`REVIEW.md` 示例

markdown 复制代码

# Review instructions

## Passes

执行三轮专项审查，并为每条发现标注所属类别。

- Bugs: 逻辑错误、失效的边界情况、隐蔽的回归
- Security: 注入风险、身份认证缺口、日志中的个人敏感信息
- Compliance: 改动符合 spec.md、plan.md 和组织的设计原则

## What Important means here

Important 只用于会破坏行为、泄露数据或违反政策的问题。
风格和命名问题属于 Nit。

## Cap the nits

每次评审最多报告五条 Nit，其余问题只汇总数量。

## Do not report

不报告 src/gen/ 下的生成文件，以及 CI 已经强制检查的内容。

治理考虑

职责分离得以保留，因为编写代码的智能体没有权限批准代码。REVIEW.md 中的评审政策适用于所有 PR。发现、修复、评分和批准都会记录在 PR 历史中，因此 PR 本身就是审计记录。

最终批准仍由人作出，并由分支保护规则强制执行。评审发现为人的决定提供信息。

如何衡量

先行指标

统计等待第一次评审所需的时间，目标是缩短到分钟级。还要统计无需人修改分支便能解决的评审意见比例，数据直接保存在 Git 中。

滞后指标

比较合并前发现的缺陷和漏洞，以及逃逸到生产环境的问题。数据来自 PR 历史和事故跟踪系统。

用 hooks 建立审批节点

第三阶段把 hooks 用作防护规则，无需人工参与便可允许或阻止动作。hook 也可以发起审批请求，并暂停当前动作，直到指定人员批准。这正是发布审批所需的行为。

这项做法放在部署阶段，因为发布审批最容易说明它的用途，但 hooks 并不只用于部署。Claude 在哪里执行动作，hooks 就可以在哪里运行。

例如，第三阶段可以使用 hooks 阻止没有变更工单的数据库迁移和基础设施修改。第四阶段也可以阻止智能体在修复任务中编辑测试文件。

如何开始

前置条件

无。

基础设施

一份书面清单，列出变更流程要求的全部审批。

执行步骤

工程管理层与变更管理和合规团队共同列出必须保留的人工审批节点，例如变更管理批准、发布授权，以及对受保护路径的修改。
平台工程师把每个审批节点实现为 hook。hook 是 Claude 执行动作以前运行的脚本，可以允许、请求审批或阻止动作。
团队级 hooks 放在 Git 中的 .claude/settings.json。不能协商的 hooks 放入平台管理员或 IT 管理员负责的 managed settings，个别工程师无法关闭。
阻止动作时必须解释原因。hook 阻止某项操作后，Claude 的输出中应出现原因和申请批准的方法。

`.claude/settings.json` 示例

json 复制代码

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh"
          }
        ]
      }
    ]
  }
}

`.claude/hooks/production-gate.sh` 示例

bash 复制代码

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
  if [ -z "$RELEASE_APPROVAL" ]; then
    echo "Production deploys need a release authorization." >&2
    exit 2 # exit 2 blocks the action; the message goes to Claude
  fi
fi
exit 0

治理考虑

hooks 就是审批节点。检查条件会对每个人、每次操作强制执行。允许和阻止决定都会带时间戳记录。审批节点也会定义什么才算有效批准，例如已经获批的变更工单，或者发布经理的授权。

受监管企业的 managed settings 示例

以下配置由平台团队通过 MDM 或管理控制台下发。工程师无法编辑或覆盖其中任何设置。

json 复制代码

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(./secrets/**)",
      "WebFetch",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(git *)",
      "Bash(make build)",
      "Bash(make test)",
      "Bash(make lint)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": [
        "git.internal.example.com",
        "registry.npmjs.org"
      ]
    },
    "credentials": {
      "files": [
        {
          "path": "~/.ssh",
          "mode": "deny"
        },
        {
          "path": "~/.aws/credentials",
          "mode": "deny"
        }
      ],
      "envVars": [
        {
          "name": "GITHUB_TOKEN",
          "mode": "deny"
        }
      ]
    }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "example-corp/approved-plugins"
    }
  ],
  "requiredMinimumVersion": "2.1.193"
}

下面逐项说明这些设置能够提供哪些控制效果。

permissions.deny 防止密钥进入智能体上下文，也阻止工具任意访问外部网络。permissions.allow 预先批准安全的日常开发操作，避免拒绝清单造成频繁的授权提示。

disableBypassPermissionsMode 与 allowManagedPermissionRulesOnly 配合后，工程师、项目文件和命令行参数都无法放宽规则。

sandbox 用来补上权限规则无法覆盖的缺口。工具层面禁止 WebFetch，并不能阻止 shell 命令访问网络。操作系统层面的域名白名单可以直接阻止未经允许的外部连接。

failIfUnavailable 和 allowUnsandboxedCommands 让沙箱成为强制检查。沙箱无法初始化时，Claude Code 会拒绝启动。在沙箱内失败的命令也不能转到沙箱外重试。

credentials 补上拒绝规则留下的另一处缺口。permissions.deny 管理 Claude 的文件工具，但沙箱中的 shell 命令默认仍可能读取 ~/.ssh 或 ~/.aws/credentials。这一部分会阻止读取这些文件，并从每条沙箱命令的环境变量中移除指定密钥。

allowManagedHooksOnly 表示只有本节定义的审批 hooks 可以运行，本地配置不能增加或替换它们。

disableSideloadFlags 与 strictKnownMarketplaces 配合后，工程师机器上的每个 skill、智能体、hook 和 MCP server 都必须来自组织批准的插件市场，不能从用户主目录侧载。

allowManagedMcpServersOnly 把智能体的工具范围变成由平台团队维护的白名单。

requiredMinimumVersion 会拒绝启动低于批准下限的版本，确保这些控制措施由组织已经评估过的 Claude Code 版本执行。

上面的配置只是一份需要按实际情况调整的起点，不建议直接照抄。每一条拒绝规则都会限制一部分能力，正确的平衡取决于代码库的数据分类。settings 参考文档列出了全部配置键，包括只能由管理员设置的项目。

如何衡量 hooks

先行指标

统计每个审批节点的等待时间。每次 hook 决定都会写入 OpenTelemetry 导出，记录时间戳以及允许或阻止结果，因此每个节点的等待时间都可以观察。

滞后指标

比较引入 hooks 前后，违反审批要求并进入生产环境的事件数量。数据来自事故跟踪系统。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code。执行环境使用沙箱，让长时间运行的智能体保持安全。部署能力通过 MCP 集成提供，并在智能体真正需要回滚以前反复演练回滚路径。

传统做法

流水线运行确定性脚本。凡是需要判断的工作都要等待人处理，例如分析不稳定测试、编写变更日志，或者查明构建失败的原因。部署和回滚依赖操作手册，由人在压力下执行。

AI 原生做法

Claude 在流水线内部以非交互方式处理需要判断的步骤。它在沙箱中运行，只持有范围受限的凭据。部署工具通过 MCP 提供给智能体。

这样，完成代码编写和测试的同一套工作流，也能在组织为各环境设定的审批节点内完成发布和回滚。

如何开始

前置条件

Claude 已经进入 PR 评审循环，hooks 也已经成为审批节点。自动化开始加速流程以前，审批节点必须先存在。

基础设施

已经安装 claude-code-action 的 CI 平台，或者任何能够调用 claude -p 的执行器
通过 API 访问模型。调用流量需要保留在组织现有云服务合同内时，可以使用 Bedrock、Foundry 或 Vertex
面向部署目标的 MCP servers
智能体任务使用的沙箱配置，默认不持有长期有效的生产凭据

执行步骤

平台工程师先从只读的判断工作开始。在流水线任务中使用 claude -p 分析构建失败、总结不稳定测试，或者起草变更日志。
在现有审批节点后面增加写入操作，例如修复 lint、更新生成文档，或者通过 @claude 提及处理评审意见。智能体写出的任何内容都要通过 PR 和分支保护进入代码库，智能体不能直接推送到 main。
所有执行都在沙箱中完成。智能体任务运行在受网络策略约束的容器中，只持有短期、范围受限的令牌，默认没有生产凭据。
通过 MCP 提供部署能力。部署、状态查询和回滚会成为按照环境划分权限的工具。智能体的部署权限由白名单明确限定，不再依赖带有凭据的 shell 脚本。
按环境划分自主程度。在开发环境中，智能体可以自由部署。在生产环境中，智能体准备发布，由发布经理授权，再由 hook 强制执行生产审批。预发环境处在两者之间。
回滚应该成为流水线中演练最充分的路径。它应是一条智能体可以运行的命令，并在预发环境定期演练。第六阶段介绍的持续循环会在指标超出控制区间时调用回滚，因此这条路径必须提前验证。

流水线步骤示例

yaml 复制代码

- name: Triage failed build
  if: failure()
  run: >
    claude -p "读取 out/build.log 中的构建日志。指出最可能的原因，
    判断这次失败更像不稳定问题还是真实故障，并为 PR 讨论串写一段
    三行总结。" >> triage.md

治理考虑

核心原则是让智能体可以执行到生产审批节点以前，但不能自行越过。下面的控制措施负责执行这条原则。

分支保护会把智能体编写的任何内容变成 PR，智能体没有直接进入 main 的路径。
生产部署 hook 会阻止发布，直到指定的发布经理授权。每次非交互运行都使用智能体自己的身份，因此流水线日志可以区分智能体做了什么，以及触发任务的工程师做了什么。
按环境划分的权限层级决定智能体在到达审批节点以前可以执行多少操作。

如何衡量

先行指标

统计无需通知人工便能完成分析的流水线失败所占比例。数据来自 CI/CD 流水线日志。

滞后指标

观察 DevOps Research and Assessment，也就是 DORA 指标。CI 系统和部署工具通常已经能够生成这些数据。

06｜维护

循环在这里接上起点。触发器无需人工发起便可调用 Claude，Claude 的发现会以 intent.md 形式重新进入流水线。

维护并让流程持续运行

前面介绍了如何把 Claude 加入 SDLC 的各个阶段。最初，每个阶段都需要人启动第一步。到了维护阶段，重点转向让 Claude 自主运行，使整个流程能够持续循环。

例如，持续运行的监控智能体可以在 bug 工单出现后创建 intent.md，再让它依次经过需求、计划、开发实现、测试和评审阶段。

维护阶段可以无人值守地运行。各阶段之间设置独立的可信性检查，由确定性检查或对抗性评审智能体决定上一阶段的结果可以继续流转，还是需要转交人工处理。

传统做法

维护是一个被动阶段。所有工单和事故都要等待人处理，再由人重新启动流程。凌晨三点发出的告警可能被错过，工单可能一直留在待办列表中，事故复盘提出的行动项也可能因为新的事故接踵而至，始终没有进入代码库。

AI 原生做法

指标超出控制区间、工单、频道消息或定时任务，都可以在无需人工参与的情况下调用 Claude。Claude 负责诊断，只能通过设有检查的路径采取行动，再把发现写成 intent.md，交给前面介绍的各阶段处理。

人继续负责分派和评审这些工作，但不必再亲自启动流程。

接上循环

一段确定性脚本负责监控生产环境。指标超出控制区间后，脚本会调用 Claude。监控指标越界只是用来说明自主循环的一种常见场景。本阶段末尾的 Claude Tag 会介绍从其他渠道进入的工作。

如何开始

前置条件

使用 intent.md 为循环提供一种结构化输出，使流程可以重新开始
由 Claude 加速的 PR 评审
把 hooks 用作动作边界
CI/CD 中已经验证的回滚路径，最高自主层级会调用它

基础设施

检测脚本能够查询的指标存储，例如 Prometheus、CI 系统 API 或同类工具
代码库的读取权限
在 CI 中以非交互方式运行 Claude Code 的能力，或者使用 Agent SDK 构建接收 webhook 的服务

执行步骤

服务负责人或平台工程师选择一项滚动基线稳定的指标，例如 CI 测试失败率、部署后的 5xx 比例，或者 PR 周期时间。
编写检测脚本。常见做法是在滚动时间窗口中计算均值和标准差，再使用 Western Electric 或类似规则，使控制区间既能发现突发尖峰，也能识别缓慢漂移。脚本要纳入版本管理，并配有单元测试。检测过程保持完全确定性，不使用模型。
在纳入版本管理的配置中定义响应层级，下面的 bands.yaml 就是示例。达到 1σ 时，脚本只记录。达到 2σ 时，以只读方式调用 Claude 诊断。达到 3σ 时，Claude 可以采取行动，但只能提交 PR 进入评审，或者触发事先批准的操作手册。
触发层可以使用 GitHub 或 GitLab 的定时工作流、现有监控系统发出的 webhook，或者内网定时任务。Claude 以无状态方式运行，可以作为 CI 执行器上的非交互步骤，也可以作为沙箱容器中的 Agent SDK 服务。CI/CD 做法介绍了部署和模型访问方案。运行过程无状态且无需交互，因此整个循环可以在没有人启动的情况下自行开始和结束。
智能体按照第一阶段的格式，把诊断写成 intent.md。内容包括异常及其证据、建议结果、受影响的系统和待澄清问题。之后，这项发现会像其他工作一样经过完整流水线。
服务负责人或值班工程师处理分派队列，把涉及产品的发现交给产品负责人。他们可以选择立即修复、安排到后续计划，或者驳回。驳回结果会用来调整控制区间并减少噪声。
修复上线后，为这起事故增加一条 eval。持续 eval 会把它保留为回归测试，防止同类问题再次发生。

`bands.yaml` 示例

下面的配置监控 CI 测试失败率。

yaml 复制代码

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

治理考虑

响应层级的边界由纳入版本管理的配置强制执行，权限和 managed settings 会拒绝生产访问。每次调用、每项发现和每个分派决定都会带时间戳记录。

服务负责人负责处理并批准发现。由此产生的变更仍要经过正常的 PR 评审。智能体能够触发的操作手册也必须事先获得批准。

如何衡量

先行指标

统计指标超出控制区间，到 intent.md 进入分派队列所需的时间，并与过去从事故发生到形成复盘行动项的时间对比。检测脚本日志会记录越界时间戳和事故层级。

滞后指标

统计最终变成已合并修复的发现所占比例。可以把分派队列与实际 PR 历史对照。还要统计同类事故重复发生的次数。修复不断向 eval 套件增加用例后，这个数字应当下降。

示例

CI 测试失败率达到 3σ 时，智能体隔离不稳定测试，或者提交一个撤销变更的 PR，再由评审节点决定是否合并。
部署后的 5xx 比例达到 3σ，且监控窗口内存在一次部署时，智能体触发现有回滚流水线。
PR 周期时间触发漂移规则时，智能体为工程管理层编写报告。这说明同一套机制既适用于流程指标，也适用于生产指标。

检测始终保持确定性。只有指标超出控制区间以后，Claude 才会被调用，响应层级决定它可以执行哪些操作。

通过 Claude Tag 值守

事故也可能通过 Slack 或 Teams 等工作沟通工具进入。过去，事故频道晚上十点出现一条紧急修复消息后，需要等待人处理。现在，这类消息可以立即得到响应。

Claude Tag 目前处于 Slack 公开测试阶段。它让 Claude 使用自己的身份加入频道，使每起新事故都能立即获得首位响应者。处置过程也会成为循环的一部分，并留下可供以后处理同类事故参考的记录。

对话和组织知识都留在频道中，频道里的任何人都能引导并处理响应。团队成员可以实时验证假设、尝试新方案并展开调查。频道历史也提高了整个过程的可审计性。

Claude 通过 MCP 访问相关系统，确认指标是否已经回到基线，并在讨论串中报告结果。它还会把事故复盘写入纳入版本管理的经验文件，供以后的调查读取。

Claude Tag 处理的工作并不限于事故。Claude 通过 MCP 在工单中被提及，或者在频道中收到问题时，也会采用相同方式分派工作。

范围较小、边界清楚的修复会形成 PR，并经过评审节点。更大的工作会写成 intent.md，重新进入第一阶段。到了这里，循环开始自行运转。

频道本身就是审计记录。请求、诊断、人的授权和修复，都留在事故实际得到处理的地方。

结语

随着模型及其配套工具与控制框架不断增强，组织可以改造代码生产方式，也可以改造整个软件开发生命周期。

这项改造把人的判断保留在流程中心，同时考虑了大型企业的治理和监管要求。

本指南整理了 Anthropic 应用 AI 团队每天为客户执行的许多真实做法。我们希望它能成为一份实用、可以直接行动的资料。

循环持续运行，最终判断权始终由人掌握。

资源与致谢

下面这些文档可以帮助平台团队搭建本文介绍的控制措施。排列顺序大致对应推荐的实施顺序。

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献。本文受到他们此前大量工作的启发，也建立在这些工作之上。

AI 原生软件开发生命周期手册 - 如何借助 AI，逐阶段改造软件开发生命周期

AI 原生 SDLC 实战手册

如何借助 AI，逐阶段改造软件开发生命周期

代码已经不再是瓶颈

什么是 AI 原生 SDLC

两种模式的变化

实施做法

01｜计划

把想法写成 intent.md

如何开始

执行步骤

示例

治理考虑

如何衡量

02｜设计

合并需求分析与设计

如何开始

执行步骤

示例提示词

治理考虑

如何衡量

03｜开发实现

默认从 Claude Code plan mode 开始

如何开始

执行步骤

plan.md 示例

治理考虑

如何衡量

Claude Code auto mode

遗留系统与权威记录

CLAUDE.md

如何开始

执行步骤

CLAUDE.md 示例

治理考虑

如何衡量

用 skills 保存组织知识

如何开始

执行步骤

.claude/skills/secure-api-review/SKILL.md 示例

治理考虑

如何衡量

用 hooks 建立开发实现阶段的防护规则

并行会话与子智能体

如何开始

执行步骤

.claude/agents/verifier.md 示例

治理考虑

如何衡量

04｜测试

为 Claude 建立反馈循环

如何开始

执行步骤

CLAUDE.md 中的验证配置示例

治理考虑

如何衡量

在 CI 中持续运行 eval

如何开始

执行步骤

.github/workflows/agent-evals.yml 示例

治理考虑

如何衡量

05｜部署

让 AI 进入 PR 评审循环

如何开始

执行步骤

REVIEW.md 示例

治理考虑

如何衡量

用 hooks 建立审批节点

如何开始

执行步骤

.claude/settings.json 示例

.claude/hooks/production-gate.sh 示例

治理考虑

受监管企业的 managed settings 示例

如何衡量 hooks

CI/CD 集成与部署

如何开始

执行步骤

把想法写成 `intent.md`

`plan.md` 示例

`CLAUDE.md`

`CLAUDE.md` 示例

`.claude/skills/secure-api-review/SKILL.md` 示例

`.claude/agents/verifier.md` 示例

`CLAUDE.md` 中的验证配置示例

`.github/workflows/agent-evals.yml` 示例

`REVIEW.md` 示例

`.claude/settings.json` 示例

`.claude/hooks/production-gate.sh` 示例

`bands.yaml` 示例