【官方原文全译】代码不再是瓶颈：AI 原生 SDLC 手册，六阶段逐段拆

企业 AI · 研发流程改造 · 六阶段 Play 手册

代码不再是瓶颈
AI 原生 SDLC 手册：六个阶段，逐段拆

Anthropic 应用 AI 团队的落地实践。从 intent.md 到生产闭环——交付物怎么串、护栏怎么设、闸门谁来守、成不成怎么量。

目 录

代码不再是瓶颈
什么是 AI 原生 SDLC？
Play 手册
01 —— Plan（规划）
02 —— Design（设计）
03 —— Build（构建）
04 —— Test（测试）
05 —— Deploy（部署）
06 —— Maintain（运维）
结语

一句话：写代码的成本坍缩之后，瓶颈挪到了构建的两侧——规划、评审、部署仍按人的速率在跑。Anthropic 应用 AI 团队这份手册，逐阶段给出六套 Play，每套都答五件事：变了什么、怎么起步、具体步骤、治理考量、怎么衡量。

贯穿全文的那根线：每个阶段以向版本控制提交一份交付物收尾，下一阶段以读取它开场。intent.md → spec.md → plan.md → diff 与测试 → PR 与评审结论 → 事故记录。这条提交链本身就是审计轨迹。环路可以自主运转，人的判断悬在它之上。

用 AI 改造软件开发生命周期——六个阶段，逐个拆。

分类：企业 AI、Claude Code
产品：Claude Enterprise、Claude Code、Claude Tag
日期：2026 年 8 月 21 日
阅读时长：5 分钟
作者：Louis Claxton

代码不再是瓶颈

各家组织用 AI 写代码的速率，一年前想都不敢想。可代码周边那一套流程，没跟上。

不少工程团队仍在沿用同一批审批关卡、评审、交接和策略，把 Claude Code 这类 agentic coding 工具挣来的效率又堵了回去。

软件开发生命周期（SDLC）是把软件从想法送到生产的全过程。多数组织跑的都是同六个阶段：规划、设计、构建、测试、部署、运维。传统上每个阶段彼此独立，各由一个角色把持。产品经理写需求，架构师把需求转成设计，工程师照着设计实现，受监管企业的 QA 团队做验证，发布团队上线，运维盯着跑起来的东西。阶段之间靠文档、工单和签字往下传。

传统 SDLC 之所以流程繁重，是为了在每一步都压住问责与管控。然而，传统 SDLC 的高效，是为一个「最耗时最昂贵的阶段就是写代码」的时代设计的——这个前提已经不成立了。PRD、估算仪式、产品安全评审，都是为了在动辄数周、数月乃至数季的开发周期里强行对齐。

传统 SDLC 的管控措施还默认每一步都由人执行。产出价值最高的那些组织，已经围绕 agentic AI 现在能做的事重建了流程，同时确保人仍在回路里。本手册梳理 Anthropic 应用 AI 团队在内部（以及与客户合作时）把 Claude 接入 SDLC 各阶段的若干最佳实践，目标是加速开发、让流程跑得更快。

代码不再是瓶颈、构建阶段的速率超出传统 SDLC 的容纳范围，就会有三件事同时成立：

瓶颈挪到了构建阶段的两侧，主要是规划、评审与测试、部署，这三处仍按人的速率在跑。
管控措施与现实脱节，变得棘手。人写的代码，逐行手审是合理的；可一旦 diff 大部分由 agent 产出，逐行审就跟不上了。
治理成本上升，因为例外情况仍要过那些每周或每月才开一次的会议和委员会。

构建不再是约束，它两侧那些按人的速率跑的阶段才是。构建坍缩到几小时，人的阶段长度照旧。

拿安全团队举例。安全团队的编制是按人的产出配的，agent 把代码产出翻上去，要么评审队列堆积，要么代码没审透就上线。受监管的组织这两样都接受不了，它的安全与策略检查必须跟上 agent 的速度。

要充分吃下 agentic AI 的效率收益并保证安全，传统 SDLC 就需要一场与实现阶段同等量级的改造。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一套重做的流程，把旧的管控目标和新的执行手段合到一处。流程不再是线性流，而成为一个环，AI 嵌在每一处。AI 原生 SDLC 推行自动交接与后续 Play 的自动触发，用来解决传统 SDLC 阶段间交接那套笨重的手工活。

这场转变也有别的叫法——agentic SDLC、AI SDLC，或者干脆叫 agentic 软件开发。名字不同，说的是同一件事。

AI 原生 SDLC 六个阶段的位移

下表列出传统 SDLC 与 Claude 加持的 AI 原生 SDLC 这两个极端，多数组织落在两列之间的某处。

阶段传统 SDLCAI 原生 SDLC
Plan需求由委员会收集，经过研讨会与签字层层提炼，最后人工成文Claude 直接从源头综合痛点，写进 intent.md，人能读、机器能执行
Design规格由分析师撰写，再由设计师解析需求与设计压缩成同一次 agent 工作会话，由编码为 skills 的规范引导，在 git 里版本化
Build测试与代码手写，文档在主开发完成后补写测试与代码由 AI 生成，机构知识以版本化的机器可读 CLAUDE.md 与 skills 维护
Test阶段边界设 QA 关卡持续 evals 织进实现过程
Deploy人逐行审代码，治理在评审周期里进行，且常不一致分层 agentic 评审，人审只留给受监管与关键代码。治理在 AI 行动时执行，hooks 即审批关卡
Maintain人盯着生产找 bugagent 监控线上部署。任何被突破的控制带会被诊断，并作为新的 intent.md 写回环路

贯穿右列的主线是交付物。每个阶段以向版本控制写入一个交付物收尾（intent.md、spec.md、plan.md、diff 及其测试、PR 及其评审结论、事故记录），下一阶段以读取它开场。早期阶段以 .md 文件为主，因为产品负责人和 agent 都能读、都能据此行动。从 Build 往后，交付物就是代码及其记录。这条提交链同时也是审计轨迹：谁提了什么、agent 产出了什么、谁批的。

凡是需要判断的决策，人依然担责。在 agentic SDLC 里，人的注意力随需要评审的交付物一起移动。

每个阶段都提交一个下一阶段能读的交付物。意图、规格、计划、diff 与评审结论合起来，就是审计轨迹。

Play 手册

Play 是这本手册的核心，分成六个非线性阶段（Plan、Design、Build、Test、Deploy、Maintain），合起来覆盖完整生命周期。

每个 Play 讲五件事：

变了什么；
怎么起步；
具体实施步骤；
治理考量；以及
怎么衡量成没成。

这些步骤是模块化的，组织可以按自身需要，在不同时点优先改造不同阶段。每个 Play 在「前置条件」下列出它的依赖，依赖图有进一步说明。

一个阶段以提交交付物收尾，这次提交随即启动下一阶段。被接受的 intent.md 触发需求与设计这一轮，获批的 spec.md 触发 plan mode，合并的 PR 触发流水线，生产环境里被突破的控制带写下下一个 intent.md——环就这么转下去。

起初你手工 prompt 每一步，最终状态是一个环：每个被接受的交付物点燃下一道闸门。人的注意力集中在闸门上，评审 agent 标记出来的东西，而不是从零启动每个阶段。

Play 按阶段列出，箭头给出的是采纳顺序，两者不是一回事。从任何一个黏土 Play 起步——没有箭头指向它，所以它不需要任何前置。其他 Play，指向它的箭头就是你要先采纳的那些。

01 —— Plan（规划）

想法不再等人把它写成文档。意图只捕获一次，用提出者自己的话，成为下一阶段能直接行动的、版本化的交付物。

捕获为 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/ 目录。这样放，交付物链就紧挨着由它派生出的代码。只有当意图横跨多个仓库时，独立的意图仓库才值那份开销；在 monorepo 里，它就是一个目录。阶段 3：构建 的边栏会讲这个存放处如何与已在管记录的 Jira 或需求工具对接。

这套搭建是平台或工程团队的一次性活。需要一位技术成员把意图存放处立起来，并定下谁能往里写，因为贡献者会来自组织各处。

仓库一建好，没用过 git 的贡献者也不必直接碰 git。给版本控制系统（比如 GitHub）接一个连接器，Claude 就能从 claude.ai 或 Cowork 代他们提交 markdown 文件。

怎么执行

提出者用自己的话向 Claude 描述问题。他可以讲今天做不到什么、这想法影响到谁、更好是什么样、或者什么不在范围内。不需要任何正式措辞。
头脑风暴到想法足够具体。Claude 会问分析师会问的问题：范围、用户、约束、成功长什么样。
让 Claude 按组织的模板把结果写成 intent.md。模板可由技术成员编码为一个 skill，经负责人签核。内容可涵盖问题、预期结果、受影响的用户与系统、约束、以及待决问题。
提出者修正 Claude 理解错的地方。
把 intent.md 提交到共享存放处。作者与时间戳一并入档，产品负责人从这儿接手。

示例 —— intent.md：

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

治理考量

证据就是提交上去的 intent.md，它列着作者、时间戳和完整修订历史，记在意图存放处的 git 历史里。产品负责人审批，「接受或拒绝」这个把意图送进阶段 2：设计的决策，以合并或关闭评审的形式留痕。

怎么衡量

先行指标： 从首次对话到提交 intent.md 的耗时，从意图存放处的 git 历史读取，那里记着作者和时间戳。预期是从数周的需求 elicitation 与梳理周期，降到几小时。

滞后指标： 存活率，即产品负责人接受进入阶段 2：设计、而非被关闭的 intent.md 占比。接受或拒绝的决策记为交付物的合并或评审关闭。此外还有：同一次变更中，首份 spec.md 提交之后对 intent.md 的修改次数。

02 —— Design（设计）

需求与设计坍缩进同一次会话。策略在写规格时就施加，而不是几周后评审时才被发现。

需求与设计

产品负责人批过之后，Claude 接手被接受的 intent.md，产出一份需求与设计规格。过程受组织在品牌、安全、合规、UX 方面的 skills 引导。

产品负责人评审这份规格，但不写它。这套流程的目标是产出一份工程团队可据此排期、并把存疑处标注出来的规格。

前端工作是最清楚的例子。intent.md 被接受后，产品负责人在 Claude Design（beta）里照着它把设计稿做出来，反复改，然后导出到 Claude Code 去实现。

传统做法： 需求与设计是分开的两个阶段，由两队人跑。分析师把想法形式化为需求，设计师再把需求解析成设计。分开是为了问责，代价是慢，且有损。

AI 原生做法： 两个阶段发生在同一次 prompt 会话里。Claude 接手 intent.md，产出需求与设计规格，受组织 skills 约束，存疑处已标注。

怎么起步

前置条件： 一份 intent.md，以及把品牌、安全、合规、UX 策略写成 skills。

基础设施： 一位有 Claude 访问的产品负责人。不需要工程技能。

怎么执行

产品负责人开一个会话，把组织的 skills 挂上，并附上 intent.md。
产品负责人的 prompt 指向 intent.md，点明约束，并要求标出存疑处。先手工跑，之后把它固化成组织级斜杠命令。再往后，把意图存放处里 intent.md 的接受动作设为触发器，用一个在合并时触发的非交互任务，在加载组织 skills 的前提下跑这一轮，并把 spec.md 作为一个 PR 提交（阶段 5：部署 的 CI/CD Play 讲这套管道）。到这一步，产品负责人的首次介入就是评审。
同一位产品负责人拿规格对照想法来审。这份规格解决了陈述的问题吗？intent.md 里的待决问题是答了，还是顺延了？
先处理标注出来的存疑处，那些正是分析师本会往上升级的点。产品负责人在工程看到规格前，会同各策略负责人把每一条解决掉。
把 spec.md 与 intent.md 一起提交。这一对文件记下了要什么和定了什么。
产品负责人决定规格与意图是否进入构建，涉及组织定为较高风险的，会咨询技术负责人。这个决定总由人类同事来下，而接受规格正是启动阶段 3：构建 的 plan mode Play 的动作。

它长什么样（prompt）

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

治理考量

策略不再是几周后评审时才被发现，而是在写规格的当下被读取并施加。组织的 skills 作为约束施加在规格上。规格、产出它的 prompt、以及当时生效的 skill 版本，全都记进版本控制。产品负责人签核规格，并把标注的存疑处转给指名的策略负责人。

怎么衡量

先行指标： 同一次变更中 intent.md 提交与 spec.md 提交之间的墙钟时间（两个 git 时间戳），与旧的需求加设计周期对照。

滞后指标： 构建开始后的需求返工。数一数同一次变更中，日期晚于首份 plan.md 提交的 spec.md 提交。git log 直接能给。

03 —— Build（构建）

没有被接受的计划，什么都不许实现。机构知识变成 agent 读的文件，护栏以代码运行，而不是靠习惯。

Claude Code plan mode 作为默认起点

工程师以 plan mode 启动 Claude Code 会话，把阶段 2：设计 里获批的 spec.md 交给它，让它反问自己，反复迭代计划，直到工程师满意。

传统做法： 工程师读设计，然后开写。这次改动具体怎么做——动哪些文件、写哪些测试——只留在工程师脑子里，好一点的情况是写在工单评论里，别人没法评审。评审者第一眼看到的是成品 diff，到那时返工就慢了。

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

怎么起步

前置条件： 意图交付物（intent.md 或 spec.md，若有其一），CLAUDE.md 有帮助。

基础设施： Claude Code，能访问仓库。

怎么执行

工程师以 plan mode 与 Claude 开启会话。
工程师把 intent.md 和 spec.md 交给它，要一份实现计划，说清改动哪些文件、工作顺序、以及证明它成立的测试。
拷问这份计划：这次改动可能破坏什么、哪一步风险最高、Claude 没选的其他方案是什么。
迭代到一位从没看过这段对话的工程师，能照着计划独立把改动实现出来。
把获批的计划提交为 plan.md。计划并入审计轨迹，PR 评审 Play（阶段 5：部署）会拿最终的 diff 跟它核对。
接受计划，让 Claude 实现。计划扎实的话，实现常常一遍过。
实现偏离计划时，在同一次提交里更新 plan.md。可以考虑用一个 hook 强制两者同步。

它长什么样（plan.md）

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

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

## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.

## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

治理考量

设计评审发生在任何代码生成之前，那时改方向不过是编辑一份文档。plan mode 本身就强制执行这一点，因为在工程师接受计划之前，Claude 不能编辑文件。计划及其修订，连同是谁接受的，一并记录。例行改动由工程师批准，组织定为较高风险的，交技术负责人或架构师。

怎么衡量

先行指标： 首次实现就合并的改动占比，以及从计划获批到 PR 合并的时间，所需数据就在 PR 元数据里。

滞后指标： 每次改动的返工轮次（同样取自 PR 元数据），以及合并后的 diff 与已提交的 plan.md 仍然吻合的频率。

Claude Code 的 auto 模式

Claude Code 也能跑 auto 模式：工程师批准计划，满意并迭代完之后，Claude 逐条应用改动，不再每次编辑都来问一遍。随着后面几个 Play 的护栏成熟（调好的 CLAUDE.md、编码策略的 skills、阻断危险动作的 hooks、以及一套 Claude 能自己跑的测试），auto-accept 会成为例行工作的默认：一份紧实的 spec.md、很小的爆炸半径、以及测试已经覆盖的代码。

重心由此从「用户盯着 agent 改、审每一步动作」，转向「更长的自主会话之后评审交付物」。auto-accept 配合 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 上的知识，变成一份 agent 在每次会话开头读取的文件，由全团队维护，每犯一次错就迭代一次。

怎么起步

前置条件： 无。

基础设施： 一个仓库，装好 Claude Code，以及一位熟悉代码库的工程师。

怎么执行

在仓库里跑 /init。Claude 会根据它看到的东西生成一份起始 CLAUDE.md。
把生成的文件砍到「新人第一天需要的」那个量。留下构建、测试、lint 命令，真正要紧的约定，以及 Claude 老是搞错的地方。
把 CLAUDE.md 签入 git 的仓库根目录，让全团队共享一个版本，改动像代码一样被评审。
一条管用的规则：Claude 同一个错犯两次，修正就写进 CLAUDE.md。
控制在一页以内，因为 Claude 每次会话开头会通读全部内容，任何过时的东西都在白占上下文。

它长什么样（CLAUDE.md）

# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.

治理考量

CLAUDE.md 版本化，所以 agent 遵循的指令可评审、可审计。团队约定通过这个文件施加，对它的改动记在 git 历史里，代码 owner 在 PR 评审中批准这些改动。

怎么衡量

先行指标： Claude 重复犯 CLAUDE.md 本该拦住的错的频率。对 CLAUDE.md 的修正或改动应当在 git 历史里被跟踪。

滞后指标： 团队新成员首个 PR 合并的耗时，取自 PR 历史。

Skills 作为机构知识

Skills 是组织让机构知识真正落地的方式。指令是显式的、版本化的、被广泛施加的，策略一变就集中更新。经验法则：把必须一致施加的机构知识写成 skill；属于 CLAUDE.md 或 prompt 的内容，别写成 skill。

怎么起步

前置条件： 无必需项。有 CLAUDE.md 会更好，因为它把 agent 的工作知识留在仓库里，但 skill 并不依赖它。

基础设施： 一项策略，有一位指名负责人，以及一份成文的事实源。

怎么执行

挑一条今天执行得前后不一致的知识。可以是安全标准、API 设计约定，或者品牌规则。
把它写成一个 skill，即一个含 SKILL.md 的目录，frontmatter 写它何时触发，正文写要做什么。工程师依据策略负责人的事实源来写，可用 Claude 帮忙。
把 skill 放进仓库的 .claude/skills/<name>/，让它随代码分发；或者通过插件在组织范围内分发。
验证 skill 会触发。用不同方式让 Claude 做相关任务，确认 skill 每次都加载。
策略变了就改 skill，并让策略负责人签核这次变更。
工程师在下一次会话里自动拿到新版本。

它长什么样（.claude/skills/secure-api-review/SKILL.md）

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
modifying an external-facing endpoint, reviewing API code, or
generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

治理考量

Skill 是一种控制，不过是劝导性的。它让 Claude 在写代码时更可能施加策略，但没有任何东西强制会话遵守它。必须始终成立的策略，需要在 skill 背后放点确定性的东西，比如一个阻断该动作的 hook，或者在 PR 处复检策略的评审轮次。Skill 让违规变少，hook 让违规近乎不可能。Skill 的调用记在会话追踪里，策略负责人像评审代码一样评审 skill 的变更。

怎么衡量

先行指标： 从策略负责人批准策略变更，到更新后的 skill 合并的耗时，取自 skill 目录上的 PR。

滞后指标： PR 评审中引用该策略的发现数。一旦 skill 在写代码时就施加了策略，这个数应当趋近于零。要是不趋零，要么是 skill 没触发，要么是它的文本已与官方策略脱节。

Hooks 作为构建期护栏

Skill 是劝导性控制，hook 是它背后的确定性层。Claude 的多数动作都是实现过程中的文件编辑与 shell 命令，所以构建阶段是 hook 触发最频繁的地方。

构建期 hook 可以：

阻断对受保护路径的编辑，比如生成的类或一个冻结的包；
在文件编辑后跑 formatter 和 linter，让漂移无从累积；
把凭据挡在 diff 之外。

任何「策略必须无例外成立」的 skill，都要拿 hook 兜底。hook 在匹配的每个动作上运行，所以构建期 hook 要快，且作用域限定在改动的文件上。全量测试套件这类重检查，放在提交或 PR 那一层。

要向人征求批准的 hook 属于阶段 5：部署 的闸门，因为构建中途弹审批，等于把所有并行会话的关键路径上重新塞回一个人。

并行会话与子 agent

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

并行会话是另一个完整的 Claude Code 实例，在自己的 git worktree 里跑独立任务。每个独立会话彼此一无所知，把它们串起来的只有那位工程师。

子 agent 跑在单个会话内部，是一个有自己上下文窗口和工具限制的、范围受限的助手，适合在多个任务里反复出现的活，比如验证应用是否按预期运行。

并行会话抬高了一位工程师在飞任务数，子 agent 让每个会话专注于自己的任务。工程师的活是掌舵和评审所有这一切。

传统做法： 一位工程师一次干一个任务，一天或一周里有相当一部分花在构建、测试和等评审上。等的时候切任务是可能的，但上下文切换累人，很少有人选。

AI 原生做法： 一位工程师同时跑几个 Claude 会话，各自在自己的 worktree 里跑自己的任务。重复的活变成有自己上下文和工具限制的子 agent。工程师的活转向编排，并最终转向搭建和监控环路。

怎么起步

前置条件： CLAUDE.md，因为所有会话都读这个文件。反馈环（阶段 4：测试）也有帮助，因为会话若能自验，工程师需要盯的程度就低了。

基础设施： 一个 git 仓库，因为隔离靠 worktrees，另外权限设置要调到不会让会话卡在「组织认为安全的命令」的审批提示上。

怎么执行

工程师把工作拆成触及不同文件的任务，用 plan mode Play（阶段 3：构建）的计划看清哪些工作彼此独立。共用文件的任务放在单个会话里，一个接一个跑。
每个并行任务分到自己的 worktree，比如一个终端里 claude --worktree feature-auth，另一个里 claude --worktree fix-rate-limit。worktree 是独立分支上的独立检出，能防止会话在文件上撞车。
两三个会话是合理的起点。实际天花板是一个人能认真评审多少条流，所以只在评审跟得上时才加会话。
把重复的活做成子 agent，定义在 .claude/agents/ 下的 markdown 文件里，每个带名字、何时使用的描述、以及可碰的工具。例子包括：主 agent 收工后剥掉不必要复杂度的代码简化器；跑起应用并检查行为的验证器；探索代码库并回报而不淹没主上下文的研究员。把这些定义签进 git，让全团队共享。

它长什么样（.claude/agents/verifier.md）

---
name: verifier
description: Runs the app and checks the change works before the session
reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

治理考量

会话越多产出越多，所以管控必须来自仓库里的配置。那里的 hooks 与权限设置施加于所有会话，一个会话做了什么会被记录并归属于跑它的那位工程师。

怎么衡量

先行指标： 在评审质量不掉的前提下，每位工程师的并发会话数，从 OpenTelemetry 导出里统计；以及一天里花在掌舵而非等待上的占比。

滞后指标： 每位工程师每周合并的改动数，与取自 PR 历史的返工率对照着看。

04 —— Test（测试）

每次会话在人看到之前先自验，而且驱动 agent 的那套配置，要像它写的代码一样接受回归测试。

给 Claude 一个反馈环

永远给 Claude 一条自验的路径——测试、构建，或者截图 diff。会话自验自纠，工程师看到之前就把错修了。

反馈环别和 verifier 子 agent（阶段 3：构建）混为一谈。反馈环贯穿整个任务，随工作反复跑。verifier 子 agent 则是把最后检查打包的其中一种方式——在会话认为工作完成时开一个全新上下文窗口跑一次，这样结论不会被产出代码的那些假设染色。

传统做法： 「代码能跑」这个信号来得太晚。CI 在几分钟后，测试在几天后，生产在几周后。让 agent 来产出代码，信号晚意味着人得检查它的全部产出，这个人就成了瓶颈。

AI 原生做法： 会话在人看到之前就拿到自验手段。跑测试、跑构建、截个图。Claude 迭代到检查通过，所以到工程师手上时已经过了检查。搭这个环是跑会话那位工程师的活，下面几步就是写给他们看的。

怎么起步

前置条件： 无。

基础设施： 一套测试和一个构建，各自一条命令能在本地跑起来。对 UI 工作，让 Claude 看到结果至关重要——要么一个浏览器工具，要么通过 MCP 接进来的截图工具。

怎么执行

如果今天检查工作要一串命令加一些环境知识，把它包成单一 target，比如 make test 或 npm test，失败时以非零码退出。
在 CLAUDE.md 的 Commands 段，把每条命令连同一份健康输出示例列出来。
说清目标并让它可量化，这样 Claude 不用问你就能自查，比如「test_status.py 里所有测试通过」、「截图与所附设计稿吻合」，或者「端点返回 200 且带新字段」。
修 bug 时，先写那个失败的测试。让 Claude 把 bug 复现成一个测试，跑它，确认它因你预期的原因失败。提交这个测试。然后才让 Claude 在不许改测试的前提下把它跑通，最后一步的 test-file hook 负责强制这条限制。一个在修复之前就存在、且 agent 无法重写的测试，才是 bug 已消失的证据。
UI 工作用视觉检查闭合这个环。给 Claude 一个浏览器或截图工具，给它设计稿，让它迭代。实现、截图、比对、调整。两三轮是正常的，结果应当逐轮变好。
让验证成为「完成」的一部分。指令写在 CLAUDE.md 里。报任务完成前跑测试，并把输出贴出来。
最后，这个环本身需要保护，因为修代码的 agent 不许削弱检查那段代码的手段。一个在修复任务期间阻断编辑测试文件的 hook 就是干这个的。退而求其次的做法是在评审时查 diff，凡碰测试的改动一律打回。

它长什么样（CLAUDE.md 验证块）

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

治理考量

强制执行什么： 报任务完成前的验证，以及修复期间禁止 agent 编辑测试文件。组织要求硬保证的，两者都以 hook 实现。

证据是什么： make test 的字面输出、构建日志，或者 Claude 跑过并粘贴的截图 diff——证据来自工具链本身。

记在哪里： 会话记录里，由 OpenTelemetry 导出转发到组织的可观测栈；以及 PR 的检查运行里，评审者和日后的审计师都能看到。

谁来批： 评审 PR 的代码 owner。机械性证据已经附上了，他可以专心看意图和风险。

怎么衡量

先行指标： agent 所写改动的首次 CI 通过率，CI 系统本来就支持这个指标。

滞后指标： 每个 PR 的评审耗时（取自 PR 元数据）——一旦测试接住了评审者过去接的东西，这个数应当下降；以及来自事故追踪器的变更失败率。

CI 里的持续 evals

Evals 是 AI 原生世界里对应阶段关卡 QA 的东西。具体说就是一套在 agent 配置变更时运行的套件。换了新模型或重写了 prompt，eval 套件会告诉你 agent 是否仍以同样标准干活。

Evals 应当被视为一个活的套件。模型进步，曾经有区分度的用例就不再有区分度，必须补上来自持续监控的新用例。

按用例不同，有些团队可能更喜欢离线按固定节奏跑这些 evals，而不是每次变更都跑。下面几步是针对持续 evals 的。

怎么起步

前置条件： CLAUDE.md 与反馈环（阶段 4：测试）。

基础设施： 能以非交互方式运行 Claude Code 的 CI，以及一份有 evals 运行预算的 API key。

怎么执行

平台工程师从近期工作里收集 20 到 50 个真实任务，带上预期或已接受的结果。
把每个任务写成一条 eval，即 prompt 加上定义「可接受」的检查项（测试通过、lint 干净、行为未变、策略被遵守）。
套件在 CI 里非交互运行，按时调度，并在 CLAUDE.md、skills 或 hooks 有任何变更时运行——那套配置驱动着 agent，理应享受代码才有的回归测试待遇。
配置变更以结果为门槛。一个让通过率下滑的 skill 变更，要在合并前被评审。
每次生产事故都产出一条 eval，由事故归属团队撰写，并作为回归测试留在套件里。

它长什么样（.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

治理考量

Evals 给了 QA 一道跟得上 agent 产出的闸门。通过率阈值作为合并检查强制执行，运行被记录以便跨时间比较结果，拥有配置变更的团队批准它。

怎么衡量

先行指标： eval 通过率随时间的走势（套件每次运行都会报），以及一次生产事故多久变成一条永久 eval。

滞后指标： CI 里捕获的回归，对比生产里发现的回归，取自事故追踪器。

05 —— Deploy（部署）

评审双向进行，治理在 agent 行动时执行。agent 做到生产闸门为止，绝不越过它。

PR 评审环里的 AI

Claude 既给评审也接评审。它按组织策略评审进来的 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 Play 会讲这些部署选项）。要求代码 owner 批准的分支保护策略也值得配上。

怎么执行

托管 Code Review 服务起步最快。管理员启用它并勾选仓库。需要掌控流水线、或希望 API 调用走自己的云协议时，用 claude-code-action 在你自己的 CI 里跑评审（CI/CD Play 讲这套管道）。
技术负责人把评审策略写成仓库根目录的 REVIEW.md，按组织关心的轮次分段：bug 与逻辑错误；安全与漏洞；对照规格（需求 Play 的 spec.md）、实现计划（plan mode Play 的 plan.md）和设计原则的合规性。REVIEW.md 还要定义什么算 Important、什么算 Nit，以及什么该跳过。
技术负责人设定人的阈值。发现项本身不批准也不阻断 PR，分支保护仍要求代码 owner 批准。想按发现项卡合并的平台工程师，可以读检查运行以机器可读计数发布的严重度统计。
评审者或作者在评审评论里 @ 了 @claude 时，Claude 处理这条意见并推送修复。PR 线程把请求和改动都记下来。这个修复环通过 claude-code-action 运行。在托管服务里，评论 @claude review 则是请求一次全新评审。对 Claude 自己开的 PR，可以走得更远——让 Claude 照看这个 PR 直到合并。有团队把这个环包成一个自定义斜杠命令：扫一遍 PR 上未解决的评审意见和失败的检查，处理掉，推送修复，直到 PR 转绿、只等代码 owner 批准。
评审发现项回流进 CLAUDE.md。某个错被评审第二次标记时，修正就在那次评审中写进 CLAUDE.md；由于评审会读 CLAUDE.md，这个错从下一个 PR 起就被接住。评审还会标记某次改动是否让 CLAUDE.md 过时了。
技术负责人每月调一次这套配置：给发现项打分让评审者进步，并在 REVIEW.md 里给 Nit 数量设上限。生成的路径，以及 CI 已经强制的东西，都排除掉。

它长什么样（REVIEW.md）

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

治理考量

职责分离得以保持，因为写代码的 agent 没有任何批准它的途径。REVIEW.md 里的评审策略施加于所有 PR，发现项、修复、评分与批准都记在 PR 历史里，所以 PR 就是审计记录。批准来自人，经分支保护做出，并以发现项为参考。

这些控制在生产规模上如何组合，参见 Anthropic 如何保护其 AI 原生 SDLC。

怎么衡量

先行指标： 首次评审时间，应当降到分钟级；以及无需人碰分支就解决的评审意见占比，数据直接存在 Git 上。

滞后指标： 合并前捕获的缺陷与漏洞，对比逃逸到生产的，取自 PR 历史与事故追踪器。

Hooks 作为审批闸门

构建阶段把 hooks 当护栏用——放行或阻断动作，不涉及人（阶段 3：构建）。hook 也可以提问，把动作暂停下来等特定的人批准，这正是发布门控需要的。

这个 Play 放在阶段 5：部署，是因为发布闸门是最清楚的用例，但 hooks 并非部署专属——Claude 在哪儿行动，它们就在哪儿运行。举例说，hooks 可以在阶段 3：构建 里阻断无变更工单情况下对迁移与基础设施的编辑，也可以在阶段 4：测试 里拦住 agent 在修复任务中编辑测试文件。

怎么起步

前置条件： 无。

基础设施： 一份成文的清单，列明变更流程要求哪些审批。

怎么执行

工程领导层会同变更管理与合规，列出必须保留的人工审批闸门，比如变更管理签核、发布授权、以及对受保护路径的编辑。
平台工程师把每道闸门表达为一个 hook，即在 Claude 行动前运行、能放行、提问或阻断的脚本。
团队级 hooks 放在 git 里的 .claude/settings.json，不可商量的 hooks 放进由平台或 IT 管理员持有的托管设置，个体工程师无法关掉它们。
一次阻断应当自我说明，所以 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
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
if [ -z "$RELEASE_APPROVAL" ]; then
echo "Production deploys need a release authorization." >&2
exit 2 # exit 2 blocks the action; the message goes to Claude
fi
fi
exit 0

治理考量

Hooks 就是审批闸门。闸门条件每次都执行，对每个人都执行。放行与阻断决策连同时间戳被记录。闸门还定义了什么算批准——是一张已批的变更工单，还是发布经理的签字。

实操案例 —— 受监管企业的托管设置

由平台团队经 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 意味着本 Play 的审批闸门是唯一会跑的 hooks，本地任何东西都无法增补或替换它们。
disableSideloadFlags 和 strictKnownMarketplaces 意味着工程师机器上的每一个 skill、agent、hook 和 MCP server，都经组织批准的插件市场进来，绝不会从某个主目录里来。
allowManagedMcpServersOnly 让 agent 的工具面成为平台团队持有的一份白名单。
requiredMinimumVersion 在低于批准底线的版本上拒绝启动，所以这些控制是由组织真正评估过的构建来强制的。

以上当作裁剪的起点，而不是照抄的推荐。每一条拒绝都在拿能力做交换，合适的平衡点取决于仓库的数据分级。settings 参考文档列出了每一个键，包括那些「仅托管」的：code.claude.com/docs/en/settings

怎么衡量（hooks 本身）

先行指标： 每道审批闸门上等待的时间。每次 hook 决策都连时间戳和放行或阻断判定写进 OpenTelemetry 导出，所以每道闸门的等待都是可见的。

滞后指标： 上线 hooks 前后，逃逸到生产的闸门违规，取自事故追踪器。

CI/CD 集成与部署

把 Claude Code 以非交互方式跑在 CI/CD 流水线里，给执行加沙箱好让长跑 agent 安全运行，通过 MCP 集成把部署暴露出来，并在 agent 需要回滚路径之前先演练它们。

传统做法： 流水线跑确定性脚本，凡是需要判断的都等人。比如给 flaky 测试分诊、写 changelog，或者弄清楚构建为什么挂了。部署与回滚是人照着 runbook 在压力下执行的动作。

AI 原生做法： Claude 以非交互方式在流水线里跑那些需要判断的步骤，跑在带作用域凭据的沙箱里。部署工具经 MCP 暴露给 agent，所以那套写下并测试了改动的工作流，也能在组织按环境定义的闸门内把它发布和回滚。

怎么起步

前置条件： PR 评审环里的 Claude，以及作为审批闸门的 hooks——闸门必须先存在，自动化才能加速任何东西穿过去。

基础设施： 装了 claude-code-action 的 CI 平台，或任何能调 claude -p 的 runner；经 API 的模型访问，或流量必须留在组织云协议内时的 Bedrock、Foundry、Vertex；面向部署目标的 MCP servers；一份给 agent 作业的沙箱配置，不带任何常驻生产凭据。

怎么执行

平台工程师先从只读的判断类步骤入手。在流水线作业里用 claude -p 给失败的构建分诊、总结 flaky 测试，或者起草 changelog。
在既有闸门之后加写入步骤，比如修 lint、更新生成的文档，或者经 @claude 提及处理评审意见。agent 写的一切都以 PR 形式经分支保护进来，agent 没有推送到 main 的路径。
执行加沙箱。agent 作业跑在网络策略下的容器里，持短期作用域令牌，默认不持有任何生产凭据。
通过 MCP 暴露部署。部署、状态、回滚都变成工具，按环境限定作用域，这样 agent 的部署权限是一份白名单，而不是一个揣着凭据的 shell 脚本。
按环境给自主度分级。开发环境里 agent 自由部署。生产环境里 agent 准备发布，由发布经理授权，且有一道 hook 强制生产闸门。预发环境夹在两者之间。
回滚应当是流水线里演练最多的路径——一条 agent 能跑、且在预发环境里被定期验证的命令。闭合环路 Play（阶段 6：运维）会在控制带被突破时调用这个回滚，所以它必须提前被证明可用。

它长什么样（流水线步骤）

- 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

治理考量

治理原则是：agent 可以一直做到生产闸门，但不能越过它。下面的控制强制执行这一原则。

分支保护把 agent 写的一切变成 PR，没有直达 main 的路径。
生产部署 hook 阻断发布，直到指名的发布经理授权。每次非交互运行都以 agent 自己的身份行动，所以流水线日志能把 agent 做的事与触发它的工程师做的事分开。
按环境的权限分级，设定 agent 在通往闸门的路上最多能做什么。

怎么衡量

先行指标： 无需呼叫人工就完成分诊的流水线失败占比，取自 CI/CD 流水线日志。

滞后指标： DORA（DevOps Research and Assessment）指标，CI 系统与部署工具本来就在产出这些数据。

06 —— Maintain（运维）

环路闭合。一个触发器在没有人在调用路径上的情况下唤起 Claude，它的发现以 intent.md 重新进入流水线。

维护与闭合环路

至此我们讨论的都是如何把 Claude 加进 SDLC 每个阶段，且每个阶段都要有人来启动最初几步。而这一阶段转向让 Claude 自主运行、闭合环路。

举例说，一个持续运行的监控 agent 可以在一张 bug 工单被提出之后，创建一份 intent.md，然后流过需求、计划、构建、测试和评审各阶段。阶段 6：运维 以 headless 方式运行，阶段之间有一道独立的置信闸门——一个确定性检查或一个对抗性评审 agent——决定上一阶段的产出是往下走，还是升级给人。

传统做法： 维护是个被动阶段。所有工单或事故都等着人来动手、重启流程。告警凌晨三点响，可能被漏掉；工单可能在待办里躺到有人捡起它；事后复盘的动作如果先起了另一场火，可能根本没落到代码库里。

AI 原生做法： 一个触发器——控制带被突破、一张工单、一条频道消息，或者一次调度——在没有人在路径上的情况下唤起 Claude。Claude 诊断，只经门控路由行动，把发现写成 intent.md，然后走上面描述的各阶段。人分诊和评审这些工作，不再需要启动它。

闭合环路

一个确定性脚本盯着生产，在控制带被突破时唤起 Claude。突破监控是环路自主运行的一个好例子，而阶段末尾的 Claude Tag（公开 beta）一节讲经不同渠道进来的工作。

怎么起步

前置条件： intent.md，它给环路一个结构化的输出来重启。Claude 加速的 PR 评审、作为动作边界的 hooks，以及一条给 CI/CD 的回滚路径（最高自主度那一层会调用它）。

基础设施： 检测脚本能查的指标存储（Prometheus、CI 系统的 API 或等价物）、仓库的读访问权、在 CI 里非交互运行 Claude Code 的方式，或者给一个接收 webhook 的服务配 Agent SDK。

怎么执行

服务负责人或平台工程师挑一个滚动基线稳定的指标，比如 CI 测试失败率、部署后 5xx 率，或者 PR 周期时间。
他们写检测脚本，典型做法是滚动窗口上的均值与标准差，配上规则（Western Electric 或类似方法），好让控制带既抓得住尖峰也抓得住缓慢漂移。脚本版本化并做单元测试，检测全程保持确定性，不牵涉任何模型。
响应分层定义在版本化配置里（下面的 bands.yaml）。1σ 时脚本只记录；2σ 时唤起 Claude 以只读方式诊断；3σ 时 Claude 可以行动，但只能通过开 PR 进入评审闸门，或触发一个预先批准的 runbook。
触发层可以是 GitHub 或 GitLab 里的调度工作流、既有监控栈的 webhook，或者网络内的一个 Cron Job。Claude 以无状态方式运行，要么是 CI runner 上的一个非交互步骤，要么是沙箱容器里的一个 Agent SDK 服务，CI/CD Play 会讲部署与模型访问的选项。因为这次运行是无状态且非交互的，一个环路可以在没人启动它的情况下开始和结束。
agent 把诊断写成阶段 1：规划 格式的 intent.md，涵盖异常及其证据、预期结果、受影响的系统，以及任何待决问题。从那儿起，这个发现就像别的东西一样过流水线。
服务负责人或 on-call 工程师分诊队列，把面向产品的发现转给产品负责人。立刻修、排期，还是忽略。忽略的处置会调校控制带，帮助降噪。
修复上线时，为这次事故加一条 eval（持续 evals Play），确保这类问题从此被防住。

它长什么样（例：一个监控 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 可触发的 runbook 事先已获批准。

怎么衡量

先行指标： 从控制带被突破，到分诊队列里出现一份 intent.md 的耗时，对照旧口径下「从事故到复盘动作」的时间。检测脚本的日志里有突破时间戳和事故层级。

滞后指标： 变成已合并修复的发现占比（分诊队列对照实际 PR 历史），以及同类事故的重现率——随着修复不断给 eval 套件补用例，这个数应当下降。

例子

CI 测试失败率突破 3σ 时，agent 隔离那条 flaky 测试或开一个 revert PR，由评审闸门定夺。
部署后 5xx 率突破 3σ、且窗口内有部署时，agent 触发既有的回滚流水线。
PR 周期时间触发漂移规则时，agent 给工程领导层写一份报告——这说明这套机制对流程指标同样有效，不只对生产指标。

检测保持确定性。控制带一被突破就唤起 Claude，而层级设定它能做什么。

定期代码库扫描

一次安全扫描，是对「某个特定模型之下的某份代码库」的一个时点陈述，而两半都会过期：代码每周都在变，每一代模型都能找出上一代漏掉的漏洞。AI 原生的答案是按调度运行扫描，调用路径上没有人在，把发现的东西送进和其他代码库变更相同的闸门。

Claude Security 是定期扫描的托管形态。接上一个 GitHub 仓库，扫描就在 Anthropic 基础设施里的 Claude Mythos 5 上跑，每条发现在报告前经过验证，并附上置信度评级。建议的补丁在网页版 Claude Code 里评审并应用。组织拿到发现，无需接触模型本身。

传统做法： 安全扫描是一个事件——在发布或审计之前发起一次扫描。报告进追踪器，backlog 靠人手往下清，直到下一次事件。中间写的代码，由 PR 评审抓到多少算多少。

AI 原生做法： 扫描按调度对着每个已接入仓库运行，跑在当下最强的模型上，发现在任何人读到之前经过验证。每条发现的处置方式与被突破的控制带一样：一个 PR 装得下的修复走评审闸门，更大的写成 intent.md。覆盖度从最后一次运行算起，而不是从第一次。

怎么起步

前置条件： PR 评审闸门与作为审批闸门的 hooks（阶段 5：部署），好让发现像其他变更一样过评审。阶段 1：规划 的 intent.md 格式，用于一个 PR 装不下的发现。

基础设施： Claude Security 面向 Claude Enterprise 组织公开 beta。它需要在目标仓库（云托管的 github.com）上安装 Anthropic GitHub App、启用网页版 Claude Code、开启 Extra Usage 并设好支出上限、给跑扫描的人配 premium 席位，并由管理员在 claude.ai/admin-settings/claude-code 打开这个功能。扫描按消耗以 Mythos 5 费率计费，所以支出上限应当与仓库的规模和数量匹配。

怎么执行

安全负责人接入仓库，并按仓库、服务或团队把它们组织成项目，这样发现项的归属从一开始就是清楚的。
对最关键的仓库跑一次全量扫描，包括那些此前被其他工具或更早的模型扫过的。把第一次扫描当作基线。第一次扫描很可能在曾被认为干净的代码里翻出发现项。
按项目设调度。对活跃开发的服务，每周是合理的默认值；仓库很大或混杂时，把扫描范围限定到某个目录或分支。
拿着置信度评级来分诊发现项。带理由地忽略，这样这次忽略被记录下来，同一条发现不会在下一次运行时作为新发现回来。
对一个边界清楚的发现，在网页版 Claude Code 里打开建议的补丁，评审它，然后像其他变更一样送进 PR 评审闸门。提出修复的 agent 没有任何批准它的途径。
对任何比一个补丁更宽的东西——比如一处架构薄弱点，或跨服务重复出现的模式——按阶段 1 格式写成 intent.md，从 Plan 起步。
修复发布到生产后，从持续 evals Play 给套件补一条针对该漏洞类别的 eval，这样从那时起，驱动 agent 的那套配置就会针对这一类别被测试。
把发现导出为 CSV 或 Markdown，或者用 webhooks，让组织既有的追踪器与审计系统留在审计师本就期望它们所在的位置上，充当记录系统。

治理考量

扫描运行在组织的管理员控制之下——接入哪些仓库、谁持有扫描席位、支出上限，全都是集中设定的。每条发现都有验证结果和置信度评级，每次忽略都有理由，所以扫描历史就是一份审计记录：什么被发现了、什么被修了、什么被有意识地接受了。

修复经 PR 评审闸门与分支保护到达生产，而不是来自扫描本身。Claude Security 是对既有静态分析与依赖扫描的补充。确定性检查留在 CI，模型驱动的扫描覆盖那些确定性检查没被设计来发现的、依赖上下文的漏洞。

怎么衡量

先行指标： 已接入仓库中处于调度下的占比，以及从一条发现被报告到它的补丁进入 PR 评审闸门的耗时，取自扫描历史与 PR 元数据。

滞后指标： 定期扫描发现的漏洞，对比生产或外部报告发现的，取自事故追踪器；以及跑过几轮之后仓库上单次扫描发现数的走势——随着修复和 evals 累积，这个数应当下降。

Claude 待命：Claude Tag

事故也可能经别的渠道进来，比如办公沟通软件 Slack 或 Teams。事故可以长成「晚上十点事故频道里一条求急修的 Slack 消息」，而现在它能被立刻处置。Claude Tag（公开 beta，目前支持 Slack）让 Claude 以自己的身份成为那些频道的成员，这样每起新事故都有一位第一响应人，而这次响应本身也成为未来事故的环路与记忆的一部分。

对话与机构知识留在频道里，频道里任何人都能引导并处置这次响应。任何团队成员都可以实时检验假设、探索新选项、展开调查，频道历史则不断累加可审计性。经 MCP 访问，Claude 验证指标是否回到基线并在线程里确认，把事后复盘写进一份版本化的教训文件，供未来的调查读取。

事故并非 Claude Tag 接下的唯一工作。经 MCP 被 @ 到一张工单上，或者在频道里被问起，Claude 以同样方式分诊这份工作。一个边界清楚的小修复以 PR 形式经评审闸门进来，更大的则写成 intent.md 交给阶段 1：规划——到这一步，环路开始自己喂养自己。参见：Claude Tag 如何为 Anthropic 的 CI/CD 待命。

频道就是审计轨迹：请求、诊断、人工授权与修复，全都留在事故被处置的那个地方。

结语

模型与 harness 已经进化到这个程度：组织能改造的，不只是产出代码的方式，而是整个软件开发生命周期。

这场改造把人的判断保持在流程的中心，并顾及大型企业组织的治理与合规要求。

本手册汇总了我们的应用 AI 团队每天为客户执行的许多真实最佳实践，希望它对你是一份实用、可落地的资源。

环路持续运转。人的判断悬在它之上。

资源与致谢

以下文档是平台团队搭建这些控制所需的资料，大致按你的上线顺序排列。

为你的组织配置 Claude Code —— 管理员决策地图，从这里开始
设置参考与优先级，含每一个仅托管键
来自 Claude 管理控制台的服务器托管设置
权限
沙箱 —— 操作系统级的文件系统与网络隔离
Hooks —— 指南
Hooks —— 参考
Skills
插件与私有市场 —— skills 与 hooks 如何在组织范围内分发
托管 MCP —— 集中控制 agent 的工具面
企业部署概览 —— Bedrock、Vertex、Foundry
企业网络配置
监控（OpenTelemetry）
分析看板
合规 API —— 企业活动流、对话检索与删除
安全模型

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

译自 The AI-Native SDLC playbook · Louis Claxton · 2026-08-21

编译：智柴 · 2026-08-28 · 代码块、文件名与命令行原样保留未译

#AI原生SDLC #ClaudeCode #Agent工程 #智能体编排 #研发效能 #企业级Agent #智柴