ARTICLE · 1330755
OpenSpec 之后再无规格文档?聊聊 spec-driven development 的三个流派
先说一个很多人还没反应过来的变化：2025 年之后，"规格文档"这三个字，正在从"项目里没人看的那个 Word"变成 AI 编码里最值钱的东西。
驱动力很简单。AI 写代码的速度已经是人的十倍，瓶颈挪到了你能不能把需求说清楚。一句"帮我做个登录"丢给 agent，出来什么全看运气；而一份写得足够精确的规格，能让十个不同的模型、十个不同的 agent，都朝着同一个目标干活。于是"先写 spec 再写代码"这件事，从老派流程主义者的执念，变成了 2026 年 AI 编码的主流水役——这波操作甚至有了自己的名字：spec-driven development（SDD）。
这个赛道上现在站着三个代表：GitHub 官方的 spec-kit（148,000+ star）、轻量级的 OpenSpec（74,000+ star）、AWS 的商业产品 Kiro。它们看起来都在"用规格驱动 AI"，但底层的设计取舍完全不同——拆开看，正好是三种对同一个问题的不同回答：
规格到底是个一次性流程，还是一份活的资产？
流派一：spec-kit，GitHub 的"四步仪式"
2025 年 8 月 21 日，GitHub 官方把 spec-kit 挂上了自己的组织名下。一年出头，14.8 万 star——这个数字说明 SDD 不是小众玩法，是行业级需求。
spec-kit 的思路是把规格做成一套流程命令。四个命令走完一个功能：
/speckit.specify 描述要建什么 → 生成 spec.md（需求与用户故事）/speckit.plan 补充技术栈与架构决策 → 生成 plan.md/speckit.tasks 拆解成带依赖的任务清单 → 生成 tasks.md/speckit.implement 按任务清单逐个执行，AI 开始写代码它还有一个别的工具很少强调的东西：宪法（constitution）。一个独立于任何单个功能的文件，写项目级的原则——"优先用成熟方案""测试必须先行"之类，每一步生成时都要对着宪法校验。相当于把"团队工程文化"也规格化了。
spec-kit 的哲学可以概括成一句话：SDD 是一种开发仪式。每个功能从 specify 走到 implement，是一个有始有终的流程。文档是流程的产物。
代价也在这里：仪式感意味着开销。改三行代码也要走一遍四步，很多开发者会开始糊弄——spec 随手写写，plan 复制上一次的。流程一旦变成形式，规格就退化成了"给 AI 看的临时便签"。
流派二：OpenSpec，规格是"活文档"
同样是 2025 年 8 月出生（Fission AI，8 月 5 日建仓），OpenSpec 选了另一条路。它抓的核心问题是 spec-kit 们普遍没解决的：代码上线了，spec 怎么办？
传统做法里 spec 是一次性的：功能开发完，spec.md 扔在角落里慢慢过时，三个月后它描述的世界和代码库已经是两个平行宇宙。OpenSpec 的答案是让规格变成持续演进的基线 + 增量变更：
仓库里始终有一套 baseline spec，描述系统"当前是什么样"，这是唯一的真源； 要改功能时，创建一个 change proposal，里面写的是delta specs——用 ADDED / MODIFIED / RENAMED / REMOVED 四种标记，描述"这次变更之后规格会变成什么样"； AI 按提案实施代码，完成后走 archive：delta 合并回 baseline，过时的规格当场更新，永远不会漂移； 全程有 validate（--strict模式下场景缺 WHEN/THEN 直接报错）和verify-change（校验实现和规格是否一致）兜底。
一个 change proposal 里的 delta spec，读起来长这样——注意它不描述系统，只描述"这次变更"：
## ADDED Requirements### Requirement: 批量导出- WHEN 用户勾选超过 100 条记录- THE 系统 SHALL 分片流式导出，30 秒内返回首个分片## MODIFIED Requirements### Requirement: 账户锁定- WHEN 密码连续错误达 5 次- THE 系统 SHALL 锁定账户 15 分钟并发送告警邮件归档时这些 delta 被合并进 baseline——ADDED 的条目写进主规格，MODIFIED 的条目原地替换。规格库的历史，就是一串这样的变更提案，跟代码库的 commit 历史一一对应。
也就是说，spec-kit 把规格当流程票据，OpenSpec 把规格当数据库——每次变更是带事务语义的更新，归档就是 commit。这更像工程师熟悉的那套逻辑：代码库有版本控制，规格库为什么不能有？
轻量是它的另一个取舍：不做 IDE、不做平台，就是个 CLI + 一堆 markdown，即装即用，Claude Code、Codex、OpenCode 这些主流 agent 都能挂。你可以只给一个功能用它，不必全盘接受一套方法论。
流派三：Kiro，AWS 的"平台化打包"
前两个是开源工具，Kiro 是完全不同的物种：AWS 的商业产品（Pro 档每月 19 美元起），2025 年 AWS Summit 发布，口号是"从 AI 编码到 agentic engineering"。
Kiro 把 SDD 做成了完整的产品体验。你输入一个功能描述，它按顺序产出三份文档，每一份都停下来等你审：
- requirements.md
：需求文档，用 EARS 句法写验收标准——"WHEN 用户提交空表单，THE 系统 SHALL 返回字段级错误提示"。句法强制消歧义，比自然语言需求精确一个量级； - design.md
：技术架构、接口契约、数据流； - tasks.md
：原子化的任务序列，每个任务可以独立丢给 agent 执行。
但 Kiro 真正的差异化在两样规格之外的东西：
Steering 文件管项目级约定——技术栈、目录结构、错误处理规范，每次生成代码自动注入。它和 spec 的分工很清晰：spec 管单个功能，steering 管整个项目。
Agent Hooks 管自动化——文件保存、代码提交时自动跑测试、更新文档、扫安全漏洞。相当于把"规格的执行监督"也自动化了。
AWS 的思路很清楚：SDD 不该是一个开发者自己的习惯，而该是团队和组织级的工程平台——有权限、有成本控制、有 IAM/SSO，规格文档成为新人 onboarding 时直接能读的"系统说明书"。这是把 SDD 往企业里卖。
三个流派的对照，一句话说透
有意思的是，这三家的"轻重"和"新旧"是反着的：spec-kit 流程最重、但最有方法论野心；OpenSpec 最轻，却把"规格与代码同步"这个最难的工程问题解决得最干净；Kiro 什么都做了，但你要把整个开发生命周期都交给 AWS。
我的判断：规格文档不会消失，但形态彻底变了
回到标题的问题。OpenSpec 之后再无规格文档？恰恰相反——规格文档会活得比以前好，前提是想清楚三件事。
第一，spec 的本质变了：从"给人读的"变成"给 agent 执行的"。 过去的 PRD 是沟通工具，写完就使命结束；现在的 spec 是机器可执行契约，是 agent 的输入源。这个转变意味着 spec 必须精确（EARS、WHEN/THEN 这类结构化句法会普及）、必须和代码同步（不然 agent 拿着错误地图开车）、必须可校验（validate/verify 这类环节不是附加项，是刚需）。
第二，"写代码前先对齐"这步的价值被 AI 放大了一百倍。 人工时代，需求写错了，开发者会用自己的经验兜底；agent 时代没有兜底，你写什么它建什么。在 requirements 阶段改一句错话只要几秒，等五百行代码生成完再改，就是一个下午——这正是所有三个流派不约而同设置"文档审阅关卡"的原因。
第三，别急着全盘上 SDD。 我的实用建议是按改动风险分层：改个文案、修个小 bug，直接 vibe coding，别立 spec；新功能、跨模块改动、要给 AI 长期维护的代码，先写 spec。规格是杠杆，但杠杆两头都有成本——最小的可用规格，好过一份没人维护的完美规格。
2026 年再看这个赛道，SDD 之争的本质其实不是"要不要写文档"，而是：当 AI 把写代码的成本打到接近零，工程师的不可替代性挪到了哪？ 答案越来越清晰——挪到了"定义清楚要做什么"上。规格文档，就是这个新时代的代码。
工具会换、流派会卷，但这个方向不会回头。
