从 Vibe Coding 到 Spec-Driven：AI 编程范式的下一次进化

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

39K Star 的 OpenSpec 拆开看：AI 编程的瓶颈早换了——写不出代码？不，是说不清要写什么。

你肯定经历过这种场景：

让 AI 给项目加个暗黑模式。它改了 12 个文件，写了一堆 CSS 变量，搭了一个 ThemeContext。你一看------和你要的不一样。

你说"改一下"，它又改了 8 个文件。这次颜色对了，但 localStorage 持久化没做。你说"再加一下"。它又改了 5 个文件......

三个回合下来，你也不知道当前代码是什么状态了。AI 也不知道。因为需求从头到尾只存在于聊天记录里，越聊越长，谁都对不上。

这就是 Vibe Coding 的天花板：单次输出很强，持续迭代很烂。

前面我写过一篇《vibe coding 不是危机，是前端分工重塑的开始》。当时的判断是：Vibe Coding 会替代"翻译"和"实现"层的工作，但替代不了"理解"和"决策"。

AI 编程的瓶颈变了。代码它能写，但你越来越说不清要它写什么。

它缺的不是能力，是约束。一个白纸黑字的规格：做什么、不做什么、做完怎么验。

于是有了 Spec-Driven Development（规格驱动开发）。

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 仓库和官方文档，项目迭代快，建议以最新版本为准。

从 Vibe Coding 到 Spec-Driven：AI 编程范式的下一次进化

1. Delta Spec：只说变化，不说全部

ADDED Requirements

Requirement: Two-Factor Authentication

Scenario: 2FA login

MODIFIED Requirements

Requirement: Session Expiration