像細(xì)菌一樣編寫代碼！

創(chuàng)造出“氛圍編程”、“軟件3.0”的大神Karpathy又拋出一個(gè)新概念，引起網(wǎng)友廣泛討論——

細(xì)菌編程（Bacterial code），要有三個(gè)特點(diǎn)：代碼塊小而精、模塊化、自包含且易于復(fù)制粘貼。

如此一來(lái)，開(kāi)源社區(qū)就能通過(guò)“水平基因轉(zhuǎn)移”蓬勃發(fā)展。

圖片

網(wǎng)友們就Karpathy提出的這個(gè)新概念進(jìn)行了廣泛討論。

甚至有網(wǎng)友認(rèn)為這則推文是他“近十年來(lái)看到過(guò)的最有趣的帖子”。

圖片

還有網(wǎng)友好奇Karpathy的腦洞：

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

圖片

More gists, less gits.

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

他覺(jué)得，若想打造一個(gè)充滿活力、能快速迭代的開(kāi)源社區(qū)，開(kāi)發(fā)者不妨向地球上最具生存智慧的生命形式細(xì)菌學(xué)習(xí)。

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

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

Karpathy把這套演化邏輯提煉成三條法則，還映射到軟件開(kāi)發(fā)實(shí)踐里：

• ?。啃写a都消耗能量）

生物學(xué)里，復(fù)制、維護(hù)每個(gè)DNA堿基對(duì)都得消耗能量。這種“成本約束”，讓細(xì)菌基因組天然自帶“自我精簡(jiǎn)機(jī)制”。

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

圖片

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

細(xì)菌的基因，會(huì)組織成叫“操縱子（Operon）”的功能簇。這些模塊能整體被激活、抑制或轉(zhuǎn)移，實(shí)現(xiàn)功能的 “即插即用”。

在編程中，這對(duì)應(yīng)于高內(nèi)聚、低耦合的模塊化設(shè)計(jì)。每個(gè)類或模塊都應(yīng)像一個(gè)獨(dú)立的“操縱子”，可以被輕松地替換或與其它模塊組合，而不會(huì)引發(fā)連鎖反應(yīng)。

• 自包含（通過(guò)水平基因轉(zhuǎn)移輕松“復(fù)制粘貼”）

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

對(duì)應(yīng)到軟件開(kāi)發(fā)中，也就是說(shuō)代碼片段應(yīng)是自包含的，不依賴于項(xiàng)目特定的復(fù)雜配置、全局狀態(tài)或大量的外部庫(kù)。

更通俗一點(diǎn)，如何判斷軟件代碼是否符合“細(xì)菌編程”標(biāo)準(zhǔn)？

就此，Karpathy提出了兩個(gè)問(wèn)題：

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

用一句話總結(jié)：More gists, less gits.

當(dāng)然，“細(xì)菌編程”并非萬(wàn)能靈藥。它雖然擅長(zhǎng)快速原型設(shè)計(jì)，但無(wú)法構(gòu)建復(fù)雜生命。

Karpathy表示，相比之下，真核生物基因組是更大、更復(fù)雜、組織更緊密的monorepo，創(chuàng)新性明顯較低，卻是構(gòu)建完整器官和協(xié)調(diào)生命活動(dòng)的必要條件。

憑借智能設(shè)計(jì)的優(yōu)勢(shì)，應(yīng)該可以兼取兩者之長(zhǎng)：

必要時(shí)構(gòu)建真核生物monorepo骨架，但最大化保留“細(xì)菌 DNA”的特性。

那些由Karpathy提出的大火概念

作為前特斯拉AI總監(jiān)和OpenAI創(chuàng)始成員，Andrej Karpathy在AI和軟件開(kāi)發(fā)領(lǐng)域具有重要影響力。

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

軟件3.0（Software 3.0）

軟件3.0，即用自然語(yǔ)言編程大模型的新時(shí)代，這個(gè)概念Karpathy在上個(gè)月剛剛提出。

他表示，軟件在過(guò)去70年基本沒(méi)怎么變過(guò)，但最近幾年卻連續(xù)經(jīng)歷了兩次根本性變革。

• 軟件1.0：代碼，就是我們熟悉的傳統(tǒng)編程，程序員敲代碼指揮計(jì)算機(jī)通過(guò)指令執(zhí)行任務(wù)。
• 軟件2.0：權(quán)重參數(shù)，神經(jīng)網(wǎng)絡(luò)時(shí)代不再直接寫代碼，而是調(diào)整數(shù)據(jù)集，讓優(yōu)化器生成神經(jīng)網(wǎng)絡(luò)的權(quán)重參數(shù)。

他認(rèn)為，當(dāng)初很多人覺(jué)得神經(jīng)網(wǎng)絡(luò)就是個(gè)分類器，跟決策樹差不多，真正的巨變發(fā)生在大模型出現(xiàn)后。

圖片

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

由此，我們現(xiàn)在進(jìn)入了用自然語(yǔ)言編程大模型的軟件3.0新時(shí)代。

圖片

站在軟件3.0的起點(diǎn)，Karpathy對(duì)想要進(jìn)入科技行業(yè)的人分享了自己的看法：

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

短期來(lái)看，大量軟件需重構(gòu)為 “人類+大模型” 協(xié)同模式，半自主應(yīng)用爆發(fā)。

中期來(lái)看，大模型逐步滲透企業(yè)級(jí)工作流，代碼、文檔、數(shù)據(jù)分析全面智能化。

長(zhǎng)期來(lái)看，類似《鋼鐵俠》賈維斯的智能助手普及，自主權(quán)滑動(dòng)條從左到右延伸，但人類始終是閉環(huán)中的決策者。

這是一個(gè)需要同時(shí)掌握 Software 1.0（代碼）、2.0（模型訓(xùn)練）、3.0（提示詞工程）的時(shí)代。

氛圍編程（Vibe coding）

Vibe coding，是另一個(gè)由Karpathy提出的流行詞，核心是既然大模型能理解英語(yǔ)，那每個(gè)會(huì)說(shuō)話的人都能編程。

Karpathy稱自己發(fā)了推特15年，也猜不到究竟哪條會(huì)火，以為隨便聊聊Vibe coding這個(gè)自己想出來(lái)的新詞不會(huì)有太多人關(guān)注，結(jié)果這個(gè)詞現(xiàn)在火到連維基百科頁(yè)面都有詞條了。

圖片

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

不過(guò)他發(fā)現(xiàn)寫代碼反而是容易的部分，真正困難的是部署——認(rèn)證、支付、域名配置這些都要在瀏覽器里點(diǎn)來(lái)點(diǎn)去?！坝?jì)算機(jī)在告訴我該點(diǎn)哪里，這太荒謬了，為什么不是它自己去點(diǎn)？”

由此，Karpathy認(rèn)為：需要為AI agent重建基礎(chǔ)設(shè)施。

現(xiàn)在的軟件都是為人類設(shè)計(jì)的，到處都是“點(diǎn)擊這里”的指令，大模型看不懂。一些先驅(qū)如Vercel和Stripe已經(jīng)開(kāi)始提供大模型友好的文檔，用Markdown格式，把所有“點(diǎn)擊”替換成了curl命令。

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

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

圖片

Karpathy表示，很多人覺(jué)得提示詞就是日常用大模型時(shí)輸入的簡(jiǎn)短指令，但在所有工業(yè)級(jí)LLM應(yīng)用中，“上下文工程”完全是另一門藝術(shù)與科學(xué)，它得精準(zhǔn)把控上下文窗口里的信息填充。

說(shuō)它是“科學(xué)”，是因?yàn)橐龊眠@件事需要整合任務(wù)說(shuō)明、示例演示、檢索增強(qiáng)生成（RAG）、相關(guān)多模態(tài)數(shù)據(jù)、工具調(diào)用、狀態(tài)記錄和歷史對(duì)話等要素，還要通過(guò)壓縮技術(shù)優(yōu)化內(nèi)容。

信息太少或形式不當(dāng)，LLM 就缺乏足夠的上下文來(lái)發(fā)揮最佳性能；信息過(guò)多或無(wú)關(guān)，則會(huì)推高調(diào)用成本并降低效果，要做到恰到好處絕非易事。

說(shuō)它是“藝術(shù)”，則因?yàn)檫@需要對(duì)LLM的“行為邏輯”有直覺(jué)性的把握，如同理解人類思維的規(guī)律。

除了上下文工程本身，Karpathy表示，一個(gè)LLM應(yīng)用還需要：

• 合理將問(wèn)題拆解為可控的工作流
• 精準(zhǔn)填充上下文窗口
• 調(diào)用匹配任務(wù)需求的LLM模型
• 處理生成-驗(yàn)證的用戶交互流程
• 更多細(xì)節(jié)：安全防護(hù)、效果評(píng)估、并行處理、預(yù)加載機(jī)制等

總之，AI的進(jìn)化速度已經(jīng)遠(yuǎn)超預(yù)期，而Karpathy的這些腦洞，或許正是未來(lái)編程范式的早期信號(hào)。

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