你有没有遇到过这种情况？
让AI帮你写代码，它倒是写得快，但：
- 需求理解错了，白写
- 代码风格不统一，东一块西一块
- 没有文档，过两周自己都看不懂
- 改个需求，整个推倒重来
今天介绍一个神器——OpenSpec，它能让AI”按规矩”写代码。
一句话总结：AI编码的规范驱动开发框架，让AI先想清楚再动手。
一、传统AI编码的问题
我们先看看传统AI编码的流程：
`
用户：帮我写一个用户注册功能
AI：好的！[噼里啪啦写了一堆代码]
用户：等等，我没说要支持手机号注册
AI：哦，那我重写
用户：等等，密码加密要用bcrypt
AI：好的，再改
用户：等等，还要支持邮箱验证
AI：……
`
这个流程有什么问题？
- 需求不明确：AI猜着写，猜错了就返工
- 没有规范：每次生成的代码风格不一样
- 缺少文档：为什么这么设计？没人知道
- 难以迭代：改一个地方，其他地方跟着崩
二、OpenSpec的解决方案
OpenSpec的核心理念是：先写规范，再写代码。
它的流程是这样的：
`
- 用户提出需求
- OpenSpec生成规范文档（Spec）
- 用户确认规范
- OpenSpec根据规范生成代码
- 代码可验证、可追溯
`
这不是什么新概念，软件工程早就这么教了。但问题是：以前写规范比写代码还累，没人愿意干。
OpenSpec用AI解决了这个问题：让AI帮你写规范，然后让AI按规范写代码。
三、OpenSpec是什么？
OpenSpec是一个开源的规范驱动开发框架，专为AI编码助手设计。
它的核心特性：
- 规范管理：自动创建、维护、归档规范文档
- 变更追踪：每次修改都有完整记录
- 多工具支持：Claude Code、Codex、Cursor、OpenCode等
- Brownfield友好：特别适合已有代码库的持续迭代
四、快速开始
4.1 安装
`bash
# 全局安装
npm install -g @fission-ai/openspec@latest
# 初始化项目
openspec init
`
初始化后，OpenSpec会在项目中创建以下目录结构：
`
your-project/
├── openspec/
│ ├── config.yaml # 配置文件
│ ├── specs/ # 主规范文档
│ ├── changes/ # 变更记录
│ └── archive/ # 归档的变更
├── .claude/ # Claude Code配置
├── .cursor/ # Cursor配置
└── .opencode/ # OpenCode配置
`
4.2 基本使用
`bash
# 创建新的变更提案
openspec propose “添加用户注册功能”
# 探索和规划
openspec explore
# 实施变更
openspec apply
# 归档完成的变更
openspec archive
`
五、核心工作流
5.1 Propose（提议）
当你有一个新需求时，先创建一个提案：
`bash
openspec propose “添加用户注册功能，支持手机号和邮箱”
`
OpenSpec会生成一个规范文档，包含：
- 需求描述
- 技术方案
- 影响范围
- 测试策略
5.2 Explore（探索）
在实施之前，先探索一下：
`bash
openspec explore
`
这个阶段会：
- 分析现有代码库
- 识别可能的影响
- 提出技术方案
- 评估风险
5.3 Apply（应用）
确认规范后，开始实施：
`bash
openspec apply
`
AI会严格按照规范文档来写代码：
- 代码风格一致
- 命名规范统一
- 注释完整
- 测试覆盖
5.4 Archive（归档）
变更完成后，归档：
`bash
openspec archive
`
归档后：
- 变更记录永久保存
- 主规范文档更新
- 新会话自动加载历史规范
六、为什么OpenSpec有效？
6.1 外部长期记忆
AI的上下文窗口是有限的，聊着聊着就忘了之前说了什么。
OpenSpec把规范写到文件里，成为AI的”外部记忆”：
- 每次新会话自动加载相关规范
- 历史变更随时可查
- 不会因为上下文窗口限制而丢失信息
6.2 变更可追溯
每个变更都有完整记录：
- 为什么要改？
- 改了什么？
- 谁批准的？
- 测试通过了吗？
这在团队协作中特别重要。
6.3 代码质量保障
AI按规范写代码，而不是”自由发挥”：
- 命名规范：团队统一的命名风格
- 架构规范：不破坏现有架构
- 测试规范：每个功能都有测试
- 文档规范：代码即文档
七、与其他工具对比
| 特性 | OpenSpec | Superpowers | Spec-Kit |
|---|
|——|———-|————-|———-|
| 核心定位 | 规范管理 | 执行纪律 | 流程骨架 |
|---|---|---|---|
| 适合场景 | 已有代码库 | 新项目 | 项目初始化 |
| 上手成本 | 中等 | 低-中 | 中等 |
| Token消耗 | 低 | 中高 | 中等 |
| 变更追踪 | 强 | 弱 | 中等 |
| TDD强制 | 否 | 是 | 否 |
7.1 OpenSpec vs Superpowers
- OpenSpec：管”做什么”——需求、规范、设计
- Superpowers：管”怎么做”——流程、纪律、质量
两者不冲突，可以组合使用。
7.2 OpenSpec vs Spec-Kit
- OpenSpec：增量变更管理，适合已有项目
- Spec-Kit：项目初始化规范，适合新项目
八、实战案例
8.1 案例：给现有项目添加新功能
假设你有一个电商项目，要添加优惠券功能：
`bash
# 1. 创建提案
openspec propose “添加优惠券系统，支持满减、折扣、固定金额”
# 2. 探索现有代码
openspec explore
# 输出：分析了商品模块、订单模块、支付模块的影响
# 3. 确认规范后实施
openspec apply
# AI严格按照规范生成代码
# 4. 完成后归档
openspec archive
# 变更记录永久保存
`
8.2 案例：团队协作
多人协作时，OpenSpec的价值更大：
- 规范先行：新人加入项目，先读规范
- 变更审核：每个PR都有对应的规范文档
- 知识沉淀：离职的人带走的是代码，留下的是规范
九、OpenSpec的哲学
OpenSpec背后有一个深刻的哲学：AI编码不应该是”对着干”，而应该是”一起干”。
传统AI编码：
- 用户提需求 → AI猜 → 用户纠错 → AI改 → 循环
OpenSpec编码：
- 用户提需求 → AI生成规范 → 用户确认 → AI按规范写代码 → 完成
区别在哪？规范文档是中间层，它让AI和用户在同一个频道上对话。
十、不足与展望
当前不足
- 需要一定的学习成本
- 小项目可能觉得”多此一举”
- 依赖AI工具的质量
未来展望
- 更多AI工具支持
- 更智能的规范生成
- 团队协作功能增强
- 与CI/CD深度集成
十一、我的使用建议
- 从小需求开始：别一上来就搞大重构，先用小需求熟悉流程
- 规范要具体：越具体，AI写出来的代码越符合预期
- 定期归档：别让changes目录堆积太多
- 团队统一：如果团队使用，先统一规范风格
总结
OpenSpec解决了一个核心问题：如何让AI”按规矩”写代码。
它不是要限制AI的能力，而是给AI一个”导航仪”，让它知道该往哪走。
如果你：
- 受够了AI乱写代码
- 想要可维护的AI生成代码
- 需要团队协作的规范管理
那OpenSpec值得一试。
项目地址：https://github.com/Fission-AI/OpenSpec
你用过OpenSpec吗？或者你有什么让AI”听话”的技巧？欢迎评论区分享！
发表回复