📍 真實場景
小林，電商後台的後端工程師，負責維護商品訂單查詢服務
尖峰時段系統要在數百萬筆訂單資料裡做大量比對與篩選，回應越來越慢，主管一直催他優化
😖 卡住的地方：他知道『寫一個超快的比對引擎』或『客製一個 JIT 編譯器』是效能優化的終極解法，但這種活以前只有頂尖系統工程師做得到，他連從哪裡下手都不知道
💡 看完這課會知道，現在借助 AI 代理人跑優化迴圈，連沒受過編譯器訓練的工程師，都能做出比通用做法更快、更貼合自己資料特性的客製版本——但也要懂得避開『調到只服務單一測試』的陷阱
🧭 這到底是什麼（白話版）
這篇文章的起點是一則在網路上吵起來的討論：有人酸『靠 AI 寫程式的人未來會被迫用超優化的組合語言重寫一切』，但作者反駁說，重點不是要不要用組合語言，而是『效能優化』這件事的成本正在崩跌。他舉例，JIT 編譯器在程式執行的當下，即時把常執行的程式碼片段編譯成更快的機器碼，而不是事先全部編譯好 這種技術，原理教科書都寫得到，但過去因為『做出來太難』而很稀少，現在借助 AI，任何工程師都做得出堪用版本。
文章用一個真實案例撐起整個論點：作者的團隊讓一個 AI 代理人，針對一套叫做 rebar 的benchmark（效能基準測試）用一組固定的測試題目，量化比較不同程式或版本誰跑得比較快 ，自主跑了一整個月的優化迴圈，做出一個叫 FRE 的正規表達式引擎專門用來比對「文字符合某種樣式」的程式，例如判斷一個字串是不是 email 格式 。結果分數高到嚇人，但也踩到一個經典陷阱。
那個陷阱叫過度配適（overfit）針對某一份測試資料調到極致，導致遇到其他沒看過的資料反而表現變差 ——AI 代理人把程式碼刻死成剛好吃透 rebar 這份考題的資料特性，換一批沒看過的資料，表現就沒那麼神。團隊後來告訴代理人『還留了一份你沒看過的holdout（保留測試集）刻意留一份沒讓對方看過的測試資料，用來檢查優化成果是不是「作弊式」地只對特定考題有效 』，逼它做出更通用一點的優化，結果才總算過關。
作者最後把這件事拉高到一個產業趨勢：以後軟體會更常從『服務一整類問題的通用引擎』，走向『只為某一份特定工作負載量身訂做』，就像訊號處理函式庫 FFTW 會依硬體特性自動挑最快演算法，或早年 demoscene 工程師把程式碼直接塞進材質提升快取命中率一樣。這不是全新概念，只是 AI 讓『值得客製化』的專案範圍，從極少數大型計畫，擴大到幾乎任何人手上的專案。
🎯 為什麼值得你花時間
效能優化的『人才門檻』正在消失 過去做 JIT 編譯器、客製正規表達式引擎，需要極少數精通底層的工程師；現在有 AI 代理人輔助，會打字描述需求、看得懂測試結果的人就能生出堪用版本，稀缺技能變成人人可取得的工具。
軟體會從『通用』走向『量身訂做』 FFTW（依硬體特性自動挑最快演算法的訊號處理函式庫）跟老派 demoscene 技巧都是『只為某一種特定工作負載』客製化的例子；以後這種做法會更常見，效能更好，但也代表要重新評估維護風險。
『在測試集上調到最好』不等於『真的變快』 FRE 引擎的實驗說明：只顧著在單一測試集刷分，AI 代理人會把程式過度配適到只在那份考題上表現好，一定要留一份沒給它看過的 holdout 測試集，才能驗證優化是不是真本事。
⚙️ 它是怎麼運作的
1
先找一套公認的效能考題 團隊選用 rebar 這套業界公認的正規表達式效能測試組，做為 AI 代理人優化的評分標準。
▼
2
讓 AI 代理人自己跑優化迴圈，跑上一整個月 不是工程師手動調，而是設定好目標和測試方式後，讓 AI 代理人自主嘗試各種改法、跑測試、看分數、再改，日夜不停跑了一個月。
▼
3
意外過度配適：只在考題上厲害 代理人跑出來的 FRE 引擎，在 rebar 這份考題上分數超高，但那其實是因為它把程式碼量身打造到剛好吃透這份考題的資料特性，不代表遇到其他資料也一樣快。
▼
4
加入 holdout 測試集，逼它練『真功夫』 團隊告訴代理人『我們還留了一份你沒看過的測試資料』，代理人因此被迫做出更通用、不是靠死記硬背考古題的優化方式，在新資料上表現才總算『還可以』。
▼
5
跟其他手法比對，理解客製化的本質 文章把這種『為特定工作負載量身訂做』跟 FFTW、demoscene 的老招數放在一起看，說明這件事不是新概念，只是 AI 讓門檻大幅降低，讓更多場景值得投入。
傳統效能優化 vs. AI 輔助效能優化，差在哪裡
面向 傳統做法 AI 輔助做法（文章觀點） 需要的人才 極少數精通底層/編譯器的資深工程師 任何能清楚描述需求、會看測試結果的工程師 值不值得做 只有最大規模、最賺錢的專案才划算 中小型專案、單一工作負載也可能划算 最大風險 開發時間太長、根本做不出來 容易『過度配適』測試集，需要 holdout 驗證才可靠 代表案例 FFTW、demoscene 手工優化 FRE 正規表達式引擎、pgrust JIT 專案
🛠️ 動手做：通用查詢 vs. 客製查詢：親眼看『過度配適』怎麼發生
頁面上有兩個查詢函式在賽跑：一個是「通用版」，不管資料長怎樣都能用；另一個是「客製版」，是針對『訂單編號一定在 100000~199999』這個已知特性打造的。
按下「情境一：用原本假設的工作負載測試」，看客製版靠著這個假設贏了通用版多少。
按下「情境二：換一批超出原本假設的陌生資料」，觀察客製版的表現會發生什麼事——這就是文章講的過度配適風險，跟 FRE 引擎在 rebar 考題上調到最高分、換一份沒看過的資料就現出原形，是同一種道理。 👇 下面是活的，直接操作 ↻ 重來一次
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼團隊要刻意留一份 AI 代理人『沒看過』的 holdout 測試集，而不是讓它用所有考古題全力衝分？
這是效能工程裡『過度配適 vs. 真通用』的經典取捨。如果只用單一 benchmark 當唯一目標，AI 代理人（人類工程師也一樣）很容易找到『鑽考題漏洞』的捷徑，把程式碼刻死成剛好吃該測試資料的特性，分數超高卻換一批資料就爆炸。留一份 holdout，等於逼優化過程往『這招在沒看過的情境下也還算合理』的方向收斂，犧牲一點極限分數，換來的是可以真的上線的可靠度——跟機器學習裡訓練集/測試集分離是同一個道理，只是這裡拿來測『程式碼』而不是『模型』。
🔭 文章說『動態客製軟體』會帶來『各種好玩的風險與機會』，資深工程師實際上在賭什麼？
當你把軟體從『服務一整類問題的通用引擎』換成『只服務我這份特定工作負載的客製版』，其實是拿『維護成本』換『效能』。通用引擎（像標準 regex library）已經被無數專案、無數奇怪的輸入洗禮過，邊界案例都踩過雷；客製版是為了你手上這批資料量身打造，換了資料特性、換了硬體、甚至只是資料量成長，原本的假設可能整套失效，而且因為只有你自己在用，社群不會幫你踩雷。這代表以後『要不要客製化』會變成一個要持續重新評估的決策，而不是做一次就永久受益的工程投資。
🔭 作者引用 Michael Malis 說『寫程式碼本身就是難的部分』，這跟『AI 讓效能優化變便宜』有什麼因果關係？
很多效能優化技術（像 JIT 編譯器）背後的原理其實不是秘密，教科書都寫得清清楚楚，真正卡住大多數團隊的是『把這套已知原理，正確無誤地實作出來』這件事——這需要大量、精細、容易出錯的工程細節。當 LLM 把『把已知原理轉成能跑的程式碼』這一步的成本壓低到接近打幾句話，原本『原理都懂但沒人做得出來』的技術（像 JIT、客製正規表達式引擎），一下子就從『只有頂尖團隊玩得起』變成『任何看得懂需求的工程師都能生出堪用版本』。這解釋了為什麼作者說軟體慢『再也沒有藉口』——不是運算資源變便宜了，是『把優化做出來』這件事本身變便宜了。
📝 隨堂考（點選答案，立即回饋）
Q1. 文章提到 FRE 這個由 AI 代理人跑了一個月優化出來的正規表達式引擎，一開始被發現有什麼問題？
跑不動，直接當機
過度配適在 rebar 這份測試集上，換其他資料表現沒那麼好
程式碼完全看不懂，沒人能維護
比原本的引擎慢十倍
✅ 文章明講 FRE『heavily overfit to rebar』，直到團隊警告還有一份 holdout 測試集，AI 代理人才被迫把優化改得更通用。
Q2. 根據文章，Marc Brooker 提到的 FFTW 和老派 demoscene 技巧，共同點是什麼？
都是針對特定硬體/特定問題量身打造，而不是服務一整類通用需求
都已經被 AI 完全取代，不再有人用
都跟正規表達式引擎的原理完全一樣
都是 1990 年代才出現的新技術
✅ 文章把 FFTW（依硬體特性自動挑最快演算法的訊號處理函式庫）跟 demoscene 手法（例如把程式碼塞進材質提升快取命中率）都當成『針對特定問題/硬體客製化』的例子。
Q3. 文章裡 Michael Malis 認為，JIT 編譯器過去很少見的真正原因是什麼？
因為運算資源不夠貴，用不到 JIT
因為實作 JIT 編譯器歷史上太困難，門檻高到不值得投入
因為 JIT 編譯器對效能完全沒幫助
因為法律規定禁止使用 JIT 技術
✅ 原文寫『implementing a JIT compiler historically was too difficult for it to be worthwhile』，重點在『做出來的成本太高』，不是技術沒用或資源問題。
Q4. 文章開頭提到一則爆紅推文，內容在嘲諷什麼立場的人？
嘲諷認為 LLM 會造成程式碼變慢、變臃腫的人，將來要用超優化組合語言重寫全部程式
嘲諷所有還在用 Python 的工程師
嘲諷不會用 AI 寫程式的資深工程師
嘲諷組合語言已經過時的人
✅ 文章第一句就在講一則推文，內容是諷刺『覺得 LLM 造成程式碼慢又臃腫的人，以後全部重寫成超優化組合語言就會被打臉』的立場。
🃏 翻牌記憶卡（先想答案，再點開對答）
JIT 編譯器點我翻面
程式執行到一半，即時把常跑的那段程式碼編譯成更快的機器碼，而不是事先整份編譯好（跟 AOT 相對）。
holdout 測試集點我翻面
刻意留一份優化過程完全沒看過的測試資料，事後拿來檢查優化成果是不是只在『它看過的考題』上作弊式地表現好。
過度配適（overfit）點我翻面
為了在某一份特定測試/資料上衝到最高分，把程式或模型調到只適合那份資料，換一批沒看過的資料反而表現變差。
AOT 編譯（Ahead-of-Time）點我翻面
程式在真正執行之前，就先整份翻譯成機器碼備好，跟『邊執行邊翻譯』的 JIT 相對。
為特定工作負載客製化點我翻面
不是寫一個服務『所有情況』的通用程式，而是針對『我現在手上這批資料/這個場景』的特性去量身打造，換取更高效能。
ai-lecturer 教案工廠｜藍圖 flash-full-v1.0｜本頁零外部依賴，離線可開