SDD + Harness 四周学习计划 · Week 2 · Day 11（全计划第 11 课）
今日主题：命令循环：spec → story → implement → verify → review → release → phase-close
建议用时：60–90 分钟 ｜ 前置：Day 9 的
.ai/结构（commands/ 的位置与用法）+ Day 10 已装好 harness 的测试仓库输出物：一张七命令循环图 + 每个命令的「输入 / 产物 / 触发时机」速查表
0. 一句话剧透
Day 9 你见过 .ai/commands/ 里有七个 Markdown 文件，今天把它们串成一条命令循环：spec → story → implement → verify → review → release → phase-close。
这套循环的用法是「让 AI 遵循该文件」——每个文件是一份流程说明书（内含 Usage / Inputs / Procedure / Done criteria），你想让 AI 进入哪个阶段，就把对应文件喂给它。sdd-harness 不绑定特定 AI，它靠这七个文件把任何 AI 拉进同一条流水线。
把这七个词当成「开发的生命周期」：从「定契约」到「收尾归档」，每一步都有明确输入和产物——这正是 Day 1 说的「可验证、可回退」。
1. 今日目标（学完你能做到）
- 能按顺序背出七个命令，并说出每个命令在循环里的位置
- 能说出每个 commands 文件的通用四段结构（Usage / Inputs / Procedure / Done criteria）
- 能讲清「让 AI 遵循该文件」是什么用法，以及为什么这能实现 runtime-agnostic
- 能说出开发主循环（spec→story→implement→verify）与收尾（review→release→phase-close）的分界
- 能把命令循环与分支规范 / SemVer 关联起来（squash merge、release 分支、tag）
- 完成实操：精读一个 commands 文件 + 纸上走一遍循环
对应计划 Day 11 主题：命令循环。今天不装任何新东西——你用 Day 10 的测试仓库来读文件、走流程。
2. 学习动线（建议时间分配）
| 步骤 | 内容 | 用时 |
|---|---|---|
| 1 | 打开 .ai/commands/，通读七个文件名与开头 |
10 分钟 |
| 2 | 精读「3」：命令循环全景 + 通用四段结构 | 10 分钟 |
| 3 | 精读「4」：开发主循环 spec → story → implement → verify | 20 分钟 |
| 4 | 精读「5」：收尾 review → release → phase-close | 15 分钟 |
| 5 | 精读「6」：循环与分支/SemVer 的咬合 | 10 分钟 |
| 6 | 实操「7」：精读一个文件 + 纸上走循环 | 15–20 分钟 |
| 7 | 自测「8」+ 打卡 | 10 分钟 |
3. 命令循环全景：七个 Markdown 流程文件
.ai/commands/ 下是七个 Markdown 文件，名字就是循环的阶段：
1
2
spec → story → implement → verify → review → release → phase-close
（定契约）（拆故事）（实现）（验证）（评审）（发布）（阶段收尾）
用法：不是「在终端敲一个命令」，而是「让 AI 遵循该文件」——把这个 Markdown 文件作为流程指令交给当前 AI 会话，AI 就按文件里的步骤走。每个文件都是同一套四段结构：
| 段 | 含义 | 对应问题 |
|---|---|---|
| Usage | 什么时候用这个命令 | 现在该不该进入这个阶段 |
| Inputs | 需要什么输入（文件、信息、前置产物） | 手头有什么才能开始 |
| Procedure | 一步步做什么 | 具体怎么执行 |
| Done criteria | 什么算完成 | 阶段验收标准 |
关键认知：这七个文件就是「流程的具象化」。 换任何 AI，流程不变——因为流程不在 AI 脑子里，在仓库文件里。这就是 Day 9 runtime-agnostic 在「流程层」的落地。
注：本节只给出七个命令的名称、顺序与通用结构；每个文件的逐字内容请以仓库
.ai/commands/实际文件为准（本讲义不逐字引用，细节标「待核验」）。
4. 开发主循环：spec → story → implement → verify
前四个命令构成一次「开发」的主体，和 Week 1 的 SDD 认知严丝合缝：
4.1 spec（定契约）
- 位置：循环起点。
- 做什么：把需求写成 spec，落到
.ai/specs/。这正是 Week 1 你练的东西——七要素、可量化验收、WHAT 不写 HOW。 - 与 Week 1 的接点：你 Day 7 产出的 spec v2（
Day5-spec-<功能名>-v2.md）就是「spec 阶段」的现成素材，Day 13 实操会把它带进.ai/specs/跑三态。 - 触发时机：有需求要开发时（从
BACKLOG.md取出）。
4.2 story（拆故事）
- 位置：spec 之后。
- 做什么：把 spec 拆成可执行的故事/任务单元——对应 Week 1 的「拆任务」环节（Spec-Kit 的
/tasks干的就是类似的事）。 - 输入：已定稿的 spec；产物：若干可独立实现、可独立验收的故事条目。
4.3 implement（实现）
- 位置：故事就绪后。
- 做什么：按故事实现代码，spec 与代码一起进入提交——这正是 Day 10 你被拦的那件事的正确做法（先有 spec，再有代码提交）。
- 守门：pre-commit hook 在
feat/*/feature/*分支检查你碰没碰.ai/specs//.ai/adrs/。
4.4 verify（验证）
- 位置：实现之后、评审之前。
- 做什么：对照 spec 的验收标准（Given-When-Then）验证实现——跑测试、核对行为，把「做完了」变成「有证据地做完了」。
- 对应护栏：Hooks 是「提交时自动守门」，verify 是「人/AI 主动对照验收」。
主循环一句话：spec 定契约，story 拆任务，implement 照做，verify 对账。 这四步和 Week 1 的 SDD 完全同构——harness 只是把它们变成了「可反复执行的文件流程」。
5. 收尾与发布：review → release → phase-close
5.1 review（评审）
- 位置：verify 之后。
- 做什么：对实现做评审——代码是否满足 spec、有没有越界、spec 有没有被绕过。书面审查、记录结论。
- 对应 Week 1：Day 5 让你做的「AI 视角反向通读」在这里升级为团队/流程级的 review 环节。
5.2 release（发布）
- 位置：review 通过后。
- 做什么：走发布流程——
release/vX.Y.Z分支 → squash merge 到main→ 打 tagvX.Y.Z→ back-merge 回develop。 - 版本号：SemVer（
主版本.次版本.修订号）。 - 分支纪律：
main只做发布；日常开发从develop切type/short-description分支，squash merge 回develop。
5.3 phase-close（阶段收尾）
- 位置：循环终点。
- 做什么：关闭当前阶段——归档文档、清理分支、确认 backlog 状态、沉淀复盘。让一个循环「有始有终」，下一个循环从干净的状态开始。
收尾三件套一句话：review 把关质量，release 把东西发出去，phase-close 把账记完。 没有 phase-close，循环会越跑越乱——这是「可回退」的前提。
6. 循环与分支 / SemVer 怎么咬合
命令循环不是悬空的流程，它和 Git 分支模型是一套系统：
| 循环阶段 | Git 侧动作 |
|---|---|
| spec / story / implement / verify | 在 feat/*（或 feature/*）分支上推进；hook 守门 |
| review | review 通过前不合入 |
| release | release/vX.Y.Z → squash merge 到 main → tag vX.Y.Z → back-merge develop |
| phase-close | 清理已合并分支、归档产物 |
- squash merge：把分支上一串提交压成一个合入
develop/main——历史干净，每个合并点对应一个完整功能。 - SemVer：
vX.Y.Z——破坏性变更升主版本，新增功能升次版本，修 bug 升修订号。版本号本身就是「变更契约」。 - main 只发布：保证
main永远是「可发布状态」，这也是一种守门。
到这里，Day 9 埋的线全接上了：
.ai/commands/管「流程」，.ai/hooks/管「守门」，分支规范管「怎么合」，SemVer 管「怎么标版本」——一个循环走完，开发、验证、发布、归档全链路有文档可查、可回退。
7. 今日实操（约 20 分钟）
7.1 精读一个 commands 文件（10 分钟）
打开测试仓库的 .ai/commands/spec.md（或 verify.md），回答：
- 它的 Usage 写了什么场景用？
- Inputs 要求哪些前置输入？
- Procedure 分几步？
- Done criteria 写了几条、分别是什么？
把四段答案记进笔记。如果你读的是 spec.md，会发现它和你 Week 1 学的七要素是同一种东西的「流程化版本」。
7.2 纸上走一遍循环（10 分钟）
选一个你想做的小功能（例如「给测试仓库加一个用户问候接口」），沿七命令在纸上走一遍：
1
2
3
4
5
6
7
spec → 写清：目标、验收（Given-When-Then）、非目标
story → 拆成 2–3 条故事
implement → 每条故事一个提交（在 feat/xxx 分支，spec 一起提交）
verify → 对照验收标准列验证清单
review → 挑一条你之前代码里最可能被 AI 钻空子的点
release → 假设版本 v0.1.0，写 release 步骤（分支/tag/back-merge）
phase-close → 列出要归档的文档和要清理的分支
这张纸就是 Day 13 实操的剧本。今天先「纸上走」，Day 13「真跑一遍」。
自测题
- 七个命令按顺序写出来。（填空）
- 每个 commands 文件的四段结构是什么？各回答什么问题？（简答）
- 「让 AI 遵循该文件」是什么意思？为什么这实现了 runtime-agnostic？（简答）
- 开发主循环是哪四个命令？收尾是哪三个？（简答）
- spec 命令与 Week 1 的什么概念同构？（简答）
- story 命令解决的问题是什么？输入是什么？（简答）
- release 流程的四个动作是什么？（填空：
release/vX.Y.Z→ __ → tag → __） - 判断题：
main分支可以直接做日常开发提交。（判断——正确答案：否，main 只做发布） - 选择题：把一条功能分支的多条提交压成一个合入，叫什么？ A. rebase B. squash merge C. cherry-pick D. fast-forward
- phase-close 不做的后果可能是什么？（开放性简答）
提示：第 4 题——前四后三；第 7 题——squash merge 到 main、back-merge 回 develop；第 9 题——Day 9/10 都出现过这个词。
延伸阅读
- sdd-harness 仓库（
.ai/commands/七个文件的原文在这）：https://github.com/iMark21/sdd-harness - 《SDD 和 Harness：AI 编程的两大支柱》（SDD 完整闭环图与命令式流程的出处）：https://blog.csdn.net/qq_43284469/article/details/164267908
- 《AI 编程可闭环协作·卷三：Harness 与 SDD》（任务单最少内容、书面审查、合并前自动检查——和 review 环节对应，Week 4 精读）：https://juejin.cn/post/7647333934796537919
本工作纸依据《SDD+Harness四周学习计划.md》Day 11 主题编制。整理日期：2026-09-09
