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

“当代码本身不再是瓶颈，速度的卡点就转移到了写代码前后的那些环节。”

代码不再是瓶颈。组织已经能用 AI 以一年前无法想象的速度写代码，但围绕代码的流程却没有同步跟上。很多工程团队仍沿用旧的审批关卡、评审、交接与政策，拖慢了代理式编码方案（如 Claude Code）带来的效率提升。软件开发生命周期（SDLC）是把软件从想法推进到上线的全过程，大多数组织都在跑大体相同的六个阶段：规划、设计、构建、测试、部署、维护。传统上每个阶段都是独立环节、由不同角色负责，产品经理写需求、技术架构师把需求变成设计、工程师实现设计、受监管企业的 QA 团队验证、发布团队发布、运维监控运行。工作通过文档、工单与签核在阶段之间流动。

传统 SDLC 流程繁重，为的是在每个步骤上保证问责与掌控。但它是为"写代码最耗时、最昂贵"的时代设计的，如今不再是这种局面。PRD、测试、产品安全评审，都是为了在可能长达数周、数月甚至数季度的开发工作中强制对齐；它同时假定每一步都由人来完成。创造最多价值的组织，已经围绕代理式 AI 现在能做到的事重塑了自己的流程，同时确保人始终留在回路里。本手册从头到尾走一遍 Anthropic Applied AI 团队在内部把 Claude 整合进 SDLC 各环节、以加速开发并让流程跑得更快的最佳实践，也借鉴了与客户合作中得到的经验。

01

代码不再是瓶颈，三个事实随之成立。

“构建阶段的速度一旦超过传统 SDLC 的承载，瓶颈就会移到它左右两侧、仍以人类速度运行的环节。”

当代码不再是最低环节、构建阶段跑得比传统 SDLC 允许的更快时，三件事随之成立：瓶颈移到构建左右两侧的步骤，主要是规划、评审/测试与部署，它们仍以人类速度运行；控制措施与现实的匹配失效、变得难以应付，逐行评审在一行代码由人写出时说得通，但一旦 agent 写掉了大部分 diff 就追不上；治理成本上升，因为仍然要流经每周或每月才开一次会的委员会与评审组。

用安全瓶颈来举例。安全团队是按人类产出规模配置的，当 agent 放大代码产出时，要么评审队列越堆越长，要么代码在欠评审状态下上线。受监管组织两种结果都接受不了，于是其安全与政策检查必须跟上 agent 的节奏。为了真正兑现代理式 AI 的产出增益并把它管控好，传统 SDLC 流程需要经历与实现阶段所经历的同等级变革。

02

什么是 AI 原生 SDLC。

“AI 原生 SDLC 把旧的管控目标与新的强制执行方式结合起来，让流程从线性变成闭环。”

AI 原生 SDLC 是一种被重新想象出来的流程：把旧的管控目标与新的强制执行结合在一起。它不再是线性流动，而是变成一个环，AI 嵌在每一个点上。AI 原生 SDLC 推动自动交接、以及触发后续玩法（plays），从而缓解传统 SDLC 阶段之间那种手工、笨拙的交接。贯穿右栏的那条主线是"已提交的工件"，每个阶段结束时向版本库提交一样东西（intent.md、spec.md、plan.md、diff 与其测试、带着评审发现的 PR、事故记录），下一阶段从读取它开始。早期的阶段里 .md 是主要工件，因为产品负责人和 agent 能读并作用于同一个文件；从构建阶段起，工件就是代码及其记录。这串 commit 也是审计线索：谁要了什么、agent 产出了什么、谁批准了。人仍然对每一个需要判断的决策负责。在代理式 SDLC 的世界里，人的注意力跟着需要被评审的工件一起转移。

下表展示了传统 SDLC 与由 Claude 支撑的 AI 原生 SDLC 两个端点的差异。大多数组织位于两栏之间。

03

Plays：六个阶段的玩法总览。

“每个玩法都覆盖五件事：改了什么、怎么上手、具体步骤、治理考量、以及如何衡量是否奏效。”

玩法（plays）是这本手册的核心，按六个非线性的阶段（Plan、Design、Build、Test、Deploy、Maintain）分组，共同覆盖完整生命周期。每个玩法覆盖：改了什么；怎么上手；实现的具体步骤；治理考量；如何衡量它是否奏效。这些步骤是模块化的，组织可以按自身需求，在不同的时间优先转型不同的阶段。每个玩法在"Prerequisites（前置条件）"下点名它的依赖，依赖图进一步说明了这一点。一个阶段以提交一个工件结束，这个提交触发下一阶段，一份被接受的 intent.md 触发需求与设计环节，一份获批的 spec.md 触发计划模式，一个合并的 PR 触发流水线，生产中的一个控制带突破写下一份 intent.md，循环由此继续。

一开始是人工逐步提示每一步，最终形态是一个环：每个被接受的工件延伸下一个关卡。人的注意力集中在关卡上，评审 agent 标记出来的东西，而不必从零开始启动每个阶段。图中的玩法按阶段列出；箭头给出采用它们的顺序，两者不是一回事。可以从任意一个"clay play"开始，没有任何箭头指向它，说明它不需要任何前置；对其它玩法，指向它的箭头就是采用它之前要先采纳的玩法。

04

Stage 1 计划：把想法捕获为 intent.md。

“想法不再等着有人把它写出来；意图被一次性捕获，用发起者自己的话，做成下一阶段能直接作用的版本化工件。”

intent.md 是启动软件开发流程的东西，可以通过不同途径进入：一个人有了想法、一个工单被创建、或通过告警浮出一个事故（见 Stage 6 维护）。当一个人有想法时，他与 Claude 头脑风暴，产出一份 markdown 原型规格（proto-spec）。在传统 SDLC 里，同一个人还要再去说服产品团队成员替他把想法写出来或一起写。而这份由 Claude 生成的 proto-spec 人可读、被版本化、能立即被下一阶段消费，被保存为 intent.md。无论意图来自事件触发还是来自 agent，采用的步骤都一样：产品负责人在它提交前，先评审并纠正那份由 agent 写出的 intent.md。

传统做法：一个想法要经过待办条目、用户故事、故事点、细化会议，才轮到有人能动手。交付权在每次交接时转移，所以最终到达工程端的东西，已经离发起者的本意差了好几步。

AI 原生做法：发起者与 Claude 头脑风暴，把结果写成 intent.md，一份用发起者自己的话写成的原型规格。工件里包含想要什么、为什么、以及在哪些约束之下。重复性流程通过 skills 编码。

怎么上手。 前置条件：无。基础设施：为不会写代码的人提供 Claude 访问（claude.ai 或 Cowork）；一份商定好的 intent.md 模板；一个共享、可版本化的意图存放处，由产品负责人盯着。对单个产品，最简单的存放处是产品仓库里的 intent/ 目录，让工件链与由它派生出的代码挨在一起。只有在意图跨多个仓库时才值得单独建一个意图仓库；在 monorepo 里它就是一个目录。Stage 3 构建的侧边栏介绍了这个存放处与已经存着记录的 Jira 或需求工具之间的关系。这属于平台或工程团队的一次性搭建任务，需要一位懂技术的人搭起意图存放处、并决定谁有写入权，会有很多来自组织各处的贡献者。仓库就位后，没有 git 经验的贡献者不必直接用 git；取而代之的是一个连接到版本控制系统（如 GitHub）的连接器，让 Claude 从 claude.ai 或 Cowork 替他们提交 markdown 文件。

如何执行：发起者用自己的话向 Claude 描述问题，可以描述今天做不了什么、这个想法影响谁、更好的样子是什么、或哪些超出范围，不需要正式语言；头脑风暴直到想法具体化，Claude 会像个分析师那样问：范围、用户、约束、成功什么样子；让 Claude 按组织模板把结果写成 intent.md（模板可由一位懂技术的人编码成 skill、并由一位负责人签核），覆盖问题、预期产出、受影响用户与系统、约束与开放问题；发起者纠正 Claude 理解错的地方；把 intent.md 提交到共享存放处，作者与时间戳进入记录，产品负责人从这里接手。

治理考量：证据就是已提交的 intent.md，它列出作者、时间戳与完整修订历史，记录在意图存放处的 git 历史里。产品负责人批准，把意图送进 Stage 2 设计的"接受或拒绝"决策，就记录为这次 merge 或关闭的评审。

如何衡量：领先指标，从第一次对话到一份已提交的 intent.md 的时间，从意图存放处的 git 历史读取（记录作者与时间戳），期望从数周的启发与细化周期降到数小时。滞后指标，存活率，即被产品负责人接受进入 Stage 2 设计、而非关闭的 intent.md 比例；接受或拒绝记录为工件的 merge 或关闭的评审；此外还有同一变更在首份 spec.md 提交之后又对 intent.md 做出的改动次数。

05

Stage 2 设计：需求与设计一次会话。

“需求与设计坍塌进一次会话；政策在写规格时就被应用，而不是几周后在评审里才发现。”

一旦产品负责人批准，Claude 拿着被接受的 intent.md，产出一份需求与设计规格。这由组织的技能（skills）引导，它们涵盖品牌、安全、合规与 UX。产品负责人评审这份规格，但不必亲手写它。流程的目标是产出一份工程团队能据以规划、并标出关注区域的规格。前端的例子最清楚：intent.md 被接受后，产品负责人在 Claude Design（测试版）里从 intent.md 起把设计做成原型，反复迭代，然后导出给 Claude Code 去构建。

传统做法：需求与设计是两个独立阶段、由不同团队负责。分析师把想法正式化为需求，设计师再把需求解析回设计。这种分离是为了问责，但既慢又有损耗。

AI 原生做法：两个阶段在同一次提示（prompt）会话里完成。Claude 取 intent.md，产出需求与设计规格，受组织 skills 约束，并标出关注区域。

怎么上手：前置条件，写一份 intent.md，把品牌、安全、合规与 UX 政策写成 skills。基础设施，一位有 Claude 访问权限的产品负责人，不需要工程技能。

如何执行：产品负责人打开一个加载了组织 skills 的会话，并附上 intent.md；产品负责人的提示指向 intent.md、点名约束、要求标出关注点，先手工跑，然后固化为组织级斜杠命令，再从把意图存放处接受 intent.md 做成触发器、用一个在 merge 时触发的非交互任务加载组织 skills 跑一遍、并把 spec.md 作为 PR 提交（Stage 5 部署的 CI/CD 玩法覆盖管道）；从那时起产品负责人的第一次介入就是评审。同一产品负责人对照想法评审规格，它是否解决了所述问题，intent.md 里的开放问题是被回答了还是被带了过去；先处理被标出的关注点，那些是分析师会升级的点，产品负责人在工程端看到规格前，逐一与对应的政策负责人解决；把 spec.md 与 intent.md 一起提交，这组文件记录了什么被要求、什么被决定；产品负责人决定规格与意图是否推进到构建，对组织归为较高风险的内容请教一位技术负责人，这个决定总由一位人类队友做出，接受规格就成为启动 Stage 3 构建计划模式玩法的动作。

它长什么样（提示词）：读取附上的 intent.md，产出一份把它整合进我们现有代码库的需求与设计规格。应用你可用的 skills，让计划符合我们的品牌规范、安全政策与 UX 标准。把规格完整体现为 spec.md，随时可交给工程团队。清楚描述任何关注区域，特别是你无法同时满足相互冲突政策的地方。

治理考量：这一变体不再是几周后在一次评审里才发现问题，而是在写规格时就读取并应用现行政策。组织的 skills 作为规格上的约束被应用。规格、产生它的提示词、以及当时生效的 skill 版本，全部记录在版本控制里。产品负责人签核规格，并把关注点转给具名的政策负责人。

如何衡量：领先指标，同一次变更从 intent.md 提交到 spec.md 提交的间隔时间（两个 git 时间戳），与旧的"需求加设计"周期比较。滞后指标，构建开始后的需求返工，统计同一变更在首份 plan.md 提交之后才出现的 spec.md 提交，git log 直接给出。

06

Stage 3 构建：计划模式与制度资产。

“没有一份被接受的计划，什么都不实现；机构知识变成 agent 读取的文件，护栏作为代码而不是习惯来运行。”

工程师以 Claude Code 的计划模式（plan mode）打开会话，把 Stage 2 设计批准的 spec.md 给 Claude，让它"面试"工程师、反复打磨计划直到工程师满意。这保证设计评审发生在任何代码生成之前，那时改弦更张还只是改一份文档的事。计划模式本身就强制这一点，因为 Claude 在工程师接受计划前无法改文件。

传统做法：工程师读设计开始写代码。改动怎么做、落到哪个文件、哪些测试，都停留在工程师脑子里、顶多是一句工单备注。没人能评审它。评审者看到的第一样东西是成品 diff，到那时返工已经很慢。

AI 原生做法：工作从一份由 Claude 在计划模式中产出的书面计划开始，它能读代码库但什么也不改。工程师在写代码前纠正计划，批准的版本提交成 plan.md，供后续阶段对照。

怎么上手：前置条件，意图工件（intent.md 或 spec.md）如果存在、以及 CLAUDE.md 文件会有帮助。基础设施能访问仓库的 Claude Code。

如何执行：工程师以计划模式开启 Claude 会话；把 spec.md 与 intended 给 Claude，让它给出一份实施计划，点名会改的文件、工作顺序、以及能证明它的测试；用"这个改动可能破坏什么、哪一步最冒险、Claude 没选哪些其它选项"来质询计划；反复迭代，直到一位从未看过这段对话的工程师仅凭计划就能实现这个改动；把批准的 plan.md 提交，计划进入审计线索，Stage 5 部署的 PR 评审玩法会把最终 diff 与它对照；接受计划、让 Claude 实现，有了扎实的计划，实现往往一遍就过；当实现偏离计划时，在同一提交里更新 plan.md，考虑用 hook 强制两者同步。

计划长什么样（plan.md）：列出了会改的文件（StatusPanel.tsx 等）、工作顺序、风险（claims-core API 限速 50 rps，面板必须缓存）、以及证明（test_status.py 覆盖四种理赔状态，截图与批准的原型一致）。

治理考量：设计评审发生在任何代码生成之前，那时改方向只是改文档。计划与它的修订连同谁接受它一起被记录。常规改动由工程师批准，组织归为较高风险的交技术负责人或架构师。

如何衡量：领先指标，从第一次实现就合并的改动占比，以及从计划批准到合并 PR 的时间（PR 元数据里有所需数据）。滞后指标——每次改动的返工周期，以及合并后的 diff 是否仍与已提交的 plan.md 一致。

自动模式（auto mode）：Claude Code 也能跑自动模式，工程师批准计划、反复迭代满意后，Claude 逐项应用改动而不逐次提示。随着后续玩法的护栏成熟（调好的 CLAUDE.md、编码政策的 skills、拦截危险动作的 hooks、Claude 能跑的测试集），自动接受成为日常工作的默认：一份紧凑的 spec.md、小的爆炸半径、以及已有测试覆盖的代码。重心从"用户盯着 agent 做编辑、评审动作"转向"在更长的自主会话之后评审工件"。结合 worktrees，自动接受模式还能在个人与团队间进一步并行，也是按 Stage 6 维护所述自主运行 SDLC、并闭合环路的基础。

侧边栏：遗留系统与真源。 适用于流程产出的每一个工件。现有 SDLC 流程很可能已经追踪工件，只是不在 markdown 文件里。工作项可能在 Jira、需求在带监管追溯的工具里、设计在 Figma、变更审批在变更委员会。这些系统很难被替换，因为审计与监管已经接受它们、且其它团队依赖它们，所以 AI 原生 SDLC 必须绕着现有存在来适配。转型时，对流程产出的每个工件，指定一个系统作为真源（source of truth），其余都保存它的一份副本或一个指向原件的链接。配置可以做成单真源，选择因工件而异：仓库作为真源，markdown 工件是权威记录，遗留系统引用提交内的文件，这往往是工程主导型组织里最干净的一种，所有记录在一个工具、一个时间戳权威里；遗留系统作为真源，Jira、ServiceNow 或需求工具持有权威记录，markdown 工件是工作副本，Claude 在会话开始时读记录、通过 MCP 连接器在同一会话里把结果写回；以"链接"作为最低标准，所有工件注明记录 ID，所有遗留记录包含 markdown 文件的 commit SHA，这是转型时的好起点，但要接受存在两个真源。只要两者之间有链接、或其一被指定为真源，遗留系统与 markdown 优先系统就能共存。

CLAUDE.md：给 Claude 提供一位新同事需要的上下文，约定、命令、架构、团队最常见的错误。以前散落在人脑与 wiki 里的知识，变成 agent 在每次会话开始时读取的文件，由整个团队维护，每当犯错就迭代。上手：在仓库里运行（生成一份起始 CLAUDE.md，从 Claude 发现的东西里）；把它裁剪成新同事第一天需要的内容，保留构建/测试/lint 命令、重要约定、以及 Claude 总搞错的事；把它 check 进仓库根目录，让整个团队共享同一版本、改动像代码一样被评审；一条有效规则，当 Claude 两次犯同一个错，就把纠正写进 CLAUDE.md；保持在一页以内，因为 Claude 会话开始会读全部内容，过时的东西只在白白占用上下文。

CLAUDE.md 长什么样：以"支付服务"为例——Commands（make build / make test / make lint）、Conventions（Java 21、Spring Boot 3、不用新的 Lombok、钱一律 BigDecimal 不用 double、每个端点都要集成测试）、Architecture、Things Claude gets wrong（不升级依赖版本，平台团队持有它们；遗留 v1/ 包冻结，改动进 v2/）。

技能即机构知识（skills）：skills 是组织把机构知识变成可操作的方式。指示明确、经版本控制、被广泛应用、政策变化时集中更新。经验法则：为"必须被一致应用的机构知识"写 skill；不要为属于 CLAUDE.md 或提示词里的组件写 skill。上手：挑一条今天执行得不一致的知识，可能是安全标准、API 设计约定或品牌规则；把它写成 skill，一个含 SKILL.md 的目录，frontmatter 说明何时触发，正文说明做什么，由一位工程师从政策负责人的真源出发、用 Claude 协助写；把 skill 放在仓库的 .claude/skills/ 下让它随代码走，或通过插件组织级分发；测试它是否触发，用不同方式让 Claude 做相关任务，确认每次 skill 都加载；政策变化时改 skill、由政策负责人签核；工程师在下一次会话自动拿到新版本。

Skill 长什么样（.claude/skills/secure-api-review/SKILL.md）：一个安全 API 评审 skill，frontmatter（name: secure-api-review，description：应用 API 安全标准，在创建/修改外露端点、评审 API 代码或生成 OpenAPI 规格时使用），正文列规则：每个端点要求网关 JWT、不接受 /health 之外的匿名路由；按 OpenAPI schema 校验请求体并拒绝未知字段；每个状态变更端点发出含操作者、动作、实体与时间戳的审计事件；schema 中标为 pii 的字段永不进日志或错误信息，并在小结里带上 scripts/check-endpoints.sh 的输出。

治理考量：skill 是一种控制，尽管偏建议性。它让 Claude 在写代码时更可能应用政策，但没有任何东西强制会话去遵守它。凡是必须始终成立的政策，需要在 skill 之外放某种确定性的东西，比如拦截动作的 hook，或一个在 PR 处复查政策的评审环节。skill 让违规变少，hook 让违规近乎不可能。skill 调用记录在会话追踪里，政策负责人像评审代码一样评审 skill 变更。

如何衡量（skills）：领先指标，从政策负责人批准一项政策变更到更新后的 skill 合并的时间，取自 skill 目录的 PR。滞后指标，引用该政策的 PR 评审意见，一旦 skill 在写代码时应用政策，这个数应趋近于零；若不降，要么 skill 没触发、要么它文本已经偏离官方政策。

hooks 作为构建护栏：skill 是建议性控制，hook 是它背后确定性的那一层。Claude 的动作大多是实现中的文件编辑与 shell 命令，所以构建阶段是 hook 最可能密集触发的阶段。构建阶段的 hook 能：拦截对受保护路径（如生成类、冻结的包）的编辑；在文件编辑后跑格式器与 linter，让漂移不累积；让凭据不进 diff。给任何政策"必须无例外成立"的 skill 背后架一个 hook。hook 对每个命中它的动作运行一次，所以构建阶段 hook 应该快、并只作用于变更的文件。更重的检查（如完整测试套件）属于 commit 或 PR 阶段。一个要求人类批准的 hook，归入 Stage 5 部署的关卡，因为构建期间的审批提示，会把一个人重新放回到所有并行会话的关键路径上。

并行会话与子代理（subagents）：一个工程师能同时驱动多条工作流。并行会话是另一个完整的 Claude Code 实例，在自己的 git worktree 里跑一个独立任务；每个独立会话彼此不知道，驱动它们的工程师是唯一的共享点。子代理跑在单个会话内部，是一个带自己上下文窗口与工具限制的受限助手，适合在多个任务里反复出现的活（如验证应用按预期运行）。并行会话提高一个工程师能同时开工的任务数，子代理让每个会话专心于自己的事。工程师的活变成引领与评审所有这些会话。

传统做法：一个工程师一次只做一个任务，相当一部分时间花在构建、测试与评审上。等待时切换任务虽有可能，但上下文切换太累，没几个人愿意。

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

怎么上手：前置条件，CLAUDE.md，因为所有会话都读它；Stage 4 测试的反馈环也帮得上，会话能自己验证时，就不太需要工程师监督。基础设施，一个 git 仓库，隔离来自 worktree，权限设置调到会话不必为组织认为安全的命令等待审批提示。

如何执行：工程师用计划模式玩法的计划，把工作拆成触碰不同文件的任务；共享文件的任务在一个会话里、一个接一个跑；每个并行任务获得自己的 worktree，例如一个终端跑主分支、另一个跑特性分支，worktree 是在自己分支上的独立检出，能阻止会话在文件上相撞；两到三个会话是合理的起点，实际上限是一个人能妥善评审多少条流，只在评审跟得上时再加会话；把重复的活变成子代理，定义在 .claude/agents/ 下的 markdown 里，每个有自己的名字、何时使用的描述、以及可触碰的工具，示例包括一个在主 agent 完成后剥离多余复杂度的代码简化器、一个跑起应用并核查行为的验证器、一个探查代码库并向主上下文报告而不刷屏的研究者，把这些定义 check 进 git，整个团队共享。

子代理长什么样（.claude/agents/verifier.md）：名字 verifier、描述"在会话报告完成前跑起应用并核查改动生效"、工具 Bash、Read；正文用 make run 启动应用，练习改动的行为与两个最近的相邻流程，报告你跑了什么、看到了什么、以及任何与 plan.md 不符的行为，不要修任何东西，只报告。

治理考量：会话越多产出的越多，所以控制必须来自仓库里的配置。hooks 与那里的权限设置适用于所有会话，一次会话做了什么被记录、并归属到运行它的工程师。

如何衡量：领先指标，评审质量保持时的每工程师并发会话数，来自 OpenTelemetry 导出；以及一天里花在"引领"而非"等待"的份额。滞后指标，每位工程师每周合并的改动数，与实际返工率一起看（按 PR 历史）。

07

Stage 4 测试：反馈环与持续评测。

“每个会话都在人看到之前先自检；驱动 agent 的那份配置，也要像它写的代码一样被回归测试。”

给 Claude 一个反馈环。 永远给 Claude 一个验证自己工作的途径，测试、构建、或截图 diff。会话在自己的工作、人看到之前修好自己的错误。反馈环不该与 Stage 3 构建的验证器子代理混淆，反馈环贯穿整个任务、随工作反复跑很多次；验证器子代理则是把最终检查打包的一种方式，在会话相信已完成之后用一个全新上下文窗口跑一遍，这样结论不会被产生代码时的假设染上颜色。

传统做法：代码能用的信号来得晚，CI 几分钟后、测试者几天后、生产几周后。由 agent 产出代码时，晚到的信号意味着人得检查它的全部输出，而这个人成了瓶颈。

AI 原生做法：会话被人看到之前就拿到自检的途径。跑测试、跑构建、截图。Claude 迭代到检查通过，所以到达工程师手里的东西已经过检查。搭起这个环是运行会话的工程师的事，下面这些步骤为他们而写。

怎么上手：前置条件无。基础设施是一套能用一条命令本地跑起来的测试套件与构建；UI 工作则需要让 Claude 能看到结果的方式，一个浏览器工具或通过 MCP 接上的截图工具。

如何执行：如果今天检查工作要一串命令+环境知识，就把它们包进单个目标（如 make test 或 npm test），失败时非零退出；在 CLAUDE.md 的 Commands 部分列出每条命令与一个健康输出的示例；设定一个可量化目标，让 Claude 不用问你就能自检，"test_status.py 的所有测试通过""截图与附件原型一致""端点返回带新字段的 200"；修 bug 时先写会失败的那个测试，让 Claude 把 bug 复现成测试、运行它、确认它因你预期的原因失败，提交那个测试，然后才让 Claude 在不改测试的情况下让它通过、由最后一步的测试文件 hook 强制限制；一个在修 bug 前就存在的、且 agent 无法重写它就能证明 bug 已修复。UI 工作用视觉检查闭合环路，给 Claude 浏览器或截图工具、给它原型、让它迭代：实现、截图、对比、调整，两三轮很正常，结果应逐轮改善。让验证成为"完成"的一部分，指示写在 CLAUDE.md，报告任务完成前跑测试并把输出贴出来。最后，环路本身需要保护，一个在修复任务期间阻止编辑测试文件的 hook 做到这点；备选是评审里检查 diff、拒绝任何触碰测试的改动。

CLAUDE.md 验证块长什么样：构建：make build（必须结束于"Build succeeded"）；测试：make test（全绿；永不跳过或删掉一个失败的测试）；lint：make lint（零警告），报告任何任务完成前先跑这三样并粘贴输出。若测试失败，修代码，不修测试。

治理考量（反馈环）：强制执行任务报告完成前的验证、修 bug 期间阻止 agent 编辑测试文件的限制，都在组织想确保的地方实现成 hook。证据，make test 的字面输出、构建日志、或 Claude 跑过并粘贴的截图 diff，证据来自工具链。记录，会话记录里，OpenTelemetry 导出转发到组织的可观测性栈，以及 PR 的 check run，评审者与审计者都能看到。审批，评审 PR 的代码负责人，因为机械证据已附上，能专注在意图与风险上。

如何衡量（反馈环）：领先指标，agent 改动的一次通过 CI 成功率，CI 系统已支持。滞后指标，每个 PR 的评审时间（来自 PR 元数据），一旦测试接住评审者过去接住的东西就应下降；以及来自事故追踪器的变更失败率。

CI 里的持续评测（evals）：评测是阶段关卡 QA 的 AI 原生等价物。实际操作里，指一套每当 agent 配置变化时就跑的套件，换新模型、重写提示词，评测套件就会说 agent 是否仍以同一标准做好这份工作。评测应被视为一套活的套件，随模型进步，曾经有区分度的用例会失去区分度，要补入从持续监控中新冒出来的用例。视用例而定，有些团队更愿意按固定节奏离线跑这些评测、而不是每次变更都跑。下面的步骤针对持续评测。

怎么上手：前置条件是CLAUDE.md（Stage 3 构建）与反馈环（Stage 4 测试）。基础设施是能非交互跑 Claude Code 的 CI，以及带着评测预算的 API key。

如何执行：平台工程师从近期工作中收集 20 到 50 个真实任务、连同其预期/已接受的结果；把每个任务写成一项评测，即提示词加上定义"可接受"的检查（测试通过、lint 干净、行为不变、政策被遵守）；整套非交互地在 CI 里按计划跑、并在任何 CLAUDE.md / skills / hooks 变更时跑，因为正是这份配置在驱动 agent，值得给它像代码一样被回归测试；用结果给配置变更设卡，一项让通过率下降的 skill 变更，在合并前先被评审；每个生产事故都得到一项评测，由拥有该事故的团队写出，并留在套件里作为回归测试。

评测流水线长什么样（.github/workflows/agent-evals.yml）：触发于对 CLAUDE.md 与 .claude/** 的 PR、以及一个定时 cron；job 安装 @anthropic-ai/claude-code，非交互跑 eval，用 --allowedTools "Read,Edit,Bash(make test)" --output-format json，再跑 ./evals/check.sh 校验结果。

治理考量（评测）：评测给了 QA 一个跟得上 agent 产出的关卡。通过率阈值作为 merge 检查被强制，运行被记录以便跨时间比较，拥有该配置变更的团队批准它。

如何衡量（评测）：领先指标指随时间变化的评测通过率（每次运行都报告），以及一个生产事故要多久变成一项常驻评测。滞后指标指CI 里被接住的回归，相对生产中被发现的回归（来自事故追踪器）。

08

Stage 5 部署：双向评审与审批门。

“评审双向进行，治理在 agent 行动时被强制；agent 做上生产门之前的一切、不过它之后的一切。”

PR 评审环里的 AI。 Claude 既给出也接收评审：它按组织政策评审进来的 PR，也回应自己 PR 上的评审意见。这让工程师能专注在行为层面的评审，本质上就是判断意图与风险。

传统做法：评审能力按人类产出规划。一份 PR 等一位评审者读完全部，评审质量随评审者负荷浮动，作者在积压增长时追着跑。

AI 原生做法：所有 PR 得到一套相同的评审，发现按严重度排序。人的注意力上移一层——这次的改动是否做了计划想做的事、以及风险是否可接受。

怎么上手：前置条件指一份来自 Stage 3 构建的更新版 CLAUDE.md；如果评审过程要强制执行已写的政策，则需要 skills、定义好的子代理。基础设施指一个装有 Claude 集成的仓库，要么是托管版 Code Review（研究预览，由管理员启用），要么是在自己 CI 里跑的 claude-code-action，按需通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 做模型调用（CI/CD 玩法覆盖部署选项）；要求代码负责人批准的分支保护策略也值得有。

如何执行：托管版 Code Review 服务是最快的起步，管理员启用它并选择仓库；需要在流水线里掌控、或想让 API 调用走自己云协议时，就用 claude-code-action 在自己 CI 里跑评审（CI/CD 玩法覆盖管道）。技术负责人把评审政策写成仓库根的 REVIEW.md，分成组织关心的几个 pass：bug 与逻辑错误；安全与漏洞；对照规范（intent/spec.md来自需求玩法）、实施计划（plan.md来自计划模式玩法）与设计原则的合规。REVIEW.md 还定义什么算 Important、什么算 Nit、以及要跳过哪些。技术负责人设定人工阈值，发现本身不单独批准或阻止一份 PR，分支保护仍要求代码负责人批准；想按发现来设 merge 关卡的平台工程师，可以读该 check run 发布的、机器可读的严重度计数。当评审者或作者在评审意见上 @Claude，Claude 回应并推送修复；PR 线程记录请求与改动。这个修复环跑在 claude-code-action 上；托管服务里输入特定指令则请求一份新评审。对 Claude 自己开的 PR，更进一步让 Claude 照顾到合并，团队把环包进一个自定义斜杠命令，扫过 PR 上未解决的评审意见与失败的检查，回应并推修复，直到 PR 变绿、只等代码负责人批准。评审发现回馈进 CLAUDE.md，当一次评审第二次标出一个错误，纠正就写进 CLAUDE.md，因为评审读 CLAUDE.md，下一次 PR 起这个错误就会被接住；评审也标出何时变更已让 CLAUDE.md 过时。每月技术负责人通过给发现打分来调优该设置、并在 REVIEW.md 里封顶 Nit 量；生成路径与任何 CI 已强制的东西除外。

REVIEW.md 长什么样：运行三个 pass 并为每条发现打个 pass 标签，Bugs（逻辑错误、坏掉的边界情况、微妙回归）、Security（注入风险、认证缺口、日志里的 PII）、Compliance（改动符合 spec.md、plan.md 与我们的设计原则）。"Important"在这里的含意——留给会打破行为、泄露数据或违反政策的发现；风格与命名是 nit。封顶 nit每次评审最多报五条 nit，其余汇总成一个计数。不要报src/gen/ 下的生成文件、以及任何 CI 已强制的东西。

治理考量：职责分离被保留，因为写代码的 agent 没有批准代码的途径。REVIEW.md 里的评审政策应用到所有 PR，发现、修复、评分与批准记录在 PR 历史里，所以 PR 就是审计记录。批准来自人类，通过分支保护、以发现为依据。

如何衡量（PR 评审）：领先指标指到首次评审的时间，应降到分钟级；以及不让人碰分支就解决的评审意见占比（数据直接存在 Git 上）。滞后指标指合并前被接住的缺陷与漏洞，相对逃到生产里的那些（来自 PR 历史与事故追踪器）。

hooks 作为审批门。 构建阶段用 hook 做护栏，允许或阻止动作、不涉及人（Stage 3 构建）。hook 也能"询问"，暂停动作直到某个具体的人批准，这正是发布关卡需要的。这个玩法放在 Stage 5 部署，因为发布关卡是最清楚的情形，但 hooks 不只用于部署，它们跑在 Claude 行动的任何地方。例如，构建阶段 hook 能阻止无变更工单就编辑迁移与基础设施，测试阶段（Stage 4）能阻止修 bug 任务期间 agent 编辑测试文件。

怎么上手：前置条件无。基础设施指一份列出变更流程所需审批的书面清单。

如何执行：工程领导层会同变更管理与合规，列出必须存活的人工审批关卡——例如变更管理签核、发布授权、对受保护路径的编辑。平台工程师把每个关卡表达成一个 hook，一个在 Claude 行动前运行、可 allow（允许）/ask（询问）/block（阻止）的脚本。团队 hooks 放 .claude/settings.json 里进 git；不可谈判的 hooks 放托管设置里、由平台或 IT 管理员持有，工程师关不掉。一次阻止应自我解释，所以当 hook 拦下一个动作，原因与批准途径出现在 Claude 输出里。

settings.json hooks 长什么样：.claude/settings.json 里一个 PreToolUse 钩子，matcher "Bash"，command 指向 .claude/hooks/production-gate.sh。而关卡本身（production-gate.sh）：一个 Bash 脚本，检查命令行是否含 deploy 与 production，若缺少 $RELEASE_APPROVAL 则输出"生产部署需要发布授权"并以退出码 2 阻止动作。

治理考量（hooks）：hooks 就是审批关卡。关卡条件每次、对每个人都被强制。allow 与 block 决策带时间戳记录。关卡也定义什么算"批准"，一张已批准的变更工单，或发布经理的签核。

受管设置：一份针对受监管企业的实操示例。 由平台团队经 MDM 或管理控制台部署；工程师不能编辑或覆盖其中任何一项。permissions.deny 把密钥挡在 agent 上下文之外、并阻止经工具的不受控网络外连（Read(.env*)、Read(./secrets/**)、WebFetch、Bash(curl *)、Bash(wget *)）；permissions.allow 预先批准安全的内循环，让 deny 清单不至于变成提示疲劳（Bash(git *)、make build/test/lint）；disableBypassPermissionsMode 加 allowManagedPermissionRulesOnly 意味着没有任何工程师、项目文件或命令行旗标能放宽这些规则；sandbox 封住权限封不住的口，工具层对 WebFetch 的 deny 挡不住一个 shell 命令触达网络，OS 级域名允许清单直接从根上阻止外连；failIfUnavailable 与 allowUnsandboxedCommands 让 sandbox 成为一道门，无法初始化时 Claude Code 拒绝启动、sandbox 内失败的命令不能挪到外面重试；credentials 封住 deny 规则留下的口子，permissions.deny 管 Claude 的文件工具，但一个沙箱化 shell 命令默认仍可能读 ~/.ssh 或 ~/.aws/credentials，这一块 deny 那些读取、并把命名的密钥从每个沙箱命令的环境里剥掉；allowManagedHooksOnly 让这里的审批关卡是唯一能跑hooks 的地方，本地不能加入或替换；disableSideloadFlags 与 strictKnownMarketplaces 意味着每台机器上的每个 skill、agent、hook、MCP 服务器都来自组织批准的插件市场、而非任何用户目录；allowManagedMcpServersOnly 把 agent 的工具面收归平台团队所有、成为允许清单；requiredMinimumVersion（2.1.193）拒绝在低于已评估版本上启动，让控制由组织真正评估过的构建来强制。把以上当作一个起点来按需取舍、而不是建议照抄，每一条 deny 都拿能力去换，合适的平衡取决于仓库的数据分级。设置文档列出了每个键、包括仅托管的那部分。

hooks 本身的衡量：领先指标——在每个审批关卡上等待的时间，每次 hook 决策带时间戳与 allow/block 判定写入 OpenTelemetry 导出，按关卡可见等待。滞后指标——在 hooks 之前与之后到达生产、来自事故追踪器的关卡违规数。

CI/CD 集成与部署。 在 CI/CD 流水线里非交互地跑 Claude Code，沙箱化执行让长跑 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 服务器；一个不带常驻生产凭据的 agent 任务沙箱配置。

如何执行：平台工程师先做只读的判断步骤，用流水线 job 里的 claude -p 归类一次失败的构建、总结一个 flaky 测试、或起草 changelog。在既有关卡后加写步骤——如修 lint、更新生成文档、或经 @Claude 提及回应评审意见；agent 写的任何东西都以 PR 经分支保护到达，agent 没有通往 main 的路径。执行被沙箱化——agent 任务跑在带短命限域令牌的容器里、受网络策略约束、默认不持有生产凭据。经 MCP 暴露部署，deploy、status、rollback 都变成工具、按环境限域，让 agent 的部署能力是一份允许清单、而不是一个带凭据的 shell 脚本。按环境给自主度分级，开发环境 agent 自由部署；生产环境 agent 准备发布、由发布经理授权、hook 强制执行生产关卡；预发居中。回滚应是流水线里被演练得最多的一条路径，一个单命令、agent 能跑、并定期在预发里演练；Step 6 维护的"闭合环路"玩法在控制带被突破时会调用它，所以要提前证实。

流水线步骤长什么样：一个名为"归类失败构建"的 step，if: failure()，运行 claude -p"读取 out/build.log 的构建日志，指出最可能的原因，说失败看起来像 flaky 还是真实，为 PR 线程写三行小结" >> triage.md。

治理考量：治理原则是agent 可以做上生产门之前的一切、不能越过它。以下控制强制这一原则：分支保护把 agent 写的任何东西变成 PR、没有直通 main 的路；生产部署 hook 阻止发布，直到具名发布经理授权；每次非交互运行以 agent 自己的身份动作，所以流水线日志区分"agent 做了什么"与"触发它的工程师做了什么"；按环境的权限层级规定了在通往关卡的路上 agent 能做的量。

如何衡量（CI/CD）：领先指标指不惊动人就被归类掉的流水线失败占比（来自 CI/CD 流水线日志）。滞后指标指DevOps 研究评估（DORA）指标，CI 系统与部署工具已经产出。

09

Stage 6 维护：闭合环路与在线待命。

“这个环闭合了，一个触发器在无人参与调用路径的情况下唤醒 Claude，它找到的东西作为新 intent.md 重回流水线。”

维护与闭合环路。 到目前为止，我们讲了如何把 Claude 加进 SDLC 流程的每个阶段，每个阶段都还要一个人启动初始步骤。这个阶段把重心转到自主运行 Claude 来闭合环路。例如，一个持续运行的监控 agent，可以借着 bug 工单被提起，创建一份 intent.md，流经需求、计划、构建、测试与评审阶段。Stage 6 维护无头运行，阶段之间有一个独立的置信关卡，一个确定性检查或一个对抗式评审 agent决定上一阶段的产出是继续、还是升级给人。

传统做法：维护是反应性的。所有工单或事故都等人去行动并重启流程。凌晨三点一个告警发出来可能被错过，一张工单能躺在待办里直到有人捡起，事后行动可能根本到不了代码库，如果另一场火先烧起来的话。

AI 原生做法：一个触发器控制带突破、一张工单、一条频道消息或一个计划在没有人在路径里召唤 Claude。Claude 诊断、只经有关卡的路行动、把发现写成 intent.md，然后走上述各阶段。人分诊并评审那些工作，不必再亲自启动它们。

闭合环路。 一个确定性脚本盯着生产，在控制带被突破时唤醒 Claude。监控一次突破是描述环路自主运行的一个有用示例，本节末尾的 Claude Tag（公开测试版）部分覆盖了经不同渠道到达的工作。

怎么上手：前置条件intent.md（给环路一个结构化输出来重启它）、加速 PR 评审的 Claude（Stage 5 部署）、作为行动边界的 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 里的定时 workflow、现有监控栈的 webhook、或网络内的 Cron Job；Claude 无状态运行，要么作为 CI runner 上的非交互步骤、要么作为沙箱容器里的 Agent SDK 服务；CI/CD 玩法覆盖部署与模型访问选项。因为运行无状态且非交互，一个环路能无人启动地开始与结束。agent 把诊断写成 Stage 1 计划格式的 intent.md 覆盖异常与其证据、预期产出、受影响系统与任何开放问题；从那里按其它东西走流水线。服务负责人或值班工程师分诊队列，把面向产品的发现转给产品负责人，现在就修、排期、或驳回；驳回会调校控制带、帮助降噪。当修复上线，为该事故补一项评测（持续评测玩法），确保这类事以后受保护。

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 评审关卡，agent 可触发的 runbook 已提前批准。

如何衡量（闭环）：领先指标指从控制带突破到分诊队列里出现一份 intent.md 的时间，相对旧的一次事故到一次事后行动的时间；检测脚本日志里有突破时间戳与层级。滞后指标指变成已合并修复的发现占比（分诊队列对比实际 PR 历史），以及同级事故的重发率随修复给评测套件补用例，这个数应下降。

示例：当 CI 测试失败率突破 3σ，agent 隔离那个 flaky 测试、或开一份回滚 PR，由评审关卡决定；当窗口里有部署、且部署后 5xx 率突破 3σ，agent 触发现有的回滚流水线；当 PR 周期时间触发一条漂移规则，agent 给工程领导层写一份报告，说明这套装置对流程指标、也对生产指标都奏效。检测保持确定性。一旦控制带被突破才唤醒 Claude，层级规定它能做什么。

Claude Tag 在线待命。 事故也能经其它方式到达，比如 Slack 或 Teams 这类职场沟通应用。事故可以像晚上十点事故频道的 Slack 消息、要求紧急修复，而现在能被立即处理。Claude Tag（公开测试版，目前可在 Slack 用）让 Claude 以自己身份成为那些频道的成员，每个新事故有一位第一响应者、响应本身成为未来事故的环路与记忆的一部分。对话与机构知识留在频道里，频道里任何人能引导并处理响应。任何团队成员都能实时测试假设、探索新选项、做调查，频道历史为可审计性加码。经 MCP 访问，Claude 核实指标回到基线、在线程里确认、并把事故复盘写进一份版本化的教训文件、供未来调查读取。事故不是 Claude Tag 捡起的唯一工作。在工单上 @Claude 或频道里被问到，Claude 以同样方式分诊工作，一个边界清晰的小修复作为 PR 经评审关卡到达；更大的写成分 Stage 1 计划的 intent.md，届时环路开始自我补给。

10

收尾与资源：循环不停，判断在上。

“模型与装置已经进步到让组织既能转化产出代码的方式、也能转化整个软件开发生命周期。”

这场转变把人判断力保持在流程中心，也顾及大型企业组织的治理与监管要求。这本手册综合了 Applied AI 团队每天为客户执行的大量真实最佳实践，希望它是一份实用、可上手操作的资源。闭环持续运转，人判断始终在其上。

以下文档是平台团队搭建那些控制所需的东西，大致按你会推行它们的顺序列出：设置 Claude Code 的组织级管理决策图（从这里开始）；设置参考与优先级、含每项仅托管键；来自 Claude 管理控制台的服务器托管设置；权限；沙箱是OS 级文件系统与网络隔离；hooks 指南与参考；skills；插件与私有市场，skills 和 hooks 如何在组织内分发；托管 MCP实现对 agent 工具面的集中控制；企业部署总览（Bedrock、Vertex、Foundry）；企业网络配置；监控（OpenTelemetry）；分析仪表板；合规 API是企业活动流、聊天检索与删除；安全模型。

References

[01] Anthropic Blog — "The AI-Native SDLC playbook"（2026-08-21）: https://claude.com/blog/the-ai-native-sdlc-playbook

Disclaimer

内容仅供信息参考，不构成任何投资建议或决策依据。

1. 本文所含信息来源于网络公开信息整理，已尽合理审慎义务，但不对信息的完整性、准确性、时效性作出任何明示或暗示的保证。

2. 部分内容或素材可能借助 AI 工具辅助整理/生成，均仅用于提升信息传递效率，不构成任何专业背书。

3. 若涉及公司、产品或市场动态的分析与判断，均为个人观点，不构成投资建议。读者据此操作，风险自担。

4. 如需转载或引用相关内容，请对信息溯源，注明原始出处和保留本声明。

5. 因使用文章内容导致的任何直接或间接损失，不承担任何法律责任，文章仅为公开信息传递整理，不涉及任何时事、公共政策、社会事件立场。