写代码先写规格有用吗？OpenSpec 把规格驱动开发做成了工具

GitHub 仓库

Fission-AI/OpenSpec

总 Stars

★ 74,064

今日新增

+111

主要语言

TypeScript

查看 GitHub 项目

结论先行：Fission-AI 的 OpenSpec 拿了 74,064 个 star，TypeScript，MIT，11 月 5 日还在更新。它把「规格驱动开发」（SDD）做成了一套给 AI 编程助手用的工具，npm 包是 @fission-ai/openspec。README 里那句「text → fluid not rigid → iterative not waterfall」基本就是它的哲学：规格是活的文本，迭代着写，不是瀑布式文档。

它是什么

一套让 AI 先读规格、再写代码的工作流：你把要做什么、做到什么程度写成规格，AI 按规格生成与修改代码，改完再回头对照规格验收。规格和代码放在同一个仓库里一起演进。

它能干嘛

新功能先定规格再动手、需求变更先改规格再改代码、代码评审多一个对照物。对 AI 结对编程尤其有用：模型不再凭空猜你的意图，规格就是意图的书面版。

谁适合用

已经在用 AI 写代码、但常被「模型理解跑偏」折腾的人；带小团队、想让需求与实现对得上号的人。个人小项目也可以试，但规格本身的维护成本要自己掂量。

要注意什么

规格不是写得越细越好：太细等于把代码复述一遍，维护成本翻倍。先从一两个核心功能的规格起步，跑顺了再扩。工具只解决流程问题，规格写得含糊，AI 照样跑偏。

规格驱动和直接让 AI 写代码差在哪？

差在「意图有没有落字为据」。直接写代码时意图只存在你脑子里，模型猜错了你很难定位；规格写下来之后，意图、实现、验收三方都能对照同一份文本，扯皮少一半。

站长点评：七万多 star 说明这套打法戳中了 AI 编程时代的痛点。我的判断是：它适合有明确需求的项目，不适合探索性原型——原型阶段需求天天变，规格的维护成本会先压垮你。