如何借助 AI 分阶段重塑你的软件开发生命周期。

 Category Enterprise AI Claude Code    
 Product Claude Enterprise Claude Code Claude Tag    
 Date August 21, 2026  
 Reading time 5 min   
 Share Copy linkhttps://claude.com/blog/the-ai-native-sdlc-playbook  
 Author(s) Louis Claxton     

代码不再是瓶颈

各组织已开始以一年前难以想象的速度使用 AI 编写代码，然而围绕代码的流程却未能以同样的速度跟进。

许多工程团队仍然沿用相同的审批关卡、评审、交接和策略，这拖慢了通过 Claude Code 等智能体编码方案所取得的效率提升。

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

传统的软件开发生命周期（SDLC）流程繁重，以确保每一步都有问责和控制。然而，传统 SDLC 的设计初衷是在编写和实现代码是最耗时、最昂贵阶段的时代最大化效率，而如今情况已不再如此。PRD、估算流程和产品安全评审的存在，都是为了在可能长达数周、数月甚至数季度的开发工作中强制各方对齐。

传统 SDLC 还包含一些假设每一步都由人类执行的管控措施。而创造最大价值的组织已经围绕智能体 AI 现在所能做到的事情重建了流程，同时确保人类始终参与其中。在本指南中，我们将介绍我们的 Applied AI 团队在 SDLC 各个阶段内部集成 Claude 的若干最佳实践，以加速开发并让流程运行得更快，这些实践灵感来源于我们与客户的合作。

当代码不再是瓶颈，且构建阶段运行速度快于传统 SDLC 所能允许的范围时，三件事将成为现实：

瓶颈转移到了构建阶段左右两侧的环节。主要是规划、审查/测试和部署，这些环节仍以人类速度运行。控制手段开始与现实脱节，变得难以驾驭。当代码由人类编写时，逐行审查是有意义的，但一旦智能体编写了大部分代码差异（diff），这种方式就跟不上了。治理成本随之增加，因为例外情况仍然要通过每周或每月召开的会议和委员会来流转处理。

构建不再是制约因素——围绕它的人类速度环节才是。人类速度的各个阶段保持原有耗时，而构建阶段则压缩至数小时。

我们以安全瓶颈为例。安全团队的规模是按人类产出配置的，因此当智能体将代码产出成倍放大时，要么审查队列不断积压，要么代码在审查不足的情况下就发布了。受监管的组织无法接受任何一种结果，因此其安全和策略检查必须跟上智能体的节奏。

为了更好地实现智能体 AI 的生产力收益并保障其安全性，传统的 SDLC 生命周期需要经历与实施阶段同等程度的变革。

目录

1. 代码不再是瓶颈
2. 行动方案（Plays）
3. 阶段 1 —— 规划
4. 阶段 2 —— 设计
5. 阶段 3 —— 构建
6. 阶段 4 —— 测试
7. 阶段 5 —— 部署
8. 阶段 6 —— 维护
9. 结语

什么是 AI 原生 SDLC？

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

转变

下表展示了由 Claude 支持的传统 SDLC 与 AI 原生 SDLC 之间的两个极端。大多数组织处于这两列之间的某个位置。

阶段	传统 SDLC	AI 原生 SDLC
规划	需求由委员会收集，通过研讨会和签字审批来提炼，由人工撰写成文	Claude 直接从源头综合痛点，并将其捕获到 intent.md 中，该文件既可供人类阅读，也可供机器执行
设计	规格由分析师编写，由设计师解析	需求与设计被压缩进与智能体的单次工作会话中，由编码为技能的标准化规范引导，并在 git 中进行版本管理。
构建	测试和代码由人工编写，文档则在主要开发完成之后撰写。	测试和代码由 AI 生成，机构知识以版本化的机器可读 CLAUDE.md 文件和技能形式维护。
测试	在阶段边界设置 QA 关卡。	持续评估贯穿实现过程。
部署	人工审查每一行代码，治理在审查周期中进行，且往往执行不一致。	多层智能体审查，人工审查仅保留给受监管和关键代码。治理在 AI 行动时强制执行，以钩子作为审批关卡。
维护	人工监控生产环境中的缺陷。	智能体监控实时部署。任何超出控制范围的情况都会被诊断，并作为新的 intent.md 写回循环中。

贯穿右栏的主线是已提交的工件。每个阶段结束时都会将一个工件写入版本控制（包括 intent.md、spec.md、plan.md、diff 及其测试、包含审查结论的 PR 以及事件记录），下一阶段则从读取该工件开始。在早期阶段，.md 文件是主要工件，因为产品负责人和智能体都能读取并操作同一文件。从构建阶段起，工件变为代码及其记录。提交链同时也是审计追踪：谁要求了什么、智能体产出了什么、谁批准了什么。

人类仍对所有需要判断力的决策负责。在智能体 SDLC 世界中，人类的注意力随需要审查的工件一同转移。

每个阶段都提交一个可供下一阶段读取的工件。意图、规格、计划、diff 和审查结论共同构成审计追踪。

剧本

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

每个剧本涵盖：

变更内容；入门指南；具体的实施步骤；治理考量；以及如何衡量其是否奏效。

这些步骤是模块化的，各组织可以根据自身独特需求，选择在不同时间优先改造不同阶段。每个玩法都在“前置条件”下注明其依赖项，依赖关系图对此作了进一步说明。

一个阶段以提交工件结束，提交动作随即启动下一阶段。被接受的 intent.md 触发需求与设计环节，获批的 spec.md 触发计划模式，合并的 PR 触发流水线，而生产环境中的控制带被突破则写入下一份 intent.md，如此循环往复。

首先，你手动为每个步骤提供提示词，最终状态是一个循环：每个被接受的工件都会触发下一道关卡。人工注意力集中在关卡处，审查智能体标记的内容，而不是从头开始每个阶段。

这些玩法按阶段列出；箭头表示采用它们的顺序。两者并不相同。从任何一个“黏土”玩法开始——没有箭头指向它，因此它不需要任何前置条件。对于任何其他玩法，指向它的箭头所对应的玩法就是需要先采用的玩法。

计划

想法不再需要等待有人将其写成文档。意图只被捕获一次，用提出者自己的话表达，作为受版本控制的工件，供下一阶段直接使用。

捕获为 intent.md

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

当一个人有了想法时，他们会与 Claude 进行头脑风暴，并生成一份 markdown 格式的原型规格说明。在传统 SDLC 中，同一个人随后必须说服产品团队的一名成员，与其一起或代其将想法写成文档。

由 Claude 生成的原型规格说明是人类可读的、受版本控制的，并且可被下一阶段直接使用。该原型规格说明保存为 intent.md。

无论意图来源于事件触发还是智能体，所遵循的步骤都是相同的：产品负责人会在提交 agent 编写的 intent.md 之前对其进行审查和修正。

传统方式：一个想法在任何人能够行动之前，需要经过待办事项条目、用户故事、故事点和细化会议。所有权在每次交接时转移，因此最终到达工程团队的内容，与最初提出者的本意已经相隔了好几个环节。

AI 原生方式：提出者与 Claude 进行头脑风暴，并将结果记录为 intent.md，这是一份用提出者自己的语言写成的原型规格说明。该产物包含想要什么、为什么想要，以及在哪些约束条件下。重复性流程通过技能（skills）进行编码。

快速上手

前置条件

无。

基础设施

为非工程师人员提供 Claude 访问权限（claude.ai 或 Cowork）；一份各方认可的 intent.md 模板；一个共享的、受版本控制的 intent 存放位置，由产品负责人关注。对于单一产品，最简单的存放位置是产品仓库中的 intent/ 文件夹。这种设置使产物链与由其衍生的代码保持相邻。只有当 intent 跨越多个仓库时，专门的 intent 仓库才值得投入额外开销，而在单体仓库中它就是一个目录。第 3 阶段：构建 侧边栏介绍了该存放位置与已保存记录的 Jira 或需求工具之间的关系。

设置这一环境是平台或工程团队的一次性任务。技术团队成员需要搭建 intent 存放位置并决定谁可以写入，因为许多贡献者将来自整个组织的不同部门。

一旦仓库创建完成，没有 git 经验的贡献者无需直接使用 git。相反，通过连接到版本控制系统（例如 GitHub）的连接器，可以让 Claude 代表他们从 claude.ai 或 Cowork 提交 markdown 文件。

如何执行

1. 提出者用自己的语言向 Claude 描述问题。提出者可以描述他们今天无法做到的事情、受该想法影响的人群、更好的状态是什么样的，或者哪些内容不在范围内。不需要任何正式语言。
2. 进行头脑风暴，直到想法变得具体。Claude 会提出分析师会问的问题：范围、用户、约束条件，以及成功是什么样子的。
3. 让 Claude 按照组织模板把结果写成 intent.md，该模板可由技术团队成员编码为技能包，并由负责人签字确认。这份文档可以涵盖问题、预期成果、受影响的用户和系统、约束条件以及待解决的问题。
4. 发起人纠正 Claude 理解错的任何内容。
5. 将 intent.md 提交到共享主目录。作者和时间戳会一并记录在案，产品负责人从那里接手这个想法。

markdown Intent：理赔状态自助查询 作者：J. Ortiz（理赔运营部）。状态：草稿。

问题 客户致电联络中心询问理赔进度。客服人员大约有三分之一的工作时间花在仅查询状态的通话上。

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

受影响的用户和系统 理赔客服人员、门户团队、理赔核心 API。

约束条件 门户会话中不新增任何 PII。仅使用现有身份验证。

待解决的问题 第三方损失理算师是否也需要访问权限？

治理考量

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

如何衡量

先行指标

从首次对话到提交 intent.md 的时间，通过读取 intent 主目录上的 git 历史获得，其中记录了作者和时间戳。预期是将数周的需求收集和细化周期缩短到数小时。

滞后指标

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

设计

需求和设计合并为一次会话。策略在编写 spec 时即被应用，而不是在数周后的评审中才发现。

需求和设计

经产品负责人批准后，Claude 会采用已接受的 intent.md 并生成需求与设计规格说明书。此过程由组织在品牌、安全、合规和用户体验方面的技能所引导。

产品负责人审阅该规格说明书，但不会亲自撰写。此流程的目标是生成一份工程团队可以据此规划的规格说明书，并标注出需要关注的领域。

前端工作是这方面最清晰的例子。一旦 intent.md 被接受，产品负责人会基于 intent.md 在 Claude Design（测试版）中制作设计原型，对原型进行迭代，然后将其导出到 Claude Code 进行构建。

传统模式中，需求和设计是由不同团队执行的独立阶段。分析师将想法正式化为需求，然后设计师再将这些需求解析为设计。这种分离是为了明确责任，但过程缓慢且信息有损。

AI 原生模式中，两个阶段在同一个提示会话中完成。Claude 接受 intent.md 并生成需求与设计规格说明书，受组织技能约束，并标注出需要关注的领域。

快速入门

前提条件

编写一个 intent.md 文件，并将品牌、安全、合规和用户体验策略编写为技能。

基础设施

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

执行方式

1. 产品负责人开启一个会话，加载组织的技能，并附上 intent.md。
2. 产品负责人的提示词指向 intent.md，指明约束条件，并要求标注出需要关注的领域。首先手动运行此流程，然后将其固化为组织级别的斜杠命令。此后，将 intent 主页中 intent.md 的接受作为触发器，在合并时触发一个非交互式任务，加载组织的技能运行该流程，并将 spec.md 作为拉取请求提交（第 5 阶段：部署中的 CI/CD 部分涵盖了相关管道）。从那时起，产品负责人的首次介入就是审阅。
3. 同一位产品负责人对照原始想法审阅规格说明书。该规格说明书是否解决了所述问题？intent.md 中提出的开放性问题是否已得到解答或被继续推进？
4. 先处理被标记的问题，因为这些都是分析人员会升级上报的要点。产品负责人会在工程团队看到规格说明之前，逐一与对应的策略负责人解决这些问题。
5. 将 spec.md 与 intent.md 一起提交。这对文件记录了所要求的内容和所决定的内容。
6. 产品负责人决定规格说明和意图是否进入构建阶段，对于组织归类为较高风险的事项，会咨询技术负责人。这个决定始终由人类团队成员做出，而接受规格说明正是启动第 3 阶段（构建）中计划模式运行的开端。

实际效果（提示词）

markdown 阅读所附的 intent.md，并产出一份将其集成到我们现有代码库中的需求与设计规格说明。运用你可用的技能，使计划符合我们的品牌指南、安全策略和 UX 标准。将规格说明完整记录为 spec.md，随时可以交给工程团队。清晰描述任何值得关注的领域，尤其是当你无法同时满足相互冲突的策略时。

治理考量

现行策略不是在数周后的评审中才被发现，而是在编写规格说明的同时就被读取和应用。组织的技能作为约束条件施加于规格说明之上。规格说明、生成它的提示词，以及生效中的技能版本，全部记录在版本控制中。产品负责人签署批准规格说明，并将标记的问题转交给指定的策略负责人。

如何衡量

先行指标

同一变更从 intent.md 提交到 spec.md 提交之间的耗时（两个 git 时间戳），与旧的“需求加设计”周期进行比较。

滞后指标

构建开始后的需求返工量。统计同一变更在首个 plan.md 提交之后产生的 spec.md 提交次数。Git log 可以直接给出这个数据。

构建

没有已批准的计划，就不会实施任何内容。机构知识变成智能体读取的文件，护栏以代码形式运行，而非依赖习惯。

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

工程师以计划模式启动 Claude Code 会话，将第 2 阶段（设计）中已批准的 spec.md 交给 Claude，并让它对工程师进行访谈，不断迭代计划，直到工程师对计划满意为止。

传统方式：工程师阅读设计后开始编写代码。变更将如何实施——具体到哪些文件和哪些测试——都保留在工程师的脑海中，至多写在工单评论里。其他人无法审查。审查者看到的第一样东西是最终的差异（diff），而到那时返工已经变得缓慢。

AI 原生方式：工作始于 Claude 在计划模式（plan mode）下生成的一份书面计划，在该模式下它可以读取代码库而不做任何修改。工程师在代码编写之前修正计划，批准后的版本作为 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 审查环节（阶段 5：部署）将对照它检查最终的差异。
6. 接受计划并让 Claude 实施。有了扎实的计划，实施往往一次就能完成。
7. 当实施偏离计划时，在同一提交中更新 plan.md。可考虑使用钩子（hook）强制两者保持同步。

示例（plan.md）

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

变更文件 portal/src/claims/StatusPanel.tsx（新增）、claims-api/routes/status.py、claims-api/tests/teststatus.py

工作顺序

1. 在现有认证之后添加状态端点。
2. 将面板对接该端点。
3. 接入门户导航。

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

验证 teststatus.py 覆盖四种理赔状态；截图与已批准的模型一致。

治理考量

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

如何衡量

先行指标

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

滞后指标

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

自动模式下的 Claude Code

Claude Code 也可以以自动模式运行，在此模式下，工程师批准计划，并在满意且迭代完善后，Claude 无需每次编辑都提示即可应用每项变更。随着后续实践中的防护措施逐渐成熟（经过调优的 CLAUDE.md、编码策略的技能、阻止不安全操作的安全钩子，以及 Claude 可以运行的测试套件），自动接受成为常规工作的默认方式：一份紧凑的 spec.md、较小的爆炸半径，以及测试已覆盖的代码。

现在的转变方向是：从用户盯着智能体做编辑并审查操作，转向在更长的自主会话结束后审查产物。自动接受模式配合 worktrees 使用时，还能进一步实现个人和团队层面的并行化，并且是自主运行 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 上的知识，变成了一份智能体在每次会话开始时都会读取的文件，由整个团队维护，并在每次犯错时迭代更新。

开始使用

前置条件

无。

基础设施

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

执行方式

1. 在仓库中运行 /init。Claude 会根据它发现的内容生成一份初始的 CLAUDE.md。
2. 将生成的文件精简到新成员第一天就需要的内容。保留构建、测试和 lint 命令、重要的约定，以及 Claude 经常出错的地方。
3. 将 CLAUDE.md 提交到仓库根目录的 git 中，这样整个团队共享一个版本，变更也会像代码一样接受审查。
4. 这里有一条实用规则：当 Claude 连续两次犯同样的错误时，就把修正写进 CLAUDE.md。
5. 内容保持在一页以内，因为 Claude 会在会话开始时读取全部内容，任何过时的信息都只会白白占用上下文。

实际效果示例（CLAUDE.md）

javascript 支付服务

命令

• 构建：make build
• 测试：make test（单元测试）、make itest（集成测试，需要 docker）
• 代码检查：make lint（在 CI 中运行；推送前先修复）

约定

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

架构

• api/ 存放 REST 控制器，core/ 存放领域逻辑，adapters/ 对接外部系统。
• Kafka 事件定义在 schemas/ 中；绝不手动编辑生成的类。

Claude 容易出错的地方

• 不要升级依赖版本；这些由平台团队统一管理。
• 旧版 v1/ 包已冻结；改动一律放在 v2/ 中。

治理考量

CLAUDE.md 纳入版本控制，因此智能体所遵循的指令是可审查、可审计的。团队约定通过该文件落地，对它的修改会记录在 git 历史中，代码所有者会在 PR 评审中审批这些改动。

如何衡量效果

先行指标

Claude 重复犯下本应由 CLAUDE.md 避免的错误的频率。对 CLAUDE.md 的修正或改动应在 git 历史中留痕。

滞后指标

新成员从加入团队到首个 PR 被合并所需的时间（依据 PR 历史统计）。

技能作为机构知识

技能是组织将机构知识落地为可操作能力的方式。其指令明确、纳入版本控制、适用范围广，并在政策变化时集中更新。经验法则：为必须一致执行的机构知识编写技能；不要为应属于 CLAUDE.md 或提示词的组件编写技能。

快速上手

前置条件

无需任何前置条件。有 CLAUDE.md 会有所帮助，因为它能把智能体的工作知识保留在仓库中，但技能并不依赖它。

基础设施

每项策略都有指定的负责人和书面的权威来源。

执行方式

1. 挑选一条目前执行不一致的知识点。可以是安全标准、API 设计约定或品牌规范。
2. 把它写成一个技能，也就是一个包含 SKILL.md 的文件夹，其 frontmatter 说明该技能何时触发，正文说明该做什么。工程师根据政策所有者的权威来源编写该技能，并借助 Claude 辅助完成。
3. 将该技能放在仓库的 .claude/skills/ 目录下，使其随代码一起发布，或者通过插件在组织范围内分发。
4. 测试该技能能否触发。用不同方式让 Claude 执行相关任务，并确认每次都能加载该技能。
5. 当政策发生变化时，修改该技能，并让政策所有者签字确认这一变更。
6. 工程师会在下一次会话中自动获取新版本。

实际效果示例（.claude/skills/secure-api-review/SKILL.md）

markdown

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

安全 API 审查

当你创建或修改 API 端点时：

1. 身份验证：每个端点都需要网关 JWT；除 /health 外不允许匿名路由。
2. 输入验证：根据 OpenAPI 模式验证请求体，并拒绝未知字段。
3. 审计：每个改变状态的端点都会发出包含操作者、操作、实体和时间戳的审计事件。
4. 数据分类：模式中标记为 pii 的字段绝不能出现在日志或错误消息中。

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

治理考量

技能是一种控制手段，尽管是建议性的。它使 Claude 在编写代码时更有可能应用该政策，但没有任何机制强制某个会话必须遵守它。对于必须始终成立的政策，需要在技能背后加上确定性的保障，例如阻止该操作的钩子，或在 PR 阶段重新检查政策的审查环节。技能使违规变得罕见，而钩子使违规几乎不可能发生。技能调用会记录在会话轨迹中，政策所有者像审查代码一样审查技能变更。

如何衡量

先行指标

从政策所有者批准政策变更到更新后的技能合并所用的时间，取自技能文件夹上的 PR。

滞后指标

对引用该策略的 PR 审查结果进行复核，一旦技能在代码编写过程中应用了该策略，此类结果应趋近于零。若结果未趋近于零，要么是技能未触发，要么是其文本已偏离官方策略。

钩子作为构建阶段的护栏

技能是建议性控制，而钩子是其背后的确定性层。Claude 的大部分操作发生在实现阶段的文件编辑和 shell 命令上，因此构建阶段是钩子最常触发的地方。

构建阶段的钩子可以：

阻止对受保护路径的编辑，例如生成的类或冻结的包；在文件编辑后运行格式化和 lint 检查，使偏差永不累积；防止凭据出现在 diff 中。

为任何策略必须无条件成立的技能提供支撑。钩子会在每次匹配的操作上运行，因此构建阶段的钩子应保持快速，并限定在发生变更的文件范围内。更重的检查（如完整测试套件）应放在提交或 PR 阶段。

需要人工审批的钩子应归属于第 5 阶段（部署）的门禁，因为构建期间的审批提示会把人员重新拉回所有并行会话的关键路径上。

并行会话与子智能体

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

并行会话是另一个完整的 Claude Code 实例，在各自的 git worktree 中处理独立任务。每个独立会话互不知晓彼此，工程师的调度是它们唯一的共同点。

子智能体在单个会话内作为受限助手运行，拥有自己的上下文窗口和工具限制，适合在多个任务中重复出现的工作，例如验证应用按预期运行。

并行会话提高了工程师同时进行的任务数量，而子智能体则让每个会话专注于自身任务。工程师的职责是调度和审查所有这些工作。

传统方式下，一名工程师一次只处理一个任务，并将一天或一周的相当大一部分时间花在构建、测试和审查上。等待期间切换任务虽有可能，但上下文切换带来的疲劳足以让大多数人选择不这么做。

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

入门指南

前置条件

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

基础设施

一个 git 仓库，因为隔离性来自工作树，并且权限设置经过调整，使得会话不会因组织认为安全的命令而等待审批提示。

执行方式

1. 工程师利用计划模式剧本（第 3 阶段：构建）中的计划，将工作拆分为涉及不同文件的任务，以确定哪些工作相互独立。共享文件的任务在单个会话中依次运行。
2. 每个并行任务都有自己的工作树，例如在一个终端中运行 `claude --worktree feature-auth`，在另一个终端中运行 `claude --worktree fix-rate-limit`。工作树是在各自分支上的独立检出，可防止会话在文件上发生冲突。
3. 两到三个会话是合理的起点。实际上限取决于一个人能妥善审查多少条流，因此只有在审查跟得上的情况下才增加会话。
4. 将重复性工作转变为子智能体，这些子智能体在 `.claude/agents/` 目录下的 markdown 文件中定义，每个子智能体都有名称、使用场景描述以及可访问的工具。示例包括：一个代码简化器，在主智能体完成后去除不必要的复杂性；一个验证器，运行应用并检查行为；一个研究员，探索代码库并汇报结果，而不会淹没主上下文。将这些定义提交到 git 中，以便整个团队共享。

示例（.claude/agents/verifier.md）

javascript

name: verifier description: Runs the app and checks the change works before the session reports done tools: Bash, Read

使用 `make run` 启动应用。测试变更后的行为以及两个最邻近的流程。报告你运行了什么、看到了什么，以及任何与 plan.md 不符的行为。不要修复任何问题，只做报告。

治理考量

会话越多意味着产出越多，因此控制措施必须来自仓库中的配置。仓库中的钩子和权限设置适用于所有会话，会话所执行的操作会被记录并归属于运行该会话的工程师。

如何衡量

先行指标

在审查质量保持的前提下，每位工程师的并发会话数（从 OpenTelemetry 导出中统计），以及一天中用于引导而非等待的时间占比。

滞后指标

每位工程师每周合并的变更数，结合根据 PR 历史确定的返工率一起解读。

为 Claude 建立反馈回路

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

反馈回路不应与验证子智能体（阶段 3：构建）混淆。反馈回路贯穿整个任务，运行次数与工作量相当。而验证子智能体则是将会话认为工作完成后的最终检查打包的一种方式——通过运行一个全新的上下文窗口来实现。这样，最终结论就不会受到产生代码时那些假设的影响。

传统方式 代码是否可用的信号来得太晚。CI 要几分钟后，测试人员要几天后，生产环境要几周后。当智能体生成代码时，迟到的信号意味着必须有人检查它的全部输出，而这个人就成了瓶颈。

AI 原生方式 会话在有人看到之前就获得了一种自行检查工作的方式。运行测试、运行构建、截图。Claude 会不断迭代直到检查通过，因此到达工程师手中的内容已经通过了检查。建立这个回路是运行会话的工程师的职责，下面的步骤就是为他们编写的。

入门

前置条件

无。

基础设施

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

如何执行

1. 如果今天检查工作需要一系列命令和一些环境知识，就将其封装到单个目标中，例如“make test”或“npm test”，并在失败时以非零状态码退出。
2. 在 CLAUDE.md 的 Commands（命令）部分，列出每条命令，并附上一个健康输出的示例。
3. 设定一个目标，并使其可量化，这样 Claude 无需询问你即可自行检查工作，例如：“teststatus.py 中的所有测试均通过”、“截图与所附的 mock 一致”，或“端点返回 200 并带有新字段”。
4. 对于 bug 修复，先编写失败的测试。请 Claude 将 bug 复现为测试，运行它，并确认它因你预期的原因而失败。提交该测试。然后才请 Claude 在不修改测试的情况下使其通过，并利用最后一步中的测试文件钩子来强制执行此限制。一个在修复之前就已存在、且智能体无法重写的测试，就是 bug 已消除的证明。
5. 对于 UI 工作，通过视觉检查来闭环。给 Claude 一个浏览器或截图工具，给它 mock，让它迭代。实现、截图、对比、调整。两三轮是正常的，而且每一轮结果都应有所改进。
6. 将验证纳入“完成”的定义。指令写在 CLAUDE.md 中。在报告任务完成之前运行测试，并展示输出。
7. 最后，这个循环本身也需要保护，因为修复代码的智能体绝不能削弱对该代码的检查。在修复任务期间，阻止对测试文件进行编辑的钩子就能做到这一点。另一种做法是在审查时检查 diff，并拒绝任何涉及测试的更改。

实际效果（CLAUDE.md 验证块）

javascript 验证你的工作

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

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

治理考量

强制执行的内容

任务报告完成前的验证，以及修复期间阻止智能体编辑测试文件的限制，这两者都在组织希望得到保障的地方以钩子形式实现。

证据是什么

“make test”的字面输出、构建日志，或 Claude 运行并粘贴的截图对比，因此证据来自工具链本身。

记录位置

在会话记录中（OpenTelemetry 导出会将其转发到组织的可观测性堆栈），以及在 PR 的检查运行中，审查者和任何后续审计人员都能看到这些内容。

谁负责审批

审查 PR 的代码所有者，他们可以专注于意图和风险，因为机械性的证据已经附上了。

如何衡量

领先指标

智能体编写变更的首次 CI 通过率，CI 系统本身已经支持这一指标。

滞后指标

每个 PR 的审查时间（来自 PR 元数据），一旦测试能捕获过去需要审查者人工发现的问题，这一时间应当下降；以及来自事件跟踪系统的变更失败率。

CI 中的持续评估

评估是 AI 原生版的阶段门控 QA。在实践中，这意味着每当智能体的配置发生变化时，就会运行一套评估套件。当换入新模型或重写提示词时，评估套件会判断智能体是否仍能按照同样的标准完成工作。

评估应被视为一套活套件。随着模型不断改进，曾经具有区分度的用例会逐渐失效，必须根据持续监控中出现的新的情况添加新的用例。

根据具体使用场景，有些团队可能更倾向于按固定节奏离线运行这些评估，而不是在每次变更时都运行。以下步骤针对的是持续评估。

入门

前置条件

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

基础设施

能够以非交互方式运行 Claude Code 的 CI，以及带有评估运行预算的 API 密钥。

如何执行

1. 平台工程师从近期工作中收集 20 到 50 个真实任务，并附上预期/可接受的结果。
2. 将每个任务编写为一个评估项，即提示词加上定义可接受结果的检查项（测试通过、lint 无报错、行为不变、策略得到遵守）。
3. 该套件在 CI 中按计划以非交互方式运行，并在 CLAUDE.md、技能或钩子发生任何变更时运行，因为这些配置会引导智能体的行为，理应获得与代码同等的回归测试待遇。
4. 根据结果对配置变更设置门禁。导致通过率下降的技能变更在合并前需要经过审查。
5. 每次生产事故都会对应一个评估项，由负责该事故的团队编写，并作为回归测试保留在套件中。

它看起来是什么样（.github/workflows/agent-evals.yml）

yaml name: Agent evals on: pullrequest: 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: ANTHROPICAPIKEY: ${{ secrets.ANTHROPICAPIKEY }} 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提供了一道能跟上智能体产出的把关闸门。通过率阈值作为合并检查强制执行，运行过程会被记录以便随时间对比结果，而负责该配置变更的团队负责审批。

如何衡量

领先指标

评估通过率随时间的变化（由测试套件在每次运行时报告），以及一次生产事故需要多久才能转化为一个永久性的评估用例。

滞后指标

在CI中捕获的回归问题，与根据事故追踪系统得出的生产环境中发现的回归问题之间的对比。

部署

双向审查运行，治理在智能体行动时强制执行。智能体负责生产门禁之前的所有工作，门禁之后则一概不做。

PR 审查循环中的 AI

Claude 既给出审查，也接收审查。它根据组织的政策审查传入的 PR，并处理自己 PR 上收到的审查意见。这让工程师在 PR 审查中能够专注于行为本身，而这归结为判断意图和风险。

传统审查 审查容量是按人工产出规划的。一个 PR 要等待审查者通读全部内容，审查质量随审查者的负载而波动，作者在积压不断增长的同时还要不断催促。

AI 原生 所有 PR 都获得一组完全相同的审查流程，发现的问题按严重程度排序。人工注意力上移一个层级，聚焦于变更是否符合计划意图、风险是否可接受。

入门指南

前置条件

来自阶段3：构建的更新版 CLAUDE.md 文件；如果审查通过则强制执行书面政策、已定义的子智能体。

基础设施

一个安装了 Claude 集成的代码仓库，要么是由管理员启用的托管代码审查（研究预览）服务，要么是在你自己的 CI 中运行的 claude-code-action，在需要时通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 进行模型调用（CI/CD 方案涵盖了部署选项）。要求代码所有者批准的分支保护策略也值得采用。

如何执行

1. 托管代码审查服务是最快的入门方式。管理员启用它并选择代码仓库。当你需要控制流水线，或希望 API 调用通过你自己的云协议路由时，可以在自己的 CI 中使用 claude-code-action 运行审查（CI/CD 方案涵盖了这些管道细节）。
2. 技术负责人将审查策略写成仓库根目录下的 REVIEW.md，分为组织关心的几个方面：缺陷和逻辑错误；安全性和漏洞；对照规范（来自需求方案的 spec.md）、实施计划（来自计划模式方案的 plan.md）和设计原则的合规性。REVIEW.md 还定义了什么是“重要”问题，什么是“小问题”，以及哪些内容需要跳过。
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）

markdown 审查说明

通过项 运行三轮审查，并为每条发现标注其所属轮次：

• 缺陷：逻辑错误、边界情况处理不当、细微回归
• 安全：注入风险、认证漏洞、日志中的 PII（个人身份信息）
• 合规：变更符合 spec.md、plan.md 及我们的设计原则

“重要”在此处的含义 将“重要”级别保留给会导致行为异常、数据泄露或违反策略的发现。风格和命名问题属于小问题（nit）。

限制小问题数量 每次审查最多报告五个小问题；其余以计数形式汇总。

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

治理考量

职责分离得到保留，因为编写代码的智能体无法批准自己的代码。REVIEW.md 中的审查策略适用于所有 PR，发现、修复、评级和批准均记录在 PR 历史中，因此 PR 本身就是审计记录。批准由人类通过分支保护机制完成，并参考审查发现。

如何衡量

先行指标

首次审查时间，应缩短至分钟级别，以及无需人工触碰分支即可解决的审查评论占比，数据直接存储在 Git 上。

滞后指标

合并前捕获的缺陷和漏洞与流入生产的缺陷和漏洞之比，数据来自 PR 历史和事件跟踪系统。

Hook 作为批准门禁

构建阶段使用 Hook 作为护栏，在无人工介入的情况下允许或阻止操作（第 3 阶段：构建）。Hook 也可以进行询问，暂停操作直到特定人员批准，这正是发布门禁所需要的。

这个剧本位于第 5 阶段：部署，因为发布审批是最清晰的用例，但钩子并非仅限部署场景：只要 Claude 采取行动，钩子就会运行。例如，钩子可以在第 3 阶段：构建期间阻止在没有变更工单的情况下修改迁移文件和基础设施，也可以在第 4 阶段：测试期间阻止智能体在修复任务中编辑测试文件。

快速上手

前置条件

无。

基础设施

一份书面清单，列出变更流程所需的各项审批。

执行方式

1. 工程领导层与变更管理和合规团队共同列出必须保留的人工审批关卡，例如变更管理签核、发布授权，以及对受保护路径的编辑权限。
2. 平台工程师将每个关卡实现为一个钩子，即在 Claude 行动之前运行的脚本，该脚本可以允许、询问或阻止操作。
3. 团队级钩子放在 git 中的 .claude/settings.json 里，而不可协商的钩子则放在由平台或 IT 管理员拥有的托管设置中，个人工程师无法将其关闭。
4. 阻止操作时应说明原因，因此当钩子阻止某个操作时，原因和审批途径会显示在 Claude 的输出中。

效果示例（.claude/settings.json）

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

关卡脚本本身（.claude/hooks/production-gate.sh）

bash #!/bin/bash 生产环境部署需要具名的发布授权 cmd=$(jq -r '.toolinput.command' < /dev/stdin) if [[ "$cmd" == "deploy" && "$cmd" == "production" ]]; then if [ -z "$RELEASEAPPROVAL" ]; then echo "生产环境部署需要发布授权。" >&2 exit 2 # exit 2 阻止该操作；消息会传递给 Claude fi fi exit 0

治理考量

钩子就是审批关卡。关卡条件每次都会强制执行，对所有人都一视同仁。允许和阻止的决定都会带有时间戳记录。关卡还定义了什么算作审批，无论是已批准的变更工单还是发布经理的签核。

实际案例：受监管企业的托管设置

由平台团队通过 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": "GITHUBTOKEN", "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 意味着本方案中的审批闸门是唯一会运行的钩子；本地任何内容都无法新增或替换它们。

`disableSideloadFlags` 和 `strictKnownMarketplaces` 意味着工程师机器上的每个技能、智能体、钩子和 MCP 服务器都必须来自组织批准的插件市场，绝不会来自个人主目录。

`allowManagedMcpServersOnly` 使智能体的工具面成为由平台团队拥有的允许列表。

`requiredMinimumVersion` 拒绝在低于批准下限的版本上启动，因此这些控制措施由组织实际评估过的构建来强制执行。

请将上述内容视为定制的起点，而非照搬的建议。每一项拒绝都会以能力为代价，而正确的平衡取决于仓库的数据分类。设置参考文档记录了每个键，包括仅托管管理的键：code.claude.com/docs/en/settings

如何衡量（针对钩子本身）

先行指标

在每个审批关卡上等待的时间。每个钩子决策都会连同时间戳以及允许或阻止的判定写入 OpenTelemetry 导出，因此每个关卡的等待时间都是可见的。

滞后指标

在钩子部署前后，从事件跟踪器中统计到达生产环境的关卡违规数量。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code，对执行进行沙箱化，使长时间运行的智能体安全运行，通过 MCP 集成暴露部署能力，并在智能体需要回滚路径之前预先演练这些路径。

传统流水线运行确定性脚本，任何需要判断的事情都要等待人工处理。例如，对不稳定测试进行分类、编写变更日志，或排查构建失败的原因。部署和回滚是人工在压力下遵循的操作手册。

AI 原生的 Claude 以非交互方式在流水线中运行，负责需要判断的步骤，运行在具有限定凭据的沙箱中。部署工具通过 MCP 暴露给智能体，因此编写和测试变更的工作流也可以发布变更并回滚变更，这一切都在组织按环境定义的关卡内进行。

入门

前置条件

将 Claude 纳入 PR 审查循环，并将钩子作为审批关卡，因为关卡必须先存在，自动化才能加速任何流程通过它们。

基础设施

一个安装了 claude-code-action 的 CI 平台，或任何能够调用 `claude -p` 的 runner；通过 API 或 Bedrock、Foundry、Vertex 获得模型访问权限（在流量必须保留在组织云协议范围内的场景下）；用于部署目标的 MCP 服务器；以及一个不持有常驻生产凭据的智能体任务沙箱配置文件。

如何执行

1. 平台工程师从只读的判断步骤开始。在流水线任务中使用 `claude -p` 来分诊失败的构建、总结不稳定的测试，或起草变更日志。
2. 在现有门禁之后添加写入步骤，用于修复 lint 问题、更新生成的文档，或通过 @claude 提及来处理评审意见等任务。智能体写入的任何内容都会以 PR 的形式通过分支保护机制提交，且智能体没有任何途径直接推送到 main 分支。
3. 执行过程是沙箱化的。智能体任务在容器中运行，受网络策略约束，使用短期作用域 token，默认不持有任何生产凭据。
4. 通过 MCP 暴露部署能力。部署、状态查询和回滚都成为工具，按环境限定作用域，因此智能体的部署权限是一个允许列表，而不是一个携带凭据的 shell 脚本。
5. 按环境分级授予自主权。在开发环境中，智能体可以自由部署。在生产环境中，智能体准备发布版本，由发布经理授权，并通过钩子强制执行生产门禁。预发环境则介于两者之间。
6. 回滚应该是流水线中演练最充分的路径——一个智能体可以执行的单一命令，并在预发环境中定期演练。闭环玩法（第 6 阶段：维护）在控制带被突破时会调用此回滚，因此它必须事先得到验证。

实际效果（流水线步骤）

markdown

• name: Triage failed build if: failure() run: > claude -p "Read the build log at out/build.log. Identify the most likely cause, say whether the failure looks flaky or real, and write a three-line summary for the PR thread." >> triage.md

治理考量

治理原则是：智能体可以一直行动到生产门禁之前，但绝不能越过它。以下控制措施用于强制执行这一原则。

分支保护会将智能体写入的任何内容转化为 PR，且不存在直接通往主分支的路径。生产部署钩子会阻止发布，直到指定的发布经理授权为止。每次非交互式运行都以智能体自身的身份执行，因此流水线日志能将智能体的操作与触发它的工程师的操作区分开来。按环境划分的权限层级决定了智能体在到达关卡之前可以执行多少操作。

如何衡量

先行指标

从 CI/CD 流水线日志中提取的、无需呼叫人工即可完成分诊的流水线失败占比。

滞后指标

DevOps 研究与评估（DORA）指标，这些指标由 CI 系统和部署工具已经生成。

维护

闭环形成。一个触发器在调用路径中没有任何人工参与的情况下调用 Claude，而它发现的内容会以 intent.md 的形式重新进入流水线。

维护与闭环

到目前为止，我们讨论了如何将 Claude 添加到 SDLC 流程的每个阶段，每个阶段都需要人工启动初始步骤。然而，这一阶段将重点转向让 Claude 自主运行以形成闭环。

例如，一个持续运行的监控智能体可以在 bug 工单被创建后，生成一个 intent.md，并依次经历需求、计划、构建、测试和审查阶段。第 6 阶段：维护以无人值守模式运行，在阶段之间设置独立的置信度关卡——可以是确定性检查，也可以是对抗性审查智能体——来决定前一阶段的输出是继续流转，还是升级给人工处理。

传统的维护是一个被动响应的阶段。所有工单或事件都需要等待人工采取行动并重新启动流程。凌晨 3 点触发的告警可能会被错过，工单可能会一直躺在待办列表中直到有人接手，而如果另一场事故先发生，事后总结的行动可能根本不会落实到代码库中。

AI 原生模式。诸如控制带越界、工单、频道消息或定时计划之类的触发器会在路径中无人工参与的情况下调用 Claude。Claude 进行诊断，仅通过受控路由采取行动，并将其发现写入 intent.md，随后该文件会经过上述各个阶段。人工负责分诊和审查这些工作，而不再需要启动它们。

形成闭环

一个确定性的脚本监控生产环境，当控制带被突破时调用 Claude。对突破的监控是循环自主运行模式的一个有用示例，而本阶段末尾的 Claude Tag（公开测试版）部分则涵盖通过不同渠道进入的工作。

入门指南

前置条件

Intent.md 为循环提供结构化输出以重新启动。Claude 加速 PR 审查、钩子作为操作边界，以及 CI/CD 的回滚路径（由最高自主层级调用）。

基础设施

一个检测脚本可查询的指标存储（Prometheus、CI 系统的 API 或等效方案）、仓库的读取权限、在 CI 中以非交互方式运行 Claude Code 的途径，或用于接收 webhook 的服务的 Agent SDK。

执行方式

1. 服务所有者或平台工程师选择一个具有稳定滚动基线的指标，例如 CI 测试失败率、部署后 5xx 错误率或 PR 周期时间。
2. 他们编写检测脚本，通常采用滚动窗口上的均值和标准差，并配合规则（Western Electric 或类似规则），使控制带既能捕捉缓慢漂移也能捕捉突发尖峰。脚本进行版本控制并配有单元测试，检测过程完全保持确定性，不涉及任何模型。
3. 响应层级在版本控制的配置中定义（如下文的 bands.yaml）。在 1σ 时脚本仅记录日志，在 2σ 时调用 Claude 以只读方式诊断，在 3σ 时 Claude 可以采取行动，但仅限于向审查门禁提交 PR 或触发预先批准的 runbook。
4. 触发层可以是 GitHub 或 GitLab 中的定时工作流、来自现有监控栈的 webhook，或网络内部的 Cron Job。Claude 以无状态方式运行，要么作为 CI 运行器上的非交互步骤，要么作为沙箱容器中的 Agent SDK 服务，CI/CD 部分涵盖部署和模型访问选项。由于运行是无状态且非交互的，循环可以在无人启动的情况下开始和结束。
5. 智能体将其诊断以 intent.md 的形式写入第 1 阶段：计划格式，涵盖异常及其证据、提议的结果、受影响的系统以及任何未解决的问题。之后，发现结果像其他任何内容一样进入流水线。
6. 服务负责人或值班工程师对队列进行分诊，将面向产品的发现项路由给产品负责人。可选择立即修复、安排计划或直接驳回。驳回操作会调整各分档区间，有助于降低噪音。
7. 当修复上线时，为该事件添加一个评估用例（持续评估体系会发挥作用），以确保此类问题在未来得到防护。

实际效果示例（例如，一个用于监控 CI 测试失败率的 bands.yaml 配置）

yaml metric: citestfailurerate baseline: rolling30d rules: westernelectric tiers: 1sigma: { action: log } 2sigma: { action: diagnose, tools: "Read,Grep,Bash(gh run view )" } 3sigma: { action: propose, routes: [pullrequest, runbook:rollback-deploy] }

治理考量

分档边界由版本控制的配置强制执行，权限和托管设置禁止生产环境访问。调用记录、发现项和分诊决策均带有时间戳。服务负责人对发现项进行分诊和审批，由此产生的变更走常规 PR 审查流程，智能体可能触发的运行手册（runbook）也事先经过审批。

如何衡量

先行指标

从分档被突破到分诊队列中出现 intent.md 的时间，对比以往从事件发生到事后复盘行动的时间。检测脚本的日志中包含事件的分档突破时间戳和事件等级。

滞后指标

发现项中最终成为已合并修复的比例（分诊队列对比实际 PR 历史），以及同类事件的重复发生率——随着修复不断为评估套件补充用例，这一比例应当下降。

示例

当 CI 测试失败率突破 3σ 时，智能体会隔离不稳定的测试或发起回滚 PR，由审查流程决定最终处理方式。当部署后 5xx 错误率在部署窗口内突破 3σ 时，智能体会触发现有的回滚流水线。当 PR 周期时间触发漂移规则时，智能体会为工程管理层撰写报告，这表明该机制同样适用于流程指标和生产指标。

检测过程保持确定性。一旦分档被突破，Claude 才会被调用，而分档等级决定了它可以执行的操作。

Claude 值班，由 Claude 标记

事件也可能通过其他途径传入，例如 Slack 或 Teams 等职场通讯应用。事件可能表现为晚上 10 点在事件频道里发来的一条紧急修复消息，而现在可以立即处理。Claude Tag（目前已在 Slack 中提供公开测试版）让 Claude 以自身身份成为这些频道的成员，因此每起新事件都会有一位第一响应人，而响应本身也会成为循环的一部分，并为未来事件积累记忆。

对话和机构知识保留在频道内，频道中的任何人都可以引导并执行响应。任何团队成员都可以实时检验假设、探索新选项并进行调查，频道历史记录则增强了可审计性。通过访问 MCP，Claude 会验证指标已恢复到基线水平，并在线程中确认这一点，同时将事后复盘写入一个受版本控制的经验教训文件中，供未来的调查阅读。

事件并非 Claude Tag 接手的唯一工作。无论是通过 MCP 在工单上被标记，还是在频道中被直接指派，Claude 都会以同样的方式对工作进行分类。一个范围明确的小修复会以 PR 的形式通过审查门禁，而任何更大的工作则会被写成 intent.md 进入第一阶段：规划，此时循环便开始自我驱动。

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

结语

模型和工具链已变得更加先进，使组织不仅能够转变代码生产方式，还能重塑整个软件开发生命周期。

这一转变将人类判断力保持在流程的核心位置，并兼顾大型企业组织的治理与合规要求。

本指南汇集了我们的 Applied AI 团队每天为客户执行的许多真实最佳实践，希望您能从中获得实用且可操作的参考。

循环持续运转，人类判断始终居于其上。

资源与致谢

以下文档是平台团队建立这些控制机制所需的资料，大致按照您推出的顺序排列。

为你的组织设置 Claude Code——管理员决策地图；从这里开始 code.claude.com/docs/en/admin-setup 设置参考与优先级，包括每一个仅限管理的键 code.claude.com/docs/en/settings 来自 Claude 管理控制台的服务器托管设置 code.claude.com/docs/en/server-managed-settings 权限 code.claude.com/docs/en/permissions 沙箱——操作系统级别的文件系统和网络隔离 code.claude.com/docs/en/sandboxing 钩子——指南 code.claude.com/docs/en/hooks-guide 钩子——参考 code.claude.com/docs/en/hooks 技能 code.claude.com/docs/en/skills 插件和私有市场——技能和钩子如何在组织范围内分发 code.claude.com/docs/en/plugin-marketplaces 托管 MCP——对智能体工具面的集中控制 code.claude.com/docs/en/managed-mcp 企业部署概览——Bedrock、Vertex、Foundry code.claude.com/docs/en/third-party-integrations 企业网络配置 code.claude.com/docs/en/network-config 监控（OpenTelemetry）code.claude.com/docs/en/monitoring-usage 分析仪表板 code.claude.com/docs/en/analytics 合规 API——企业活动流、聊天检索与删除 platform.claude.com/docs/en/manage-claude/compliance-api 安全模型 code.claude.com/docs/en/security

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本指南的灵感来源于并建立在他们此前的大量工作之上。

相关文章

面向初创公司的 Claude Code 指南

面向初创公司的 Claude Code 指南面向初创公司的 Claude Code 指南

面向初创公司的 Claude Code 指南面向初创公司的 Claude Code 指南

使用计算机操作、技能 API 和文件 API 构建生产级智能体

产品公告

使用计算机操作、技能 API 和文件 API 构建生产级智能体使用计算机操作、技能 API 和文件 API 构建生产级智能体

使用计算机操作、技能 API 和文件 API 构建生产级智能体使用计算机操作、技能 API 和文件 API 构建生产级智能体

Anthropic 的 AI 教学与学习方法

产品公告

Anthropic 的 AI 教学与学习方法Anthropic 的 AI 教学与学习方法

Anthropic 的 AI 教学与学习方法

Claude 随叫随到：Claude Tag 如何充当 Anthropic 应对 CI/CD 故障的第一响应者

借助 Claude 变革组织的运营方式

Claude Tag

编程