第 08 课 | GSD 问答 20 题（中）：工作流详解

第二章：工作流详解

每个命令具体做什么、能跳过什么、怎么定制。

Q8：/gsd-new-project 具体做了什么？能跳过吗？

完整流程：

1. 提问阶段：问你项目名称、描述、目标用户、技术约束
2. 研究阶段：并行跑 4 个研究 agent（领域/技术栈/架构/生态），产出 research 文件
3. 需求阶段：基于研究产出 + 你的回答，生成 REQUIREMENTS.md
4. 路线图阶段：把需求按依赖关系排成 Phase，生成 ROADMAP.md
5. 初始化阶段：创建 STATE.md、config.json、CLAUDE.md

能跳过：

• --auto 跳过提问，从当前对话上下文自动推断
• --skip-research 跳过研究（你已经有领域知识时）
• 路线图和需求生成后可以手动编辑

不能跳过：至少需要项目名称和基本描述。

Q9：/gsd-discuss-phase 是跟谁讨论？我能跳过直接写代码吗？

跟 Claude AI 讨论。它扮演"有经验的同事"，问你没想到的问题。

典型讨论内容：

• "你确定要用 eval() 吗？有安全风险。"
• "浮点精度有三种方案，你的场景选哪种？"
• "历史记录最多存几条？为什么不是无限？"

能跳过。直接 /gsd-plan-phase 也能跑。但跳过的风险：

• AI 会自行做决策，可能和你的预期不同
• 后期发现问题要返工

建议：至少对第一个 Phase 做 discuss。后续 Phase 如果简单可以跳过。

Q10：/gsd-plan-phase 生成的计划长什么样？我能修改吗？

计划是 Markdown 文件，存在 .planning/phases/XX/PLAN-YY.md。

典型结构：

## Plan 01：解析器 + 基础运算
- Task 1：实现 tokenize() 函数 [TDD]
  - 红灯：写测试 tokenize("2+3") → ["2", "+", "3"]
  - 绿灯：实现 tokenize()
  - 重构：处理边界情况
- Task 2：实现 shuntingYard() [TDD]
  - ...

可以修改。计划就是 Markdown 文件，随便改。改完后 /gsd-execute-phase 会读新版本。

实用技巧：如果你只想改一部分，不需要重新跑 /gsd-plan-phase，直接编辑 PLAN.md 文件。

Q11：/gsd-execute-phase 会自动提交代码吗？我能控制吗？

默认行为：

• 每个 Task 完成后自动 git commit（原子提交）
• 提交消息自动生成，描述做了什么
• Co-Authored-By: Claude 标注

控制方式：

• --auto：全自动，不问问题
• --interactive：每个 Task 前确认
• --wave N：只执行第 N 波任务（手动控制节奏）
• --gaps-only：只修复验证失败的部分

如果你不想自动提交：用 --interactive 模式，或者执行完后手动 git reset 回退（原子提交让回退容易）。

Q12：Phase 做到一半发现方向错了怎么办？

三个选择：

1. 回退：git log 找到出错前的 commit，git revert 回退。原子提交让每个 Task 可独立回退。
2. 修正：用 /gsd-quick 修改特定文件。不重新走整个流程。
3. 重新规划：重新 /gsd-discuss-phase + /gsd-plan-phase，保留已有代码。

GSD 不怕做错。原子提交 + .planning/ 记录让修正成本低。

Q13：/gsd-verify 和我自己检查一遍有什么区别？

区别在于系统性和客观性。

自己检查：

• 容易遗漏（"我觉得没问题"）
• 容易只看代码，不看目标（代码写了，但没实现需求）

/gsd-verify：

• 读 PLAN.md 里的 Phase 目标
• 逐条检查"这个目标对应的代码存在吗？逻辑正确吗？"
• 生成 VERIFICATION.md：通过/部分通过/未通过，每条有证据
• 不看你"做了几个 Task"，看"目标达成了没有"

类比：自己检查是自测，/gsd-verify 是独立审计。

Q14：什么时候用 /gsd-quick，什么时候必须走完整流程？

/gsd-quick 适合：

• 改一个 CSS 值
• 修一个 bug
• 加一行注释
• 更新文档
• 任何 5 分钟内能完成的事

必须走完整流程（discuss → plan → execute → verify）：

• 新增功能（影响多个文件）
• 架构变更（影响已有代码结构）
• 需求变更（需要更新 REQUIREMENTS.md）

判断标准：这个改动会影响其他部分吗？会 → 完整流程。不会 → quick。