在 AI 编程助手大行其道的今天，作为开发者，享受着“一句话生成代码”的便利的同时，也常常陷入一种新的焦虑：AI 真的理解我们要什么吗？
你大概也经历过这样的场景：让 AI “加个登录功能”，结果它自作主张引入了 OAuth2、短信验证码、图形验证码三套方案；或者让它“优化性能”，它直接重写了整个数据层，却没问你是否兼容旧接口。问题不在于 AI 能力不足，而在于——需求从未被清晰锁定。
上上周刷 Github，发现一个名为 OpenSpec 的开源项目正试图解决这一痛点。它不取代你的 AI 工具，而是为它们加上一套“规范驱动开发” SDD（Spec-Driven Development）的工作流，让人类和 AI 在写第一行代码前，先就“做什么”达成共识。
什么是 OpenSpec？
OpenSpec 是由 Fission AI 团队发起的一个轻量级开发框架，核心理念很简单：先写规格（spec），再写代码。
它在项目中创建两个关键目录：
openspec/specs/：存放当前系统的真实行为规范（即“事实来源”）openspec/changes/：存放正在提议中的功能变更（包括提案、任务清单和规格差异）
整个流程围绕四个步骤展开：起草 → 评审 → 实施 → 归档。AI 助手全程参与，但所有输出都基于明确的 spec，而非模糊的聊天上下文。
更重要的是，无需 API 密钥，不绑定特定平台。无论你用 Cursor、Copilot、Claude 还是其他支持 AGENTS.md 协议的工具，都能无缝接入。
实战演示：给博客系统加“点赞”功能
假设你正在维护一个博客系统，现在要添加“用户点赞”功能。传统做法可能是直接对 AI 说：“帮我加个点赞按钮。”但用 OpenSpec，你会这样做：
第一步：初始化项目
npm install -g @fission-ai/openspec
cd super-blog-site
openspec init
工具会引导你选择常用的 AI 助手（如 Cursor、Claude），并自动生成配置和 AGENTS.md 文件。
第二步：创建变更提案
/openspec:proposal 请为博客系统创建一个 OpenSpec 变更提案，用于添加点赞功能，要求已登录用户可点赞，每人每篇文章只能点一次。”
AI 会自动生成以下结构：
openspec/
└── changes/
└── add-blog-like/
├── proposal.md # 功能背景与目标
├── tasks.md # 实现任务清单
└── specs/blog/spec.md # 新增的规格（Delta 格式）
其中 spec.md 会明确写出：
### Requirement: 博客点赞功能
系统 MUST 允许已认证用户对文章点赞，且每人每篇文章仅限一次。
#### Scenario: 首次点赞
- WHEN 用户点击点赞
- THEN 点赞数 +1，且记录该用户已点赞
#### Scenario: 重复点赞
- WHEN 用户再次点击
- THEN 不增加计数，并提示“已点赞”
第三步：评审与调整
你可以用命令查看提案细节：
openspec show add-blog-like
如果发现遗漏（比如忘了“取消点赞”），只需告诉 AI 补充，它会更新 spec 和任务。
第四步：实施与归档
确认无误后，说：
“开始实现这个点赞功能。”
AI 将严格按 tasks.md 生成数据库表、API 接口和前端组件。完成后，执行：
openspec archive add-blog-like --yes
此时，新规格自动合并进 openspec/specs/，成为系统文档的一部分，而变更记录被归档，全程可追溯。
为什么开发者需要它？
- 减少返工：AI 不再“自由发挥”，所有输出有据可依。
- 活文档自动生成：每次归档都是对系统行为的一次正式记录。
- 团队协作更顺畅：新人看
specs/就能理解系统设计，无需翻聊天记录。 - 适配现有项目：特别适合对已有系统做增量改进（1→n 场景），而非仅限从零开始。
与 GitHub 官方 spec-kit 对比：两种“规范驱动”的不同路径
GitHub 在 2024 年底推出的 spec-kit 同样倡导“Spec-Driven Development”（规范驱动开发），其核心目标是让规格成为可执行的起点，而非文档终点。它由 GitHub 内部团队孵化，深度集成 Copilot，并强调通过 /constitution、/specify、/plan、/tasks、/implement 等斜杠命令构建一个结构化开发流程。
乍看之下，OpenSpec 与 spec-kit 理念高度一致，但深入使用后会发现，它们代表了两种不同的工程思维：
| 维度 | OpenSpec | GitHub spec-kit |
|---|---|---|
| 核心目标 | 管理变更的生命周期 ——聚焦“如何安全地修改现有系统” | 引导从零构建高质量应用 ——聚焦“如何从模糊想法生成可靠实现” |
| 工作流重心 | 围绕 变更提案（Change Proposal） （起草 → 评审 → 实施 → 归档） | 围绕 功能开发阶段（Development Phases） （定义原则 → 写 spec → 制定计划 → 拆解任务 → 执行） |
| 项目状态假设 | 默认项目已存在（brownfield） 强调与现有代码/文档共存 | 更适合新项目或独立功能模块（greenfield） 常伴随 specify init 创建全新目录 |
| 规格组织方式 | 使用 Delta（增量）模式 变更期间仅描述差异，归档时才合并到主干 specs | 规格直接写入 specs/<feature>/spec.md每个功能对应一个完整 spec 文件 |
| 用户角色 | 适合 维护者/迭代者 （如给 SaaS 产品加新功能、重构旧模块） | 适合 创建者/探索者 （如 MVP 开发、技术原型验证、创意实验） |
| 输出产物 | 强调 可审计的变更记录 （archive 中保留完整上下文） | 强调 可执行的工程资产 （自动生成 plan.md、data-model.md、contracts 等） |
举个例子：
- 如果你要为公司内部 CRM 系统新增“客户标签分组”功能，且该系统已有复杂权限模型和数据库结构，OpenSpec 能让你清晰隔离本次变更的影响范围，避免 AI 误改无关逻辑。
- 如果你要从零开始做一个照片整理工具，不确定用 React 还是 Svelte，数据库选 SQLite 还是 IndexedDB，spec-kit 能帮你通过多轮
/plan和/tasks探索不同技术栈，并生成完整的架构文档。
总结：不是替代，而是互补
spec-kit 像是一位经验丰富的架构师，擅长从白纸开始搭建一座结构严谨的大厦；
OpenSpec 则像一位谨慎的改造工程师，专注于在不破坏原有建筑的前提下，精准嵌入新功能。
两者都试图解决“AI 编程缺乏确定性”的根本问题，只是切入角度不同。
对于大多数正在维护线上系统的团队而言，OpenSpec 的增量式、低侵入、高可追溯特性，可能更容易融入现有研发流程。而 spec-kit 则在创新探索和标准化启动阶段展现出强大引导力。
无论选择哪一种，它们共同传递了一个信号：未来的高效开发，不再是谁写代码更快，而是谁能把“意图”表达得更清晰、更结构化、更可验证。
正如 spec-kit README 所言：“Specifications become executable, directly generating working implementations.”
而 OpenSpec 则补充道：“And every change to that specification must be reviewed, implemented, and archived — just like code.”
写在最后
AI 不会取代程序员，但会重塑开发流程。OpenSpec 的出现，标志着我们正从“让 AI 猜需求”走向“与 AI 共同定义需求”。
它不炫技，不堆概念，只是默默在代码之前，加了一道“确认键”。而这，或许正是可控、可靠、可协作的 AI 编程时代真正开始的地方。
项目地址：github.com/Fission-AI/…
推荐尝试：在下一个功能开发前，先运行openspec init—— 你可能会惊讶于，当 AI 真正“懂你”时，效率能有多高。
