追问 GSD-2：六个值得审视的命题

主文勾勒了 GSD-2 作为 "AI 项目经理" 的全貌，但有几个点值得单独拎出来追问。

---

1. 复杂度是否已超过收益临界点？

8 个 internal package + 24 个 extension + Rust workspace + VS Code extension + Web/Studio + Docker。维护这套系统的认知成本，对于普通开发者是否过高？ngjoo.com 的 5K 深度解析直言："设计上有过度工程嫌疑"。当工具的复杂度接近它所管理的项目时，工具本身就成了负担。

这不是说 GSD-2 不应该复杂——大项目 orchestration 本来就需要复杂度。问题是：这个复杂度是必要复杂度还是偶然复杂度？30+ 文件的 auto 子系统里，有多少交叉调用是为了优雅，有多少是为了应急补丁？

---

2. Spec-driven 的"垃圾进，垃圾出"问题

GSD-2 的铁律是：先出 spec，再拆 slice，再执行。这意味着整个系统的上限被初始 spec 的质量严格锁定。

如果 PROJECT.md 里对某个业务逻辑的描述是错的，后续所有 agent 都会在这个错误地基上施工。更糟糕的是，由于 auto 模式的自动化程度很高，错误可能在多个 slice 之后才被发现，届时回滚成本远大于传统开发。

v1 版本的 /gsd:discuss-phase 需要人工澄清灰区，v2 的 discuss-phase 还保留了多少人类介入的强制检查点？还是已经过度依赖 AI 自己澄清自己了？

---

3. SQLite + Markdown + JSON 混合存储的 schema 漂移

.gsd/ 目录同时存在三种存储格式。官方说法是 "DB authoritative，markdown 只是渲染投影"，但运行时 migration 和 CI guards（v2.78 引入）的存在本身就说明：schema 漂移是真实发生过的问题。

这让人联想到早期 ORM 的 migration hell。当状态结构同时服务于：LLM prompt context、人类 review、git history、runtime state 四种场景时，单一 schema 很难同时满足所有约束。GSD-2 的解法是否足够优雅，还是说这只是把问题推迟到了 v3？

---

4. Token 成本与"全自动"的经济学

/gsd auto 的宣传语是 "走开并回来验收成品"。但这忽略了经济学：一个大型 greenfield 项目的 auto 模式可能需要数百次 agent session，每次都要过完整的 context window。

目前没有任何公开的基准测试数据。README 提到 token_profile 节省 40-60%，但没有给出对照基准。对于预算敏感的团队，auto 模式的成本是否可预测？是否存在"半程耗尽预算，半成品无法交付"的尴尬局面？

---

5. Agent 路由：scout / researcher / worker 的分工是否合理

GSD-2 内置了 5 种 agent 角色：scout、researcher、worker、javascript-pro、typescript-pro。但预设的角色体系是否适配所有项目类型？

比如：Rust 后端项目不需要 js-pro/ts-pro，但需要 rust-pro；AI/ML 项目需要 data-science-pro；嵌入式项目需要 embedded-pro。当前的角色体系是否足够 extensible，还是说开发者需要自己写 agent definition？如果是后者，agent 质量又回到了 "garbage in" 的问题。

---

6. 从 gsd-build 到 open-gsd：组织迁移的深层含义

原仓库 gsd-build/gsd-2 已归档，活跃开发在 open-gsd/gsd-pi。这是一个从个人/小团队维护到社区化治理的迁移。

但迁移本身也提出了问题：GSD-2 的 roadmap 是否因此变得更保守？Pi SDK 的依赖关系是否意味着 Anthropic 对 GSD 生态有事实上的影响力？当 core SDK 由商业公司维护、GSD 由社区维护时，两者的节奏 mismatch 会成为长期风险吗？

---

> 千寻 | 追问 GSD-2 的六个命题 | 基于 ngjoo.com 深度解析、ARCHITECTURE.md、agentconn.com 对比评测

#追问 #Agent #Orchestration #GSD