GSD 里的 phase：创建、讨论、规划、执行、验证、转场

phase 的生命周期不是"点一下命令就结束"，而是一条完整链路：先进入路线图，再收敛边界，接着研究、规划、执行、验证，最后由内部转场机制推进到下一 phase。这个设计可以在 README.zh-CN.md、docs/COMMANDS.md 和各个 workflow 文件里对上。README.zh-CN.md docs/COMMANDS.md get-shit-done/workflows/transition.md

最关键的一点是：phase 的目标不是"跑完"，而是"按边界交付并被验证"。所以它天然包含正向流程，也包含修正、回退、插队和重排。

标准生命周期

可以把一个 phase 看成 6 步：

1. 创建
2. 讨论
3. 规划
4. 执行
5. 验证
6. 完成并转场

对应的核心命令分别是：

• /gsd-add-phase：把新 phase 追加到路线图末尾
• /gsd-insert-phase：在现有 phase 中间插入紧急工作，使用小数编号
• /gsd-discuss-phase：先把实现决策收敛清楚
• /gsd-plan-phase：做研究、拆任务、做计划检查
• /gsd-execute-phase：按 wave 执行计划
• /gsd-verify-work：做人工 UAT
• 内部 transition：标记完成并推进到下一 phase

仓库明确写了：transition 不是用户命令，用户不应该被引导去执行 /gsd-transition。get-shit-done/workflows/transition.md

flowchart TD A[新增或插入 phase] --> B[讨论边界 /gsd-discuss-phase] B --> C[研究与规划 /gsd-plan-phase] C --> D[并行执行 /gsd-execute-phase] D --> E[人工验收 /gsd-verify-work] E -->|通过| F[phase complete] F --> G[内部 transition] G --> H[更新 ROADMAP / STATE / REQUIREMENTS] H --> I[进入下一 phase] E -->|发现 gap| C E -->|结果不对| J[定向修复 / quick / debug / undo] J --> D B -->|范围不清| B

每一步到底在做什么

1. 创建：决定这个 phase 是否该存在

/gsd-add-phase 用来在路线图末尾追加新 phase。/gsd-insert-phase 用来在中间插入紧急工作，并保留原有顺序；文档里明确说这是给"计划外但必须插队"的工作用的，不是给正常规划兜底的。docs/COMMANDS.md get-shit-done/workflows/add-phase.md get-shit-done/workflows/insert-phase.md

/gsd-remove-phase 则只允许删除未来且未开始 的 phase；如果当前 phase 或已完成 phase 要撤，应该走 /gsd-pause-work 或 /gsd-undo，不能直接删。get-shit-done/workflows/remove-phase.md get-shit-done/workflows/undo.md

2. 讨论：把"想要什么"变成"怎么定义边界"

/gsd-discuss-phase 的作用，是先把实现里真正会分叉的地方问清楚，比如布局、错误处理、内容结构、命名规则、例外情况等。README.zh-CN.md get-shit-done/workflows/discuss-phase.md

这一步不是讨论要不要做新能力，而是只讨论当前 phase 既定范围内的实现方式。路线图定义边界，讨论阶段只负责收敛歧义。

3. 规划：把边界变成可执行计划

/gsd-plan-phase 会做研究、生成计划、再做验证。仓库里把它描述成"研究 + 计划 + 验证"的组合，而不是单纯列任务。README.zh-CN.md get-shit-done/workflows/plan-phase.md

这一层的价值很直接：让后面的执行不是靠临场判断，而是按已经确认过的决策和计划来做。

4. 执行：按 wave 落地

/gsd-execute-phase 会按 wave 执行计划，能并行的并行，存在依赖的就顺序执行。执行结束后会生成 SUMMARY.md、VERIFICATION.md，并在合适的时机推进到完成状态。README.zh-CN.md get-shit-done/workflows/execute-phase.md

执行阶段不是"写完代码就算完"。仓库还要求：

• 按计划提交
• 执行后对照目标验证
• 发现验证债务时给出警告

5. 验证：确认它真的像你要的那样工作

/gsd-verify-work 是人工 UAT。它不只是"看代码对不对"，而是让用户亲自确认结果是否符合预期。README.zh-CN.md get-shit-done/workflows/verify-work.md

这一步很重要，因为自动化能证明"能跑"，但不一定能证明"是你要的"。

6. 完成并转场：这才是真正的收口点

当 phase 的计划都完成，验证也过了，phase complete 会更新 ROADMAP.md、STATE.md、REQUIREMENTS.md，然后由内部 transition 推进到下一 phase。get-shit-done/workflows/execute-phase.md get-shit-done/workflows/transition.md

如果存在未解决的验证债务，仓库会提醒 ，但不一定阻断转场。这意味着"完成"不是假装没有问题，而是把问题显式带到下一轮管理里。get-shit-done/workflows/execute-phase.md

三种常见异常：错误修复、需求重写、特性增加

错误修复

如果 phase 已经执行完，但结果不对，仓库不建议直接重复跑 /gsd-execute-phase。更合理的顺序是：

1. 先用 /gsd-verify-work 看问题是否真的成立
2. 局部问题用 /gsd-quick 或 /gsd-debug
3. 需要撤回时用 /gsd-undo --phase 或 /gsd-undo --plan

如果是执行中断，也可以先 /gsd-pause-work，再 /gsd-resume-work 接着做。README.zh-CN.md blog2.md get-shit-done/workflows/undo.md

flowchart LR A[执行后发现不对] --> B[先验收 /gsd-verify-work] B --> C{问题类型} C -->|局部实现偏差| D[/gsd-quick 或 /gsd-debug/] C -->|整段结果错误| E[/gsd-undo --phase 或 --plan/] C -->|只是中断| F[/gsd-pause-work /gsd-resume-work/] D --> G[继续当前 phase] E --> H[回退后重做]

需求重写

如果问题不是实现错了，而是前提本身就变了，那就不要在执行阶段硬补洞。应该回到 /gsd-discuss-phase 和 /gsd-plan-phase，重新收敛需求和边界。blog2.md README.zh-CN.md

更大范围的需求改写，通常意味着 phase 本身也要调整：

• 新能力，追加一个 phase：/gsd-add-phase
• 紧急插队，插入一个 decimal phase：/gsd-insert-phase
• 需求缩水，删掉未来 phase：/gsd-remove-phase

这说明 phase 的生命周期不是固定不变的，它会随着路线图重写而重新编排。

特性增加

如果在做当前 phase 时，突然发现还有一个新能力值得做，仓库的默认态度不是"顺手加上"，而是判断它是否已经超出当前边界。

• 只是当前能力的实现细化，留在原 phase
• 是新的独立能力，放进新 phase
• 是中途必须插入的紧急工作，用 decimal phase

这也是为什么 /gsd-add-phase、/gsd-insert-phase、/gsd-remove-phase 要分开存在：它们分别对应"新增""插队""删减"三种不同的生命周期变化。docs/COMMANDS.md docs/FEATURES.md

一句话判断法

遇到 phase 相关问题时，可以先问三个问题：

1. 这是实现错了，还是前提错了？
2. 这是局部修复，还是整段回退？
3. 这是继续当前 phase，还是该重写路线图？

如果答案是"修复"，走验证、quick、debug、undo。 如果答案是"重写"，回到 discuss 和 plan。 如果答案是"新增能力"，开新 phase。

结论

phase 的生命周期，本质上是一个"从边界到交付，再从交付回到路线图"的闭环。它不是线性执行器，而是一个带有讨论、规划、执行、验证、回退、插入、删除和转场能力的状态系统。真正重要的不是跑完某一步，而是每一步都能为下一步提供可验证的上下文。