這部影片延續「Loop Engineering（迴圈工程）」的主題，透過 codila 的一篇長文，具體剖析 Andrej Karpathy 如何用一個只有六百多行的 AutoResearch 迴圈，讓 AI agent 自己跑實驗、改模型。影片還介紹了一篇論文如何在 Karpathy 的 loop 上再套一層「元迴圈」，把改進幅度直接拉到五倍，並提醒我們：loop 改變工作方式，卻不會把人從思考中刪除。

---

原影片連結：https://youtu.be/tyO5L2iOxoU

影片重點

• prompt 是「一次指令」，loop 是「一個目標」——你只定義一次「什麼算完成」，其餘交給 agent 自己發現、動手、檢查、重來。
• 讓 loop 真正成立的三要素：驗證器（判真假的檢查）、狀態檔（記下試過什麼）、停止條件（達標或跑滿 N 輪）。
• Karpathy 的 AutoResearch 只有三個檔案、約 630 行，一個月衝到六萬多顆星，被 Fortune 稱為「The Karpathy Loop」。
• 關鍵設計：agent 只能改 train.py，不能碰評分器 prepare.py，避免它「把考試改簡單而不是把模型改好」。
• 實測成果：Karpathy 手工調了二十年的模型，agent 跑兩天、七百次實驗，找出二十處他漏掉的改進。
• Shopify CEO 用它跑一晚，讓 8 億參數模型贏過原本 16 億參數的模型 19%。
• 核心洞察：只要有客觀指標，跑實驗的人就不該是你——你是瓶頸，把自己從迴圈裡拿掉。
• 「雙層 AutoResearch」論文：在內層 loop 上再套一層外層 loop 去研究「怎麼搜」，驗證損失改進達單層的五倍。
• 五倍的提升來自架構而非更聰明的模型，兩層用的是同一個 LLM。
• loop 適不適合你的日常 coding，關鍵在「驗證能不能自動化」；同時要警惕「理解債」與「認知投降」。

詳細內容

00:00 從 prompt 到 loop：視角的切換

影片開場延續上一期 Loop Engineering 的主題：從「給 AI 打字的人」，轉變為「寫那個替你打字的 loop 的人」。作者讀到 codila 的一篇長文，正好把這套概念落到一個具體的人身上——Andrej Karpathy，而且文中還有人把他的方法再提速五倍。

一句話區分兩者：一條 prompt 是一次指令，你問它答，下一步做什麼由你決定；一個 loop 是一個目標，你只定義一次「什麼算完成」，它自己去發現要做什麼、動手做、檢查結果，沒到就把結果餵回去再跑一輪。

文章強調，讓 loop 真正成立的是三樣東西：一個驗證器（能判真假的檢查，沒有它 agent 只是反覆對自己點頭）、一個狀態檔（記下試過什麼，否則每輪都犯同樣的錯）、一個停止條件（達成目標，或跑滿 N 輪就停下彙報）。

01:20 AutoResearch：三個檔案、630 行、六萬顆星

今年三月，Karpathy 放出名為 AutoResearch 的倉庫，三個檔案、約 630 行程式碼，一個月衝到六萬多顆星，Fortune 雜誌稱它為「The Karpathy Loop」。

它的結構簡單到離譜：第一個檔案 train.py 是訓練腳本，是唯一允許 agent 修改的檔案；第二個 prepare.py 是給模型打分的評分器，agent 不許碰——因為若它能碰，它會去把考試改簡單，而不是把模型改好；第三個 program.md 是你寫給 agent 的說明，告訴它探索什麼、守住哪些約束。

迴圈這樣運轉：agent 讀一遍程式碼、提一個改動，把改過的小模型從頭訓練五分鐘（算力固定、掐錶計時），然後看驗證指標有沒有變好——變好就 commit 成新基線，沒變好就 git reset 回退，再來一輪。你去睡覺，醒來看到的是一整份實驗日誌，和一個但願更好的模型。

02:40 成果：agent 不會累，也不執著於「越大越好」

整個過程你不碰 train.py，只寫 program.md，跑實驗這件事交給 agent。成果很能說明問題：Karpathy 拿一個他手工打磨了二十年的模型，讓 agent 跑兩天、七百次實驗，找出二十處他自己漏掉的改進。

其中一處是注意力機制裡少了一個縮放係數，讓注意力在各個頭之間攤得太散。這不是模糊測試能抓到的 bug，而是一個細心的人本可以發現、卻沒發現的優化——因為人做到第十二個實驗就累了，agent 不會累。

Shopify 的 CEO Tobi Lütke 也拿它在內部模型上跑了一晚，醒來時一個 8 億參數的模型，比它要替換掉的 16 億參數模型還高出 19%。一半的大小反而更好，因為 agent 是衝著硬體去優化的，而不是預設「越大越好」。Karpathy 的核心洞察是：只要你有一個客觀指標，那個跑實驗的人就不該是你，你是瓶頸，把自己從迴圈裡拿掉。

04:00 一個能跑起來的 loop 有哪五塊

文章把一個真正能跑起來的 loop 拆成五塊：自動觸發（心跳，Claude Code 裡是 /loop 和 /goal，Codex 裡是 Automations）；skill（把專案知識寫一次，每輪都讀）；子 agent（把「寫的」和「審的」拆成兩個，因為寫程式那個給自己打分太寬鬆）；連接器（讓 loop 能去開 PR、貼 ticket）；最後是驗證器（自動把壞結果擋回去的閘門）。

作者認同文章裡的一句話：其它四樣都是管道，驗證器才是讓 loop 成立的那一塊；沒有它，你只是在花錢買一個整晚都在自我認同的 agent。

05:10 五倍從哪來：雙層 AutoResearch

同樣是今年三月，兩位研究者發了一篇論文《Bilevel Autoresearch》（雙層自動研究），副標題更直白——讓 autoresearch 來研究 autoresearch 它自己。

他們的做法是在 Karpathy 那個 loop 上面再套一層。內層 loop 做的就是 Karpathy 原本那套：提改動、訓練、評估、留下或丟棄。外層 loop 不碰模型，它盯著內層跑，讀內層的程式碼和運行軌跡，找出這個搜索過程本身卡在哪，然後生成一段新的 Python 程式碼去改變內層「怎麼搜」，注入後再讓內層跑一遍。

結果，在 Karpathy 那個 GPT 預訓練基準上，驗證損失的改進是單層 loop 的五倍——不是好 5%，是整整五倍。要注意兩件事：兩層用的是同一個 LLM，你不需要更聰明的模型來當「元」層；提升來自架構，而不是來自更強的智能。

06:30 外層發現了什麼

外層到底發現了什麼？它發現內層老是掉進同樣的搜索套路——模型對「該試什麼優化」有一套先驗，哪怕這套先驗已經不管用了，它還是一次次繞回去。外層做的，就是強行把它推向那些它本能會迴避的方向，打破這個套路。

論文結尾有一句話值得琢磨：如果自動研究能對它自己做元研究，那原則上，它能對任何一個有可度量目標的東西做元研究。

07:20 你現在就能試：一段提示詞搭出 loop

不用 Claude Code、不用 Codex，你現在就能感受這個機制。文章給了一段提示詞，貼進任意大模型即可。核心是四步、每輪重複：先說下一步做什麼，然後動手做，接著按你定的標準給結果打分並誠實列出還差在哪，最後判斷——每一項都到八分以上就收工，沒到就再來一輪，先修最弱的那一項。

模型會自己起草、自己對著標準打分、找到弱點、重寫，直到過線。這就是一個 loop，你用一段話就搭出來了。當然它是簡化版：你還是那個觸發器，沒有調度、沒有持久狀態，關掉分頁就沒了；但核心機制就在這裡，往上再補自動觸發、狀態檔、驗證閘門，就是一個真正自主的 loop。

08:30 這套適不適合你的日常 coding

關鍵就看那個「四條件測試」裡最要命的一條：驗證能不能自動化。能，就適合搭成 loop——比如讓一批失敗的測試全變綠、對著 benchmark 把某段程式跑得更快、把型別錯誤清零、把打包體積壓下去，這些都有一個能自動判真假的裁判，loop 是在真的搜索方案。

不能，就別硬套——像設計一個新介面、搭一個新頁面、需求本身還模糊的活，對不對只能靠人判斷，loop 要麼發酵過頭把本來能編譯的程式改壞，要麼給自己的作業打高分。所以對多數人的日常 coding，現在更穩的還是你開著 Claude Code 或 Codex、人在環裡邊跑邊審——先把驗證器立起來，再談讓它自己跑。

09:40 loop 不會把你從工作裡刪掉

最後是文章裡最清醒的一段。loop 改變工作，但不會把你從工作裡刪掉。而且有兩個問題會隨著 loop 越來越好而變得更尖銳：一個是理解債——loop 越快交付你沒親手寫的程式，你倉庫裡有的與你腦子裡真懂的，差距就越大；另一個是認知投降——當 loop 自己在跑，你會很想停止判斷，照單全收。

同一個 loop，兩個人能用出完全相反的結果：一個人用它在自己深懂的領域跑得更快，另一個人用它來迴避搞懂這件事。loop 分不清這兩者，但你分得清。文章最後那句話很值得帶走：Karpathy 不寫程式了，Cherny 不 prompt 了，但他們兩個都沒有停止思考。

我的想法

這期最打動我的不是「五倍」這個數字，而是它背後的思路：真正的槓桿往往不在「做得更好」，而在「改變怎麼做」。雙層 loop 用同一個 LLM、只靠多套一層架構就拿到五倍，某種程度上呼應了系統設計裡常見的道理——瓶頸經常出在流程結構，而不是單點的算力或智力。

不過我更想強調影片裡那句「驗證器才是讓 loop 成立的那一塊」。在日常開發中，我們很容易被自動化的成果沖昏頭，卻忘了如果沒有一個誠實、客觀、無法被作弊的裁判，agent 的自我打分幾乎沒有意義。這也解釋了為什麼 prepare.py 要禁止 agent 修改——這不是技術限制，而是一種制度設計，防止「優化目標」被替換成「優化指標」。這個 reward hacking（獎勵駭入）的風險，值得每個要搭自動化流程的人放在心上。

最後，「理解債」與「認知投降」是我認為最該被反覆提醒的兩點。loop 能幫你更快抵達，但它無法替你理解。真正拉開差距的，從來不是誰的 agent 跑得快，而是誰在 agent 跑的時候還在持續思考。與其擔心被工具取代，不如把工具當成放大器——放大你的理解，而不是替代它。