一、四层各是什么

规格层：写清做什么、验收标准是什么。落到指令文件、任务描述、验收清单。 能力层：agent 能做哪些动作。落到技能、MCP、内置工具。 编排层：谁来调度、什么时候触发、过程放哪儿。落到子代理、钩子、无人值守模式。

治理层：谁能用、出事怎么办。落到插件、权限、审计。 四层是从「想清楚」到「能追责」的一条线。缺哪层，就在哪层出问题——而且症状各不相同。

二、真跑：四个任务逐层判

四个任务：修一个线上小 bug、加一个新接口、批量重构五十个文件、每日巡检出报告。 结果分别要 2、3、4、3 层。没有一个是「默认四层」。 修 bug 只要两层：说清改哪儿（规格）、能读能写（能力）。它不跨模块，不需要隔离。

批量重构一下就顶到四层：跨五十个文件，过程必须隔离，改完还要能追。 所以「要不要上全套」这个问题问错了。该问的是「这个任务在哪个维度上越了界」。

三、层数是哪来的

修 bug：改动一处，错了也能马上回滚。所以不需要编排，也不需要治理。 加接口：要评审、得留记录，于是多一层治理。 批量重构：跨模块，过程必须隔离，于是多一层编排。

每日巡检：定时跑、只读、风险低，编排要、治理可以省。 三条判据：跨模块就要编排；要追责就要治理；只改一处就都不用。

四、少了某一层会怎样

缺规格：改错地方。而且它做得很对——按自己的理解，做得无可挑剔。 缺能力：干不了。它会来回绕，最后绕过工具直接改文件，反而更危险。 缺编排：主线被灌满。中间读文件的过程全堆在主上下文里，后面没空间干活。

缺治理：出了事说不清。不知道谁改的、什么时候改的、改之前是什么样。 四个症状里「缺规格」最难发现，因为结果看起来是成功的——只是不是你要的。

五、推荐的组合方案

日常小改：规格加能力。对话里说清就够，别写进指令文件。 功能开发：规格、能力、治理。加评审和审计，不加编排——改动集中在一个模块里。 批量改造：四层全上。子代理隔离过程、插件分发规则、钩子留审计。

这套组合不是标准答案，是起点。真正要带走的是那个判据：层数跟着越界走。

六、动手 Demo：四个任务各要几层：SDD 生态的四层账

四个任务，按规格、能力、编排、治理四层逐层判断「要不要」。 结果没有一个是四层全上——这件事本身就是结论。

TASKS = [
    (u"修一个线上小 bug", 1, 1, 0, 0, u"改动一处，错了也能马上回滚"),
    (u"批量重构五十个文件", 1, 1, 1, 1, u"跨模块，得隔离过程"),
]
n = sp + cap + orch + gov

实跑输出：

--------------------------------------------------------------------
四个任务各要几层：SDD 生态的四层账
--------------------------------------------------------------------

  前面九章讲的机制，摊在一张图上就是四层：规格、能力、编排、治理。
  不是每个任务都要四层——层数是任务逼出来的，不是标准配置。

  ① 四层各是什么
  --------------------------------------------------------------------
| 层 | 解决什么 | 落到哪些机制 |
|---|---|---|
| 规格层 | 写清做什么、验收标准 | CLAUDE.md、任务描述 |
| 能力层 | agent 能做哪些动作 | Skills、MCP、内置工具 |
| 编排层 | 谁来调度、什么时候触发 | 子代理、Hooks、Headless |
| 治理层 | 谁能用、出事怎么办 | Plugin、权限、审计 |

  四层是「从想清楚到能追责」的一条线，缺哪层就在哪层出问题。

  ② 真跑：四个任务逐层判
  --------------------------------------------------------------------
| 任务 | 规格 | 能力 | 编排 | 治理 | 合计 |
|---|:---:|:---:|:---:|:---:|:---:|
| 修一个线上小 bug | 要 | 要 | — | — | 2 层 |
| 加一个新接口 | 要 | 要 | — | 要 | 3 层 |
| 批量重构五十个文件 | 要 | 要 | 要 | 要 | 4 层 |
| 每日巡检出报告 | 要 | 要 | 要 | — | 3 层 |

  四个任务分别是 2、3、4、3 层。没有一个是「默认四层」。
  修 bug 只要两层：说清改哪儿（规格）、能读能写（能力）。它不跨模块，所以不需要隔离。
  批量重构一下就顶到四层：跨五十个文件，过程必须隔离，改完还要能追。

  ③ 层数是哪来的
  --------------------------------------------------------------------
  - 修一个线上小 bug：改动一处，错了也能马上回滚
  - 加一个新接口：要评审，得留记录
  - 批量重构五十个文件：跨模块，得隔离过程
  - 每日巡检出报告：定时跑，只读，风险低
  所以判据不是「这个任务重要不重要」，是「这个任务在哪个维度上越了界」。
  跨模块 → 编排；要追责 → 治理；只改一处 → 都不用。

  ④ 少了某一层会怎样
  --------------------------------------------------------------------
| 缺哪层 | 症状 | 具体表现 |
|---|---|---|
| 缺规格 | 改错地方 | 它按自己的理解做了，而且做得很对 |
| 缺能力 | 干不了 | 来回绕，最后绕过工具直接改文件 |
| 缺编排 | 主线被灌满 | 中间的读文件过程全堆在主上下文里 |
| 缺治理 | 出了事说不清 | 不知道谁改的、什么时候改的 |


  ⑤ 推荐的组合方案
  --------------------------------------------------------------------
| 场景 | 组合 | 要点 |
|---|---|---|
| 日常小改 | 规格 + 能力 | 对话里说清，别写进 CLAUDE.md |
| 功能开发 | 规格 + 能力 + 治理 | 加评审和审计，不加编排 |
| 批量改造 | 四层全上 | 子代理隔离、Plugin 分发、Hook 审计 |

  ! 四层的划分是这一课对全书的归纳，教材的层级命名可能不同；层数是示意。

①四层：规格（写清做什么）、能力（能做哪些动作）、编排（谁调度、过程放哪）、治理（谁能用、 出事怎么办）。 ②四个任务分别要 2、3、4、3 层。修 bug 只要两层，批量重构才顶到四层。 ③三条判据：跨模块就要编排、要追责就要治理、只改一处就都不用。层数跟着越界走，不跟重要性走。 ④缺规格最难发现——它做得很对，只是不是你要的。缺能力最危险——它会绕过工具直接改文件。

30 秒实验

1. 加一个任务「把日志格式统一改一遍」，重跑一遍。它要几层？和批量重构差在哪？
2. 把「加一个新接口」的治理层去掉，重跑一遍。它变成两层，会缺什么？这个缺口什么时候暴露？
3. 给「每日巡检」加上「可能自动修复」，重跑一遍。哪一层从不要变成要？为什么？

常见误区

1. 什么任务都上四层。小改动上全套，配置成本比收益高。
2. 只做能力和规格。跨模块时主线被灌满，后面没空间干活。
3. 以为治理是「大公司才要的」。要追责就要治理，跟公司大小无关。
4. 缺了规格还以为是能力不够。它做得很对，只是不是你要的。
5. 把层数当成质量指标。层多不等于做得好，只等于这个任务越界多。

最后一节收全书：八种机制放进一次任务里，数一遍它们各在什么时候出场。

• ☐ （本篇完，下一篇 10.8 全局视图：8 种核心机制的协奏）

相关笔记

• 四层架构模型：四层的机制来源
• 全局视图：8 种核心机制的协奏：八种机制各出场几次
• Claude Code 橙皮书 · 索引
• 🐎 Claude Code 实战 · 索引