从 Vibe Coding 到 Spec-Driven：AI 编程范式的下一次进化
39K Star 的 OpenSpec 拆开看：AI 编程的瓶颈早换了——写不出代码？不，是说不清要写什么。
Vibe Coding 的天花板
你肯定经历过这种场景：
让 AI 给项目加个暗黑模式。它改了 12 个文件，写了一堆 CSS 变量，搭了一个 ThemeContext。你一看——和你要的不一样。
你说"改一下"，它又改了 8 个文件。这次颜色对了，但 localStorage 持久化没做。你说"再加一下"。它又改了 5 个文件……
三个回合下来，你也不知道当前代码是什么状态了。AI 也不知道。因为需求从头到尾只存在于聊天记录里，越聊越长，谁都对不上。
这就是 Vibe Coding 的天花板：单次输出很强，持续迭代很烂。
前面我写过一篇《vibe coding 不是危机，是前端分工重塑的开始》。当时的判断是：Vibe Coding 会替代"翻译"和"实现"层的工作，但替代不了"理解"和"决策"。
AI 编程的瓶颈变了。代码它能写，但你越来越说不清要它写什么。
它缺的不是能力，是约束。一个白纸黑字的规格：做什么、不做什么、做完怎么验。
于是有了 Spec-Driven Development（规格驱动开发）。
OpenSpec：39K Star 不是偶然
2025 年 8 月，一个叫 OpenSpec 的项目在 GitHub 上线。8 个月后，39,230 Star。NPM 包 @fission-ai/openspec，MIT 协议，TypeScript 写的。
Star 数不说明一切。但 8 个月 39K，这个速度在开发者工具里算顶级了。
它做的事情用一句话说：在 AI 编程助手写代码之前，先让你和它对齐"要做什么"。
核心机制不复杂：
你的项目/
└── openspec/
├── specs/ ← 系统当前行为的真相源
│ ├── auth/
│ ├── payments/
│ └── ui/
└── changes/ ← 每个待做的变更，一个文件夹
└── add-dark-mode/
├── proposal.md ← 为什么做 + 做什么
├── specs/ ← 规格变化（增量）
├── design.md ← 技术方案
└── tasks.md ← 实现清单
使用方式更简单。装好之后，在 Claude Code 或 Cursor 里：
你: /opsx:propose add-dark-mode
AI: Created openspec/changes/add-dark-mode/
✓ proposal.md — 做什么，为什么做
✓ specs/ — 需求和场景
✓ design.md — 技术方案
✓ tasks.md — 实现清单
准备实施！
然后：
你: /opsx:apply
AI: 实施任务...
✓ 1.1 创建 ThemeContext
✓ 1.2 添加 CSS 变量
✓ 1.3 实现 localStorage 持久化
全部完成！
最后：
你: /opsx:archive
AI: 归档 add-dark-mode...
✓ 增量规格已合并到主 specs
✓ 变更已归档
准备下一个特性！
核心流程就三步：propose → apply → archive。
为什么这个思路能跑通
OpenSpec 里有几个设计决策，我觉得是它火起来的关键。
1. Delta Spec：只说变化，不说全部
这是我觉得最聪明的设计。
传统写规格的方式是写一份完整的文档。但 80% 的开发工作是改现有代码，不是从零开始。每次改一个功能就重写一遍规格？没人愿意干。
OpenSpec 的做法是 Delta Spec（增量规格）：只描述这次变更了什么。
# Delta for Auth
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST support TOTP-based two-factor authentication.
#### Scenario: 2FA login
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented
- AND login completes only after valid OTP
## MODIFIED Requirements
### Requirement: Session Expiration
The system MUST expire sessions after 15 minutes of inactivity.
(Previously: 30 minutes)
三种操作：新增 / 修改 / 移除。Archive 的时候自动合并到主 specs。
说白了就一句话：大多数开发工作是改，不是新建。为"改"设计的规格系统，才有意义。
2. 不锁工具，25+ 编程助手通吃
OpenSpec 不绑定任何一个 AI 编程工具。它通过 Skill 机制适配：
| 工具 | 支持方式 |
|---|---|
| Claude Code | .claude/skills/ + /opsx:propose |
| Cursor | .cursor/skills/ + /opsx-propose |
| Windsurf | .windsurf/skills/ + /opsx-propose |
| GitHub Copilot | .github/prompts/ + /opsx-propose |
| Gemini CLI | .gemini/skills/ + /opsx-propose |
| Cline, RooCode, Junie, Codex... | 各自适配 |
一共 25+ 个工具。你用 Claude Code 也行，用 Cursor 也行，甚至用 Gemini CLI 也行。
工具无关这一点很重要。开发者最烦被绑定——"用我的框架、我的工具、我的模型"。OpenSpec 的 specs 就是 Markdown 文件，跟着仓库走。换工具不用重写规格。
3. 棕地优先（Brownfield-first）
大部分软件工作不是从零开始写新系统，是在现有系统上改东西。OpenSpec 的哲学明确写了：
→ fluid not rigid 不搞阶段门槛
→ iterative not waterfall 边做边学
→ easy not complex 轻量级
→ built for brownfield 为现有项目设计，不只是新项目
这四条真不是口号。Delta Spec 就是 brownfield-first 的直接落地——你不用从头描述整个系统，只说这次改了什么就行。
和竞品比，差在哪
规格驱动开发这个赛道不只有 OpenSpec。两个最直接的对比：
vs Spec Kit（GitHub 官方）
GitHub 自己也出了个 Spec Kit。思路类似：先写规格再写代码。
但 Spec Kit 的问题是太重。严格的阶段门槛，大量 Markdown 模板，Python 安装。适合大团队做严格的需求管理，不适合个人开发者或小团队快速迭代。
OpenSpec 更轻。npm install -g 一行装好，openspec init 初始化，直接就能用。
vs Kiro（AWS）
Kiro 是 AWS 的 AI IDE，内置了 spec-driven 的开发流程。但 Kiro 锁死在自己的 IDE 上，只能用 Claude 模型。
你如果用 Cursor + Claude Code 切着用，Kiro 就插不进来。你如果团队有人用 Windsurf，有人用 Copilot，Kiro 也统一不了。
OpenSpec 的优势在这摆着：不绑 IDE、不绑模型。Specs 就是 Markdown 文件，跟着代码仓库走，任何工具都能读。
vs 什么都不用
不写规格，直接让 AI 写代码。大部分个人项目确实不需要。
但当项目超过一定复杂度——多人协作、需求频繁变更、AI 的修改要可追溯——没规格就没约束。AI 写出来的东西你 predict 不了，review 也无从下手。
Specs 不是文档，是约束。有了约束才有可预测性。
我的判断
什么时候该用
- 多人协作的项目。AI 写的代码需要其他人能理解和追溯。Specs 就是上下文。
- 复杂特性的开发。一个特性要改十几个文件、跨多个模块。先把规格定清楚，AI 的输出质量完全不一样。
- 长期维护的项目。每次改东西都能看到"系统当前应该是什么样"和"这次要改什么"，比翻 git log 高效得多。
- 频繁切换 AI 工具。今天用 Claude Code，明天用 Cursor。Specs 跟着项目走，不跟着工具走。
什么时候不需要
- 原型验证和快速实验。你就是想快速看看效果，搞规格是浪费时间。
- 简单脚本和一次性任务。三行代码的事，不需要流程。
- 一个人、一个工具、一个短期项目。上下文全在你脑子里，不需要外化。
最重要的一个认知
OpenSpec 火起来，靠的不是功能多强。它恰好打中了一个很多人都有但说不清楚的痛点：
AI 能写代码了，但我怎么确保它写的是我要的？
模型越强，单次输出越好。但你和 AI 之间的"对齐成本"不会自动降低。
从 Vibe Coding 到 Spec-Driven，没什么革命性的。就是 AI 编程从"能不能写"走到"写对了没有"的自然一步。
文中 OpenSpec 数据基于 2026 年 4 月 GitHub 仓库和官方文档，项目迭代快，建议以最新版本为准。
