概述
在 AI 驱动的软件开发日益普及的今天,如何让开发者与 AI 助手协同高效、可控地演进项目,成为新的挑战。OpenSpec 是一款 AI 规范驱动开发辅助工具。本文将系统介绍 OpenSpec 的设计理念、核心价值、使用流程,并结合实际案例,帮助开发者深入感受其优势。
一、为什么选择 OpenSpec?
常规 AI 助手问题
- 当需求仅存在于对话历史,AI 助手的输出往往不可控、难以复现,甚至遗漏业务关键点。
- 缺乏规范驱动,代码产出既无法溯源,也难以审核,协作成本高。
OpenSpec 的变革
- 规范驱动开发:将需求以轻量 spec(规范)管理,所有相关方(人和 AI)在编码前达成一致。
- 可审计、可追溯:所有提案、任务、规范变更都结构化存档,方便回溯与迭代。
- 无需 API 密钥,极简配置:绝大多数 AI 工具零门槛集成,无需额外账号或设置。
- 兼容现有 AI 助手:已支持 Claude Code、CodeBuddy、Cursor、OpenCode、Qoder 等主流工具,Slash 命令一键触发。
二、OpenSpec 核心工作流
提出变更提案 Proposal -> 审核与协同 Review & Align -> 实现任务 Implement Tasks -> 归档与更新 Archive & Update
具体步骤
- 拟定变更提案(Proposal):使用命令或 AI 助手创建 spec 更新。如'添加角色搜索过滤'。
- 审核与对齐(Review & Align):多人或 AI 反复修订,完善需求和验收标准。
- 实现任务(Implement Tasks):AI 或人工依规范实现细分任务,确保落地。
- 归档变更(Archive & Update):变更完成后归档,更新'当前规范'(source of truth)。
三、OpenSpec 目录结构与 Delta 规范
openspec/
├── specs/ # 当前项目规范(source of truth)
│ └── auth/
│ └── spec.md
├── changes/ # 所有变更提案及任务
│ └── add-2fa/
│ ├── proposal.md
│ ├── tasks.md
│ ├── design.md
│ └── specs/
│ └── auth/
│ └── spec.md # delta,仅表现变更内容
Delta 格式说明
## ADDED Requirements:新增能力
## MODIFIED Requirements:变更行为
## REMOVED Requirements:移除特性
每个需求必须包含至少一个 #### Scenario: 场景说明,并采用'SHALL/MUST'等强制词。
四、与其他方案对比
| 比较维度 | OpenSpec | spec-kit | Kiro.dev | 无规范 |
|---|
| 项目适用性 | 新功能、旧功能均适合 | 适合新项目(0→1) | 变更易分散 | 难以控管 |
| 需求变更追踪 | 明确、可管理两层结构 | 单层结构易混乱 | 多文件追踪困难 | 容易遗漏 |
| 团队协作与可审计性 | 变更、任务、规范集中结构化管理 | 相对松散 | 结构较为分散 | 无 |
五、快速上手指南
1. 安装 CLI 工具
npm install -g @fission-ai/openspec@latest
确认安装:
openspec --version
2. 初始化项目
cd your-project
openspec init
如选择支持的 AI 助手,自动生成关联命令和 AGENTS.md。
3. 创建变更提案
对话示例:
你:创建一个 OpenSpec 变更,添加'两步验证'功能。
AI:已自动生成 openspec/changes/add-2fa/,包含 proposal.md、tasks.md、spec delta。
4. 方案审核与完善
命令核查:
openspec list
openspec validate add-2fa
openspec show add-2fa
与 AI 交互补全验收标准、细化业务场景。
5. 实现变更任务
AI 辅助自动实现 tasks.md 列出的所有技术任务。例如:
- 数据库新增字段
- 后端实现 OTP 接口
- 前端集成验证码组件
6. 归档上线
openspec archive add-2fa --yes
自动将变更整合入 specs/,归档成功。
六、团队协作与升级维护
- 新成员只需
openspec init 即可接入标准流程。
- 每个变更会被规范归档,方便持续演进。
- 灵活兼容多种 AI 助手,团队成员可自由切换。
openspec update 一键刷新命令与指导。
七、实例:用 OpenSpec 落地'两步验证'功能
- 创建 change 提案(增加 2FA)
- 设计 Delta,新增'OTP 登录'
- 生成 tasks.md(如'数据库设计'、'接口实现'、'前端集成')
- 审核落地,归档变更
通过规范驱动,每一步都可复查、回溯,并且支持跨角色、跨工具协同。
实例细化:用 OpenSpec 规范驱动'添加两步验证(2FA)'功能
场景背景
假设你正在开发一个 Web 系统,希望为用户登录新增'两步验证'(OTP/动态验证码),提升安全性。你使用 OpenSpec,让 AI 与团队协同推进需求落地。
步骤一:创建 2FA 变更提案
自动生成目录结构
openspec/
├── specs/
│ └── auth/
│ └── spec.md # 现有登录/认证规范
└── changes/
└── add-2fa/
├── proposal.md # 为什么要加 2FA?改动内容说明
├── tasks.md # 具体实现任务列表
├── specs/
│ └── auth/
│ └── spec.md # 只包含新增/变更内容(Delta 规范)
└── design.md # 技术方案、架构决策(可选)
指令对话/命令行
/openspec:proposal add-2fa
或
openspec init
openspec list
步骤二:细化需求与验收标准
specs/auth/spec.md(Delta)示例:
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.
#### Scenario: OTP required
- WHEN a user submits valid credentials
- THEN an OTP challenge is required
#### Scenario: Successful OTP verification
- WHEN a user enters the correct OTP
- THEN allow login and issue JWT
#### Scenario: OTP failure
- WHEN a user enters wrong OTP
- THEN deny login, show error reminder
proposal.md 示例内容(由 AI 自动生成并可人工补充):
# 变更提案:增加两步验证
- 目的:提升账户安全,防止盗号风险。
- 影响范围:登录流程;用户数据表需扩展。
- 验收标准:
- 用户登录时需验证动态验证码(OTP)
- 支持短信/邮件/Authenticator APP
- 管理员可强制开启 2FA
步骤三:拆解技术任务(tasks.md)
- [ ] 1.1 用户表新增 OTP 密钥(secret 字段)
- [ ] 1.2 新建 OTP 验证日志表(存储验证结果、时间戳)
- [ ] 2.1 新增生成 OTP 接口(如 RESTful: /api/otp/generate)
- [ ] 2.2 修改登录逻辑,登录成功后进入 OTP 校验阶段
- [ ] 2.3 新增 OTP 验证接口(/api/otp/verify)
- [ ] 2.4 支持多种 OTP 发送方式(短信/邮件/Google Authenticator)
- [ ] 3.1 登录页面新增 OTP 输入框与校验步骤
- [ ] 3.2 错误处理与用户体验优化
- [ ] 3.3 可视化展示 2FA 启用、关闭入口
步骤四:协同完善、审查与对齐
- 在'proposal.md'和'spec.md'中补充实际业务场景、边界情况(如多次失败锁定、备份码等)。
- 让 AI 或团队成员完善'tasks.md'具体实现细节。
openspec show add-2fa 展示所有内容,团队或 AI 共同审核。
步骤五:任务实现与归档
- 按任务清单开发各模块,AI 助手可自动标记完成情况(如
[x] 已完成)。
- 变更自动归档至 specs 目录,成为系统新业务的