程式碼不再是瓶頸：當 AI 讓寫程式變便宜，瓶頸移到了審查與帳單

ai 產業觀察

程式碼不再是瓶頸封面：瓶頸位移示意——寫程式碼便宜了、不再是瓶頸，人的審查與算力帳單變成新瓶頸；右側為 +220%／+36%／÷1000 三個數字

過去兩年，軟體業有一句話從「新鮮」變成「共識」：寫程式碼本身，其實一直不是主要的瓶頸。AI 把這句話從一種說法變成了每天的現實——當生成程式碼變得又快又便宜，卡住團隊的不再是「寫不寫得出來」，而是兩件原本沒人當成瓶頸的事：有沒有人審得完，以及帳單付不付得起。這篇文章想說明瓶頸為什麼會這樣位移，以及對評估「AI 提升效率」的人來說，該改看哪兩個數字。

為什麼工程主管突然都在講「瓶頸不在寫程式碼」

軟體工程電子報 The Pragmatic Engineer 的作者 Gergely Orosz，在 7 月的一篇觀察裡記下一個轉折。他說從今年 1 月新一代模型讓 AI 在多數公司都能寫出更多、更好的程式碼開始，「總監層級的人開始談，做軟體的瓶頸正從寫程式碼移到審查階段」。他描述的症狀很具體：過度認真的程式碼審查正在把工程師燒壞、反而讓審查品質下降；而當 AI 幫忙審查、又挑不出實質意見時，開發者就直接按下核准。

這不是單一公司的抱怨。Orosz 與 Elin Nilsson 在 4 月做的一份調查收到九百多份工程師與工程主管的回覆，把使用 AI 的人分成三種：追求品質與架構的「builder」、追求出貨速度的「shipper」，以及能力尚可，但會產出大量「AI slop」（AI 生成的低品質內容）的「coaster」。三種人共用同一個工作環境，意味著 builder 與 shipper 每天要審的，有一部分是 coaster 靠 AI 快速生出來、品質參差的程式碼。調查裡有一個具體場景：一位工程師把一個 P1 專案當成幾天的副業做完，成果是 12 個 pull request、大約 2,500 行程式碼的變動——一個人幾天內產出的審查量，就相當於過去一個小組一段時間的份。

證據：寫得多，交付沒有等比變多

「寫程式碼不是瓶頸」不只是工程主管的體感，也有數字。Reuters 記者 Katie Paul 在 8 月揭露 Meta 內部文件時，引用了技術長 Andrew Bosworth 6 月初的一則內部貼文：員工對內部平台與基礎設施的程式碼變更年增 220%，但真正到達使用者的新功能或升級變更只年增 36%；同一時期，重大技術與資安事件比前一年增加 40%，員工花在「救火」的時間增加 70%。

把這四個數字放在一起，故事很清楚：寫出來的程式碼多了三倍多，送到使用者手上的成果只多了三分之一，中間的落差沒有消失，而是變成了更多的事故與更多的救火。程式碼的「產出」和「交付」脫鉤了。

長條圖:Meta 內部一年,程式碼變更 +220%、真正交付給使用者的只 +36%、重大技術與資安事件 +40%、救火時間 +70%

第三方的隨機對照試驗指向同一個方向。METR 是美國的非營利 AI 評測機構，它在 2025 年的一項研究讓 16 位資深開源開發者在自己熟悉的專案上完成真實任務，隨機分配能不能用 AI 工具。結果是允許使用 AI 時，完成任務的時間反而長了 19%，即使開發者事後仍覺得自己變快了。原因不難理解：對熟悉專案的資深開發者來說，敲鍵盤打字的速度並不是限制，讀懂、驗證、整合別人（或 AI）寫的東西才是。AI 加速了前者，卻加重了後者。

瓶頸一：審查與判斷——有人得看，有人得負責

第一個新瓶頸是人的審查。這裡的審查不只是抓語法錯誤，而是三件機器還接不住的事：判斷這段程式碼該不該進產品、把它和既有系統整合起來，以及在它出事時負責。生成端變便宜，這三件事的量就等比放大，但做這三件事的人沒有等比增加。Orosz 記錄的「審查燒壞人、於是變成橡皮圖章」，就是這個瓶頸被塞爆時的樣子——當審不完，團隊要嘛拖慢、要嘛降低標準假裝審過，兩條路都把風險往後推。

值得注意的是，把「人審」當成正式關卡，正是現在被認為做對了的設計。Anthropic 在 9 月談商務 agent 的設計時寫道：「沒有任何一次模型的工具呼叫會動到錢或改變業務」，下單、付款、改價這些動作最後都落在一個由執行框架，而非模型控制的關卡上，模型能做的最危險的事只是「提議」，真正生效前要走企業原本就有的「一人做、一人核」流程。這句話換到程式碼上同樣成立：模型可以提議一千個 pull request，但決定哪個能合併的，還是人。

審查為什麼不能省，最近有一個很具體的例子。英國的 AI 評測機構 AISI 在 7 月底的一份測試報告裡記錄，測試中有 AI 對開源專案發動了惡意的 pull request 供應鏈攻擊，而這次攻擊被擋下來，靠的是一位人類維護者發現並拒絕核准那段程式碼。當生成端可以無限量產、而且可能夾帶惡意時，那個「按不按核准」的人，就是最後一道防線。

示意圖:AI 生成程式碼又快又便宜,pull request 佇列越堆越高,卡在有限的人工審查這一關才能交付

瓶頸二：帳單——每 token 變便宜，總帳單反而變大

第二個新瓶頸是錢，而且它的樣子違反直覺。單看每個 token 的價格，AI 是在快速變便宜的。a16z 的 Guido Appenzeller 在 2024 年底提出「LLMflation」：達到同樣品質所需的每百萬 token 成本，三年內下降了大約一千倍——2021 年底 GPT-3 等級的輸出要價每百萬 token 60 美元，到他寫文時最便宜的同級模型只要 0.06 美元；換算下來，同等智慧的單價大約每年降十倍，比 PC 時代的運算成本、網路泡沫時代的頻寬都降得更快。

但「單價變便宜」不等於「帳單變小」。恰恰相反，便宜會誘發用量爆炸，總帳單反而往上走，而且開始出現在企業的財報與工程師的日常裡。Meta 財務長 Susan Li 在 7 月 30 日的法說會上拆解費用增加來源時，「第三方 AI token 成本」是明列的一項——買外部模型的推論服務，已經是 Meta 帳上一條看得見的費用線。NVIDIA 8 月申報的 FY2027 第二季 10-Q 更直接：研發費用年增 64%，經營討論明寫主因是自用運算基礎設施支出成長 127%，同期薪酬與福利只成長 30%。執行長黃仁勳在法說會上把這件事講成一種常態：「你應該盡可能租用智慧，我們自己也在租。」到了個別工程師這一層，帳單也看得見：Orosz 的調查裡，公司常為重度使用者每月每人付 100 到 200 美元的 AI 工具費用，約三成受訪者會撞到用量或 token 上限，卡在工作流裡動彈不得。

兩欄圖:左為每百萬 token 價格三年跌約 1000 倍($60→$0.06),右為總帳單反而上升的三個訊號——NVDA 運算 +127%、Meta 明列第三方 AI token 成本、每工程師每月 $100–200

我們的判斷是：這兩個瓶頸其實是同一件事的兩面。當生成程式碼變得又快又便宜，便宜本身就把成本推到了兩條線上——一條是人的審查（有人得看得完、整合得了、扛得起責任），一條是算力的帳單（生成越多，token 與 compute 的總支出越大）。寫程式碼這個環節的成本降到接近零，並沒有讓總成本消失，只是把它搬到了這兩個地方。

對用 AI 的人意味什麼：改看兩個數字

如果你在企業裡導入 AI 寫程式，或在評估一家公司「用 AI 提升工程效率」的說法，這件事給的不是「別用」的結論，而是把評估的焦點換掉。過去大家愛講的「AI 幫我們多寫了多少程式碼」「commit 數成長多少」，在瓶頸位移之後幾乎沒有意義——Meta 的例子已經說明，寫得多不等於交付得多。真正該量的是另外兩個數字。

一、審查吞吐量。 團隊每天能可靠審查、整合、為之負責的變更量是多少？這個數字，而不是生成量，決定了交付速度的上限。如果生成量翻倍、審查吞吐量沒動，多出來的產出只會變成更長的佇列、更多的橡皮圖章、更多的事故——就是 Meta 那組「+220% 對 +36%」數字的來源。要提升效率，該投資的是審查與整合的能力（更好的測試、更清楚的規格、AI 輔助但由人把關的審查），不是更快的生成。

二、單位產出的算力成本。 不是「每 token 多少錢」，而是「每一個真正交付、通過審查的成果，花了多少 token 與 compute」。因為便宜會誘發浪費：一個 coaster 可以用很便宜的單價，生成大量最後被丟掉或需要重寫的程式碼，單價再低，這些帳單也是白付的。把算力成本除以「通過審查的產出」而不是「生成的產出」，才看得出 AI 到底有沒有讓這家公司更有效率，還是只是讓它更會燒錢。

我們的判斷，以及什麼會推翻它

我們的判斷是：2026 年這一波「AI 讓工程效率大增」的說法，多數把瓶頸看錯了地方。寫程式碼的成本確實在崩，但它一直不是主要的限制；當它趨近於零，限制會清楚地落在人的審查與算力的帳單這兩條線上。對看待這類主張的人，「審查吞吐量」與「單位交付的算力成本」比「寫了多少程式碼」更能預測結果。

什麼會推翻這個判斷？我們列三個可證偽的條件。第一，如果 AI 審查工具進步到能可靠地承擔「判斷、整合、負責」這三件事，讓審查吞吐量隨生成量一起放大，那審查就不再是瓶頸，這個說法要收回。第二，如果有公司能證明它的程式碼變更量大幅上升、同時交付量等比上升且事故沒有增加（也就是沒有出現 Meta 那種「220 對 36」的落差），那「產出與交付脫鉤」就不是通則。第三，如果 token 與 compute 的總帳單在用量爆炸後仍長期持平或下降，那「帳單變成瓶頸」的說法也不成立。在這三件事發生之前，我們維持上面的判斷。

一個具體的觀察點：下一次看到某公司宣布「AI 讓我們的工程產出成長 N 倍」時，先問兩個問題——交付量成長了幾倍？事故與救火時間動了多少？如果它只答得出第一個數字，那它量的多半是生成量，不是效率。