很多人第一次看 GSD，会以为它只是“新项目初始化工具”。实际不是。仓库文档明确写了：如果已经有现成代码库，应该先跑 /gsd-map-codebase，再用 /gsd-new-project 让系统理解当前代码库状态。README.md README.zh-CN.md
这意味着，GSD 对已有项目场景是有完整预设的。它不是要求你推倒重来，而是先识别现状，再进入增量交付。
适合什么场景
如果你的仓库已经有业务代码，且你要做的是：
- 增加一个新功能
- 修改现有页面或接口
- 修复一个跨文件的问题
- 在旧项目上继续做下一版迭代
那么 GSD 的工作流是能接上的。仓库里还专门把 /gsd-map-codebase 列为“已有项目支持”功能，用来在 new-project 前分析现有代码库。docs/FEATURES.md README.md
推荐工作流
1. 先做代码库映射
对已有项目，第一步通常不是提需求，而是先盘点代码库：
/gsd-map-codebase
它会并行分析技术栈、架构、约定和风险点。这样后续讨论和规划，不是凭空猜，而是基于现有项目事实展开。README.md
2. 再进入项目初始化或里程碑
如果你要把这个仓库正式纳入 GSD 管理，可以继续：
/gsd-new-project
但要注意，new-project 不是重复初始化器。仓库要求 .planning/PROJECT.md 不存在，否则会阻止重新初始化。docs/FEATURES.md
如果你是在一个已经管理过的项目里推进下一轮版本，则更适合：
/gsd-new-milestone
仓库说明里把它描述为“和 new-project 类似，但面向现有代码库”的下一版本流程。README.md
3. 对单个功能走阶段流程
如果目标是“在当前项目里加一个功能”，通常会走：
/gsd-discuss-phase N
/gsd-plan-phase N
/gsd-execute-phase N
/gsd-verify-work N
其中：
discuss-phase用来收敛实现决策plan-phase负责研究、规划、验证execute-phase负责按计划实施verify-work负责人工验收
这套链路本质上是把“想法”变成“可验证交付”，而不是只生成一份计划。README.md
更适合老项目的配置
仓库提供了一个很实用的开关：workflow.discuss_mode = assumptions。它会先读代码，再基于代码生成假设，只让你修正不对的地方，而不是从头问一遍。docs/CONFIGURATION.md docs/workflow-discuss-mode.md
这对已有项目很有价值，因为老项目通常有：
- 既有命名规范
- 既有模块边界
- 既有架构约束
- 既有历史包袱
如果继续用纯问答式流程，信息收集成本会比较高。assumptions 模式更接近“先读代码，再确认差异”。
小任务怎么走
不是每次改动都值得走完整阶段流。仓库给了 /gsd-quick，适合 bug 修复、小功能、配置调整这类临时任务。README.md
如果你希望更稳一点，可以用：
/gsd-quick --full
它会把计划检查和验证也加进去，适合“改动不大，但不想冒进”的场景。
一句话总结
GSD 在已有项目里的正确姿势是：
先映射现状，再决定是走新项目式的正式建模，还是直接按阶段做增量交付。对老代码库来说，/gsd-map-codebase + assumptions 模式 + 阶段流，是最贴合仓库设计的组合。
如果目标只是一个小修小补，/gsd-quick 更省成本；如果是下一轮正式迭代，/gsd-new-milestone 更合适。
