Vibe Coding 已經過時了——而這對產品經理是好消息
2026 年，最早把「vibe coding」這個詞帶火的 Andrej Karpathy，站上台宣布它已經過時。他用來取代它的新說法叫 agentic engineering（智能體工程），並把它拆成一串動作：寫設計規格、監督計畫、審查 diff、寫測試、搭評估循環、管理權限、守住品質。
把這串清單裡的工程師術語去掉，再讀一遍。決定該做什麼；檢查結果是否符合意圖；定義「夠好」的標準，並拒絕低於它的東西上線。這根本不是什麼新學科。正如 Jeff Gothelf 所說：做判斷的那個版本，才是這份工作本身——它從來都是。 AI 只是把我們過去用來藏住它的地方，全拆掉了。
這是當下做產品的人最該記住的一個轉變。而它指向的方向，多數人第一反應是「反常識」。
留下來的能力，不是寫程式
過去十年，「學會寫程式」是所有有產品想法的人聽到的標準建議。2026 年，這個建議悄悄反轉了。當 AI 智能體能把一個說清楚的問題變成可執行的軟體，寫文件不再是工作本身——意圖、清晰、判斷，才是工作。 這一年真正重要的人，業界已經有了稱呼，而且不是「提示詞工程師」。Product School 的判斷很直接：在 2026 年，真正算數的產品經理，是 AI 產品經理。
具體怎麼做，也佐證了這一點。關於「AI 原生產品經理到底做什麼」，業界的共識收斂成了三個動作：
- 描述：把你想要的東西說清楚到，一個有能力的智能體能照著動手。
- 拆解：把問題切成小到可以逐一驗證的塊。
- 判斷：評估產出是否符合意圖——並決定在那不符合的 15% 裡，該怎麼辦。
這三件事，沒有一件是寫程式。三件，都是產品管理。
為什麼不懂程式反而是優勢
接下來這段聽起來不對，但它沒錯。會寫程式的人，腦子後台永遠跑著一個估算：這玩意兒實作起來有多麻煩。 當你是動手的那個人，這個估算很有用；可當你是決定什麼東西該存在的那個人，它就成了包袱——想法還沒出口，就先被實作成本修剪、定型，而不是被用戶價值。
如果你不會寫程式，就沒有這層條件反射。你手裡只剩下開局最重要的那兩個問題：用戶到底需要什麼？這個體驗對不對？然後你的活兒，就是把它說清楚。而「把想法說清楚」，是產品經理最古老的看家本事。
這不是在為「不學」辯護。這是在說：瓶頸挪位置了。稀缺的不再是你在編輯器裡敲字的速度，而是你所要求的那個東西，本身有多清晰。
「言出法隨」是一套方法，不是憑感覺
但有個前提：vibe coding 拿到那份訃告，是有原因的。當你提示得很隨意，每一次執行都會漂移——設計師們已經注意到，AI 原型填上了過去線框圖占的位置，可同一個提示詞每跑一次，結果都微妙地不一樣，這種語義漂移會迅速放大。意圖含糊地進去，產品就不一致地出來。
所以答案不是「把提示詞憋得更用力」，而是帶著紀律去做。這套紀律，我們叫它 DO AI PM，落到幾條承諾上：
- 高保真優先。 跳過線框圖，直接做能跑的真東西——真實內容、真實狀態（載入 / 空 / 錯誤 / 成功）、真實互動——然後靠實際執行來驗證它。一個能跑的原型，永遠贏過一個被描述的原型，包括在做決定的那個會議室裡。
- 五個階段，小步走。 發現 → 定義 → 設計 → 開發 → 驗證。在「定義」階段，讓 AI 先反問你，再寫規格；在「開發」階段，一次只改一件事。
- 一張安全網。 原型裡不放真實金鑰和正式環境資料；不可逆的按鈕——發布、刪除、付款——由人來按；不碰正式環境；拿不準，就問。
最後這串，正是「我撞運氣蒙對了一個提示詞」和「下週一我還能再做一次」之間的區別。
成果即證據
只會自我解釋的方法，一文不值。所以這裡的每一句，背後都是用同一套方法、用 Claude Code 做出來的真實產品：SoloMD（Markdown 編輯器）、Unterm（AI 能操作的終端機）、unfetch（人和 AI 都能用的下載器）、StoryAlter（學你文風的 AI 寫作助手）、Unflick（人和 AI 都能用的播放器）。你正在看的這個網站——八種語言、這個部落格、那幾頁演示稿——也是用同樣的方式「說」出來的，沒有一行程式是手寫的。
方法解釋作品，作品證明方法。
Karpathy 沒說錯，vibe coding 結束了。可取代它的，不是一種更難的工程——而是「把決定做好、把意圖說清」的紀律。這件事有名字，而現在，正是幹這份活兒的好時候。
想真切體會一下「言出法隨」是什麼感覺，從方法論中心開始。
延伸閱讀
討論