前几周，GitHub 的 spec-kit 在社区火得一塌糊涂。
30k+ stars，各种技术博主推荐，仿佛找到了 AI 时代软件开发的圣杯：Spec-Driven Development (SDD)。
我也兴冲冲地上手试了几周。
结果？大失所望。
实操后的第一感受：太啰嗦了
说实话，这个 workflow 比 kiro 还啰嗦。
一个简单的需求，走完完整流程：
- 📝 写 Feature Spec（需求规格）
- 🔍 Clarification（澄清环节）
- 📋 Review & Acceptance Checklist（验收检查）
- 🏗️ Generate Plan（生成技术方案）
- 🔬 Research（技术调研）
- 📦 Implementation Details（实现细节）
- ✅ Validate Plan（验证计划）
- 🚀 Implementation（实现）
看起来很"专业"，对吧？
问题是：产出了一堆文档，实际代码还没开始写。
文档屎山来了
用 spec-kit 做了几个需求后，项目目录变成了这样：
specs/
├── 001-create-taskify/
│ ├── contracts/
│ │ ├── api-spec.json
│ │ └── signalr-spec.md
│ ├── data-model.md
│ ├── plan.md
│ ├── quickstart.md
│ ├── research.md
│ ├── spec.md
│ └── tasks.md
├── 002-user-authentication/
│ ├── contracts/...
│ ├── data-model.md
│ ├── plan.md
│ └── ...
└── 003-...
每个需求 7-8 个文档。
做 10 个需求，就是 70-80 个文档。
更糟糕的是：这些文档很快就会过时，代码改了，文档谁去更新？
这不就是传统软件工程最大的痛点吗？怎么到了 AI 时代又回来了？
为什么有人觉得 SDD 很好？
冷静下来想想，SDD 也不是完全没道理。
本质上，这是"磨刀不误砍柴工"：
- Pre-AI 时代，我们也会拆解需求
- 也会做技术调研
- 也会写技术方案（或者在脑子里）
- 也会拆解成任务放到 Jira、禅道
功夫花在需求实现之前，效果确实会好。
这也是为什么 Cursor 的 Plan Mode 效果好的本质原因：
- 先思考
- 再行动
- 避免盲目写代码
但 SDD 的问题在哪？
1. 过度形式主义
SDD 把"规划"这件事形式化了。
不是说形式化不好，而是过度形式化让人看不清事情的本质。
就像公司里的各种流程：
- 最开始是为了解决问题
- 后来变成了为了走流程而走流程
- 最后大家只记得填表，忘了为什么要做这件事
典型的工具主义陷阱。
2. 任务拆解过细
spec-kit 和 kiro 都有这个问题：
一个简单需求，能拆出 70-80 个任务。
简直好笑。
日常我们不是那样做需求的。
你见过哪个工程师真的会把"创建一个登录表单"拆成：
- 创建 HTML 结构
- 添加 CSS 样式
- 写 input 字段验证
- 写 submit 按钮逻辑
- 连接 API
- 处理错误
- 添加 loading 状态
- …
这不是计划，这是八股文。
3. 文档幻觉
SDD 的一个卖点是：文档能跟上代码变化。
听起来很美好。
但现实是：
- 代码改了 10 次
- 文档改了 2 次
- 最后文档还是旧的
而且到了 AI 时代，这个问题的解决方案变了：
我们不需要手写文档，AI 可以从代码提取文档。
- 想知道这个函数做什么？问 AI
- 想知道这个模块的架构？问 AI
- 想知道 API 接口？问 AI
实时、准确、永不过时。
谁还维护静态文档？
商业现实：速度 > 文档
还有一个很多人忽略的点：
在商业世界中，文档并不重要。
重要的是：
- ✅ 能不能快速验证想法
- ✅ 能不能快速交付功能
- ✅ 能不能快速响应市场
创业公司不会因为"文档写得好"而成功。
会因为"产品迭代快"而赢得市场。
SDD 的完整流程，一个需求下来，可能需要：
- 📝 写文档：2 小时
- 🤖 AI 生成计划：30 分钟
- 🔍 Review 计划：1 小时
- 💻 实现：3 小时
总共 6.5 小时。
如果直接写代码：
- 💻 实现：2 小时
- 🧪 测试：1 小时
总共 3 小时。
你愿意选哪个？
SDD 不是一无是处
冷静点，我也不是完全否定 SDD。
它确实有一些可取之处：
1. EARS 语法
在规范需求描述时，EARS（Easy Approach to Requirements Syntax）语法很有用：
When [触发条件]
The system shall [系统行为]
比模糊的"系统应该能够…“清晰多了。
2. 规范的 Workflow
SDD 提供了一个相对规范的开发流程模板。
对于新手或者没有流程的团队，有参考价值。
3. 强制思考
走一遍 SDD 流程，强制你在写代码前把需求想清楚。
这本身是好的。
我的建议
折腾了几周，我的结论是：
❌ 不要在大需求上用 SDD
- 会产生文档屎山
- 维护成本极高
- 实际价值有限
✅ 在细小需求上用 SDD 没问题
- 需求范围小，文档少
- 容易维护
- 快速验证
✅ 坚持 KISS 原则
KISS = Keep It Simple, Stupid
- 不要为了形式而形式
- 不要为了工具而工具
- 不要为了文档而文档
✅ 坚持本质：程序 = 数据结构 + 算法
永远跟踪这条主线：
- 数据怎么存？（数据结构）
- 逻辑怎么处理？（算法）
- 接口怎么暴露？（API）
搞清楚这三点，代码自然就清晰了。
不需要 80 个文档告诉你怎么写代码。
最后
Spec-Kit 的走红，某种程度上反映了 AI 时代的焦虑：
我们该如何与 AI 协作？
有人觉得需要更严谨的流程，于是有了 SDD。
有人觉得需要更智能的工具，于是有了各种 AI Agent。
但本质上，好的软件工程实践没有变：
- 理解需求
- 设计方案
- 实现代码
- 测试验证
- 持续迭代
不要因为 AI 的出现，就忘了这些基本功。
工具是为了让我们更快，不是让我们更慢。
如果一个工具让你产出大量文档，却没有产出更好的代码，那它就是在浪费时间。
Spec-Kit，不是不好，只是被过度神化了。
链接
你用过 spec-kit 吗？体验如何？欢迎在评论区聊聊 💬
#AI #开发 #工具 #吐槽