当AI开始"签字画押"再动手：OpenSpec正在改变编程的游戏规则

“为什么 AI 写出来的代码风格每次都不一样？因为它没有一份’规格合同’可以签字。”

一、我被 AI 带崩了三次之后开始认真思考的问题

我最近在用 AI 编程助手写一个项目，前前后后大概一个多月。

第三次崩的时候，我终于坐下来认真想了一下：问题到底在哪？

不是 AI 不够聪明，不是模型不够强，而是——它没有一份持久化的规范来约束它的行为。

每次新开一个对话，AI 就把之前的约定忘得干干净净。同一个需求，它给出了完全不同的两种实现方式。上一次写的 helper 函数，这一次直接重写了一遍——因为它根本不记得上一次是怎么决定的。

这不是 AI 的问题，这是工作流的问题。

Vibe Coding——靠感觉写——在简单任务上很爽，但在复杂项目里，它的代价是上下文腐烂和技术债务快速累积。

我想找一种方式，让 AI 在动手之前先把”要做什么”说清楚、写成文档，然后双方签字、按文档执行。

后来我找到了 OpenSpec。

二、OpenSpec 是什么

OpenSpec 是一个轻量级的”规格驱动开发”（Spec-Driven Development）框架，来自 Fission AI 团队。

它的核心逻辑很简单：在写代码之前，先让 AI 把”要做什么”说清楚，写成文档，然后严格按文档执行。

它不是让 AI 直接写代码，而是给 AI 加了一层规格合约——代码动之前，规范先行。

有意思的是，OpenSpec 的设计哲学是四个词：fluid、iterative、easy、built for brownfield。轻量、迭代、不折腾、优先支持已有代码库。

这四个词我看完就知道——这东西是给”不想被流程绑架”的团队用的。

三、它怎么工作的：三步，提案→执行→归档

OpenSpec 的工作流只有三个核心命令：

/opsx:propose 添加深色模式支持 ↓ 创建变更目录 ↓ /opsx:apply add-dark-mode ← 执行实现 ↓ /opsx:archive add-dark-mode ← 归档，规范合并入 specs/

每个变更都是一个独立目录，里面装着：

proposal.md — 变更提案（what & why）
design.md — 技术设计
tasks.md — 任务列表
specs/ — 对原有规范的增量修改

关键设计：所有相关文档打包在一起，AI 一次性理解全部上下文。

而不是像有些工具那样，把规范散落在多个文件里，AI 要到处找。

四、为什么它值得认真对待

1. 轻量——不需要 API Key，不需要 MCP

OpenSpec 本身只是规范管理层。它不依赖任何 AI 供应商的 API Key，也不需要配置 MCP 凭证。

这意味着什么？

不需要额外付费
不被某个 AI 平台绑定
可以搭配 20+ 种工具使用：Claude Code、Cursor、Codex、Windsurf、Gemini CLI……

这是它最实用的地方——你的规范层和你的 AI 工具是解耦的。

2. 规范即文档——持久化的”规格合同”

/opsx:propose 创建的那些文档，执行完之后不会消失。它们会被归档并合并到 openspec/specs/ 目录，成为项目的持久规范。

这带来一个重要变化：新对话中，AI 可以直接读取规范，理解”这个项目是怎么走到今天的、哪些决定是谁做的、为什么这么实现”。

规范不只是过程的记录，规范本身就是上下文。

3. Brownfield 优先——为已有代码库设计

OpenSpec 官方明确打出旗号：built for brownfield。

这是它和很多规范工具最本质的区别——很多规范驱动工具是从”白板项目”出发的，用在遗留系统上会很别扭，因为它们要求你一次性建立完整的规范体系。

OpenSpec 不一样，它的优先级是：你可以局部引入规范，不影响现有代码结构，规范层不影响 CI/CD 流程。

这对于正在改造一个老项目的团队来说，极其友好。

五、OpenSpec vs Spec-Kit vs Superpowers：我的选型感受

这三个工具我最近都在研究，差异挺大的。

维度	Spec-Kit	OpenSpec	Superpowers
核心范式	规范可执行化	轻量规格层	技能触发
Star 数	82.5K	34.5K	115K
TDD 强制	❌ 不强制	❌ 不强制	✅ 强制
需要 API Key	取决于代理	❌ 不需要	取决于代理
需要 MCP	取决于代理	❌ 不需要	取决于代理
阶段门控	7个阶段门控	无门控，流畅迭代	无门控，技能自动触发
工具支持	11+	20+（最多）	5+
团队协作	✅ 企业级	🚧 开发中	✅ Discord 社区

我的感受：

如果你在大型企业团队，流程严格、质量要可控，选 Spec-Kit
如果你在快速迭代的创业团队，或者在改造已有代码库，选 OpenSpec
如果你对代码质量有执念，需要强制 TDD，选 Superpowers

我自己的话，我会先试 OpenSpec——因为它最灵活，门槛最低，踩坑成本也最低。

六、用 OpenSpec 驱动一个功能变更

说一个具体的场景——给项目添加”记住我”登录功能。

Step 1：发起提案

在 AI 编码助手中输入：

/opsx:propose 为登录功能添加"记住我"选项

OpenSpec 会创建对应目录，里面有提案、设计、任务、规范增量——AI 一次性读完所有上下文。

Step 2：执行变更

/opsx:apply add-remember-me

Step 3：归档，规范沉淀

/opsx:archive add-remember-me

变更目录归档，规范增量合并到 specs/——它成为项目持久规范的一部分，未来的 AI 对话可以直接读取。

七、为什么这个方向值得关注

2026 年，AI 编程正在经历一个范式转移：

从”模型博弈”到”工程化落地”

早期的 vibe coding 靠感觉靠运气；现在开始需要结构、需要规范、需要持久化的”规格合同”。

三个驱动力：

上下文腐烂：项目规模扩大后，AI 需要持久化的规范来维持一致性
多工具协作：团队使用不同的 AI 编码工具，需要统一的规格层作为共享上下文
合规要求：企业项目需要可追溯的决策记录，规范层正好满足这个需求

OpenSpec 站在这个趋势上，定位清晰：轻量、通用、不绑定平台。