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 幫你做到），小步推進，守住安全網。
這不是又一套要你學的新框架——框架已經夠多了。這是回到產品經理最樸素的那個動作：想清楚要什麼，說明白，然後讓它跑起來。
言出，法隨。
討論