规范驱动开发，音准差了一道闸门

你大概也撞见过这套连锁：让 AI 把按钮改成圆角，它动了按钮，导航栏碎了；你补一句“把导航栏修好”，认证又失效了；再修认证，样式没了。这串多米诺倒在你屏幕前的时候，你甚至生不起气来——你知道不是 AI 笨，是它从头到尾就没拿到过一道约束。

这摊事有人收拾出过办法：先花个把小时把需求一条条钉清楚，再放开手让 AI 写，提交就从反复整体重写，变成局部小改。有人给这法子起了个名字：规范驱动开发（Spec-Driven Development）。

名字我不满意。规范从来没在驱动什么，真起作用的是生成之前那道闸。我把它叫做：闸门式生成。定义就一句话——先钉死为谁建、建什么、哪些不可改，然后才放 agent 出闸。为什么叫闸门不叫蓝图？蓝图要画完整个设计，闸门只负责拦一下那脚油门。它不需要覆盖全部细节，只需要强制你不能空档起步。

评论区有人说，这不就是 BDD 吗，行为驱动开发换层皮。这声我不认。BDD 管的是行为验证——代码跑起来之后，测它是不是真做了该做的；闸门式生成管的是生成边界——代码还没出生，方向先定住。一个在事后查岗，一个在事前断路。能说出换皮的人，大概还没被那种改按钮改崩半个项目的场面收拾过。

真正让我停住的是另一条评论：规范是死的，代码是活的。agent 按 spec 改七轮之后，你再打开 requirements.md，里面写的东西早就被这七轮改得面目全非。跟着它走，是照旧地图赶路；不跟它走，这张规范从第一天起就是废纸。这摊我管它叫：规范漂移。

它跟代码腐化不是一回事。代码腐化是代码一步步烂掉，你知道它烂在哪；规范漂移是你不知道它还算不算数。造闸门的人如果不顺手装一个校准机制，你只不过是把 AI 幻觉，换成了规范幻觉。

但闸门从来不是挡在 vibe coding 前面的墙。你半夜手痒照样 vibe，早晨九点先把需求钉死。两道都得会。

你下次再遇到 agent 长对话里那个“改着改着，不知道还该不该信那份 spec”的时刻，就说一句：规范漂移了！用这四个字指认它，指的人多了，它就不只我一个人在喊。

附带一个作废条件：半年内没人认领，或者社区已经有了更准的词在传，我回来把它回炉，不占这块空地。造词的特权，止于能不能让得出。📯