前言
最近用 SDD 做了不少需求，整体体验有好有坏，趁这个机会整理一下。
先说优点——SDD 的理念确实不错。先写规范，再生成代码，让 AI 在结构化约束下干活，比 vibe coding 那种"随便聊聊就生成代码"要可控得多。OpenSpec 这类工具还能追溯每次变更背后的意图，听起来很工程化。
但用着用着，问题也暴露出来了。
Token 消耗是 vibe coding 的 3-5 倍
SDD 的核心机制决定了它必然是"重"的。每次代码生成前，需要先处理大量规范文档，结合上下文进行推理，最后才输出代码。实际测下来，token 消耗大概是直接 vibe coding 的 3 到 5 倍。
这不是一个可以忽略的数字，它意味着两件事：
- 成本成比例增加：在 API 计费或企业套餐场景下，SDD 的经济负担远高于普通对话式编程。
- 效率成比例下降：更多的 token 意味着更长的响应时间，对于节奏快的迭代场景，这是一个持续的摩擦源。
文档越来越多，反而没人认真 review
SDD 的核心承诺之一是：通过让用户 review 规范文档，来保证最终代码的稳定性和正确性。
然而现实是，文档的数量本身成为了 review 的障碍。一个中等规模的需求经过 SDD 流程后，可能产生需求文档、设计文档、任务文档、接口规范等一系列文件。面对如此体量的输出，大多数开发者的实际行为是粗略扫一眼，甚至直接跳过。
结果相当讽刺：SDD 生产了大量本应被仔细 review 的文档，但文档的堆积本身反而瓦解了 review 的动力和可能性。规范文档从"质量保障"退化为"走个过场"。
变更追溯：性价比极不稳定
追溯代码变更是 SDD 的另一个卖点，但实践中存在一个两难困境：
- 简单变更走 SDD 流程：为追溯一个小改动而走完整个流程，代价远超收益。
- 简单变更绕过 SDD：变更游离于规范体系之外，追溯性依然归零。
结果是，SDD 的追溯能力只在"复杂到值得走完整流程"的场景下才有意义。日常高频的小改动基本都会绕过，追溯覆盖率极低，体系的完整性被碎片化的现实持续侵蚀。
异常流程缺失，体验容易断裂
以 OpenSpec 为例，官方流程是线性且理想化的：描述需求 → 生成文档 → apply → 归档。
但真实开发过程从来不是线性的。当你在 apply 之后需要追加需求，或直接修改某段代码时，麻烦就来了。
场景一：对话意外中断
apply 之后的补充需求，通常只能通过继续对话来实现。但一旦对话重启或意外切换，新会话无法恢复对 spec 文档的上下文，AI 会直接修改代码而不是先更新规范——spec 与代码就此悄悄偏离。
场景二：单向流程被打破
SDD 的设计哲学是 spec → code 的单向流动，规范是代码的唯一来源。但 apply 之后通过对话进行代码修改，实质上将流程变成了 spec ⇌ code 的双向循环，系统的一致性从这一刻起开始瓦解。
一种可能的缓解方案
针对上述问题，目前探索出一种可能的解法：用AI创建一个名为 opsx-add-requirement 的全局 skill。
参考项目中的skill:opsx-apply。创建如下全局skill，名称 opsx-add-requirement ，功能如下：
如果当前openspec还未apply，则在当前change中继续补充需求，但不执行apply操作；否则先在当前change中补充需求，然后执行apply
这个 skill 能在一定程度上修补流程断裂，但它的存在本身也说明：官方流程对异常路径的覆盖是不足的。
对话驱动导致需求发散，结果不稳定
SDD 通常以对话为载体推进——用户逐步描述需求，AI 逐步完善规范。这种方式看似灵活，实则暗藏风险。
对话天然鼓励发散思维。在来回交流中，用户容易不断追加想法、修改方向，需求的边界变得模糊。AI 接收到的是一系列碎片化的指令，而不是一个完整意图，最终生成的结果往往缺乏整体一致性。
相比之下，先写一份简单但完整的需求文档，再交给 AI 执行，效果要稳定得多。文档迫使思考者在动手之前收敛思路，这个过程本身就是对需求质量的一次过滤。
这是一个反直觉的结论：SDD 的对话式流程，在某些情况下，反而不如一份朴素的文档来得高效。
"模型无关"是个难以成立的承诺
SDD 的愿景之一是构建一套不依赖特定 LLM 的约束规范——规范本身是稳定的，换一个模型照样能跑。
然而现实是，SDD 的实现高度绑定于特定 LLM 的理解能力。以 OpenSpec 为例，整套流程依赖于当前 LLM 对 openspec 文档格式的正确解析和执行。一旦切换到另一个模型，原有的规范文档未必能被正确理解，流程可能直接失效。所谓"模型无关"，在工程实践中几乎是一个美好的假设。
更值得关注的是另一个现象：在实际使用中发现，即使没有 SDD 的约束，直接使用 Claude 等高阶 LLM，模型也能自行推理出项目的架构规范和代码风格，并保持相当高的一致性。如果希望自定义项目级的规范，同样可以通过 AGENTS.md / CLAUDE.md 文件来进行定义，无需依托spec。
这带来了一个难以回避的追问：生成的规范到底是 SDD 带来的，还是 LLM 自身能力的体现？如果是后者，SDD 的"规范约束"究竟在多大程度上是真实必要的？
暴论
上述的相当多的缺陷是本质的且不可调和的缺陷，因此SDD必然昙花一现。
