SDD 工作流 - HAC's Blog

这是 sdd-riper-one 中给出的推荐工作流：

标准流（中大型任务）：
- create_codemap -> build_context_bundle -> sdd_bootstrap -> Research -> (Innovate, 可选) -> Plan -> Execute -> Review
快速流（小任务/需求模糊）：
- sdd_bootstrap -> （按需补）create_codemap/build_context_bundle -> Research -> Plan -> Execute -> Review
关键门禁：
- 首版 spec 落盘前，不进入后续实现阶段。
- 最终目标和当前任务单元未写清前，不进入 Plan。
- 未收到精确字样 Plan Approved，禁止进入 Execute。
- Review 不通过，必须回到 Research/Plan 闭环修正。

这里的工作流是指我需要按这个流程去和 Agent 对话，还是已经内置到了这套skills中？

1. 关于该工作流的角色#

那条推荐流程，既是「内置在 skill 里的行为协议」，也需要你在对话里「启用并配合」。

它不是像 CI pipeline 那样自动跑的后台程序，而是一套写进 SKILL.md 的 Agent 行为约束 + 人机协作节奏。Agent 读到 skill 后会按阶段推进；你在关键节点要 批准、纠偏、说 Plan Approved，流程才会继续。

README 里也写得很直白：

更推荐把 sdd-riper-one 当成一种标准控盘工作方式来使用，而不是当成一组必须死记硬背的显式命令。
显式命令是能力接口，不是唯一入口。

所以：我们不必逐字背 create_codemap -> build_context_bundle -> ... 这条链；更重要的是理解「先 spec、先批准、再改代码」这套习惯。命令名只是 skill 内部给 Agent 用的「动作标签」。

2. 这套 skills 到底是什么？#

可以把它理解成 给 Agent 看的操作手册，不是可执行程序：

组件	作用
`SKILL.md`	运行内核：硬规则、阶段、门禁
`references/`	模板、诊断、按需加载的长规则
`examples/`	脱敏后的 spec / codemap 样例
`AGENTS.md`	项目级路由：默认用哪个 skill

Agent 被 显式点名（如「请使用 sdd-riper-one」）或通过 AGENTS.md 路由后，会读这些 Markdown，并按其中规则行动。

3. 初学者怎么用？（最短路径）#

第一步：选 skill#

面临的情况	用哪个
日常开发、任务已基本清楚、想低打扰	`sdd-riper-one-light`（默认）
需求乱、新手、高风险、要审计留痕	`sdd-riper-one`
陌生/大型代码库	先 `codemap`，再进上面两个之一
长对话要交接	`new-chat-ready`

第二步：用「工作方式模板」开对话#

不必先记 RIPER 各阶段名。直接这样开：

1
请使用 sdd-riper-one-light 处理这个任务，先不要直接改文件。
2

3
请先给我：
4
- 你对任务的理解
5
- 本轮核心目标
6
- 最小 spec / summary
7
- Done Contract：什么算完成，由什么证明
8
- 下一步动作
9
- 风险
10
- 验证方式
11

12
我批准后再执行。

如果用重型版，把 sdd-riper-one-light 换成 sdd-riper-one 即可。

第三步：你只需做三件事#

给任务时带上：目标、范围、约束、验证方式（哪怕很粗）
在 checkpoint 处审批：Agent 给出 spec/plan 后，你看懂再批准；重型版进 Execute 前需回复 Plan Approved
用证据验收：测试、日志、手测通过才算 done，不靠 Agent 自己说「完成了」

4. 那条工作流具体指什么？#

这段：

1
标准流：create_codemap -> build_context_bundle -> sdd_bootstrap
2
        -> Research -> (Innovate) -> Plan -> Execute -> Review

可以拆成两层理解：

4.1 对 Agent：内置的行为协议#

create_codemap / build_context_bundle / sdd_bootstrap：skill 里定义的 Pre-Research 动作名，Agent 在 Research 前按需执行（建代码索引、汇总需求、产出首版 spec）
Research → Plan → Execute → Review：RIPER 阶段状态机，写在 SKILL.md 里，Agent 应遵守
门禁（如「没 Plan Approved 不改代码」）也在 skill 里，Agent 读到就应阻塞

4.2 对你：协作节奏，不是你要手动执行的脚本#

你 不需要 每轮输入 create_codemap 或 sdd_bootstrap。口述需求、贴 PRD、说「先收敛任务别改代码」就够了，Agent 会按 skill 自行决定何时建 codemap、何时写 spec。

你需要参与的是人类侧的控制点：

1
首版 spec 落盘前     → 不进入实现（Agent 应停，你审 spec）
2
目标/任务单元未写清 → 不进入 Plan（你补充或纠正）
3
未收到 Plan Approved → 禁止 Execute（你明确批准）
4
Review 不通过        → 回到 Research/Plan（你决定是否继续）

5. Light vs One：流程差异#

	`sdd-riper-one-light`	`sdd-riper-one`
流程形态	checkpoint 驱动，不强制展开 RIPER 文本	显式 RIPER 阶段 + 更完整 spec
你的负担	较低：批准 + 验收即可	较高：更多 checkpoint、`Plan Approved` 字面批准
适合	熟练用户、任务已较清楚	SDD 初学者、复杂/高风险任务

作为 SDD 初学者，若任务不小或边界不清，建议先用 sdd-riper-one 练习惯；熟练后可切 light 减负。

小结#

Skills = Agent 的行为协议文档，不是自动运行的引擎
工作流 = Agent 内置应遵循的阶段 + 你配合的审批节奏
你不必背命令链；用启动模板开对话，在 spec/plan 处批准，用证据验收即可
重型版 Execute 前必须你回复 Plan Approved，这是少数需要你「精确字样」的门禁之一

音乐

音乐