OpenSpec实战：AI编程告别“瞎写”
- 人工智能
- 15天前
- 17热度
- 0评论
OpenSpec 实战指南：让 AI 编程告别随意发挥
用人工智能编写代码时最大的顾虑是什么？它可能会做出超出预期的行为。用户要求添加登录功能，结果却得到了OAuth、短信验证和人脸识别的实现；请求修复一个bug，AI直接重写了整个模块并留下一堆难以理解的修改记录。
这就是所谓的“vibe coding”——你给 AI 一句话，它就给你一大段代码，并且好坏全凭运气。OpenSpec 的核心理念正是解决这个痛点：先定规矩再干活。
原理
OpenSpec 的主要思路是不让 AI 直接编写代码，而是让它首先制定规范。
一个规范文件的示例如下：
# 需求：用户筛选
- 支持按角色筛选（管理员/普通用户）
- 支持按团队筛选（技术/产品/运营）
- 筛选后URL参数同步在这个框架内，AI 的任务是根据规范进行工作。如果规范中没有提到的功能或特性，AI 就不会编写相关代码。
OpenSpec 包含两个核心文件夹：
- specs/ —— 定义整个系统的规范（只读）
- changes/ —— 存放待审批的变更提案
这类似于 Git 中的 main 分支和 feature 分支——稳定的规范就像主干，变化的提案就像是新分支。
流程详解
步骤一：编写提案
用户要求添加功能时，如“给用户列表增加按角色筛选”，AI 不会直接生成代码，而是先创建一个提案文件夹：
changes/add-role-filter/
├── proposal.md # 说明为什么要实施该变更、具体位置等信息
├── tasks.md # 具体需要执行的任务描述
└── specs/user-list/spec.md # 规范详情 步骤二：审批提案
用户审核 proposal.md 文件，确认内容后告知 AI 可以开始工作。
步骤三：AI 实现变更
接下来，AI 根据任务列表逐条执行，不会编写超出规范的代码。你可以随时查看进度和细节。
└── tasks.md # 包括添加导出按钮、实现Excel生成等功能步骤 步骤四：归档变更
完成所有变更后，将更改文件合并到 specs/ 目录中，形成新的规范。下次再进行类似的修改时，AI 就会知道现在的系统状态。
实战案例
假设需要为一个后台管理系统添加“导出报表”功能。
传统方式： 开发者请求：“增加导出按钮”，但 AI 提供了一个包含 Excel、CSV 和 PDF 的完整实现，甚至还有邮件发送选项。开发人员表示只想要 Excel 导出，于是 AI 又重新生成代码。
使用 OpenSpec 方式：
- 编写提案文件：
# 导出功能规范
- 格式：仅 Excel (.xlsx)
- 触发方式：点击“导出”按钮
- 数据来源：当前筛选后的列表数据
- 并发限制：同时允许一个导出任务
审批提案。
AI 执行变更
- 添加导出按钮
- 实现 Excel 生成功能
- 对接现有筛选器逻辑
- 加入并发锁机制
归档变更
收益
可追溯性：
每个功能都有对应的规范文件，便于追踪开发历史和原因。
可审核性：
代码审查不再需要查看大量 diff 而是直接检查规范的变化是否合理。
可复用性：
新加入的 AI 只需阅读 specs/ 文件夹即可快速掌握项目概况而无需额外沟通背景信息。
限制
OpenSpec 不适合用于探索性原型、一次性脚本及纯算法优化场景，这些情况下编写全面规范是不现实的。对于正式项目的多人协作和长期维护而言，它是目前最有效的 AI 编程工程化方案之一。
总结
通过 OpenSpec 方案，可以确保 AI 严格按照既定规则执行编程任务而不是自由发挥。虽然你无法控制 AI 如何实现代码细节，但可以通过规范文件来限定其功能范围。
尝试使用以下命令（如果您的 AI 支持此功能）：
/openspec:proposal 我要加一个功能：...这样做的好处在于让整个开发流程更加规范化和可追溯。
> 🔗 相关阅读：企业级智能体