AI 编程热潮下，95% 的 Vibe Coding 项目活不过两周。问题根源在于模糊意图产生模糊代码，导致可维护性极差。Spec-Driven Development 通过先写规范再写代码的方式，为 AI 编程提供了新的解决思路，但现有工具是否真正有效？
智能速览
90-95% 的企业 AI 项目未能从试点进入生产环境
仅 6% 的技术决策者完全信任 AI Agent 的输出
五大 SDD 框架各有特色，但都存在过度设计问题
规范的冗长程度与 AI 遵从程度无线性关系
SDD 应在项目工程化阶段引入，而非原型阶段
精华内容
Vibe Coding 的本质是输入模糊意图输出可执行代码，当项目复杂度超过边界时，这种模式便失效了。SDD 试图通过规范约束来解决这一问题，但实践效果如何？
Vibe Coding 困境
2025 年 Andrej Karpathy 创造的 Vibe Coding 概念迅速走红，但现实却很残酷。Rand Group 2026 年调研显示，90-95% 的企业 AI 项目未能从试点进入生产。McKinsey 报告更指出，65% 的企业反馈 AI 生成的代码在原型阶段表现很好，但无法满足生产环境的可维护性要求。Gartner 数据显示，仅 6% 的技术决策者完全信任 AI Agent 的输出。问题的核心在于，当项目复杂度超过一个文件、一个功能的边界时，模糊意图产生的是模糊代码——能跑，但没人知道它为什么这么写，更没人敢改。
五大工具对比
2025 年下半年涌现了至少五个主要 SDD 框架。Spec Kit 是 GitHub 官方工具，拥有 50,000+ Stars，兼容 17+ AI 工具，但被批评生成过多重复 Markdown 文件。OpenSpec 专为已有代码库设计，轻量灵活但缺乏强制约束。Superpowers 深度绑定 Claude Code，通过说服力原则确保 Agent 遵守规范。Kiro 是 AWS 推出的轻量实现，仅生成 3 个 Markdown 文件，但对小 Bug 修复显得过度设计。Tessl 则走得更远，尝试规范即源代码的激进路线。
实践问题暴露
Martin Fowler 团队的 Birgitta Böckeler 指出了 SDD 的三大问题。首先是审查成本问题——审查规范文件比审查代码本身更耗时、更无聊。其次是遵从度问题——规范的冗长程度和 AI 的遵从程度之间没有线性关系，AI 仍会忽视指令或过度执行。最尖锐的是一刀切问题——现有工具都假设每个任务需要完整的 SDD 流水线，但现实中大多数编码任务不需要如此复杂的流程。
数据验证趋势
多个独立来源的数据显示，采用 SDD 的团队中，45% 的代码变更通过规范驱动；团队代码审查时间平均减少 28%；但 37% 的团队反馈文档维护负担过重。这些数据揭示了 SDD 的两面性：确实能提升效率，但也带来了新的负担。SDD 的效果取决于任务复杂度、团队纪律性和工具匹配度三个变量的交叉作用。
正确实施路径
SDD 方向正确，但当前工具集体犯了过度设计的毛病。推荐的正确姿势是渐进式 Spec——原型阶段不要引入 SDD，用流程杀死速度；当项目验证可行性进入工程化阶段，再引入 Spec 约束。对于 Tessl 的 Spec-as-Source 路线应持谨慎观望，Martin Fowler 将其与失败的 MDD 类比，虽然 LLM 消除了某些约束，但非确定性风险仍存在。
SDD 为 AI 编程的可持续发展提供了关键思路，但工具仍需进化。真正的解决方案或许在于智能识别任务复杂度，动态调整规范深度。当 AI 能理解何时需要详细规范、何时只需要简单提示时，Vibe Coding 与 SDD 的矛盾才能真正化解。
