效能盲點：AI 代理寫出緩慢的程式碼

程式碼通過了每一項測試。Linter 檢查毫無問題。型別檢查器也完全滿意。程式碼審查已經核准。然而這個函式的執行速度，比它應有的慢了 446 倍。¹

Codeflash 是一款程式碼效能最佳化工具，他們分析了兩個完全由 Claude Code 產生的 Pull Request：橫跨一個 Java 語言支援模組和一個 React 框架整合，共計 76,000 行程式碼。¹ 他們發現了 118 個存在嚴重效能問題的函式。效能降低的幅度從 3 倍到 446 倍不等。最嚴重的案例：一個型別擷取函式在每次呼叫時都重新掃描整個 AST，而非快取遍歷結果。行為完全正確。效能卻是災難性的。

這個發現並非個案。SWE-fficiency 是一個涵蓋 498 個最佳化任務的基準測試，橫跨 NumPy、Pandas 和 SciPy 等知名程式庫，結果發現表現最佳的 LLM 代理在相同任務上僅達到專家開發者所能實現加速幅度的不到 0.15 倍。² 另一項獨立研究測試了 Claude 3.5、OpenAI o1 和 Llama 3.2 在 26 個高效能運算程式碼上的表現，發現 Claude 3.5 在序列最佳化上僅達到 1.02 倍的加速（實質上等於零改善），且在 30% 的案例中產生了錯誤的程式碼。³ Codeflash 自己對 100,000 個開源函式的分析則發現，90% 的 AI 建議最佳化不是錯誤就是沒有任何可量測的效益，而在正確的最佳化中，73% 帶來的增益低於 5%。⁴

效能是 AI 程式碼工具看不見的維度。每一個標準品質關卡（linter、型別檢查器、測試套件、程式碼審查）驗證的都是正確性，沒有任何一個驗證效率。結果就是：在每一行 AI 生成的程式碼上附加了一筆隱形稅負，它通過了所有檢查，卻拖累了每一個它進入的系統。

摘要

AI 代理寫出正確但緩慢的程式碼。Codeflash 在 Claude Code 產出的 76,000 行程式碼中發現了 118 個效能問題，效能降低幅度從 3 倍到 446 倍。¹ 學術基準測試也證實了這一模式：LLM 在最佳化任務上僅達到不到專家加速幅度的 0.15 倍。² 原因是結構性的：訓練資料獎勵正確性，而標準品質關卡不衡量效能。要突破這個瓶頸，需要效能基礎設施：在單元測試旁加入基準測試、在 hook 中使用基於 AST 的模式偵測，以及將效能分析納入標準工作流程。

關鍵要點

對個人開發者而言。在每個 AI 生成的函式進入熱路徑後，於驗證步驟中加入 time 或效能分析器。那個 446 倍的效能降低通過了所有測試和每一個 linter。唯一能攔截它的關卡就是基準測試。將「能執行」視為必要但不充分條件。將「執行速度如何？」作為標準的後續問題。

對團隊負責人而言。效能退化是「夠好就好」高原的隱形型態。通過所有功能測試的 AI 生成程式碼會製造虛假的完成感。在 CI 中將效能基準測試與單元測試並列。Faros AI 的資料顯示，使用 AI 輔助的團隊完成了多 21% 的任務，同時每位開發者多產生 9% 的 bug。⁵ 效能相關的 bug 並未被計入那 9%，因為根本沒有人在衡量它們。

對平台工程師而言。建構缺失的關卡。Linter 檢查風格。型別檢查器檢查合約。測試套件檢查行為。在標準 CI 流程中，沒有任何機制檢查演算法複雜度或執行時間特性。基於 AST 的模式偵測（Semgrep 規則、ast-grep 模式或自訂 hook）可以攔截最常見的效能反模式：冗餘遍歷、缺少記憶化，以及不必要的複製。

118 個 Bug 的面貌

Codeflash 對兩個 Claude Code PR 的分析提供了目前最精細的 AI 生成效能問題公開資料集。¹ 這兩個 PR 合計 76,000 行：52,000 行用於 Java 語言支援，24,000 行用於 React 框架支援。兩者功能都正常。兩者都通過了測試套件。兩者都包含在實際負載下會退化的程式碼。

根本原因可歸納為四個類別：

低效的演算法。這是最主要的類別。一個將位元組偏移量轉換為行號位置的函式使用了 O(n) 掃描，而非使用預先計算的查找表進行 O(log n) 二元搜尋。程式碼可讀性很高。變數名稱描述清晰。邏輯完全正確。但複雜度等級是錯的。

冗餘計算。函式重新解析、重新遍歷或重新計算本可快取的值。輔助函式搜尋器在每次呼叫時都重新解析同一份原始檔。一個記憶化裝飾器就能在首次呼叫後將 74 倍的額外開銷降為零。

缺少快取與記憶化。與冗餘計算密切相關，但不同之處在於資料在更廣的作用域中已經可用。型別定義擷取器每次都遍歷完整的 AST，而非在首次存取時建立索引。這個模式的本質是：代理在撰寫每個函式時都是獨立的，從未考慮它會在迴圈中被呼叫的情況。

次佳的資料結構。在集合或字典能提供 O(1) 查找的場景中使用列表掃描。匯出檢查器透過迭代列表來測試成員資格。轉換為集合就能完全消除 9 倍的額外開銷。

為什麼代理會產生緩慢的程式碼

效能盲點不是某個特定模型的 bug。其原因是結構性的，運作在三個層面：訓練資料、評估標準和工作流程假設。

訓練資料獎勵可讀性

LLM 從訓練資料中程式碼的分布中學習。任何演算法最常見的實作方式就是最樸素的版本。教學程式碼優先考慮清晰度。Stack Overflow 的回答優先考慮正確性。開源程式碼中確實包含效能最佳化的版本，但它們在數量上被直觀的實作方式遠遠超越。

這個模式不僅限於效能。Stanford 發現使用 AI 輔助的開發者在五個安全任務中的四個產出了更多不安全的程式碼，而且這些開發者更傾向於相信自己的程式碼是安全的。⁸ 這種信心差距同樣適用於效能：程式碼看起來乾淨、讀起來順暢、產出正確的結果，因此開發者信任它。SWE-fficiency 的研究者發現，代理難以定位最佳化機會並跨函式推理執行邏輯。² LLM 傾向於進行小型的、針對特定輸入的修改，而非演算法層面的改進。當被要求最佳化時，模型會選擇最近的正確轉換（加一個快取、內聯一個函式），而非重新思考演算法方法。結果就是在根本性的低效結構上層層疊加微觀最佳化。

沒有任何評估關卡衡量效能

標準品質關卡驗證的是它們被設計來驗證的東西：

業界已經標準化的每一個關卡都是針對正確性運作的。效能測試確實存在（效能分析器、基準測試框架、負載測試工具），但它佔據著一個獨立的工作流程，大多數團隊不會將其整合到 CI 流程中，而 AI 代理也從不會主動呼叫它。

解釋 10% 生產力瓶頸的驗證真空比功能正確性延伸得更深。這個真空不僅僅是「程式碼能不能運作？」而是「程式碼執行得好不好？」——而沒有任何標準關卡會問第二個問題。

代理寫的是函式，而非系統

最深層的原因是架構性的。AI 代理一次生成一個函式、一個檔案、一個任務。每次生成的範圍都是眼前的需求。效能問題出現在邊界處：當一個為單次呼叫而寫的函式被放在迴圈中呼叫時，當一個為小型輸入而寫的解析器接收到大型檔案時，當一個為正確性而寫的查找被每個請求都觸及時。

代理失敗分類中的隧道視野失敗模式在功能層面描述了這個模式：代理完善了一個元件，卻沒有檢查整合點。效能盲點就是隧道視野應用在執行時間特性上的表現。函式在隔離環境中是完美的。系統退化了，因為函式的效能特性從未在上下文中被評估過。

隱形稅負

如果 AI 生成的程式碼只佔正式系統的一小部分，效能盲點充其量是個小問題。但目前的數據使其成為一個系統性風險。

DX 的測量顯示，AI 撰寫的程式碼佔合併到正式環境程式碼的 26.9%，且仍在攀升。⁶ Faros AI（一家 DevOps 分析供應商）發現使用 AI 輔助的團隊合併的 PR 比 AI 出現前的基準線大了 154%，完成了多 21% 的任務，且每位開發者多產生 9% 的 bug。⁵ 這 9% 計算的是功能缺陷。效能退化完全不在這個指標中，因為大多數團隊根本沒有效能基準線可供對比。

複利效應值得關注。METR 的隨機對照試驗發現，有經驗的開發者使用 AI 工具反而多花了 19% 的時間，但他們自認 AI 加速了 20%。⁹ 如果開發者自己都無法準確評估影響，效能債務就會在不知不覺中累積。當 26.9% 的合併程式碼都可能攜帶效能債務，而組織又沒有效能關卡時，這筆債務在每個衝刺迭代中持續累積。DORA 2025 年報告發現，AI 的採用與交付不穩定性的增加相關，儘管吞吐量有所提升。⁷ 報告並未將不穩定性特別歸因於效能，但機制是吻合的：更多程式碼、更快合併，而效能特性從未被衡量。

接受 Codeflash 調查的工程主管中，有 52% 表示 AI 使用量的增加導致了程式碼庫的效能問題。⁴ 這個數字是自行回報的，而且來自供應商（Codeflash 銷售效能最佳化工具），但方向與每一個獨立資料集一致。更多的 AI 生成程式碼，以標準品質關卡合併，產出的系統功能正確但執行緩慢。

10% 生產力瓶頸有一個原始資料未浮現的效能維度。如果 AI 將程式碼生成加速了 10%，但生成的程式碼攜帶的效能債務在數週或數月後以正式環境事件的形式浮現，淨生產力增益會進一步縮水。瓶頸不僅是「AI 沒有讓開發者更快」。瓶頸還包括「AI 以沒有人衡量的方式讓程式碼變慢」。

偵測的面貌

針對 AI 生成程式碼的效能偵測需要大多數組織尚不具備的基礎設施。工具已經存在。缺的是整合。

CI 中的基準測試關卡

最直接的修正：對關鍵路徑進行基準測試，並在退化時讓建置失敗。每種主要程式語言都有相應的框架：Python 的 pytest-benchmark、Java 的 JMH、Rust 的 criterion、JavaScript 的 benchmark.js。挑戰不在於工具，而在於實踐。基準測試需要基準線，而基準線需要有人在 AI 生成的程式碼可能造成退化之前先寫好初始基準測試。

最小可行的實作方式：識別熱路徑中的 10-20 個函式，為這些函式撰寫基準測試，然後將它們加入 CI。Codeflash 發現的 118 個 bug 集中在解析器和 AST 遍歷函式中：運算核心，而非黏合程式碼。效能問題每次都集中在同樣的地方。

基於 AST 的模式偵測

靜態分析可以在不執行程式碼的情況下攔截最嚴重的模式。Semgrep 和 ast-grep 支援自訂規則來偵測：

• 巢狀迴圈中內部集合不變的列表推導式或迴圈（快取候選）
• 對可以是集合的列表使用 .index() 或 in 檢查
• 迴圈內的檔案 I/O 或網路呼叫未進行批次處理
• 以相同參數重複呼叫函式（記憶化候選）

這些規則不能取代效能分析。它們攔截的是佔 118 個 bug 大多數的模式：冗餘計算、缺少快取、錯誤的資料結構。

基於 Hook 的效能意識

對於 Claude Code 的使用者，PreToolUse hook 可以將效能意識注入代理的工作流程中。這個方法與用於正確性的證據關卡模式類似：

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

Hook 不是效能分析器。它提升的是意識。目標與其他所有品質關卡相同：讓不可見的變得可見，使開發者（或後續迭代中的代理）能在程式碼上線前加以處理。

缺失的基礎設施

每一個數據點的模式都與解釋 10% 生產力瓶頸和七種失敗模式的模式相同：AI 放大既有的一切基礎設施，包括基礎設施的缺失。

擁有 CI 效能基準測試的組織，會像攔截人為造成的效能退化一樣攔截 AI 生成的效能退化。沒有的組織則會在不知不覺中累積效能債務。DORA 的「放大器」發現直接適用於此：AI 並沒有創造效能盲點。AI 將它擴大了。⁷

三項最低限度的投資可以彌補這個差距：

1. 在 AI 圍繞關鍵路徑生成程式碼之前，先對其進行基準測試。基準測試就是基準線。沒有它，任何退化都無法被偵測。識別佔大部分運算時間的 10-20 個函式，優先為這些函式撰寫基準測試。

2. 將基於 AST 的效能靜態分析加入 CI 流程。使用 Semgrep 或 ast-grep 規則來標記四種主要反模式（冗餘計算、缺少快取、錯誤的資料結構、不必要的複雜度）。這些規則輕量且可與既有的靜態分析步驟組合。

3. 將效能意識注入代理工作流程。對 Claude Code：使用 hook 來標記修改檔案中與效能相關的模式。對其他工具：使用包含「驗證演算法複雜度」的提示作為標準指令。目標不是自動化最佳化，而是意識：在一個目前不會提出「這夠快嗎？」這個問題的工作流程中，浮現這個問題。

盲點不在 AI。盲點在於效能基礎設施的缺失。業界建構的每一個標準品質關卡都驗證正確性。沒有任何一個驗證效率。這個差距在 AI 出現之前就存在。AI 讓它變成了一個佔正式環境程式碼 26.9% 的問題。

來源