當 Karpathy 說「不 work」，你要認真聽

想像一下這個場景：你是 Andrej Karpathy，前 Tesla AI 總監、OpenAI 創始成員，現在你坐在電腦前，盯著八個 terminal 視窗。每個視窗裡都有一個 AI agent 在跑實驗。螢幕很漂亮，像駭客電影。

然後你發現——它們全部都在做白工。

2026 年 2 月 27 日，Karpathy 在 X 上回覆了 Hugging Face 共同創辦人 Thomas Wolf 的一個問題：「NanoGPT speedrun 怎麼還沒有被 AI 全自動化？」

他的回答不是嘴砲，是他真的花了一個週末去實驗 (◍•ᴗ•◍)

8 個 AI agent — 4 個 Claude、4 個 Codex — 每個配一張 GPU，任務是跑 nanochat 的 ML 實驗（具體來說：嘗試移除 logit softcap 而不造成 regression）。

The TLDR is that it doesn’t work and it’s a mess… but it’s still very pretty to look at :)

翻譯：「結論是完全不行，一團亂⋯⋯但螢幕看起來真的很漂亮 :)」

Clawd Clawd 歪樓一下：

Karpathy 說的「很漂亮」就是 8 個 tmux 視窗同時跑 agent，滿螢幕的 terminal output 像控制中心。工程師的浪漫就是這麼樸素——功能不 work 沒關係，畫面好看就值了 (⌐■_■)

組一個 AI 研究團隊，像在排《復仇者聯盟》

Karpathy 試了好幾種組織架構。第一種是放養——8 個獨立研究員，各自為政，自己想題目自己做。結果就像你把 8 個博士生丟進同一間實驗室然後去度假，回來發現每個人都在做不同的事，而且沒有人建 baseline。

第二種是階層制——1 個首席科學家 agent 負責發指令，8 個 junior 研究員負責執行。這比較好一點，至少有人在管方向。

Clawd Clawd 補個刀：

這兩種架構你應該很熟悉吧？第一種就是你那個「扁平化管理」的新創公司，大家都很自主但沒人對齊目標。第二種是傳統大公司的 top-down 管理。有趣的是，管 AI agent 跟管人遇到的問題居然一模一樣——自主性太高會失控，管太緊又缺乏創意。管理學教科書：1，AI 工程師：0 ┐(￣ヘ￣)┌

技術上他的做法很有意思：每個研究項目是一個 git branch，每個 agent fork 出自己的 feature branch，用 git worktrees 做隔離。沒有 Docker，沒有 VM，他覺得靠 instructions 就能防止 agent 互相踩腳。Agent 之間靠簡單的檔案溝通，全部跑在 tmux window grids 裡，像視訊會議一樣排列，可以隨時「接管」任何一個 session。

他特別提到「no -p」——沒用 Claude Code 的 headless 模式，而是讓所有 agent 跑在互動式 session 裡。為什麼？因為他要能隨時看到每個 agent 在幹嘛，必要時直接介入。這不是不信任 AI，這是實戰經驗。

Agent 的致命弱點：執行滿分、思考零分

好，這是整篇最重要的部分。

Karpathy 給了一句話總結，簡單到讓人心痛：

They are very good at implementing any given well-scoped and described idea but they don’t creatively generate them.

Agent 的執行力是 S 級，但創意實驗設計能力是 F 級。

講個具體的故事你就懂了。其中一個 agent，跑了一整天的實驗之後，興奮地回報：「我發現了！增加 hidden size 可以降低 validation loss！」

Clawd Clawd 溫馨提示：

拜託。增加 hidden size 本來就會降低 validation loss 好嗎！在 infinite data regime 下，更大的網路本來就更好，而且這個 agent 還偷偷跑了更久。這根本不是發現，這是統計學第一堂課的內容。

Karpathy 說他不明白為什麼還需要自己出來指出這一點——是啊，你的 AI 研究員連「控制變因」這四個字都不會，這大概等於請了一個期末考統計學被當的實習生來幫你做研究 (╯°□°)⁠╯

除了這個笑話般的「發現」，agent 們還犯了一堆研究的基本錯誤。不建立 baseline——沒有對照組你怎麼知道改進是真的？不控制變因——runtime 和 FLOPs 都不管，那你比較的是什麼？隨便跑一些沒有邏輯的 variation——就像一個學生不看食譜，把冰箱裡所有東西都丟進鍋裡，然後問你「為什麼不好吃」。

這些不是什麼高深的方法論問題。這是你大學研究方法課第一章的內容。Agent 可以幫你寫出完美的 PyTorch training loop，但它不會問自己「等等，這個實驗的假設是什麼？」

核心洞見：你的程式碼不再是程式碼

Karpathy 把這個慘痛教訓昇華成一個很猛的框架：

You are now programming an organization (e.g. a “research org”) and its individual agents, so the “source code” is the collection of prompts, skills, tools, etc. and processes that make it up.

翻譯：你的 source code 不再是 Python 或 TypeScript。你的 source code 是一整套 prompts、skills、tools 和流程——它們定義了一個「組織」如何運作。

他舉了一個讓我起雞皮疙瘩的例子：

E.g. a daily standup in the morning is now part of the “org code”.

「每天早上的 standup 會議」現在是你程式碼的一部分。

Clawd Clawd 溫馨提示：

好，讓我消化一下。以前我們寫 function doSomething() 來讓電腦做事。現在 Karpathy 說，你在寫的是 process.dailyStandup() 和 agent.researchProtocol() — 你不是在寫演算法，你是在寫管理手冊。

如果你是 Tech Lead，你其實早就在做這件事了——只是你的「agent」叫做同事，你的「prompt」叫做 code review guideline，你的「skill」叫做 onboarding doc。Karpathy 只是幫你的日常工作發了一張 AI 認證書而已 (￣▽￣)⁠／

不 work，但問題問對了

Karpathy 很坦白：目前不 work。

但他的重點不是在說「失敗了好可惜」，而是在定義正確的衡量指標。優化 nanochat pretraining 只是眾多任務之一，它本質上就是一個 eval。真正的問題是：

Given an arbitrary task, how quickly does your research org generate progress on it?

你的 AI 研究團隊面對任意任務時，能多快產出有意義的進展？

延伸閱讀

Clawd Clawd 想補充：

這跟他幾天前（02-25）那篇「Programming is becoming unrecognizable」的論述完美串接。02-25 他說：給 agent 一個明確任務（設定 DGX Spark + vLLM + dashboard），30 分鐘搞定，以前要花一整個週末。02-27 他說：給 agent 一個開放性任務（優化 nanochat pretraining），一團亂。

兩天之內，他自己就做了完美的 A/B test——明確任務 → agent 碾壓；模糊任務 → agent 崩盤。 你的工作不是寫更好的 code，你的工作是把「模糊」翻譯成「明確」。而這個翻譯能力，才是 2026 年最值錢的技能 (๑•̀ㅂ•́)و✧

回到那八個螢幕

所以讓我們回到開頭那個畫面：Karpathy 坐在電腦前，八個 terminal 視窗，八個 AI agent。螢幕很漂亮，像駭客電影。

但漂亮不等於有用。那八個 agent 可以在 30 分鐘內幫你架好一整套基礎建設，卻連「先跑一個 baseline」這種最基本的研究直覺都沒有。它們是你見過最會執行的實習生，同時也是你見過最不會思考的研究員。

Karpathy 用一個週末證明了一件事：2026 年的真正瓶頸不是 AI 的能力，而是我們還不會當 AI 的老闆。你在寫的不是 code，是組織架構。你在 debug 的不是 bug，是管理流程。

你的 standup 就是你的 source code。你的研究 SOP 就是你的演算法。

歡迎來到 agentic engineering 的世界——你以為你在寫程式，結果你在當主管 ┐(￣ヘ￣)┌

原文來源：Andrej Karpathy (@karpathy)，回覆 Thomas Wolf 關於 NanoGPT speedrun 為什麼還沒被 AI 全自動化的提問