告别“猜需求”式编程：这个开源工具让 AI 编码变得真正的可控

在 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，你会这样做：

第一步：初始化项目

kotlin 复制代码

npm install -g @fission-ai/openspec
cd super-blog-site
openspec init

工具会引导你选择常用的 AI 助手（如 Cursor、Claude），并自动生成配置和 AGENTS.md 文件。

第二步：创建变更提案

shell 复制代码

/openspec:proposal  请为博客系统创建一个 OpenSpec 变更提案，用于添加点赞功能，要求已登录用户可点赞，每人每篇文章只能点一次。"

AI 会自动生成以下结构：

text 复制代码

openspec/
└── changes/
    └── add-blog-like/
        ├── proposal.md      # 功能背景与目标
        ├── tasks.md         # 实现任务清单
        └── specs/blog/spec.md  # 新增的规格（Delta 格式）

其中 spec.md 会明确写出：

markdown 复制代码

### Requirement: 博客点赞功能
系统 MUST 允许已认证用户对文章点赞，且每人每篇文章仅限一次。

#### Scenario: 首次点赞
- WHEN 用户点击点赞
- THEN 点赞数 +1，且记录该用户已点赞

#### Scenario: 重复点赞
- WHEN 用户再次点击
- THEN 不增加计数，并提示"已点赞"

第三步：评审与调整

你可以用命令查看提案细节：

sql 复制代码

openspec show add-blog-like

如果发现遗漏（比如忘了"取消点赞"），只需告诉 AI 补充，它会更新 spec 和任务。

第四步：实施与归档

确认无误后，说：

"开始实现这个点赞功能。"

AI 将严格按 tasks.md 生成数据库表、API 接口和前端组件。完成后，执行：

sql 复制代码

openspec archive add-blog-like --yes

此时，新规格自动合并进 openspec/specs/，成为系统文档的一部分，而变更记录被归档，全程可追溯。

为什么开发者需要它？

减少返工：AI 不再"自由发挥"，所有输出有据可依。
活文档自动生成：每次归档都是对系统行为的一次正式记录。
团队协作更顺畅 ：新人看 specs/ 就能理解系统设计，无需翻聊天记录。
适配现有项目：特别适合对已有系统做增量改进（1→n 场景），而非仅限从零开始。

与 GitHub 官方 spec-kit 对比

GitHub 的 spec-kit，同样倡导"先写 spec"。两者理念相近，但在设计上存在关键差异：

维度	OpenSpec	GitHub spec-kit
适用场景	擅长修改现有系统（brownfield）	更适合从零构建新功能（greenfield）
变更管理	所有相关文件（提案、任务、spec）集中在一个 `changes/xxx/` 文件夹	spec 分散在各模块目录，变更追踪较弱
AI 集成	原生支持 20+ 主流 AI 工具，提供斜杠命令和 AGENTS.md 双协议	主要面向 GitHub Copilot，生态较封闭
工作流	明确四步流程（起草→评审→实施→归档），强调闭环	侧重 spec 编写，缺乏完整的变更生命周期管理

简言之，spec-kit 像是一套"写作模板"，而 OpenSpec 是一套"协作流程" 。如果你的项目已经上线，且需要频繁迭代、多人协作，OpenSpec 的结构化变更追踪和跨工具兼容性会更具优势。

写在最后

AI 不会取代程序员，但会重塑开发流程。OpenSpec 的出现，标志着我们正从"让 AI 猜需求"走向"与 AI 共同定义需求"。

它不炫技，不堆概念，只是默默在代码之前，加了一道"确认键"。而这，或许正是可控、可靠、可协作的 AI 编程时代真正开始的地方。

项目地址 ：github.com/Fission-AI/...
推荐尝试 ：在下一个功能开发前，先运行 openspec init ------ 你可能会惊讶于，当 AI 真正"懂你"时，效率能有多高。