10月6日凌晨，知乎「OpenSpec最近火了，规范驱动开发是AI编程的未来吗？」这个问题下面又冒出一条新回答，几个小时浏览就冲过了16万。开头第一句就是冷水——“我不劝你用OpenSpec，但我劝你别把它当文档”。知乎
另一边，B站上Matt Pocock的规范驱动工作流实战视频（/implement-spec、/pr、/retro 三连）当天就有两千多人围观，评论区一水儿“这才是正经项目该有的样子”。哔哩哔哩
一边说“写规范比写代码还累”，一边说“规范省了两小时返工”。两派都有实测、都有拥趸，这场架从9月中吵到今天，OpenSpec、GitHub的Spec Kit、AWS的Kiro全被拉下水。我把两边的料都翻完了，先说判断：两派吵的根本不是同一个“规范”。搞清楚这件事，比选工具重要得多。
反方的三宗罪，条条属实
先看骂得最狠的几条，都来自带过团队的老程序员：
第一条，AI不遵守规范，这是结构性事实，不是态度问题。文档人都未必读，凭什么AI要遵守一篇散文？
第二条，翻车案例最集中的是AWS自家出的SDD集成开发环境Kiro。有开发者实测让它写一个读取运动数据的简单应用，出来20个文件、1500多行代码，同样的活儿人写200行就够，代码里还塞满没删干净的console.log；任务失败之后上下文直接丢，得从头再来。知乎
第三条最致命，叫drift（漂移）：代码已经跑出去了，需求和设计文档还留在原地。有人总结自己用OpenSpec一个月的真实感受——“和AI来来回回十几轮，沟通时间比自己写代码还长”。知乎
这些批评都对。但注意，它们全都建立在一个隐藏前提上：规范是一份写给人看、给AI“参考”的文档。
正方的三个失控现场，也条条属实
支持SDD（Specification-Driven Development，规范驱动开发）的人晒的是另一组画面：
让AI给订单模块加“优惠券校验”，它为了复用把支付模块的同名函数也“顺手”改了，三天后线上炸了；
要一个支持签到、消费、兑换的积分系统，两周后打开代码，等级、成就、排行榜全有了，唯独没有兑换；
三个月后git blame一个逻辑很怪的函数，commit message写着“实现需求”，当时的需求是什么，没人知道。
这三个坑的共同根源：意图只存在你的脑子里和对话记录里，从来没有变成一个可被检查、可被追溯的物件。知乎
顺便说一句，两边最火的文章其实都夹带了生意——正方的对照实验出自MonkeyCode的推广文，反方那条16万浏览的回答结尾也在卖自家的Skill手册。数据都要打折，但吵出来的问题是真问题。知乎
真正的分水岭：文档靠喊话，账本靠闸门
10月6日那条冷水回答里最值钱的一句话是——你没法让AI付出代价，但你可以让CI付出代价。知乎
同一条规范，他写了两版：
散文版：“禁止在Service层直接操作Mapper，必须通过Repository访问数据。”——发到群里，两周后没人记得。
可校验版：“Service层文件不得 import *Mapper；触发即CI阻断，PR无法合并。”——一行正则脚本挂上流水线，从此没人再犯。
区别不在写法，在于背后有没有一道AI绕不过去的物理闸门。AI写出的代码违反规范，它自己不会痛，但流水线会红、会拦住merge、会通知到人。
看懂这一层，OpenSpec的目录设计突然就合理了：specs/ 里是冻结基线，只回答“系统现在应该是什么样”；changes/ 里是本次变更单，提案、设计、任务清单、WHEN/THEN验收场景各归各位；archive归档时一次操作、两个产出——增量合并进基线，完整证据链原样留底。半年后有人问“限流阈值为什么从100改成了500”，基线里查不到，但archive里翻得到当时的提案和diff。知乎
这是账本，不是文档。账本不指望AI自觉，它指望每次变更都必须从这里过。
带团队的人还可以抄那个三层分法：Rules是机器可校验的硬规则，CI执行，AI绕不过；Skill是稳定复用动作的编排，人可审；MCP是只读数据源，服务端权限受控。三层里只有中间一层是给AI看的“规范”，另外两层压根不给AI看。
最后一条红线必须写死：AI生成的测试脚本，绝对不能让AI自己标记“已审核”。 这个口子一开，验收标准就成了AI自己给自己打分，整条证据链当场作废。
OpenSpec还是Spec Kit：一张表说清
决定要试的话，选型账在这（参数核对自两个工具的官方文档和实测文章）：
OpenSpec这边：Fission AI开源，MIT协议，需要Node.js 20.19以上，`npm install -g @fission-ai/openspec` 一行装完；定位是轻量规范层，官方口号是“流动而非僵化、迭代而非瀑布、为存量项目而生”；在仓库里只加一个 openspec/ 目录，不接管工程。知乎
Spec Kit那边：GitHub官方出品，同样MIT，需要Python 3.11加uv，`uv tool install specify-cli` 安装；主张“规范可执行”——规范不只引导实现，而是直接生成实现；目录是 .specify/，还有constitution（项目宪法）概念，强调组织级治理。知乎
两个容易忽略的细节：
OpenSpec默认开启匿名遥测（只采集命令名和版本），介意就装完执行 `openspec config set telemetry.enabled false`，或设环境变量 OPENSPEC_TELEMETRY=0；
两者目录不冲突，同一仓库可以共存。实测文章里公认的长期最优路线是：用Spec Kit的constitution定组织准则、跑0到1的交付；项目进维护期后切OpenSpec，用变更单持续沉淀基线，让“系统现在到底怎么工作”始终有活账本。
搬家之前，先算三笔账
第一笔：这代码三个月后还有人管吗？ 有人管，规范才值钱；没有，vibe就行。改错别字、写一次性脚本还硬走完整SDD流程，纯属自我惩罚。正方自己也承认三个代价：前期慢（对照实验里前25分钟零代码产出，习惯“5分钟看到代码”的人会难受）、小任务不划算、规范会漂移需要人维护。知乎
第二笔：你有没有CI可挂？ 项目连流水线都没有，先别装任何工具。做最小实验：写一条规范，配一行检查脚本挂上CI，跑一周。管用再扩大，不管用损失的也只是一个下午。
第三笔：你的时间花在“生成”还是“返工”上？ 那个65分钟对3小时的对照实验，数字要打折，但结构没错：SDD是把时间从“事后返工”搬到“事前对齐”。你的项目痛在返工，它就划算；痛点是需求本来就清楚、纯粹缺人手，那就别再加一层流程。知乎
接下来值得盯的信号：OpenSpec的版本迭代和community schema生态会不会起来；GitHub会不会把Spec Kit塞进Copilot产品线；Kiro的上下文丢失问题修不修。这三个任何一个动了，今天的结论都要重算。
一句话收尾：这场吵了一个月的“规范先行”之争，输的一方基本都是把规范当文档的人。先有闸门，再有账本，最后才是工具——顺序别搞反。
