为什么不用 Spec 框架
以精简、Cursor 原生的方式实践 SDD 理念
核心观点
我们遵循 规范驱动开发（SDD） 理念，但采用精简的、无框架的实现方式。这不是否定框架，而是为了 保持 Cursor 原生体验，提高可控性。
什么是规范驱动开发？
SDD 代表了软件开发范式的转变：
- 规范是真相之源 — 不仅是文档，而是可执行的指南
- AI 参与整个生命周期 — 从规范生成到实现
- 结构化工作流 — 意图 → 规范 → 设计 → 任务 → 实现
热门 Spec 框架
| 框架 | 类型 | 工作方式 |
|---|---|---|
| OpenSpec | 本地优先框架 | 自由度最高，可用本地 LLM（Ollama、LM Studio 等）零成本运行。无统一监控界面。 |
| Spec-Kit | 模板 + CLI + Slash 命令 | 本身不直接调用 LLM，Token 消耗完全取决于接入的 AI 代理。 |
| Kiro Spec | 完整 IDE（基于 VS Code） | 内置规范系统，Requirements → Design → Tasks 工作流。深度集成的 IDE 体验。 |
框架优势
- 结构化指导 — 预定义工作流帮助保持一致性
- 自动化规范生成 — AI 从提示或原型创建规范
- 变更追踪 — 清晰的规范演进历史（尤其是 OpenSpec）
- 多工具兼容 — 与各种 AI 编码助手协同工作
为什么不使用它们
我们拥抱 SDD 理念，但更倾向于精简的、Cursor 原生的实现。
1. 避免工具冲突
Spec 框架引入自己的工作流、命令和约定。与 Cursor 结合时可能出现：
- 职责重叠 — 框架命令 vs Cursor Agent 能力
- 上下文碎片化 — 规范在 Cursor 上下文窗口之外管理
- 工作流摩擦 — 在框架 CLI 和 Cursor 聊天之间切换
2. 保持可控性
通过直接用 Cursor + Rules 实现 SDD 原则：
- 完全可见 — 每个 Prompt 和 Rule 都是显式的、可编辑的
- 迭代优化 — 根据实际结果调整工作流
- 无外部依赖 — 一切都在项目仓库中
3. 与现有工作流集成
使用 Jira、有成熟代码评审流程和文档标准的企业团队，可能发现框架强加的结构与现有实践冲突。
4. 保持简单
Cursor Agent + Rules 已经足够强大。 额外工具意味着：
- 增加学习曲线
- 增加环境复杂性
- 额外的维护负担
我们的精简 SDD 方法
我们将核心 SDD 原则提炼到 Draft-Final 模式：
specs/
├── 001-feature-name/
│ ├── draft.md # 意图捕获（类似 spec 输入）
│ ├── final.md # AI 完善的方案（类似 spec 输出）
│ └── references/ # 支持材料采纳的核心原则：
| SDD 原则 | 我们的实现 |
|---|---|
| 规范优先思维 | 编码前先写 draft.md |
| AI 增强完善 | Cursor 将 draft 完善为 final |
| 结构化工作流 | Draft → 审查 → Final → Code |
| 知识沉淀 | 所有规范提交到 Git |
何时使用 Spec 框架
框架在以下情况下有价值：
- 从头开始 — 没有需要集成的现有工作流
- 独立开发 — 框架提供你可能缺乏的结构
- 学习 SDD — 框架通过示例教授最佳实践
- 需要特定功能 — 如 OpenSpec 的增量变更追踪
总结
| 方式 | 最适合 |
|---|---|
| Spec 框架 | 新项目、个人开发者、学习 SDD |
| 精简方式（Cursor 原生） | 有现有工作流的团队、以 Cursor 为中心的开发 |
SDD 理念无论用哪种方式实现都很强大。我们选择精简路径是为了 保持 Cursor 原生体验、避免工具冲突、完全掌控工作流。
下一步
查看 Draft-Final 模式 了解我们的实现，然后阅读工作流实践了解完整的开发工作流。
最后更新于: