Spec-driven Development
OpenSpec
An open-source spec-driven development workflow for turning ideas, changes, and agent work into proposals, specs, tasks, and reviewable implementation plans.
- 价格
- Open source
- 平台
- Docs, CLI, Git, Agent workflows
我的判断
OpenSpec 值得放进 Coding Agent Tools，因为下一阶段的瓶颈不只是模型能力，而是团队能不能把 agent 工作变成持久的 spec、任务计划和可 review 的决策。
我的实际判断：OpenSpec 不是 Cursor、Claude Code、Codex、OpenHands 或 Aider 的替代品。它是让这些工具减少即兴发挥的结构层。如果你的 agents 经常忘记原始目标、重复打开旧决策、或者没有验收标准就产出 patch，那么 OpenSpec-style SDD 就是缺失层。
它解决什么
OpenSpec 最强的地方，是给变化建立项目记忆。真正有用的产物是 proposals、specs、tasks、acceptance criteria 和 review questions。这很适合 AI coding，因为 agents 需要的不只是一个 prompt，而是跨会话稳定存在的 single source of truth。
在 Coding Agent Tools 的语境里，关键 skills 是 Strategic Advisor 原任务清单、prototype-to-SDD 顺序计划、README/OpenSpec project 索引、AI orchestration safety 文档。这些产物会让后续工具更可靠。
适合谁
- 把产品意图转成 spec-driven development 的团队。
- 想把原型转成可维护任务的人。
- 希望 README、决策、specs 和实现计划保持连接的项目。
- 在执行前需要给 coding agents 提供稳定上下文的工作流。
- 需要给多 agent 或 MCP-heavy 工作流写安全边界的团队。
不适合谁
- 快速内联代码修改。
- 一次性自动补全工作流。
- 不愿在首轮实现后继续维护 specs 的团队。
如何连接到 Coding Tools
先用 OpenSpec，再用 Claude Code、Codex、Cursor、OpenHands、Gemini CLI、opencode 或 Aider。让 OpenSpec 定义要改什么、为什么改、什么算完成、哪些文件或系统不在范围内。再让 coding agent 按这个契约实现。
Coding Agent Tools 结论
只要 agent 混乱带来的成本高于写一份短 spec 的成本，我就会加入 OpenSpec。最好的信号是：proposal、任务清单、实现 diff 和验证输出讲的是同一个故事。