企业架构、智能体设计 规格驱动开发为何失败？双重事实源如同戴两只手表 #vibe编程 #Specification模式 #产品需求与商业分析BA方法 #DDD领域驱动设计 2026-07-26 4K banq 规格驱动开发喊了三年，号称能让程序员从写代码的苦力变成定义需求的艺术家。
结果呢？GitHub上那个Spec Kit的issue挂了一年，每隔两周就有人跑进去哭诉同一个问题：我改了代码，规格文档还在原地装死，现在两个东西各说各话，到底谁才是老大？
这个问题不解决，规格驱动开发永远是个笑话。
规格文档变成第二个代码库
写规格文档这件事，本来是为了给AI一个清晰的地图。你告诉它你要什么，它帮你把路铺好。但这个地图有个致命bug——路修好了，地图没更新。每次代码迭代一次，规格文档就落后一步。改十次代码，规格文档就成了考古文物，记录的是远古时期的想法。
问题的根源在于同步成本。改代码的时候你脑子里全是逻辑、变量、函数调用，谁还有空去翻那个几百行的Markdown文档？更别说把改动翻译成人话写进去。这种体力活干一次两次还行，每天干谁受得了。结果就是规格文档从导航仪变成了摆设，你走你的，它躺它的。
有人会说，那你用AI自动同步不就行了？问题是AI能读懂你的代码改动，但它读不懂你脑子里那个“为什么”。规格文档真正值钱的部分不是“做了什么”，而是“为什么这么做”。这个因果链条AI抓不住，只能给你生成一堆流水账式的更新日志，看着像那么回事，实际屁用没有。
两个真相害死一个流程
规格驱动开发最大的陷阱就是制造了两个真相。代码里的逻辑是一个真相，规格文档里的描述是另一个真相。两个东西都在变，频率还不一样，最后只能选择一个当老大。
现实里大家选的都是代码当老大。为什么？因为代码是最终跑起来的那个东西，测试通过不通过看的是代码，上线崩不崩看的也是代码。规格文档写得再漂亮，代码跑不通一切都是零。所以一旦发生冲突，所有人都默认规格文档是错的，代码才是对的。这时候规格文档就彻底失去了意义，变成了一个需要维护的历史包袱。
更尴尬的是，当你必须靠规格文档来指挥AI写代码的时候，这个包袱就变成了枷锁。你改一行规格描述，AI重新生成几百行代码。你发现生成的代码有bug，手动修一下，规格文档又对不上号了。这个循环跑几轮之后，你整个人都麻了，只想把规格文档扔进垃圾桶。
有个哥们说得特别狠，规格驱动开发留下的不是代码库，而是一堆没人看的Markdown。需求文档、高层设计、底层设计、开发计划，全在你改代码的第一秒就开始腐烂。等到上线那天，这些文档的真实性跟路边算命的大爷差不多，信不信全看缘分。
规格适合画饼不适合炒菜
那规格这东西到底有没有用？有用，但得用对地方。规格最擅长的是定方向，不是定细节。你告诉团队我们要做一个电商系统，支持支付、库存、物流，这叫规格。但你说支付流程第一步调接口A，第二步验签名B，第三步落库C，这种级别的细节写到规格里就是找死。
代码细节天生就是流动的。你写代码的时候会发现需求里没考虑到的边界情况，会发现第三方接口的文档是错的，会发现性能瓶颈需要换方案。这些东西全是在写的过程中暴露出来的，你不可能在写代码之前全想清楚。规格文档一旦细化到这种程度，就变成了一个预言，而且是注定会被现实打脸的预言。
聪明人的做法是把规格当作战术执行文档。做调研的时候写一写，规划的时候写一写，实现的时候看一眼，做完就扔掉。下次再做类似功能的时候从头开始调研，因为时间变了、依赖变了、需求也变了，以前的经验只能当参考不能当圣经。
RPI模式就是这么玩的。Research阶段写调研笔记，Plan阶段写执行方案，Implement阶段按方案干活，干完活所有文档归档封存。规格存在的意义是帮你理清当下的思路，不是给你未来三千年立规矩。
管理AI和管人用的是同一套心法
有人觉得规格驱动开发是AI时代的新物种，新鲜得不行。但本质上看，你不直接写代码，而是写需求让别人（或者AI）来写代码，这不就是工程经理在干的事吗？
工程经理管程序员的时候，写需求文档、画架构图、定接口规范，然后交给团队去实现。实现的细节能不能完全按照文档来？做梦。团队在写代码的过程中会发现一堆文档里没写的问题，会做出各种调整，最终的代码跟初始设计文档肯定有出入。这时候工程经理能怎么办？掐着程序员的脖子让他改代码直到跟文档一模一样？谁这么干谁就是傻叉。
聪明的工程经理管的是结果，不是过程。他要的是功能上线、性能达标、用户满意，至于代码写成啥样，只要不烂到影响维护，细节都是可以妥协的。同样地，你指挥AI写代码的时候也得有这个觉悟。AI生成的代码跟你的规格文档对不上号？只要功能对、性能行、没bug，细节就别较真了。
反过来想，如果你连细节都要靠规格文档控制，说明你骨子里是个控制狂。控制狂当经理会被团队骂死，控制狂用AI写代码会被自己蠢哭。因为AI比人类更不靠谱，它生成的代码随机性更大，你越控制越失控。
规格是沟通工具不是交付物
规格真正的身份是沟通媒介。你在规格文档里写清楚要什么功能、什么流程、什么体验，然后拿给AI看，让它理解你的意图。这跟你跟产品经理对需求、跟设计师对齐交互、跟测试确认验收标准是一回事。
一旦沟通完成，代码开始写了，规格的使命就结束了。代码是新的沟通结果，是你跟机器达成的最终共识。规格文档如果还要继续存在，就得更新成跟代码一致的状态，但这个更新工作谁来做？让AI自动同步？前面说了AI只配做流水账。让程序员手动维护？程序员宁可在代码里多写两行注释。
所以最务实的做法是，把规格当成一次性的沟通载体。写代码之前用它来对齐预期，写代码过程中遇到模糊的地方回头翻一翻，代码写完这个文档就可以光荣退休了。下次再动这块代码的时候，重新写调研笔记、重新写执行方案，因为环境全变了，旧规格的价值约等于零。
有个比喻特别形象，规格文档就像考试前老师画的重点。考试的时候你能照着重点抄吗？不行，你得自己理解、自己推导。考完试重点还有用吗？没用了，下次考试范围都不一样。规格驱动开发非要让重点在考完试之后继续指导你学习，这不是有病吗。
规格文档和代码的离婚冷静期
那些鼓吹规格驱动开发的人，最大的幻觉是觉得规格和代码能白头偕老。现实是这俩东西结婚第一天就开始闹离婚，而且谁看谁都不顺眼。代码嫌规格更新太慢跟不上时代，规格嫌代码改得太野不尊重原配。
解决这个矛盾只有三条路：
第一条，规格当老大，代码必须跟规格保持一致。代价是开发效率暴跌，因为每次改代码都要先改规格，改完规格再重新生成代码，生成完发现不对还得再改规格。这条路的尽头是程序员集体辞职。
第二条，代码当老大，规格爱咋咋地。代价是规格彻底沦为摆设，AI失去了可靠的输入依据，你只能用自然语言跟AI瞎聊，让它猜你想干啥。这条路的尽头是AI生成的代码质量随缘。
第三条，规格和代码离婚，各自安好。代码归代码写，规格归规格聊。写代码之前用规格对齐意图，写完之后规格归档进博物馆。下次要改代码的时候重新聊、重新写规格、重新对齐。这条路看着麻烦，但反而是最省力的。因为每次重新对齐的成本是固定的，不会随着时间越滚越大。
懂的都懂，第三条路就是RPI模式的精髓。你把规格当成每次开发的启动资金，花完就没了，别想着存起来吃利息。利息没吃到，本金先亏光了。
规格的保质期只有一次提交
很多人接受不了规格文档用完就扔，觉得浪费。他们没算清楚一笔账，维护一份过时的规格文档要花多少时间成本，又有多少人在用这份文档。事实是过时的文档不光没人用，还会误导人。新人入职翻到三年前的规格文档，照着理解系统架构，结果代码早就重构了八遍，这文档就是个大坑。
RPI模式把规格的保质期限定在一次提交之内。这次提交之前，规格是活地图，指哪儿打哪儿。这次提交之后，规格就是历史档案，谁爱看谁看，反正我不负责更新。下次再改这个功能，起点跟上一次完全一样，都是从头开始调研。
这种玩法的底气来自Token成本的暴跌。以前写调研笔记要花大量时间收集信息、整理思路，因为人脑的带宽太窄，存储成本太高。现在AI帮你做调研，几秒钟扫完几千行代码、几百篇文档、几十个接口定义，然后生成一份热乎的执行方案。你花在调研上的时间从半天压缩到十分钟，规格文档自然也就从战略资产变成了战术耗材。
反过来想，如果你还在纠结规格文档要不要维护、要不要同步、要不要审核，说明你的开发模式还停留在上个时代。这个时代的玩法是用Token换时间，用时间换迭代速度，用迭代速度换竞争优势。规格文档只是Token消耗过程中的副产品，用完就扔不可惜。
代码里的真相比文档硬气
最终能存活下来的真相只有代码本身。测试用例在代码里，数据模型在代码里，业务逻辑在代码里，安全策略在代码里，性能配置也在代码里。规格文档里写的所有东西，最后都要翻译成代码才有价值。
所以聪明人把精力花在让代码自己说话上。写清晰的变量名、拆合理的函数、补必要的注释、加完善的测试。这些写在代码里的信息永远跟代码同步更新，不会有规格和代码两张皮的问题。你改代码的时候顺手改一下注释和测试，成本远低于去维护一份独立的规格文档。
当然代码自己说话也有局限，它只能告诉你“是什么”，说不清楚“为什么”。这时候就需要在代码提交说明里补上设计决策的因果链。提交说明是跟着代码走的，版本管理工具天然帮你维护了同步关系。你查某行代码为什么这么写，翻当时的提交记录就明白了。这比翻一份跟代码脱节的规格文档靠谱一万倍。
那些坚持用规格文档记录设计决策的人，要么是被工具洗了脑，要么是没经历过文档追不上代码的毒打。他们幻想文档和代码能相亲相爱一辈子，现实是代码变心的速度比渣男还快，文档永远是被甩的那个。
规格是过河用的船，不是河对岸的地皮。船帮你过了河，你就该上岸赶路，别背着船走。规格驱动开发的最大贡献就是教会我们，有些东西值钱的时候是工具，过时的时候就是累赘。
下次写规格之前先问自己一句话，这份文档是给我指路的还是给我添堵的？答案不难猜。