一條Karpathy推文引發(fā)的開發(fā)者九級地震

2025年12月27日，Andrej Karpathy在推特上發(fā)了一條長推文。

這不是普通的技術(shù)分享，而是一次公開的自我審視——這位前特斯拉Autopilot負責(zé)人、OpenAI創(chuàng)始團隊成員、無數(shù)開發(fā)者心中的技術(shù)偶像，坦言自己"從未如此強烈地感到落后"。

更關(guān)鍵的是，他說自己"能變得強大10倍"，只要能正確串聯(lián)起過去一年出現(xiàn)的工具。而無法做到這一點，"感覺就像是技能問題"。

這條推文迅速在技術(shù)圈炸開。轉(zhuǎn)發(fā)過萬，點贊數(shù)萬。因為它戳中了一個所有開發(fā)者都能感受到，但很少有人能清晰表達的現(xiàn)實：

軟件工程這個職業(yè)，正在被一場"9級地震"徹底重塑。

兩周后，知名技術(shù)YouTuber Theo（t3.gg創(chuàng)始人、Ping Labs CEO）制作了一期視頻回應(yīng)這條推文。視頻標題直白得有些殘酷："You're falling behind. It's time to catch up."（你正在落后，是時候追上了）

Theo的核心觀點很清晰：Karpathy的感受不是個例，而是整個行業(yè)正在經(jīng)歷的集體轉(zhuǎn)型。那些還在觀望的人，已經(jīng)"正式遲到"了。

本文完整編譯Theo的這期視頻，結(jié)合Karpathy推文的核心洞察，為你拆解這場正在發(fā)生的革命，以及如何在這場變革中不被淘汰。

原文鏈接：https://www.youtube.com/watch?v=Z9UxjmNF7b0&t=152s

1

永久拐點：游戲規(guī)則已經(jīng)改寫

Theo的核心論斷簡潔有力：軟件工程領(lǐng)域已經(jīng)到達了一個永久性的拐點（permanent inflection point）。

這不是又一次技術(shù)迭代，不是從jQuery到React那種級別的變化，而是更根本的東西——開發(fā)者這個職業(yè)本身正在被重新定義。

他用了一個精準的比喻：這是一場“9級地震”。不是余震，不是小打小鬧，而是能夠改變地貌的那種巨震。

AI不再是"助手"，而是"伙伴"

過去幾年，我們見證了各種AI編程工具的誕生：GitHub Copilot、Tabnine、Codeium……但在Theo看來，那些工具本質(zhì)上還是"智能補全"——它們能幫你寫完一行代碼，但你還是那個真正在編程的人。

但現(xiàn)在不一樣了。

Theo透露了一個讓很多人震驚的數(shù)據(jù)：在他自己的工作中，以及他運營和顧問的多個團隊里，現(xiàn)在70%到90%的代碼是AI生成的。

不是輔助生成，不是參考生成，而是直接生成。

對比一下時間線：

• 2023年：AI能幫你寫函數(shù)，你需要檢查和修改

• 2024年：AI能幫你寫模塊，你需要整合和調(diào)試

• 2026年：AI能幫你寫整個功能，你需要審查和優(yōu)化

這個趨勢的終點在哪里？Theo認為，可能根本沒有終點，只有持續(xù)的加速。

"等等看"的窗口期已經(jīng)關(guān)閉

Theo引用了一句很有意思的話：“寧愿遲到也不要太早……但我們現(xiàn)在已經(jīng)過了那個時間點。”

在2023到2024年，持觀望態(tài)度是合理的。那時候工具不成熟，成本高昂，可靠性存疑。很多開發(fā)者會說：“讓子彈飛一會兒，看看這東西到底行不行。”

但到了2026年，這個態(tài)度已經(jīng)變成了負擔(dān)。

基礎(chǔ)模型的能力已經(jīng)達到生產(chǎn)級別，推理成本每8周減半，工具生態(tài)已經(jīng)成熟到可以直接上手的程度。Cursor、Claude Code、Windsurf這些工具已經(jīng)不是"試驗品"，而是生產(chǎn)力工具。

Theo的判斷很直接：現(xiàn)在開始適應(yīng)AI的人，已經(jīng)是"officially late"（正式遲到）了。再等下去，就不是遲到的問題，而是會缺席整場比賽。

你的角色正在被"重構(gòu)"

傳統(tǒng)的開發(fā)流程是線性的：需求→設(shè)計→編碼→測試→部署。開發(fā)者的核心價值在"編碼"那一環(huán)——你能多快、多準確地把邏輯轉(zhuǎn)化為代碼。

但現(xiàn)在，這個流程正在被解構(gòu)重組。

Theo用了一個編程術(shù)語來形容這種變化：“The role of the programmer is being dramatically refactored.”（程序員的角色正在被徹底重構(gòu)。）

重構(gòu)后的角色是什么？不再是"手寫代碼的工匠"，而是"編排AI Agent的指揮家"。

你需要掌握的不再是語法細節(jié)、算法實現(xiàn)、框架特性，而是：

• Agents（智能體）：如何設(shè)計和使用AI代理

• Sub-agents（子智能體）：如何拆解任務(wù)給不同的AI

• Contexts（上下文管理）：如何給AI提供恰當(dāng)?shù)男畔?/p>

• Memory（記憶機制）：如何讓AI記住項目的歷史和決策

• Workflows（工作流）：如何編排AI的協(xié)作流程

• MCP、LSP：新的協(xié)議和接口標準

這是一個全新的可編程抽象層。就像從匯編到高級語言是一次抽象層的躍遷，現(xiàn)在我們正在經(jīng)歷從"手寫代碼"到"編排AI"的又一次躍遷。

1

來自真實世界的證據(jù)：Ramp的Inspect Bot

理論說得再多，不如一個真實的案例來得有說服力。Theo在視頻中重點介紹了Ramp公司（一家金融科技獨角獸）的內(nèi)部工具：Inspect Bot。

這個工具的工作流程簡單到有些"可怕"：

1. 自動監(jiān)控：連接到Sentry（錯誤監(jiān)控平臺），實時掃描生產(chǎn)環(huán)境的錯誤

2. 智能篩選：自動識別出最常見的Top 20錯誤

3. 自動修復(fù)：為每個錯誤啟動一個"子會話"（child session），也就是一個獨立的AI Agent

4. 代碼提交：AI自主編寫修復(fù)代碼，并提交Pull Request

5. 人工審核：工程師只需要審查PR，決定是否合并

整個流程中，人類只出現(xiàn)在最后一步。

對比一下傳統(tǒng)的bug修復(fù)流程：

• 傳統(tǒng)：發(fā)現(xiàn)bug → 分配給工程師 → 排查問題 → 編寫修復(fù) → 測試 → 提交 → 審核 → 部署（耗時數(shù)小時到數(shù)天）

• AI流程：發(fā)現(xiàn)bug → AI自動修復(fù) → 人工審核 → 部署（耗時數(shù)分鐘）

工程師的角色從"修bug的人"變成了"審核修復(fù)方案的人"。

agent.md：你和AI之間的"圣經(jīng)"

Ramp的工程副總裁Rahul和工程師Nicolas Bevacqua還分享了另一個關(guān)鍵策略：維護agent.md或claude.md文件。

這個策略的核心思想很簡單：每當(dāng)你需要手動修改AI生成的代碼時，不要只是改完就算了，而是要：

1. 記錄這次修改的原因

2. 提煉成通用規(guī)則

3. 更新到agent.md文件中

4. 讓AI在未來自動遵循這個規(guī)則

Rahul的團隊報告說，他們每天會多次更新這些文檔。結(jié)果是，AI的輸出質(zhì)量持續(xù)提升，需要人工干預(yù)的情況越來越少。

Theo對此的評價一針見血：“Every manual edit you make is an opportunity for agent.md improvement.”（你做的每一次手動編輯，都是改進agent.md的機會。）

這就像是在訓(xùn)練一個學(xué)徒，但這個學(xué)徒的學(xué)習(xí)速度是人類的百倍千倍。

1

定制微調(diào)已死，長live提示工程

Theo在視頻中宣告了一件很多人可能還沒意識到的事：定制微調(diào)（custom fine-tuning）已經(jīng)過時了。

這個判斷乍一聽很反直覺。過去幾年，微調(diào)一直被視為讓AI適應(yīng)特定任務(wù)的最佳方式。但Theo給出了三個理由：

第一，基礎(chǔ)模型進化太快了。微調(diào)一個模型需要8周時間，但基礎(chǔ)模型每8周就有重大升級。等你的微調(diào)版本訓(xùn)練好，新的基礎(chǔ)模型已經(jīng)出來了，而且往往比你的微調(diào)版本還要強。這就像你花三個月造了一輛自行車，結(jié)果市面上已經(jīng)開始賣汽車了。

第二，推理成本暴降。2024到2026年，推理成本每8周減半。微調(diào)的主要價值之一就是"提高效率降低成本"，但當(dāng)基礎(chǔ)模型的成本已經(jīng)低到可以忽略時，微調(diào)的性價比就消失了。

第三，通用模型更強。Claude 4.5、GPT-4o這些最新的通用模型，在大多數(shù)場景下已經(jīng)超過了定制微調(diào)的模型。除非你的場景極其特殊，否則通用模型+好的提示詞，效果會更好。

那新的策略是什么？Prompt優(yōu)化 + Agent Docs + 工作流編排。這個組合的迭代周期不是"周級"而是"小時級"，你可以快速試錯、快速調(diào)整、快速改進。

1

“滑板手視角”：重新看待每一個重復(fù)任務(wù)

Theo在視頻中用了一個絕妙的類比：滑板手看世界的方式。

普通人看到樓梯和扶手，會想：“這是障礙，得小心繞過去。”

滑板手看到樓梯和扶手，會想：“這是機會，可以滑一段。”

AI時代的開發(fā)者也應(yīng)該有這種視角轉(zhuǎn)換。當(dāng)你看到一個重復(fù)性任務(wù)時，不應(yīng)該想"這很煩"，而應(yīng)該想"這是自動化的機會"。

Slop Code的新價值

過去，有很多小任務(wù)我們會直接忽略：

• 批量重命名文件

• 生成測試數(shù)據(jù)

• 寫一次性的數(shù)據(jù)遷移腳本

• 自動化某個手動操作

原因很簡單：寫這個腳本可能要30分鐘，但手動做只要10分鐘，不劃算。

但在AI時代，這個計算徹底改變了。讓AI寫這個腳本只需要2分鐘，而且這個腳本以后可以復(fù)用、可以改進、可以分享給團隊其他人。

Theo把這類代碼叫做"slop code"（馬虎代碼），但這個詞不是貶義，而是指那些過去因為投入產(chǎn)出比不劃算而不會被寫出來的代碼。AI降低了創(chuàng)建成本，讓這些"邊際項目"變得可行。

他自己就用AI構(gòu)建了一個1萬行代碼的資產(chǎn)管理工具，只是為了支持一個小型游戲項目。在傳統(tǒng)世界里，這種"投入產(chǎn)出比不劃算"的工具根本不會存在。

啟示很明確：不要再用"手寫代碼的成本"去評估是否做某件事，而要用"Prompt的成本"去評估。這會打開無數(shù)新的可能性。

1

五步追趕指南：從"遲到"到"跟上"

理論講完了，Theo給出了非常具體的行動指南。他把這個過程拆解成五個遞進的步驟。

Step 0：立即接入AI代碼審查

第一步是最簡單、風(fēng)險最低的：在你的代碼庫中接入AI驅(qū)動的代碼審查工具。

推薦的工具包括Graptile和CodeRabbit。這些工具會在PR階段自動檢查代碼質(zhì)量、發(fā)現(xiàn)潛在bug、提出優(yōu)化建議、標注安全隱患。

為什么是Step 0？因為這一步零成本、零風(fēng)險、立竿見影。你不需要改變?nèi)魏喂ぷ髁鞒蹋恍枰贑I/CD流程里加一個步驟。效果是，在人類審查之前，AI已經(jīng)幫你過濾掉了90%的低級錯誤。

Step 1：測試AI的極限

第二步是建立直覺：找一個你過去花了一周時間完成的任務(wù)，嘗試用AI在幾分鐘內(nèi)完成。

不要期待AI完美完成，重點是建立對AI能力邊界的直覺。只有知道邊界在哪里，你才能有效地編排它。

Theo的建議很直接：“If you’re not at least a little bit uncomfortable, you are not trying hard enough.”（如果你沒有感到哪怕一點點不適，說明你還不夠努力。）

Step 2：學(xué)會閱讀AI的思考過程

第三步是理解AI：使用"Plan Mode"（規(guī)劃模式）觀察AI如何推理。

大多數(shù)AI編程工具都有這個功能，AI會先分析代碼庫結(jié)構(gòu)、制定實現(xiàn)計劃、拆解成子任務(wù)、然后逐步執(zhí)行。

看這個過程的目的不是學(xué)習(xí)具體技巧，而是理解AI如何看待代碼、如何組織邏輯、在哪里會卡住。這就像看棋手復(fù)盤，你不僅要知道結(jié)果，還要理解每一步的考量。

Step 3：建立agent.md體系

第四步是積累經(jīng)驗：在你的代碼庫中創(chuàng)建并維護agent.md或claude.md文件。

這個文件記錄了所有項目特定的規(guī)則、常見模式、已知問題、最佳實踐。每次你手動修改AI代碼時，就往這個文件里加一條規(guī)則。

效果是指數(shù)級的：

• 第一周：AI準確率從60%提升到75%

• 第一個月：AI準確率提升到85%

• 三個月后：AI準確率接近95%

你的工作從"寫代碼"逐漸變成了"提需求"。

Step 4：學(xué)會編排多個Agent

最后一步是終極目標：讓多個AI Agent協(xié)同工作，像交響樂團一樣。

這涉及到Sub-agents（不同Agent負責(zé)不同任務(wù)）、Context管理（給每個Agent提供恰當(dāng)?shù)男畔ⅲemory機制（讓Agent記住歷史）、Workflow編排（定義協(xié)作流程）。

Theo的評價是：“焦點已經(jīng)從’程序員貢獻的代碼位’轉(zhuǎn)移到了更高層次的編排：智能體、子智能體、上下文、記憶和工作流。”

這是一個全新的技能樹，而且這個技能樹還在快速生長。

1

給管理者的嚴重警告

Theo在視頻中專門用了一段時間，直接對話技術(shù)管理者和CTO們。語氣罕見地嚴肅。

他的核心警告是：不要強制員工使用落后的模型。

很多公司出于"成本控制"或"數(shù)據(jù)安全"的考慮，要求工程師使用公司內(nèi)部微調(diào)的老模型，或者限制使用Claude Opus、GPT-4o等最新模型。

Theo的判斷很直接：“Forcing them to use older or inferior internal models will lead to top talent leaving.”（強制他們使用舊的或劣質(zhì)的內(nèi)部模型，會導(dǎo)致頂尖人才離職。）

原因很簡單：優(yōu)秀的工程師會意識到，在這家公司，自己的生產(chǎn)力被人為限制了，技能增長速度比市場慢了，正在用落后的工具做落后的事。結(jié)果就是人才流失，競爭力下降，形成負向循環(huán)。

他還駁斥了一個常見的成本計算謬誤。很多管理者會說：“Claude Opus每百萬token要$15，我們自己的模型只要$0.5，必須省錢。”

但真實的計算是：一個高級工程師的時薪是$100-200，如果用劣質(zhì)模型，工程師需要修改50%的AI輸出；用最佳模型，工程師只需要修改5%。哪個更省錢？

答案顯而易見。推理成本每8周減半，工程師工資每年漲10%。這筆賬怎么算都是工具成本可以忽略。

1

尾聲：地震正在發(fā)生

Andrej Karpathy說他"從未如此強烈地感到落后"，這聽起來像是壞消息。但換個角度看：如果連站在最前沿的人都在全力奔跑，那說明這個領(lǐng)域還遠未定型。

機會還在，但窗口正在快速關(guān)閉。

就像Theo所說的，現(xiàn)在行動的人已經(jīng)"正式遲到"了，但遲到總比缺席好。真正危險的不是現(xiàn)在開始，而是繼續(xù)觀望。

2026年，軟件工程的規(guī)則已經(jīng)改寫。問題不再是"AI能否取代程序員"，而是“會用AI的程序員將取代不會用AI的程序員”。

點個“愛心”，再走 吧