OpenSpec 深度拆解：AI 编程不是让 AI 猜，是让 AI 照着做

经常来 智柴网 的朋友可能早就注意到一个趋势： AI 编程工具越强大，开发者越焦虑。Cursor 越聪明，你越多时间花在 debug 它写的代码上。Claude Code 越能干，你越担心它"自由发挥"改坏你的项目。

问题的根源不在 AI 不够强，而在于人和 AI 对"要做什么"从未真正达成共识。你说了三句话，AI 理解成了三个版本，最后写出来的代码可能是第四个版本。

OpenSpec 就是来解决这个问题的。它的核心理念粗暴而有效：

先写规范，再写代码。Agree before you build.

📦 什么是 OpenSpec

OpenSpec 是 Fission AI 团队推出的规范驱动开发（Spec-Driven Development, SDD）框架。它是一个轻量级的文件系统 + CLI 工具，让开发者在写任何代码之前，先和 AI（以及团队）就"要构建什么"达成一致。

它不是又一个项目管理工具。它是一套**让 AI 从"自由发挥"变成"有据可依"**的规则。

GitHub: https://github.com/Fission-AI/OpenSpec
安装：npm install -g @fission-ai/openspec@latest

🧠 为什么需要 SDD？看看 DORA 的数据

Google DORA 2024 报告有一个反直觉的发现：

• AI 编码助手采用率每增加 25%，软件交付稳定性反而下降 7.2%
• 开发者主观感觉速度提升了 20%，但实际完成时间增加了 19%

为什么会这样？因为传统 AI 编程的模式是：

1. 你提一个模糊需求（"帮我加个用户登录"）
2. AI 自作主张（OAuth2、短信验证、邮箱验证、JWT、Redis Session 全给你上了）
3. 你花了两小时 review 和 rollback
4. 最后发现不如自己手写

OpenSpec 把这个流程改成了：

1. 先写规范（proposal.md → specs/ → design.md → tasks.md）
2. 人和 AI 对齐（确认"这是我们要的"）
3. 按任务列表执行（AI 照着 tasks.md 一条一条实现）
4. 归档和追溯（变更历史永久保存，可审计）

🏗️ 核心工作流：从 Explore 到 Archive

OpenSpec 的工作流设计得非常优雅，核心是四个命令：

1. /opsx:explore —— 先想清楚，再动手

不确定要怎么做？先探索。

你：/opsx:explore
AI：你想探索什么？
你：我想加暗黑模式，但不确定怎么实现最干净。
AI：让我看看你的样式系统...
     最干净的路径：CSS 变量 + 小型主题上下文，
     带系统偏好检测。不需要新依赖。确定范围？
你：Yes, let's do it.

这个阶段是无承诺的——AI 只是帮你分析、提方案，不会动任何代码。你可以随时喊停。

2. /opsx:propose <change-name> —— 生成规范

确定方向后，AI 自动生成一个变更文件夹：

openspec/changes/add-dark-mode/
├── proposal.md    ← 为什么做、改什么
├── specs/         ← 需求规格（验收标准）
├── design.md      ← 技术方案（How）
└── tasks.md       ← 实现清单（可勾选）

每个文件都有明确职责：

• proposal.md：业务意图，任何看这个项目的人都能理解"为什么"
• specs/：验收标准，用 Gherkin 语法（Given/When/Then）描述
• design.md：技术决策，包括架构图、API 设计、数据库变更
• tasks.md：可执行的子任务，AI 照着一条条实现

3. /opsx:apply —— 执行

AI 读取 tasks.md，按顺序实现：

✓ 1.1 Add theme context provider
✓ 1.2 Create toggle component
✓ 2.1 Add CSS variables
✓ 2.2 Wire up localStorage
All tasks complete!

这不是黑盒。每一步你都能看到 AI 在做什么，随时可以打断、修正、回滚。

4. /opsx:archive —— 归档

完成后归档到 openspec/changes/archive/2026-01-23-add-dark-mode/，specs 自动合并到主规范中。

整个变更历史永久可追溯。三个月后你问"为什么当初用 CSS 变量而不是 class 切换？"答案就在 proposal.md 里。

🔧 Delta Spec：变更管理的精髓

传统文档有个致命问题：一改需求就得重写整篇文档。OpenSpec 的 Delta Spec 机制 解决了这个痛点。

你只需要描述"什么在变化"：

• 新增：add-requirement
• 修改：modify-requirement
• 删除：remove-requirement
• 重命名：rename-requirement

变更历史像 Git diff 一样清晰，规范的演进过程完全可追溯。

🛡️ 三层验证：从格式到业务逻辑

OpenSpec 不是只管"写了规范"，它要确保规范是对的。

第三层尤其关键。OpenSpec 能检测功能间的意外交互——比如你的暗黑模式是否会覆盖用户手动设置的主题偏好。

🏪 Stores 功能：团队的共享规范库（Beta）

OpenSpec 1.0 之后引入了 Stores 功能——把规范存在一个独立的仓库中，团队共享。

这意味着：

• 前端团队、后端团队、QA 团队共用同一套规范
• 不同项目之间可以复用 spec 模板
• 变更审批流程可以接入 CI/CD

它不是简单地把 Markdown 文件放在 Git 里。它是一个结构化的规范数据库，支持版本控制、依赖追踪和跨项目引用。

⚖️ 对比：OpenSpec vs Superpowers vs Kiro vs spec-kit

Superpowers 更像是一个完整的 AI 开发工作台，功能大而全。OpenSpec 只做一件事：让 AI 和人先对齐，再编码。如果你已经在用 Cursor/Claude Code，OpenSpec 是零侵入的加法。Superpowers 则是替换整个工作流。

💡 最佳实践：从"Vibe Coding"到"Spec Coding"

1. 聚焦 What，而非 How

❌ 不好的规范：

"实现用户登录，用 JWT，存 localStorage。"

✅ 好的规范：

### Requirement: User Login
用户应能够使用用户名和密码登录系统。

#### Scenario: Successful Login
- **GIVEN** 用户输入有效的用户名和密码
- **WHEN** 用户点击登录按钮
- **THEN** 系统返回认证 token
- **AND** 重定向到用户首页

让 AI 决定技术方案，你只定义验收标准。

2. 保持上下文清洁

开始实现前，清除 AI 的上下文窗口。让 AI 只读 proposal.md 和 tasks.md，而不是在 20 轮对话的碎片中猜你的意图。

3. 小步快跑，及时归档

每个变更应该是一个逻辑单元。不要一个变更里塞五个不相关的功能。完成就归档，保持工作区整洁。

4. 用 /opsx:continue 恢复进度

/opsx:continue add-dark-mode

AI 自动从 tasks.md 读取进度，继续上次没做完的任务。这是长会话的救星。

🎯 一句话总结

OpenSpec 不是一个让你写更多文档的工具。它是一个让 AI 真正理解你的工具。

在 AI 编程时代，最大的瓶颈不是 AI 不够聪明，而是我们从来没有学会如何准确地告诉 AI 我们要什么。OpenSpec 提供的不是约束，而是共同语言——人和 AI 在编码之前，先达成真正的共识。

当规范成为代码的一部分，AI 从"实习生"变成了"照着蓝图施工的建筑师"。而你，终于可以把时间花在真正重要的事情上：定义问题，而不是清理 AI 的烂摊子。

参考链接

• OpenSpec GitHub: https://github.com/Fission-AI/OpenSpec
• 官方文档: https://openspec.dev
• 安装命令: npm install -g @fission-ai/openspec@latest

本文同步发布于 智柴

#OpenSpec #规范驱动开发 #SDD #AI编程 #Cursor #ClaudeCode #开发者工具 #小凯