AI 做的 App 為什麼沒人用？NBER 研究量出瓶頸在出貨

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 9 月，一份追蹤超過 50 萬名 GitHub 開發者的研究把「AI 寫程式到底有沒有用」的爭論往前推了一步：有用，而且效果很大，但效果幾乎全部停在寫碼端。自主跑任務的 AI 代理讓開發者的每週 commit 累積增加 240%，一路往下游走到真正可供下載的 release，只剩 30%。同一份研究再看四個軟體商店，看到的是同一件事的市場端版本：新 App 數量在 2025 年之後暴增，總使用量卻沒有跟著增加，而且連 10 個評分都拿不到的新 App 佔比還在上升。

這是 NBER 工作論文 w35275《Writing Code vs. Shipping Code》的九月修訂版結論，作者為 Mert Demirer、Leon Musolff 與 Liyuan Yang，2026 年 5 月首發、9 月更新。創投 a16z 隨後在 9 月 18 日的圖表週刊以「So Many Apps, So Little Time」為題引述這份論文，配上 Sensor Tower 的美國市場營收與使用時間估計，把現象定調為「App-Slop」：App 的供給在三大商店翻倍甚至翻四倍，使用的人沒有變多。一份學術論文加一份創投週刊，兩層資料互相咬合，值得把它們各自量到了什麼、沒量到什麼拆開來看。

Pin

寫碼端最多增加 240%，到出貨只剩 30%

研究團隊把 AI 寫程式工具分成三個世代，每一代的增益都比上一代大。論文摘要給出的數字是：自動補全讓 commit 增加 30%，與開發者並肩工作的同步代理增加 180%，自己接任務跑到完成的非同步代理增加 240%。這裡的 commit 指開發者把一批程式變更存入版本控制的動作，是寫碼活動量的直接訊號。

問題出在下一層。240% 的寫碼增益，換到「開發者觸及的專案數」剩下 80%，換到真正發布、別人拿得到的 release，剩下 30%。同步代理的對比更極端：程式行數增加 958%、pull request 增加 86%，release 只增加 20%；自動補全則是行數增加 234%、release 只增加 9%。寫得越多，出貨的比例越低，三個世代全部呈現同一個形狀的衰減。

論文用「弱環節」解釋這個形狀：軟體從寫出來到上架，中間要經過整合、審查、測試與打磨，最後還要有人判斷這個功能值不值得發布，這些環節大部分仍然是人力在做。研究估計 AI 與人力之間的替代彈性只有 0.23，數字越低代表兩者越難互相取代，也就是 AI 產出的程式碼必須等人的環節消化完，才會變成產品。上游提速，下游不動，增益就一路漏掉。

50 萬人的資料從哪裡來

這份研究的分量來自資料。研究團隊結合 GitHub 上公開可見的活動紀錄與 Microsoft 內部的 AI 使用遙測，追蹤超過 50 萬名開發者，因此能跨廠牌看見同一個人用了哪些工具：自動補全來自 GitHub Copilot，同步代理涵蓋 GitHub Copilot、Claude 與 Codex，非同步代理涵蓋 GitHub Copilot 與 Codex。

方法上採用配對事件研究：每個採用 AI 工具的開發者，配一位在一年前同一週、活動量相近的對照者，比較兩組人事後的走向。這比單純比較使用者與非使用者嚴謹，但仍然不是隨機分組的實驗，採用工具的人本來就可能更積極。研究團隊也做了對照：他們估出的自動補全效果，與外部團隊對 GitHub Copilot 做田野實驗得到的 26% 任務級增益方向一致，算是方法上的一次互檢。另外兩位作者 Demirer 與 Musolff 在 NBER 頁面揭露，他們過去曾在 Microsoft 擔任博士後研究員，目前是 Microsoft 的付費研究顧問，這層關係不必然推翻結果，但讀數字時應該一起放進天秤。

還有一個容易被忽略的細節：效果對活動量低的開發者更大。自動補全的效果從最活躍族群的約 20% 一路上升到最不活躍族群的 61%，等於 AI 把入門門檻拉平的力道，比給高手裝上渦輪更強。工具之間也有差異，長期同步效果在 Claude Code 用戶上是 296%，GitHub Sync 是 126%，OpenAI Codex 是 119%，但論文自己提醒，這可能反映採用族群的差異，也可能反映工具本身的效果，兩種機制論文明言無法區分。

試錯變便宜的另一面：七倍的新增、十二倍的刪除

寫碼增益去了哪裡？一部分變成試錯。採用同步代理之後，開發者新增的程式行數變成 7 倍，刪除的行數變成 12.2 倍，建立的分支增加 79%。分支是開發時另開的平行路線，拿來嘗試新功能或修問題；分支越多，代表團隊同時探索的方向越多，也代表更多方向會被丟掉。論文進一步統計，新建立的儲存庫在第一個月之後就再也沒有任何活動的比例，從 2021 年的 60% 升到 69%，多出 9 個百分點。

這組數字描繪的畫面相當一致：AI 讓「試一下」的成本降到接近零，於是大家試得更多、丟得也更快。放到管理層就是一個量測陷阱，如果公司用程式行數、commit 數或原型數量衡量產出，等於把「更便宜的試錯」誤讀成「更多成功的產品」。

真正有參考價值的訊號在 release 這一層，而 release 本身也變大了：論文量到每次 release 的中位數程式行數從約 5,210 行上升到約 13,420 行，檔案數從 48 個增加到 76 個。出的貨沒有多多少，但每一包都更重，審查與測試的工作量跟著上去，這又繞回人力瓶頸。

上游活動暴增還有一個論文引用的旁證：GitHub 的 CTO 在 2026 年 8 月 17 日一次重大當機的事後檢討中說過，每月 commit 數從 2026 年 4 月的 14 億成長到 29 億，翻了一倍以上。平台自己都感受到寫碼流量的洪峰，只是洪峰還沒變成上架的貨。

商店端的證據：新 App 暴增，使用量持平

研究的最後一段把視角拉到四個軟體商店：Apple App Store、Google Play、Chrome Web Store 與 SourceForge，前兩者與 Chrome 的資料經由 SimilarWeb 與 chrome-stats.com 的 API 授權取得，SourceForge 則直接從站上蒐集。三個主要商店的走向不完全相同，但方向一致。

iOS 最明顯。每月新上架的 App 從 2023 年到 2025 年初一直在 3.3 萬到 4.5 萬之間，2025 年之後快速上揚，到 2026 年 4 月達到約 10.8 萬。Android 是另一種故事：每月新上架數從 2020 年的高點一路下滑，2025 年 1 月落在約 4.2 萬的低檔，之後反彈，2026 年中回到約 9.9 萬。Chrome 線上應用程式商店的新擴充功能自 2023 年以來成長約 7 倍，論文特別註明這波成長早於代理式寫程式工具的熱潮，2025 年之後只是再加速。

供給暴增，需求端呢？研究把每個月上架的新 App 視為一批同期產品，追蹤它們上市後前三個月的表現。iOS 因為 Apple 不公開下載數，以評分數量代替，Android 與 Chrome 用下載數。結果是三個商店的新 App 總使用量都沒有跟上供給：iOS 的同期評分總量在 2024 到 2025 年間大致持平，Android 的同期下載量只有小幅增加、遠低於新上架的增幅，Chrome 的同期下載量快速下滑，而且這個跌勢在供給暴增前就已經開始。更關鍵的是門檻數字：上市前三個月累積少於 10 個評分的 iOS 新 App，佔比從 2025 年 1 月的約 78% 升到 2026 年 4 月的 87%；Android 至多 100 次下載的佔比從約 22% 升到 26%；Chrome 少於 10 次下載的佔比從 19% 升到 33%。暴增的供給，絕大多數落在沒有任何受眾看得見的長尾裡。

論文把 2025 年 2 月之後標為「代理式寫程式時代」，Claude Code 的正式版在 2025 年 5 月 22 日隨 Opus 4 上線，時間軸與供給加速大致重疊。但作者對因果的措辭相當節制：時間重疊加上開發者層級的產出證據，支持 AI 確實推高供給，卻不能把每一款新增 App 都記到 AI 頭上。

a16z 的補充：收入幾乎沒動，成長集中在少數類別

a16z 的圖表週刊在論文之外補上市場營收這一面。依 Sensor Tower 截至 2026 年 9 月 15 日的估計，以 2024 年 12 月為基期 100，美國 App 市場的整體營收指數走到 102.0，總使用時間指數走到 107.0，換算約莫是營收增加 2%、使用時間增加 7%，而且圖上註明涵蓋所有類別含遊戲。供給翻了倍，營收幾乎原地踏步。

Pin

分類別看更有意思。a16z 的泡泡圖把美國各 App 類別自 2025 年以來的營收成長對使用時間成長畫在一起，圖上的近似讀值顯示：Productivity 是唯一同時雙成長的大型類別，使用時間約增加 55%、營收約增加 105%，a16z 直接點名推力來自 ChatGPT、Claude、Gemini 與 Grok；營收增速最高的 Food & Drink 時間持平且規模小；Developer Tools 是極小類，但成長突出，Replit 是這個類別成長最快的產品。反方向的是幾個大型舊類別：遊戲的使用時間約下滑 3%、營收約下滑 14%，Lifestyle 營收約下滑 30%，Books 約下滑 40%。a16z 的總結寫得很白：AI App 本身非常受歡迎，AI 做出來的 App 就未必了。

Pin

同一篇週刊還引了 Consumer Edge 的美國交易資料：到 2026 年第一季，付費購買 AI 產品的美國消費者約 3%，年輕族群的採用率約是年長族群的 4 倍，而且這個數字只算個人卡消費，不含企業支出。付費 AI 的滲透率仍在低檔，對照 App 供給的暴增，兩者之間的缺口正是 a16z 所謂「App-Slop」的背景，也和Shopify 執行長說的「AI 垃圾手榴彈」指向同一個問題：產出變便宜之後，品質與判斷的責任更沒有地方躲。

三種常見誤讀，與這份研究的邊界

第一種誤讀是「AI 寫程式沒效」。資料說的剛好相反：三個世代的工具全部顯著增加寫碼活動，pull request、觸及的專案數也都上升，只是增幅逐層縮小。沒效的是「把寫碼增益直接當成出貨增益」的推論，兩件事隔著整條生產鏈。

第二種是「App 暴增全部是 AI 的功勞」。論文自己反對這個讀法：Chrome 的成長早於代理工具熱潮，Android 是長期下滑後的反彈，商店層資料是描述性趨勢，不是因果實驗。合理的說法是 AI 與供給增加發生在相近時期，且開發者層級的產出證據支持 AI 確實是推力之一。

第三種是「新 App 沒人用，因為 AI 寫的程式品質差」。這是直覺但證據尚不足的一步。論文明說，現有資料無法完全分辨兩種解釋：一種是供給端問題，半成品更容易被推上架；另一種是分發端問題，商店的排名、推薦與使用者時間就是那麼多，供給翻倍之後每個 App 能分到的曝光自然變薄。研究只追蹤上架後三個月，慢熱型產品還來不及累積口碑；評分與下載數也不是留存或收入，更不是使用者實際得到的價值。

邊界之外還有兩件事該記著。NBER 工作論文的地位是已公開供學術討論，尚未等同通過同儕審查的定論，這份論文從 5 月到 9 月已經改過一版，數字仍可能隨修訂調整；GitHub 資料以公開與開源活動為主，企業內部系統的代表性較弱，配對方法降低了偏差但排除不了「本來就更積極的人更早採用工具」這類問題。至於台灣在地的 App 市場，論文的商店面板沒有限定單一市場，a16z 引的營收與時間圖則只涵蓋美國，類別消長的幅度不該直接平移到其他市場。

接下來值得追蹤的三個訊號

對開發者與團隊，這份研究真正可用的結論是瓶頸已經搬家：產出程式碼不再是稀缺環節，審查、測試、發行與需求判斷才是，工具採購與流程設計都應該對準後面這幾段，手上同時跑多個代理的團隊，也需要像 Vibe Kanban 這類統一管理介面把任務與花費看在一起，成本面則可以對照 AI coding plan 的額度與計價結構先算清楚。對創業者與投資人，衡量的指標要跟著移動，commit 數、原型數或功能數量都只是上游訊號，啟用率、留存、付費轉換與錯誤率才是下游答案，一家公司宣稱開發速度提升數倍，只證明了它的製作成本下降，沒有證明需求、定價能力或護城河。

後續可以盯三個訊號：這份論文的下一次修訂與同儕審查進度，特別是彈性估計與逃逸速度門檻的數字是否穩定；Sensor Tower 與 a16z 每週圖表上，Productivity 與 Dev Tools 的成長何時外溢到其他類別；以及 GitHub 官方是否公佈更多 commit 增長的細目，讓上游暴增與出貨之間的缺口可以被持續量化。供給革命已經發生，現在值得看的，是需求端什麼時候接招。