AI 讓軟體效能工作進入「人人可做」時代
最近 X 上一則病毒式傳播的推文主張：「那些抱怨 LLM 讓程式碼變慢、變肥的人，最終會被迫重寫所有東西到超優化組合語言，才會閉嘴。」雖然我們還沒到把所有東西都用組合語言寫的地步，但效能工作本身的成本結構已經發生了根本性的變化。
過去只有少數專家團隊能做的優化，現在只要會「打幾句話」就能讓 agent 代勞。AWS 的 Marc Brooker（Vogels 欽點的 AWS Distinguished Engineer）回應這個觀察時，直接引用了舊時代 FFTW（Fastest Fourier Transform in the West）這種「為特定硬體、特定問題量身打造」的例子，認為未來會出現大量根據「特定工作負載」動態客製的軟體。
Completely agree with your closing point. Dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome. (Which comes with all kinds of fun risks and opportunities of its own). Kind of reminds me of FFTW. — Marc Brooker, AWS
Microsoft 的工程師 Michael Malis（pgrust 專案負責人）也引用類似的觀點：
There’s been a meme circulating about how AI doesn’t help because “code was never the hard part.” I think that’s true in some domains, but in others, writing the code absolutely was the hard part. JIT compilers are a great example of that. — Michael Malis, pgrust
「寫程式從來不是難的部分」這個說法在某個領域是對的，但 JIT 編譯器（Just-In-Time Compiler，能在程式執行時即時把高頻路徑編譯成機器碼）這類歷史上手工撰寫極度困難的系統，現在 LLM 大幅降低了門檻。
用 ripgrep 實測：2 倍到 4 倍加速
作者用先前文章中介紹的 FRE 開源 regex 引擎（Regex 是一種用特殊符號描述字串樣式的搜尋語法，比一般字串搜尋更彈性也更快）做了一個實驗：當 ripgrep 在跑正規搜尋時，讓另一個執行緒用 FRE 把正規表達式預先編譯成原生機器碼，跑完後切換過去。這個想法很簡單，但實作涉及「多執行緒切換、AOT 編譯器整合、benchmark 對接」一連串程式碼手術。
結果：在作者自己的 codex 歷史查詢中，長查詢有 2 倍到 4 倍加速；在保留測試集（holdout benchmark，作者特地保留的「沒看過答案」題目，避免 AI 死背作弊）上，整體平均加速約 7%。不是什麼驚天動地的數字，但「只花幾分鐘打字給 codex」就拿到這個加速，作者認為完全划算。
實驗還在繼續，預期會更上一層樓。
為什麼不直接建索引？
理論上，重複搜尋文字的標準解法是建索引（index，把所有檔案內容預先整理成查詢表，省去每次重頭掃描），而不是寫 AOT（提前編譯成機器碼）正則編譯器。但這只是為了說明：這類過去需要一整個工程團隊的技術工作，現在 AI agent 都可以在幾分鐘內搞定。
作者曾在 Microsoft 參與 Bing 搜尋引擎索引 BitFunnel 的開發，這套系統在 SIGIR 拿下最佳論文獎，特色是常數時間（不管資料量多大，查詢耗時都幾乎固定）的快速文字攝取。如果要為整台機器建本地索引，作者有一些具體想法（例如應該索引整顆硬碟而非只有程式碼目錄），但留給「在 AI Lab 工作、有 Cerebras 這類加速器（把 AI 推論專用晶片當搜尋引擎用）的人」當練習。
優化已經變得極度便宜
成本下降的趨勢從 2025 年 11 月就開始了，公開模型出現後更明顯。作者舉自己用 GPT-5.1 或 5.2 寫 Azul 棋類 AI 的例子：完全不懂遊戲 AI，卻寫出當時世界最強的 Azul AI。從第二強 AI 的論文推測，作者的版本贏在優化做得更深，但花的時間少兩個數量級（百倍），而且主要是在筆電上跑、沒用叢集運算。
關鍵差別：作者版本支援多執行緒（multi-threading，讓多顆 CPU 核心同時工作），對手是單執行緒。光這一項在大機器上就能碾壓；如果再疊上 10 到 20 個「手工做太煩」的優化，差距會拉到不可思議的程度。
在遊戲 AI 領域，每提升一倍速度大約多 100 Elo（Elo 是棋類積分單位，分數越高代表越強，這裡用來衡量 AI 強度的差異），這個數字比西洋棋大得多，可能因為 Azul 極少和棋。
對於「能多打 2% 效能但要花 N 人天驗證」這種過去被擱置的優化，現在 N 已經降到 1000 倍以下（人類時間），甚至百萬倍。每個人都會找到一堆「過去不值得做、現在划算」的微優化。
工作負載特化優化成為新常態
Jamie Brandon 在準備 Anthropic 效能面試的 takehome（公司給回家做的技術作業）時，讓 Claude 接手他做到一半的工作，結果大幅勝過他自己的版本。他說 Claude 做的很多優化他都想到了，只是還沒做；還有些「除非花幾週專心做，不然我絕不會嘗試的瘋狂東西」。
這個案例的關鍵意義：就算是受過訓練的效能工程師，在有明確邊界的優化問題上，也無法跟一個「還行」的 AI 模型競爭。
回到作者自己的實驗：他讓 agent 針對自己的 ripgrep 查詢做了「工作負載特化」優化，大約 2 分鐘就啟動完成。第一輪跑完保留測試集有 2% 加速，而且還在繼續改善。2% 看起來不多，但考慮到「只是順手試試」、且仍在改進中，作者說他會收下這個成果。
過去我們擔心「過擬合」（overfitting，AI 把測試題背下來但遇到新題就不會寫）會讓這類優化失效，但只要你清楚這是「為我的工作負載量身訂做」，就能接受這個 trade-off（取捨）。資料集一直在變，模型也在持續學習新的查詢模式。
軟體不該繼續慢下去
作者長期反對「某個軟體的開發者很爛應該感到羞愧」這種說法。事實上，多數程式設計師沒有受過效能專家訓練，而且從商業角度、就業市場來看，多數專案本來就沒必要培養這種專業。問題不在於開發者，而是過去做效能優化的成本太高，無法普及。
但這個時代已經結束了。
現在，一個對 LLM 有基本熟悉度的人（不是效能專家），就應該能寫出效能合理的軟體。當你叫 LLM「幫我優化」，它會做出很多錯誤的東西，需要你抓；但這本來就是「有效使用 LLM」的一部分。
Jamie Brandon 拿到了 Anthropic 的 offer，但一般人請不起他。然而請一個 AI agent 在「有限範圍的優化問題」上打敗他，這件事現在做得到。
為什麼這件事重要
這篇文章不只是 danluu 個人的實驗記錄，它具體展示了 AI 對工程文化帶來的三個深層影響：
-
效能專業的去神秘化：過去 JIT 編譯器、SIMD 指令（CPU 的「一次算多筆資料」特殊指令）、自訂記憶體池、快取感知演算法這些東西需要專家數月甚至數年鑽研，現在一個工程師打字給 agent 就能完成 70% 的價值。
-
「為特定工作負載客製化」成為主流：過去 SaaS 產品強調「一套軟體服務所有客戶」，但當優化成本降到接近零，每個客戶都可以得到「為我量身打造的版本」。BitFunnel 已經證明這件事可行，現在門檻低到個人開發者也能做。
-
遊戲規則改變對資深工程師的衝擊：Jamie Brandon（公認的資深前端與效能專家）公開說自己在某些任務上已經輸給 AI。這不是說工程師會失業，而是說「稀缺技能」的定義會快速改變。
數據解讀與質疑
danluu 這篇文章的實驗數字相對保守（2% 到 4% 在長查詢、7% 在 holdout），但這反映的是「個人幾分鐘的 AI 互動」的結果。如果讓 agent 跑一天、針對整個工作流程做深度優化，加速比可能會到 10 倍甚至更高。
值得保留的質疑點：
- 過擬合風險：作者自己承認，FRE 在 rebar benchmark 上嚴重過擬合，直到他提示有 holdout 才改善。對企業而言，把「客戶實際查詢模式」餵給 AI 自動產生客製版本，需要配套監控機制，否則遇到「客戶工作模式改變」時就會失靈。
- 非同步編譯的代價：ripgrep 範例顯示，用一個執行緒跑 AOT 編譯器會犧牲短查詢的效能。這在「個人開發者偶爾跑一次」沒問題，但對「每秒幾萬次查詢」的 SaaS 服務來說，這個成本結構完全不同。
- 專家仍然不可取代：在「開放式、沒明確邊界」的優化問題上（例如重新設計整個資料庫引擎），AI 仍會犯錯。文章中的藍圖案例雖然成功，但作者也承認「現在公開的 SOTA 模型在實驗設計上還不夠好」，需要人類先把測試框架架好。
附錄：codex 跑 ripgrep 的真實分佈
作者統計一個月內 codex 在他的筆電上呼叫 ripgrep 的 99 分位數查詢時間（p99，將所有查詢由快到慢排序，第 99 名的耗時，意即 99% 的查詢都比這個更快）接近 1 分鐘，99.9 分位數（p999）接近 10 分鐘，最長的查詢跑了將近 2 小時。
模式長度的中位數（p50）是 55 個字元，p90 是 119 個字元，遠比人手工寫的 grep 指令長。99% 是 regex 查詢，99.9% 是 ASCII 純英文；但被搜的檔案中 55% 包含 Unicode，這個比例比預期高。
編按：本文綜合整理自 danluu 部落格「There’s no reason for software to be slow anymore」、Marc Brooker、Michael Malis、Jamie Brandon 的公開回應，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)