在已有项目里用 GSD 推进功能时，最容易遇到的不是“能不能跑起来”，而是“跑出来的结果和预期差很多”。仓库文档对这类情况的处理很明确：不要直接重复执行同一阶段，而是按问题类型分流处理。
这套思路很适合中文开发者的实际工作习惯，因为它不是让你死磕一轮完整流程，而是把“偏差、回滚、改规划”拆开，分别处理。
先分清是哪一种问题
1. 还在执行中，发现方向不对
如果任务还没跑完，但你已经看出方向偏了，最稳妥的做法是先暂停：
/gsd-pause-work
它会保存结构化的交接信息，便于后面继续接着做，而不是丢掉上下文硬重来。
如果后面要接着继续：
/gsd-resume-work
这类场景的关键不是“继续跑完”，而是先把现场留住，避免越改越乱。
2. 结果已经出来，但和预想差很多
这时不要急着重跑 /gsd-execute-phase。仓库的用户指南明确说了，执行后如果要改，应该走更有针对性的方式，比如：
/gsd-verify-work N
verify-work 会做人工验收和自动诊断，适合先确认到底是实现偏了、验收标准变了，还是某个细节没做对。
如果问题很明确是实现缺陷，仓库建议用：
/gsd-quick
/gsd-debug
前者适合小范围修正，后者适合系统性排查。
3. 结果已经提交了，但你反悔了
如果不是“修一修就行”，而是你要撤销整段 phase 或某个 plan，仓库提供了安全回滚命令：
/gsd-undo --phase NN
/gsd-undo --plan NN-MM
它的设计重点是安全：会检查依赖关系，并在真正回滚前给确认门。换句话说，这不是暴力删改，而是可控回退。
正确的处理顺序
情况 A：执行偏了，但还没完全结束
推荐顺序：
/gsd-pause-work- 检查当前输出和预期差异
- 用
/gsd-verify-work或/gsd-debug定位问题 - 需要时用
/gsd-quick做定向修复
这个顺序的好处是保留上下文，避免重新开局。
情况 B：执行完了，但结果不满意
推荐顺序：
/gsd-verify-work N- 判断是实现问题还是需求问题
- 如果只是局部问题，用
/gsd-quick - 如果要撤回整阶段，用
/gsd-undo --phase NN
这里最容易犯的错，就是看到结果不对就直接重跑执行阶段。GSD 文档不建议这么做。
情况 C：不是实现错了，是前面的规划就错了
这时候应该回到前置阶段，而不是在执行阶段补洞。仓库提供了：
/gsd-discuss-phase N
/gsd-plan-phase N
如果是范围变化，还可以调整路线图：
/gsd-add-phase
/gsd-insert-phase N
/gsd-remove-phase N
如果是里程碑层面的缺口，则用：
/gsd-plan-milestone-gaps
这说明 GSD 的思路不是“执行失败就硬修”，而是先判断问题出在需求、规划还是实现。
什么时候该用 quick，什么时候该回滚
/gsd-quick 适合这类情况：
- 小修小补
- 配置调整
- 局部 bug 修复
- 不值得重新走完整 phase 的改动
/gsd-undo 适合这类情况：
- 已经提交了错误结果
- 需要撤回整个 phase
- 需要撤回某个具体 plan
一句话区分：
- 想修正，用 quick 或 debug
- 想撤销，用 undo
- 想改前提，回 discuss 和 plan
执行后还能怎么续上
如果你只是临时离开，并不是要否定当前工作，可以先保存交接，再恢复：
/gsd-pause-work
/gsd-resume-work
仓库还提供了：
/gsd-progress
它会直接告诉你当前进度和下一步，适合中断后快速找回上下文。
最后给一个实用判断法
遇到“结果和预想差很多”时，可以先问自己三个问题：
- 是实现偏了，还是需求本身变了？
- 是局部问题，还是整阶段方向错了？
- 是要修正，还是要撤回？
答案如果是“修正”，优先走 verify-work、quick、debug。
答案如果是“撤回”，优先走 undo。
答案如果是“前面就想错了”，回到 discuss-phase 和 plan-phase 重新来。
这也是 GSD 在已有项目里最有价值的地方：它不是只负责“做完”，而是给你一套把做偏的工作安全拉回来的方法。
