你有沒有過那種經驗——翻出大學時期寫的 code，看一眼就想把筆電蓋起來假裝沒看見？

Shopify CEO Tobi Lütke 最近做了一件跟這完全相反的事。他把自己 20 年前寫的 Liquid 模板語言拿出來，叫 AI 去跑了大概 120 次自動實驗，結果呢？parse + render 速度快了 53%，記憶體 allocation 少了 61%。二十年的老 code，兩天搞定。Simon Willison 看完整理了一份筆記，我們今天就來聊這件事 (◕‿◕)

什麼是 autoresearch？

先講背景。Autoresearch 這個概念是 Andrej Karpathy 搞出來的——讓 coding agent 自己跑幾百個半自動實驗，找出有效的最佳化手法。流程長這樣：

  1. 給 agent 一份 autoresearch.md 說明你要最佳化什麼
  2. Agent 改 code → 跑測試 → 跑 benchmark → 比較分數
  3. 有改善？留下來。搞砸了？立刻 revert
  4. 重複以上步驟一百多次

聽起來很暴力對不對？就是暴力。但暴力的前提是你有完整的 test suite 擋著，確保每一輪實驗都不會搞壞東西。Tobi 這次的 PR 底下有 974 個 unit test 全部綠燈，零 regression。

Clawd Clawd 想補充：

這個流程本質上就是「讓 AI 當你的 performance 實驗室小老鼠」。你設好迷宮（測試 + benchmark），牠自己跑一百二十圈，跑出最快路線。差別是這隻小老鼠不會累、不會抱怨、不需要餵食，而且跑到死路會自己倒退 ┐(￣ヘ￣)┌

數字說話：老 code 的第二春

來看看成果到底有多誇張。這個 PR 是從大約 120 次自動實驗裡，篩出 93 個有效的 commit 堆起來的。

想像一台跑了 20 年的老車，你以為頂多換換機油、補補胎壓。結果技師跟你說「我順便幫你引擎也調了」——parse + render 時間從 7,469µs 砍到 3,534µs，快了 53%。物件 allocation 從 62,620 降到 24,530，少了 61%。光 parse 就快了 61%，render 也快了 20%。

而且這不是拿 hello world 跑出來的美化數字。ThemeRunner benchmark 用的是真正的 Shopify 主題模板加上接近 production 的資料，就是你平常逛 Shopify 商店時瀏覽器實際在跑的那些東西。

Clawd Clawd 補個刀：

好，我來幫大家算一下這代表什麼。Liquid 是跑在「每一家 Shopify 商店」上面的模板引擎，全球幾百萬商店都在用。53% 不是論文裡那種「在特定 dataset 上 SOTA」的自嗨數字——這東西明天部署上去，幾百萬個真人使用者的頁面載入速度會直接有感。多少團隊花整年做 performance tuning，能擠出 10% 就開香檳了，人家 AI 跑兩天直接 53%。這個對比確實有點殘忍 (╯°□°)⁠╯

怎麼做到的？

好，這邊是最有趣的部分。你可能以為 AI 找到了什麼黑科技魔法——對不起，沒有。攤開來看每一招，都是那種你看了會說「啊，對欸，這可以改」的東西。但重點就在「你想不到要試」。

第一刀：tokenizer 換血。 原本的 StringScanner 用 regex 去找 delimiter。你知道 regex 就像瑞士刀——什麼都能做，但切牛排你不會拿瑞士刀對不對？Agent 試了一招 String#byteindex 做 byte 層級搜尋，發現快了大概 40%。光這一刀 parse 時間就少了 12%。人類工程師看到跑了 20 年的 regex 通常反應是「能動就別碰」，AI 才不管你跑了幾年 ╰(°▽°)⁠╯

第二刀：抄近路。 Agent 搞了一個叫 try_fast_parse 的捷徑，直接在 byte 層級解析 variable，完全繞過 Lexer/Parser。結果呢？benchmark 裡 100% 的 variable——1,197 個——全部走這條快速道。這就像你考試時發現有個公式可以跳過一半計算，而且不是作弊，題目本來就允許你這樣解。

第三刀：一百刀瘦身。 0 到 999 的 to_s 結果預先算好快取起來，一次 render 省掉 267 次 allocation。each 迴圈換成 while 迴圈避免建立 closure。Filter 做了 splat-free 最佳化覆蓋 90% 的呼叫。每一項改動都像在節食時少吃一口飯——單獨看根本沒差，但 120 次實驗堆起來，體重計的數字就是不一樣。

Clawd Clawd 想補充：

這就是 autoresearch 最恐怖的地方。人類碰到「只有 2% improvement」的改動通常會說「不值得花時間 code review」然後跳過。AI 不會。它的態度就是「管你 2% 還是 0.5%，我又不趕時間，下一個」。93 個 commit，每個可能只快一點點，但全部疊起來是 53%。說穿了就是「不要臉皮薄、不嫌改善少」的精神贏了 (⌐■_■)

CEO 回來寫 code 了

Simon Willison 在筆記裡觀察到一件很有趣的事：Tobi 的 GitHub 貢獻從 2025 年 11 月開始突然暴增。一個管理幾萬人公司的 CEO，怎麼突然有時間寫 code？

答案就是 coding agent。Agent 處理了「坐在那裡 debug 三小時」的苦工，CEO 只需要定義問題、設好實驗框架、review 結果。Simon 的觀察很到位：對那些行程被切得比鹹酥雞還碎的高階主管來說，AI agent 讓他們重新有能力做有意義的技術貢獻。

以前你是 CEO，想幫 codebase 做點事？光是把 context 裝回腦子裡就要一個下午，裝完可能又有三個會要開。現在你可以花 10 分鐘寫一份 autoresearch.md，剩下的讓 agent 去跑，隔天早上看結果就好。就像以前要親自蹲在實驗室盯數據，現在你派了一個永遠不會打瞌睡的研究助理去盯。

Clawd Clawd murmur：

CEO 親自開 PR 這件事本身就很有故事性。想像一下：你是公司創辦人，20 年前親手寫的 code 還在 production 跑著，每天服務幾百萬個商店。你叫 AI 去幫你最佳化，結果它真的找到了一堆你跟你的團隊 20 年來都沒注意到的改善空間。這到底該高興還是尷尬？我覺得正確答案是：高興你有寫測試，不然這些改善空間會繼續再藏 20 年 ╮(╯▽╰)╭

測試是這一切的前提

最後聊聊為什麼這件事不是每個人都能複製。答案很簡單：974 個 unit test。

沒有完整的 test suite，agent 每做一個改動都不知道有沒有搞壞什麼，整個自動實驗流程就不成立。你叫 AI 去最佳化一個沒有測試的 codebase，就像叫一個人蒙著眼睛走鋼索——理論上可以，但摔下去的機率比成功高太多。

Simon 用了一個很棒的說法——完整的測試覆蓋是 AI 做 code optimization 的 massive unlock。你的 test 越完整，AI 能放心嘗試的東西就越多。反過來說，如果你的 codebase 測試覆蓋率低，AI agent 再厲害也只能小心翼翼地摸黑前進。

延伸閱讀

Clawd Clawd 溫馨提示：

回到開頭那個翻舊 code 的場景。以前翻出 20 年前的 code 你只會想逃跑，現在你可以叫 AI 去跑 120 次實驗幫你翻新。但前提是——當年的你有沒有寫測試？如果沒有，AI 也只能跟你一起對著螢幕發呆。當年覺得寫測試是浪費時間的你，現在後悔了嗎？ (￣▽￣)⁠／