Claude Code AI 原生软件开发生命周期实战手册

原文链接：https://claude.com/blog/the-ai-native-sdlc-playbook发布时间：2026年8月21日

译者注：本文是 Claude Code AI 原生的一次实践，针对传统软件开发生命周期（SDLC）逐个阶段进行 AI 优化，最终进行完成交付，形成一个完美的闭环。操作上其实非常朴实无华，没有提到知识库、记忆这些概念，更没有 loop/graph，依旧是基于 CLAUDE.md、Skills、SubAgent、Hooks、Goal 来进行优化和构建，但每一项能够做到依旧不容易，文章较长，建议收藏慢慢观看，以下是全文翻译。

代码不再是瓶颈

各类组织已经开始使用 AI 来编写代码，速度之快在一年前简直不可想象，但围绕代码的流程却没有跟上同样的节奏。

许多工程团队仍然沿用相同的审批关卡、代码评审、工作交接和制度规范，白白拖慢了使用 Claude Code^[1] 等 Agent 编程方案所带来的生产力提升。

软件开发生命周期 (Software Development Lifecycle, SDLC) 是将软件从创意推进到生产环境的完整过程。大多数组织运行的都是同一套六阶段流程的某种变体，涵盖规划、设计、构建、测试、部署和维护软件。传统上，每个阶段都是一个独立的环节，由不同角色负责。产品经理编写需求，技术架构师将其转化为设计方案，工程师实现这些设计，受监管企业的 QA 团队负责验证，发布团队负责上线，运维团队监控运行中的系统。工作通过文档、工单和签批在各阶段之间流转。

传统的 SDLC 之所以流程繁重，是为了确保每一步都有问责和控制。然而，传统 SDLC 的设计初衷是在编写和实现代码最耗时、最昂贵的年代最大化效率——而这个前提已经不复存在。PRD (产品需求文档)、估时仪式和产品安全评审的存在，都是为了在可能持续数周、数月甚至数个季度的开发工作中强制对齐认知。

传统 SDLC 还设置了假设每一步都由人类执行的控制机制。那些创造最大价值的组织，已经围绕 Agent AI 现在能做的事情重建了流程，同时确保人类始终在环中。在本指南中，我们将介绍 Applied AI 团队在内部各 SDLC 阶段集成 Claude 以加速开发和提升流程效率的多项最佳实践，这些实践源自我们与客户的合作经验。

当代码不再是瓶颈，构建阶段的速度超越了传统 SDLC 所能容纳的上限时，三件事变成了现实：

• 瓶颈转移到了构建阶段的左右两侧。主要是规划、评审/测试和部署——这些仍然以人类速度运行。
• 控制机制与现实脱节，变得难以为继。逐行人工评审在代码由人类编写时是合理的，但当 Agent 生成了大部分代码差异时，这种方式根本跟不上。
• 治理成本上升，因为例外情况仍然要经过每周或每月召开的会议和委员会来处理。

构建不再是约束——围绕它的人类速度阶段才是。人类速度的阶段保持原有时长，而构建阶段压缩到了数小时。

让我们以安全瓶颈为例。安全团队的人员配置是按人类产出规模规划的，因此当 Agent 成倍增加代码产出时，要么评审队列越积越长，要么代码在未经充分审查的情况下上线。受监管的组织两种结果都不能接受，因此其安全和合规检查必须跟上 Agent 的节奏。

为了更好地实现 Agent AI 的生产力收益并确保其安全性，传统 SDLC 需要经历与实现阶段同等程度的变革。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一个重新构想的流程，它将旧有的控制目标与新的执行方式相结合。流程不再是线性的，而是变成了一个循环，AI 嵌入在每个节点中。AI 原生 SDLC 促进了自动化交接和后续步骤的触发，有助于解决传统 SDLC 各阶段之间手动且笨拙的交接问题。

关键转变

下表列出了传统 SDLC 与 AI 原生 SDLC (由 Claude 支持) 之间的两极对比。大多数组织处于两列之间的某个位置。

阶段	传统 SDLC	AI 原生 SDLC
规划	需求由委员会收集，通过研讨会和签批层层提炼，手动撰写	Claude 直接从来源综合痛点，并将其记录为人类可读、机器可操作的 `intent.md`
设计	规格由分析师撰写，设计师解析	需求和设计压缩为与 Agent 的一次工作会话，由编码为 skills 的标准指引，纳入 git 版本管理
构建	测试和代码手工编写，文档在主体开发完成后才撰写	测试和代码由 AI 生成，机构知识以版本化的机器可读 `CLAUDE.md` 文件和 skills 形式维护
测试	在阶段边界设置 QA 关卡	持续评估贯穿实现过程
部署	人类逐行审查代码，治理在评审周期中进行，往往不一致	多层 Agent 评审，人工评审仅保留给受监管和关键代码。治理在 AI 行动时即时执行，hooks 作为审批关卡
维护	人类监控生产环境寻找 bug	Agent 监控线上部署。任何违反控制带的情况都会被诊断，并作为新的 `intent.md` 写回循环

贯穿右列的主线是已提交的产物 (artifact)。每个阶段以向版本控制提交一个产物结束 (包括 intent.md、spec.md、plan.md、代码差异及其测试、PR 及其评审发现、以及事件记录)，下一个阶段则以读取该产物开始。在早期阶段，.md 文件是主要产物，因为产品负责人和 Agent 都能读取和操作同一文件。从构建阶段开始，产物就是代码及其记录。提交链同时也是审计追踪：谁提出了什么请求，Agent 产出了什么，谁批准了它。

人类对每一个需要判断的决策负责。在 Agent 化的 SDLC 世界中，人类的注意力随着必须审查的产物而转移。

每个阶段都会提交一个下一阶段可以读取的产物。intent、spec、plan、代码差异和评审发现共同构成了审计追踪。

实战剧本

这些剧本是本手册的核心，分为六个非线性阶段 (规划、设计、构建、测试、部署、维护)，共同覆盖完整的生命周期。

每个剧本包含：

• 变化了什么；
• 如何开始；
• 具体实施步骤；
• 治理考量；以及
• 如何衡量效果。

这些步骤是模块化的，组织可以根据自身独特需求选择在不同时间优先转型不同的阶段。每个剧本在"前置条件"下列出了其依赖项，依赖图进一步说明了这些关系。

一个阶段以提交产物结束，该提交启动下一个阶段。一个被接受的 intent.md 触发需求和设计环节，一个被批准的 spec.md 触发计划模式，一个合并的 PR 触发流水线，而生产环境中违反控制带的情况则写入下一个 intent.md——循环由此延续。

首先，你手动提示每一步，最终状态是一个循环——每个被接受的产物触发下一个关卡。人类的注意力集中在关卡处，审查 Agent 标记的内容，而不是从头开始每个阶段。

剧本按阶段列出；箭头给出了采纳的顺序。两者并不相同。从任何基础剧本 (clay play) 开始——没有箭头指向它，因此它不需要任何前置条件。对于其他任何剧本，指向它的箭头就是需要先采纳的剧本。

01 规划

创意不再等待有人来撰写。意图一次性捕获，用发起人自己的话语，作为下一阶段可操作的版本控制产物。

捕获为 intent.md

启动软件开发流程的 intent.md 可以通过不同路径进入。一个人有了想法，提交了一个工单，或者通过告警浮现了一个事件 (参见第六阶段：维护)。

当一个人有了想法时，他们与 Claude 进行头脑风暴并生成一份 Markdown 格式的原型规格说明。在传统 SDLC 中，这个人接下来必须说服产品团队的成员与他们一起或代表他们把想法写下来。

Claude 生成的原型规格说明是人类可读的、版本控制的，并且可以立即被下一阶段消费。原型规格说明保存为 intent.md。

无论 intent 源自事件触发还是 Agent，相同的步骤都适用：产品负责人在提交之前审查并修正 Agent 编写的 intent.md。

传统方式：一个想法经过待办事项、用户故事、故事点和需求精炼会议后才有人能着手处理。每次交接都转移了所有权，因此到达工程团队的内容已经与发起人的原意隔了好几层。

AI 原生方式：发起人与 Claude 进行头脑风暴，并将结果写为 intent.md——一份用发起人自己的语言表达的原型规格说明。该产物包含想要什么、为什么以及在什么约束下。重复性流程通过 skills 编码。

如何开始

前置条件

无。

基础设施

为非工程师人员提供 Claude 访问权限 (claude.ai 或 Cowork^[2])；一个约定的 intent.md 模板；一个共享的、版本控制的 intent 存放地，产品负责人会关注该位置。对于单个产品，最简单的存放地是产品仓库中的 intent/ 文件夹。这种设置让产物链与由其派生的代码紧邻。只有当 intent 跨越多个仓库时，专门的 intent 仓库才值得额外开销；在 monorepo 中它就是一个目录。第三阶段：构建的侧边栏介绍了此存放地与已有的 Jira 或需求工具之间的关系。

这是平台或工程团队的一次性设置任务。技术团队成员需要搭建 intent 存放地并决定谁可以写入，因为许多贡献者来自组织各处。

仓库建立后，没有 git 经验的贡献者无需直接使用 git。相反，一个连接到版本控制系统 (如 GitHub) 的连接器让 Claude 可以代替他们从 claude.ai 或 Cowork 提交 Markdown 文件。

如何执行

1. 发起人用自己的话向 Claude 描述问题。发起人可以描述今天做不到什么、谁受这个想法影响、什么样算更好、或什么不在范围内。不需要正式语言。
2. 头脑风暴直到想法具体化。Claude 会提出分析师会问的问题：范围、用户、约束以及成功的标准。
3. 要求 Claude 使用组织的模板将结果写为 intent.md，该模板可以编码为由技术团队成员设置并由负责人签署的 skill。这可以涵盖问题、期望结果、受影响的用户和系统、约束以及待解决问题。
4. 发起人修正 Claude 误解的任何内容。
5. 将 intent.md 提交到共享存放地。作者和时间戳加入记录，产品负责人从此处接手这个想法。

# Intent: 理赔状态自助查询作者: J. Ortiz (理赔运营)。状态: 草稿。## 问题客户打电话到联络中心询问理赔进度。处理人员大约三分之一的通话时间花在仅查询状态上。## 期望结果客户可以在门户中看到理赔状态、下一步和预计日期。## 受影响的用户和系统理赔处理人员、门户团队、claims-core API。## 约束门户会话中不引入新的 PII。仅使用现有认证。## 待解决问题第三方损失评估师也需要访问权限吗？

治理考量

证据就是已提交的 intent.md，其中列出了作者、时间戳和完整的修订历史。它记录在 intent 存放地的 git 历史中。产品负责人批准，将 intent 送入第二阶段：设计的接受或拒绝决定以合并或关闭评审的形式记录。

如何衡量

先行指标

从第一次对话到提交 intent.md 的时间，从 intent 存放地的 git 历史中读取 (记录了作者和时间戳)。预期从多周的需求引出和精炼周期缩短到数小时。

滞后指标

存活率，即产品负责人接受进入第二阶段：设计的 intent.md 文件占比，而非被关闭的。接受或拒绝决定以产物的合并或关闭评审的形式记录。此外，还有在同一变更的首次 spec.md 提交之后对 intent.md 所做修改的数量。

02 设计

需求和设计压缩为一次会话。策略在规格编写时就被应用，而不是在数周后的评审中才被发现。

需求与设计

一旦产品负责人批准，Claude 接收被接受的 intent.md 并生成需求和设计规格。这一过程受到组织的品牌、安全、合规和用户体验 skills^[3] 的指引。

产品负责人审查该规格，但不需要自己编写。这个流程的目标是创建一份工程团队可以据此制定计划的规格，并标注关注领域。

前端工作是最清晰的例子。一旦 intent.md 被接受，产品负责人在 Claude Design^[4] (测试版) 中基于 intent.md 制作设计稿，迭代设计稿，然后导出到 Claude Code 进行构建。

传统方式：需求和设计是由不同团队运行的独立阶段。分析师将想法形式化为需求，设计师再将其解析为设计方案。这种分离是为了问责，但既慢又有信息损耗。

AI 原生方式：两个阶段在一次带提示的会话中完成。Claude 接收 intent.md 并生成需求和设计规格，受组织 skills 的约束，并标注关注领域。

如何开始

前置条件

编写一份 intent.md 文件，品牌、安全、合规和用户体验策略以 skills 形式编写。

基础设施

一位拥有 Claude 访问权限的产品负责人。不需要工程技能。

如何执行

1. 产品负责人打开一个加载了组织 skills 的会话，并附上 intent.md。
2. 产品负责人的提示指向 intent.md，指定约束条件，并要求标注关注点。起初手动执行，然后将其编码为组织级的斜杠命令。之后让 intent 存放地中 intent.md 的接受成为触发器——在合并时触发一个非交互式任务，加载组织的 skills 运行此环节，并以拉取请求 (Pull Request) 的形式提交 spec.md (第五阶段：部署中的 CI/CD 剧本涵盖了相关基础设施)。从那时起，产品负责人的首次介入就是评审。
3. 同一位产品负责人对照想法审查规格。规格是否解决了陈述的问题，intent.md 中的待解决问题是否得到了回答或向后传递？
4. 优先处理标注的关注点，因为这些是分析师会升级的要点。产品负责人在工程团队看到规格之前，与相应的策略负责人逐一解决。
5. 将 spec.md 与 intent.md 一起提交。这对文件记录了所请求的内容和所做的决定。
6. 产品负责人决定规格和意图是否进入构建阶段，对于组织归类为高风险的内容需咨询技术负责人。这个决定始终由人类团队成员做出，接受规格即启动第三阶段：构建中的计划模式剧本。

示例 (提示词)

读取附件 intent.md 并生成将其集成到我们现有代码库的需求和设计规格。应用你可用的 skills，使方案符合我们的品牌指南、安全策略和用户体验标准。将规格完整记录为 spec.md，可直接交付给工程团队。清晰描述任何关注领域，特别是你无法满足相互矛盾的策略的地方。

治理考量

策略不是在数周后的评审中才被发现，而是在编写规格时就被读取和应用。组织的 skills 作为约束应用于规格。规格、生成它的提示词以及当时生效的 skill 版本都记录在版本控制中。产品负责人签署规格，并将标注的关注点路由给指定的策略负责人。

如何衡量

先行指标

同一变更的 intent.md 提交与 spec.md 提交之间的经过时间 (两个 git 时间戳)，与旧的需求加设计周期进行对比。

滞后指标

构建开始后的需求返工。统计日期晚于同一变更首次 plan.md 提交的 spec.md 提交数。Git log 可以直接提供这一数据。

03 构建

没有被接受的计划就不实现任何东西。机构知识变成 Agent 在每次会话开始时读取的文件，护栏以代码而非习惯的形式运行。

Claude Code 计划模式作为默认起点

工程师以计划模式^[5]启动 Claude Code 会话，将第二阶段：设计中批准的 spec.md 交给 Claude，让它像面试一样提问，在计划上反复迭代，直到工程师满意为止。

传统方式：工程师阅读设计文档然后开始写代码。变更将如何实现——具体到哪些文件、哪些测试——留在工程师脑中，最多写在工单评论里。没有其他人能审查它。评审者看到的第一样东西是完成的代码差异，到那时返工已经很慢了。

AI 原生方式：工作从 Claude 在计划模式下产出的书面计划开始，在该模式中 Claude 可以读取代码库但不能做任何修改。工程师在代码编写之前修正计划，批准的版本作为 plan.md 提交，供后续阶段对照检查。

如何开始

前置条件

意图产物 (intent.md 或 spec.md)，如果存在的话；CLAUDE.md 文件也有帮助。

基础设施

具有仓库访问权限的 Claude Code。

如何执行

1. 工程师以计划模式与 Claude 开始会话。
2. 工程师将 intent.md 和 spec.md 交给 Claude，要求一份实现计划，列出变更的文件、工作顺序以及证明其正确性的测试。
3. 质询计划：问这个变更可能破坏什么、哪一步风险最大、以及 Claude 选择不做的其他方案是什么。
4. 反复迭代，直到一个从未看过对话的工程师也能仅凭计划独立实现该变更。
5. 将批准的计划作为 plan.md 提交。计划加入审计追踪，第五阶段：部署中的 PR 评审剧本会将最终的代码差异与之对照。
6. 接受计划并让 Claude 实现。有了扎实的计划，实现通常一次通过。
7. 当实现偏离计划时，在同一个提交中更新 plan.md。可以考虑使用 hook 来强制两者同步。

示例 (plan.md)

# 计划: 理赔状态自助查询 (源自 intent.md 2026-06-02)## 变更的文件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 覆盖四种理赔状态；截图与批准的设计稿一致。

治理考量

设计评审发生在生成任何代码之前，此时改变方向仍然只是编辑文档的问题。计划模式本身就强制执行了这一点，因为在工程师接受计划之前 Claude 无法编辑文件。计划及其修订连同谁批准了它一起被记录。常规变更由工程师批准，组织归类为高风险的内容则提交给技术负责人或架构师。

如何衡量

先行指标

从首次实现即合并的变更占比，以及从计划批准到 PR 合并的时间 (所需数据在 PR 元数据中)。

滞后指标

每次变更的返工周期 (同样来自 PR 元数据)，以及合并的代码差异仍然与已提交的 plan.md 匹配的频率。

Claude Code 自动模式

Claude Code 还可以在自动模式 (auto mode) 下运行，工程师批准计划后，一旦满意并经过迭代，Claude 无需逐次编辑确认即可应用每个变更。随着后续剧本中的护栏日趋成熟 (经过调优的 CLAUDE.md、编码策略的 skills、阻止不安全操作的 hooks、以及 Claude 可以运行的测试套件)，自动接受模式成为常规工作的默认选择：紧凑的 spec.md、小的影响范围、以及测试已经覆盖的代码。

现在的转变是从用户看着 Agent 进行编辑并审查操作，转向在更长的自主会话之后审查产物。自动接受模式在与工作树 (worktrees) 配合使用时进一步实现了个人和团队层面的并行化，并且是自主运行 SDLC 和闭合循环 (如第六阶段：维护中所述) 的基础。

遗留系统与唯一信息源

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

现有的 SDLC 流程可能已经在追踪产物，只不过不是以 Markdown 文件的形式。工作项可能在 Jira 中，需求在带有法规可追溯性的工具中，设计在 Figma 中，变更审批在变更委员会中。这些系统很难替代，因为审计员和监管机构已经接受了它们，且其他团队依赖于它们，所以 AI 原生 SDLC 必须适配现有系统。

在过渡到 AI 原生 SDLC 时，对于流程产生的每一个产物，指定一个系统作为唯一信息源 (source of truth)，其他一切仅保存副本或指向原始记录的链接。以下配置可以设置为拥有一个唯一信息源，不同产物的选择可以不同：

以仓库为唯一信息源。 Markdown 产物是权威记录，遗留系统引用提交中的文件。对于工程主导的组织，这可能是最简洁的配置，因为所有记录都在一个工具中，拥有统一的时间戳权威。

以遗留系统为唯一信息源。 Jira、ServiceNow 或需求工具持有权威记录，Markdown 产物是工作副本。Claude 在会话开始时读取记录，并在同一个产出规格或计划的会话中通过 MCP^[6] 连接器将结果写回。

以链接为最低门槛。 所有产物注明记录 ID，所有遗留系统记录包含 Markdown 文件的提交 SHA。在过渡到 AI 原生 SDLC 时，链接是一个良好的起点，接受存在两个信息源的现实。

遗留系统和 Markdown 优先系统可以共存，只要两者之间有链接或其中一个被声明为唯一信息源。

CLAUDE.md

CLAUDE.md^[7] 为 Claude 提供了新人入职第一天所需的上下文，涵盖规范约定、命令、架构以及团队最常见的错误。曾经存在于人们脑海和 Wiki 中的知识变成了 Agent 在每次会话开始时读取的文件，由整个团队维护，并在每次犯错时迭代更新。

如何开始

前置条件

无。

基础设施

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

如何执行

1. 在仓库中运行 /init。Claude 根据所发现的内容生成初始的 CLAUDE.md。
2. 将生成的文件精简为新人第一天所需的内容。保留构建、测试和 lint 命令，重要的约定，以及 Claude 经常犯错的地方。
3. 将 CLAUDE.md 检入仓库根目录的 git，这样整个团队共享一个版本，变更像代码一样经过评审。
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>/ 中使其随代码一起发布，或通过插件^[8]在组织范围分发。
4. 测试 skill 是否触发。以不同方式要求 Claude 执行相关任务，确认 skill 每次都加载。
5. 当策略变更时，修改 skill 并让策略负责人签署变更。
6. 工程师在下一次会话中自动获取新版本。

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

---name: secure-api-reviewdescription: 应用 API 安全标准。在创建或修改外部端点、  审查 API 代码或生成 OpenAPI 规格时使用。---# 安全 API 审查当你创建或变更一个 API 端点时：1. 认证：每个端点需要网关 JWT；   /health 之外不允许匿名路由。2. 输入验证：根据 OpenAPI schema 验证请求体，   拒绝未知字段。3. 审计：每个状态变更端点发出审计事件，   包含操作者、动作、实体和时间戳。4. 数据分类：schema 中标记为 pii 的字段   绝不能出现在日志或错误消息中。运行 scripts/check-endpoints.sh 并在摘要中包含其输出。

治理考量

Skill 是一种控制手段，但属于建议性的。它使 Claude 在编写代码时更可能应用策略，但没有任何东西强制会话遵守它。必须始终成立的策略需要在 skill 背后有确定性的机制支撑——比如阻止操作的 hook 或在 PR 时重新检查策略的评审环节。Skill 让违规变得罕见，而 hook 让违规几乎不可能。Skill 的调用记录在会话跟踪中，策略负责人像审查代码一样审查 skill 的变更。

如何衡量

先行指标

从策略负责人批准策略变更到更新后的 skill 合并的时间 (从 skill 文件夹上的 PR 获取)。

滞后指标

引用该策略的 PR 评审发现应趋向零。当发现数量没有趋向零时，要么是 skill 没有触发，要么是其文本已偏离官方策略。

Hooks 作为构建时护栏

Skill 是建议性控制，而 hook^[9] 是其背后的确定性层。Claude 在实现过程中的大多数操作是文件编辑和 shell 命令，因此构建阶段是 hooks 可能最频繁触发的地方。

构建阶段的 hooks 可以：

• 阻止对受保护路径 (如生成的类或冻结的包) 的编辑；
• 在文件编辑后运行格式化器和 linter，使偏差不会积累；
• 阻止凭据进入代码差异。

为任何策略必须无一例外成立的 skill 提供 hook 支持。Hook 在每个匹配的操作上运行，因此构建阶段的 hooks 应当快速且范围限定在变更的文件。更重的检查 (如完整测试套件) 属于提交或 PR 环节。

在构建过程中请求人工批准的 hook 属于第五阶段：部署中的关卡，因为在构建中的批准提示会将人类重新放到所有并行运行会话的关键路径上。

并行会话和子 Agent

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

并行会话是另一个完整的 Claude Code 实例，在其独立的 git 工作树^[10]中处理独立的任务。每个独立会话对其他会话一无所知，驾驭它们的工程师是它们唯一的共同点。

子 Agent (subagent)^[11] 在单个会话内作为有范围限制的助手运行，拥有自己的上下文窗口和工具限制，适合在多个任务中反复出现的工作，比如验证应用是否按预期运行。

并行会话提升了一位工程师同时处理的任务数量，而子 Agent 使每个会话专注于自己的任务。工程师的工作是驾驭和审查所有这些。

传统方式：一位工程师一次处理一个任务，一天或一周中很大一部分时间花在构建、测试和等待评审上。在等待时切换任务是可能的，但上下文切换足够令人疲惫，以至于很少有人选择这样做。

AI 原生方式：一位工程师同时运行多个 Claude 会话，每个会话在自己的工作树中处理自己的任务。重复性工作变成拥有自己上下文和工具限制的子 Agent。工程师的工作转变为编排，最终转变为构建和监控循环。

如何开始

前置条件

CLAUDE.md，因为所有会话都读取该文件。反馈循环 (第四阶段：测试) 在这里也有帮助，因为当会话能验证自己的工作时，工程师需要的监督就更少。

基础设施

一个 git 仓库，因为隔离来自工作树，以及调整过的权限设置，使会话不会在组织认为安全的命令上等待批准提示。

如何执行

1. 工程师将工作拆分为涉及不同文件的任务，使用计划模式剧本 (第三阶段：构建) 中的计划来看哪些工作是独立的。共享文件的任务在单个会话中依次运行。
2. 每个并行任务获得自己的工作树，例如在一个终端中运行 claude --worktree feature-auth，在另一个中运行 claude --worktree fix-rate-limit。工作树是在自己分支上的独立检出，防止会话在文件上发生冲突。
3. 两到三个会话是合理的起点。实际上限是一个人能正确审查多少个流，因此只在评审跟得上时才增加会话。
4. 将重复性工作转化为子 Agent，定义在 .claude/agents/ 中的 Markdown 文件中，每个包含名称、使用场景描述和可触及的工具。示例包括：代码简化器——在主 Agent 完成后剥离不必要的复杂性；验证器——运行应用并检查行为；研究者——探索代码库并报告而不淹没主上下文。将定义检入 git，使整个团队共享。

示例 (.claude/agents/verifier.md)

---name: verifierdescription: 运行应用并在会话报告完成前检查变更是否生效tools: Bash, Read---使用 make run 启动应用。测试变更的行为和两个最相近的相邻流程。报告你运行了什么、看到了什么、以及任何不符合 plan.md 的行为。不要修复任何东西；仅报告。

治理考量

更多的会话意味着更多的产出，因此控制必须来自仓库中的配置。其中的 hooks 和权限设置适用于所有会话，会话的行为被记录并归属于运行它的工程师。

如何衡量

先行指标

在评审质量保持不变的情况下每位工程师的并行会话数 (从 OpenTelemetry 导出中统计)，以及一天中花在驾驭而非等待上的时间占比。

滞后指标

每位工程师每周合并的变更数 (从 PR 历史中获取)，与返工率一起查看。

04 测试

每个会话在人类看到之前检查自己的工作，而驾驭 Agent 的配置像它编写的代码一样接受回归测试。

给 Claude 一个反馈循环

始终给 Claude 一种验证自己工作的方式，无论是测试、构建还是截图对比。会话在工程师看到之前检查自己的工作并修复自己的错误。

反馈循环不应与验证器子 Agent (第三阶段：构建) 混淆。反馈循环贯穿整个任务，随工作运行多次。而验证器子 Agent 是打包最终检查的一种方式——在会话认为工作完成后运行一个新的上下文窗口。这样判定就不会受到产出代码时的假设的影响。

传统方式：代码有效的信号来得很晚。CI 需要几分钟后，测试人员需要几天后，生产环境需要几周后。当 Agent 产出代码时，晚到的信号意味着一个人必须检查其所有输出，而这个人就成了瓶颈。

AI 原生方式：会话被赋予在人类看到之前检查自己工作的能力。运行测试、运行构建、截取屏幕截图。Claude 反复迭代直到检查通过，因此到达工程师手中的内容已经通过了检查。设置循环由运行会话的工程师负责，以下步骤就是为他们编写的。

如何开始

前置条件

无。

基础设施

一个测试套件和一个构建，各用一条命令即可本地运行。对于 UI 工作，Claude 看到结果的能力至关重要——通过 MCP 接入的浏览器工具或截图工具。

如何执行

1. 如果今天检查工作需要一系列命令和一些环境知识，将其包装为一个单一目标，如 "make test" 或 "npm test"，在失败时返回非零退出码。
2. 在 CLAUDE.md 的 Commands 部分，列出每个命令及其健康输出的示例。
3. 设定一个量化的目标，使 Claude 无需询问你即可检查工作，例如："test_status.py 中的所有测试通过"、"截图与附件的设计稿匹配"或"端点在新字段下返回 200"。
4. 对于 bug 修复，先写失败的测试。要求 Claude 将 bug 复现为测试，运行它，确认它因你预期的原因失败。提交该测试。然后才要求 Claude 在不编辑测试的情况下使其通过——最后一步中的测试文件 hook 强制执行这一限制。一个在修复之前就存在且 Agent 不能重写的测试，就是 bug 已修复的证明。
5. 对于 UI 工作，用视觉检查闭合循环。给 Claude 一个浏览器或截图工具，给它设计稿，让它迭代。实现、截图、对比、调整。两到三轮是正常的，每一轮结果都应有所改善。
6. 将验证作为"完成"的一部分。指令写在 CLAUDE.md 中：报告任务完成前运行测试，并展示输出。
7. 最后，循环本身需要保护——修复代码的 Agent 不能削弱对该代码的检查。一个在修复任务期间阻止编辑测试文件的 hook 可以做到这一点。替代方案是在评审中检查差异，拒绝任何涉及测试的变更。

示例 (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 和反馈循环 (第四阶段：测试)。

基础设施

能够非交互式运行 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 evalson:  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 获得相同的一组评审环节，发现按严重性排序。人类注意力上移一个层次——变更是否实现了计划的意图，风险是否可接受。

如何开始

前置条件

来自第三阶段：构建的更新后的 CLAUDE.md 文件；如果评审环节执行书面策略则需要 skills 和定义好的子 Agent。

基础设施

安装了 Claude 集成的仓库——管理员启用的托管 Code Review^[12] (研究预览) 服务，或在你自己 CI 中运行的 claude-code-action^[13]——在需要时通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 进行模型调用 (CI/CD 剧本涵盖部署选项)。要求代码所有者批准的分支保护策略也值得设置。

如何执行

1. 托管 Code Review 服务是最快的起步方式。管理员启用它并选择仓库。当你需要控制流水线或希望 API 调用通过自己的云协议路由时，使用 claude-code-action 在自己的 CI 中运行评审 (CI/CD 剧本涵盖该基础设施)。
2. 技术负责人在仓库根目录编写评审策略 REVIEW.md，按组织关心的环节划分：bug 和逻辑错误；安全和漏洞；与规格 (需求剧本中的 spec.md)、实现计划 (计划模式剧本中的 plan.md) 和设计原则的合规性。REVIEW.md 还定义了什么算 Important (重要) 而什么是 Nit (小问题)，以及什么应该跳过。
3. 技术负责人设定人工阈值。发现不会自行批准或阻止 PR，分支保护仍然要求代码所有者批准。想要以发现为合并关卡的平台工程师可以读取检查运行发布的机器可读严重性计数。
4. 当评审者或作者在评审评论中标记 @claude 时，Claude 处理评论并推送修复。PR 讨论线记录了请求和变更。此修复循环通过 claude-code-action 运行。在托管服务中，评论 @claude review 则请求一次全新评审。对于 Claude 开启的 PR，更进一步——让 Claude 看管 PR 直到合并。团队将循环包装为自定义斜杠命令：扫描 PR 上未解决的评审评论和失败检查，处理它们并推送修复，直到 PR 变绿且仅等待代码所有者批准。
5. 评审发现反馈进 CLAUDE.md。当评审第二次标记同一错误时，修正意见在该评审中写入 CLAUDE.md；由于评审读取 CLAUDE.md，该错误从下一个 PR 起就会被捕获。评审还会标记变更使 CLAUDE.md 过时的情况。
6. 每月一次，技术负责人通过对发现评分来调优设置，使评审者改进，并在 REVIEW.md 中限制 Nit 数量。生成的路径和 CI 已经强制执行的内容被排除。

示例 (REVIEW.md)

# 评审指南## 评审环节运行三个环节，并为每个发现标记所属环节：- Bug：逻辑错误、破损的边界用例、隐蔽的回归- 安全：注入风险、认证缺口、日志中的 PII- 合规：变更与 spec.md、plan.md 和我们的设计原则一致## 这里 Important 的含义仅对会破坏行为、泄露数据或违反策略的发现标记 Important。风格和命名属于 nit。## 限制 nit 数量每次评审最多报告五个 nit；其余汇总为计数。## 不要报告的内容src/gen/ 下的生成文件和 CI 已强制执行的内容。

治理考量

职责分离得到保持，因为编写代码的 Agent 无法自行批准代码。REVIEW.md 中的评审策略应用于所有 PR，发现、修复、评分和批准都记录在 PR 历史中——因此 PR 就是审计记录。批准通过分支保护由人类做出，以发现为依据。

如何衡量

先行指标

首次评审时间——应降至分钟级，以及无需人类触碰分支即解决的评审评论占比 (数据直接存储在 Git 上)。

滞后指标

合并前捕获的缺陷和漏洞与逃逸到生产环境的对比 (来自 PR 历史和事件追踪器)。

Hooks 作为审批关卡

构建阶段使用 hooks 作为护栏——允许或阻止操作，无需人类参与 (第三阶段：构建)。Hook 也可以发出询问，暂停操作直到特定人员批准——这正是发布把关所需要的。

这个剧本放在第五阶段：部署中，因为发布关卡是最清晰的案例，但 hooks 并非部署特有的：它们在 Claude 行动的任何地方运行。例如，hooks 可以在第三阶段：构建期间在没有变更工单的情况下阻止对迁移和基础设施的编辑，以及在第四阶段：测试的修复任务期间阻止 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 # exit 2 阻止操作; 消息发送给 Claude   fifiexit 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 命令访问网络；OS 级别的域名白名单直接阻断出口。

failIfUnavailable 和 allowUnsandboxedCommands 使沙箱成为关卡：当沙箱无法初始化时 Claude Code 拒绝启动，在沙箱中失败的命令不能在沙箱外重试。

credentials 弥补了拒绝规则留下的缺口。permissions.deny 管理 Claude 的文件工具，但沙箱化的 shell 命令默认仍可读取 ~/.ssh 或 ~/.aws/credentials；此块拒绝这些读取并从每个沙箱化命令的环境中剥离指定的秘密。

allowManagedHooksOnly 意味着此剧本中的审批关卡是唯一运行的 hooks；本地无法添加或替换它们。

disableSideloadFlags 和 strictKnownMarketplaces 意味着工程师机器上的每个 skill、agent、hook 和 MCP 服务器都来自组织批准的插件市场，永远不是来自主目录。

allowManagedMcpServersOnly 使 Agent 的工具面成为平台团队拥有的白名单。

requiredMinimumVersion 拒绝在低于批准下限的版本上启动，确保控制由组织实际评估过的构建版本执行。

以上应作为定制的起点，而非照搬的建议。每条 deny 都以能力为代价，正确的平衡取决于仓库的数据分类级别。设置参考文档记录了每个键，包括仅限托管的键：code.claude.com/docs/en/settings^[14]

如何衡量 (针对 hooks 本身)

先行指标

每个审批关卡的等待时间。每个 hook 决定都带时间戳和允许或阻止判定写入 OpenTelemetry 导出，因此每个关卡的等待时间清晰可见。

滞后指标

hooks 部署前后到达生产环境的关卡违规 (来自事件追踪器)。

CI/CD 集成与部署

在 CI/CD 流水线中非交互式运行 Claude Code，沙箱化执行使长时间运行的 Agent 安全运行，通过 MCP 集成暴露部署能力，并在 Agent 真正需要之前演练回滚路径。

传统方式：流水线运行确定性脚本，任何需要判断的事情都等人来处理。例如，分类不稳定测试、编写变更日志或弄清构建为何失败。部署和回滚是人在压力下执行的运行手册。

AI 原生方式：Claude 在流水线中非交互式运行判断步骤，在具有范围凭据的沙箱中。部署工具通过 MCP 暴露给 Agent，因此编写和测试变更的工作流也可以发布和回滚它——在组织为每个环境定义的关卡内。

如何开始

前置条件

PR 评审循环中的 Claude 和作为审批关卡的 hooks——因为关卡必须在自动化加速任何通过之前就位。

基础设施

安装了 claude-code-action 的 CI 平台，或任何可以调用 claude -p 的运行器；通过 API 访问模型，或通过 Bedrock、Foundry 或 Vertex (当流量必须留在组织的云协议上时)；用于部署目标的 MCP 服务器；一个不持有生产凭据的 Agent 任务沙箱配置。

如何执行

1. 平台工程师从只读判断步骤开始。在流水线任务中使用 claude -p 来分类失败的构建、总结不稳定测试或起草变更日志。
2. 在现有关卡之后添加写入步骤——用于修复 lint、更新生成的文档或通过 @claude 提及处理评审评论。Agent 写入的任何内容都作为 PR 通过分支保护到达，Agent 没有直接推送到 main 的路径。
3. 执行沙箱化。Agent 任务在具有网络策略的容器中运行，使用短期范围 Token，默认不持有生产凭据。
4. 通过 MCP 暴露部署。部署、状态和回滚成为工具，按环境划定范围——这样 Agent 的部署能力是白名单而非带凭据的 shell 脚本。
5. 按环境分层自主权。在开发环境中，Agent 自由部署。在生产环境中，Agent 准备发布而发布经理授权——hook 强制执行生产关卡。预发环境介于两者之间。
6. 回滚应该是流水线中演练最多的路径——一条 Agent 可以运行的单一命令，并定期在预发环境中验证。闭合循环剧本 (第六阶段：维护) 在控制带被突破时调用此回滚，因此它必须提前得到验证。

示例 (流水线步骤)

- name: 分类失败的构建  if: failure()  run: >    claude -p "读取 out/build.log 中的构建日志。找出最可能的原因，    说明失败看起来是不稳定还是真实的，并为 PR 讨论线写一个三行摘要。" >> triage.md

治理考量

治理原则是 Agent 可以做到生产关卡之前的一切，不能越过它。以下控制执行此原则。

• 分支保护将 Agent 写入的任何内容转为 PR，没有直达 main 的路径。
• 生产部署 hook 在指定的发布经理授权之前阻止发布。每次非交互式运行都以 Agent 自己的身份行动，因此流水线日志将 Agent 做的事和触发它的工程师做的事分开。
• 按环境的权限层级设定 Agent 在到达关卡之前可以做多少。

如何衡量

先行指标

无需呼叫人类即可分类的流水线故障占比 (从 CI/CD 流水线日志获取)。

滞后指标

DevOps 研究与评估 (DORA) 指标——CI 系统和部署工具已经在产出这些数据。

06 维护

循环闭合。触发器在调用路径中无需人类即可调用 Claude，而它发现的内容作为 intent.md 重新进入流水线。

维护与闭合循环

到目前为止，我们讨论了如何在 SDLC 的每个阶段加入 Claude，每个阶段都需要人类启动初始步骤。然而这个阶段将焦点转向 Claude 的自主运行以闭合循环。

例如，一个持续运行的监控 Agent 可以在一个 bug 工单被提交后创建一个 intent.md，并流经需求、计划、构建测试和评审阶段。第六阶段：维护以无头模式运行，各阶段之间有独立的信心关卡——确定性检查或对抗性评审 Agent——决定前一阶段的输出是继续流转还是升级给人类。

传统方式：维护是一个被动阶段。所有工单或事件都等待一个人来处理并重新启动流程。凌晨 3 点的告警可能被遗漏，工单可能在待办中搁置直到有人处理，而事后复盘的行动项可能因为新的火灾而根本到不了代码库。

AI 原生方式：触发器——如控制带突破、工单、频道消息或定时计划——在调用路径中无需人类即可调用 Claude。Claude 进行诊断，仅通过有关卡的路由行动，并将发现写为 intent.md，然后走上述阶段的流程。人类分类和审查那些工作，不再需要启动它。

闭合循环

一个确定性脚本监控生产环境，在控制带被突破时调用 Claude。监控突破是循环自主运行的模式的一个有用示例，而本阶段末尾的 Claude Tag^[15] (公测版) 部分则涵盖通过不同渠道到来的工作。

如何开始

前置条件

intent.md——为循环提供结构化输出以重新启动。Claude 加速的 PR 评审、作为操作边界的 hooks，以及 CI/CD 的回滚路径 (最高自主级别会调用它)。

基础设施

一个检测脚本可以查询的指标存储 (Prometheus、CI 系统的 API 或等效物)，对仓库的读取权限，在 CI 中非交互式运行 Claude Code 的方式，或用于接收 webhook 的 Agent SDK^[16]。

如何执行

1. 服务负责人或平台工程师选取一个具有稳定滚动基线的指标——如 CI 测试失败率、部署后 5xx 率或 PR 周期时间。
2. 编写检测脚本——通常是滚动窗口上的均值和标准差，配合规则 (Western Electric 或类似规则)，使控制带既能捕获缓慢漂移也能捕获尖峰。脚本版本控制并有单元测试，检测保持完全确定性——不涉及模型。
3. 响应层级定义在版本控制的配置中 (下方的 bands.yaml)。在 1σ 时脚本仅记录，在 2σ 时调用 Claude 只读诊断，在 3σ 时 Claude 可以行动——但仅限于向评审关卡开启 PR 或触发预批准的运行手册。
4. 触发层可以是 GitHub 或 GitLab 中的定时工作流、来自现有监控栈的 webhook 或网络内的 Cron Job。Claude 无状态运行——作为 CI 运行器上的非交互式步骤或作为沙箱容器中的 Agent SDK 服务——CI/CD 剧本涵盖部署和模型访问选项。因为运行是无状态和非交互式的，循环可以在无人启动的情况下开始和结束。
5. Agent 按第一阶段：规划的格式将诊断写为 intent.md——涵盖异常及其证据、建议的结果、受影响的系统和任何待解决问题。从此发现像其他任何东西一样通过流水线。
6. 服务负责人或值班工程师分类队列，将面向产品的发现路由给产品负责人。立即修复、排期或忽略。忽略的决定调优控制带并有助于降噪。
7. 当修复上线后，为该事件添加一个评估 (持续评估剧本)，确保此类问题在未来得到防护。

示例 (bands.yaml，监控 CI 测试失败率)

metric: ci_test_failure_ratebaseline: rolling_30drules: western_electrictiers:  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 为工程领导层撰写报告——这展示了该 Harness 对流程指标和生产指标同样适用。

检测保持确定性。Claude 在控制带突破后被调用，层级设定它可以做什么。

Claude Tag 实现 Claude 值班

事件也可以通过其他方式到达——如 Slack 或 Teams 等工作场所通讯应用。事件可能看起来像事件频道上晚上 10 点的 Slack 消息请求紧急修复——现在可以立即处理。Claude Tag (公测版，目前在 Slack 中可用) 使 Claude 以自己的身份成为这些频道的成员，因此每个新事件都有一个首位响应者，响应本身成为循环和未来事件记忆的一部分。

对话和机构知识留在频道中，频道中的任何人都能指导和执行响应。任何团队成员都可以实时测试假设、探索新选项和调查——频道历史增加了可审计性。通过访问 MCP，Claude 验证指标回到基线并在讨论线中确认，将事后复盘写入版本控制的经验教训文件以供未来调查读取。

事件不是 Claude Tag 处理的唯一工作。通过 MCP 在工单上被标记或在频道中被询问，Claude 以相同方式分类工作。小型、边界清晰的修复作为 PR 通过评审关卡到达，更大的则被写为 intent.md 进入第一阶段：规划——此时循环开始自我供给。

频道就是审计追踪：请求、诊断、人工授权和修复都留在事件被处理的地方。

结语

模型和 Harness 变得更加先进，使组织不仅能够变革代码的生产方式，还能变革整个软件开发生命周期。

这种变革将人类判断置于流程的核心，并考虑了大型企业组织的治理和监管要求。

本指南整合了我们 Applied AI 团队每天为客户执行的诸多实际最佳实践，我们希望你觉得它既实用又可操作。

循环持续运转。人类判断始终凌驾其上。

资源与致谢

以下文档是平台团队设置这些控制所需的内容，大致按推出的顺序排列。

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本指南受到他们之前大量工作的启发并在此基础上构建。

引用链接

[1] Claude Code: https://claude.com/product/claude-code[2] Cowork: https://claude.com/product/cowork[3] skills: https://code.claude.com/docs/en/skills[4] Claude Design: https://claude.com/product/design[5] 计划模式: https://code.claude.com/docs/en/permission-modes[6] MCP: https://code.claude.com/docs/en/mcp[7] `CLAUDE.md`: https://code.claude.com/docs/en/memory[8] 插件: https://code.claude.com/docs/en/plugin-marketplaces[9] hook: https://code.claude.com/docs/en/hooks[10] git 工作树: https://code.claude.com/docs/en/worktrees[11] 子 Agent (subagent): https://code.claude.com/docs/en/sub-agents[12] Code Review: https://code.claude.com/docs/en/code-review[13] claude-code-action: https://code.claude.com/docs/en/github-actions[14] code.claude.com/docs/en/settings: https://code.claude.com/docs/en/settings[15] Claude Tag: https://claude.com/product/tag[16] Agent SDK: https://platform.claude.com/docs/en/agent-sdk/overview