用AI写代码,最怕什么?它自作主张。
你让它加个登录,它给你整出OAuth、短信验证、人脸识别。你让它修个bug,它把整个模块重写了。更气人的是,改完之后你都不知道它动了哪里,Code Review无从下手。
这就是"vibe coding"的真实写照------你给AI一句话,它给你一堆代码,好坏全凭运气。
OpenSpec解决的就是这个问题:先定规矩,再干活。
原理
OpenSpec的思路很简单:不让AI直接写代码,而是先让它写规范。
规范长这样:
markdown
# 需求:用户筛选
- 支持按角色筛选(管理员/普通用户)
- 支持按团队筛选(技术/产品/运营)
- 筛选后URL参数同步
规范写清楚,你确认了,AI再动手。它敢乱加功能?规范里没有,它就不该写。
核心文件就两个:
specs/------ 当前系统的规范(只读,不准改)changes/------ 要改什么(写在这里,等你审批)
这就好比Git的main分支和feature分支------规范是稳定版,变更是提案。
流程
1. 写提案
你告诉AI:"给用户列表加按角色筛选" AI不写代码,先建文件:
bash
changes/add-role-filter/
├── proposal.md # 为什么要加、加在哪
├── tasks.md # 要干哪几件事
└── specs/user-list/spec.md # 具体怎么筛
2. 你审批
打开proposal.md看一眼。太复杂?删掉多余功能。太简单?补充细节。 确认无误后,告诉AI:"可以干了"。
3. AI执行
AI严格按照tasks.md逐条实现。不会多写一行多余代码。 你可以随时看进度------做了几条,还剩几条。
4. 归档
代码合入后,执行归档。changes/里的内容合并到specs/,成为新规范。 下次改代码,AI就知道现状是什么,不会再重复造轮子。
实战
场景:给后台管理系统加"导出报表"功能。
传统做法: 开发者:帮我写个导出按钮 AI:生成200行代码,包含Excel、CSV、PDF三种格式,还自带邮件发送 开发者:我只想要Excel啊... AI:好的,重新生成...
OpenSpec做法:
第一步,写提案:
markdown
# 导出功能规范
- 格式:仅Excel (.xlsx)
- 触发:点击"导出"按钮
- 数据:当前筛选后的列表数据
- 并发:限制同时1个导出任务
第二步,审批通过。
第三步,AI按tasks.md逐条实现:
- 添加导出按钮
- 实现Excel生成
- 对接当前筛选器
- 加并发锁
第四步,归档。下次再加CSV导出,你知道要从specs/里改,而不是在代码里瞎塞。
收益
可追溯:每个功能都有对应的规范文件。谁写的?什么时候?为什么?全在Git历史里。
可审查:Code Review不再是看几百行diff,而是看规范变化。规范对了,代码大概率对。
可复用 :新AI加入项目,读一遍specs/目录,秒懂系统全貌。不用重新"聊天灌上下文"。
限制
- 探索性原型:你不知道要做什么,规范没法写
- 一次性脚本:写完就扔,不值得建规范
- 纯算法优化:规范描述"怎么更快"很难,不如直接看代码
对于正式项目、多人协作、长期维护------OpenSpec是目前AI编程最靠谱的工程化方案。
结论
一句话总结:OpenSpec让AI从"自由发挥"变成"照章办事"。
你不需要管AI怎么写代码,但你必须管AI写什么功能。规范就是那个"管"的工具。
试试这个命令(如果你的AI支持OpenSpec):
bash
/openspec:proposal 我要加一个功能:...
剩下的,交给流程。