告别古法编程,AI开发神器OpenSpec

01

    相信大家在 AI 辅助开发中都使用过Vibe Coding的开发方式，在 Vibe Coding 模式下，我们常会遇到以下的问题:

1. 需求缺乏结构化表达，Prompt 不断叠加，语义逐渐混乱，难以复用和维护

2. 相同提示词在不同上下文下可能产生完全不同的实现，生成的结果不可预测

3. 想要修改局部的代码逻，但单常常造成“改一处、坏三处”的惨状

4. 需求信息散步在一长串的问答记录中，团队之间无法协作

      本文将介绍另一种开发范式OpenSpec，帮助大家根据自己的开发场景选择相应的开发范式，高效完成开发任务

02

      Spec-Driven Development（SDD）是一种以“规格（Spec）为核心”的开发范式。在传统的软件工程中，开发的流程通常是：

     其中，设计文档本质上就是一种“规格（Spec）”，在设计文档中通常定义了系统做什么、功能如何实现。

      Spec 驱动开发的关键在于,Spec是系统的“单一真实来源”，可以持续的参与开发过程，它继承了传统软件工程中的设计思想，但做了一个关键转变：从“写文档辅助开发”，变为“用规格直接驱动开发”，并在开发过程中，我们可以在任何阶段修改任何产物。

OpenSpec它主要包含两个核心概念：

1. Specs (openspec/specs/)：当前系统的真实状态。存放现有的功能规范

2. Changes (openspec/changes/)：当你想要修改系统时，你不是直接改代码，而是先创建一个 Change 、Proposal（变更提案）。

03

// 1.终端执行安装命令npm install -g @fission-ai/openspec@latest ( node >=  20.19 )// 2.查看是否安装成功openspec --version// 3.初始化openspec init 

本文我们选择Claude演示，其他工具同理

初始化后生成如下文件结构

初始化 init 后 命令不全，如果需要暴露全部的命令，可以在终端执行

openspec config profile

04

      针对不同复杂度的开发场景，OpenSpec 提供了两种工作流

1. 快速工作流（核心模式）：路径最短、成本低、适合小需求、个人项目

1. 扩展工作流（自定义模式）：适合需要严谨把控的复杂开发场景，更适合团队项目

    OpenSpec遵循Delta specs规范，增量规范会明确标注出新增（ADDED）、修改（MODIFIED）、删除（REMOVED）的需求，降低上下文负担，AI 只需关注变更部分，而不是整个系统；本质上，Delta Specs 将“代码 diff”提升为“需求 diff”。

      开发过程中，你可以通过OpenSpec的CLI命令，随时查看、验证项目状态：

1.列出所有待实现的变更：

openspec list

2.查看某个变更的详细内容：

openspec show 变更名称

3.验证规范格式是否正确：

openspec validate 变更名称

4.打开交互式面板查看项目全貌：

openspec view

05

实例将演示更复杂的扩展工作流

1. 创建需求变更 /opxs:new + 需求详细描述，包括需求目的，需求涉及的带动点、不需要修改的点等

1. /opsx:continue 创建参考文档design.md、task.md，类似软件开发中的系统架构设计和详细设计，生成的文档就是我们之后apply生成代码的唯一参考，如果文档描述有误，我们可以继续continue继续修改，直到满意为止

3./opsx:apply 

根据spec进行需求实现，如果代码需要修改，继续continue修改文档和代码，而不是直接修改代码，openspec是以文档为核心的，这跟我们传统开发有区别

4./opsx:verify 

验证代码实现和task.md是否匹配，生成验证报告，可以查看task任务是否有偏差

5./opsx:verify 

如果代码符合要求，就可以变更归档，变更的信息会同步到spec文件夹对应的模块下，同时changes中也会有本次的变更记录，方便日后回溯

06

适用场景：较复杂的新页面开发、旧页面功能迭代（设计新增加组件、改动点较大的）

不适合场景：小需求（例如样式文案修改）、新页面（功能简单，描述成本较高的需求）、线上问题紧急修复

1.控制变更的粒度

一个变更 具备完整业务闭环，且可独立验证；粒度太大，范围失控，难以评审和回滚；粒度太小，流程成本过高，效率下降，推荐用vibe coding

2.不确定时候先explore

explore不产生任何文件，是0成本的思考工具,适用需求模糊、技术方案不确定、多方案对比

3.好的Spec 审查可以避免数小时的返工

Proposal / Spec / Design 是评审重点，不要把问题留到代码阶段，跳过审查，本质上就是退回 Vibe Coding，文档精简明（50k限制）

看proposal有没有遗漏和多余的内容

specs 需求描述是不是符合完整的场景覆盖

design.md看下技术方案是否合理

task任务分解是否足够清晰

4. Apply 阶段

严格按照 Spec 实现，避免“边写边改设计”

实现前清理上下文窗口，确保 AI 的注意力只聚焦当前 Spec，避免历史 prompt 干扰和上下文污染导致生成偏移

5.及时归档，保持文档代码的一致性

spec 必须始终反映“当前真实系统状态”,变更完成后及时 archive,避免 Change 长期堆积

07

原创不易，如果对你有帮助，帮忙点个关注、赞~

掘金： Mose前端