10%之牆：為何AI生產力停滯不前，以及如何突破

DX調查了450家公司的121,000名開發者。92.6%至少每月使用AI程式碼助手。AI撰寫的程式碼現已佔正式合併的26.9%。開發者回報每週節省約四小時。¹但生產力始終未突破10%。

這個數字已連續三個季度維持不變。^{1 2}採用率攀升了。程式碼量攀升了。工具改善了。但收益沒有。DX技術長Laura Tacho直言不諱：「這其實是管理問題。炒作讓人以為只要嘗試AI就能自動獲益。」³

2025年DORA報告發現了分歧。擁有良好工程實踐的組織看到AI放大了既有優勢。實踐薄弱的組織則看到AI放大了既有缺陷。相同的工具，截然相反的結果。報告總結道：「AI在軟體開發中的主要角色是放大器。它會放大高績效組織的優勢，也會放大掙扎中組織的失能。」⁴

這道牆不是模型問題，而是基礎設施問題。更好的模型無法突破一道由缺乏驗證、缺乏脈絡、缺乏治理所築成的牆。本文的姊妹篇描述了這套架構：Anatomy of a Claw說明協調層，The Fabrication Firewall說明輸出閘門，Context Is Architecture說明脈絡注入系統。本文則解釋這些系統為何而存在。

摘要

121,000名開發者受訪。92.6%採用率。生產力停滯在10%。這道牆之所以存在，是因為AI產生程式碼的速度遠超組織驗證、脈絡化或治理的能力。三個根本原因：脈絡飢餓（AI在缺乏專案特定知識時產生幻覺）、驗證真空（程式碼出貨速度超越審查流程的適應能力）、以及治理缺口（AI繞過了人類所執行的品質標準）。突破需要的是圍繞AI建立基礎設施，而非更好的AI。證據顯示：建立了驗證與治理基礎設施的組織將事故減半；未建立基礎設施就採用AI的組織則事故倍增。^{4 5}這是一次N=1的基礎設施建構嘗試，附帶具體數據。它無法證明普適性，但能展示牆的另一側是什麼樣子。

調查數據

DX的資料集涵蓋2025年11月至2026年2月間觀察的420萬名開發者，其中包含一個橫跨450家公司、121,000名開發者的詳細調查面板。¹這些數字述說兩個故事。

採用率的故事明確無疑。 AI程式碼助手已接近全面普及。DX測得92.6%的月度採用率和約75%的週使用率。¹ Stack Overflow的2025年調查發現84%的開發者正在使用或計畫使用AI工具。⁶ JetBrains在194個國家的24,534名開發者中測得85%的常規使用率。⁷採用率的天花板已近在眼前。

生產力的故事已經停滯。 DX測得每週平均節省四小時，與上一季的3.6小時相比幾無變化。^{1 2} AI撰寫的程式碼從22%上升至合併程式碼的26.9%，但額外的量並未轉化為額外的產出。^{1 2} Laura Tacho點出了背後的算術：開發者大約只有20%的時間在撰寫程式碼。對工作日20%的部分改善10%，整體僅改善2%。「打字速度從來不是瓶頸。」⁸

關鍵在最後一行。DORA的2024年報告調查了39,000名專業人士，發現每增加25%的AI採用率，交付吞吐量估計下降1.5%，交付穩定性下降7.2%。⁵ 2025年DORA報告發現吞吐量已恢復（關係從負轉正），但穩定性仍為負值。⁴即使吞吐量改善，AI採用率仍持續與不穩定性增加相關。

比起平均值，分歧更值得關注。METR研究了16名資深開源開發者處理246個真實程式庫問題的情況，發現使用AI工具比不使用多花了19%的時間。⁹ Google對96名工程師的隨機對照試驗發現速度提升21%，但結果在統計上不顯著（95%信賴區間跨越零）。¹⁰ McKinsey發現簡單任務有35-50%的提升，但高複雜度任務不到10%。¹¹模式很清楚：AI加速的是開發過程中從來不是瓶頸的部分。

突破的公司並非使用了更好的模型，而是建立了能捕捉模型遺漏之處的基礎設施。

為何牆會存在

三個根本原因解釋了這個停滯期。每個原因獨立運作，合在一起形成了更好的模型也無法穿透的天花板。

脈絡飢餓

AI程式碼助手只能處理當前檔案中可見的程式碼以及提示視窗能容納的脈絡。除非有人注入相關資訊，否則它不知道您的架構決策、您的API合約、您的部署限制，或您團隊的命名慣例。

缺乏專案特定脈絡時，模型只能猜測。它會幻覺出遵循合理慣例但實際不存在的檔案路徑。它會產生呼叫符合常見模式但不符合您的模式的API端點。它會建議從您的專案未使用的套件匯入。¹²

Faros AI分析了1,255個團隊中10,000名開發者的遙測數據，發現AI輔助的pull request比非輔助的大154%。¹²更大的PR帶來更多脈絡相關錯誤的表面積。AI自信地產生程式碼。程式碼能編譯。但程式碼沒有考慮到記錄在AI從未看過的Confluence頁面上的限制條件。

這不是模型安全意義上的幻覺問題。模型完全按照設計運作：根據可用脈絡預測可能的程式碼。問題在於可用脈絡排除了特定程式碼庫中大部分攸關正確性的資訊。

驗證真空

AI產生程式碼的速度超過現有審查流程的消化能力。Faros發現AI輔助的PR審查時間長了91%。¹²開發者完成的任務多了21%，合併的pull request多了98%，但審查流程處理的是人類速度的產出。¹²

史丹佛的不安全程式碼研究量化了安全面向。研究人員讓47名開發者在有無AI協助的情況下完成編碼任務。AI輔助組在五項任務中有四項更常寫出不安全的解決方案。在SQL注入任務中，AI組有36%寫出了有漏洞的程式碼，而對照組只有7%。使用AI協助的參與者更傾向認為自己寫出了安全的程式碼，即使實際上並非如此。¹³更快的產出加上更高的錯誤信心，創造了手動審查在規模上無法彌合的驗證缺口。

GitClear分析了1.53億行變更的程式碼，發現程式碼翻攪率（撰寫後兩週內被重寫的程式碼）預計在2024年相較AI前基準線翻倍。¹⁴ AI工具帶來的量增加產生了部分抵消生產力收益的重工。Stack Overflow的2025年調查印證了這種摩擦：66%的開發者表示花更多時間修復AI產生的「幾乎正確」程式碼。⁶

治理缺口

AI產生的程式碼繞過了人類開發者已內化的治理機制。一位資深開發者知道要檢查風格指南、執行linter、更新changelog，並就架構變更通知團隊負責人。AI助手則產生一個滿足提示的解決方案。「能編譯且通過測試」與「符合組織標準」之間的差距，就是治理。

McKinsey 2023年的研究發現，使用AI的初階開發者速度慢了7-10%，而非更快。¹¹研究人員將此歸因於產生的程式碼與組織脈絡之間的差距。初階開發者缺乏判斷AI輸出是否符合他們尚未內化的標準的能力。沒有將這些標準編碼為自動檢查的治理基礎設施，AI輸出就會不受檢查地流向下游。

治理缺口在團隊間會複合放大。一位開發者的AI產生工具函式與另一位開發者的既有模組重複。兩個AI產生的端點對同一個API使用不同的錯誤格式。AI撰寫的遷移檔案採用與團隊標準不同的命名慣例。每個違規都很小。累積效應是程式碼庫偏離自身慣例的速度超過審查所能矯正的速度。

牆的另一側是什麼樣子

DORA的發現描述了使用相同工具的兩個群體。一個將事故減半，另一個將事故倍增。⁴兩者之間的變數不是使用哪個AI，而是AI周圍的基礎設施。

每個根本原因對應一個基礎設施解決方案。下表將問題到解決方案的鏈條串聯起來，並以我在姊妹篇中建構並記錄的系統作為具體實作範例。這是一次附帶具體數據的嘗試，而非通用處方。

脈絡注入透過確保模型在每個提示中接收專案特定資訊來解決飢餓問題。一個分派hook觸發九個依序處理器，注入當前日期、git分支、工作目錄、專案慣例、活動任務脈絡和架構限制。模型在處理使用者請求前會收到200-400個token的基礎脈絡。測量延遲：所有九個hook總計200毫秒。模型不再猜測檔案路徑，因為它已被告知實際路徑。¹⁵

獨立驗證透過在常規檢查中將人類從驗證瓶頸中移除來解決真空問題。自主開發迴圈（記錄於Anatomy of a Claw）產生程式碼、執行完整測試套件，並將結果提交給三個獨立運作的審查代理。實作代理永遠不審查自己的輸出。這呼應了史丹佛研究的發現——AI輔助組對不安全程式碼更有信心：無論作者是人還是AI，自我驗證都不可靠。¹³

自動化治理透過將團隊標準編碼為可執行的檢查來解決缺口問題。Fabrication Firewall將每個對外動作分類為本地、共享或外部，將外部發布延遲至人工審查。品質閘門會阻擋使用模糊語言（「應該沒問題」、「看起來正確」）而非引用測試輸出和檔案路徑的完成報告。該系統執行的是經驗豐富的開發者在有時間逐行審查時會應用的標準。在AI產生的速度下，他們沒有這個時間。

合併後的系統在自身程式碼庫上產生可衡量的結果：4,518個程式碼區塊被索引用於語意搜尋、49,746個知識庫區塊橫跨15,800個檔案用於持久記憶，以及一個在任何變更報告完成前自動執行的測試套件。¹⁵這些數字描述的是一位開發者的基礎設施。它們無法證明該方法具普適性，但能證明只要在另一側擁有正確的工具，這道牆是可以穿透的。

治理比率

Anatomy of a Claw中描述的hook系統包含84個hook。經核實計數，按功能區分：35個判斷型hook決定某件事是否應該發生，44個自動化hook執行預定動作。比率為4:5。起初為1:6。¹⁵

起始比率反映了大多數團隊首先建構的內容：自動化。注入脈絡、記錄指標、格式化輸出、記錄使用情況。這些hook捕捉了每個人都能得到的那10%。它們自動化了在AI之前就已經部分自動化的開發機械部分。DX的數據證實了這一點：每週節省的四小時來自程式碼產生和模板減少，而這些原本就是開發週期中最快的部分。¹

向判斷型hook的轉移反映了額外收益的來源。

McKinsey 2025年對近300家公司的調查發現，最高績效者實現了16-30%的生產力提升和31-45%的品質提升。¹⁶這些組織擁有80-100%的開發者採用率，並結合了組織整合。區分因素不是採用率（全面來看都與10%收益相關），而是圍繞該採用率建立的基礎設施和流程。

Laura Tacho的框架在此適用：「我對任何宣稱能在不解決底層限制的情況下提升效能的技術持懷疑態度。」³底層限制是判斷限制。這段程式碼符合我們的標準嗎？這項變更會破壞下游的東西嗎？這個輸出是否包含捏造內容？自動化hook無法回答這些問題。判斷型hook可以——雖不完美——透過編碼資深開發者在腦中應用的標準來實現。

這個比率尚未達到平衡。系統仍然自動化多於治理。這本身就是一個診斷指標：任何自動化hook多於判斷型hook的協調層都有改善空間。

您實際需要建構什麼

姊妹篇中描述的系統有84個hook、43個skill、19個代理和15,000行基礎設施。您不需要15,000行。您需要三樣東西。

一個脈絡注入hook。 五行bash，將當前日期、分支和工作目錄注入每個AI提示。這消除了一整類幻覺：模型不再捏造檔案路徑和分支名稱，因為它擁有真實的資訊。

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

一個品質閘門。 十五行程式碼，在完成報告中搜尋模糊語言。如果代理說「應該沒問題」而非引用測試輸出，閘門就會阻擋。這以最低成本的切入點解決驗證真空問題。¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

一個獨立測試執行器。 一個在每次程式碼變更後執行專案測試套件的hook，測試失敗時明確報錯。實作因專案而異，但原則不變：撰寫程式碼的代理不能是該程式碼的唯一裁判。

從您的工作流程中最常出問題的地方開始。如果您的AI幻覺檔案路徑，先建構脈絡hook。如果您的AI交付未經測試的程式碼，先建構測試執行器。如果您的AI寫「完成」卻無證據，先建構品質閘門。

Karpathy描述了從氛圍編碼到代理工程的演進：「協調執行[工作]的代理，並擔任監督角色。」¹⁷上述三個hook就是最小可行的監督。它們不會產生30%的收益。但它們會讓您從10%邁向15%，而且每增加一個都會揭示下一個值得解決的限制。

這道牆是真實的，也是具體的。脈絡飢餓、驗證真空和治理缺口是工程問題，有工程解決方案。模型會持續改善。但對於每個將AI視為程式碼產生器而非需要基礎設施治理其輸出的系統的團隊來說，這道牆會持續停在10%。

參考來源