AI 原生软件开发生命周期(SDLC)实战手册

原文：The AI-Native SDLC playbook（Enterprise AI / Claude Code，2026 年 8 月 21 日，阅读时长约 5 分钟）
作者：Louis Claxton
说明：原文篇幅很长（六个阶段、二十余个"打法"、大量代码与配置示例），本文是对全文内容的完整梳理与改写，保留全部阶段结构、表格与关键配置示例，行文以译者自己的语言重述，而非逐句直译。

代码不再是瓶颈

企业开始用 AI 以一年前难以想象的速度写代码，但围绕代码的流程却没有跟上同样的节奏。

许多工程团队仍在沿用原有的审批关卡、评审、交接和政策，这些环节正在拖慢 Claude Code 这类智能体编码工具本该带来的生产力提升。

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

传统 SDLC 流程繁重，是为了在每一步都确保责任到人、过程可控。但它的设计初衷，是让"写代码和实现代码"这个当年最耗时、最昂贵的阶段效率最大化——而这个前提如今已经不成立了。PRD、估算仪式、产品安全评审，本质上都是为了在可能长达数周、数月甚至数季度的开发周期里，强制各方保持对齐。

传统 SDLC 里的各种管控，也都假定每一步都是由人来执行的。而那些从中获益最多的组织，已经围绕"智能体 AI 现在能做什么"重建了自己的流程，同时确保人始终留在决策回路中。本文梳理了 Anthropic 应用 AI 团队在与客户合作过程中，把 Claude 整合进 SDLC 各阶段的一系列最佳实践。

当代码不再是瓶颈、构建阶段的速度超出了传统 SDLC 所能承受的节奏时，会出现三件事：

• 瓶颈转移到了构建阶段前后的环节——主要是规划、评审/测试和部署，这些环节仍然运行在"人的速度"上。
• 原有的管控开始脱离现实，变得难以为继——当代码是人写的时候，逐行人工评审是合理的，但当智能体写出了大部分 diff 之后，这种做法就跟不上了。
• 治理成本上升——因为例外情况仍然要走每周或每月才开一次的会议和委员会。

（原文配图示意：构建阶段被压缩到几个小时，而它前后那些"人力速度"的阶段长度基本不变，瓶颈随之外移。）

拿安全评审来举例：安全团队的编制是按人类的产出速度配置的，一旦智能体让代码产出量成倍增长，要么评审队列越堆越长，要么代码带着不充分的评审就上线了。受监管的组织两种结果都无法接受，所以它的安全与政策检查环节，必须跟上智能体的节奏。

要真正释放智能体 AI 的生产力、同时确保它的安全性，传统 SDLC 需要经历和"实现阶段"同等程度的转型。

什么是 AI 原生的 SDLC

AI 原生 SDLC，是把旧有的管控目标和新的执行方式重新组合出来的一套流程。它不再是一条线性流水线，而变成了一个循环，AI 被嵌入到循环的每一个节点上。AI 原生 SDLC 提倡自动化的交接与后续动作触发，用来解决传统 SDLC 里各阶段交接手工、笨重的问题。

两种模式的转变

下表列出了传统 SDLC 与 Claude 支持下的 AI 原生 SDLC 两个极端，大多数组织其实介于两者之间：

阶段	传统 SDLC	AI 原生 SDLC
规划	由委员会收集需求，经工作坊和层层签字提炼，手工写成文档	Claude 直接从原始信息源提炼痛点，写成人可读、机器可执行的 `intent.md`
设计	分析师写规格，设计师再解读成设计	需求与设计压缩进一次与智能体的协作会话，由编码为技能（skills）的标准来引导，纳入 git 版本控制
构建	测试和代码手写，文档在主要开发工作完成后补写	测试和代码由 AI 生成，团队知识以带版本的机器可读 `CLAUDE.md`文件和技能形式维护
测试	在阶段边界设 QA 关卡	持续的评测（evals）贯穿实现全过程
部署	人工逐行评审代码，治理散落在评审周期里，常常执行不一致	多层智能体评审，人工评审留给受监管和关键代码；治理在 AI 行动的同时被强制执行，钩子（hooks）充当审批关卡
维护	人盯着生产环境找 bug	智能体监控实际运行的部署；任何越界的控制指标都会被诊断，并作为新的 `intent.md`重新写回循环

贯穿右侧那一列的主线，是"已提交的 artifact"。每个阶段结束时都要把一份 artifact 写入版本控制（intent.md、spec.md、plan.md、diff 及其测试、带评审意见的 PR、事件记录），下一个阶段则从读取这份 artifact 开始。在早期阶段，.md文件是主要的 artifact 形式，因为产品负责人和智能体都能读懂、也都能对同一份文件采取行动。从"构建"阶段起，artifact 就变成了代码及其相关记录。这条提交链，同时也就是审计轨迹：谁提出了什么要求、智能体产出了什么、又是谁批准的。

人依然对每一个需要判断力的决定负责。在智能体化的 SDLC 里，人的注意力会随着"需要被评审的 artifact"而转移。

各阶段的"打法"（Plays）

这些"打法"是整套手册的核心，被归入六个非线性的阶段（规划、设计、构建、测试、部署、维护），共同覆盖整个生命周期。

每个打法都包含：改变了什么；如何上手；具体的实施步骤；治理层面的考量；如何衡量它是否奏效。

这些步骤是模块化的，不同组织可以根据自身需求，选择优先改造不同的阶段。每个打法都在"前置条件"里注明了它的依赖关系，文中的依赖关系图会进一步展示这一点。

一个阶段的结束方式，是提交一份 artifact，而这次提交本身就会触发下一个阶段。一份被接受的 intent.md会触发需求与设计环节；一份被批准的 spec.md会触发计划模式；一次合并的 PR 会触发流水线；生产环境中一次越界的控制指标，则会写出下一份 intent.md，循环由此继续。

一开始，你需要手动去提示每一步；理想的终态，则是一个循环——每一份被接受的 artifact 都会自动触发下一道关卡。人的注意力集中在这些关卡上，审阅智能体标记出来的问题，而不必每个阶段都从零开始。

阶段一｜规划（Plan）

核心变化：想法不再需要等人来把它写下来。意图只需被记录一次，用发起者自己的原话，写成一份下一阶段可以直接采取行动的、纳入版本控制的 artifact。

记录为 intent.md：触发整个软件开发流程的 intent.md，可以经由不同渠道产生——一个人有了想法、一张工单被提交，或者一次事件通过告警被发现（见阶段六：维护）。

当一个人有了想法，他会和 Claude 一起头脑风暴，产出一份 markdown 格式的原型规格（proto-spec）。而在传统 SDLC 里，这个人还得再去说服产品团队的某个人，帮他（或代他）把这个想法正式写下来。

Claude 生成的这份原型规格是人可读的、纳入版本控制的，并且下一阶段可以立即拿来用，它被保存为一份 intent.md。

无论意图是由某个事件触发还是由智能体生成，接下来的步骤都是一样的：产品负责人会在提交之前，审阅并修正智能体写出的这份 intent.md。

传统做法：一个想法要经过待办事项、用户故事、故事点、精化会议，才能被真正付诸行动。每一次交接都会转移责任归属，等到达工程团队手上时，往往已经和发起者的原意相去甚远。

AI 原生做法：发起者与 Claude 一起头脑风暴，把结果写成 intent.md——一份用发起者自己的语言写就的原型规格。这份 artifact 包含"想要什么、为什么想要、有哪些约束"，重复性的流程则被编码进技能里。

上手方式

• 前置条件：无。
• 基础设施：为非工程师人员提供 Claude 访问权限（claude.ai 或 Cowork）；一份约定好的 intent.md模板；一个产品负责人会持续关注的、共享的、纳入版本控制的意图存放位置。对单一产品而言，最简单的做法，是在产品仓库里建一个 intent/文件夹，这样能让 artifact 链条紧挨着由它衍生出的代码。只有当意图跨越多个仓库时，一个专门的意图仓库才值得投入（在单体仓库里，它就是一个目录）。

搭建这套东西是平台或工程团队的一次性工作。技术团队成员需要搭好这个"意图之家"，并决定谁有权限往里写——因为很多贡献者会来自组织内各个部门。一旦仓库建好，没有 git 经验的贡献者也不需要直接用 git：一个连接到版本控制系统（比如 GitHub）的连接器，能让 Claude 代他们从 claude.ai 或 Cowork 提交 markdown 文件。

执行步骤

1. 发起者用自己的话，向 Claude 描述问题——可以讲现在做不到什么、这件事影响了谁、更好的状态是什么样、或者哪些不在范围内，不需要正式的措辞。
2. 头脑风暴，直到想法变得具体。Claude 会像一名分析师那样提问：范围、用户、约束条件、成功的标准是什么。
3. 让 Claude 按组织的模板，把结果写成 intent.md（这份模板可以由技术团队成员编码成一个技能，并由负责人审核签发），内容可以涵盖问题、拟议结果、受影响的用户与系统、约束条件和待解决的问题。
4. 发起者纠正 Claude 理解有误的地方。
5. 把 intent.md提交到共享位置。作者和时间戳会随之进入记录，产品负责人从这里接手这个想法。

示例（节选）：

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

## 问题
客户打电话到客服中心询问理赔进度，客服人员大约三分之一的
通话时长都花在纯状态查询上。

## 拟议结果
客户能在门户网站上看到理赔状态、下一步操作和预计时间。

## 受影响的用户与系统
理赔专员、门户团队、理赔核心 API。

## 约束条件
门户会话中不得引入新的 PII，只能使用现有的身份认证方式。

## 待解决的问题
第三方查勘人员是否也需要访问权限？

治理考量：证据就是那份已提交的 intent.md，其中记录了作者、时间戳和完整的修改历史，这些都留在意图仓库的 git 历史里。产品负责人审批，而"接受"或"拒绝"（送入阶段二：设计）的决定，会体现为合并记录或已关闭的评审。

衡量方式

• 领先指标：从第一次对话到一份已提交的 intent.md之间经过的时间（可从意图仓库的 git 历史中读出，其中记录了作者和时间戳）。理想情况下，这个周期应从原本长达数周的调研与精化循环，降到几个小时。
• 滞后指标：intent.md的"存活率"——即产品负责人接受进入阶段二、而非直接关闭的比例；以及同一改动中，intent.md在第一份 spec.md提交之后又发生的修改次数。

阶段二｜设计（Design）

核心变化：需求与设计被压缩进同一次会话。政策在规格撰写的过程中就被应用，而不是几周之后才在评审里被发现。

需求与设计一体化：一旦产品负责人批准了 intent.md，Claude 就会据此产出一份需求与设计规格，这个过程由组织在品牌、安全、合规和 UX 方面的技能（skills）来引导。产品负责人审阅这份规格，但不需要亲自撰写它。这个过程的目标，是产出一份工程团队可以据此规划的规格，其中标注出所有需要关注的问题点。

前端工作是最典型的例子。intent.md一旦被接受，产品负责人就可以在 Claude Design（beta）里根据 intent.md做出设计原型，反复迭代，再导出给 Claude Code 去构建。

传统做法：需求和设计是由不同团队分别负责的两个独立阶段。分析师把想法正式化为需求，设计师再把需求转译回设计。这种分离是为了明确责任归属，但速度慢、且容易在传递中损失信息。

AI 原生做法：两个阶段在一次会话中同时完成。Claude 拿到 intent.md，在组织技能的约束下，产出一份需求与设计规格，并标注出需要关注的问题。

上手方式：前置条件是一份 intent.md文件，以及以技能形式编码好的品牌、安全、合规、UX 政策。基础设施上，只需要一位拥有 Claude 访问权限的产品负责人，不需要工程技能。

执行步骤

1. 产品负责人在可用组织技能的环境下打开一个会话，附上 intent.md。
2. 提示词指向这份 intent.md，说明约束条件，并要求标出需要关注的问题。一开始手动执行，之后把它固化成一个组织级的斜杠命令；再往后，可以把 intent.md在意图仓库中被接受作为触发条件，用一个非交互式任务在合并时自动触发，加载组织的技能跑一遍，把 spec.md作为 Pull Request 提交（阶段五的 CI/CD 打法会讲到具体的管线搭建）。从这一步起，产品负责人第一次介入，就是去做评审。
3. 同一位产品负责人对照最初的想法评审这份规格：它是否解决了所陈述的问题？intent.md里悬而未决的问题是否得到了回答或被继续保留？
4. 优先处理被标注出的问题点，因为这些正是一名分析师原本会上报的那些疑点。产品负责人在工程团队看到这份规格之前，就和相应的政策负责人一起把每一个问题解决掉。
5. 把 spec.md和 intent.md一起提交。这一对文件，记录了"当初要求的是什么"和"最终决定了什么"。
6. 产品负责人决定这份规格与意图是否可以进入构建阶段，对组织认定风险较高的部分，会咨询技术负责人。这个决定始终由人来做出，而接受这份规格，正是启动阶段三"计划模式"打法的动作。

示例提示词：

读取附带的 intent.md，为把它整合进我们现有代码库产出一份需求与
设计规格。运用你可用的技能，确保计划符合我们的品牌规范、安全
政策和 UX 标准。把规格完整地写成 spec.md，可以直接交给工程团队。
清楚地描述任何需要关注的问题，尤其是当你无法同时满足相互冲突
的政策时。

治理考量：现行政策在规格撰写的当下就被读取并应用，而不是几周之后才在评审里被发现。组织的技能被当作对规格的约束条件应用；这份规格、产生它的提示词，以及当时生效的技能版本，都记录在版本控制中。产品负责人签发规格，并把标注出的问题路由给对应的政策负责人。

衡量方式：领先指标——同一改动中 intent.md提交与 spec.md提交之间经过的时间（两个 git 时间戳），与旧有的"需求+设计"周期对比。滞后指标——构建开始后的需求返工，统计在同一改动的首个 plan.md提交之后才提交的 spec.md（git log 可以直接给出这个数字）。

阶段三｜构建（Build）

核心变化：没有被接受的计划，就不会有任何实现。团队知识变成了智能体会去读取的文件，护栏以代码的形式运行，而不再依赖习惯。

以 Claude Code 计划模式作为默认起点：工程师在计划模式下启动 Claude Code 会话，把阶段二批准的 spec.md交给 Claude，让它对自己进行"访谈"，反复迭代计划，直到工程师满意为止。

传统做法：工程师读完设计就开始写代码。这次改动具体要怎么做——改哪些文件、写哪些测试——往往只存在于工程师自己脑子里，最多写在一条工单评论里，没有别人能评审它。评审者第一眼看到的是完成后的 diff，这时再返工就很慢了。

AI 原生做法：工作从一份书面计划开始，由 Claude 在计划模式下产出（这个模式下它可以读代码库，但不能改动任何东西）。工程师在代码被写出之前先修正这份计划，被批准的版本以 plan.md的形式提交，供后续阶段核对。

上手方式：前置条件是意图类 artifact（intent.md或 spec.md，如果存在的话），有 CLAUDE.md会有帮助。基础设施是拥有仓库访问权限的 Claude Code。

执行步骤

1. 工程师在计划模式下与 Claude 开始会话。
2. 把 intent.md和 spec.md交给 Claude，要求给出一份实现计划，写明会改动哪些文件、工作的顺序，以及能证明结果的测试。
3. 追问这份计划：这次改动可能弄坏什么？哪一步风险最大？Claude 还考虑过、但没有选用的其他方案是什么？
4. 反复迭代，直到一个完全没参与过这次对话的工程师，也能单凭这份计划把改动实现出来。
5. 把批准的计划以 plan.md提交。这份计划加入审计轨迹，阶段五的 PR 评审打法会拿最终的 diff 去对照它。
6. 接受计划，让 Claude 去实现。有了扎实的计划，实现往往一次就能通过。
7. 当实现偏离了计划，要在同一次提交里更新 plan.md。可以考虑用一个钩子来强制这两者保持同步。

示例（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. 接入门户导航。

## 风险
理赔核心 API 限流为 50 rps，面板必须做缓存。

## 验证方式
test_status.py 覆盖四种理赔状态；截图与已批准的原型一致。

治理考量：设计评审发生在任何代码被生成之前——那时改变方向只是编辑一份文档的事。计划模式本身就会强制执行这一点，因为在工程师接受计划之前，Claude 无法编辑文件。计划及其修订会连同批准人一起被记录下来。常规改动由工程师本人批准，组织认定风险较高的部分则上交技术负责人或架构师。

衡量方式：领先指标——从首次实现就能合并的改动比例；从计划批准到 PR 合并所经过的时间（数据来自 PR 元数据）。滞后指标——每次改动的返工轮次（同样来自 PR 元数据），以及最终合并的 diff 与已提交的 plan.md保持一致的频率。

Claude Code 的 Auto Mode：Claude Code 也可以运行在 auto mode 下——工程师批准并反复打磨过计划之后，Claude 会应用每一处改动，而不必逐条编辑都弹窗确认。随着后续打法带来的护栏逐渐成熟（一份调校好的 CLAUDE.md、把政策编码成技能、拦截不安全操作的钩子，以及一套 Claude 可以自行运行的测试套件），对常规工作而言，自动接受会成为默认方式：一份严谨的 spec.md、一个较小的影响范围，以及测试已经覆盖到的代码。

这标志着一次转变：从"用户盯着智能体做每一次编辑、逐条审查动作"，转向"在更长的自主会话结束之后，审查最终的 artifact"。配合 worktree 使用时，自动接受模式还能进一步实现个人与团队层面的并行化，这正是阶段六里"自主运行 SDLC、闭合整个循环"的基础。

旁注｜遗留系统与"单一事实来源"（适用于流程产出的每一个 artifact）：现有的 SDLC 流程很可能已经在追踪这些 artifact 了，只是没有用 markdown 文件的形式——工作项可能在 Jira 里，需求可能在一个自带监管可追溯性的工具里，设计可能在 Figma 里，变更审批可能要走变更委员会。这些系统很难被替代，因为审计方和监管方已经认可了它们，其他团队也依赖着它们，所以 AI 原生 SDLC 必须围绕现有系统去适配。

在向 AI 原生 SDLC 过渡时，对流程产出的每一份 artifact，都指定一个系统作为"单一事实来源"，其余系统只持有副本或指向原件的链接。可选的配置包括：

• 以代码仓库为事实来源：markdown artifact 是权威记录，遗留系统只在提交记录里引用文件。对以工程为主导的组织来说，这可能是最干净的配置，因为所有记录都活在同一个工具里，由同一个时间戳权威来管理。
• 以遗留系统为事实来源：Jira、ServiceNow 或需求工具持有权威记录，markdown artifact 只是工作副本。Claude 在会话开始时读取记录，并在产出规格或计划的同一次会话中，通过一个 MCP 连接器把结果写回去。
• 以关联关系为最低门槛：所有 artifact 都记下对应的记录 ID，所有遗留记录里都包含 markdown 文件的提交 SHA 值。在向 AI 原生 SDLC 过渡的早期，接受"存在两个事实来源、但彼此关联"是一个不错的起点。

只要两个系统之间存在关联，或者其中一个被明确宣告为事实来源，遗留系统和以 markdown 为先的系统就可以共存。

CLAUDE.md：CLAUDE.md给 Claude 提供了一位新人需要了解的上下文——约定、命令、架构，以及团队最常犯的错误。原本存在于人脑子里和 wiki 上的知识，变成了一份 Claude 在每次会话开始时都会读取的文件，由整个团队共同维护，每次犯错之后都会更新。

上手方式：前置条件为无；基础设施需要一个仓库、装好的 Claude Code，以及一位熟悉代码库的工程师。

执行步骤：

1. 在仓库里跑一次 /init，Claude 会根据它发现的内容生成一份初始的 CLAUDE.md。
2. 把生成的文件精简到新人第一天就需要知道的内容——保留构建、测试、代码检查命令，重要的约定，以及 Claude 一直会犯的错误。
3. 把 CLAUDE.md提交到仓库根目录的 git 里，让整个团队共用一个版本，改动也像代码一样被评审。
4. 有一条实用的经验法则：当 Claude 第二次犯同一个错误时，这条修正就该写进 CLAUDE.md。
5. 把它控制在一页以内，因为 Claude 在会话开始时会读完全部内容，任何过时的内容都是在白白占用上下文、却没有任何好处。

示例（CLAUDE.md节选）：

# 支付服务

## 命令
- 构建：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本该拦下"的错误的频率（对该文件的修正或改动应通过 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节选）：

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

当你创建或修改一个 API 接口时：
1. 身份认证：每个接口都需要网关 JWT；/health 之外不允许匿名路由。
2. 输入校验：对照 OpenAPI schema 校验请求体，拒绝未知字段。
3. 审计：每个会改变状态的接口都要发出一条包含操作者、动作、
   实体和时间戳的审计事件。
4. 数据分类：schema 中标记为 pii 的字段绝不能出现在日志或
   错误信息中。

运行 scripts/check-endpoints.sh，并把它的输出附在你的总结里。

治理考量：技能是一种管控手段，但只是"建议性"的。它让 Claude 在写代码的当下就倾向于遵循政策，但没有任何东西强制一次会话必须遵守它。必须始终成立的政策，需要在技能之外再配一层确定性的机制——比如一个能拦截操作的钩子，或在 PR 阶段重新核查该政策的评审环节。技能让违规变得罕见，钩子让违规变得几乎不可能。技能的调用会被记录在会话轨迹里，政策负责人像评审代码一样评审对技能的改动。

衡量方式：领先指标——从政策负责人批准一项政策变更、到相应技能更新合并所经过的时间（来自技能文件夹的 PR）；滞后指标——引用该政策的 PR 评审意见数量，一旦技能真正在代码写作阶段应用了该政策，这个数字应当趋近于零（如果没有趋近于零，说明要么技能没有被触发，要么它的内容已经和官方政策脱节）。

作为构建期护栏的钩子：技能是建议性的管控，钩子则是它背后确定性的那一层。Claude 在实现阶段的大部分动作都是文件编辑和 shell 命令，所以构建阶段往往是钩子触发最频繁的地方。

构建阶段的钩子可以：拦截对受保护路径（比如生成的类或已冻结的包）的编辑；在文件编辑之后自动运行格式化工具和代码检查工具，防止风格漂移积累；防止密钥出现在 diff 里。

任何"政策必须无例外地成立"的技能，背后都应该有一个钩子撑腰。钩子会对每一个匹配到的动作运行一次，所以构建阶段的钩子应当又快又聚焦于发生改动的那个文件。像完整测试套件这类更重的检查，应当放在提交或 PR 环节去做。

一个需要人来批准的钩子，属于阶段五"部署"里的关卡范畴，因为在构建阶段插入一个审批提示，会让一个人重新卡在所有并行会话的关键路径上。

并行会话与子智能体：一名工程师可以同时驱动多条工作流。一个并行会话，是另一个完整的 Claude Code 实例，在自己独立的 git worktree 里处理一个单独的任务。每个独立会话彼此互不知情，唯一的共同点是驾驭它们的那位工程师。

子智能体在单一会话内部运行，是一个拥有自己上下文窗口和工具权限的、范围受限的帮手，适合那种在多个任务里反复出现的活儿，比如核验应用是否按预期运行。

并行会话提升了一名工程师能同时推进的任务数量，子智能体则让每个会话专注于自己的任务。工程师的工作变成了驾驭和评审这一切。

传统做法：一名工程师同一时间只做一项任务，把一天或一周的大部分时间花在构建、测试和评审上。等待时切换到别的任务在技术上可行，但这种上下文切换足够累人，很少有人会真的这么做。

AI 原生做法：一名工程师同时运行多个 Claude 会话，各自在自己的 worktree 里处理各自的任务。重复性的工作变成拥有自己上下文和工具权限的子智能体。工程师的角色转向编排，最终转向搭建和监控各种循环。

上手方式：前置条件是 CLAUDE.md（所有会话都会读取这份文件），阶段四的反馈循环也有帮助，因为当一个会话能自行核验自己的工作时，需要工程师盯着的程度就会降低。基础设施上需要一个 git 仓库（隔离性来自 worktree），以及针对组织认定安全的命令调校好的权限设置，避免会话反复卡在审批提示上。

执行步骤：

1. 工程师根据计划模式打法（阶段三）产出的计划，把工作拆分成会触及不同文件的任务，看清哪些工作彼此独立。会共享文件的任务，放进同一个会话里依次进行。
2. 每个并行任务都有自己的 worktree，比如在一个终端里 claude --worktree feature-auth，在另一个终端里 claude --worktree fix-rate-limit。worktree 是一个独立分支上的独立检出，能防止各会话在文件上互相冲突。
3. 两到三个会话是一个合理的起步规模。实际的上限，取决于一个人能认真评审多少条并行工作流，所以只在评审能跟得上的前提下增加会话数量。
4. 把重复性的工作变成定义在 .claude/agents/目录下的子智能体——每个都有名称、使用场景说明，以及它可以触及的工具。例如：一个在主智能体完成后清理不必要复杂度的"代码简化器"；一个运行应用、核查行为的"核验者"；一个探索代码库、汇报发现、但不会把主上下文塞满的"研究员"。把这些定义提交进 git，让整个团队共享。

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

---
name: verifier
description: 在会话报告完成之前，运行应用并核查改动是否生效
tools: Bash, Read
---
用 make run 启动应用。实际操作被改动的行为，以及与它最相邻的
两条流程。汇报你运行了什么、看到了什么，以及任何与 plan.md
不符的行为。不要修复任何问题，只负责汇报。

治理考量：更多的会话意味着更多的产出，所以管控必须来自仓库里的配置本身。钩子和权限设置对所有会话统一生效，每个会话做了什么都会被记录，并归因到运行它的工程师身上。

衡量方式：领先指标——在评审质量不下降的前提下，每位工程师能同时维持的会话数（从 OpenTelemetry 导出数据中统计），以及一天中花在"驾驭"而非"等待"上的时间占比；滞后指标——每位工程师每周合并的改动数（结合 PR 历史中的返工率一起看）。

阶段四｜测试（Test）

核心变化：每个会话在人看到结果之前，都会先核验自己的工作；而驾驭智能体的那套配置本身，也要像它写出的代码一样接受回归测试。

给 Claude 一个反馈循环：始终给 Claude 一种核验自己工作的方式——无论是测试、构建，还是截图比对。一个会话在工程师看到之前，就先检查并修正自己的错误。

反馈循环不应与"核验者"子智能体（阶段三）混为一谈。反馈循环贯穿整个任务，反复运行多少次都行；而核验者子智能体，则是一种打包"最终检查"的方式——在会话认为工作已完成之后，用一个全新的上下文窗口去跑一遍核验，这样得出的结论就不会被产出这段代码时的假设所影响。

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

AI 原生做法：会话被赋予一种在人看到之前核验自己工作的方式——跑测试、跑构建、截图比对。Claude 反复迭代直到检查通过，所以送到工程师手上的东西已经先过了这一关。搭建这套循环的工作，落在运行这个会话的工程师身上。

上手方式：前置条件无；基础设施需要一套能各自用一条命令在本地运行的测试套件和构建流程。对于 UI 相关的工作，让 Claude 能"看到"结果至关重要——可以是一个浏览器工具，或者通过 MCP 接入的截图工具。

执行步骤

1. 如果今天核验工作需要一连串命令和一些环境知识，就把它们包进一个单一的目标里，比如 "make test" 或 "npm test"，失败时返回非零退出码。
2. 在 CLAUDE.md的命令小节里，列出每条命令，并给出一个健康输出的示例。
3. 给出一个可量化的目标，让 Claude 不用问你就能自行核验，比如："test_status.py里的所有测试都通过"、"截图与附带的原型一致"、或"该接口在带上新字段时返回 200"。
4. 修 bug 时先写失败的测试。让 Claude 把这个 bug 复现成一个测试，运行它，确认它确实因为你预期的原因而失败。提交这个测试，然后才让 Claude 在不改动这个测试的前提下让它通过（最后一步里的钩子可以强制执行这条限制）。一个在修复之前就存在、且智能体无法重写的测试，正是这个 bug 已被消除的证明。
5. 对 UI 工作，用一次视觉核查来闭合这个循环：给 Claude 一个浏览器或截图工具，给它原型图，让它反复迭代——实现、截图、比对、调整。两三轮是正常的，而且每一轮结果都应该在变好。
6. 把核验变成"完成"定义的一部分。这条指令写在 CLAUDE.md里：在报告任务完成前先跑测试，并展示输出。
7. 最后，这个循环本身也需要被保护，因为一个正在修 bug 的智能体，不应该有能力削弱对那段代码的检查。一个在修复任务期间拦截对测试文件编辑的钩子可以做到这一点；另一种做法，是在评审时检查 diff，凡是触及测试的改动一律拒绝。

示例（CLAUDE.md中的验证小节）：

## 核验你的工作

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

报告任何任务完成之前，先运行以上三条，并贴出输出。
如果测试失败，去修代码，而不是修测试。

治理考量：被强制执行的，是"任务报告完成之前必须先核验"，以及"智能体在修复任务期间不得编辑测试文件"这两条——在组织希望它们被绝对保证的地方，都以钩子的形式实现。证据是 Claude 实际运行并粘贴出来的"make test"的原始输出、构建日志，或截图比对结果，所以证据来自工具链本身，而非智能体的自述。这些记录会留在会话记录里（经 OpenTelemetry 导出到组织的可观测性系统），也会留在 PR 的检查结果里，供评审者和之后的审计人员查看。批准来自评审 PR 的代码负责人，他们因为机械性的证据已经附上，可以专注于意图和风险判断。

衡量方式：领先指标——智能体改动的首次 CI 通过率（CI 系统本身就能提供）；滞后指标——每个 PR 的评审耗时（应随着测试拦下了原本靠评审者拦下的问题而下降），以及事件追踪系统里的改动失败率。

CI 中的持续评测（Continuous evals）：评测是 AI 原生世界里"阶段关卡式 QA"的等价物。实践中，这意味着一套只要智能体的配置发生变化就会运行的测试组。当换了新模型、或提示词被重写时，评测组会告诉你智能体是否还能按同样的标准完成工作。

评测应当被当作一套"活的"测试组来对待——随着模型能力提升，曾经能区分优劣的案例会失效，而持续的监控又会带来新的案例需要补充进去。有些团队会选择按固定节奏、离线运行这些评测，而非每次改动都跑一遍，以下步骤针对的是持续评测的场景。

上手方式：前置条件是 CLAUDE.md和阶段四的反馈循环；基础设施需要能非交互式运行 Claude Code 的 CI，以及一个有评测运行预算的 API key。

执行步骤

1. 平台工程师从近期工作中收集 20 到 50 个真实任务，连同各自预期/已被接受的结果。
2. 把每个任务写成一条评测——即提示词，加上定义"可接受"的检查项（测试通过、代码检查干净、行为不变、政策被遵循）。
3. 这套测试组按计划、以及每当 CLAUDE.md、技能或钩子发生任何改动时，就在 CI 里非交互式地运行——因为这些配置在驾驭智能体，理应得到代码本身那种回归测试待遇。
4. 用测试结果去把关配置改动：一次让通过率下降的技能改动，在合并前需要被评审。
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 一道能跟得上智能体产出速度的关卡。通过率的阈值作为合并检查项被强制执行，每次运行都会被记录以便随时间对比，而配置改动由拥有该配置的团队批准。

衡量方式：领先指标——评测通过率随时间的变化（测试组每次运行都会汇报），以及一次生产事件转化为一条永久评测所需的时间；滞后指标——CI 里拦下的回归问题数，与事件追踪系统里记录的、流到生产环境的回归问题数之间的对比。

阶段五｜部署（Deploy）

核心变化：评审变成双向的，治理在智能体行动的同时被强制执行。智能体可以把一切都做到生产关卡为止，但无法越过它。

AI 参与 PR 评审循环：Claude 既给出评审、也接受评审——它按组织政策评审收到的 PR，也会处理自己 PR 上收到的评审意见。这让工程师的评审精力，能集中在"判断意图与风险"这件事上。

传统做法：评审能力是按人类产出速度规划的。一条 PR 要等评审者读完全部内容，评审质量随评审者的工作量起伏，作者只能一边追进度、一边看着积压越堆越多。

AI 原生做法：所有 PR 都会经过同样一套评审环节，发现的问题按严重程度排序。人的注意力上移一层——去判断这次改动是否达成了计划里设定的目标，以及这个风险是否可以接受。

上手方式：前置条件是来自阶段三的、更新过的 CLAUDE.md；如果评审环节要强制执行书面政策，还需要相应的技能，以及已定义好的子智能体。基础设施上，需要一个装好 Claude 集成的仓库——可以是管理员启用的托管式 Code Review（研究预览）服务，也可以是在自己 CI 里运行的 claude-code-action（模型调用可按需路由经过 AWS Bedrock、Google Vertex 或 Microsoft Foundry）。要求代码负责人批准的分支保护策略同样值得配置。

执行步骤

1. 托管式 Code Review 服务是最快的起步方式，由管理员启用并选定仓库；当你需要掌控整条流水线、或希望 API 调用经由自己的云合约路由时，用 claude-code-action 在自己的 CI 里运行评审。
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里给"吹毛求疵"式发现的数量设上限，生成的路径和 CI 已经强制执行的内容一律排除在外。

示例（REVIEW.md）：

# 评审说明

## 评审环节
运行三个环节，给每条发现标注所属环节：
- Bug：逻辑错误、边界情况处理不当、隐蔽的回归问题
- 安全：注入风险、身份认证漏洞、日志中的 PII
- 合规性：改动是否符合 spec.md、plan.md 以及我们的设计原则

## "重要（Important）"在这里的含义
只把"重要"留给那些会破坏行为、泄露数据或违反政策的发现。
风格和命名问题算吹毛求疵。

## 限制吹毛求疵条目的数量
每次评审最多报告五条吹毛求疵意见，其余的用一个统计数字概括。

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

治理考量：职责分离得以保留，因为写代码的智能体没有权限批准自己的代码。REVIEW.md里的评审政策适用于所有 PR，发现、修复、打分和批准都记录在 PR 历史里，PR 本身就是审计记录。批准始终来自一个通过分支保护机制的人，且这个决定是基于评审发现做出的。

衡量方式：领先指标——首次评审所需时间（应降到几分钟），以及在没有人接触分支的情况下被解决的评审意见比例（数据直接存储在 Git 里）；滞后指标——合并前拦下的缺陷与漏洞数量，对照流到生产环境的数量（来自 PR 历史和事件追踪系统）。

作为审批关卡的钩子：构建阶段把钩子当作护栏使用，在没有人介入的情况下放行或拦截操作（阶段三）。钩子也可以"发问"——暂停某个操作，直到某位指定的人批准，这正是发布把关所需要的机制。

这个打法被归在阶段五，是因为发布关卡是最典型的场景，但钩子并非部署专属：它们在 Claude 采取行动的任何地方都会运行。举例来说，钩子可以在阶段三里拦截没有变更工单的情况下对迁移文件和基础设施的编辑，也可以在阶段四的修复任务期间阻止智能体编辑测试文件。

上手方式：前置条件无；基础设施需要一份书面清单，列出变更流程要求的各项审批。

执行步骤

1. 工程管理层联合变更管理和合规部门，列出必须保留的人工审批关卡——比如变更管理签字、发布授权，以及对受保护路径的编辑。
2. 平台工程师把每一道关卡表达成一个钩子——一个在 Claude 行动之前运行的脚本，可以放行、发问或拦截。
3. 团队级别的钩子放进 git 里的 .claude/settings.json；不可协商的钩子放进由平台或 IT 管理员拥有的受管理设置里，个体工程师无法关闭它们。
4. 一次拦截应当"自我解释"：当钩子拦下一个操作时，原因和获得批准的途径都应出现在 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

治理考量：钩子就是审批关卡本身——关卡条件对每个人、每一次都会被强制执行，放行与拦截的决定都带着时间戳被记录下来。关卡同时也定义了"什么算批准"——无论是一张已批准的变更工单，还是发布经理的签字。

实战范例｜面向受监管企业的受管理设置（由平台团队通过 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把密钥挡在智能体的上下文之外，也拦下了工具发起的任意网络出站请求；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的运行器）；通过 API，或 Bedrock、Foundry、Vertex（当流量必须留在组织自己的云合约内时）获得模型访问权限；为部署目标准备的 MCP 服务器；以及一个不持有常驻生产凭证的、专为智能体任务准备的沙箱环境。

执行步骤

1. 平台工程师先从只读的判断性步骤入手——在流水线任务里用 claude -p去给一次失败的构建做分诊、总结一个不稳定的测试、或起草变更日志。
2. 在既有关卡的保护之下，逐步加入写入类步骤——比如修复代码检查问题、更新自动生成的文档、或通过 @claude提及来处理评审意见。智能体写出的任何内容，都通过分支保护以 PR 的形式送达，智能体没有直接推送到主分支的通道。
3. 执行过程被沙箱化：智能体任务运行在受网络策略约束的容器里，使用短期、限定范围的令牌，默认不持有任何生产凭证。
4. 通过 MCP 把部署能力暴露出来：部署、查看状态、回滚都变成按环境限定范围的工具，让智能体的部署能力变成一份白名单，而不是一段带着凭证的 shell 脚本。
5. 按环境分层自主程度：在开发环境中，智能体可以自由部署；在生产环境中，智能体准备好发布内容，由发布经理来授权，一个钩子强制执行生产关卡；预发布环境介于两者之间。
6. 回滚应该是流水线里被演练得最熟练的路径——一条智能体可以运行、并在预发布环境里被定期演练的单一命令。阶段六"闭合循环"的打法会在某个控制指标越界时调用这个回滚动作，所以它必须提前被验证过。

示例（流水线步骤）：

- name: Triage failed build
  if: failure()
  run: >
    claude -p "读取 out/build.log 里的构建日志。判断最可能的原因，
    说明这次失败看起来像是偶发性的还是真实的问题，并为 PR 讨论区
    写一段三行的总结。" >> triage.md

治理考量：这里的治理原则是，智能体可以把一切都做到生产关卡为止，但无法越过它。以下管控手段强制执行这条原则：分支保护把智能体写出的任何内容都变成一条 PR，没有直达主分支的路径；生产部署钩子会拦下发布，直到一位具名的发布经理授权；每一次非交互式运行都以智能体自己的身份执行，因此流水线日志能区分"智能体做了什么"和"触发它的工程师做了什么"；按环境分层的权限设置，决定了智能体在抵达关卡之前能做多少事。

衡量方式：领先指标——无需呼叫人工、就能被分诊的流水线失败比例（来自 CI/CD 流水线日志）；滞后指标——DORA（DevOps 研究与评估）指标，这些数据 CI 系统和部署工具本身就会产出。

阶段六｜维护（Maintain）

核心变化：循环真正闭合。一个触发条件会在没有人介入调用路径的情况下唤起 Claude，它的发现会以 intent.md的形式重新进入整条流水线。

前面几个阶段，讲的都是如何把 Claude 加入 SDLC 的每一步，而每一步的最初动作都需要人来启动。这个阶段，则把重心转向让 Claude 自主运行，从而真正闭合这个循环。

举例来说，一个持续运行的监控智能体，可以在一张 bug 工单被创建之后，自动生成一份 intent.md，并流经需求、计划、构建、测试和评审这几个阶段。阶段六是无人值守（headless）运行的，每个阶段之间都有一道独立的"置信度关卡"——一次确定性检查，或一个对抗性的评审智能体——来决定上一阶段的产出是继续往下走，还是被上报给人。

传统做法：维护是一个被动响应的阶段。所有工单或事件都要等人来处理、重新启动整个流程。凌晨三点响起的告警可能被漏掉，工单可能在积压里躺到有人翻到它，如果又冒出别的紧急情况，事后复盘的行动项甚至可能根本进不了代码库。

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. 编写检测脚本，通常是在一个滚动窗口内计算均值和标准差，并配合规则（西方电气规则或类似方法），使这套指标带既能捕捉突发峰值，也能捕捉缓慢的漂移。这个脚本本身纳入版本控制、有单元测试，检测过程完全确定性，不涉及任何模型。
3. 响应层级定义在纳入版本控制的配置里（见下方的 bands.yaml）：1σ 时脚本只做记录；2σ 时唤起 Claude 以只读方式诊断；3σ 时 Claude 可以采取行动——但仅限于开一条进入评审关卡的 PR，或触发一个预先批准的操作手册（runbook）。
4. 触发层可以是 GitHub 或 GitLab 里的一个计划任务、现有监控系统发出的 webhook，或内网中的一个 Cron 任务。Claude 无状态地运行——要么作为 CI 运行器上的一个非交互式步骤，要么作为沙箱容器里的一个 Agent SDK 服务（阶段五的 CI/CD 打法讲到了具体的部署与模型访问选项）。因为这次运行是无状态且非交互式的，一个循环可以在无人启动的情况下自行开始和结束。
5. 智能体把自己的诊断结果，按阶段一的格式写成 intent.md——涵盖异常现象及其证据、拟议结果、受影响的系统，以及任何待解决的问题。从这里起，这项发现就像其他任何情况一样，走一遍整条流水线。
6. 服务负责人或值班工程师对队列做分诊，把面向产品的发现路由给产品负责人：立即修复、排期，还是直接关闭。被关闭的情况有助于调优检测阈值、降低噪音。
7. 一旦某个修复上线，就为这次事件补充一条评测（对应"持续评测"打法），确保类似问题今后能被拦下。

示例（bands.yaml，以监控 CI 测试失败率为例）：

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 评审关卡，智能体可能触发的操作手册也都是提前批准好的。

衡量方式：领先指标——从指标越界到一份 intent.md进入分诊队列所经过的时间，对照旧有的"从事件发生到复盘行动"所需的时间（检测脚本的日志里有越界的时间戳和层级）；滞后指标——最终变成已合并修复的发现比例（分诊队列对照真实的 PR 历史），以及同一类事件的重复发生率——随着这些修复不断为评测组增添案例，这个比例应当逐渐下降。

示例场景：

• 当 CI 测试失败率越过 3σ 时，智能体隔离掉那个不稳定的测试，或开一条回退 PR，由评审关卡来决定。
• 当部署后 5xx 率在一次部署窗口内越过 3σ 时，智能体触发既有的回滚流水线。
• 当 PR 周期时长触发了漂移规则时，智能体为工程管理层写一份报告——这也说明这套框架同样适用于流程类指标，而不仅仅是生产环境指标。

检测环节始终保持确定性，Claude 只在某个指标层级被越界之后才会被唤起，具体能做什么则由那个层级来设定。

用 Claude Tag 实现"随叫随到"：事件也可能通过其他渠道到来，比如 Slack 或 Teams 这类办公协作应用。一条晚上十点、要求紧急处理某个事件频道的 Slack 消息，现在也可以立刻被采取行动。Claude Tag（目前在 Slack 上提供公开测试版）让 Claude 以自己的身份成为这些频道的一员，于是每一次新的事件都有了第一响应者，响应过程本身也成了这个循环、以及未来事件处理记忆的一部分。

对话和团队知识都留在频道里，频道里的任何人都可以引导和推动这次响应。任何团队成员都可以实时验证假设、探索新方案、展开调查，频道历史记录进一步增强了可审计性。借助对 MCP 的访问，Claude 能核实相关指标已回到基线，在讨论串里加以确认，并把复盘写入一份纳入版本控制的经验教训文件，供未来的调查参考。

事件并不是 Claude Tag 处理的唯一工作类型。无论是通过 MCP 在一张工单上被提及，还是在频道里被直接问到，Claude 都会用同样的方式对这项工作进行分诊：一个小而边界清晰的修复，会以 PR 的形式经由评审关卡送出；而更大的工作，则会被写成 intent.md，进入阶段一的规划环节——循环由此开始自我供给。

（原文配图说明：频道本身就是审计轨迹——请求、诊断、人工授权和修复，全都留在事件被处理的那个地方。）

结语

模型和运行框架都变得更加先进了，这让企业不仅能改变自己产出代码的方式，还能改变整个软件开发生命周期本身。

这场转型始终把人的判断力放在流程的核心位置，同时也充分考虑了大型企业组织在治理和监管方面的需求。

本手册汇总了 Anthropic 应用 AI 团队日常在为客户执行的许多真实最佳实践，希望它对你来说是一份实用、可落地的参考。

循环持续运转，而人的判断力始终凌驾其上。

参考资料

以下文档是平台团队搭建上述各项管控所需要的资料，大致按你会部署它们的顺序排列：

• 为你的组织配置 Claude Code —— 管理员决策地图，从这里开始
• 设置参考与优先级，包括所有仅限受管理设置使用的字段
• 来自 Claude 管理控制台的服务器端受管理设置
• 权限
• 沙箱化——操作系统级别的文件系统与网络隔离
• 钩子——指南
• 钩子——参考文档
• 技能
• 插件与私有市场——技能和钩子如何在全组织范围内分发
• 受管理的 MCP——对智能体工具范围的集中管控
• 企业部署总览——Bedrock、Vertex、Foundry
• 企业网络配置
• 监控（OpenTelemetry）
• 分析仪表盘
• 合规 API——企业活动流、会话检索与删除
• 安全模型

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本手册的贡献——本手册的写作深受他们此前工作的启发，并建立在这些工作之上。