AI 原生 SDLC 实战手册（中文翻译）

如何借助 AI，逐阶段重塑软件开发生命周期。

本文是 Louis Claxton 发表于 Claude Blog 的文章 The AI-Native SDLC playbook 的中文翻译。原文发布于 2026 年 8 月 21 日，版权归原作者及 Anthropic 所有。产品名称、配置键和命令保留原文。

代码不再是瓶颈

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

许多工程团队仍沿用原来的审批门禁、评审、交接和策略，导致 Claude Code 等智能体编程方案带来的生产力提升被这些流程拖住。

软件开发生命周期（SDLC）是软件从想法走向生产环境的全过程。大多数组织采用的流程都包含相似的六个阶段：规划、设计、构建、测试、部署和维护。传统上，每个阶段都是由不同角色负责的独立环节。产品经理编写需求，技术架构师把需求转化为设计，工程师按设计构建，受监管企业中的 QA 团队负责验证，发布团队负责上线，运维团队监控正在运行的系统。工作通过文档、工单和签字审批，在各阶段之间流转。

传统 SDLC 流程繁重，是为了在每一步确保问责和控制。然而，传统 SDLC 是在这样一个时代设计出来的：编写和实现代码是最耗时、成本最高的阶段，而如今已不再如此。PRD、估算仪式和产品安全评审之所以存在，是为了迫使各方在可能持续数周、数月甚至数个季度的开发过程中达成一致。

传统 SDLC 的控制措施还假定每一步都由人完成。那些从 AI 中获得最大价值的组织，已经围绕智能体 AI 现在能够完成的工作重建了流程，同时确保人始终参与其中。本指南结合我们与客户合作获得的经验，介绍应用 AI 团队在内部将 Claude 融入 SDLC 各阶段时采用的一些最佳实践，从而加速开发、提升流程运行速度。

当代码不再是瓶颈，而且构建阶段的运行速度超过传统 SDLC 所能承载的速度时，会出现三种情况：

• 瓶颈会转移到构建阶段左右两侧的环节，主要是规划、评审/测试和部署，因为它们仍以人的速度运行。
• 控制措施开始脱离现实，变得难以执行。当代码由人编写时，逐行人工评审很合理；但当大部分差异都由 Agent 生成时，这种方式便无法跟上。
• 治理成本上升，因为异常情况仍要提交给每周或每月才开会的会议和委员会处理。

构建已不再是约束——构建时间缩短至数小时，但以人的速度运行的阶段仍保持原来的耗时。

以安全瓶颈为例。安全团队的人员配置是按照人的代码产出来规划的，因此，当 Agent 将代码产出放大数倍时，要么评审队列不断积压，要么代码在评审不足的情况下上线。受监管组织无法接受其中任何一种结果，所以安全和策略检查必须跟上 Agent 的速度。

为了更充分地实现智能体 AI 带来的生产力收益，同时保证其安全性，传统 SDLC 必须经历与实现阶段同等程度的转型。

目录

1. 代码不再是瓶颈
2. 实践项
3. 阶段 1——规划
4. 阶段 2——设计
5. 阶段 3——构建
6. 阶段 4——测试
7. 阶段 5——部署
8. 阶段 6——维护
9. 结语

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一个经过重新构想的流程：它保留原有的控制目标，但采用新的执行机制。流程不再是一条线，而是变成一个循环，AI 被嵌入其中的每一个节点。AI 原生 SDLC 推动自动交接，并自动触发后续实践项，以解决传统 SDLC 各阶段之间交接过程人工、笨重的问题。

转变

下表展示了 Claude 所支持的 AI 原生 SDLC 与传统 SDLC 这两个光谱端点之间的差异。大多数组织实际处于两者之间。

阶段	传统 SDLC	AI 原生 SDLC
规划	委员会收集需求，通过研讨会和签字审批逐步提炼，再由人工写成文档	Claude 直接从信息源中综合痛点，记录到人类可读、机器可执行的 intent.md 中
设计	分析师编写规格，设计师再对其进行解读	在一次与 Agent 协作的工作会话中完成需求和设计，由编码为 Skills 的标准提供指导，并在 Git 中进行版本管理
构建	测试和代码由人工编写，文档在主要开发工作完成后再补写	测试和代码由 AI 生成；组织知识以机器可读、受版本控制的 CLAUDE.md 文件和 Skills 维护
测试	在阶段边界设置 QA 门禁	将持续评测嵌入实现过程
部署	人工评审每一行代码，治理在评审周期中进行，而且经常不一致	采用多层 Agent 评审，只把受监管和关键代码留给人工评审；在 AI 行动时执行治理，并将 Hooks 作为审批门禁
维护	人工监视生产环境中的缺陷	Agent 监控线上部署；一旦突破控制区间，便进行诊断，并把结果作为新的 intent.md 写回循环

右侧一列贯穿始终的线索，是提交到版本控制中的产物。每个阶段结束时都会写入一个产物，包括 intent.md、spec.md、plan.md、代码差异及其测试、包含评审发现的 PR，以及事故记录；下一阶段则从读取该产物开始。在早期阶段，.md 文件是主要产物，因为产品负责人和 Agent 都能读取它并据此行动。从构建阶段开始，产物则变成代码及其相关记录。

这一连串提交同时构成审计轨迹：谁提出了什么要求、Agent 生成了什么、又是谁批准了它。

凡是需要判断的决策，最终责任仍由人承担。在智能体 SDLC 中，人的注意力会随着需要评审的产物一起转移。

每个阶段都会提交一个可供下一阶段读取的产物。意图、规格、计划、代码差异和评审发现共同构成审计轨迹。

实践项

这些实践项是本手册的核心，被划分到六个非线性阶段中：规划、设计、构建、测试、部署和维护。它们共同覆盖完整的软件生命周期。

每个实践项都会说明：

• 有什么变化；
• 如何开始；
• 具体实施步骤；
• 治理方面的注意事项；
• 如何衡量它是否有效。

这些步骤采用模块化设计。组织可以根据自身需求，在不同时期优先改造不同阶段。每个实践项都会在“前置条件”中列出依赖关系，依赖关系图也会进一步展示这些依赖。

一个阶段通过提交产物结束，而这次提交又会启动下一阶段。被接受的 intent.md 会触发需求与设计流程；获批的 spec.md 会触发 Plan 模式；合并后的 PR 会触发流水线；生产环境中突破控制区间的事件会写入下一个 intent.md，循环由此继续。

一开始，你可以手动提示每一个步骤；最终目标则是形成一个循环，让每个被接受的产物自动触发下一道门禁。人的注意力集中在这些门禁上，评审 Agent 标记出的事项，而不必每次都从头启动下一阶段。

图中列出了各阶段中的实践项，箭头表示采用它们的顺序。两者并不相同。可以从任意一个陶土色的实践项开始——没有箭头指向它，所以它不依赖其他实践项。对于其余实践项，指向它的箭头表示应当先采用哪些实践项。

01 规划

想法不必再等待某个人把它写出来。意图只需按发起者自己的表达记录一次，成为受版本控制、可供下一阶段直接采取行动的产物。

以 intent.md 捕获意图

启动软件开发过程的 intent.md 可以通过不同路径进入流程：某个人提出一个想法、有人提交一张工单，或者告警暴露了一起事故（参见阶段 6：维护）。

当一个人产生想法时，他可以与 Claude 展开头脑风暴，并生成一份 Markdown 原型规格。在传统 SDLC 中，这个人随后还必须说服产品团队成员，与自己一起把想法写出来，或者由对方代写。

Claude 生成的原型规格既能被人阅读，也受到版本控制，而且下一阶段可以立即使用。该原型规格保存为 intent.md。

无论意图来自事件触发器还是 Agent，后续步骤都相同：在提交之前，由产品负责人评审并纠正 Agent 编写的 intent.md。

传统方式

一个想法要先后经过待办事项、用户故事、故事点和需求梳理会议，之后才有人能够采取行动。每次交接都会转移所有权，因此，当想法最终到达工程团队时，已经与发起者的本意隔了好几层。

AI 原生方式

发起者与 Claude 进行头脑风暴，并把结果写成 intent.md——一份使用发起者自身语言撰写的原型规格。该产物包含想要什么、为什么想要，以及有哪些约束。重复执行的流程则编码为 Skills。

开始使用

前置条件

无。

基础设施

为非工程人员提供 Claude 访问权限（claude.ai 或 Cowork）；商定统一的 intent.md 模板；为意图准备一个由产品负责人关注、共享且受版本控制的存放位置。对于单一产品，最简单的做法是在产品仓库中建立 intent/ 文件夹。这样，产物链会与由其产生的代码放在一起。只有当一个意图跨越多个仓库时，单独建立意图仓库所带来的额外开销才值得承担；在单体仓库中，它只是一个目录。阶段 3“构建”中的侧栏会说明，这个存放位置如何与已经保存正式记录的 Jira 或需求工具配合使用。

这是一项由平台或工程团队一次性完成的设置工作。技术团队成员需要建立意图的存放位置，并决定谁有写入权限，因为贡献者会来自整个组织的许多不同部门。

仓库建立后，不熟悉 Git 的贡献者不必直接使用 Git。通过连接版本控制系统（例如 GitHub）的连接器，Claude 可以从 claude.ai 或 Cowork 代表他们提交 Markdown 文件。

如何执行

1. 发起者用自己的语言向 Claude 描述问题。他可以说明目前做不到什么、谁受到影响、理想状态是什么，或者哪些内容不在范围内，不需要使用正式语言。
2. 持续进行头脑风暴，直到想法足够具体。Claude 会提出分析师通常会问的问题：范围、用户、约束，以及成功是什么样子。
3. 要求 Claude 使用组织模板把结果写成 intent.md。模板可以编码为一项 Skill，由技术团队成员配置并由负责人批准。它可以包含问题、预期结果、受影响的用户与系统、约束和开放问题。
4. 发起者纠正 Claude 误解的内容。
5. 将 intent.md 提交到共享位置。作者和时间戳会成为记录的一部分，产品负责人从这里接手这个想法。

# 意图：理赔状态自助查询
作者：J. Ortiz（理赔运营）。状态：草稿。

## 问题
客户会致电客服中心询问理赔处理到了哪一步。
理赔处理人员大约三分之一的通话时间都花在单纯查询状态的问题上。

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

## 受影响的用户和系统
理赔处理人员、门户团队、claims-core API。

## 约束
门户会话中不得出现新的个人身份信息（PII）。仅使用现有身份验证。

## 开放问题
第三方损失理算员是否也需要访问？

治理注意事项

证据是已经提交的 intent.md，其中包含作者、时间戳和完整修订历史。这些内容记录在意图存放位置的 Git 历史中。产品负责人负责批准，而将意图送入阶段 2“设计”的接受或拒绝决定，则记录为产物的合并或评审关闭。

如何衡量

领先指标

从第一次对话到提交 intent.md 所花费的时间。可以从意图存放位置的 Git 历史中读取，因为其中记录了作者和时间戳。预期效果是把原本持续数周的需求获取与梳理周期缩短到数小时。

滞后指标

存活率，即产品负责人接受并送入阶段 2“设计”的 intent.md 占比，而不是将其关闭。接受或拒绝的决定记录为产物合并或评审关闭。此外，还要统计同一项变更的首个 spec.md 提交完成后，intent.md 又发生了多少次修改。

02 设计

需求与设计被压缩到同一次会话中完成。策略在编写规格时即被应用，而不是几周后才在评审中被发现。

需求与设计

产品负责人批准 intent.md 后，Claude 会根据它生成需求与设计规格。该过程由组织针对品牌、安全、合规和用户体验制定的 Skills 提供指导。

产品负责人负责评审规格，但不必亲自编写。目标是生成一份工程团队可以据此规划的规格，并标记出值得关注的区域。

前端工作最能说明这一点。intent.md 被接受后，产品负责人根据它在 Claude Design（Beta）中生成设计原型并反复调整，然后将其导出到 Claude Code 中进行构建。

传统方式

需求与设计是由不同团队分别执行的独立阶段。分析师将想法形式化为需求，设计师随后再把需求解读成设计。这样的分离是为了实现问责，但过程缓慢且容易损失信息。

AI 原生方式

两个阶段在同一次提示会话中完成。Claude 读取 intent.md 并生成需求与设计规格，受到组织 Skills 的约束，同时标记出值得关注的区域。

开始使用

前置条件

编写 intent.md，并将品牌、安全、合规和用户体验策略编写为 Skills。

基础设施

一名可以访问 Claude 的产品负责人，不要求具备工程技能。

如何执行

1. 产品负责人打开一个已经提供组织 Skills 的会话，并附上 intent.md。
2. 产品负责人的提示应指向 intent.md、明确列出约束，并要求标记风险点。一开始可以手动运行，随后再将其固化为组织级斜杠命令。下一步，让意图存放位置中 intent.md 的接受事件成为触发器：合并时启动一个非交互式任务，加载组织 Skills 执行处理，并以拉取请求的形式提交 spec.md（阶段 5“部署”中的 CI/CD 实践项会介绍相应管道）。从此，产品负责人的第一次介入将发生在评审环节。
3. 同一位产品负责人根据原始想法评审规格：它是否解决了提出的问题？intent.md 中的开放问题是否得到回答，或者被继续保留下来？
4. 优先处理标记出的关注点，因为它们正是分析师通常会上报的问题。产品负责人需要在工程团队看到规格之前，与相应的策略负责人解决每一个问题。
5. 将 spec.md 与 intent.md 一起提交。这对文件记录了提出了什么要求，以及最终作出了什么决定。
6. 产品负责人决定规格和意图是否进入构建阶段。凡是被组织划为较高风险的内容，都要咨询技术负责人。这个决定始终由人类团队成员作出；接受规格会启动阶段 3“构建”中的 Plan 模式实践项。

示例：提示词

阅读随附的 intent.md，并生成一份需求与设计规格，说明如何将其集成到现有代码库中。
应用你可以使用的 Skills，使方案符合我们的品牌指南、安全策略和用户体验标准。
将规格完整记录为 spec.md，使其可以直接交给工程团队。
清楚说明所有值得关注的区域，尤其是无法同时满足相互矛盾策略的地方。

治理注意事项

当前有效的策略不再等到几周后的评审阶段才被发现，而是在编写规格时就被读取并应用。组织的 Skills 作为规格的约束条件。规格、生成它的提示，以及当时生效的 Skill 版本都会记录在版本控制中。产品负责人签字批准规格，并把标记出的关注点交给对应的策略负责人。

如何衡量

领先指标

同一项变更从提交 intent.md 到提交 spec.md 的耗时，即两个 Git 时间戳之间的差值，并与过去“需求加设计”的周期比较。

滞后指标

构建开始后的需求返工次数。统计同一项变更首次提交 plan.md 之后发生的 spec.md 提交；Git 日志可以直接给出结果。

03 构建

未经批准的计划，不得进入实现。组织知识会变成 Agent 可以读取的文件，护栏也会以代码而不是习惯的形式运行。

默认从 Claude Code 的 Plan 模式开始

工程师在 Plan 模式下启动 Claude Code 会话，把阶段 2“设计”中获批的 spec.md 交给 Claude，并让 Claude 通过提问了解情况、反复修改计划，直到工程师满意为止。

传统方式

工程师读完设计便开始编写代码。具体要如何修改、会涉及哪些文件和测试，都留在工程师脑中，最多只写进工单评论里。其他人无法提前评审；评审者第一次看到的是已经完成的代码差异，而到那时，返工已经很慢。

AI 原生方式

工作从书面计划开始。Claude 在 Plan 模式中生成计划；此时它可以读取代码库，但不能修改内容。工程师在代码编写前纠正计划，并将获批版本提交为 plan.md，供后续阶段进行核对。

开始使用

前置条件

如果已有意图产物，则提供 intent.md 或 spec.md；CLAUDE.md 也会有所帮助。

基础设施

能够访问代码仓库的 Claude Code。

如何执行

1. 工程师在 Plan 模式下启动 Claude 会话。
2. 工程师向 Claude 提供 intent.md 和 spec.md，要求生成一份实现计划，列明要修改的文件、工作顺序，以及用来证明实现正确的测试。
3. 追问计划：这项变更可能破坏什么？哪一步风险最高？Claude 放弃了哪些其他方案？
4. 持续迭代，直到一名从未看过对话的工程师也能只根据计划完成实现。
5. 将获批计划提交为 plan.md。计划由此加入审计轨迹；阶段 5“部署”中的 PR 评审实践项会核对最终代码差异是否符合它。
6. 接受计划，让 Claude 开始实现。有了扎实的计划，实现通常可以一次完成。
7. 如果实现偏离计划，在同一次提交中更新 plan.md。可以考虑使用 Hook 强制两者保持同步。

plan.md 示例

# 计划：理赔状态自助查询（源自 2026-06-02 的 intent.md）

## 要修改的文件
portal/src/claims/StatusPanel.tsx（新增）、claims-api/routes/status.py、
claims-api/tests/test_status.py

## 工作顺序
1. 在现有身份验证机制后面新增状态接口。
2. 构建调用该接口的面板。
3. 将面板接入门户导航。

## 风险
claims-core API 的速率限制为 50 rps；面板必须使用缓存。

## 证明
test_status.py 覆盖四种理赔状态；截图与获批原型一致。

治理注意事项

设计评审发生在生成任何代码之前，此时改变方向仍然只需修改文档。Plan 模式本身会强制执行这一点，因为在工程师接受计划前，Claude 无法编辑文件。计划及其修订版本都会被记录，同时也会记录由谁接受。常规变更由工程师批准；被组织划为较高风险的事项则交给技术负责人或架构师。

如何衡量

领先指标

第一次实现就能合并的变更占比，以及从计划获批到 PR 合并的时间；所需数据保存在 PR 元数据中。

滞后指标

每项变更经历的返工轮数，同样取自 PR 元数据；以及合并后的代码差异仍与已提交 plan.md 相符的频率。

Claude Code 的 Auto 模式

Claude Code 也可以运行在 Auto 模式下。工程师批准并反复完善计划，确认满意后，Claude 会执行每一项变更，而不再要求逐次批准编辑操作。随着后续实践项中的护栏逐渐成熟——经过调优的 CLAUDE.md、编码策略的 Skills、阻止不安全操作的 Hooks，以及 Claude 可以运行的测试套件——自动接受可以成为常规工作的默认方式：spec.md 范围明确、影响范围较小，而且代码已被现有测试覆盖。

重点由此从用户盯着 Agent 修改、逐项评审操作，转向在更长时间的自主会话结束后评审产物。与 Git 工作树配合使用时，自动接受模式还会进一步提升个人和团队的并行能力；它也是自主运行 SDLC，并按阶段 6“维护”所述闭合循环的基础。

侧栏：遗留系统与唯一事实来源

适用于流程产生的每一种产物。

现有 SDLC 流程很可能已经在跟踪这些产物，只是它们并不以 Markdown 文件的形式存在。工作项可能放在 Jira，需求可能保存在具备监管追溯能力的工具中，设计可能在 Figma，变更审批可能由变更委员会掌握。这些系统很难被替换，因为审计人员和监管机构已经认可它们，其他团队也依赖它们，所以 AI 原生 SDLC 必须适应现状。

在向 AI 原生 SDLC 迁移时，应为流程产生的每一种产物指定一个唯一事实来源，其余位置只保存副本或原始记录的链接。不同产物可以选择不同的事实来源，主要有以下几种配置：

以代码仓库为唯一事实来源。 Markdown 产物是权威记录，遗留系统引用具体提交中的文件。这是工程驱动型组织最简洁的配置之一，因为所有记录都保存在同一个工具中，使用同一套时间戳权威来源。

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

至少建立关联。 所有产物都注明记录 ID，所有遗留系统记录都包含 Markdown 文件的提交 SHA。迁移到 AI 原生 SDLC 时，这是一种很好的起点，代价是暂时接受两个事实来源并存。

遗留系统和 Markdown 优先的系统可以共存，但两者之间必须建立链接，或者明确声明其中一个为唯一事实来源。

CLAUDE.md

CLAUDE.md 为 Claude 提供新成员加入团队时需要了解的上下文，包括约定、命令、架构，以及团队最常看到的错误。过去存在人们脑中或 Wiki 上的知识，变成了 Agent 每次会话开始时都会读取的文件；它由整个团队共同维护，并在每次出现错误后持续改进。

开始使用

前置条件

无。

基础设施

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

如何执行

1. 在仓库中运行 /init，Claude 会根据它发现的内容生成初始 CLAUDE.md。
2. 精简生成的文件，只保留新成员第一天需要了解的内容：构建、测试和 Lint 命令；真正重要的约定；以及 Claude 经常出错的事项。
3. 将 CLAUDE.md 提交到仓库根目录，让整个团队共享同一版本，并像评审代码一样评审它的变更。
4. 可以采用一条实用规则：当 Claude 同一个错误犯了两次，就把纠正方法写进 CLAUDE.md。
5. 将文件控制在一页以内，因为 Claude 会在每次会话开始时读取全部内容；任何过时信息都只会无益地占用上下文。

CLAUDE.md 示例

# 支付服务

## 命令
- 构建：make build
- 测试：make test（单元测试），make itest（集成测试，需要 Docker）
- Lint：make lint（CI 中会运行；推送前修复问题）

## 约定
- Java 21、Spring Boot 3。不要新增 Lombok。
- 金额始终使用 BigDecimal，绝不能使用 double。
- 每个接口都必须在 src/itest 中包含一个集成测试。

## 架构
- api/ 保存 REST 控制器，core/ 保存领域逻辑，
  adapters/ 与外部系统通信。
- Kafka 事件在 schemas/ 中定义；绝不要编辑生成的类。

## Claude 容易出错的事项
- 不要升级依赖版本；它们由平台团队负责。
- 遗留的 v1/ 包已冻结；变更应放入 v2/。

治理注意事项

CLAUDE.md 受到版本控制，因此 Agent 工作时依据的指令可以被评审和审计。团队约定通过该文件执行，对它的修改记录在 Git 历史中，并由代码所有者在 PR 评审中批准。

如何衡量

领先指标

Claude 重复犯下本应由 CLAUDE.md 阻止的错误的频率。对 CLAUDE.md 的修正和修改应当能在 Git 历史中得到跟踪。

滞后指标

从 PR 历史中统计新成员加入团队后，到第一个 PR 合并所花费的时间。

用 Skills 承载组织知识

Skills 是组织将自身知识转化为实际运行能力的方式。指令明确、受版本控制、被广泛应用，并在策略变化时集中更新。经验法则是：必须始终一致应用的组织知识，应当写成 Skill；属于 CLAUDE.md 或单次提示的内容，则不要写成 Skill。

开始使用

前置条件

没有硬性要求。拥有 CLAUDE.md 会有帮助，因为它可以把 Agent 的工作知识保存在仓库中，但 Skill 并不依赖它。

基础设施

选择一项已经明确负责人、并有书面唯一事实来源的策略。

如何执行

1. 选择一项目前执行不一致的知识，例如安全标准、API 设计约定或品牌规则。
2. 将其编写为 Skill：创建一个包含 SKILL.md 的文件夹，在 Frontmatter 中说明何时触发，在正文中说明要做什么。工程师依据策略负责人的事实来源编写，并可让 Claude 协助。
3. 把 Skill 放在仓库的 .claude/skills/<name>/ 中，使其随代码一起分发；也可以通过插件在整个组织中分发。
4. 测试 Skill 是否会被触发。以不同方式要求 Claude 执行相关任务，并确认 Skill 每次都能加载。
5. 策略发生变化时，修改 Skill，并由策略负责人批准变更。
6. 工程师会在下一次会话中自动获得新版本。

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

---
name: secure-api-review
description: 应用 API 安全标准。在创建或修改面向外部的接口、
  评审 API 代码或生成 OpenAPI 规格时使用。
---
# 安全 API 评审

创建或修改 API 接口时：
1. 身份验证：每个接口都必须使用网关 JWT；
   除 /health 外，不得存在匿名路由。
2. 输入验证：依据 OpenAPI Schema 验证请求体，
   并拒绝未知字段。
3. 审计：每个改变状态的接口都必须发出审计事件，
   包含 actor、action、entity 和 timestamp。
4. 数据分类：Schema 中标记为 pii 的字段绝不能出现在
   日志或错误消息中。

运行 scripts/check-endpoints.sh，并在总结中包含其输出。

治理注意事项

Skill 是一种控制措施，但它是建议性的。它会提高 Claude 在编写代码时应用策略的概率，却没有任何机制强制会话遵守。必须始终成立的策略，需要在 Skill 背后增加确定性机制，例如用 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 应放在阶段 5“部署”的门禁中，因为如果在构建阶段弹出批准请求，就会让人重新回到所有并行会话的关键路径上。

并行会话与子 Agent

一名工程师可以同时推动多条工作流。

并行会话是另一个完整的 Claude Code 实例，它在自己的 Git 工作树中处理一项独立任务。每个独立会话都不知道其他会话的存在；它们唯一共享的是负责引导这些会话的工程师。

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

并行会话增加一名工程师同时在途的任务数量，子 Agent 则让每个会话专注于自己的任务。工程师的工作是引导并评审所有这些会话。

传统方式

一名工程师一次处理一项任务，并把一天或一周中的大量时间花在等待构建、测试和评审上。等待期间切换任务虽然可行，但上下文切换十分疲惫，所以很少有人愿意这样做。

AI 原生方式

一名工程师同时运行多个 Claude 会话，每个会话都在自己的工作树中处理自己的任务。重复工作变成拥有独立上下文和工具限制的子 Agent。工程师的角色转向编排，并最终转向构建和监控循环。

开始使用

前置条件

所有会话都会读取的 CLAUDE.md。阶段 4“测试”中的反馈循环也会有所帮助，因为当会话能够自行验证工作时，工程师需要投入的监督会更少。

基础设施

一个 Git 仓库，因为隔离通过工作树实现；还要调整权限设置，避免会话为了组织认为安全的命令反复等待批准。

如何执行

1. 工程师使用 Plan 模式实践项（阶段 3“构建”）生成的计划，判断哪些工作彼此独立，再把工作拆分成会修改不同文件的任务。会修改相同文件的任务应当在同一个会话中依次执行。
2. 每项并行任务使用自己的工作树，例如在一个终端运行 claude --worktree feature-auth，在另一个终端运行 claude --worktree fix-rate-limit。工作树是在独立分支上的单独检出，可以避免多个会话发生文件冲突。
3. 从两到三个会话开始比较合理。实际的上限取决于一个人能够认真评审多少条工作流；只有在评审跟得上的前提下，才增加会话数量。
4. 把重复工作转换成子 Agent。每个子 Agent 在 .claude/agents/ 下的 Markdown 文件中定义，包含名称、使用时机说明，以及可以使用的工具。例如：主 Agent 完成后移除不必要复杂度的代码简化器；运行应用并检查行为的验证器；探索代码库并汇报结果、同时避免挤占主上下文的研究员。把这些定义提交到 Git，让整个团队共享。

.claude/agents/verifier.md 示例

---
name: verifier
description: 在会话报告完成之前运行应用，并检查变更是否有效
tools: Bash, Read
---
使用 make run 启动应用。测试发生变更的行为，以及与之最接近的两条相邻流程。
报告你运行了什么、看到了什么，以及任何不符合 plan.md 的行为。
不要修复问题，只进行报告。

治理注意事项

更多会话意味着更多产出，因此控制措施必须来自仓库中的配置。仓库中的 Hooks 和权限设置会应用于所有会话；会话执行的操作也会被记录，并归属于启动它的工程师。

如何衡量

领先指标

在评审质量保持稳定的前提下，每名工程师并发运行的会话数，可从 OpenTelemetry 导出中统计；以及一天中用于引导而不是等待的时间占比。

滞后指标

每名工程师每周合并的变更数量，并结合根据 PR 历史计算的返工率一起观察。

04 测试

每个会话都会在交给人查看之前检查自己的工作；引导 Agent 的配置，也会像 Agent 编写的代码一样接受回归测试。

为 Claude 提供反馈循环

始终为 Claude 提供验证自身工作的方法，无论是测试、构建，还是截图差异比较。会话先检查自己的工作并修正自身错误，再交给工程师查看。

不要把反馈循环与验证器子 Agent（阶段 3“构建”）混为一谈。反馈循环会贯穿整项任务，并随着工作反复运行多次。验证器子 Agent 则是在会话认为工作完成后，使用一个全新的上下文窗口执行最终检查的方法。这样一来，验证结论便不会被生成代码时采用的假设所影响。

传统方式

代码能否工作的信号来得很晚：CI 要几分钟，测试人员要几天，生产环境可能要几周。当代码由 Agent 生成时，信号延迟意味着必须由人检查它的全部产出，而这个人便成为瓶颈。

AI 原生方式

在把工作交给人查看之前，先给会话一种自我检查的方法：运行测试、运行构建、生成截图。Claude 持续迭代，直到检查通过，因此，抵达工程师手中的内容已经完成验证。建立这套循环是运行会话的工程师的责任，以下步骤也是为他们而写。

开始使用

前置条件

无。

基础设施

测试套件和构建流程都能分别通过一条命令在本地运行。对于 UI 工作，Claude 必须能够看到结果，可以通过 MCP 接入浏览器工具或截图工具。

如何执行

1. 如果目前检查工作需要执行一连串命令并依赖环境知识，就把它封装为 make test 或 npm test 之类的单一目标，并确保失败时以非零状态码退出。
2. 在 CLAUDE.md 的“命令”部分列出每条命令，并附上正常输出示例。
3. 设定可量化的目标，让 Claude 无需询问便能自行检查，例如：“test_status.py 中的所有测试都通过”“截图与随附原型一致”或“接口返回 200，并包含新字段”。
4. 修复缺陷时，先编写会失败的测试。要求 Claude 把缺陷复现为测试、运行它，并确认它因为预期原因而失败。提交该测试，然后才要求 Claude 在不编辑测试的前提下让它通过，并使用最后一步介绍的测试文件 Hook 强制执行这一限制。修复前就已存在、而且 Agent 无法改写的测试，才是缺陷确已消失的证据。
5. 对于 UI 工作，使用视觉检查闭合循环。为 Claude 提供浏览器或截图工具以及原型，让它反复迭代：实现、截图、比较、调整。进行两三轮很正常，而且结果应当逐轮改善。
6. 把验证纳入“完成”的定义。将相关指令写入 CLAUDE.md：报告任务完成前必须运行测试，并展示输出。
7. 最后，反馈循环本身也需要保护，因为修复代码的 Agent 不能被允许削弱用于检查代码的机制。可以用 Hook 阻止 Agent 在修复任务中编辑测试文件；另一种做法是在评审中检查差异，并拒绝任何修改了测试的变更。

CLAUDE.md 验证段落示例

## 验证你的工作

- 构建：make build（必须以“Build succeeded”结束）
- 测试：make test（全部通过；绝不要跳过或删除失败的测试）
- Lint：make lint（零警告）

报告任何任务完成前，都要运行以上三项并粘贴输出。
如果测试失败，应修复代码，而不是修改测试。

治理注意事项

强制执行什么

任务报告完成之前必须经过验证；修复期间禁止 Agent 编辑测试文件。如果组织要求保证这两点，应将它们实现为 Hooks。

证据是什么

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

记录在哪里

记录在会话转录中，再由 OpenTelemetry 导出转发到组织的可观测性平台；同时也记录在 PR 的检查运行中，评审人员和今后的审计人员都可以查看。

由谁批准

由评审 PR 的代码所有者批准。因为机械性的证据已经附上，所以他可以把注意力集中在意图和风险上。

如何衡量

领先指标

Agent 编写的变更首次 CI 即成功的比率，现有 CI 系统已经可以统计。

滞后指标

每个 PR 的评审时间，取自 PR 元数据。当测试开始捕捉过去由评审人员发现的问题后，这一时间应当下降；同时还要从事故跟踪系统中统计变更失败率。

在 CI 中持续运行评测

评测（Evals）相当于 AI 原生时代的阶段门禁式 QA。实际做法是：每当 Agent 配置发生变化时，就运行一套评测。当更换新模型或重写提示后，评测套件会判断 Agent 是否仍能按照相同标准完成工作。

评测应被视为一套持续演进的活套件。随着模型改进，过去能够区分能力的案例会逐渐失去区分度；同时，还必须根据持续监控中发现的问题加入新案例。

根据使用场景，有些团队可能更适合按固定周期离线运行评测，而不是每次变更都运行。以下步骤针对持续评测。

开始使用

前置条件

CLAUDE.md 和反馈循环（阶段 4“测试”）。

基础设施

能够以非交互方式运行 Claude Code 的 CI，以及一枚为评测运行预留预算的 API 密钥。

如何执行

1. 平台工程师从近期工作中收集 20 到 50 项真实任务，以及相应的预期结果或已经接受的结果。
2. 将每项任务写成评测，即提示加上定义“可接受”的检查条件，例如测试通过、Lint 干净、行为未改变、策略得到遵守。
3. 评测套件按计划在 CI 中非交互运行，并在 CLAUDE.md、Skills 或 Hooks 每次变更时运行。因为这些配置会引导 Agent，所以它们与代码一样值得接受回归测试。
4. 根据结果为配置变更设置门禁。如果一项 Skill 变更导致通过率下降，就要在合并前进行评审。
5. 每起生产事故都要形成一个评测，由负责该事故的团队编写，并永久保留在套件中作为回归测试。

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

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

治理注意事项

评测为 QA 提供了一道能够跟上 Agent 产出速度的门禁。通过率阈值作为合并检查强制执行；运行过程被记录，以便比较一段时间内的结果；拥有相应配置变更的团队负责批准。

如何衡量

领先指标

套件每次运行时报告的评测通过率趋势，以及一场生产事故转化为永久评测所需的时间。

滞后指标

根据事故跟踪系统，对比 CI 捕捉到的回归与生产环境中发现的回归。

05 部署

评审在两个方向上运行，治理则在 Agent 行动时执行。Agent 可以完成生产门禁之前的所有工作，但不能越过门禁。

让 AI 进入 PR 评审循环

Claude 既提供评审，也接受评审。它按照组织策略评审传入的 PR，也会处理自己 PR 上的评审意见。这让工程师能够在 PR 评审中专注于行为；归根结底，他们只需判断意图与风险。

传统方式

评审能力按照人的产出来规划。一个 PR 要等待评审人员读完所有内容；评审质量随着评审人员的负载而变化；作者不断催促，积压却继续增长。

AI 原生方式

所有 PR 都接受同样的一组评审轮次，发现的问题按严重程度排序。人的注意力上移一层，转而判断变更是否实现了计划中的意图，以及风险是否可以接受。

开始使用

前置条件

阶段 3“构建”中更新过的 CLAUDE.md；如果评审轮次要执行书面策略，则还需要 Skills；以及已经定义的子 Agent。

基础设施

安装了 Claude 集成的仓库。可以由管理员启用托管的 Code Review 服务（研究预览版），也可以在自己的 CI 中运行 claude-code-action；如有需要，模型调用可以通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 发出（CI/CD 实践项会介绍部署选项）。此外，也值得设置分支保护策略，要求代码所有者批准。

如何执行

1. 托管 Code Review 服务是最快的起点。管理员启用服务并选择仓库。如果需要控制流水线，或希望 API 调用通过组织自己的云协议路由，则使用 claude-code-action 在自己的 CI 中运行评审（CI/CD 实践项会介绍相应管道）。
2. 技术负责人在仓库根目录将评审策略写成 REVIEW.md，并按照组织关注的方向拆分成多轮评审：缺陷与逻辑错误；安全与漏洞；是否符合规格（需求实践项产生的 spec.md）、实现计划（Plan 模式实践项产生的 plan.md）和设计原则。REVIEW.md 还应定义什么属于“重要问题”、什么只是“小问题”，以及哪些内容应跳过。
3. 技术负责人设置人工门槛。评审发现本身不能批准或阻止 PR，分支保护仍然要求代码所有者批准。如果平台工程师希望根据发现为合并设置门禁，可以读取检查运行发布的机器可读严重程度计数。
4. 当评审人员或作者在评审评论中标记 @claude 时，Claude 会处理评论并推送修复。PR 讨论串会同时记录请求和变更。这条修复循环通过 claude-code-action 运行。在托管服务中，评论 @claude review 则会请求重新评审。对于 Claude 自己创建的 PR，还可以让 Claude 持续照看直到合并。团队可以把这套循环封装为自定义斜杠命令：扫描 PR 中尚未解决的评审意见和失败检查，逐一处理并推送修复，直到 PR 全部通过，只等待代码所有者批准。
5. 评审发现应反馈到 CLAUDE.md 中。同一个错误第二次在评审中出现时，就在本次评审内把纠正方法写入 CLAUDE.md。由于评审过程会读取 CLAUDE.md，从下一个 PR 开始便能捕捉该错误。评审还应标记哪些变更使 CLAUDE.md 变得过时。
6. 技术负责人每月调优一次设置：对评审发现进行评级以改进评审器，并在 REVIEW.md 中限制小问题的数量。生成文件路径以及 CI 已经强制检查的内容应被排除。

REVIEW.md 示例

# 评审指令

## 评审轮次
运行三轮评审，并为每项发现标明所属轮次：
- 缺陷：逻辑错误、损坏的边界情况、隐蔽的回归
- 安全：注入风险、身份验证缺口、日志中的 PII
- 合规：变更符合 spec.md、plan.md 和我们的设计原则

## 此处“重要问题”的定义
只有会破坏行为、泄露数据或违反策略的发现才标为“重要”。
样式和命名问题属于小问题。

## 限制小问题数量
每次评审最多报告五个小问题；其余只汇总数量。

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

治理注意事项

职责分离得以保留，因为编写代码的 Agent 无法批准自己的代码。REVIEW.md 中的评审策略应用于所有 PR，发现、修复、评级和批准都记录在 PR 历史中，因此 PR 本身就是审计记录。最终批准由人通过分支保护完成，评审发现为这个决定提供信息。

如何衡量

领先指标

首次评审所需时间——应缩短到数分钟；以及无需人工触碰分支即可解决的评审意见占比，相关数据直接保存在 Git 中。

滞后指标

根据 PR 历史和事故跟踪系统，对比合并前捕捉到的缺陷与漏洞和逃逸到生产环境中的缺陷与漏洞。

用 Hooks 充当审批门禁

构建阶段使用 Hooks 作为护栏，在无需人工参与的情况下允许或阻止操作（阶段 3“构建”）。Hook 也可以选择“询问”，暂停操作，直到某个特定人员批准；发布门禁正需要这种能力。

这个实践项被放在阶段 5“部署”中，是因为发布门禁最能说明其用途，但 Hooks 并非部署专用：无论 Claude 在哪里行动，它们都可以运行。例如，在阶段 3“构建”中，Hooks 可以在没有变更工单时阻止编辑数据库迁移和基础设施；在阶段 4“测试”的修复任务中，可以阻止 Agent 编辑测试文件。

开始使用

前置条件

无。

基础设施

一份书面清单，列明变更流程所要求的批准。

如何执行

1. 工程管理层与变更管理及合规团队共同列出必须保留的人工审批门禁，例如变更管理签字、发布授权和受保护路径的编辑审批。
2. 平台工程师把每道门禁表达为 Hook，即一段在 Claude 行动前运行、能够选择允许、询问或阻止的脚本。
3. 团队 Hooks 放入 Git 中的 .claude/settings.json；不可协商的 Hooks 则放在平台或 IT 管理员拥有的托管设置中，个人工程师无法将其关闭。
4. 阻止操作时应解释原因。当 Hook 停止某项操作时，Claude 的输出中应显示原因和申请批准的路径。

.claude/settings.json 示例

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

门禁脚本 .claude/hooks/production-gate.sh

#!/bin/bash
# 生产部署需要指定的发布授权
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "生产部署需要发布授权。" >&2
     exit 2 # 退出码 2 会阻止操作；消息会发送给 Claude
   fi
fi
exit 0

治理注意事项

Hooks 就是审批门禁。门禁条件每次都会对所有人强制执行。允许和阻止的决定会与时间戳一起记录。门禁还定义了什么才算批准，例如已获批的变更工单，或发布经理的签字。

完整示例：受监管企业的托管设置

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

{
  "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 防止秘密信息进入 Agent 的上下文，并阻止工具任意访问外部网络；permissions.allow 则预先批准安全的内部循环，避免拒绝列表演变为提示疲劳。

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

sandbox 弥补了权限机制无法覆盖的缺口。在工具层禁止 WebFetch，并不能阻止 Shell 命令访问网络；操作系统层的域名允许列表则会彻底阻止网络外联。

failIfUnavailable 和 allowUnsandboxedCommands 让沙箱成为一道门禁：当沙箱无法初始化时，Claude Code 会拒绝启动；在沙箱内失败的命令也不能转到沙箱外重试。

credentials 弥补拒绝规则留下的缺口。permissions.deny 管理 Claude 的文件工具，但默认情况下，沙箱中的 Shell 命令仍可能读取 ~/.ssh 或 ~/.aws/credentials。这一配置块会拒绝这些读取操作，并从每个沙箱命令的环境中移除指定的秘密变量。

allowManagedHooksOnly 表示只有本实践项中的审批门禁 Hooks 可以运行；任何本地配置都不能增加或替换它们。

disableSideloadFlags 和 strictKnownMarketplaces 表示工程师机器上的每项 Skill、Agent、Hook 和 MCP 服务器都来自组织批准的插件市场，而不是从用户主目录旁加载。

allowManagedMcpServersOnly 将 Agent 的工具集合限制为由平台团队管理的允许列表。

requiredMinimumVersion 会拒绝在低于批准版本的 Claude Code 上启动，从而确保这些控制措施由组织真正评估过的构建版本执行。

应将以上内容视为可供调整的起点，而不是照抄建议。每一项拒绝规则都会以能力为代价，正确的平衡取决于仓库中的数据分类。设置参考文档列出了所有配置键，包括仅能托管的设置：code.claude.com/docs/en/settings。

如何衡量 Hooks 本身

领先指标

等待每道审批门禁所花费的时间。每个 Hook 决定都会写入 OpenTelemetry 导出，包含时间戳以及允许或阻止的判定，因此可以看到每道门禁的等待时间。

滞后指标

从事故跟踪系统中，对比使用 Hooks 前后进入生产环境的门禁违规数量。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code；将执行放入沙箱，使长时间运行的 Agent 能够安全运行；通过 MCP 集成向 Agent 提供部署能力；并在 Agent 真正需要回滚之前，反复演练回滚路径。

传统方式

流水线运行确定性脚本，任何需要判断的事情都要等待人工处理，例如判断不稳定测试、编写变更日志，或找出构建失败的原因。部署和回滚依赖人在压力下执行运行手册。

AI 原生方式

Claude 在流水线内部以非交互方式处理需要判断的步骤，并运行在使用限定凭据的沙箱中。部署工具通过 MCP 暴露给 Agent，因此，编写并测试变更的同一套工作流也能发布或回滚它；所有操作都位于组织为不同环境定义的门禁之内。

开始使用

前置条件

Claude 已进入 PR 评审循环，并且 Hooks 已充当审批门禁。必须先建立门禁，才能让自动化加速工作从中通过。

基础设施

安装了 claude-code-action 的 CI 平台，或任何能够调用 claude -p 的 Runner；通过 API 访问模型，如果流量必须留在组织的云协议内，则使用 Bedrock、Foundry 或 Vertex；用于部署目标的 MCP 服务器；以及为 Agent 任务准备的沙箱配置，默认不提供长期有效的生产凭据。

如何执行

1. 平台工程师从只读的判断步骤开始。在流水线任务中使用 claude -p 对失败构建进行分诊、总结不稳定测试，或起草变更日志。
2. 在现有门禁之后增加写入步骤，用于修复 Lint、更新生成文档，或通过 @claude 提及处理评审意见。Agent 写入的任何内容都会通过分支保护以 PR 形式进入，而且 Agent 没有直接推送到主分支的路径。
3. 所有执行都在沙箱中进行。Agent 任务在应用网络策略的容器中运行，只使用短期、限定范围的令牌，而且默认不持有生产凭据。
4. 通过 MCP 提供部署能力。部署、状态查询和回滚都变成按环境限定权限的工具，使 Agent 的部署能力成为允许列表，而不是一段携带凭据的 Shell 脚本。
5. 按环境划分自治等级。在开发环境中，Agent 可以自由部署；在生产环境中，Agent 准备发布，由发布经理授权，再由 Hook 强制执行生产门禁；预发布环境位于两者之间。
6. 回滚应当是流水线中演练最充分的路径。它应是一条 Agent 可以运行的单一命令，并定期在预发布环境中演练。阶段 6“维护”中的闭环实践项会在突破控制区间时调用该回滚路径，所以必须提前证明它有效。

流水线步骤示例

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

治理注意事项

治理原则是：Agent 可以行动到生产门禁为止，但不能越过它。以下控制措施用于执行这一原则。

• 分支保护会把 Agent 编写的任何内容变成 PR，使其不存在直接进入主分支的路径。
• 生产部署 Hook 会阻止发布，直到指定发布经理授权。每次非交互运行都使用 Agent 自己的身份，因此，流水线日志可以区分 Agent 的操作与触发任务的工程师所做的操作。
• 每个环境的分级权限决定 Agent 在抵达门禁之前能够执行多少操作。

如何衡量

领先指标

无需通知人工即可完成分诊的流水线失败占比，取自 CI/CD 流水线日志。

滞后指标

DevOps Research and Assessment（DORA）指标；现有 CI 系统和部署工具已经会产生这些数据。

06 维护

循环在这里闭合。某个触发器会在调用路径中没有人的情况下启动 Claude，而 Claude 的发现会以 intent.md 的形式重新进入流水线。

维护与闭合循环

到目前为止，我们讨论了如何把 Claude 加入 SDLC 的每一个阶段，每个阶段的初始步骤仍需要由人启动。但在这个阶段，重点会转向让 Claude 自主运行，从而闭合循环。

例如，一个持续运行的监控 Agent 可以在缺陷工单创建后生成 intent.md，并依次流经需求、计划、构建、测试和评审阶段。阶段 6“维护”以无界面方式运行；各阶段之间设置独立的置信度门禁，由确定性检查或对抗性评审 Agent 判断上一阶段的产出应继续向下流转，还是升级给人处理。

传统方式

维护是一个被动响应阶段。所有工单和事故都要等待某个人采取行动并重新启动流程。凌晨三点触发的告警可能被错过；工单可能一直留在待办列表，直到有人领取；如果又发生新的事故，事后复盘中的行动项甚至可能永远无法进入代码库。

AI 原生方式

突破控制区间、工单、频道消息或定时计划等触发器，会在路径中没有人的情况下调用 Claude。Claude 进行诊断，只能通过设置了门禁的路径行动，并把发现写成 intent.md，再进入上述各阶段。人负责分诊和评审这些工作，而不必亲自启动它们。

闭合循环

一段确定性脚本监视生产环境，并在突破控制区间时调用 Claude。监控区间突破是展示自主循环运行模式的好例子；本阶段最后的 Claude Tag（公开 Beta）部分，则会介绍通过其他渠道进入的工作。

开始使用

前置条件

能够为循环提供结构化输出、使其重新启动的 intent.md；由 Claude 加速的 PR 评审；作为行动边界的 Hooks；以及 CI/CD 回滚路径——最高自治等级会调用这条路径。

基础设施

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

如何执行

1. 服务负责人或平台工程师选择一项拥有稳定滚动基线的指标，例如 CI 测试失败率、部署后 5xx 比率或 PR 周期时间。
2. 编写检测脚本。常见做法是在滚动窗口上计算均值与标准差，并使用规则（例如 Western Electric Rules），让控制区间既能捕捉缓慢漂移，也能捕捉尖峰。脚本受版本控制并具备单元测试；检测过程始终完全确定，不使用模型。
3. 在受版本控制的配置中定义响应等级（参见下方 bands.yaml）。达到 1σ 时，脚本只记录日志；达到 2σ 时，以只读方式调用 Claude 进行诊断；达到 3σ 时，Claude 可以行动，但只能创建进入评审门禁的 PR，或者触发预先批准的运行手册。
4. 触发层可以是 GitHub 或 GitLab 中的定时工作流、现有监控栈发出的 Webhook，或网络内部的 Cron Job。Claude 以无状态方式运行：可以作为 CI Runner 中的非交互步骤，也可以作为沙箱容器中的 Agent SDK 服务。CI/CD 实践项介绍了部署和模型访问选项。由于运行无状态且非交互，一个循环可以在无人启动的情况下自行开始和结束。
5. Agent 按照阶段 1“规划”的格式，把诊断写成 intent.md，内容包括异常及其证据、建议结果、受影响的系统和所有开放问题。之后，这项发现像其他工作一样进入流水线。
6. 服务负责人或值班工程师对队列进行分诊，把面向产品的发现转交给产品负责人。选择立即修复、排期或忽略。忽略决定可以用来调节控制区间，帮助减少噪声。
7. 修复上线后，为这起事故增加一项评测（持续评测实践项），确保今后能够防止同类问题。

示例：监控 CI 测试失败率的 bands.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] }

治理注意事项

各响应等级的边界由受版本控制的配置强制执行，权限和托管设置会拒绝生产访问。每次调用、发现和分诊决定都会与时间戳一起记录。服务负责人负责分诊和批准发现；由此产生的变更必须通过正常 PR 评审门禁；Agent 可以触发的运行手册均已提前获批。

如何衡量

领先指标

从突破控制区间，到分诊队列中出现 intent.md 所花费的时间，与过去从事故发生到形成复盘行动项的时间对比。检测脚本日志包含突破时间戳和事故等级。

滞后指标

最终变成已合并修复的发现占比，可以对比分析分诊队列与实际 PR 历史；以及同类事故的重复发生次数。随着修复不断向评测套件添加案例，重复事故应当减少。

示例

• 当 CI 测试失败率突破 3σ 时，Agent 隔离不稳定测试，或创建回滚 PR，再由评审门禁作出决定。
• 当部署后 5xx 比率突破 3σ，并且时间窗口内存在一次部署时，Agent 触发现有回滚流水线。
• 当 PR 周期时间触发漂移规则时，Agent 为工程管理层编写报告；这说明这套运行框架既适用于生产指标，也适用于流程指标。

检测始终保持确定性。只有突破控制区间后才调用 Claude，响应等级则决定它可以做什么。

让 Claude Tag 与 Claude 一起值班

事故也可以通过 Slack 或 Teams 等工作沟通应用进入。例如，事故频道中可能在晚上十点出现一条要求紧急修复的 Slack 消息，而现在它可以立即得到处理。Claude Tag（目前在 Slack 中提供公开 Beta）使 Claude 以自己的身份成为这些频道的成员，于是每起新事故都有一个第一响应者，而响应本身也会成为循环的一部分，并成为未来事故的记忆。

对话和组织知识会保留在频道中，频道中的任何人都可以引导响应并推动行动。任何团队成员都能实时检验假设、探索新方案和开展调查，而频道历史会增强过程的可审计性。通过 MCP 访问，Claude 可以验证指标已经恢复基线，并在线程中确认；还可以把事故复盘写入受版本控制的经验文件，供未来调查读取。

Claude Tag 接收的不只是事故。无论是通过 MCP 在工单上标记它，还是在频道中向它提出要求，Claude 都会以相同方式分诊工作。小型且边界明确的修复会以 PR 形式进入评审门禁；更大的工作则被写成阶段 1“规划”的 intent.md，从那里开始，循环会自行供给下一轮工作。

频道就是审计轨迹：请求、诊断、人工授权和修复，都保留在事故得到处理的地方。

结语

模型和智能体运行框架已经变得更加先进，使组织不仅能够改变生产代码的方式，还能改变整个软件开发生命周期。

这场转型始终把人的判断置于流程核心，同时考虑大型企业的治理与监管要求。

本指南汇集了应用 AI 团队每天为客户实施的许多真实最佳实践。我们希望它是一份实用、可以采取行动的资源。

循环持续运行，人的判断始终位于循环之上。

资源与致谢

以下文档包含平台团队建立这些控制措施时需要的内容，顺序大致对应建议的实施次序：

• 为组织设置 Claude Code——管理员决策图；从这里开始
• 设置参考与优先级，包括所有仅能托管的配置键
• 来自 Claude 管理控制台的服务器托管设置
• 权限
• 沙箱——操作系统级文件系统与网络隔离
• Hooks——指南
• Hooks——参考
• Skills
• 插件与私有市场——如何在组织内分发 Skills 和 Hooks
• 托管 MCP——集中控制 Agent 的工具集合
• 企业部署概览——Bedrock、Vertex、Foundry
• 企业网络配置
• 监控（OpenTelemetry）
• 分析仪表板
• Compliance API——企业活动流、聊天检索与删除
• 安全模型

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献。本指南的灵感来自他们此前的大量工作，并在此基础上完成。