AI 時代還要不要先做 MVP？2.11 億行程式碼測出返工率從 3.3% 漲到 7.1%
你把一個想法丟給 AI，十次裡有八次，它第一句回你的是「我們先做一個最小可行版本」。
這句話聽起來像判斷。它是回憶。Agile Manifesto 是 2001 年的，《The Lean Startup》是 2011 年的，這兩份東西和它們衍生出來的幾十萬篇部落格、課程、事後檢討，全在 AI 的訓練資料裡。它推薦迭代，不是因為它算過自己的帳。
它算的是人的帳。而這兩張帳單的結構，正好是相反的。
MVP 成立的四條前提，今天還剩三條
迭代不是自然規律，是一組具體約束下的最佳解。那組約束長這樣：
- 寫程式碼慢且貴。 一個功能從想清楚到能跑，以人天計。
- 改程式碼比寫程式碼更貴。 改要先讀懂，讀懂要重新進入別人（或三個月前的自己）的腦子。
- 需求會在過程中變準。 使用者看到東西才知道自己要什麼，所以早點拿出東西給他看有收益。
- 最關鍵的一條：簡陋實作和完整實作之間，有巨大的成本差。
最後這條是 MVP 的經濟學地基。先用 localStorage 存著，先不做權限，先寫死幾個設定——省下來的那幾週是真的，省下來之後拿去驗證假設，也是真的划算。
四條約束裡，前三條今天還成立。第四條沒了。
localStorage 和 PostgreSQL，在 AI 手裡差幾分鐘
V2EX 上有個貼文把這件事說得最乾淨（t/1216691，標題就叫「AI 編程時代，MVP 思維已經失效了？」）。樓主的原話是：用 Cursor 描述「用 localStorage 存資料」和描述「用 PostgreSQL 加連線池」，生成時間差不了幾分鐘。
既然成本一樣，為什麼要做簡易版？
這一句話就把地基抽掉了一半。你省下的不再是幾週，是幾分鐘；而你為此欠下的東西——一套要被替換掉的儲存層、一批基於它寫的呼叫、一份要重來的遷移——一樣都沒少。
簡陋不再便宜，它只是不再完整。
AI 的帳單：脈絡才是成本主體
第二半地基塌在成本結構上，這一層比第一層更隱蔽。
跑一次 agentic 任務，輸入 token 的大頭從來不是你那句任務描述。是系統提示、是儲存庫地圖、是對話歷史、是它讀過的檔案。任務描述在裡面佔的比例小到可以忽略。
由此推出的幾條，都能查到實測：
- 每次重試，整份脈絡重發一遍。兩次重試就能把一次工作階段的成本變成三倍。
- 算上脈絡開銷，真實成本是裸算的 3 到 5 倍，一個 PR 落在 0.27 到 3.25 美元之間，複雜儲存庫裡單個任務超過 20 美元也很正常。
- arXiv 上那篇《Cheap Code, Costly Judgment》（2607.01087）測出來，agentic 任務消耗的 token 是普通程式碼對話的 1000 倍，而且同一個任務重複跑，token 消耗的變異數最高到 30 倍。
現在把人和 AI 的迭代放在一起算。
人分三期做一件事，每一期的成本差不多。因為人記得上一期幹了什麼——脈絡裝在腦子裡，呼叫它不要錢。
AI 不記得。它每一期都要把脈絡重新買一遍。
| 同樣是分三期 | 人 | AI |
|---|---|---|
| 每期的主要成本 | 幹活本身 | 重建脈絡 |
| 上一期的記憶 | 在腦子裡，呼叫免費 | 不存在，必須重新載入 |
| 三期總成本 | ≈ 三份工錢 | ≈ 三份工錢 + 兩次重建費 |
| 多切一刀的邊際代價 | 一次溝通 | 一次完整的脈絡重購 |
| 迭代買到的東西 | 少走錯路的機會 | 同樣的機會，但要另外付摩擦費 |
迭代對人是買保險，對 AI 是交摩擦費。
GitClear 把返工量出來了：3.3% → 7.1%
上面還是推算，下面是實測。
GitClear 分析了 2.11 億行變更程式碼，追蹤一個叫 churn 的指標——合併之後幾天內就被大幅重寫或刪除的程式碼佔比。它衡量的正是「第一次沒做對」。
| 年份 | churn |
|---|---|
| 2023 之前（基線） | 3.3% |
| 2024 | 5.7% |
| 2025 | 7.1% |
兩年翻了一倍多。同一份研究裡其他幾個指標指向同一個方向：
- 提交內複製貼上 +41%
- 程式碼區塊重複 +81%
- 錯誤掩蓋式寫法 +47%
- 跨檔案函式呼叫（複用的指標）−35%
- 重構式的程式碼移動 −70%
GitClear 把 AI 放大的返工分成三類，每一類都是「先交個半成品」的直接後果：
- 位置錯了——邏輯和語法都對，但放在了錯誤的架構位置，後來被人搬走
- 重複造了——重新實作一遍已有功能，而不是複用它
- 幾天後重寫——合併進去之後，因為邊界情況或者約定衝突被大幅改掉
同一批研究裡，AI 編寫的 PR 平均帶 10.83 個問題，人寫的是 6.45 個，1.7 倍。
開發者自己的感受對得上這組數字。Stack Overflow 2026 開發者調查裡：
- 84% 的人在用 AI 工具
- 45% 的人說偵錯 AI 生成的程式碼比自己寫還費時間
- 66% 的人說最大的挫折是 AI 給的東西「幾乎是對的，但不完全對」
- 而對 AI 輸出的信任度只有 3%
另有一份調查給出 43% 的 AI 生成程式碼變更需要在生產環境裡偵錯。
「幾乎對」這三個字是關鍵。它意味著問題不會在你驗收那一刻暴露，會在合併之後暴露——正好落在下一期迭代的頭上。你以為省下的那一輪，帳記在了後面。
「一次做好」不等於「一次做完」：交付粒度和執行粒度
到這兒最容易滑向一句口號：別迭代了，一次做完。那是錯的，而且是危險的錯。
要分開的是兩個粒度：
- 執行粒度：一次改一處，改完就驗證。這條今天照舊成立，甚至更重要——AI 一次動十個檔案，你根本審不過來。
- 交付粒度：這一輪交出去的東西，是不是成品。
「一次做好」說的是後者。它約束的是完成度，不是功能數量。
範圍可以很窄，窄到只有一個頁面、一個介面。但這一輪定下來要做的部分，得是完整的：真實的資料結構，不是佔位；載入、空、錯誤、成功四種狀態都在，不是只有理想路徑；能真的跑起來給人用，不是截圖。
MVP 這個詞最大的問題是它把「範圍窄」和「做得糙」打包賣了。以前它們確實綁在一起——想省錢只能兩個一起省。現在它們可以拆開：範圍仍然要窄，糙已經不省錢了。
「MVP 是驗證假設，跟 AI 無關」——四條反駁裡哪兩條站得住
那個 V2EX 貼文底下的反對意見比主貼更有價值。逐條看：
1.「MVP 的核心是驗證假設，跟程式碼無關，跟 AI 不 AI 也無關。」
站得住，而且它正好說明了問題出在哪：MVP 這個詞一直混裝著兩件事——驗證一個假設，和交付一個殘缺的實作。以前這兩件事必須綁在一起，因為驗證假設的唯一便宜辦法就是做個糙的。現在它們解耦了。假設照驗，但你可以拿一個完整的東西去驗。
2.「你永遠沒辦法一次性了解潛在使用者的所有需求。」
站得住，而且它跟「一次做好」不衝突。沒人要求你一次做完所有功能。要求的是你這次做的那部分別留半截。
3.「邏輯複雜的專案，尤其是有複雜業務迴圈和狀態機的軟體系統，一步到位結果就是一坨。」
這是真問題，但它是執行粒度的問題。複雜狀態機當然要一步一步來、每步驗證。它不構成「先交一個明知道要重寫的版本」的理由。
4.「有了 AI 迭代可以飛快，成本極低。」
這條不站得住。上面那兩節就是它的反例：快的是生成，不是收斂。churn 從 3.3% 漲到 7.1% 量的正是這個差。
把「禁止分迭代開發」寫進全域規則之後
我在自己的全域規則裡寫死了一條：禁止分迭代開發，交付即成品，不允許 MVP 和階段性交付。
落到具體動作上是這樣的：
- 第一輪就要求真實資料結構和真實內容，不許有 Lorem ipsum，不許有假資料
- 四種狀態一次交齊，載入、空、錯誤、成功
- 交付之前必須自己跑一遍，瀏覽器裡點開、命令列裡執行、介面用 curl 打一遍
代價是真實存在的：第一次描述要長得多。 你得在動手之前把邊界、狀態、資料結構想清楚，這部分工作沒被 AI 拿走，只是從「第三輪返工時被迫想清楚」挪到了「第一輪開始前主動想清楚」。
收益也很直接：不用第二次、第三次把同一件事重新講一遍。而重新講一遍，正好是上面那張帳單裡最貴的一項。
範圍該切多窄，AI 幫不上
這個問題仍然沒有答案。
「一次做好」的前提是範圍切對了。切得太寬，一次做好變成一次做很久；切得太窄，做出來的東西沒法驗證任何假設。這一刀切在哪，靠的是對使用者和場景的判斷——那篇論文的標題已經把話說完了：程式碼變便宜了，判斷沒有。
討論