出品 | 51CTO技術棧（微信號：blog51cto）

軟件開發因AI有了根本性轉變？

剛剛，帶火“Vibe Coding”風潮的前 OpenAI 大佬 Andrej Karpathy，在 YC 的演講刷屏出圈！

這是一場足以改變你對編程、對大模型、對未來軟件形態理解的深度分享。

Karpathy 一開場就擲地有聲地說：

 “軟件正在再次發生根本性的變化。”

這句話引爆了 Hacker News 社區熱議——哪怕最初發布的只是一份錯漏百出的轉錄稿，依舊擋不住大家的瘋狂轉發與評論。

圖片

而在 X 上，YC 創始人 Jared 表示：

“這場演講發人深省，讓人對 LLM 有了全新的認識。”

圖片

Karpathy 的核心觀點是：

• 過去 70 年，軟件的底層范式幾乎未變；
• 但短短幾年內，軟件連續發生了兩次結構性巨變；
• AI 正把“寫代碼”這件事，變成“寫提示”、“對話”、“控制 Agent”；
• 英語，正在成為新的“編程語言”。

他說：

 “我們正站在一場軟件重寫的浪潮上，我們有大量的工作要做、大量的軟件要寫，甚至重寫，這將遠超我們想象。”

現在，這場官錄視頻終于新鮮出爐！

圖片

我們為你提煉了這場演講的干貨，圖文并茂，幫你還原Karpathy大神眼中的軟件3.0，從中讀出軟件未來的走向、LLM 背后的操作系統哲學、以及“AI賦能人類”的正確姿勢。

?? 視頻地址：

??https://www.youtube.com/watch?v=LCEmiRjPEtQ??

話不多說，準備迎接 Software 3.0 的世界！

1.“軟件地圖”：Software 1.0 → 2.0 → 3.0

我們可以先看看“軟件世界”的整體形態。假設我們有一張“軟件地圖”，那這張圖展示的是 GitHub 上的全部項目。

 這些項目可以看作是人類寫給計算機的“指令”，告訴它如何在數字世界中執行任務。

你放大地圖，可以看到各種各樣的代碼倉庫——這些就是我們已經寫好的所有代碼。這些代碼是“指令”，告訴計算機怎么在數字世界中完成任務。

我幾年前觀察到，軟件開始向一種新形式演化，我當時給它取名叫 Software 2.0。

• 所謂 Software 1.0，是傳統意義上我們手寫的代碼；
• 而 Software 2.0，指的是神經網絡，準確地說是它們的參數（weights）。我們不再直接寫“代碼”，而是調數據、跑優化器，生成參數。

圖片

當時的神經網絡還只是被看作一種分類器——就像決策樹一類的工具。因此“訓練神經網絡”的流程，倒還挺自然。

如今，我們在 Software 2.0 世界中也有了類似 GitHub 的東西——比如 

Hugging Face、模型地圖等，它們就像代碼庫一樣存儲著不同的模型。

你看到的中間那個大圓圈，其實是 Flux（一個圖像生成模型）的參數。每次有人在 Flux 上微調模型，就像是對 GitHub 的一次提交。

圖片

一直以來，我們所熟悉的神經網絡，其實都更像“功能固定的機器”——比如圖像分類器。

而這一次，我認為最根本的改變是：

神經網絡開始“可編程”了。

 這就是我們所說的大語言模型（LLMs）。

 在我看來，這是一種全新的計算機。我甚至認為它值得被稱為Software 3.0。 

圖片

現在，你寫的 prompt 就是“程序”，而它運行在大模型之上。更奇妙的是——這些“程序”居然是用英語寫的！

這是一種非常特別的編程語言。

因此，現在我們已經擁有三種完全不同的編程范式：

• Software 1.0：手寫邏輯；
• Software 2.0：訓練參數；
• Software 3.0：用 prompt 驅動大模型。

我建議任何即將入行的人，都要對這三種范式“多面手”，因為它們各有優劣：

• 有時你想顯式寫邏輯，那就用 1.0；
• 有時你想訓練模型，那就用 2.0；
• 有時你只需要 prompt，那就用 3.0。

2.大模型（LLMs）不是“算法”而是“操作系統”

接下來，我想聊聊大語言模型（LLMs）所代表的新計算范式，以及這個新“計算生態”長什么樣子。

我很早以前看到一句話讓我印象深刻，是 Andrew Ng 說的：

 “AI 就像是新時代的電力。” 

這句話點出了關鍵點：

• LLM 實驗室（如 OpenAI、Gemini、Mistral 等）投入資本（CapEx）來訓練模型；
• 然后用運營開銷（OpEx）通過 API 向開發者“輸送智能”；
• 模型按 token 計價，像電力一樣被“計量使用”；
• 我們對這些模型的要求也非常像“基礎設施”：低延遲、高可用、穩定輸出。

假設你切換電源時需要一個轉換開關（transfer switch），我們在用 LLM 時也需要在不同模型之間切換，比如通過 router 連接 Claude、GPT、Gemini。

 “當 SOTA 模型宕機的時候，簡直就像是全世界都‘斷電’了。就像電壓不穩，全球都在‘降頻’運行。” 

但和電不一樣，LLM 不是一種簡單商品，而是一個復雜的軟件系統，甚至更像操作系統（Operating System）：

• OpenAI、Anthropic 就像是 Windows 和 macOS；
• 而開源模型（如 Mistral、Qwen、LLaMA）則更像 Linux；
• 操作系統的作用不是“運行某個功能”，而是構建一個“平臺”來承載更多功能；
• 同樣地，LLM 并不是自己在“完成任務”，而是承載了很多提示詞、工具、代理（agents）等“運行時系統”。

當然，現在的 LLM 還處在非常早期的階段，它們本質上還是“語言模型”。

但現在的趨勢非常清晰：重點不再只是模型本身，而是圍繞它的工具鏈、模態集成、交互協議等全面生態。

我當初意識到這一點時，嘗試畫了一張草圖：

• LLM 是一種新型“計算機”，類似于 CPU；
• Context window（上下文窗口）就是內存；
• LLM 負責協調“內存 + 計算資源”來解決問題；
• 它使用的“能力插件”正在不斷擴展。

從這個角度看，LLM 看起來非常像一個新型的“操作系統”。

圖片

還有個類比我很喜歡：

比如你要下載一個 App，比如 VS Code。你可以在 Windows、Linux、macOS 上運行。

同理，你也可以拿一個基于 LLM 的 App，比如 Cursor，部署在 GPT、Claude、Gemini 上。

這些模型像是不同系統平臺，而 App 則是通用的可插模塊。

3.我們還沒進入“AI 個人計算機時代”

我們現在的 LLM 計算，處于類似“1960 年代”的階段。

• LLM 推理成本仍然很高；
• 所以模型計算被集中部署在云端；
• 而我們就像瘦客戶端（thin client），通過網絡遠程訪問；
• 沒有人真正“獨享”一臺模型計算機。

于是我們回到了“分時共享制”（Time-Sharing）的計算模式——大家排隊用一臺模型，在云里“批處理”執行任務。

 “現在像是在 1960 年代，大家排隊使用計算資源。未來是否能像 1980 年代那樣迎來個人化 AI？我們還不知道。” 

當然，也有一些嘗試正在發生：

• 比如 Mac Mini 被證明是一些 LLM 的理想平臺；
• 如果你的使用方式是“批量推理 + 高內存消耗”，那么本地推理其實是可行的。

這些是個人化 AI 的早期跡象，但還遠遠談不上普及。

也許在座的某位會定義下一代個人 AI 計算機的模樣。

4.與 LLM 交互像是用“命令行”，而 GUI 還沒誕生

 每次我和 ChatGPT 聊天，就像是在“命令行終端”中和操作系統對話。

目前我們還沒有一個真正意義上的 GUI（圖形用戶界面）：

• ChatGPT 只是一個對話氣泡；
• 你能用它做事，但它并不適合所有任務；
• 很多未來的 LLM 應用需要建立自己的 GUI；
• 目前沒有一個通用的、跨任務 GUI 接口存在。

圖片

5.AI的技術擴散路線“上下顛倒”，這項革命性技術屬于所有人

大語言模型（LLM）和操作系統雖然有很多相似之處，但它們也有一些非常獨特的不同點，尤其是在技術擴散路徑方面。

比如說，電力、密碼學、計算機、飛行、互聯網、GPS 等等——這些具有變革性的技術，過去都是從政府和大公司先用起來的。

因為它們昂貴、門檻高，只有大型機構能率先試水，之后才逐漸擴散到消費者手中。

但 LLM 完全反過來了。

大眾用戶才是最早的 adopter，而政府和大企業反而是后知后覺的那批。

所以這次技術擴散是“上下顛倒”的。這項革命性技術不再掌握在政府或大公司手里，而是屬于我們所有人——因為它只是軟件，我們每個人都可以用！ 

ChatGPT 就像“被光速投射到了我們每一臺設備上”，轉眼之間，幾十億人擁有了這臺新計算機。

LLM 是“有缺陷的靈魂”：幻覺、近事遺忘、安全性

LLM 擁有百科全書式的知識和記憶力，遠遠超過任何單個人類。

當然，它們也有很多認知缺陷：

• 它們常常幻覺（hallucinate），會“編造”內容；
• 它們缺乏真正的自我認知模型；
• 雖然這些問題已經有所改善，但還遠未解決；
• 它們展現的是“鋸齒狀智能”——某些方面超人類，某些方面蠢到爆。

比如，模型可能堅稱：9.11 > 9.9，或者“strawberry”里有兩個 r，這些就是經典的例子。

所以它們仍然有很多“坑”，你可能一不小心就踩進去。

另一個非常獨特的問題是——近事記憶缺失（anterograde amnesia）。

你可以把 LLM 想象成一個剛入職的新同事：隨著時間推移，它應該越來越了解公司流程、吸收上下文，并建立自己的專業知識結構。但LLM沒有真實的成長，它們的記憶完全依賴你提供的上下文窗口（context window）。

換句話說：

• 它們不會自己變聰明；
• 你必須“顯式編程”它的工作記憶；
• 很多人對這點理解不足，被“AI 能自學”的幻覺誤導。

我建議大家看兩部電影：《記憶碎片》（Memento）和《初戀50次》（50 First Dates）。

兩部片子里的主角都患有記憶缺陷——每天早上醒來都失去前一天的記憶。

你想想，在這種狀態下去工作、去建立關系，真的太難了。

6.LLM 是“有缺陷的靈魂”：幻覺、近事遺忘、安全性

LLM 擁有百科全書式的知識和記憶力，遠遠超過任何單個人類。

當然，它們也有很多認知缺陷：

• 它們常常幻覺（hallucinate），會“編造”內容；
• 它們缺乏真正的自我認知模型；
• 雖然這些問題已經有所改善，但還遠未解決；
• 它們展現的是“鋸齒狀智能”——某些方面超人類，某些方面蠢到爆。

比如，模型可能堅稱：9.11 > 9.9，或者“strawberry”里有兩個 r，這些就是經典的例子。

所以它們仍然有很多“坑”，你可能一不小心就踩進去。

另一個非常獨特的問題是——近事記憶缺失（anterograde amnesia）。

你可以把 LLM 想象成一個剛入職的新同事：隨著時間推移，它應該越來越了解公司流程、吸收上下文，并建立自己的專業知識結構。但LLM沒有真實的成長，它們的記憶完全依賴你提供的上下文窗口（context window）。

換句話說：

• 它們不會自己變聰明；
• 你必須“顯式編程”它的工作記憶；
• 很多人對這點理解不足，被“AI 能自學”的幻覺誤導。

我建議大家看兩部電影：《記憶碎片》（Memento）和《初戀50次》（50 First Dates）。兩部片子里的主角都患有記憶缺陷——每天早上醒來都失去前一天的記憶。你想想，在這種狀態下去工作、去建立關系，真的太難了。

圖片

還有一個值得注意的問題是安全性。

LLM 非常容易被欺騙，比如 prompt injection 攻擊；也有可能泄露數據。

我們面對的是一種擁有超能力但又有嚴重缺陷的數字生命體。

我們要思考的是：

• 如何編程這些 LLM？
• 如何繞過它們的缺陷？
• 如何發揮它們的“超人力”？

7.部分自治軟件：下一代 LLM 應用的基本形態

我們該如何使用這些模型？又有哪些令人興奮的機會？

第一個我感到特別興奮的方向是：部分自治應用（Partial Autonomy Apps）。

 為什么你要復制粘貼代碼到 ChatGPT，再復制粘貼回來，而不是直接在一個“懂代碼”的 IDE 中完成？

因此比起ChatGPT，我更推薦你使用Cursor。

Cursor 是一款早期的 LLM 應用典范，它具備一系列通用特征，值得所有 LLM App 借鑒：

• 一方面，它保留了傳統 IDE 界面，允許用戶手動操作；
• 另一方面，它也集成了 LLM，可以處理更大規模的修改、生成任務；
• 用戶可以按需調用 LLM 處理不同粒度的任務。

還一個關鍵特性是我稱之為“自治滑塊（Autonomy Slider）”：你始終掌控著自治滑塊，根據任務復雜度來決定給 LLM 多大的權力。

還是以 Cursor 為例：

• 你可以選擇自動補全（最小自治）；
• 也可以選中一段代碼按 Command+K，讓它只修改這一段；
• 或者按 Command+L，修改整個文件；
• 甚至按 Command+I，讓它對整個 repo“放飛自我”，自由重構（最大自治）。

總結來說，LLM 應用的關鍵特征是：

• 人類可以完整手動操作：傳統輸入仍可用；
• LLM 做上下文管理與調用編排：后臺 orchestrate 多模型；
• 有 GUI 可審查生成內容：例如高亮 diff、快捷接受/拒絕；
• 自治程度可調：從部分生成，到一整頁改寫，用戶自主選擇。

8.我們和LLM進入協作階段

我們和 LLM 之間的關系，已經變成了協作。

• AI 負責生成（generation）；
• 人類負責驗證（verification）。

 我們的目標應該是：讓生成-驗證這個閉環盡可能快地運行起來，這樣我們才能真正提效。

要加快這個循環，我認為有兩個關鍵點：

（1）加快驗證流程

• GUI 是實現這一點的重要工具。
• 閱讀純文本很費勁，而看圖形是高效的。圖像是一條“通向大腦的高速公路”。
• 所以，從系統審查效率來說，圖形化呈現非常重要。

（2）我們必須給 AI 套上韁繩（on a leash）

現在很多人對 AI Agent 的能力過于樂觀。

但問題在于：

 “我不想一次性收到一個 1000 行代碼 diff。” 

即便這些代碼一瞬間生成，我作為人類審查者依舊是整個流程的瓶頸。

所以我的個人習慣是：

• 絕不一次生成太大 diff；
• 始終采取“逐塊小修改”的方式；
• 每一步都快速驗證，然后再往下推進。

圖片

我相信我們很多人都在逐步摸索出適合自己的方法論。

9.軟件真的很難，不要去做炫技的“全自治 Agent Demo”

我想順便分享一個故事：

我第一次坐上自動駕駛汽車是在 2013 年。

我當時的感覺是：天啊，自動駕駛已經實現了，它真的能跑了。

結果現在都 12 年過去了，我們還在努力攻克自動駕駛的問題。

Waymo 的車現在看起來“無駕駛員”，但其實仍然有很多遠程操作、很多人類介入。

我想說的是：軟件真的很難。

 它的難度和自動駕駛幾乎是一個等級。

所以當我看到有人說“2025 是智能體（agents）元年”，我會感到警惕。

 我想說的是：這是“Agent 的十年”，不是某一年的事情。

我還特別喜歡用《鋼鐵俠》作為比喻。

我一直都喜歡這個角色，它以很多方式非常貼切地反映了技術的演進。

你看，鋼鐵俠戰衣既是一種增強工具（augmentation），也具備自主智能體（agent）的特征：

• 有時候托尼·斯塔克親自駕駛它；
• 有時候它能獨立飛行、自動尋找目標，還能“找回主人”；
• 這就是“自治滑塊”的不同模式。

現在這個階段，我認為：

• 與其說我們在構建“Iron Man 機器人”；
• 不如說我們更像是在打造“Iron Man 戰衣”。

我們真正要做的，不是去做炫技的“全自治 Agent Demo”，而是做那些具有部分自治、真正實用的產品。

這些產品：

• 擁有定制化的 GUI 和交互體驗；
• 能讓生成-驗證的閉環極快運轉；
• 又不失控、可監督；
• 同時也保留了未來可以逐步自動化的可能性。

你應該思考：你的產品中是否已經有“自治滑塊”？你能不能逐步推動它向更高自治程度演進？

 在我看來，這類“增強人 + 可調節 Agent”的混合產品，才是當前最具潛力的方向。

10“Vibe Coding”走紅：我們應該“走向中間”，與 LLM 會合

不知道你們有沒有聽說過“Vibe Coding”？

我發的這條推文，就是在講這個概念——后來它變成了一個爆火 meme：

 “英語不是編程語言，但它現在就是了。” 

這條推文當時我以為不會有人在意，就像很多“靈感一閃”的碎碎念那樣。

結果，它意外走紅，大家瘋狂轉發。

因為它剛好說出了很多人心里的感受：我們都感覺到事情變了，卻一時找不到一個詞來定義。

現在甚至有了對應的 Wikipedia 頁面（笑），這算是我為時代貢獻的一個新術語吧。

我也試著搞了點「vibe coding」，因為它真的很有趣，其中包括一個叫 MenuGem應用，拍菜單自動生成圖片展示，大家現在就能去試：menugem.app。

vibe coding的感受是：

• 編碼本身（vibe coding）很簡單；
• 反而最麻煩的，是接入登錄、支付、部署等 DevOps 環節；
• 比如谷歌登錄，網頁寫了一大堆“點擊這→跳到那→點確認”，都是給人操作的，而不是設計給 Agent 調用的。

所以： “我們以前只為人類構建 GUI，現在要為 LLM 構建 API 生態。” 

我的觀點是：

• 對于絕大多數產品來說，我們應該“走向中間”，與 LLM 會合；
• 與其等 LLM 完美，不如我們主動調整格式、協議、接口。

最后總結

總結一下：

現在是進入這個行業的黃金時刻。

我們要重寫大量代碼，而這部分會由專業人士、也會由“vibe coder”來完成。

 LLM 像是公用設施（utilities），像是 AI 晶圓廠（fabs），但更像是操作系統。

而這一切，才剛剛開始——這還是“操作系統的 1960 年代”。

這些模型本質上就像數字人格，有缺陷，但極強大，我們要學會與它們共處。

為此，我們需要重塑軟件基礎設施。

未來十年，我們會不斷把“自治滑塊”從左往右推進。

 這個過程會非常有趣，我也等不及要跟大家一起去創造它了。

本文轉載自??51CTO技術棧??，作者：伊風