AI App 越做越多，為什麼沒人用？a16z 數據揭露 Vibe Coding 的真正瓶頸
AI coding 讓 App 供給暴增，但使用者注意力、測試、發行與留存沒有同步擴張。本文解析 a16z 與 NBER 最新數據。
AI 讓做 App 變得前所未有地容易，但容易做出來，不代表有人願意用。
2026 年 9 月，a16z 發布一組很有衝擊力的圖表：從 2025 年初開始，iOS、Android 與 Chrome 商店的新 App 數量快速增加，下載與評分卻沒有同步成長。a16z 甚至用一句很重的標題形容這個現象：App 成長呈拋物線，但幾乎沒人在用。
這個說法抓到了問題核心，卻不能照字面理解。資料沒有顯示新 App 完全無人使用，真正的問題是新增供給遠快於新增需求，多數新產品只分到更少的注意力。
更值得注意的是，這不代表 AI 寫程式沒有提高生產力。最新研究反而顯示，開發者產生的程式碼與提交次數大幅增加，只是當工作走到審查、測試、發行與取得使用者時，增幅一層一層縮小。
本文會拆解三個問題：App 到底增加多少、AI coding 的生產力去了哪裡，以及創業者和科技投資人接下來真正該看的指標是什麼。
先講結論：AI 降低的是製作成本，不是成功成本
我對這組資料的判斷很明確：AI coding 值得使用，但「會做 App」正在快速失去稀缺性。
過去，寫程式的時間與工程能力是產品能否問世的重要門檻。現在開發者可以用 AI 產生介面、串接資料庫、補測試，甚至把一整個任務交給 coding agent。Coding agent 是能讀取專案、修改檔案並執行工具的 AI 程式助手，比單純補上一行程式碼更接近可分派工作的數位工程師。
當這個門檻下降，產品的瓶頸就往後移。需求判斷、品質控制、App 商店曝光、品牌信任、使用者留存與付費，反而變得更重要。
換句話說，AI 沒有消滅軟體產品的難度，只是把難度從「能不能做」移到「為什麼有人要用」。
App 真的變多了：iOS 每月新上架數量增至約 10.8 萬款
這組討論的主要資料來源，是 2026 年 9 月修訂的 NBER 工作論文《Writing Code vs. Shipping Code》。研究團隊分析 Apple App Store、Google Play Store、Chrome Web Store 與 SourceForge，觀察 AI coding 普及前後的軟體供給。
三個主要 App 商店的走勢不完全一樣，但共同方向很清楚。
| 平台 | 2025 年初附近 | 2026 年最新觀察 | 怎麼解讀 |
|---|---|---|---|
| iOS | 每月約 3.3 萬至 4.5 萬款新 App | 2026 年 4 月約 10.8 萬款 | 2025 年後明顯加速，增加超過一倍 |
| Android | 2025 年 1 月約 4.2 萬款 | 2026 年中約 9.9 萬款 | 扭轉多年下滑並快速回升 |
| Chrome | 2023 年低基期 | 至 2026 年約增加 7 倍 | 成長早於 AI Agent 熱潮，不能全部歸功於 AI |
研究把 2025 年 2 月視為「代理式寫程式時代」的起點。代理式寫程式，是指 AI 不只提供建議，還能自行修改多個檔案、執行指令並完成一段任務。這個時間點與 GitHub Copilot Agent Mode 等工具推出大致重疊。
但時間重疊不等於完整因果。Chrome 外掛在 2025 年以前就已加速成長，Android 則是從長期下滑中反彈。較安全的結論是：AI coding 與新 App 供給增加發生在相近時期，而且開發者層級的資料也支持 AI 確實提高產出。只是我們不能把每一款新增 App 都算成 AI 的功勞。
供給增加，需求卻沒有同比例擴張
App 數量變多本身未必是壞事。更多產品可能服務更小眾的需求，即使每款下載不高，加總起來仍可能創造新的價值。
研究因此沒有只看單一熱門 App，而是把每個月新上架的產品視為一組，追蹤它們上市後三個月的總使用表現。由於 Apple 不公開下載數，iOS 使用評分數量作為代理指標。Android 與 Chrome 則使用下載或安裝相關資料。
結果是：
- iOS 新 App 的三個月總評分大致持平。
- Android 新 App 的下載量只有小幅增加，遠低於上架數增幅。
- Chrome 新外掛的下載量下滑，但這個跌勢在 2025 年前就已開始。
研究又檢查有多少新產品連很小的受眾門檻都沒跨過。2025 年 1 月到 2026 年 4 月之間，iOS 新 App 在三個月內少於 10 個評分的比例，從約 78% 升至 87%。Chrome 少於 10 次下載的比例從約 19% 升至 33%，Android 至多 100 次下載的比例則由約 22% 升至 26%。
這些數字不代表「所有 AI App 都失敗」，它顯示的是新增產品越來越集中在幾乎沒有被看見的長尾。App 商店的貨架快速變長，進店的人數卻沒有用同樣速度增加。
AI 寫程式到底有沒有效？有效，但效果卡在流程後段
如果只看 App 使用量，可能會得到另一個過度簡化的結論：AI coding 只是製造垃圾，沒有真正提高生產力。
開發者資料並不支持這個說法。
NBER 研究結合超過 50 萬名 GitHub 開發者的公開活動與 Microsoft 內部使用紀錄，再用「配對事件研究」比較採用 AI 工具前後的變化。配對事件研究是替每位採用者找活動程度相近的對照組，觀察工具出現後兩者是否走出不同趨勢。它比單純比較使用者與非使用者更嚴謹，但仍不是隨機實驗。
研究把工具分為三代：
- 自動補全：開發者打字時，AI 接著補程式碼。
- 同步 Agent：AI 與開發者同時工作，可跨檔案修改與執行任務。
- 非同步 Agent：開發者交付任務後，AI 可以在雲端自主工作，再送回成果供人審查。
2026 年 9 月修訂版顯示，三個世代帶來的每週 commits 累積增幅約為 30%、180% 與 240%。Commit 是開發者把一組程式變更存入版本紀錄的動作，可以反映開發活動，但不等於產品已經交到使用者手上。
到了真正的 releases，也就是可供使用的版本發行，最高累積增幅只剩約 30%。以同步 Agent 為例，程式碼行數增加約 958%，pull requests 增加約 86%，release 卻只增加約 20%。Pull request 是把一批程式變更送交團隊審查、準備合併的流程。
這組落差說明，AI 大幅加快了工作前段，後段卻沒有等比例擴容。程式碼仍要整合、審查、測試、修正安全問題，最後還要有人判斷這項功能是否值得發布。
更多程式碼，也帶來更多試錯與返工
研究進一步追問：前段增加的產出去了哪裡？一部分答案是試錯。
採用同步 Agent 後，開發者新增的程式碼行數約增加 7 倍，刪除的行數卻增加約 12.2 倍，建立的 branch 也增加約 79%。Branch 是獨立開發分支，常用來嘗試功能或修正問題。分支增加代表團隊可以同時探索更多方向，但不保證每個方向都會保留下來。
另一個訊號來自新專案。新 repository 建立一個月後再也沒有活動的比例，從 2021 年約 60% 升到 69%。Repository 是存放專案程式碼與歷史紀錄的空間。
這不必然代表 AI 產出的程式碼品質很差。當試作成本降低，團隊本來就會測試更多點子，也會更快放棄不值得繼續的方向。問題是，如果公司只用程式碼行數、commit 或原型數量衡量成效，就會把「更便宜的試錯」誤認成「更多成功產品」。
真正有意義的指標，應該繼續追到功能被採用、問題真的解決、使用者持續回來，甚至願意付費。
App 經濟沒有崩潰，成長只是集中在少數類別
a16z 的原始分析另外引用 Sensor Tower 的美國市場估計，補上收入與使用時間這一面。截至 2026 年 9 月 15 日，過去約一年半，美國 App 整體收入約增加 2%，使用時間約增加 7%。
因此，App 市場沒有全面萎縮。更接近資料的說法是：供給暴增沒有帶來整體收入爆發，成長高度集中在少數類別。
其中最突出的就是 Productivity，也就是生產力工具。ChatGPT、Claude、Gemini 與 Grok 帶動使用時間與收入同時明顯成長。Developer Tools 也有突出表現，Replit 是主要推力之一，但這個類別的總規模仍較小。
相對地，遊戲的使用時間與收入在圖表中約下滑 3% 與 15%。Lifestyle 收入約下滑 30%，Books 收入約下滑 40%。這些是圖表的近似讀值，而且只涵蓋美國市場，適合用來看方向，不能當成全球 App 產業的精確損益表。
這也解釋了看似矛盾的現象：**人們很愛用 AI App，卻不一定愛用 AI 做出來的每一個 App。**少數大型 AI 產品創造可觀需求，大量低成本新產品則在同一時間爭奪有限的注意力。
真正的瓶頸有兩種：產品品質，或注意力塞車
看到新 App 使用量偏低，很容易把原因全部歸咎於品質。研究作者沒有走得這麼遠，因為資料至少容許兩種解釋。
第一種是供給端問題。AI 讓開發者更容易把半成品推到商店，但測試、打磨、資訊安全、客服與產品市場契合仍需要大量工作。程式可以運行，不代表產品解決了值得付費的問題。
第二種是需求端塞車。App 商店的搜尋排名、推薦版位、社群口碑與使用者時間並不會隨 App 數量自動增加。即使新產品平均品質沒有變差，當供給翻倍，每款 App 能分到的曝光也可能下降。
目前資料無法完全分辨兩者。研究只追蹤新 App 上架後三個月，慢熱產品可能還沒累積口碑。評分與下載也無法完整代表留存、收入或使用者實際得到的價值。
因此，我不會把這份研究解讀成「Vibe Coding 已經失敗」。Vibe Coding 是用自然語言指揮 AI 寫程式、反覆修改產品的開發方式。這份資料更像是一個提醒：當做產品的人變多，市場不會自動替每個人增加需求。
Vibe Coding 時代，護城河正在換位置
對創業者來說，最危險的錯覺是把「原型做完」當成「產品完成」。AI 可以在幾天內做出過去需要數週的功能，但它不會自動回答誰真的需要、為什麼要換掉既有工具，以及使用者下週還會不會回來。
接下來更稀缺的能力有四種：
| 稀缺能力 | 該問的問題 | 比產出量更有用的指標 |
|---|---|---|
| 找對需求 | 這個問題是否高頻、昂貴或令人痛苦？ | 訪談轉換率、啟用率、主動回訪 |
| 做到可靠 | 使用者能否放心把真實工作交給產品？ | 錯誤率、人工接管率、事故數 |
| 贏得分發 | 使用者如何第一次發現產品？ | 取得客戶成本、自然流量、推薦率 |
| 建立留存與付費 | 產品是否持續創造可感知的價值？ | 次週／次月留存、付費轉換、流失率 |
對科技投資人來說，判斷方式也要跟著改。看到一家公司宣稱大量功能由 AI 生成、開發速度提升數倍，這只能證明它降低了部分成本，不能直接證明需求、定價權或護城河。
我會更在意它是否掌握專有資料、深度嵌入工作流程、擁有低成本分發，或者能把可靠度做到競爭者難以複製。若這些條件都沒有，「做得快」很可能只會換來更快進入同質化競爭。如果想理解 AI Agent 如何從回答問題走向執行工具，也可以從實際產品介面切入。
這份研究還有哪些限制？
這份論文提供了少見的大規模真實資料，但仍有幾個不能忽略的邊界。
首先，它是 NBER 工作論文，代表研究已公開供學術討論，但不能直接視為已完成同儕審查的定論。論文從 2026 年 5 月到 9 月就曾擴大樣本並更新效果數字，也提醒我們結論仍可能隨版本修訂。
其次，GitHub 資料主要涵蓋公開與開源活動，企業內部系統代表性較弱。研究使用的配對方法降低了部分偏差，卻無法排除本來就更積極的開發者更早採用 AI 工具。
再次，App 市場資料是描述性趨勢。2025 年後的 App 供給上升與 coding agent 普及時間接近，但 Figure 11 本身沒有證明 AI 是唯一原因。
最後，兩位作者披露過去曾在 Microsoft 從事博士後研究，目前是 Microsoft 的付費研究顧問。這不會自動否定研究，但讀者在解讀結論時，應連同資料無法完全公開重現的限制一起考量。
常見問題 FAQ
AI 寫程式真的讓 App 數量增加了嗎？
資料顯示兩者在時間上高度重疊，而且開發者採用 AI coding 後，commit、pull request 與 release 都有增加。不過 App 商店的趨勢分析不是因果實驗，Android 反彈與 Chrome 較早開始的成長也可能受到其他因素影響，因此不能說所有增量都由 AI 造成。
為什麼 App 變多，下載量卻沒有一起增加？
使用者的時間、App 商店曝光與口碑通道沒有跟著供給擴張。另一個可能是很多產品雖然能上架，卻還沒有完成測試、打磨與需求驗證。現有資料無法把品質與分發兩種原因完全拆開。
這代表 Vibe Coding 沒有價值嗎？
不代表。Vibe Coding 能降低原型、內部工具與客製軟體的製作成本，這是真實價值。它只是不能取代產品研究、品質管理、分發與營運。
Commit 增加 240%，為什麼 release 只增加約 30%？
Commit 只是儲存一組程式變更，release 才是可供使用的版本。中間還有整合、審查、測試、安全檢查與發行等工作。AI 主要加速前段，後段仍需要大量人類判斷，因此效果逐層縮小。
創業者現在最該看哪個指標？
不要只看生成多少程式碼或推出多少功能。更值得追蹤的是啟用率、次週與次月留存、付費轉換、流失率、錯誤率，以及使用者是否主動推薦產品。
結語：軟體沒有變簡單，難題只是往後移
AI coding 已經證明自己能增加程式產出，也讓更多人有能力把想法做成 App。這是一次真正的供給革命。
但供給革命不等於需求革命。研究看到的現況是：程式碼、commit 與新 App 快速增加，release 的增幅小得多，使用者注意力更沒有同比例擴張。
因此，我對 AI coding 工具的價值偏多，對「大量新 App 會自然變成大量新商業價值」則偏空。下一批真正的贏家，不會只是最會生成程式碼的團隊，而是最早看懂需求、把品質做穩，並建立分發與留存優勢的人。
當人人都能做 App，最稀缺的就不再是 App，而是讓人願意留下來的理由。
