概述
在 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 | 无规范 |
|---|---|---|---|---|
| 项目适用性 | 新功能、旧功能均适合 |
