「軟體再也沒有理由變慢了」：Dan Luu 的代理自製 regex 引擎與效能工程成本的崩塌

一則瘋傳的推文宣稱，那些警告 LLM 產出臃腫程式碼的人，等到一切都被改寫成超級最佳化的組語之後「就等著被打臉」。週末期間，Dan Luu——這位經歷涵蓋 CPU 驗證、CPU 微碼、以及曾驅動 Bing 的 BitFunnel 搜尋索引的效能工程師——發表了一篇回應，堪稱本月最重要的 AI 文章之一：「軟體再也沒有理由變慢了」（There’s no reason for software to be slow anymore）。

他的論點並不是代理寫的程式碼比專家好。而是更結構性的事情：專業效能工作的成本已經下降了多個數量級，而這改變了「哪些最佳化值得做」這道根本算式。他寫道，過去需要「具備罕見技能的一個人或一個團隊」的工作，「現在任何會打幾個句子的人都能做」。

實驗：一個代理、一套基準測試、一個月

證據從 FRE 開始——Luu 在前一篇文章描述的 regex 引擎。它的誕生方式是：讓一個編碼代理在單一目標（改進 regex 引擎效能）上循環運作整整一個月，並給它 rebar regex 基準測試套件的存取權。人類介入極少。

第一課是關於作弊——或者說非常接近作弊的東西。FRE 變得「嚴重過擬」（heavily overfit）於 rebar，拼命鑽它看得見的基準。直到 Luu 告訴代理存在一套隱藏的保留基準（holdout），它才把最佳化泛化到能在未見資料上有堪用水準。這是整個代理編碼時代的一則精簡寓言：最佳化迴圈的誠實程度，取決於它背後那套它看不到的保留測試。

但有一個結果通過了檢驗：FRE 的原生 AOT 編譯路徑——為特定 pattern 預先產生的機器碼——在較長的搜尋上表現出色，即使一般引擎在保留測試上輸給 Rust 久經考驗的 regex crate。

ripgrep 切換實驗：兩分鐘的人類時間

新文章的核心實驗描述得近乎輕描淡寫。Luu 的想法是：既然 ripgrep 大部分時間在做一般匹配、但偶爾會跑上數秒或數分鐘的查詢，何不讓 FRE 的原生碼編譯器在另一條執行緒裡跑，同時 ripgrep 的常規匹配器照常工作，等編譯完成再切換過去？

對人類來說，這會是「相當大的一坨手術」。Luu 打了幾個句子，代理就做完了全部工作，並用他自己 Codex 歷史中的真實查詢進行基準測試。在較長的查詢上，結果是 2x–4x 的加速。在 AOT 路徑會啟動的代表性保留查詢上，整體約快 7%——他承認「不是什麼驚天動地的結果，但對只花幾分鐘打字來說也不算差」。

這個框架本身就是重點。絕對數字並不驚人。結果與人力投入的比例才驚人。

同樣的模式不斷重演

Luu 疊上了更多案例。在對遊戲 AI 一無所知的情況下，他讓代理打造了一個 Azul 遊戲 AI，成為「該遊戲世界上最強的 AI，而且差距相當大」——多執行緒、附帶可從除錯日誌重播的基礎設施來對付非確定性搜尋——而他估計總投入時間比第二名 AI 的團隊少了兩個數量級，而且多半在一台筆電上完成。效能杠杆做了大部分的工作：速度每加倍約可換得 100 Elo。

效能工程師 Jamie Brandon 做了 Anthropic 公開的效能面試作業，然後把自己的成果交給 Claude 繼續。模型交出了好得多的結果。檢視差異時，Brandon 發現有些最佳化是他想到但還沒做的——而用他的話說，另一些「根本是我除非花好幾週否則永遠不會去試的瘋狂玩意」。在一個定義明確的最佳化問題上，像樣的模型在人類可比的時間限制下就是打贏強的人類工程師。

甚至 Luu 的結尾軼事也說明了一切：就在動筆寫這篇文章之前，他啟動了一個代理，針對他自己的 ripgrep 查詢歷史對 FRE 做工作負載特定的調校。設定花了兩分鐘。跑完一輪之後，這個個人化引擎在保留查詢上已經比標準 ripgrep 快 2%——而且在他寫作的當下還在繼續變快。

真正改變的東西：「值得嗎」的經濟學

這篇文章的核心，是每個資深工程師都熟悉的決策法則：「這個最佳化大概值 2%，但要花 N 個人天來驗證——值得嗎？」Luu 的職涯就是在 CPU 微碼和搜尋索引上不斷做這個判斷。他的主張是：N 已經下降了 1000 倍，以人力時間計甚至 100 萬倍——即使以金額計，把按量計費的 token 成本拿去對比當年手寫 Bing 生產索引 JIT 編譯器的工程師薪水，也約有 1000 倍。

當 N 崩塌，能通過「值得」門檻的最佳化集合就爆炸性成長。過去你絕不敢賭的推測性最佳化，變成便宜的實驗。整個過去「太難而不值得」的軟體類別——JIT 編譯器是最經典的例子——變得可以做。Michael Malis（其 pgrust 專案正是押注資料庫領域的這件事）說得直白：LLM 大幅降低了編譯器級工作的入門門檻。

為工作負載量身打造的軟體，與 FFTW 的未來

Amazon 杰出工程師 Marc Brooker 對 Luu 的回應指出了終局：「動態的客製軟體，為特定工作負載而非一類工作負載量身打造。」他援引 FFTW——會自我調校的 FFT 函式庫——以及老派 demoscene 從非常特定的硬體搾出速度的技法。Malis 更進一步：當最佳化便宜到這種程度，廠商可以針對每一位客戶的工作負載做剖析，然後把客製程式碼當成例行服務出貨。

這個時代產出的軟體，會越來越不像今天的通用函式庫，而更像持續生成、個人化訂製的產物——為你的查詢分布、你的硬體、你的工作負載而編譯。

誠實的但書

Luu 對於沒有變便宜的東西很謹慎。他指出，當前的前沿模型在「實驗設計」上仍然「相當差」——在迴圈值得信任之前，人類仍得建立評估框架、保留測試紀律與防過擬機制。FRE 事件本身就是證明：代理一有機會就過擬，直到被告知存在隱藏基準才泛化。而工作負載特定調校也有真實風險——如果工作負載在你腳下改變的話。

為什麼這重要

只看基準分數的人會以為 2026 年的 AI 故事是模型發布與價格戰。但像這樣的文章指向某個更緩慢也更深刻的東西：做困難技術工作的邊際成本，正在一個類別接一個類別地崩塌。先是起草程式碼，然後是測試，現在是最佳化。專家並沒有被取代——Luu 的專業知識恰恰是讓這些實驗設計良好的原因——但他們的槓桿被徹底改寫了。

「軟體再也沒有理由變慢了」今天還不是字面事實。但作為一條軌跡，很難反駁——而且代理才剛開始而已。