这份 playbook 的可评估部分不在「用 AI 写代码」，而在它给出的四层控制、一条审计链、一套控制带触发规则，以及一张按依赖而非按阶段排的采纳图。以下按这些结构重排。
“Code is no longer the bottleneck — the human-speed steps around it are.” 代码不再是瓶颈，瓶颈是它周围那些按人的速度运行的环节。
推论是结构性的：如果生成环节的成本趋近于零，那么规划、评审、测试、发布这些仍按人速运行的环节就依次成为新的约束，而它们过去被设计成串行且低频，正是因为生成环节昂贵。
六个阶段名保持不变（Plan / Design / Build / Test / Deploy / Maintain），但被重述为非线性的：每个阶段产出一份进了版本库的产物，产物触发下一阶段，最后一个阶段产出新的 intent.md 回到第一个阶段。
| 阶段 | 产物 | 该阶段被重新设计的点 |
|---|---|---|
| Plan | intent.md | 意图直接落成机器可读文件：要什么、为什么、在什么约束下。度量点是「从对话到产物提交」的时长，原文给的预期是从数周降到数小时。 |
| Design | spec.md | 需求与设计合并为一次会话，组织策略以 skills 形式作为约束参与，存疑处被显式标记。 |
| Build | plan.md CLAUDE.md | plan mode 把「设计评审先于编码」变成流程强制项；CLAUDE.md 承载约定、命令、架构、常见错误，原文建议控制在一页内。并行会话经由 git worktree，起步建议两到三个。 |
| Test | 通过的检查 | 校验收敛为单条命令，会话在反馈回路里自迭代到通过再交人。UI 类工作给出浏览器与截图能力，原文称通常两三轮。持续 eval 建议用 20 到 50 个真实任务作为套件，用于回归 agent 配置的改动。 |
| Deploy | REVIEW.md 已合并 PR | 机器评审分层执行（bug / 安全 / 合规），findings 按严重度排序，人的评审收缩到高风险代码；hook 充当审批闸门；claude-code-action 承载非交互 CI/CD；MCP 以受限权限暴露发布工具。原文建议 nit 每次评审不超过五条。 |
| Maintain | bands.yaml 新 intent.md | 确定性探测脚本（Western Electric rules）按偏离程度分级触发；诊断结论写回 intent.md 重启流水线；Claude Tag 承载 Slack / Teams 的值班响应；Claude Security 做排期扫描并在上报前先做验证。 |
这是全篇最值得单独抽出来评估的部分。四层控制在「能否否决」和「谁拥有」两个维度上是分开的，混用会直接导致治理承诺无法兑现。
| 控制层 | 性质 | 作用时点 | 所有权 | 能承诺什么 |
|---|---|---|---|---|
| Skills .claude/skills/ |
建议性 advisory |
代码被写出的过程中 | 领域团队 | 提高合规产出的概率。不构成拦截，因此不能作为控制点写进审计承诺。 |
| Hooks .claude/settings.json |
确定性 deterministic |
动作发生之前 | 平台 / IT | 放行、阻断、或要求人工批准，并留下带判定与时间戳的决策日志。这是可作为控制点的那一层。 |
| 权限与沙箱 | 确定性 | 执行环境边界 | 平台 / IT | 操作系统级隔离加工具限制，按环境分级（dev / staging / production）。 |
| Managed settings | 确定性 | 配置装载 | 平台 / IT，工程师不可覆盖 | 把上面几层的规则本身变成不可协商项——否则控制层与被控制方是同一批人。 |
一条实践边界。原文对生产发布的表述是：agent 可以一路执行到生产这道闸门前，但不能越过它。发布 hook 保持阻断，直到取得发布授权；分支保护要求人工批准才能合入。
“The chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it.”
产物链 intent.md → spec.md → plan.md → PR → 事件记录 自带作者与时间戳，构成主干。除此之外原文点名的证据载体如下。
| 审计问题 | 证据载体 |
|---|---|
| 谁提出、何时提出 | git 提交历史（作者 + 时间戳） |
| 发现了什么、如何处置 | PR 线程中的 findings 与其 resolution |
| agent 实际做了什么 | OpenTelemetry 导出的会话轨迹 |
| 已知漏洞为何未修 | 扫描结果的 dismissal 记录 |
| 某个动作是否被允许 | hook 决策日志（判定 + 时间戳） |
模型部署侧，原文指向 Bedrock / Vertex / Foundry，用于满足企业网络与合规要求。
Maintain 阶段的做法是把统计过程控制的分级响应直接用作 agent 的触发条件。探测是确定性脚本，判定规则来自 Western Electric rules，阈值写在 bands.yaml 里；被触发的动作按偏离程度分三档。
原文明确区分了两件事：“The plays are listed with stage; the arrows give the order to adopt them in. The two are not the same.”
照 Plan→Maintain 的阶段顺序推进，会在 CI/CD 集成和持续 eval 处踩空——它们的前置条件在别的分支上。
| 类别 | 原文列举 | 读法 |
|---|---|---|
| 先行 / 速度 | 想法到 intent.md 提交的时长；intent.md 与 spec.md 的提交间隔（取 git 时间戳）；首次实现即合入的 PR 占比；首次评审到达时长；控制带击穿到进入 triage 队列的时长 |
全部可从版本库与 PR 元数据直接算出，不依赖自陈。这是这套度量能被审计的原因。 |
| 滞后 / 质量 | intent.md 进入 Stage 2 的存活率；spec.md 提交晚于首个 plan.md 的占比（返工识别）；每改动返工轮次；每 PR 评审时长；每人每周合并改动数；CI 失败率的 30 天滚动基线；上线后 5xx 比例；PR 周期时间趋势；同类事件重复率 |
「每人每周合并改动数」必须与返工率同读——原文对此有明示。单看吞吐会把返工计成产能。 |
另有两处结构性提示：仓库需要为 intent/ 与 .claude/（skills / hooks / agents）安排共同归属；对接遗留系统时须选定唯一事实源——仓库、遗留工具、或二者间的显式链接，三选一。
以下问题是读这份 playbook 时留下的，原文没有给出答案。列在这里是为了与上面各节区分开。