今天，YC/奇績的朋友都被這個演講視頻刷屏了。OpenAI 創始成員，前特斯拉AI總監、安德烈·卡帕西（Andrej Karpathy）在 YC AI創業學院發表了主題演講 —— 軟件（又一次）發生了范式轉移。

這是個很大的標題，但老馮認為演講的內容對得起這個大題目。視頻的大意是，傳統的代碼是軟件 1.0，神經網絡的權重是軟件 2.0，而現在可以使用自然語言編程的 LLM 是軟件 3.0 。在軟件 3.0 的時代，什么樣的軟件是我們能立刻看到，可以動手去做或者期待出現的，真正的挑戰又是什么，這里面又有什么機會？

作者提出了三個有意思的核心類比：LLM相當于，電力，晶圓廠，操作系統，其中操作系統可能是最合適的類比 —— 當前 LLM 技術棧仍處在 “1960 年代操作系統水平”——計算貴、推理慢，云端集中部署，終端只是瘦客戶端 —— 個人 AI 尚未普及，但本地推理已顯露苗頭。

作者：Andrej Karpathy，OpenAI 創始成員，前特斯拉AI總監、安德烈·卡帕西（Andrej Karpathy）； 譯評：馮若航，數據庫老司機，云計算泥石流。

Andrej Karpathy：軟件正在再次發生改變

“軟件正在發生根本性變化。” Karpathy 在舊金山 YC AI 創業學校的演講中指出，當今軟件領域正迎來一次重大的范式轉移。他將這一新階段稱為“軟件 3.0”，其核心特征是以自然語言作為新的編程接口。在軟件 3.0 時代，開發者只需使用英語等人類語言對大型語言模型（LLM）發出指令，模型就能生成和執行相應的程序邏輯，模型本身承擔了過去需要人類編寫的復雜代碼。這一變化意味著編程門檻的降低——幾乎任何人都可以通過與模型對話來“編程”電腦。對用戶而言，交互方式也發生革命性變化：用戶的需求可以直接用日常語言描述并由計算機執行，人機協作不再有語言障礙。Karpathy 強調，我們正站在一個歷史拐點上，未來的軟件不再是冷冰冰的工具，而將成為能理解人類意圖、具備推理和自主協作能力的智能伙伴。

圖：Karpathy 提到的軟件地圖（GitHub 代碼全景）。他預測大量現有軟件將被重寫以適應軟件 3.0 時代。這種范式轉移的深遠程度不亞于當年從命令行界面到圖形界面的飛躍。

Karpathy 最初在2017年提出“軟件 2.0”的概念，用來描述由神經網絡和數據驅動的軟件開發方式。如今，大型語言模型的崛起使得軟件再度進化，“大量軟件將被重寫或重新設計”以融入這類模型。在他看來，我們正構建一種新型計算機——這種計算機不再依賴人類手工編寫的精確代碼邏輯，而是通過概率式、語義化的方式來理解人類指令，某種意義上“就像人類一樣”思考和行動。

總而言之，軟件3.0宣告了自然語言編程時代的到來：程序員和用戶使用人類語言與模型交互，模型自動完成余下的編程工作。

LLM 是新型計算機

Karpathy 將大型語言模型視作一種全新的計算機，并用多個類比形象地解釋其意義：

?類似公用事業（Utility）：訓練和提供 LLM 服務的公司（如 OpenAI 等）有點像電力公司等公用事業單位。他們投入巨資訓練模型，然后通過 API 向大眾按需提供“智能”。用戶就像用電一樣調用模型服務，需要它具備低延遲、高可靠性等“水電般”的穩定供給能力。當頂尖 LLM 服務宕機時，仿佛全世界經歷了一場“智能停電”——許多人會因智能助手不可用而陷入停滯。

?類似晶圓廠（Fab）：頂級 LLM 的訓練需要巨大的算力和資金投入，堪比建設一座尖端半導體晶圓廠。只有少數技術實驗室具備這樣的研發實力，這導致 LLM 技術（包括模型權重和訓練訣竅）短期內高度集中在少數公司手中。不過，LLM 畢竟是純軟件，擴散速度比硬件更快、防御性更弱。例如，不同于芯片工藝壟斷多年，大模型的開源版本（如 LLaMA 系列）正在快速涌現，行業格局可能比硬件時代更開放。?類似操作系統（Operating System）：在 Karpathy 看來，LLM 最貼切的類比是操作系統。LLM 構成了一個復雜的軟件生態：就像 OS 提供平臺讓各種應用運行，LLM 也將成為眾多上層應用和 agent 的智能中樞。目前有幾家閉源的大模型平臺（類似過去的 Windows、macOS），也有開源替代品的興起（如 LLaMA 之于 Linux）。

Karpathy 提出了一張草圖，把 LLM 比作 CPU，上下文窗口（context window）比作內存，LLM 可以調度“內存+算力”并調用各種工具來完成任務，這與傳統操作系統的角色非常相似。換句話說，LLM 本身就是一種新型計算機/操作系統，開發者需要學習為這種“計算機”編程。

?類比共享主機的早期計算模式：由于當前大模型推理開銷高昂，我們仿佛又回到了 1960 年代的計算格局。大模型被集中部署在云端，用戶作為“瘦客戶端”通過網絡時間共享這些模型。沒有人能獨占整臺“LLM 計算機”，而是排隊使用它的部分算力，就像當年使用大型機一樣。

個人AI計算革命尚未全面到來，但已有跡象：例如一些精簡模型可以在本地高端電腦（如配備大內存的 Mac Mini）上運行，預示未來“個人AI”的可能性。

這些類比揭示了 LLM 的雙重身份：一方面，它像電力和計算機基礎設施，正迅速成為無處不在的底層服務；另一方面，它本身又是一個復雜的軟件平臺，催生全新的應用生態。值得注意的是，LLM 技術還出現了技術擴散路徑的逆轉：過去每次科技革命（電力、計算機、互聯網等）往往先軍用/企業用，后普及到個人。

而大模型恰恰相反——首先被普通大眾廣泛使用，用于日常瑣事（例如教人煮雞蛋），而政府和大企業反而行動較慢。這意味著前所未有的“人人掌握魔法計算機”局面：LLM 作為新型計算平臺，在問世不久就通過軟件分發到了全球數以億計的人手中。Karpathy 感嘆道，這是非常瘋狂但又令人振奮的時代，我們每個人都可以參與進來，為這臺“新計算機”編程。

LLM 的“心理學”：超能力與認知缺陷

在賦予軟件全新能力的同時，LLM 本身也是一種模擬人類的智能，具有獨特的“心理”特征。Karpathy 將大型語言模型比作“人的靈魂（people spirits）”。但與真實人類不同的是，LLM 的智能既有令人驚嘆的超能力，也存在顯著的認知缺陷：

?知識與記憶的超能力：得益于訓練語料覆蓋了互聯網海量文本，LLM 仿佛擁有“百科全書式”的記憶力，可輕松記住遠超任一人類的信息量。這讓人聯想到電影《雨人》（Rain Man）中達斯汀·霍夫曼飾演的自閉天才，過目不忘電話號碼簿的所有信息。類似地，LLM 可以迅速背出復雜的 SHA 哈希值、代碼片段等內容。?幻覺（Hallucination）傾向：LLM 經常會無中生有地編造內容，對自身知識邊界缺乏可靠的判斷。也就是說，當它不知道正確答案時，往往不會直接承認無知，而是生成看似合理但實則虛假的回應。這種“幻覺”問題目前有所改善但遠未根除，是大模型的一大局限。?“鋸齒狀”的智能：LLM 在認知能力上呈現斷檔不均的表現。Karpathy 舉例說，有些模型居然堅持認為9.11 比 9.9 大，或聲稱英文單詞“strawberry”（草莓）里有兩個“R”。這種令人哭笑不得的錯誤反映了 LLM 智能的“不平衡”，存在許多危險的棱角，稍有不慎用戶就可能被誤導。?順行性遺忘（Anterograde Amnesia）：與人類會持續學習和積累經驗不同，LLM 無法自動記憶交互之外的新知識。模型的內部參數在推理時是固定的，交互結束后不會“記住”新的對話內容。換言之，LLM 的上下文窗口相當于人類的工作記憶，在每次會話（甚至每個Prompt）結束后就清空重置。正如電影《記憶碎片》和《初戀50次》中，主角記憶每天重置，這使得持續合作極為困難。因此，我們必須在每次使用時明確提供足夠的上下文信息來“教會”模型當前任務，需要付出額外精力來彌補其不會長期學習的缺陷。?安全脆弱性：當前的 LLM 容易受到對抗性攻擊和信息泄露風險。例如，惡意輸入（提示注入）可能誘使模型輸出不良內容或者泄露先前對話機密。

綜上，LLM 的智能是“超能力”與“認知障礙”并存。因此，我們在使用 LLM 時需要揚長避短，一邊發揮其超人之處，一邊想方設法彌補其思維漏洞。Karpathy 強調，開發者必須學會與這種全新的智能協作，并調整我們的基礎設施和應用設計來包容它的缺陷。

部分自主應用：人與 AI 并肩協作

面對 LLM 的機遇與局限，Karpathy 認為當下最現實、最有潛力的方向是構建“部分自主”（partial autonomy）的應用，讓 AI *賦能而非替代* 人類。也就是說，開發人機協作的軟件：由人類掌控大局，同時將特定子任務交給 AI 自動完成，并由人類對 AI 的輸出進行監督和驗證。這類似于給人類配備“增強 exosuit”（外骨骼裝備），而非完全自主的機器人。Karpathy 打趣說，我們現在要打造的是鋼鐵俠的戰衣而不是鋼鐵俠機器人——也即先打造增強人類的工具，而非炫目的全自動 Agent。

圖：Karpathy 用鋼鐵俠戰衣類比人機協作。左圖代表由人類駕駛、AI輔助的增強工具，右圖代表完全自主的 AI 代理。他主張當前應側重構建左圖這樣的部分自主產品，并在其中加入“自主程度滑塊”，以便日后逐步提高自動化水平。

典型案例是編程助手。以往程序員可能直接用 ChatGPT 這類通用對話界面來幫助寫代碼，但現在出現了專門為編程場景設計的應用，如 IDE 插件 Cursor 等。這些 LLM 驅動的應用相比通用聊天界面有明顯優勢：

?保留傳統界面：應用仍提供人類熟悉的IDE編輯器，程序員可以像平時一樣手動編寫和編輯代碼。這確保人在循環中，不會完全喪失對過程的掌控。?自動上下文管理：應用會自動將相關代碼、文檔作為上下文提供給 LLM，大大減少了人工復制粘貼的負擔。例如 Cursor 在用戶編輯不同文件時，自動讓嵌入模型關注項目中的相應文件，并對代碼變更提供解釋。?多模型調用編排：在這些應用背后，往往同時調用了多個專用模型。以 Cursor 為例，它底層集成了代碼理解模型、聊天生成模型、代碼差異（diff）分析模型等，并通過編排協調，讓它們各司其職、配合完成復雜任務。這種流水線式的模型組合遠比單次對話調用功能強大。?專用 GUI 便于審查：這類應用提供直觀的圖形界面來呈現 LLM 的輸出和建議，使人類驗證AI結果更加高效。例如，Cursor 會以高亮增刪的形式展示代碼修改建議（新增行用綠色、刪除行用紅色標出），程序員只需按下快捷鍵就能接受或拒絕變更，而不必閱讀大量文字描述。可視化降低了人審核AI工作的認知負荷，被Karpathy形容為“利用我們大腦的視覺GPU來加速審查”。?自主程度滑塊：許多 LLM 應用引入了可調節的自主化等級。以 Cursor 為例，用戶可選擇不同程度的 AI 參與：從小范圍補全代碼（幾行以內，由人主導）到整個文件重構，甚至全項目改寫。這種“autonomy slider”讓用戶根據任務難度和對AI的信任度，靈活決定讓 AI 介入多深。類似地，問答類應用 Perplexity 也提供從一次快速查詢到長時間深度調研的不同自動化級別，實質也是在調整 AI 代勞的范圍。

Karpathy 預計，未來大量現有軟件都會引入部分自主功能。開發者需要思考：如何讓我的產品接入 LLM，讓 AI 看見人能看到的信息、執行人能執行的操作，同時保證人類始終在環監督？現有的軟件界面和交互設計（主要面向人類）也需革新，以便 AI 能夠理解界面元素并自動操作。例如，Photoshop 等復雜工具的眾多按鈕和控件，未來或許需要提供機器可讀的接口，讓 LLM 代理也能點擊和調整參數。

為了讓人機合作真正高效，Karpathy指出關鍵在于加快“生成-驗證”循環。通常 AI 負責生成候選答案/方案，人類負責審核修正。要提升整體效率，可以從兩方面入手：

1.加速人類驗證：正如前述，善用 GUI 和可視化，將 AI 輸出轉化為人類易審查的形式，以降低驗證成本。比如代碼diff高亮、答案引用來源等界面，都能幫助人快速判斷 AI 建議的正確性。2.約束 AI 行為范圍：也就是給 AI “牽好繩子”，不要一下放任它做過多事情。Karpathy 反對那種一次讓 Agent 自動化過長流程的做法。例如讓 AI 一口氣生成上萬行代碼的補丁并不實用——人類審核才是瓶頸，人工無法一下子檢查如此龐大的更改。因此，與其讓 AI 野跑，不如限制它每次只做小而可控的增量改動，然后快速由人驗收，通過后再繼續下一步。他本人在 AI 輔助編程時，就是采取“小步快跑”的節奏：每次讓模型產生少量代碼改動，立即測試驗證，通過后再進行下一步。這樣既保證質量又保持高速迭代。

Karpathy 也提到一些實戰技巧正在形成。例如，如果你的提示（prompt）措辭含糊，模型輸出很可能偏離期望，導致你花更多時間去反復試錯。不如一開始就明確具體地編寫 prompt，提高一次成功的概率。許多開發者在摸索如何與 LLM 高效共事，逐漸總結出一套最佳實踐。這些方法本質上也是在彌補 AI 的認知盲區，盡量減少人類驗證負擔。

值得一提的是，Karpathy 并非紙上談兵。他曾領導 Tesla 自動駕駛團隊多年，也是在打造部分自主產品：自動駕駛系統 Autopilot 既有人機交互界面（儀表盤上實時顯示神經網絡感知到的道路情況），又在逐步提高車輛的自動駕駛權重（通過軟件升級讓汽車承擔越來越多駕駛任務）。然而他深有體會：從模型能力到可靠產品有巨大鴻溝。2013年他曾在谷歌親身體驗過一次完美的無人車試駕，本以為全面自動駕駛不遠了，結果十多年過去業界仍在攻堅。

這說明在高可靠性場景下，要讓 AI 完全接管非常困難，涉及對無數邊緣情況的處理。軟件也是如此：一點小錯誤就可能導致系統崩潰或安全漏洞，因此貿然宣稱“今年是 Agent 元年”過于樂觀。Karpathy 強調，應該把這看作一個漫長的演進過程，可能需要整個十年逐步推進，人類始終在環把關，切勿急于求成。

鋼鐵俠戰衣可以作為增強 Tony 的工具，也可以作為獨立行動的 Agent

總之，目前更務實的路徑是增強人類而非完全替代人類。通過打造“鋼鐵俠戰衣”式的AI工具，我們可以顯著提高效率，同時確保人類對關鍵環節保有控制權。當然，Karpathy也承認，從長遠看，隨著技術進步，這些任務終將可以完全自動化。

因此在設計產品時，應內置一個“自主性滑塊”，并考慮未來如何逐步將滑塊從人力轉向自動。可以預見，在可見的未來里，人類和AI將協同作戰，一步步把更多職責交給AI。這也意味著當下正是投身這一領域、構建部分自主應用的極佳時機。

自然語言編程與“氛圍編碼”

除了賦能專業開發者，軟件 3.0 的另一大魅力在于降低了編程門檻。由于用自然語言就能指揮計算機，“人人都是程序員”的前景開始顯現。Karpathy 指出，這在歷史上前所未有：過去人們需要經過多年學習才能掌握編程，而現在懂英語（或其他人類語言）就能讓強大的模型替你寫代碼。

社交媒體上已經出現了“氛圍編碼（vibe coding）”的梗，這是源自 Karpathy 本人的一個玩笑式推文。所謂氛圍編碼，指的是隨心所欲地用自然語言讓 AI 完成編程任務，就像和朋友一起“腦暴”創意一樣去開發軟件。Karpathy 分享了一個令人振奮的視頻：一群9-13歲的孩子借助 AI 模型進行氛圍編程，幾乎零基礎就做出了簡單的游戲或應用。他感嘆說，這樣的場景讓人無法對未來悲觀——未來屬于這一代通過 AI 進入編程世界的孩子們。這將成為他們踏入軟件開發的大門，一個新的創作者世代正在崛起。

Karpathy 自己也親身體驗了氛圍編碼的威力。他用對話方式“編寫”了一個基本的 iOS 應用，盡管他并不精通 Swift 編程，但在模型幫助下僅用一天就讓應用跑在了手機上。另一個例子是他開發了一個名為 MenuGen 的小項目：只需拍下餐館的菜單，模型就會生成菜單上每道菜的圖片。

他興奮地用氛圍編碼迅速做出了原型。但隨后他發現，要把這個原型變成真正上線的產品，還有許多繁瑣的非編碼工作：設置用戶登錄、支付系統、購買域名、部署服務器……這些環節往往沒有 API 可以讓 AI 代理去完成，而是需要人工按照說明一步步點擊操作，非常低效。

Karpathy 打趣說，MenuGen 雖然功能實現了，但由于每個新用戶都會消耗圖像生成API額度，它成為了他的“燒錢應用”。從這一經歷他體會到：編寫代碼本身在 AI 時代變得前所未有的容易，而編程之外的軟件構建事務反而凸顯瓶頸。

這正好引出他演講的最后一個主題：為 AI 代理而構建。

為 AI 代理構建：讓軟件生態適應智能體

既然大型模型可以充當“數字勞力”，那么我們應當主動調整軟件生態，使其更適合 AI 代理使用。Karpathy 提出，LLM 已經成為繼 GUI（供人操作）和 API（供程序調用）之后，第三種主要的數字信息消費者和操作者。這些 AI 代理本質上是軟件機器人，卻擁有類似人的理解和行動能力——可謂“互聯網中的人類之靈”在活動。因此，我們應當開始為它們設計和優化我們的系統。

一個設想是針對 AI 代理提供專門的元信息。類比于網站通過 robots.txt 文件告訴爬蟲如何抓取，未來網站或服務可以提供一個 llm.txt 文件，以簡潔明了的文本說明供 AI 理解。例如，直接用自然語言或簡潔的 Markdown 描述本站點的功能和數據接口，讓 LLM 在讀取網頁前就清楚地了解如何與之交互。相比之下，如果讓 AI 去解析復雜的 HTML 網頁，再從中推測使用方法，不但費力還容易出錯。所以，與其被動等待 AI 攻克各種格式，不如我們主動以AI 友好的形式提供信息。

同樣地，技術文檔也需要重新書寫以方便 LLM 理解。傳統文檔是寫給人看的，包含大量圖片、排版和點擊步驟說明，AI 閱讀時常常無所適從。Karpathy 提到一些前沿公司（如 Vercel 和 Stripe）已經開始將文檔改寫成Markdown 格式，盡量使用純文本、列表等結構化方式來表述，從而對 LLM 更加友好。他本人也有切身體驗：他喜歡的動畫庫 Manim 文檔非常詳盡冗長，他懶得通讀，于是索性將整份文檔拷貝給 LLM，然后直接用自然語言描述自己想實現的動畫效果。結果模型一下就生成了完全可行的代碼，讓他非常震驚。這說明如果文檔內容能被 LLM 充分“看懂”并內化，將大大解鎖 AI 自動完成任務的潛力。

不過，要真正做到這一點，不僅格式要轉換，內容本身也需要調整。Karpathy 舉例說，文檔里諸如“點擊這里打開設置”的說明對 AI 來講是死路一條，因為當前模型還不會像人一樣真正去“點擊”GUI 按鈕。相反，應該把這些步驟改寫成等效的API 調用或命令行指令。據他所知，Vercel 正在把文檔里的每個“點擊”操作替換成對應的 curl 命令，以便將來 LLM 代理可以直接調用，實現全自動化。他還提到了 Anthropic 提出的模型上下文協議（Model Context Protocol），也是讓人類可以直接與 AI agent 對話、傳達高層意圖的一種嘗試。這些探索都是為了把 AI 視為一等公民，讓我們的系統能直接對接 AI，而不再假定交互方一定是人類。

此外，已有一些巧妙的小工具幫助把現有數據源轉換成 LLM 樂于接受的形式。比如將 GitHub 倉庫的鏈接從 github.com 換成 get.ingest，就能得到一個把整個倉庫所有文件串成的大文本，并附帶清晰的目錄結構。這樣，開發者可以一股腦將代碼庫內容復制給 LLM，請它進行分析或問答，不用受限于單個文件長度。更先進的如 Deep Wiki，還能預先對倉庫做靜態分析，生成摘要和文檔頁面，相當于提煉出更精華的知識給 LLM 用。Karpathy表示，他非常欣賞這類只需改一下 URL 就能讓數據脫胎換骨為 AI 可消費內容的創意。

當然，我們也可以預計，未來 LLM 本身會變得更強大，逐步學會瀏覽網站、點擊按鈕、調用工具等操作（一些新型 Agent 已初步具備這些能力）。但即便如此，他認為主動迎合 AI 也是值得的：畢竟讓 AI 自己摸索一切仍有很高的成本和不確定性，大量傳統軟件和靜態頁面短期內不會自動適配 AI，這就需要我們提供“橋梁”來彌合。對那些核心的重要系統，更應盡早考慮如何與 AI “在中間會師”，提高交互效率。總之，在他看來，從提升 AI 自主能力和改造環境降低 AI 使用難度這兩條路徑同時推進，是非常有前景的。

展望未來，Karpathy 總結道：現在進入軟件行業可謂正逢其時，我們將見證并參與重寫海量代碼的浪潮。這其中既包括專業程序員借助 LLM 高效編寫的代碼，也包括 LLM 本身自動生成的代碼。大型模型及其背后的基礎設施，類似于新時代的“電廠”“晶圓廠”或“操作系統”，但目前仍處于早期階段（仿佛計算機發展的1960年代）。他在演講中已經介紹了一些實用的方法和工具，可以幫助我們快速迭代、構建出最簡可行的 LLM 產品原型，同時逐步為將來的全自動 Agent 打下基礎。

最后回到“鋼鐵俠戰衣”的比喻，Karpathy 預測未來十年我們將持續推動自主化的滑塊向右移動：AI 代理將變得越來越智能，能夠承擔更多責任；而我們的開發工具和實踐也會隨之演進。這是一個令人興奮的征程，他表示非常期待與開發者社區一起見證并打造這個新未來。毫無疑問，軟件正在再次改變，這一次的驅動力是大型語言模型。這場變革才剛剛開始，機遇屬于善于擁抱軟件 3.0 時代的創造者們。

老馮評論

這篇演講提出了幾個非常新穎的類比，與一些有趣的，富有啟發的觀點。但最讓老馮注意的是 Andrej Karpathy 作為一個 Vibe Coder，遭遇到的最大挫折不在寫代碼上，而在 DevOps 上 —— 他可能花了幾個小時就能讓 Curosr 糊出一個不錯的應用，但是耗費了整整一周去折騰部署，配置，技術選型的事情。

而老馮基本上剛剛也體驗過同樣的事情，在 《》里，我介紹了俺作為前端門外漢在 Claude Code / Cursor 和前端老司機的引路下快速上手糊出現代前端網站的經驗。實際上真正的卡點不在于開發，而在于 Ops —— 這件事情也很好理解，相比 Github 代碼倉庫而言，大模型并沒有非常多的 Ops 經驗學習材料。

所以，Claude Code 可以很輕松的幫我寫出各種前端代碼，但是在如何部署到 Vercel ，接入 PostHog 監控，設置 Next.js 開發環境，接入認證，支付這些運維領域的事情上，就要力所不及得多了。老馮很高興的看到并不是只有俺一個人卡在這兒了。Vibe Coding 這個 meme 的祖師爺發明人也卡這兒了。

像這樣的問題，能卡住數據庫老司機，能卡住 AI 大神，那么自然也會卡住更多的 Vibe Code，而這里就會出現巨大的機會。一套解決方案，將這些部署，運維上的摩擦阻力降到最低　—— 時代會呼喚一個 新的 “LAMP” Stack 的出現。

正如 Andrej Karpathy 對 LLM 的操作系統類比所揭示的那樣。LLM 大模型是軟件3.0時代的操作系統（L ：Linux ?? LLM）； Agent 則成為 Web 時代的服務器/瀏覽器（Apahce ?? Agent）；數據庫老馮可以 100% 斷定，除了 PostgreSQL 不會有其他了（M：MYSQL ?? PostgreSQL），至于軟件3.0時代的編程語言，就是自然語言 Prompt 了（P：PHP ?? Prompt）。

在這個新一代軟件技術棧中，Agent / Prompt 是變數最大的，而確定性最高的，其實是 PostgreSQL 數據庫。所以很多人問老馮為什么不去蹭蹭 AI 熱點 —— 真沒這個必要，PostgreSQL 已經是軟件 3.0 時代里確定性最高的鏟子了（《》）。而這也確實帶來一個難得的機會 —— 把 Vibe Coder 面臨的共性痛點，用普惠，開源，順暢，絲滑的方式解決。