vibe coding 死了，改写规格？产品经理的第三条路是言出法随
最近方法论圈在打一场架，标题都很吓人：「vibe coding 已死，快转向 spec-driven development（规格驱动开发）。」
风向确实在变。GitHub 的 Spec Kit 已经九万多星，AWS 出了围绕「先定规格再写码」的 Kiro，Thoughtworks 把规格驱动写进了技术雷达。主流说法是：规格才是唯一事实来源，代码只是它的产物；两者打架，改代码、别改规格。
听起来很有道理。但如果你是产品经理，先别急着跟风去补「写规格」这门课。
钟摆荡过头了
事情的剧本是这样的：
先是 vibe coding 火了——一句话扔给 AI，它哗啦啦给你写一堆。爽，但很快翻车：没结构、改不动、自己都说不清做了啥。于是人们矫枉过正，荡到另一头：那就把所有东西先写成规格，写得越细越好，再让 AI 照着做。
问题是，对产品经理而言，「写一沓详尽的前置规格」这件事，你太熟了——那就是 PRD。 那个动辄几十页、写完就过时、没人看完的 PRD。AI 时代最大的解放之一，本来就是把你从这种文档苦役里捞出来；现在 spec-driven 又把它原样请了回来，还给它起了个时髦的新名字。
从「瞎写」荡到「写规格」，是从一个极端荡到另一个极端。两头都不是产品经理该站的地方。
第三条路：规格不是写出来的，是说清楚 + 跑出来的
vibe coding 太脆，写规格太重。中间还有一条路，也是 doaipm 一直在走的那条——言出法随。
它的核心是：你不需要一份写在文档里的规格，你需要的是把想做的东西说清楚。 而「把话说清楚」，恰恰是产品经理最最基本的看家本领，不是新技能。
具体拆成两件事：
第一，规格活在对话里，不活在文档里。 你不必先憋一份完整 spec 再开工。你把意图说清楚——要解决谁的什么问题、关键约束是什么、什么算做对了——然后让 AI 当场把它变成能跑的东西。说不清的地方，AI 会反问你（一个好的 agent 应该先问 3–5 个尖锐问题再动手），你在对话里把它补清楚。澄清发生在交流中，而不是发生在一份没人爱读的文档里。
第二，能跑的高保真原型，本身就是最好的规格。 一份文字规格，十个人读出十个意思；一个能点、能跑、有真实状态（加载/空/错误/成功）的原型，所有人看一眼就知道对不对。高保真原型是会自己说话的规格——它不需要被解读，它直接被体验。 这也是为什么 doaipm 反对低保真线框图：在 AI 时代，直接做真的，比画个假的更快、误解更少。
那「结构」从哪来？——小步，加安全网
有人会问：不写重规格，怎么保证不重蹈 vibe coding 的覆辙、不失控？
靠两样东西，而不是靠厚文档：
- 小步快跑。 一次只改一件事，跑一下、看一眼、再走下一步。结构是在一连串可验证的小步里长出来的，不是在开工前一次性规划死的。
- 安全网。 原型里不放真密钥、真数据；不可逆的按钮（上线、删除、付款）永远留给人来按；不碰生产环境；拿不准就问。判断权始终在你手上——这正是产品经理不可被替代的部分。
说规格是唯一事实来源，其实漏了一句：在 AI 时代，最高保真的「事实来源」不是文档，是那个正在你眼前跑着的产品。
所以，今天该信什么
别在「vibe coding」和「spec-driven」之间选边站，那是个假二选一。
- 别像 vibe coding 那样，啥也不想、把脑子外包给 AI。
- 也别像写重规格那样，把 AI 时代刚帮你卸掉的文档负担又背回身上。
- 走中间这条：把话说清楚（你本来就会），让高保真原型替你说话（AI 帮你做到），小步推进，守住安全网。
这不是又一套要你学的新框架——框架已经够多了。这是回到产品经理最朴素的那个动作：想清楚要什么，说明白，然后让它跑起来。
言出，法随。
讨论