Karpathy最新腦洞「細菌編程」：優秀的代碼應該具備細菌的三大特質

西風 2025-07-07 12:21:02 來源：量子位

西風 發自 凹非寺

量子位 | 公眾號 QbitAI

像細菌一樣編寫代碼！

創造出“氛圍編程”、“軟件3.0”的大神Karpathy又拋出一個新概念，引起網友廣泛討論——

細菌編程（Bacterial code），要有三個特點：代碼塊小而精、模塊化、自包含且易于復制粘貼。

如此一來，開源社區就能通過“水平基因轉移”蓬勃發展。

網友們就Karpathy提出的這個新概念進行了廣泛討論。

甚至有網友認為這則推文是他“近十年來看到過的最有趣的帖子”。

還有網友好奇Karpathy的腦洞：

老天奶，這些知識是怎么融入你的知識體系的。

More gists, less gits.

Karpathy的新理念，源于對生物演化生存策略的深刻洞察。

他覺得，若想打造一個充滿活力、能快速迭代的開源社區，開發者不妨向地球上最具生存智慧的生命形式細菌學習。

這些微觀世界的“生存大師”歷經億萬年物競天擇，早已將適者生存的法則刻進了基因深處。

不管是極寒、酷熱，還是強酸、強堿，乃至太空環境，細菌幾乎能殖民地球上所有的生態位，靠的正是其基因組（即“代碼”）那套厲害的演化邏輯。

Karpathy把這套演化邏輯提煉成三條法則，還映射到軟件開發實踐里：

• 小（每行代碼都消耗能量）

生物學里，復制、維護每個DNA堿基對都得消耗能量。這種“成本約束”，讓細菌基因組天然自帶“自我精簡機制”。

Karpathy覺得，軟件開發也該有這意識。寫代碼太容易、成本太低，大家隨手就加依賴，最后代碼臃腫不堪，又脆弱又混亂。

• 模塊化（組織成可互換的操縱子組）

細菌的基因，會組織成叫“操縱子（Operon）”的功能簇。這些模塊能整體被激活、抑制或轉移，實現功能的 “即插即用”。

在編程中，這對應于高內聚、低耦合的模塊化設計。每個類或模塊都應像一個獨立的“操縱子”，可以被輕松地替換或與其它模塊組合，而不會引發連鎖反應。

• 自包含（通過水平基因轉移輕松“復制粘貼”）

咋理解？細菌演化出了“水平基因轉移”（Horizontal Gene Transfer）的強大能力，可以直接從其它細菌那里“復制粘貼”有用的基因片段（如抗生素抗性基因），而無需理解對方完整的基因組上下文。

對應到軟件開發中，也就是說代碼片段應是自包含的，不依賴于項目特定的復雜配置、全局狀態或大量的外部庫。

更通俗一點，如何判斷軟件代碼是否符合“細菌編程”標準？

就此，Karpathy提出了兩個問題：

對于你寫的任何一個function（基因）或class（操縱子），你能想象有人在不了解你項目其余代碼、也無需導入任何新依賴的情況下，直接“順手牽羊”（yoink）地拿走它，并立即從中獲益嗎？你的這段代碼，有沒有潛力成為一個熱門的GitHub Gist？

用一句話總結：More gists, less gits.

當然，“細菌編程”并非萬能靈藥。它雖然擅長快速原型設計，但無法構建復雜生命。

Karpathy表示，相比之下，真核生物基因組是更大、更復雜、組織更緊密的monorepo，創新性明顯較低，卻是構建完整器官和協調生命活動的必要條件。

憑借智能設計的優勢，應該可以兼取兩者之長：

必要時構建真核生物monorepo骨架，但最大化保留“細菌 DNA”的特性。

那些由Karpathy提出的大火概念

作為前特斯拉AI總監和OpenAI創始成員，Andrej Karpathy在AI和軟件開發領域具有重要影響力。

在提出“細菌編程”之前，還有多個概念被他提出并帶火，包括：

軟件3.0（Software 3.0）

軟件3.0，即用自然語言編程大模型的新時代，這個概念Karpathy在上個月剛剛提出。

他表示，軟件在過去70年基本沒怎么變過，但最近幾年卻連續經歷了兩次根本性變革。

• 軟件1.0：代碼，就是我們熟悉的傳統編程，程序員敲代碼指揮計算機通過指令執行任務。
• 軟件2.0：權重參數，神經網絡時代不再直接寫代碼，而是調整數據集，讓優化器生成神經網絡的權重參數。

他認為，當初很多人覺得神經網絡就是個分類器，跟決策樹差不多，真正的巨變發生在大模型出現后。

以前的神經網絡都是固定功能的機器，比如AlexNet只能做圖像識別。但大模型不一樣，它們是可編程的！你的提示詞（prompt）就是程序，而且還是用英語（或其他自然語言）寫的。

由此，我們現在進入了用自然語言編程大模型的軟件3.0新時代。

站在軟件3.0的起點，Karpathy對想要進入科技行業的人分享了自己的看法：

我們需要重寫海量的代碼，專業程序員要寫，vibe coder也要寫。在接下來的十年里，我們會把自主性滑塊從左邊推到右邊。

短期來看，大量軟件需重構為 “人類+大模型” 協同模式，半自主應用爆發。

中期來看，大模型逐步滲透企業級工作流，代碼、文檔、數據分析全面智能化。

長期來看，類似《鋼鐵俠》賈維斯的智能助手普及，自主權滑動條從左到右延伸，但人類始終是閉環中的決策者。

這是一個需要同時掌握 Software 1.0（代碼）、2.0（模型訓練）、3.0（提示詞工程）的時代。

氛圍編程（Vibe coding）

Vibe coding，是另一個由Karpathy提出的流行詞，核心是既然大模型能理解英語，那每個會說話的人都能編程。

Karpathy稱自己發了推特15年，也猜不到究竟哪條會火，以為隨便聊聊Vibe coding這個自己想出來的新詞不會有太多人關注，結果這個詞現在火到連維基百科頁面都有詞條了。

Karpathy自己嘗試了Vibe coding，雖然不會Swift，但一天就做出了iOS應用。還做了個叫Menu Genie的餐廳菜單圖片生成器。

不過他發現寫代碼反而是容易的部分，真正困難的是部署——認證、支付、域名配置這些都要在瀏覽器里點來點去。“計算機在告訴我該點哪里，這太荒謬了，為什么不是它自己去點？”

由此，Karpathy認為：需要為AI agent重建基礎設施。

現在的軟件都是為人類設計的，到處都是“點擊這里”的指令，大模型看不懂。一些先驅如Vercel和Stripe已經開始提供大模型友好的文檔，用Markdown格式，把所有“點擊”替換成了curl命令。

這就像給網站加robots.txt一樣，Karpathy建議加個LLM.txt，直接告訴AI這個網站是干什么的。

另外，還有一個新詞，雖然不是Karpathy率先提出的，但得到了他的力挺，這個詞就是前幾天大火的——上下文工程（Context Engineering）。

Karpathy表示，很多人覺得提示詞就是日常用大模型時輸入的簡短指令，但在所有工業級LLM應用中，“上下文工程”完全是另一門藝術與科學，它得精準把控上下文窗口里的信息填充。

說它是“科學”，是因為要做好這件事需要整合任務說明、示例演示、檢索增強生成（RAG）、相關多模態數據、工具調用、狀態記錄和歷史對話等要素，還要通過壓縮技術優化內容。

信息太少或形式不當，LLM 就缺乏足夠的上下文來發揮最佳性能；信息過多或無關，則會推高調用成本并降低效果，要做到恰到好處絕非易事。

說它是“藝術”，則因為這需要對LLM的“行為邏輯”有直覺性的把握，如同理解人類思維的規律。

除了上下文工程本身，Karpathy表示，一個LLM應用還需要：

• 合理將問題拆解為可控的工作流
• 精準填充上下文窗口
• 調用匹配任務需求的LLM模型
• 處理生成-驗證的用戶交互流程
• 更多細節：安全防護、效果評估、并行處理、預加載機制等

總之，AI的進化速度已經遠超預期，而Karpathy的這些腦洞，或許正是未來編程范式的早期信號。

參考鏈接：
[1]https://x.com/karpathy/status/1941616674094170287
[2]https://x.com/karpathy/status/1937902205765607626