讓你先做產品MVP的，都是騙子

全文大概1400字 | 閲讀大概需要4分鐘

做垃圾變容易咗，改垃圾冇變平

作者 | Zerox在探索
編輯 | Zerox在探索

今日見到即刻上一個博主發咗一張圖，好似係俾大廠員工嘅小掛件之類嘅嘢，上面寫住：「先做個垃圾出嚟，唔好諗住一次成功。」

呢句話十年前，可能我都會講，而且之前一定都覺得呢套邏輯冇乜毛病。

但係今日見到呢句話，好想反駁一下。

「先做垃圾」嘅初衷冇問題。打破完美主義，唔好喺分析同論證裏面死捱。但係大多數人聽到嘅係「先做垃圾，反正後面可以改」。原來嘅「先驗證假設」冇人記得了。

MVP嘅本意係咩？用最少嘅精力，驗證一個核心假設。注意，係驗證假設，唔係做一堆乜都做唔好嘅嘢上線。

喺AI時代，呢件事變得更加凸顯咗。因為做垃圾變容易咗，但係「改垃圾」冇變平。

之前見到一個好典型嘅例子。Lalit Maganti係Google嘅工程師。佢用Claude Code花咗一個月做SQLite開發工具。功能都跑得到。但係幾個代碼文件長到幾千行，極度脆弱。最後佢全部推倒，用Rust從零重寫。

佢覆盤嘅時候講咗句話我覺得好典型：

「AI令到我在設計決策上拖延。因為重構好平，我成日話以後再講。但係拖延決策會腐蝕你嘅思考能力，因為代碼庫一直處於混亂狀態。」

眾所周知，2025年2月，Andrej Karpathy發咗條推文，造咗個詞叫「Vibe Coding」。而家冇人唔知。

但係好多人忽略咗佢嗰句話嘅後半段。佢話呢個適合「一次性的週末項目」。

可而家呢？Y Combinator 2025冬季批次25%嘅創業公司代碼95%係AI生成嘅。

有個實驗非常有趣，而且好說明問題。METR做咗隨機對照試驗，經驗豐富嘅開發者用AI工具反而慢咗19%。但係佢哋自己覺得快咗20%。自己覺得快同真係快，呢係兩回事。

劃重點：寫代碼嘅成本確實趨近於零咗。但係「判斷做咩」同「點樣將需求講清楚」嘅成本，喺飆升。

MVP驗證嘅係方向。呢個功能有人用咩？痛點係真嘅咩？呢一步係用嚟解決方向性風險嘅。

規劃解決嘅係另一件事 → 點樣做先唔會做到一半改唔鬱？點樣做先唔會架構崩咗返工？呢啲叫執行效率。

獨立做過中型項目嘅朋友，大概率有呢個體會。一開始冇規劃，先搓咗個MVP出嚟，覺得先跑起來先講。然後基於呢個MVP往上加功能。加嚇加嚇就發現唔對路。模型記唔住之前寫嘅嘢，每次對話都好似失憶咁。更加麻煩嘅係冇明確嘅spec同plan，AI每次生成嘅代碼風格都唔同。後續維護好似打地鼠咁。邊度冒頭敲邊度。越改越亂，越亂越唔敢改。到最後維護成本大到你自己都頂唔順。只能放棄，另起爐灶。

所以其實問題就在於一開始就冇想清楚架構同邊界。

所以，講咗咁多，咩先係啱嘅呢？我覺得核心係3步（歸根結底其實都係思維上嘅工程優化）。

第一，輕量驗證甚至唔使寫代碼，畫個原型demo、俾幾個身邊人睇下，核心係排除偽需求。

第二，認真規劃驗證通過咗，花時間諗清楚架構、模塊邊界、接口定義。喺呢步，再次強烈推薦superpowers呢個技能包，邊個用邊個知。

第三，vibe執行基於規劃，用自然語言驅動AI分模塊實現。

回看過去幾十年嘅產品開發同軟件工程，值錢嘅一直係「點樣寫」（比比程序員同產品經理邊個嘅人工高就知啦）。邊個寫代碼快、寫得穩，邊個就有價值。

而而家「點樣寫」正在被AI接管。一個唔識編程嘅人，只要描述能力夠強，配合好嘅規劃，就能做出可用嘅產品。

判斷咩值得做，以及點樣將呢個判斷講清楚令AI準確執行，呢啲先係而家值錢嘅嘢。

下次你想「先做個垃圾出嚟」嘅時候，停一下，或者先規劃清楚，比先做出嚟，更加重要。

全文約1400字 | 閲讀大約需要4分鐘

做垃圾變容易了，改垃圾沒變便宜

作者 | Zerox在探索
編輯 | Zerox在探索

今天看到即刻上一個博主發了一張圖，似乎是給大廠員工的小掛件之類的東西，上面寫着："先做個垃圾出來，別想着一次成功。"

這話十年前，可能我也會說，而且之前一定也覺得這套邏輯沒啥毛病。

但今天看到這句話，很想反駁一下。

"先做垃圾"的初衷沒問題。打破完美主義，別在分析和論證裏死耗着。但大多數人聽到的是"先做垃圾，反正後面可以改"。原來的"先驗證假設"沒人記得了。

MVP的本意是什麼？用最少的精力，驗證一個核心假設。注意，是驗證假設，不是做一堆什麼都做不好的東西上線。

在AI時代，這件事變得更凸顯了。因為做垃圾變容易了，但"改垃圾"沒變便宜。

之前看到一個很典型的例子。Lalit Maganti是Google的工程師。他用Claude Code花了一個月做SQLite開發工具。功能都能跑。但幾個代碼文件長到幾千行，極度脆弱。最後他全部推倒，用Rust從零重寫。

他覆盤的時候說了句話我覺得很典型：

"AI讓我在設計決策上拖延。因為重構很便宜，我總說以後再說。但拖延決策會腐蝕你的思考能力，因為代碼庫一直處於混亂狀態。"

眾所周知，2025年2月，Andrej Karpathy發了條推文，造了個詞叫"Vibe Coding"。現在無人不知。

但很多人忽略了他那句話的後半段。他說這適合"一次性的週末項目"。

可現在呢？Y Combinator 2025冬季批次25%的創業公司代碼95%是AI生成的。

有個實驗非常有趣，且很說明問題。METR做了隨機對照試驗，經驗豐富的開發者用AI工具反而慢了19%。但他們自己覺得快了20%。自己覺得快和真的快，這是兩碼事。

劃重點：寫代碼的成本確實趨近於零了。但"判斷做什麼"和"怎麼把需求說清楚"的成本，在飆升。

MVP驗證的是方向。這個功能有人用嗎？痛點是真的嗎？這一步是用來解決方向性風險的。

規劃解決的是另一件事 → 怎麼做才不會做到一半改不動？怎麼做才不會架構崩了返工？這叫執行效率。

獨立做過中型項目的朋友，大概率有這個體會。一開始沒規劃，先搓了個MVP出來，覺得先跑起來再說。然後基於這個MVP往上加功能。加着加着就發現不對了。模型記不住之前寫的東西，每次對話都像失憶了一樣。更麻煩的是沒有明確的spec和plan，AI每次生成的代碼風格都不一樣。後續維護跟打地鼠似的。哪裏冒頭敲哪裏。越改越亂，越亂越不敢改。到最後維護成本大到你自己都扛不住。只能放棄，另起爐灶。

所以其實問題就在於一開始就沒想清楚架構和邊界。

所以，說了這麼多，什麼才是對的呢？我覺得核心是3步（歸根結底其實還是思維上的工程優化）。

第一，輕量驗證，甚至不用寫代碼，畫個原型demo、給幾個身邊人看看，核心是排除偽需求。

第二，認真規劃，驗證通過了，花時間想清楚架構、模塊邊界、接口定義。在這步，再次強烈推薦superpowers這個技能包，誰用誰知道。

第三，vibe執行，基於規劃，用自然語言驅動AI分模塊實現。

回看過去幾十年的產品開發和軟件工程，值錢的一直是"怎麼寫"（比比程序員和產品經理誰的工資高就知道了）。誰寫代碼快、寫得穩，誰就有價值。

而現在"怎麼寫"正在被AI接管。一個不會編程的人，只要描述能力夠強，配合好的規劃，就能做出可用的產品。

判斷什麼值得做，以及怎麼把這個判斷說清楚讓AI準確執行，這才是現在值錢的東西。

下次你想"先做個垃圾出來"的時候，停一下，也許先規劃清楚，比先做出來，更重要。