AI 原生 SDLC 全景拆解

00核心论断

只读这一节，也应该能拿到这份 playbook 的全部骨架。以下八条，是后面每一章的论点来源。

01核心命题：代码不再是瓶颈

组织已经在用 AI 以一年前无法想象的速度写代码，但围绕代码的流程没有以同样的速度改变。许多团队仍然保留着同样的审批关卡、评审、交接和策略——这些正是用来抑制 Claude Code 之类智能体编码方案生产力提升的东西。

传统 SDLC 之所以流程繁重，是因为它被设计出来的那个年代，编写和实现代码是最耗时、最昂贵的阶段。PRD、估算仪式、产品安全评审的存在，是为了在可能长达数周、数月甚至数季度的开发工作中强制对齐；而它隐含的另一个假设是——每一步都由人执行，所以控制手段也是按人设计的。

当代码不再是瓶颈、Build 阶段运行得比传统 SDLC 允许的更快时，三件事同时成为现实：

以安全瓶颈为例：安全团队的规模是按人类产出配置的。当智能体把代码产出倍增时，要么审查队列堆积，要么代码在审查不足的情况下发布。受监管的组织不能接受这两种结果——所以安全和策略检查必须跟得上智能体。

为了真正拿到智能体 AI 的生产力提升并保护它，传统 SDLC 生命周期需要经历与实现阶段同等程度的转型。

02什么是 AI 原生 SDLC

AI 原生 SDLC 是一个重新构想的流程：保留旧的控制目标，换上新的执行方式。流程从线性流变成一个循环，AI 嵌入每一个点。

这个转变在不同组织里有不同叫法——agentic SDLC、AI SDLC、agentic software development——标签不同，描述的是同一件事。

关键差异：交接由谁推动

六个阶段的两端对照

下表列出传统 SDLC 与 AI 原生 SDLC 的两个极端。大多数组织位于两列之间的某个位置。

03生命周期总览：六阶段闭环

Plays 是 playbook 的核心，分为六个非线性阶段。它们一起覆盖完整生命周期，但采纳顺序 ≠ 阶段顺序——你可以从任何一个没有前置依赖的阶段开始。

每个 play 都覆盖同样的五件事：什么改变、如何开始、具体实现步骤、治理考虑、以及如何衡量它是否有效。步骤是模块化的，组织可以按自身需求在不同时间优先转型不同阶段。

六阶段速查

节点结构

Plan 阶段有三个进入路径，但无论从哪条路径进入，流程是同一套：头脑风暴 → 起草 → 人工审阅更正 → 提交。

传统 vs AI 原生

基础设施（一次性搭建）

• 非工程师人员能访问 Claude（claude.ai 或 Cowork）——这是关键前提，因为 Plan 阶段的主要作者不是工程师。
• 一个商定的 intent.md 模板，通常编码为技术团队成员设置、负责人签核的 skill。
• 一个共享的、版本控制的 intent 归属地，产品负责人会关注它。单一产品最简单的归属地是产品 repo 中的 intent/ 文件夹——这让工件链留在由它派生出的代码旁边。专用 intent repo 只有在意图跨越许多仓库时才值得开销；在 monorepo 里它只是一个目录。

搭建由平台或工程团队完成，需要决定谁可以写入，因为许多贡献者会来自整个组织。一旦仓库存在，没有 git 经验的贡献者不需要直接使用 git——通过到版本控制系统（如 GitHub）的连接器，Claude 可以代表他们从 claude.ai 或 Cowork 提交 markdown 文件。

执行步骤

1. 来源者用自己的话描述问题。可以描述今天不能做什么、谁受这个想法影响、更好是什么样子、什么超出范围。不需要正式语言。
2. 头脑风暴直到想法具体化。Claude 问分析师会问的问题：范围、用户、约束、成功是什么样子。
3. 让 Claude 按组织模板写为 intent.md。模板覆盖：问题、提议结果、受影响的用户和系统、约束、开放问题。
4. 来源者更正 Claude 误解的内容。
5. 提交到共享归属地。作者与时间戳进入记录，产品负责人从这里接手。

示例 · 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?

# 意图：理赔进度自助查询
作者：J. Ortiz（理赔运营团队）。状态：草案。

## 问题描述
客户拨打客服中心电话询问其理赔进度。
处理人员大约将三分之一的通话时间用于解答仅针对进度的查询。

## 预估效果 / 方案目标
客户可在门户网站中查看理赔进度、下一步流程及预计完成日期。

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

## 约束条件
门户网站会话中不得引入新的个人身份信息（PII）。仅使用现有的身份验证机制。

## 待解决问题
第三方公估人（损失评估师）是否也需要访问权限？

传统 vs AI 原生

执行步骤

1. 产品负责人打开一个会话，挂载组织的 skills，并附上 intent.md。
2. 提示指向 intent.md、命名约束、要求标记关注点。先手动跑，然后编码为组织级 slash command。从那里进一步：把「intent 归属地中 intent.md 被接受」作为触发器，用非交互式作业在合并时触发，自动把 spec.md 作为 pull request 提交——产品负责人的第一次参与就是评审。
3. 同一个产品负责人对照想法审查规格：规格是否解决了陈述的问题？intent.md 中的开放问题是被回答还是被结转？
4. 先处理被标记的关注点，因为它们是分析师会升级的点。产品负责人在工程看到规格之前，先与策略负责人解决每一个问题。
5. 把 spec.md 与 intent.md 一起提交。这对文件记录了要求了什么和决定了什么。
6. 产品负责人决定规格和意图是否推进到构建；对组织归类为更高风险的内容，咨询技术负责人。这个决定永远由人类做——接受规格就是启动 Stage 3 的 plan mode。

示例 · 提示词

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.

阅读附加的 intent.md 并生成一份需求与设计规范，用于将其集成到我们现有的代码库中。
运用你可用的技能，使该计划符合我们的品牌指南、安全策略和 UX 标准。
将该规范完整记录为 spec.md，以便随时交付给工程团队。
清晰说明所有需要关切的领域，尤其是你无法满足互相冲突的策略之处。

节点结构：一条主链 + 一个横跨全阶段的配置层

Build 阶段的结构与其他阶段不同——它有一条顺序主链（plan mode → 审问 → 提交计划 → 实施），以及一层作用于每一个会话的配置（CLAUDE.md、skills、hooks、权限）。配置层不参与顺序，它决定主链上每一次行动的行为。

传统 vs AI 原生（plan mode）

示例 · 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.

# 计划：理赔状态自助服务（来自 intent.md 2026-06-02）

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

## 工作顺序
1. 在现有身份验证后添加状态端点（status endpoint）。
2. 基于该端点开发面板组件（Panel）。
3. 接入 Portal 导航。

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

## 验证依据
test_status.py 覆盖了四种理赔状态；截图与已批准的原型图匹配。

三个子 play：机构知识怎么变成配置

示例 · 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/.

# 支付服务

## 命令
* 构建：`make build`
* 测试：`make test`（单元测试），`make itest`（集成测试，需要 Docker）
* 代码检查（Lint）：`make lint`（在 CI 中运行；推送前请先修复问题）

## 规范 / 约定
* 使用 Java 21、Spring Boot 3。禁止新增 Lombok 依赖。
* 金额一律使用 `BigDecimal`，绝对不能用 `double`。
* 每个 API 接口都必须在 `src/itest` 中编写集成测试。

## 架构
* `api/` 存放 REST 控制器（Controllers），`core/` 存放领域核心逻辑，`adapters/` 用于与外部系统对接。
* Kafka 事件定义在 `schemas/` 目录下；切勿直接修改自动生成的类。

## Claude 容易弄错的地方
* **请勿**升级依赖包的版本；这些由平台团队（Platform team）统一维护。
* 遗留的 `v1/` 包已被冻结；所有新修改必须在 `v2/` 中进行。

示例 · .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.

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

当你创建或修改 API 接口时：
1. 身份认证：每个接口都需要网关 JWT；除了 /health 外，不得设置匿名路由。
2. 输入校验：根据 OpenAPI 规范校验请求体（Request Body），并拒绝未知字段。
3. 审计：每个改变状态的接口都要触发审计事件，记录操作者（actor）、操作（action）、实体（entity）和时间戳（timestamp）。
4. 数据分类：规范中标记为 PII（个人身份信息）的字段绝不能出现在日志或错误信息中。

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

并行会话与子智能体

• 并行会话（parallel session）：另一个完整的 Claude Code 实例，在它自己的 git worktree 中处理一个单独任务。每个会话对其他会话一无所知，指导它们的工程师是唯一的共享物。
• 子智能体（subagent）：在单个会话内运行的有范围助手，拥有自己的上下文窗口和工具限制。适合跨任务重复的工作，例如验证应用是否按预期运行。

实践建议：把工作切成不碰同一批文件的任务；每个并行任务获得自己的 worktree（如claude --worktree feature-auth）。两到三个会话是合理起点——实际上限是一个人能正确审查多少流，只有在评审跟得上时才增加会话。将重复工作变成 .claude/agents/ 下的 markdown 定义并检入 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.

---
name: verifier
description: 在会话报告完成之前，运行应用并检查修改是否正常生效
tools: Bash, Read
---
使用 make run 启动应用。测试本次修改的功能以及与之最相邻的两条业务流程。
报告你所运行的命令、看到的结果，以及任何与 plan.md 不符的行为。
不要进行任何修复，仅作报告。

节点结构：会话内自检循环 + CI 里的 evals

Test 阶段有两个独立的机制，容易混淆：反馈回路贯穿整个任务，让 Claude 边做边自检；验证器子智能体则是在会话认为工作完成后，用全新的上下文窗口做最后打包检查——这样裁决不会被产生代码时的假设着色。

传统 vs AI 原生

执行步骤要点

1. 如果今天检查工作需要一串命令和环境知识，把它包装成单一目标如 make test 或 npm test，失败时以非零退出。
2. 在 CLAUDE.md 的 Commands 部分列出每个命令，并给出健康输出的例子。
3. 陈述目标时使其可量化，以便 Claude 能自己检查而不必问你。
4. 修 bug 时先写失败的测试。让 Claude 把 bug 复现成测试、运行它、确认它因你期望的原因失败——然后提交那个测试。只有这样才让它在不编辑测试的前提下通过。一个在修复之前就存在、且智能体无法重写的测试，是 bug 已消失的证明。
5. UI 工作用视觉检查关闭循环：实现 → 截屏 → 比较 → 调整。两到三轮是正常的，结果应该每轮改善。
6. 把验证作为「完成」的一部分：在报告任务完成之前跑测试并显示输出。
7. 循环本身也需要保护——修复代码的智能体不能削弱对该代码的检查。一个在修复任务期间阻止编辑测试文件的 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.

## 验证你的工作

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

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

示例 · .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

节点结构：三通过集评审 → 人类关卡 → 分层自治

传统 vs AI 原生

执行步骤要点

1. 托管 Code Review 服务是最快的开始——管理员启用并选择仓库。需要控制流水线或想通过自己的云协议路由模型调用时，在 CI 中用 claude-code-action 自行运行。
2. 技术负责人把评审策略写成 REVIEW.md，分为组织关心的通过集，并定义什么算 Important 与 Nit、跳过什么。
3. 设置人类阈值。发现不批准也不阻止 PR，分支保护仍要求代码所有者批准；想按发现对合并设关卡的平台工程师，可以读取检查运行发布的严重性计数作为机器可读统计。
4. 让 Claude 处理评审评论。评审者或作者在评论上标记 @claude，Claude 处理并推送修复，PR 线程记录请求与变更。进一步的做法是让 Claude babysit PR 到合并：扫描未解决的评审评论与失败的检查，逐个处理直到 PR 变绿、只等代码所有者批准。
5. 评审发现反馈到 CLAUDE.md。当评审第二次标记同一个错误，更正作为该次评审的一部分进入 CLAUDE.md——因为评审读 CLAUDE.md，这个错误从下一个 PR 起就被捕获。评审还应标记「变更何时使 CLAUDE.md 过时」。
6. 每月调优一次。技术负责人给发现评分以便评审者改进，并在 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.

# 审查指南

## 审查轮次
运行三轮审查，并在发现的每个问题上标注对应的轮次：

- 逻辑缺陷（Bugs）：逻辑错误、边界情况失效、隐蔽的回归问题
- 安全性（Security）：注入风险、身份验证漏洞、日志中的个人身份信息（PII）泄露
- 合规性（Compliance）：变更是否符合 spec.md、plan.md 以及我们的设计原则

## 此处“重要（Important）”的含义
仅对会破坏系统行为、泄露数据或违反政策的发现保留“重要”标记。代码风格和命名规范仅属于微小瑕疵（nits）。

## 限制微小瑕疵的数量
每次审查最多报告 5 个微小瑕疵（nits）；其余的汇总为一个统计数量即可。

## 无需报告的内容
src/gen/ 目录下的生成文件，以及 CI（持续集成）已经强制约束的任何内容。

CI/CD 集成与部署

传统流水线运行确定性脚本，任何需要判断的东西都等待人类——分类 flaky test、写变更日志、弄清楚构建为什么坏了；部署和回滚是人在压力下遵循的 runbook。AI 原生的做法是让 Claude 在流水线内非交互式地跑那些判断步骤，在具有有范围凭证的沙箱中；部署工具通过 MCP 暴露给智能体，所以写和测试变更的工作流也能发布它，并在组织为每个环境定义的关卡内回滚它。

• 从只读判断步骤开始：在流水线作业中用 claude -p 分类失败的构建、总结 flaky test、起草变更日志。
• 在现有门后添加写步骤：修复 lint、更新生成的文档、通过 @claude 处理评审评论。智能体写的任何东西作为 PR 经分支保护到达，智能体没有推送到 main 的路线。
• 执行是沙箱化的：智能体作业在带网络策略的容器中运行，使用短期有范围令牌，默认不持有生产凭证。
• 通过 MCP 暴露部署：Deploy、status、rollback 成为按环境限定范围的工具，所以智能体的部署能力是一份允许列表，而不是一段带凭证的 shell 脚本。
• 按环境分层自主性：开发环境智能体自由部署；生产环境智能体准备发布、发布经理授权、hook 强制关卡；Staging 位于中间。
• 回滚应该是流水线中排练最多的路径：一条智能体可以运行的单一命令，并定期在 staging 中演练——因为 Maintain 阶段在控制带被突破时会调用它。

示例 · 流水线步骤

- 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

- name: 诊断失败的构建
  if: failure()
  run: >
    claude -p "读取 out/build.log 中的构建日志。找出最可能的失败原因，
    说明该失败看起来是偶然交替出现的（flaky）还是真实存在的（real），
    并为 PR 讨论串写一份三行的总结。" >> triage.md

节点结构：确定性检测 → σ 分层 → 诊断写成 intent.md

前五个阶段都需要人类启动初始步骤，这个阶段把焦点转移到自主运行 Claude 以关闭循环。它无头运行，在阶段之间有独立的信心关卡——一个确定性检查或对抗性评审智能体，决定前一阶段的输出继续还是升级给人类。

传统 vs AI 原生

闭环的执行步骤

1. 选一个有稳定滚动基线的指标：CI 测试失败率、部署后 5xx 率，或 PR 周期时间。
2. 写检测脚本：通常是滚动窗口上的均值和标准差，带 Western Electric 或类似规则，以便带状同时捕获慢漂移和尖峰。脚本是版本控制和单元测试的，检测保持完全确定性，不涉及模型。
3. 在版本控制配置中定义响应层级：1σ 只记录；2σ 调用 Claude 只读诊断；3σ Claude 可以行动，但只能通过打开 PR 进入评审关卡、或触发预先批准的 runbook。
4. 触发层可以是 GitHub/GitLab 中的计划工作流、来自现有监控栈的 webhook，或网络内的 Cron Job。Claude 无状态运行——作为 CI runner 上的非交互式步骤，或沙箱容器中的 Agent SDK 服务。因为运行是无状态且非交互式的，循环可以在没有人启动的情况下开始和结束。
5. 智能体把诊断写成 Stage 1 格式的 intent.md：异常及其证据、提议结果、受影响的系统、开放问题。从那里，发现像其他任何东西一样通过流水线。
6. 服务所有者或 on-call 工程师分类队列，把面向产品的发现路由给产品负责人。现在修复、安排或驳回。驳回调优带状并帮助减少噪音。
7. 当修复发布时，为该事件添加一个 eval（回到 Test 阶段的持续 evals play），确保此类问题在未来受到保护。

示例 · 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] }

指标：ci_test_failure_rate（CI测试失败率）
基线：rolling_30d（近30天滑动窗口）
规则：western_electric（韦斯特电信号码规则/控制图规则）
层级：
  1sigma：{ 动作：记录日志 }
  2sigma：{ 动作：故障诊断,
            工具："Read,Grep,Bash(gh run view *)" }
  3sigma：{ 动作：提出方案/建议,
            路由：[拉取请求, 运行手册:回滚部署] }

三个典型闭环例子

计划扫描与 on-call

安全扫描是关于特定模型下代码库的时间点陈述，两半都会过时：代码每周变化，每一代模型都发现前一代错过的漏洞。AI 原生的答案是按计划运行扫描，调用路径中没有人类，并把它发现的内容通过与任何其他代码库变更相同的关卡发送。

10控制体系：skill / hook / 沙箱的三层分工

整份 playbook 里最容易被误读的一点，是把 skills 当成「策略执行器」。原文的定位很明确：skill 是建议性控制，hook 是它背后的确定性层。分不清这两者，就会得到一堆「写了标准但没人遵守」的装饰。

常见误配与症状

11度量体系：每个阶段都必须成对度量

playbook 为每个阶段都同时给出前置指标与后置指标，这不是凑数。只给前置指标，团队会优化过程而不优化结果；只给后置指标，反馈太慢、无法在一周内纠正。

度量成对出现，是为了让「过程变快」这件事必须同时证明「结果没变差」。

12采纳路径：从任何无前置的 play 开始

Plays 是非线性的。采纳顺序 ≠ 阶段顺序——依赖图决定的是「先采用哪些」，不是「先做哪个阶段」。

原文的规则很干脆：从任何没有箭头指向它的 play 开始——没有任何东西指向它，所以它不需要任何先决条件。对于任何其他 play，指向它的箭头就是需要先采用的 plays。

为什么采纳顺序不等于阶段顺序

一个常见的错误是按 Plan → Design → Build → Test → Deploy → Maintain 的顺序推进。但依赖图说明：CLAUDE.md、skills、hooks 三者都无前置，可以在没有任何流程改造的情况下先落地，并且它们会立刻改善后面所有阶段。反过来，闭环自动化（Maintain）看起来是「第六个阶段」，实际是最后一个能做的——它需要 PR 评审、hooks、CI/CD 回滚路径全部就位。

13反模式清单

以下每条都对应 playbook 中一个明确的机制。用法：找到你已经在做的那些，右边就是修正方向。

14结论与出处

模型和 harness 已经足够成熟，允许组织改变的不只是产生代码的方式，而是整个软件开发生命周期。这种转型把人类判断保持在流程的中心，并考虑大型企业组织的治理和监管要求。

把六阶段串起来看，这份 playbook 实际上在说一件事：当执行变便宜之后，控制的成本结构必须一起改变。传统 SDLC 把控制放在「人的注意力」上——逐行评审、阶段签核、委员会例会。这些控制在人类速度下是廉价的，在智能体速度下是最贵的。AI 原生的答案是把控制从人的注意力搬到可执行的配置里：约定进 CLAUDE.md，策略进 skills，硬约束进 hooks 与托管设置，判断进关卡——而人只在关卡上出现。

资源清单（大致按推出顺序）

原文给出的平台团队设置清单，按 rollout 顺序排列：

1. 组织级 Claude Code 安装——管理员决策图 —— code.claude.com/docs/en/admin-setup
2. Settings 参考与优先级（含全部 managed-only key） —— code.claude.com/docs/en/settings
3. 从 Claude 管理控制台下发服务端托管设置 —— code.claude.com/docs/en/server-managed-settings
4. Permissions —— code.claude.com/docs/en/permissions
5. Sandboxing · OS 级文件系统与网络隔离 —— code.claude.com/docs/en/sandboxing
6. Hooks 指南 —— code.claude.com/docs/en/hooks-guide
7. Hooks 参考 —— code.claude.com/docs/en/hooks
8. Skills —— code.claude.com/docs/en/skills
9. Plugins 与私有 marketplace（skill 与 hook 的组织级分发方式） —— code.claude.com/docs/en/plugin-marketplaces
10. Managed MCP · 集中管控智能体的工具面 —— code.claude.com/docs/en/managed-mcp
11. 企业部署总览 · Bedrock / Vertex / Foundry —— code.claude.com/docs/en/third-party-integrations
12. 企业网络配置 —— code.claude.com/docs/en/network-config
13. 监控（OpenTelemetry） —— code.claude.com/docs/en/monitoring-usage
14. 分析仪表盘 —— code.claude.com/docs/en/analytics
15. Compliance API · 企业活动流、会话检索与删除 —— platform.claude.com/docs/en/manage-claude/compliance-api
16. 安全模型 —— code.claude.com/docs/en/security