你的 MVP 不該再是「最小化」了

對於在 2026 年用 AI 平台建構產品的人來說，最小可行產品是個糟糕的建議。嚴格來說並不算錯誤的建議——而是一個已經不存在的世界留下來的建議，之所以還被不斷重複，只是因為它讀起來順口，又剛好能塞進投影片裡。

Eric Ries 在 2011 年提出 MVP 概念時，是為了那些瓶頸在於工程師工時的團隊。如果一項功能要花三週才能完成，而你不確定有沒有人想要它，那麼縮小範圍就是唯一理性的做法——因為你在分配一項真正稀缺的資源。這就是為什麼「最小」這個字在這個詞裡承擔了關鍵意義的原因。它不是一種關於產品品味的哲學，而是在一種成本結構下的取捨：建構的成本很高，唯有先建構得少，才能讓「驗證」變得便宜。

成本結構翻轉了

當你是透過「對話 → 規劃 → 執行」的流程來建構，而不是透過衝刺看板時，邊際功能不再需要花三週。它只需要一個提示詞和一次驗證流程。過去昂貴的那件事——撰寫程式碼——現在幾乎是免費的。現在真正昂貴的事情，是搞清楚該建構什麼，以及上線後從嘈雜的使用者行為中讀出有意義的訊號。MVP 理論是為第一個限制條件所優化的。但幾乎沒有任何在 AI 平台上建構的人，現在還受限於這件事了。

所以當一位創辦人只上線了一個登入畫面和一個功能，就稱之為 MVP，說是為了「快速學習」時，他們通常並不是在分配任何稀缺資源。他們只是在套用一套適用於另一種經濟環境的建議，而這麼做的結果，是推出了一個太單薄、根本產生不了真正訊號的東西。五個人試用一個單一功能的應用程式，三個人馬上就跳出，而你幾乎什麼都沒學到，只知道一個被閹割過的應用程式感覺就是被閹割過。這不是精實，這只是小。

把最後那一行再讀一次。極簡主義的整個理由,是為了保護一項資源,而這項資源現在對你來說根本不稀缺。你正在承受舊規則的代價——更薄弱的測試面、更弱的留存訊號、因為產品感覺未完成而不是點子不好而流失的使用者——卻沒有獲得它過去帶來的好處。

「建構得更廣」實際上代表什麼

我不是說要把你能想到的一切都做出來。我的意思是,在你開始尋找使用者之前,先把這個東西完整、顯而易見的樣貌建構出來——新手引導、核心循環、你這個類別中每個人都有的那一項相鄰功能、讓它感覺像軟體而非原型的設定頁面。如果你在做習慣追蹤器,那就是連續紀錄、提醒和歷史紀錄檢視,而不是只有連續紀錄。如果你在做小眾市集,那就是上架資訊、訊息通訊,以及某種信任訊號(評論、驗證,任何一種),而不是上架資訊外加一個聯絡表單就了事。

測試標準不是「我能把這做得多小」,而是「陌生人會誤以為這是成品的最小版本是什麼樣子」。這是不同的門檻,通常需要三到四項功能的廣度,而不是一項。在這樣的平台上,每一項功能只是一個規劃步驟和一次驗證,而不是一項聘僱決策,在第一週就達到這個標準,是一件在 2011 年根本不可能實現、但如今切實可行的事。

我曾在這件事上早早吃過虧。我為朋友的工作室建構了一個小工具——單一畫面、單一功能,做得又快又「精實」。結果沒人用,我告訴自己這是市場給出的答案。但其實不是。而是因為這個工具跟他們工作流程中其他有三個分頁的東西比起來顯得未完成,所以沒人信任到願意把它變成習慣。點子本身沒問題,問題出在形態,而我當初正是因為認為「薄」是一種美德才刻意做薄了它。

批評者說對的地方

反對這個觀點的人確實有道理,而且不是關於工程成本的那種道理——是關於注意力的。建構五項功能已經不再耗費你數週的開發時間,但仍然會耗費你數週的決策時間,也會耗費使用者的理解成本。更廣的第一版意味著更大的驗證範圍、更多可能藏著漏洞的角落、更多需要撰寫的新手引導、新使用者在核心循環真正上手之前得學習更多東西。如果你建構得很廣,但核心循環是錯的,那你現在把訊號打散在五項功能中,而不是一項,要釐清究竟是哪一項害了留存率,會比單一乾淨測試花更久的時間。範圍紀律依然重要——只是現在瞄準的目標不同了。過去的 MVP 約束的是你的建構時間;適合這個時代的版本約束的是你的決策時間:挑出那幾項能讓產品感覺真實的功能,把超出這個範圍的東西無情地砍掉,並抵抗「因為建構便宜就不斷加功能」的誘惑。建構便宜不代表維護、解釋或在出問題時排查也一樣便宜。

所以要建構得比直覺告訴你的更廣,因為那個曾經讓「最小」成為正確字眼的限制已經不存在了。但要保留當初讓 MVP 成為好點子的紀律——只是把它指向上線後的範圍蔓延,而不是你的第一版。