Anthropic 官方 AI 原生软件工程实战手册:把六个阶段改造成一个环

如何用 AI 一个阶段一个阶段地重塑你的软件开发生命周期

这是 Anthropic 官方博客 8 月 21 日发的一篇实战手册，作者 Louis Claxton，来自他们的 Applied AI 团队。文章讲的不是怎么让 AI 写代码写得更快，而是写代码这一段快起来之后，规划、评审、发布、治理这些仍然按人速跑的环节怎么改。

本文为编译与解读，非逐句翻译。原文所有代码示例我另写了一套，场景换成一个优惠券核销服务，可以直接照着改成你自己项目里的文件。

代码不再是瓶颈

各家组织已经开始用 AI 写代码，速度在一年前无法想象。但围绕代码的那些流程，并没有以同样的速度变化。

很多工程团队仍然保持着原来那套审批节点、评审、交接和策略，它们正在拖住 Claude Code 这类 AI 智能体工具带来的生产力增长。

软件开发生命周期，也就是 SDLC，是把软件从想法送到生产环境的那套流程。大多数组织跑的都是同一套六阶段的某个版本，覆盖规划、设计、构建、测试、部署和维护。

传统做法里，每个阶段是一个离散的相位，由不同角色拥有。产品经理写需求，技术架构师把需求变成设计，工程师实现设计，QA 团队验证它，发布团队把它发出去，运维盯着线上跑的东西。

工作通过文档、工单和签字在各相位之间流动。

传统 SDLC 流程很重，为的是在每一步上保住责任归属和管控能力。但它被设计出来的那个年代，最耗时最昂贵的阶段是写代码和实现代码，今天已经不是了。

PRD、估点仪式、产品安全评审，这些东西存在的目的，是在长达数周、数月甚至数个季度的开发过程中强行让各方对齐。

传统 SDLC 还带着一批假设每一步都由人执行的控制手段。今天产出价值最多的那些组织，已经围绕 AI 现在能做的事重建了自己的流程，同时保证人始终在环内。

本文走一遍 Anthropic 的 Applied AI 团队在内部把 Claude 接进 SDLC 各阶段的若干最佳实践，这些实践来自与客户合作过程中的积累。

当代码不再是瓶颈，构建相位跑得比传统 SDLC 能容纳的还快时，有三件事同时成立。

• 瓶颈移到了构建相位左右两侧的步骤上。主要是规划、评审与测试、部署，它们仍然按人的速度运行。
• 控制手段与现实脱节，变得不可维持。代码由人写的时候，逐行手工审查是合理的；一旦智能体写掉了绝大部分代码差异，它就跟不上了。
• 治理成本上升，因为例外情况仍然要走那些每周或每月才开一次的会和委员会。

构建不再是约束，围绕它那些按人的速度运行的阶段才是。人速阶段的长度没变，构建则塌缩到了以小时计。

拿安全瓶颈举个例子。安全团队的人员规模是按人的产出量配的，AI 让代码产出成倍增加之后，要么评审队列越积越长，要么代码在没审够的情况下发出去。

受监管的组织两种结果都不能接受，所以它的安全与策略检查必须跟上 AI 的节奏。

想要真正拿到 AI 的生产力增益并且把它管住，传统 SDLC 需要经历与实现相位同等程度的改造。

什么是 AI 原生的 SDLC

AI 原生的 SDLC 是一套重新想象过的流程，它把旧的控制目标与新的强制手段结合起来。

流程不再是线性流动，而是成为一个环，AI 嵌在环上的每一个点。这套流程推动自动化的交接和后续打法的自动触发，用来处理传统 SDLC 各相位之间那种手工又笨重的交接。

传统是一条直线，绕回来一次就是一个新的发布周期。AI 原生是一个环，以小时而非周计，人在环之上发起、指挥和治理。

两端对照

下表列出的是在 Claude 支持下，传统 SDLC 与 AI 原生 SDLC 两个极端。大多数组织落在两列中间的某个位置。

右边这一列真正串起来的东西，是每个阶段最后提交的那份产物。一个阶段以往版本库写入一份产物作为结束，下一个阶段以读取它作为开始。这份产物包括 intent.md、spec.md、plan.md、代码差异与它的测试、带评审发现的 PR，以及事故记录。

前几个阶段之所以用 md 文件，是因为产品负责人和AI 能读同一个文件并各自据此行动。从构建阶段往后，产物变成代码本身和它的记录。

提交链本身就是审计轨迹。谁提出了什么，AI 产出了什么，谁批准的，全在里面。

需要判断的决定，责任仍然在人身上。在 AI 的 SDLC 世界里，变的是人的注意力跟着需要被评审的产物一起移动了位置。

每个阶段都提交一份下一阶段能读的产物。意图、规格、计划、代码差异和评审发现，合起来就是审计轨迹。

打法

打法是这份手册的主体，分组进六个非线性的阶段，也就是计划、设计、构建、测试、部署、维护，合起来覆盖完整的生命周期。

每个打法都涵盖五样东西。

• 变的是什么
• 怎么起步
• 具体的实施步骤
• 治理考量
• 怎么衡量它有没有奏效

这些步骤是模块化的，组织可以根据自己的情况，在不同时间优先改造不同的阶段。每个打法在「前提条件」里写明自己的依赖项，依赖图会进一步说明。

一个阶段以提交一份产物作为结束，这次提交启动下一个阶段。一份被接受的 intent.md触发需求与设计过程，一份被批准的 spec.md触发计划模式，一个被合并的 PR 触发流水线，生产环境上一次控制带突破写出下一份 intent.md，环就这样转下去。

起步时你手动提示每一步，终态是一个环，每份被接受的产物点燃下一道门。人的注意力集中到各道门上，评审智能体标记出来的东西，而不是每个阶段都从零开始。

打法按阶段列出，而箭头给的是采用顺序，两者不是一回事。橙色那一排没有任何箭头指入，需要什么前置都没有，可以直接开工。其它打法，指向它的那些箭头就是要先采用的东西。

依赖图上一共十二个节点。第一排可以直接开工的是捕获意图、CLAUDE.md、反馈闭环、hook、计划模式。第二排是 skill、子智能体、evals。第三排是需求与设计、PR 评审。第四排是 CI/CD。最后是把环闭上。

正文分成十五节，多出来的自动模式、构建期 hook 和 Claude Tag 依附在相邻的打法上，没有单独成为节点。

阶段 1 ：计划

想法不再等着谁来把它写成文档。意图被一次性地、用提出者自己的话捕获下来，成为一份下一阶段能直接拿去动作的、进了版本控制的产物。

捕获为 intent.md

启动软件开发过程的那份 intent.md可以从不同路径进来。某个人有了想法，一张工单被提出来，或者一次事故经由告警浮现（见阶段 6 维护）。

某个人有了想法时，他跟 Claude 头脑风暴，产出一份 markdown 格式的原型规格。在传统 SDLC 里，同一个人接下来必须说服产品团队的某位成员，跟他一起写、或者代他写这份东西。

Claude 产出的这份原型规格人能读、进版本控制、下一阶段能立刻消费。它以 intent.md的形式保存下来。

无论意图来自事件触发还是来自 AI，步骤都一样。产品负责人在它被提交之前，评审并订正 AI 写出来的 intent.md。

传统做法。一个想法要穿过待办条目、用户故事、故事点和梳理会，然后才有人能动它。每次交接所有权都转移一次，所以抵达工程团队的东西，跟提出者本来的意思已经隔了好几步。

AI 原生做法。提出者跟 Claude 头脑风暴，把结果写成 intent.md，一份用他自己的话写的原型规格。这份产物包含想要什么、为什么要、在什么约束下要。重复出现的过程编成 skill。

前提条件与基础设施

前置依赖没有。这是依赖图上可以直接开工的起点之一。

需要准备三样东西。一是让非工程师也能用上 Claude，claude.ai 或者 Cowork 都行。二是一份约定的 intent.md模板。三是一个共享的、带版本控制的意图存放处，产品负责人盯着它。

单个产品最简单的做法，是在产品仓库里开一个 intent/目录。这样产物链跟从它派生出来的代码待在一起。

只有当意图要跨很多个仓库时，单独开一个意图仓库才值得那份额外开销，而在 monorepo 里它就是一个目录。

阶段 3 的侧栏讲了这个存放处与已经持有记录的 Jira 或需求管理工具之间是什么关系。

搭这套东西是平台团队或工程团队的一次性工作。需要一个技术同事把存放处立起来，并决定谁有写入权限，因为贡献者会来自整个组织。

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

怎么做

1. 提出者用自己的话向 Claude 描述这个问题。他可以说今天做不了什么、谁受影响、更好的样子是什么、什么不在范围内。不需要任何正式措辞。
2. 一直头脑风暴到想法足够具体。Claude 会问分析师会问的那些问题，范围、用户、约束，以及成功长什么样。
3. 让 Claude 按组织的模板把结果写成 intent.md。模板可以编成一个 skill，由技术同事搭好、由负责人签字确认。它可以覆盖问题、提议的结果、受影响的用户和系统、约束和待定问题。
4. 提出者订正 Claude 理解错的地方。
5. 把 intent.md提交到那个共享存放处。作者和时间戳加入记录，产品负责人从这里接手。

它长什么样

# 意图：商家自助查询优惠券核销明细作者：李茗（商家运营）。状态：草稿。## 问题商家在后台看不到自家优惠券的核销明细，只能提工单。客服每天人工导两次表回传，单次耗时约 40 分钟。## 期望结果商家在后台按活动、门店、时间段自助查询核销记录，并能导出。## 涉及的人和系统商家运营、客服团队、商家后台、promo-service 核销库。## 约束不引入新的用户手机号明文展示。沿用现有商家登录态。核销库是主库，查询不能压到主库上。## 待定问题第三方代运营账号要不要一起放开？导出条数上不上限？

治理考量

证据就是那份被提交的 intent.md，它列出作者、时间戳和完整的修订历史，记录在意图存放处的 git 历史里。产品负责人做批准，而把这份意图送进阶段 2 的那个接受或驳回的决定，以合并或者关闭评审的形式被记下来。

怎么衡量

先行指标。从第一次对话到 intent.md被提交的时间，从意图存放处的 git 历史读取，那里有作者和时间戳。预期是从数周的需求获取与梳理周期降到数小时。

滞后指标。通过率，也就是产品负责人接受进入阶段 2、而非关闭掉的 intent.md占比。接受或驳回以产物合并或评审关闭的形式记录。

另外还有一个数，同一改动的第一份 spec.md提交之后，intent.md还被改了多少次。

阶段 2：设计

需求与设计塌缩进同一次会话。策略在规格被写出来的当下被应用，而不是几周后在一场评审会上才被发现。

需求与设计

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

产品负责人评审这份规格，但不写它。这个过程的目标是产出一份工程团队能据以做计划的规格，并且把需要警惕的地方标出来。

前端工作是最清楚的例子。intent.md一旦被接受，产品负责人用 Claude Design（beta）直接从 intent.md出稿，在里面迭代视觉，然后导给 Claude Code 去实现。

传统做法。需求和设计是两个相位，由两个团队跑。分析师把想法形式化成需求，设计师再把需求解析回一份设计。这种分离是为了责任归属，代价是慢，而且有损耗。

AI 原生做法。两个相位发生在一次被提示的会话里。Claude 拿着 intent.md产出一份需求与设计规格，受组织的 skill 约束，并标出需要警惕的地方。

前提条件与基础设施

需要一份写好的 intent.md，以及写成 skill 的品牌、安全、合规和 UX 策略。

需要一位能用 Claude 的产品负责人。不需要工程技能。

怎么做

1. 产品负责人开一个会话，让组织的 skill 处于可用状态，并附上 intent.md。
2. 产品负责人的提示词指向这份 intent.md，点名约束条件，并要求标出关注点。一开始手动跑，随后把它固化成一条组织级的斜杠命令。再往后，把意图存放处里 intent.md被接受这件事设为触发器，合并时启动一个非交互式任务，带着组织的 skill 跑完这一遍，并把 spec.md以 PR 的形式提交（管道部分由阶段 5 的 CI/CD 打法覆盖）。到这一步，产品负责人的第一次介入就变成了评审。
3. 同一位产品负责人对照最初的想法评审这份规格。这份规格解决了所陈述的问题吗？intent.md里的待定问题是被回答了，还是被带到了下一环？
4. 先处理被标出来的关注点，因为这些正是过去分析师会升级上报的点。产品负责人跟各自的策略负责人一条条解决掉，工程团队才会看到这份规格。
5. 把 spec.md与 intent.md并排提交。这一对文件记录了当初要求了什么、最后决定了什么。
6. 产品负责人决定这份规格与意图是否推进到构建，凡是组织判定为较高风险的，咨询技术负责人。这个决定始终由人类同事来下，而接受这份规格就是阶段 3 计划模式打法的起点。

它长什么样（提示词）

读取附件里的 intent.md，为它在我们现有代码库中的落地产出一份需求与设计规格。应用你可用的全部 skill，使方案符合我们的品牌规范、安全策略和 UX 标准。把规格完整写成 spec.md，达到可以直接交给工程团队的程度。清楚地写出所有需要警惕的地方，尤其是你无法同时满足两条互相冲突的策略的地方。

治理考量

现行策略在规格被写出来的同时就被读取并应用，而不是几周后在评审里被发现。组织的 skill 作为约束施加在规格上。规格本身、产生它的那条提示词、当时生效的 skill 版本，三样都进版本控制。产品负责人签字，被标出的关注点路由给具名的策略负责人。

怎么衡量

先行指标。同一改动的 intent.md提交与 spec.md提交之间的间隔，两个 git 时间戳相减，拿它跟过去「需求加设计」的周期比。

滞后指标。构建开始之后的需求返工量。数一下同一改动里，日期晚于第一次 plan.md提交的 spec.md提交有几次，git log 直接就能给出来。

阶段 3 ：构建

没有被接受的计划，就不实现任何东西。组织知识变成智能体会读的文件，护栏以代码的形式运行，而不是靠习惯。

计划模式作为默认起点

工程师以计划模式启动 Claude Code 会话，把阶段 2 批准的 spec.md给它，让它反过来问自己，一轮轮迭代到工程师满意为止。

传统做法。工程师读完设计就开始写代码。这个改动具体怎么做，改哪些文件、写哪些测试，留在工程师脑子里，好一点的写在工单评论里。别人没法评审。评审者看到的第一样东西是完成的代码差异，到那时候返工已经很慢了。

AI 原生做法。工作从一份写下来的计划开始，由 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提交。这份计划加入审计轨迹，阶段 5 的 PR 评审打法会拿最终的代码差异跟它核对。
6. 接受计划，让 Claude 去实现。有一份扎实的计划，实现常常一遍就过。
7. 实现过程偏离计划时，在同一次提交里更新 plan.md。可以考虑用一个 hook 来强制两者同步。

它长什么样（plan.md）

# 计划：商家自助查询核销明细（来自 intent.md 2026-07-08）## 会改动的文件merchant-portal/src/promo/RedeemQuery.tsx（新增）promo-service/internal/api/redeem_query.gopromo-service/internal/api/redeem_query_test.gopromo-service/migrations/0142_redeem_query_index.sql## 工作顺序1. 在只读从库上加复合索引，先单独上线并观察一天。2. 加查询接口，走现有商家登录态。3. 前端页面接接口。4. 挂到后台导航，灰度给 50 家商户。## 风险核销库是主库，查询必须走只读从库，从库有最长 3 秒延迟，页面要标出数据时间。导出走异步任务，不占接口。## 验证方式redeem_query_test.go 覆盖四种核销状态和跨月边界。灰度商户后台截图与设计稿一致。

治理考量

设计评审发生在任何代码被生成之前，此时改主意还只是改一份文档的成本。计划模式自身就在强制这件事，因为在工程师接受计划之前，Claude 不能编辑文件。

计划和它的修订记录，连同是谁接受的，都被记下来。常规改动由工程师批准，组织判定为较高风险的走技术负责人或架构师。

怎么衡量

先行指标。第一次实现就能合入的改动占比，以及从计划批准到 PR 合入的时长，所需数据在 PR 元信息里。

滞后指标。每个改动的返工轮数，同样从 PR 元信息取，以及合入的代码差异与提交的 plan.md还对得上的比例。

自动模式

Claude Code 也可以跑在自动模式下。工程师批准计划，在满意并迭代过之后，Claude 逐项应用改动，不再逐次编辑请求确认。

随着后面几个打法的护栏成熟起来，也就是一份调好的 CLAUDE.md、把策略编进去的 skill、能拦住危险动作的 hook，以及一套 Claude 自己能跑的测试，自动接受会成为常规工作的默认选项。

够不够格用它，看三件事，规格是否收紧、影响半径是否小、这块代码测试是否已经覆盖。

用户不再盯着智能体逐条编辑、逐个动作地审核，而是在较长的自主会话结束之后评审产物。

自动接受模式配合 worktree 使用时，进一步释放个人和团队层面的并行能力，它也是让 SDLC 自主运行、按阶段 6 描述的方式实现闭环的基础。

侧栏 遗留系统与唯一可信源

适用于这套流程产出的每一份产物。

现有的 SDLC 流程多半已经在跟踪这些产物了，只是没放在 markdown 里。工作项在 Jira，需求在某个自带合规追溯能力的工具里，设计在 Figma，变更审批在变更委员会那边。

这些系统很难被顶掉，因为审计和监管已经认它们，别的团队也依赖它们。转型时的做法是，给流程产出的每一份产物指定一个系统作为唯一可信源，其余地方只放副本或链接。

下面三种配置都能做到只有一个可信源，具体选哪个可以逐产物不同。

仓库作为可信源。markdown 产物是权威记录，遗留系统引用提交里的文件。工程主导的组织用这个配置最干净，所有记录在一个工具里，只有一套时间戳权威。

遗留系统作为可信源。Jira、ServiceNow 或需求管理工具持有权威记录，markdown 产物是工作副本。Claude 在会话开始时读取记录，并在产出规格或计划的同一次会话里，通过 MCP 连接器把结果写回去。

双向链接作为最低标准。所有产物都记下记录 ID，所有遗留记录都带上对应 markdown 文件的 commit SHA。转型初期从这里起步是合理的，代价是承认存在两个可信源。

两套体系可以共存，条件是要么之间有链接，要么明确宣布其中一个为准。

CLAUDE.md

CLAUDE.md给 Claude 的是一个新同事需要知道的东西，包括约定、命令、架构，以及这个团队最常踩的坑。

过去长在人脑子里和 wiki 上的知识，变成 AI 智能体每次会话开始就读的一个文件，由全团队维护，每犯一次错就迭代一次。

前提条件与基础设施

前置依赖没有。需要一个仓库、装好的 Claude Code，以及一个熟悉这套代码的工程师。

怎么做

1. 在仓库里运行 /init。Claude 根据它找到的东西生成一份起步用的 CLAUDE.md。
2. 把生成的文件砍到只剩一个新同事第一天需要的内容。留下构建、测试和检查的命令，真正要紧的约定，以及 Claude 老是搞错的那些事。
3. 把 CLAUDE.md提交到仓库根目录的 git 里，全团队共享一个版本，对它的改动像代码一样被评审。
4. 定一条工作规则。Claude 同一个错误犯到第二次时，把修正写进 CLAUDE.md。
5. 控制在一页以内。Claude 在会话开始时读它的全部内容，任何过时的东西都在白占上下文。

它长什么样（CLAUDE.md）

# promo-service 优惠券服务## 命令 - 构建：make build     - 测试：make test（单测）、make itest（集成测试，需要 docker）- 检查：make lint（CI 里会跑，推之前先修干净）  - 本地起服务：make run（依赖 docker-compose 起的 pg 和 redis）## 约定- Go 1.22，不引新的 ORM，SQL 手写在 internal/store 下。  - 金额一律用 int64 存分，禁止 float。  - 优惠券状态变更必须走 state machine，不允许直接 UPDATE status。- 每个对外接口都要有 internal/api 下的表驱动测试。## 架构- api/ 放 HTTP handler，domain/ 放核销与风控逻辑，  store/ 访问 pg，client/ 访问外部服务。- 核销主库只接写，所有查询走 read replica，连接串是 DB_RO_DSN。- migrations/ 由平台团队的工具执行，不要在代码里建表。## Claude 常犯的错- 不要升级 go.mod 里的依赖版本，平台团队统一管。- legacy/v1 包已冻结，改动一律写在 v2。- 查询代码不要用 DB_DSN，那是主库。

治理考量

CLAUDE.md进版本控制，所以智能体据以工作的指令是可评审、可审计的。团队约定通过这个文件生效，对它的改动记在 git 历史里，由 code owner 在 PR 评审中批准。

怎么衡量

先行指标。Claude 重复犯本该被 CLAUDE.md拦住的错误的频率。对 CLAUDE.md的修正动作在 git 历史里追踪。

滞后指标。新成员第一次合入 PR 需要的时间，从 PR 历史取。

skill 作为组织知识

skill 是组织把自己的知识变成可执行形态的方式。指令是显式的、进版本控制的、广泛生效的，策略变了就在中心改一次。

判断标准是这样，必须被一致执行的组织知识写成 skill，属于 CLAUDE.md或者一次性提示词的东西不要写成 skill。

前提条件与基础设施

没有强制的前置。有 CLAUDE.md会更顺，因为它把智能体的工作知识留在仓库里，但 skill 并不依赖它。

需要一条有具名负责人、有书面可信源的策略。

怎么做

1. 挑一条今天执行得最不一致的知识。可以是一条安全标准、一个 API 设计约定，或者一条品牌规则。
2. 把它写成 skill，也就是一个包含 SKILL.md的文件夹，frontmatter 说明什么时候触发，正文说明要做什么。由工程师依据策略负责人的可信源来写，可以让 Claude 帮忙。
3. 放进仓库的 .claude/skills/<名字>/，让它跟代码一起分发；或者做成 plugin，在组织范围内下发。
4. 测触发。用不同说法让 Claude 做相关任务，确认每次都能加载上。
5. 策略变了就改 skill，改完由策略负责人签字。
6. 工程师在下一次会话里自动拿到新版本。

它长什么样（.claude/skills/db-migration-review/SKILL.md）

---  name: db-migration-reviewdescription: 应用数据库变更规范。凡是新增或修改 migrations/ 下的  SQL 文件、评审含建表或改表的 PR、或者被要求设计表结构时使用。  ---# 数据库变更规范新增或修改 migration 时按以下规则执行。1. 单文件单变更。一个 migration 文件只做一件事，   建表、加列、加索引不要混在一起。2. 加列必须可空或带默认值，禁止一次性 NOT NULL 无默认。      3. 索引一律用 CREATE INDEX CONCURRENTLY，   并在文件头注释里写明预估耗时和影响的表大小。4. 禁止 DROP COLUMN 和 DROP TABLE。字段下线走两步，   先在代码里停止读写，一个发布周期之后再由平台团队人工执行。5. 每个 migration 都要有对应的回滚文件，命名为 <序号>_down.sql，   且必须在本地实际跑通过一次。写完运行 scripts/check-migration.sh，把它的输出放进你的总结里。

治理考量

skill 是一种控制，但它是建议性的。它让 Claude 在写代码时很可能应用这条策略，没有任何机制强制某一次会话必须遵守。

必须无例外成立的策略，背后需要一个确定性的东西兜底，比如一个直接拦住动作的 hook，或者一次在 PR 上重新核验该策略的评审。

skill 让违规变得罕见，hook 让违规几乎不可能。skill 的调用记录在会话轨迹里，策略负责人像评审代码那样评审 skill 的改动。

怎么衡量

先行指标。从策略负责人批准变更，到对应 skill 合入之间的时间，从 skill 目录的 PR 上取。

滞后指标。PR 评审中援引该策略的发现数量，skill 生效之后它应当趋近于零。如果它没有降下来，要么 skill 没被触发，要么它的正文已经跟官方策略跑偏了。

hook 作为构建期护栏

skill 是建议性控制，hook 是它背后那层确定性的东西。Claude 在实现过程中的动作大部分是文件编辑和 shell 命令，所以构建相位往往是 hook 触发最密集的地方。

构建期的 hook 可以做这些事。

• 拦住对受保护路径的编辑，比如生成的代码、已冻结的包。
• 在文件编辑之后跑格式化和 lint，让偏差不会累积。
• 让凭据不会进入代码差异。

任何一条必须无例外成立的策略，它对应的 skill 后面都该配一个 hook 兜底。

hook 在每个匹配到的动作上都会跑一次，所以构建期的 hook 要快，作用范围要收窄到发生变更的那个文件。跑全量测试这种重活属于提交或 PR 环节。

要求人来批准的 hook 属于阶段 5 的门禁，因为构建过程中弹出一个审批提示，等于把一个人重新放回所有并行会话的关键路径上。

并行会话与subagent

一个工程师可以同时推进几条工作线。

并行会话是另一个完整的 Claude Code 实例，在自己的 git worktree 里做另一件任务。各个独立会话彼此一无所知，工程师是它们唯一的共享物。

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

并行会话提高一个工程师同时在手的任务数，subagent 让每个会话专注在自己那件事上。工程师的工作是操纵和评审它们全部。

传统做法。一个工程师一次做一件任务，一天或一周里有相当大一部分时间花在等构建、等测试、等评审者上。等的时候切去做别的当然可以，但上下文切换累到很少有人愿意。

AI 原生做法。一个工程师同时跑几个 Claude 会话，各自在自己的 worktree 上做自己的任务。重复出现的活儿变成 subagent，有自己的上下文和工具限制。工程师的工作转向编排，再往后是构建和监控这些环。

前提条件与基础设施

需要 CLAUDE.md，因为所有会话都读这个文件。阶段 4 的反馈闭环也有帮助，因为会话能自己验证工作时，需要的盯守就少。

需要一个 git 仓库，隔离来自 worktree。权限设置要调好，让会话不会卡在组织认为安全的命令的审批提示上。

怎么做

1. 工程师把工作拆成触碰不同文件的任务，用计划模式产出的计划来判断哪些工作彼此独立。共享文件的任务放在一个会话里前后执行。
2. 每个并行任务给一个自己的 worktree，比如一个终端里跑 claude --worktree feat-redeem-query，另一个跑 claude --worktree fix-export-timeout。worktree 是独立分支上的独立检出，能防止会话在文件上撞车。
3. 两三个会话是合理的起点。实际上限是一个人能认真评审几条流，只在评审跟得上的前提下增加会话数。
4. 把重复出现的活儿做成 subagent，定义为 .claude/agents/下的 markdown 文件，每个带名字、说明什么时候用它，以及它可以碰的工具。常见的有一个代码精简器，在主agent写完之后剥掉多余的复杂度；一个验证器，把应用跑起来检查行为；一个研究员，在代码库里探路然后回来汇报，不把大量内容灌进主上下文。定义文件进 git，全团队共享。

它长什么样（.claude/agents/smoke-runner.md）

---name: smoke-runnerdescription: 在会话报告完成之前，把服务跑起来验证改动确实生效tools: Bash, Read---用 make run 起服务，等健康检查通过。针对本次改动的接口跑一遍正常路径，再跑最近的两个相邻场景，优惠券已核销和活动已过期这两种情况必须覆盖。报告你实际执行了什么、看到了什么，以及任何与 plan.md 不符的行为。不要修任何东西，只报告。

治理考量

会话越多产出越多，所以控制必须来自仓库里的配置。放在那里的 hook 和权限设置对所有会话生效，会话做了什么会被记录并归属到运行它的那个工程师头上。

怎么衡量

先行指标。在评审质量不下滑的前提下，每个工程师的并发会话数，从 OpenTelemetry 导出里统计；以及一天中用于操纵而非等待的时间占比。

滞后指标。每人每周合入的改动数，要和 PR 历史里的返工率并排看。

阶段 4 ：测试

QA 不再是卡在阶段边界上的一道门。检查被织进实现过程本身，会话在人看到之前先自己验一遍，配置一变就跑回归。

给 Claude 一个反馈闭环

永远给 Claude 一条能验证自己工作的路，测试、构建或者截图比对都行。会话在工程师看到之前，先检查自己的活儿并修掉自己的错。

这里要跟阶段 3 的验证 subagent 区分开。反馈闭环贯穿整个任务，工作有多长它就跑多少轮。验证 subagent 是把最终那次检查打包起来的一种方式，在会话认为工作已经完成时开一个全新的上下文窗口去跑，好让结论不被产出这段代码的那些假设带偏。

传统做法。代码能不能跑，这个信号来得很晚。CI 是几分钟之后，测试同学是几天之后，生产环境是几周之后。当代码由 AI 产出时，晚到的信号意味着必须由人去检查它的全部输出，而这个人就成了瓶颈。

AI 原生做法。会话被给到一条在人看见之前先自查的路。跑测试、跑构建、截图。Claude 一直迭代到检查通过，所以到工程师手上的东西已经过了这一关。把这个闭环搭起来是运行会话的那位工程师的事，下面的步骤是写给他的。

前提条件与基础设施

前置依赖没有。

需要一套测试和一次构建，各自能用一条命令在本地跑起来。UI 工作还需要让 Claude 能看到结果的手段，浏览器工具或者通过 MCP 接进来的截图工具。

怎么做

1. 如果今天验证工作需要敲一串命令外加一些环境知识，把它包成单个目标，比如 make test或 npm test，失败时以非零码退出。
2. 在 CLAUDE.md的命令一节里列出每条命令，并给一个正常输出的样子。
3. 给一个目标，并且让它可量化，这样 Claude 不用问你就能自己判断。比如「redeem_query_test.go 全部通过」「截图与附上的设计稿一致」「接口返回 200 且带上新字段」。
4. 修 bug 时先写失败的测试。让 Claude 把 bug 复现成一个测试，跑一遍，确认它失败的原因跟你预期的一致，把这个测试提交上去。然后才让 Claude 在不修改测试的前提下让它通过，这条限制由最后一步的 hook 强制。一个在修复之前就存在、且 AI 改不动的测试，是这个 bug 确实没了的证据。
5. UI 工作用视觉检查闭环。给 Claude 浏览器或截图工具，给它设计稿，让它自己迭代。实现、截图、比对、调整。两三轮是正常的，每轮结果都该更好一点。
6. 把验证写进「完成」的定义里。指令放在 CLAUDE.md里，报告任务完成之前跑测试并贴出输出。
7. 最后，闭环本身需要保护，因为一个在修代码的智能体不能有能力削弱针对这段代码的检查。一个在修复任务期间拦住测试文件编辑的 hook 能做到这件事。替代方案是在评审时检查代码差异，凡是动了测试的一律打回。

它长什么样（CLAUDE.md 的验证段落）

## 验证你的工作- 构建：make build（必须以 ”Build succeeded” 结束）- 测试：make test（全绿；永远不要跳过或删掉一个失败的测试）- 检查：make lint（零警告）报告任何任务完成之前，三条全跑一遍，并把输出贴出来。测试失败时，修代码，不要修测试。

治理考量

强制的是什么。任务被报告完成之前必须验证，以及修复任务期间禁止 Claude 编辑测试文件。组织需要保证时，两条都实现为 hook。

证据是什么。Claude 实际跑出并贴上来的 make test输出、构建日志或截图比对。证据来自工具链本身。

记在哪里。记在会话轨迹里，由 OpenTelemetry 导出转发到组织的可观测性栈；同时记在 PR 的 check run 里，评审者和后来的审计都能看到。

谁批准。评审这个 PR 的 code owner。机械性的证据已经附上了，他可以把注意力集中在意图和风险上。

怎么衡量

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

滞后指标。每个 PR 的评审耗时，从 PR 元信息取，测试接管了过去靠评审者去抓的东西之后它应当下降；以及变更失败率，从事故跟踪系统取。

CI 里的持续 evals

evals 是阶段门禁式 QA 在 AI 原生时代的对应物。具体说，是一套在 AI 的配置发生变化时就运行的用例。

换了新模型，或者重写了提示词，eval 套件回答的是这个 AI 还能不能把活儿干到同样的水准。

evals 要当成一套活的套件来看。模型在进步，曾经有区分度的用例会失去区分度，需要从持续监控里长出新的用例补进来。

依用例不同，有些团队会更愿意按固定节奏离线跑，而不是每次改动都跑。下面写的是持续评估这一种。

前提条件与基础设施

需要 CLAUDE.md和反馈闭环。

需要能非交互式运行 Claude Code 的 CI，以及一把有预算跑 eval 的 API key。

怎么做

1. 平台工程师从近期工作里收集 20 到 50 个真实任务，连同它们的预期或已被接受的结果。
2. 把每个任务写成一条 eval，也就是提示词加上定义「可接受」的那些检查，比如测试通过、lint 干净、行为未变、策略被遵守。
3. 套件在 CI 里非交互式运行，按计划任务跑，同时在 CLAUDE.md、skill 或 hook 发生任何改动时跑。这些配置在操纵 AI 智能体，理应享有代码那样的回归测试。
4. 用结果给配置变更设门禁。一次让通过率下降的 skill 改动，合入之前要先被评审。
5. 每一次生产事故都产出一条 eval，由承担这次事故的团队来写，留在套件里当回归测试。

它长什么样（.github/workflows/agent-evals.yml）

name: Agent evalson:pull_request:paths:['CLAUDE.md','.claude/**']schedule:-cron:'0 18 * * *'jobs:evals:runs-on: ubuntu-lateststeps:-uses: actions/checkout@v4-run: npm install -g @anthropic-ai/claude-code-name: 跑 eval 套件env:ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}run:|          for e in evals/*.json; do            claude -p "$(jq -r '.prompt' "$e")" \              --allowedTools "Read,Edit,Bash(make test)" \              --output-format json > result.json            ./evals/check.sh "$e" result.json          done

治理考量

evals 给了 QA 一道跟得上 AI 产出速度的门。通过率阈值作为合并检查强制执行，每次运行都留档以便跨时间比较，配置变更由拥有它的团队批准。

怎么衡量

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

滞后指标。CI 里抓到的回归数，对比在生产环境被发现的回归数，后者从事故跟踪系统取。

阶段 5 ：部署

评审在两个方向上运行，治理在 AI 动作发生的当下被强制执行。AI 可以做到生产门禁之前的一切，越过它一步都不行。

Claude 进入 PR 评审回路

Claude 既做评审也接受评审。它按组织策略评审进来的 PR，也处理别人给它自己的 PR 提的评审意见。这让工程师在评审时把注意力放在行为上，落到实处就是判断意图和风险两件事。

传统做法。评审容量是按人的产出量规划的。一个 PR 等着某个评审者把它全部读完，评审质量随评审者的负载浮动，作者一边催一边看积压变长。

AI 原生做法。所有 PR 都过同一套评审，发现按严重程度排序。人的注意力上移一层，判断这个改动做的是不是计划本来要做的事，以及这个风险能不能接受。

前提条件与基础设施

需要阶段 3 更新过的 CLAUDE.md。评审要强制成文策略时还需要 skill，以及定义好的 subagent。

需要一个装了 Claude 集成的仓库，可以是管理员启用的托管 Code Review 服务，也可以是跑在自家 CI 里的 claude-code-action。

需要时模型调用走 AWS Bedrock、Google Vertex 或 Microsoft Foundry（部署选项由 CI/CD 覆盖）。同时值得配上要求 code owner 批准的分支保护策略。

怎么做

1. 托管的 Code Review 服务上手最快，管理员启用并选好仓库即可。需要掌控流水线，或者希望 API 调用走自家云协议时，用 claude-code-action 在自己的 CI 里跑评审。
2. 技术负责人把评审策略写成仓库根目录的 REVIEW.md，按组织在意的几遍分开，包括缺陷与逻辑错误、安全与漏洞、与规格（阶段 2 的 spec.md）和实现计划（阶段 3 的 plan.md）以及设计原则的一致性。REVIEW.md同时定义什么算重要、什么只是吹毛求疵，以及哪些东西不用报。
3. 技术负责人设定人工阈值。评审发现本身不批准也不阻塞 PR，分支保护仍然要求 code owner 批准。想按发现数卡合并的平台工程师，可以读 check run 发布的机器可读的严重度计数。
4. 评审者或作者在评论里 @claude时，Claude 处理该意见并推送修复，PR 线程同时留下请求和改动。这个修复回路走 claude-code-action。在托管服务里，评论 @claude review触发的是重新评审。对于 Claude 自己开的 PR，可以走得更远，让它一路把 PR 带到可合并状态。有的团队把这个回路包成一个自定义斜杠命令，扫掉 PR 上未解决的评审意见和失败的检查，处理完推上去，直到 PR 全绿、只等 code owner 批准。
5. 评审发现回流到 CLAUDE.md。同一个错误被评审标记第二次时，修正作为这次评审的一部分写进 CLAUDE.md，而因为评审本身会读 CLAUDE.md，从下一个 PR 起这个错误就被拦住了。评审也会指出某个改动已经让 CLAUDE.md过时。
6. 每月一次，技术负责人给发现打分来调优评审者，并在 REVIEW.md里给吹毛求疵类的发现设上限。生成的路径和 CI 已经强制的东西排除掉。

它长什么样（REVIEW.md）

# 评审说明## 分几遍看跑三遍，每条发现标上它属于哪一遍。- 缺陷：逻辑错误、边界情况没处理、隐蔽的回归- 安全：注入风险、鉴权缺口、日志里出现手机号或身份证号- 一致性：改动与 spec.md、plan.md 和我们的设计原则是否吻合## 这里的「重要」指什么「重要」只留给会破坏行为、泄露数据或违反策略的发现。命名和风格属于吹毛求疵。## 吹毛求疵限量每次评审最多报五条，其余的汇总成一个数字。## 不用报的internal/gen/ 下的生成代码，以及 CI 已经强制的任何东西。

治理考量

职责分离被保住了，因为写这段代码的 AI 没有任何途径批准它。REVIEW.md里的评审策略作用于所有 PR，发现、修复、打分和批准全都记在 PR 历史里，PR 本身就是审计记录。批准来自人，通过分支保护给出，由评审发现为他提供依据。

怎么衡量

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

滞后指标。合并前抓到的缺陷与漏洞数，对比逃逸到生产环境的那些，前者从 PR 历史取，后者从事故跟踪系统取。

hook 作为审批门禁

构建相位把 hook 用作护栏，允许或拦住动作，没有人参与。hook 还可以问，也就是把动作挂起，直到某个特定的人批准，这正是发布门禁需要的东西。

这个打法放在阶段 5，因为发布门是最清楚的例子。

hook 本身并不专属于部署，Claude 在哪里动作它就在哪里生效。比如在阶段 3 拦住没有变更单就编辑迁移脚本和基础设施的行为，或者在阶段 4 阻止 AI 在修复任务里改测试文件。

前提条件与基础设施

前置依赖没有。

需要一份写下来的清单，列明变更流程要求哪些审批。

怎么做

1. 工程负责人会同变更管理和合规，列出必须存活下来的人工审批门，比如变更管理签字、发布授权、受保护路径的编辑。
2. 平台工程师把每个门表达成一个 hook，一段在 Claude 动作之前运行的脚本，可以放行、询问或者拦住。
3. 团队级的 hook 放进 git 里的 .claude/settings.json，不可协商的 hook 放进由平台或 IT 管理员掌管的 managed settings，个体工程师关不掉。
4. 拦截要能自我解释。hook 拦住一个动作时，原因和申请批准的路径要出现在 Claude 的输出里。

它长什么样（.claude/settings.json）

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

门本身（.claude/hooks/release-gate.sh）

#!/bin/bash# 生产发布必须持有具名的发布授权cmd=$(jq -r '.tool_input.command' < /dev/stdin)if [[ ”$cmd” == *”deploy”* && ”$cmd” == *”prod”* ]]; then  if [ -z ”$RELEASE_APPROVAL” ]; then    echo ”生产发布需要发布授权。请在变更单 CHG-xxxx 上取得发布经理签字，” >&2    echo ”然后以 RELEASE_APPROVAL=CHG-xxxx 重新执行。” >&2    exit 2# 退出码 2 拦住动作，stderr 的内容会回给 Claude  fifiexit 0

治理考量

hook 就是审批门。门的条件每一次、对每个人都被强制执行。放行和拦截的决定带时间戳记录下来。门同时定义了什么才算批准，可以是一张已批准的变更单，也可以是发布经理的签字。

实例：受监管企业的 managed settings

由平台团队通过 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.npmmirror.com"]},"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让密钥进不了 AI 的上下文，并挡住经由工具发起的任意网络外联。permissions.allow预先放行安全的内圈动作，免得 deny 清单退化成一连串审批提示把人拖疲。

disableBypassPermissionsMode加上 allowManagedPermissionRulesOnly，意味着没有任何工程师、项目文件或命令行参数能把规则放宽。

sandbox补上权限系统补不上的口子。在工具层面 deny 掉 WebFetch，并不能阻止一条 shell 命令自己去联网，操作系统层面的域名白名单则直接掐断外联。

failIfUnavailable和 allowUnsandboxedCommands让沙箱成为一道真正的门。沙箱起不来时 Claude Code 拒绝启动，在沙箱里失败的命令也不能拿到沙箱外重试。

credentials补上 deny 规则留下的口子。permissions.deny管的是 Claude 的文件工具，但一条沙箱内的 shell 命令默认仍然读得到 ~/.ssh或 ~/.aws/credentials。这一段把那些读取拒掉，并从每条沙箱命令的环境里剥掉指定的密钥。

allowManagedHooksOnly意味着这个打法里的审批门是唯一会运行的 hook，本地的任何东西都不能追加或替换它们。

disableSideloadFlags和 strictKnownMarketplaces意味着工程师机器上的每一个 skill、agent、hook 和 MCP server，都来自组织批准的插件市场，不会来自某个人的家目录。

allowManagedMcpServersOnly让智能体的工具面变成一份由平台团队掌管的白名单。

requiredMinimumVersion让低于批准下限的版本无法启动，控制项因此是由一个组织真正评估过的构建来强制的。

上面这份要当成起点去裁剪，不要当成建议直接抄。

每一条 deny 都在拿能力做交换，合适的平衡取决于这个仓库的数据分级。完整的键说明见 https://code.claude.com/docs/en/settings

怎么衡量（针对 hook 本身）

先行指标。每道审批门上的等待时长。每个 hook 决策都带时间戳和放行或拦截的结论写进 OpenTelemetry 导出，等待因此能按门分别看到。

滞后指标。上 hook 之前与之后，突破门禁抵达生产的违规数，从事故跟踪系统取。

CI/CD 集成与部署

在 CI/CD 流水线里非交互式地运行 Claude Code，把执行沙箱化好让长时间运行的智能体安全地跑，通过 MCP 把部署能力暴露给它，并且在 AI 真正需要用到之前先把回滚路径演练熟。

传统做法。流水线跑的是确定性脚本，任何需要判断的事都等人。比如分诊一个抖动的测试、写变更日志、或者搞清楚构建为什么挂了。部署和回滚是人在压力下照着执行的操作手册。

AI 原生做法。Claude 在流水线内部非交互式地承担需要判断的步骤，跑在沙箱里，凭据受限。部署工具通过 MCP 暴露给 AI，于是写了并测了这个改动的那套工作流，也能把它发出去和回滚回来，全程在组织按环境定义的门禁之内。

前提条件与基础设施

需要评审回路和审批门。门必须先存在，自动化才谈得上加速通过它们。

需要一个装了 claude-code-action 的 CI 平台，或者任何能调 claude -p的 runner；模型访问走 API，流量必须留在自家云协议内时走 Bedrock、Foundry 或 Vertex；部署目标对应的 MCP server；一份给 AI 任务用的沙箱配置，默认不持有任何常驻生产凭据。

怎么做

1. 平台工程师从只读的判断类步骤开始。在流水线任务里用 claude -p分诊失败的构建、总结一个抖动的测试，或者起草变更日志。
2. 把写入类步骤加在现有的门后面，比如修 lint、更新生成的文档、通过 @claude处理评审意见。AI 写的任何东西都以 PR 的形式经过分支保护抵达，AI 没有推到主干的路径。
3. 执行沙箱化。AI 任务跑在受网络策略约束的容器里，用短时效的受限 Token，默认不持有生产凭据。
4. 通过 MCP 暴露部署能力。部署、状态查询和回滚变成工具，按环境划定作用域，于是智能体的部署权力是一份白名单，而不是一个揣着凭据的 shell 脚本。
5. 按环境分级自治。开发环境 AI 自由部署。生产环境 AI 准备发布、由发布经理授权，并由一个 hook 强制这道生产门。预发处在两者之间。
6. 回滚应当是整条流水线里演练得最熟的一条路，一条 AI 能执行的命令，并且定期在预发环境实际跑。阶段 6 的闭环在控制带被突破时会调用这条回滚，所以它必须事先被证明过。

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

- name: 分诊失败的构建  if: failure()  run: >    claude -p "读取 out/build.log。指出最可能的原因，说明这次失败看起来是    抖动还是真实问题，并为 PR 线程写一段三行的总结。" >> triage.md

治理考量

主导原则一句话，AI 可以执行到生产门为止，不能越过它。下面三条控制在执行这条原则。

• 分支保护把 AI 写的任何东西变成 PR，没有直达主干的路径。
• 生产部署 hook 拦住发布，直到一位具名的发布经理授权。每次非交互式运行以 AI 自己的身份执行，所以流水线日志里，AI 做的事和触发它的工程师做的事是分开的。
• 按环境划分的权限档位，规定 AI 在抵达那道门之前可以做到什么程度。

怎么衡量

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

滞后指标。DORA 那几项，CI 系统和部署工具本来就在产出这些数据。

阶段 6 ：维护

环闭上了。一个触发器调用 Claude，调用路径上没有人参与，它找到的东西以 intent.md的形式重新进入流水线。

维护与把环闭上

到这里为止，我们讲的是怎么把 Claude 加进 SDLC 的每一个阶段，而每个阶段最初那几步仍然需要人来启动。这一阶段把重点转向让 Claude 自主运行，把环闭上。

举个例子。一个持续运行的监控智能体，在一张缺陷工单被提出之后创建一份 intent.md，随后流经需求、计划、构建、测试和评审各相位。

这一整段以无头方式运行，阶段与阶段之间有一道独立的置信门，由一个确定性检查或者一个持对抗立场的评审智能体，来决定上一阶段的产出是继续往下走还是升级给人处理。

传统做法。维护是被动的相位。所有工单和事故都等着某个人来处理并重启流程。凌晨三点的告警可能没人看见，一张工单可能在待办里躺到有人捡起为止，复盘产出的行动项也可能因为另一场火烧起来而根本进不到代码库。

AI 原生做法。一个触发器调用 Claude，路径上没有人。触发器可以是一次控制带突破、一张工单、一条频道消息或者一个定时任务。Claude 做诊断，只通过设了门的路径动作，把发现写成 intent.md，随后走前面描述的各个阶段。人做分诊和评审，不再需要负责起头。

把环闭上

一段确定性的脚本盯着生产环境，在控制带被突破时调用 Claude。监控突破是这个自主运行模式的一个便于说明的例子，工作从别的渠道进来的情况由本阶段末尾的 Claude Tag 一节覆盖。

前提条件与基础设施

需要 intent.md，它给这个环一个结构化的输出用来重启流程。另外还需要 Claude 加速过的 PR 评审、作为动作边界的 hook，以及 CI/CD 的回滚路径，最高一档自治会调用它。

需要一个检测脚本能查询的指标存储（Prometheus、CI 系统的 API 或等价物）、仓库的读权限、一条在 CI 里非交互式运行 Claude Code 的路径，或者用 Agent SDK 做一个接收 webhook 的服务。

怎么做

1. 服务负责人或平台工程师挑一个基线稳定的指标，比如 CI 测试失败率、发布后 5xx 率，或者 PR 周期时长。
2. 他们写检测脚本，通常是滚动窗口上的均值与标准差，配上一组规则（Western Electric 或类似的），让控制带既能抓住尖峰也能抓住缓慢漂移。脚本进版本控制并有单元测试，检测过程保持完全确定性，不引入任何模型。
3. 响应档位定义在版本控制的配置里，也就是下面的 bands.yaml。1σ 时脚本只记日志。2σ 时以只读方式调用 Claude 做诊断。3σ 时 Claude 才可以动作，而且只能通过开一个进入评审门的 PR，或者触发一份预先批准过的操作手册。
4. 触发层可以是 GitHub 或 GitLab 上的定时工作流、现有监控栈发出的 webhook，或者内网里的一个 Cron Job。Claude 无状态运行，可以是 CI runner 上的一个非交互步骤，也可以是沙箱容器里的一个 Agent SDK 服务，部署与模型访问选项由 CI/CD 覆盖。因为运行是无状态且非交互的，一轮循环可以在没有任何人启动它的情况下开始和结束。
5. AI 把自己的诊断按阶段 1 的格式写成 intent.md，覆盖这次异常及其证据、提议的结果、受影响的系统和待定问题。从这里开始，这条发现跟别的东西一样走完整条流水线。
6. 服务负责人或值班工程师分诊这个队列，把面向产品的发现路由给产品负责人。现在修、排期、或者驳回。驳回用来调整控制带，帮着降噪。
7. 修复上线时，给这次事故补一条 eval，确保这一类问题今后被挡住。

它长什么样（一份监控 CI 测试失败率的 bands.yaml）

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]}

治理考量

档位边界由版本控制的配置强制，权限和 managed settings 拒绝生产访问。调用、发现和分诊决定都带时间戳记录。服务负责人做分诊和批准，由此产生的改动走正常的 PR 评审门，AI 可以触发的操作手册是事先批准过的。

怎么衡量

先行指标。从控制带突破到一份 intent.md出现在分诊队列的时间，拿它跟过去从事故到复盘行动项的时间比。检测脚本的日志里有突破的时间戳和档位。

滞后指标。发现最终变成已合并修复的比例（分诊队列对照 PR 历史），以及同类事故的重复发生次数，随着修复不断给 eval 套件添用例，它应当下降。

例子

• CI 测试失败率突破 3σ 时，AI 隔离掉那个抖动的测试，或者开一个回滚 PR，由评审门来决定。
• 发布后 5xx 率突破 3σ 且窗口内有一次部署时，AI 触发现有的回滚流水线。
• PR 周期时长触发漂移规则时，AI 给工程负责人写一份报告。这说明这套框架不只对生产指标有效，对流程指标同样有效。

检测保持确定性。Claude 只在控制带被突破之后才被调用，而档位规定了它可以做什么。

Claude 值班，用 Claude Tag

事故也会从别的地方进来，比如 Slack 或 Teams 这类协作工具。晚上十点在事故频道里的一条紧急修复消息，现在可以被立刻接手。

Claude Tag（目前在 Slack 公测）让 Claude 以自己的身份成为那些频道的成员，于是每一起新事故都有一个第一响应者，而响应本身成了循环的一部分，也成了以后事故可以调取的记忆。

对话和组织知识留在频道里，频道里的任何人都能引导和推进这次响应。

任何团队成员都能实时验证假设、探索新选项、往下追查，频道历史本身增强了可审计性。

通过 MCP，Claude 验证指标回到基线并在线程里确认，把复盘写进一个进了版本控制的经验教训文件，供以后的排查读取。

事故不是 Claude Tag 唯一接的活。通过 MCP 在一张工单上被 @，或者在频道里被直接问到，Claude 用同样的方式分诊这份工作。

范围小、边界清楚的修复以 PR 的形式经过评审门抵达，更大的东西被写成 intent.md交给阶段 1，到这里，这个环开始自己喂自己。

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

结语

模型和框架都变强了，于是组织能够改造的不只是生产代码的方式，而是整条软件开发生命周期。

这场改造把人的判断留在流程中心，也顾及了大型企业的治理与监管要求。

这份指南汇总的是 Anthropic 的 Applied AI 团队每天在客户那里实际执行的诸多做法，希望它对你是一份能落地的材料。

环一直在转，人的判断在它之上。

资源与致谢

下面这些文档是平台团队搭起这些控制项需要的东西，顺序大致就是推荐的落地顺序。

• 为组织配置 Claude Code，管理员决策图，从这里开始 https://code.claude.com/docs/en/admin-setup
• settings 参考与优先级，含全部仅管理员可用的键 https://code.claude.com/docs/en/settings
• 来自 Claude 管理控制台的服务端下发设置 https://code.claude.com/docs/en/server-managed-settings
• 权限 https://code.claude.com/docs/en/permissions
• 沙箱，操作系统层面的文件系统与网络隔离 https://code.claude.com/docs/en/sandboxing
• Hooks 指南 https://code.claude.com/docs/en/hooks-guide
• Hooks 参考 https://code.claude.com/docs/en/hooks
• Skills https://code.claude.com/docs/en/skills
• 插件与私有市场，skill 和 hook 如何在组织范围内分发 https://code.claude.com/docs/en/plugin-marketplaces
• 托管 MCP，集中管控智能体的工具面 https://code.claude.com/docs/en/managed-mcp
• 企业部署总览，Bedrock、Vertex、Foundry https://code.claude.com/docs/en/third-party-integrations
• 企业网络配置 https://code.claude.com/docs/en/network-config
• 监控（OpenTelemetry）https://code.claude.com/docs/en/monitoring-usage
• 分析看板 https://code.claude.com/docs/en/analytics
• 合规 API，企业活动流、会话检索与删除 https://platform.claude.com/docs/en/manage-claude/compliance-api
• 安全模型 https://code.claude.com/docs/en/security

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本文很大程度上建立在他们此前的工作之上。

原文 The AI-Native SDLC playbook，作者 Louis Claxton，Anthropic，2026 年 8 月 21 日，https://claude.com/blog/the-ai-native-sdlc-playbook