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

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

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

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

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

### 3. `/opsx:apply` —— 执行

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

这不是黑盒。每一步你都能看到 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 不是只管"写了规范"，它要确保规范是**对的**。

| 验证层 | 检查内容 | 作用 |
|--------|---------|------|
| **格式验证** | Markdown 结构、字段完整性 | 确保 AI 能正确解析 |
| **语义验证** | 需求是否可测试、是否矛盾 | 避免"我要一个既快又安全的系统"这种模糊表述 |
| **业务逻辑** | 与现有规范的冲突检测 | 新功能是否会破坏已有功能 |

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

---

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

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

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

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

---

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

| 维度 | OpenSpec | Superpowers | Kiro (AWS) | spec-kit (GitHub) |
|------|----------|-------------|------------|-------------------|
| **定位** | 轻量 SDD 框架 | AI 开发环境平台 | IDE 集成方案 | 规范工具包 |
| **Stars** | ~35k+ | ~24k | 未开源 | 未公开 |
| **锁定** | 无，20+ 工具通用 | 部分锁定 | 锁定 Claude | 部分锁定 |
| **旧项目支持** | ✅ Brownfield-first | ⚠️ | ⚠️ | ❌ Greenfield |
| **学习曲线** | 低 | 中 | 中 | 高 |
| **团队规模** | 个人到企业 | 团队 | 企业 | 团队 |

**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` 恢复进度

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

---

🎯 一句话总结

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

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

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

---

参考链接