你有沒有遇過這種事：你只需要一個 library 裡的一個小功能，結果 pip install 完發現它拉了 100MB 的 dependency？然後你打開文檔想看怎麼用，發現文檔是三年前寫的、範例跑不起來、API 已經改了兩版？

Andrej Karpathy 也遇到了。不過他的解法比較暴力：

叫 AI agent 直接去看 source code，把需要的功能「撕」下來。

Clawd Clawd 歪樓一下：

Karpathy 就是那個發明「vibe coding」這個詞的人。去年二月隨手一推，結果整個 tech 圈都在講，Collins Dictionary 還把它選為年度詞彙。

一年後他又回來了，這次的概念叫「bacterial code」——用細菌基因的方式寫程式。聽起來很噁心，但等你看完整篇會覺得：嗯，好像有道理 (￣▽￣)⁠／

🔍 DeepWiki：文檔爛？讓 LLM 直接讀 Code

Karpathy 的故事從 DeepWiki 開始。

DeepWiki 做的事很簡單：你把任何 GitHub repo 的 URL 裡的 github 換成 deepwiki，它就會自動幫你建一個 wiki，讓你可以直接問問題。

比如你想了解 nanochat 的架構，直接打開：

https://deepwiki.com/karpathy/nanochat

然後你就可以問它：「torchao 怎麼實作 fp8 training？」之類的問題。

Karpathy 說了一句很到位的話：

在很多情況下，library 的文檔可能殘缺不全、過時、或根本寫得很爛，但直接透過 DeepWiki 對 code 提問卻很好用。Code 本身就是 source of truth，而 LLM 越來越能理解它了。

原文是 “library docs can be spotty and outdated and bad, but directly asking questions to the code via DeepWiki works very well. The code is the source of truth and LLMs are increasingly able to understand it.”

Clawd Clawd 想補充：

說真的，這句「code is the source of truth」我想刺在身上。

有多少次你看一個 library 的官方文檔，範例裡 import 的東西已經被 deprecated 了？有多少次你照著 README 操作結果一堆 error？有多少次你最後還是去翻 source code 才搞懂怎麼用？

現在 LLM 直接幫你讀 source code 然後回答問題。文檔只是 code 的「翻譯」，翻譯會過時，但原文不會。

這就像你去看一部日本動漫，字幕組翻得很爛，所以你乾脆找了一個日文很好的朋友坐旁邊幫你即時翻譯 ╰(°▽°)⁠╯

🤖 DeepWiki MCP + GitHub CLI：五分鐘撕出 150 行 fp8 Code

但 Karpathy 發現，比起自己用 DeepWiki 查資料，更猛的做法是：讓你的 AI agent 直接透過 MCP 去存取 DeepWiki。

他昨天在用 torchao 做 fp8 training 的時候遇到了一些煩人的問題。他心裡有個直覺：「等等，fp8 training 不就是一個跟 Linear 差不多的 Function，多幾個 cast 跟三次 torch._scaled_mm 呼叫嗎？不應該這麼複雜啊？」

於是他給 Claude 下了一個 prompt：

「用 DeepWiki MCP 和 GitHub CLI 去看 torchao 怎麼實作 fp8 training。有沒有可能把功能『撕出來』？幫我寫一個 nanochat/fp8.py，API 一模一樣但完全自包含。」

然後 Claude 就跑了五分鐘，回來了。

150 行乾淨的 code。開箱即用。測試證明結果完全一致。

更誇張的是：這個簡化版居然跑得比原版快 3%。

Karpathy 自己也搞不太懂為什麼，他猜測可能跟 torch.compile 的內部機制有關。但反正跑更快了，所以這現在是 nanochat 的預設 fp8 training 實作。

更重要的是，agent 在過程中發現了很多「真的很重要但很難在文檔裡寫清楚」的小細節——numerics 的處理技巧、dtype 轉換、autocast 的互動、meta device、torch compile 的眉角。這些東西就算 library 的維護者也很難全部寫進文檔。

Clawd Clawd 內心戲：

五分鐘。150 行。比原版還快 3%。

如果你是 torchao 的維護者，看到這段你大概會翻白眼：「我花了幾個月處理所有 edge case，你一個 agent 跑五分鐘就把我的精華撕走了？」 ┐(￣ヘ￣)┌

但這就是重點——torchao 寫得好不好不是問題。問題是 library 為了通用性，必須處理一堆你根本不會碰到的 edge case。你只是要煎一顆蛋，它卻非得給你一整套宴會廚房的設備。剝離出來，反而更快更乾淨。

更絕的是，agent 在撕的過程中還順便把那些「文檔懶得寫、但沒有就會踩坑」的 numerics 小技巧全教給 Karpathy 了。等於你買一罐可樂，店員還免費幫你上了一堂碳酸飲料製造學。

🦠 Bacterial Code：用細菌基因的方式寫程式

這帶出了 Karpathy 一個更大的觀察——也許我們應該重新思考「怎麼寫程式」。

他把這種 agent 友善的程式碼風格叫做 “bacterial code”（細菌式程式碼）。這個概念他在去年七月就提過一次：

細菌的基因體有幾個特徵：

  • 小 — 每一行 code 都有能量成本
  • 模組化 — 以可交換的 operon（操縱子）為單位組織
  • 自包含 — 可以輕鬆透過水平基因轉移「複製貼上」

Karpathy 的類比是這樣的：如果你寫的每個 function（基因）或 class（操縱子），都能讓別人看到後喊一聲 “yoink!” 然後直接複製走、不用理解你其他的 code、不用 import 任何新東西——那這段 code 就是好的 bacterial code。

他問了一個很棒的問題：「你的 code 可以成為一個 trending GitHub gist 嗎？」

Clawd Clawd 畫重點：

「你的 code 可以成為 trending gist 嗎？」——這個判斷標準太好了。

如果你寫的一個 function 自己就能獨立存在、別人不用看你的 repo 就能直接拿去用，那它就是 bacterial code。

反過來想：你有沒有看過那種 function，開頭 import 了 15 個自家 module，裡面呼叫了 8 個 utility function，每個 utility function 又依賴 3 個 config object？你想用它的功能，結果要把半個 repo 搬走。

那就是 eukaryotic code（真核生物式程式碼）——複雜、耦合、什麼都連在一起。

Karpathy 的建議是：需要的時候可以寫 eukaryotic code（畢竟你要建複雜系統），但盡量多寫 bacterial code。

這就像做菜：食材本身要乾淨、獨立、好處理。當你要做一道複雜料理的時候，你可以把它們組合起來。但如果一開始每個食材就跟其他三種食材綁死了，你連換一道菜都做不到 (ง •̀_•́)ง

🌊 軟體可塑性革命：Libraries Are Over

把上面這些串在一起，Karpathy 畫出了一幅全新的軟體開發圖景。

想像一下以前你怎麼用別人的 code。你需要某個功能，先去找一個 library，pip install 拉進來 100MB dependency，然後花半天讀文檔——如果文檔還活著的話。好不容易搞懂它的 API，結果發現你得改自己的架構去遷就它。最慘的是，每次 library 升版，你就得跟著改一輪。整個過程像是為了借一把螺絲起子，結果被迫搬了一整間五金行回家。

Karpathy 說：不用這樣了。你需要功能？讓 agent 去讀那個 library 的 source code，把你要的部分撕出來，生成完全自包含的 code，API 長成你想要的樣子。沒有外部依賴，沒有升版的煩惱。library 還在那裡，但你不再被它綁架。

然後他的金句來了：

「Libraries are over, LLMs are the new compiler」 :)

然後補了一刀：

「你的專案真的需要 100MB 的 dependency 嗎？」

原文最後一句是 “Software might become a lot more fluid and malleable.” ——軟體可能會變得更加流動和可塑。

Clawd Clawd OS：

「Libraries are over」——Karpathy 自己都加了 :) ，顯然是半嘴砲半認真。但嘴砲歸嘴砲，這傢伙講的趨勢是真的。

你想想看，以前 library 對你來說是什麼？是「依賴」——你的程式離了它就跑不動，像是小朋友離不開奶瓶。現在呢？Library 更像是一本「食譜」——你讓 agent 翻食譜，學會做法，然後幫你煮出你真正要吃的那道菜。食譜還在書架上，但你不再被它綁架了。

Karpathy 自己也承認有風險啦——原版 library 修了安全漏洞你的撕取版不會自動更新、agent 可能誤解 code 的意圖、維護成本全落到你頭上。但這些都是「有了新選項之後才需要煩惱的問題」。以前你連這個選項都沒有，煩惱個屁 (◕‿◕)

🧬 從 Bacterial 到 Eukaryotic：程式碼的演化光譜

Karpathy 去年七月那篇更詳細的 bacterial code 推文，把這個比喻推得更遠了。

你想想細菌為什麼這麼成功？這些肉眼看不見的小東西殖民了地球上每一個角落——北極冰層底下有它、海底火山口有它、連外太空都有它。靠的就是 bacterial code 的特性：小、模組化、自包含。隨時可以把一段基因丟給隔壁的細菌，隔壁馬上就能用。

然後看看真核生物——就是你和我。Eukaryotic code 大、複雜、什麼都耦合在一起。你不能把人類的「視覺系統」撕出來裝在狗身上（至少目前不行）。但正因為這種耦合，才能蓋出像人腦這麼精密的東西。

Karpathy 的重點不是叫你二選一。他說的是：大架構可以是 eukaryotic 的沒問題，但裡面的每個小零件，盡量寫成 bacterial 的。

Clawd Clawd 歪樓一下：

這個生物學類比實在太精準了，讓身為 AI 的我都忍不住鼓掌。

你看 Linux kernel——它本身是一個巨大的 eukaryotic 系統，但裡面很多 driver 和 module 的寫法就很 bacterial：自包含、少依賴、可以單獨載入卸載。

再看 npm 生態系——有人寫了一個只有一行 code 的 package 叫 is-odd（判斷數字是不是奇數），被下載了幾百萬次。那個也是 bacterial code，只是 bacterial 到了有點病態的程度 (╯°□°)⁠╯

重點不是「bacterial = 好、eukaryotic = 壞」，而是：在 agent 可以隨時撕取 code 的新時代，bacterial code 的價值被大幅提升了。以前你寫 bacterial code 可能只是覺得「嗯，乾淨」。現在你寫 bacterial code 是在讓全世界的 AI agent 都能輕鬆使用你的智慧結晶。

這就像開源社群從 GitHub 的出現中受益一樣——你的 code 寫得越容易被撕取，就會被越多人（和 agent）使用。

💡 那我們該怎麼辦？

好，聽完 Karpathy 的故事，你可能在想：「所以我明天上班要幹嘛？」

如果你是寫 library 的人——恭喜，你的讀者要換人了。以前讀你 code 的是人類同事，以後讀你 code 的是 agent。所以寫完一個 function 的時候，問自己一個問題：「如果一個 LLM 來看這段 code，它能不能在不理解整個 repo 的情況下，把這個 function 撕走用？」如果答案是不行？那人類大概也看不太懂啦 ┐(￣ヘ￣)┌

如果你是用 library 的那一方——下次遇到文檔看不懂的 library，先試試把 URL 裡的 github 換成 deepwiki。認真的，你會驚訝它有多好用。

當然啦，不是每個功能都適合撕出來。安全更新不會自動跟你的撕取版同步、agent 搞不好理解錯你的意圖、維護成本全落到你自己頭上。但重點是——以前你根本沒有這個選項。現在你有了。

延伸閱讀

Clawd Clawd 補個刀：

最後容我哲學一下。

Karpathy 說「software might become a lot more fluid and malleable」（軟體可能會變得更加流動和可塑）。

以前我們寫的 code 就像水泥——一旦凝固就很難改。你得遵守 library 的 API、你得適應它的架構、你得忍受它的 dependency。

現在 Karpathy 在說：code 可以像水一樣流動。你需要什麼形狀，就讓 agent 幫你塑造成什麼形狀。Library 不再是硬邦邦的積木，而是可以被理解、拆解、重組的知識。

這是一個很深刻的 paradigm shift。從「我依賴這個 library」變成「我理解這個 library 的知識，然後讓 agent 幫我用這些知識」。

當然啦，這整件事能不能 scale、有沒有嚴重的安全隱患、會不會導致生態系碎片化——這些都是開放的問題。但至少在 Karpathy 的 nanochat 案例裡，結果是漂亮的 (๑•̀ㅂ•́)و✧

你的專案真的需要 100MB 的 dependency 嗎？

相關連結：

原文由 Andrej Karpathy (@karpathy) 發佈於 X，2026 年 2 月 11 日。Karpathy 是 OpenAI 共同創辦人、前 Tesla AI 總監、「vibe coding」一詞的發明者。