本文旨在對安德烈·卡帕西（Andrej Karpathy）于2025年6月在YC人工智能創業學校（YC AI Startup School）發表的演講《人工智能時代的軟件》（Software in the era of AI）進行全面、專業的深度剖析 。作為人工智能領域的杰出人物，卡帕西的演講不僅是一系列觀察的集合，更是一套關于軟件演進的統一理論，并為該領域的建設者和投資者描繪了一幅戰略路線圖。

演講者背景：

Andrej Karpathy是人工智能領域最具影響力的思想家和實踐者之一。他的職業生涯貫穿了本輪AI革命的幾個關鍵節點：作為OpenAI的創始成員，他參與了奠定當前技術浪潮基礎的早期研究；在斯坦福大學，他師從著名AI學者李飛飛，并創立了極具影響力的深度學習課程CS231n；作為特斯拉前人工智能高級總監，他領導團隊將前沿的計算機視覺技術應用于自動駕駛系統Autopilot 1。近期，他創辦了AI教育組織Eureka Labs，致力于通過“Zero to Hero”等課程普及AI知識，這進一步鞏固了他作為該領域關鍵教育者和思想領袖的地位 1。Karpathy的深厚學術背景和豐富的產業經驗，使其觀點具有極高的權威性和前瞻性。

演講背景：

本次演講于6月16日在YC人工智能創業者學校進行，其核心內容不僅是對技術趨勢的解讀，更是一份為未來十年軟件開發制定的戰略宣言 7。它系統性地闡述了軟件開發范式的演進，并為技術領導者、開發者和投資者指明了方向。本文旨在對這份長達72頁的PPT進行詳盡的、逐頁的深度分析，不僅翻譯其內容，更將結合廣泛的市場、技術和戰略背景，全面解讀其深層含義。

同時我們將遵循卡帕西的敘事邏輯，分為五個部分：

1.探討軟件范式的演進；2.分析作為新型計算平臺的LLM的本質；3.剖析這些新模型的“心理學”特征；4.審視當前的市場機遇；5.論述為“智能體優先”（agent-first）世界構建基礎設施的迫切性。

01新的軟件范式

本部分解構了Karpathy的核心論點，即軟件開發正在經歷一場從代碼到權重，再到提示詞的根本性變革。這一軟件演進的三階段理論構成了其整個演講的基石，預示著軟件開發、分發和交互方式的根本性變革。

1.1 從代碼到權重：軟件2.0時代的黎明

卡帕西的理論始于對軟件開發歷史的重新劃分。傳統軟件，即“軟件1.0”，是由人類程序員通過明確的、確定性的指令編寫的，其產物是源代碼，使用的語言包括Python、C++等 。隨后，他引入了其在2017年首次提出的“軟件2.0”概念，這標志著一個根本性的轉變：程序不再是編寫出來的，而是通過優化過程學習得來的。在這個新范式中，軟件的核心產物不再是源代碼，而是神經網絡的數值“權重”——一個通過數據訓練優化而成的龐大參數集 。

這一轉變重新定義了開發者的角色。開發者從一個編寫算法的“程序員”轉變為一個“教師”或“數據策展人”，其主要工作是收集、清洗和標注海量數據集，以引導優化過程找到最佳的程序（即權重）。開發環境也從集成開發環境（IDE）轉變為由PyTorch、TensorFlow等框架構成的數據處理流水線和模型訓練基礎設施。

演講開篇即宣告了一場變革的到來。“GitHub地圖”是Karpathy用來描繪軟件1.0世界的巧妙視覺隱喻 7。在這張地圖上，技術領域被劃分為由不同編程語言和框架定義的“領地”和“王國”（如Pythonium、Javacore、Dotnet Dominion等）。這代表了數十年來由人類程序員手動編寫代碼的傳統軟件開發模式。Karpathy以此為基準，引出了即將顛覆這一格局的新范式。

將傳統的計算機代碼（軟件1.0）與一個神經網絡權重矩陣（軟件2.0）并置，并引用了Karpathy在2017年發表的博客文章 7。

此頁引入了“軟件2.0”這一核心概念。該術語由Karpathy在2017年的一篇Medium文章中首次提出，迅速成為行業內的重要詞匯 8。

○軟件1.0：由人類程序員用C++、Python等語言編寫的顯式指令。其邏輯是確定性的、人類可讀的。

○軟件2.0：“代碼”不再是人類編寫的邏輯，而是經過訓練的神經網絡的權重。程序不是被“編寫”出來的，而是通過數據“優化”出來的。其源代碼由“數據集”和定義了網絡骨架的“模型架構”組成11。

○早期反響：這一概念最初曾引發一些爭議，部分評論者認為它更像是一種“營銷炒作”或修辭手法，而非真正的范式轉移12。然而，隨著神經網絡能力的飛速發展，其影響力日益彰顯。

將“GitHub地圖”（軟件1.0）與“Hugging Face模型圖譜”（軟件2.0）進行對比 7。

Karpathy將Hugging Face定位為軟件2.0時代產物（即模型權重）的中央存儲庫。Hugging Face平臺托管了超過一百萬個模型、數據集和應用，被譽為“AI領域的GitHub” 13。其戰略重要性體現在其高達45億美元的估值（截至2023年）以及來自谷歌、亞馬遜、英偉達和Salesforce等所有主要科技巨頭的投資 13。這雄辯地證明，軟件2.0的“資產”已經形成了一個價值數十億美元的龐大市場。

1.2 從權重到提示詞：軟件3.0的崛起在軟件2.0的基礎上，卡帕西進一步提出了“軟件3.0”的概念。在這一新階段，軟件的核心產物演變成了“提示詞”（prompt）——一套給予預訓練大型語言模型的自然語言指令 。LLM本身是一個巨大的、通用的神經網絡，與軟件2.0時代功能固定的神經網絡（如用于圖像識別的AlexNet）不同，LLM是一個“可編程的神經網絡”，能夠根據指令執行多樣化的任務 。 卡帕西在2023年發布的一條廣為流傳的推文——“最熱門的新編程語言是英語”精準地捕捉到了軟件3.0的精髓 。這并非夸張，而是宣告了一個全新抽象層的誕生。開發者現在可以不必編寫復雜的Python代碼（軟件1.0），也無需策劃龐大的數據集來訓練一個自定義模型（軟件2.0），只需通過清晰的自然語言

描述任務，就能驅動一個已存在的、強大的通用模型來完成工作 。

追溯了從固定功能的神經網絡（如AlexNet，約2012年）到可編程的大語言模型（LLM，約2019年）的演進，并首次將軟件3.0定義為“提示”（Prompts）7。

○固定功能（軟件2.0）：像AlexNet這樣的早期模型，被訓練用于執行單一特定任務（如圖像識別）。它們功能強大，但在通用性上有所欠缺。

○可編程（軟件3.0）：2017年《Attention is All You Need》論文中提出的Transformer架構是實現這一飛躍的關鍵 15。Transformer的自注意力機制（Self-Attention）使模型能夠深入理解語言上下文，使其成為一種通用的計算設備。這種設備可以在推理時通過自然語言提示進行“編程”。幻燈片中的圖表展示了Transformer的核心組件：輸入/位置編碼（Input/Positional Embedding）、多頭注意力（Multi-Head Attention）和前饋網絡（Feed Forward）。

演講中關于情感分類的例子極好地說明了這三種范式的差異：

●軟件1.0：一個脆弱的Python函數，依賴于一個硬編碼的關鍵詞列表。它易于理解，但無法處理任何細微的語言差別或反諷。

●軟件2.0：需要一個包含數萬條正負面評論的大型標注數據集，經過特征工程（如詞袋模型）處理后，用于訓練一個二元分類器。這種方法更強大，但資源消耗巨大，且模型功能單一。

●軟件3.0：一段結構清晰的提示詞，向LLM解釋任務、定義輸出格式，并提供幾個示例（即“少樣本提示”或few-shot prompting）。這種方法開發速度極快，靈活性高，并且不需要任何自定義的模型訓練或代碼編寫。

對比了實現情感分類任務的三種方法

從軟件1.0到3.0的演進，體現了技術能力與使用門檻之間關系的倒置。軟件1.0要求開發者具備深厚的編程語言知識；軟件2.0要求開發者掌握機器學習和數據工程的專業技能；而軟件3.0，在其基本形式上，僅要求使用者具備清晰的邏輯思維和自然語言表達能力。這極大地降低了軟件創造的門檻，這一主題在后續的“氛圍感編程”（vibe coding）中將得到進一步闡述。

然而，這也預示著“資深”的定義正在改變。一個資深的軟件3.0工程師，其核心競爭力可能不再是傳統的編碼技巧，而是成為一個更優秀的AI“教師”和“溝通者”。他們擅長通過精妙的提示詞工程（prompt engineering）來引導、約束和激發模型的潛能，并深刻理解模型的“心理”特質，以規避其固有的缺陷。

再次展示“GitHub地圖”，并在其上增加了一塊新大陸：“LLM提示，用英語編寫”（軟件3.0）。同時，展示了Karpathy廣為流傳的推文：“最熱門的新編程語言是英語” 。

軟件“編程”的門檻被極大地降低了——從需要掌握形式化語言（如Python、C++）的專業知識，轉變為熟練運用自然語言。這在極大程度上實現了軟件創造的民主化，但同時也對技能提出了新的要求：從純粹的編碼轉向提示工程、上下文管理和系統設計。

卡帕西以特斯拉的自動駕駛系統為例，生動地展示軟件2.0如何“吞噬”軟件1.0 。● 系統架構：該系統集成了多個攝像頭、雷達和超聲波傳感器，持續不斷地收集關于車輛周圍環境的數據 6。

● 核心引擎“BEV Net”：一個被稱為“鳥瞰圖網絡”（Bird's-Eye-View Network）的龐大神經網絡，是系統的核心。它將來自不同傳感器的多模態數據流融合，構建出一個統一的、三維的向量空間來表征車輛周圍的世界。基于這個表征，網絡能夠對動態物體（如其他車輛、行人）的軌跡和靜態元素（如車道線、路沿）的位置做出精確預測 。這個通過學習得到的系統，取代了傳統軟件1.0中需要用數百萬行代碼才能勉強處理的、現實世界駕駛中無窮無盡的邊緣情況。

● 軟件2.0的開發棧：特斯拉的自動駕駛系統完美體現了軟件2.0的開發模式。其“代碼”就是BEV Net中經過訓練的權重。系統的改進并非通過重寫邏輯代碼，而是通過向其投喂更多樣化、更具挑戰性的駕駛數據來實現。這些數據部分來源于特斯拉車隊在“影子模式”下收集的真實世界駕駛場景，系統在后臺模擬決策，并將結果與人類駕駛員的行為進行比較，從而不斷迭代優化模型 7。

展示了特斯拉Autopilot的技術棧。其中，“2.0代碼”模塊（如BEV Net、Temporal module）處理來自攝像頭和傳感器的輸入以生成預測，這些預測隨后被“1.0代碼”用于控制轉向和加速 。

這是一個“軟件2.0吞噬軟件1.0”的真實世界案例 10。作為特斯拉前AI總監，Karpathy提供了內部視角。特斯拉最初在視覺任務上更多地使用傳統的算法方法（軟件1.0），但后來轉向了一個統一的神經網絡方法（軟件2.0），該方法直接從海量的駕駛數據中學習 10。“鳥瞰圖預測”（Bird's eye view predictions）是神經網絡（權重）的輸出，這些輸出接著成為經典控制系統（代碼）的輸入。

這種范式轉變并非簡單的技術升級，而是一種深刻的權衡。軟件2.0在處理像自動駕駛這樣復雜、數據豐富的領域時展現出超越人類的潛力，但同時也引入了新的挑戰。特斯拉自動駕駛系統既能完成令人驚嘆的駕駛操作，也因其在某些邊緣場景下的可靠性問題而備受爭議。這種在“能力”與“可靠性”之間的張力，是軟件2.0的核心特征。它以犧牲傳統軟件的確定性和可解釋性為代價，換取了在模糊和復雜問題上的強大性能。

“巨量的軟件將被（重新）編寫”，并用箭頭表示從1.0向2.0和3.0的遷移 7。

向軟件2.0和3.0的轉變不僅意味著創造新應用，更意味著對現有軟件進行根本性的平臺重構。這創造了巨大的經濟機遇，堪比從大型機到個人電腦，或從桌面端到Web端的歷史性轉變。

特征

軟件1.0

軟件2.0

軟件3.0

源產物

顯式代碼（如Python文件）

神經網絡權重（如.pt文件）

自然語言提示（如文本文件）

開發過程

編寫顯式邏輯

策劃數據集、訓練模型

提示工程、少樣本示例

運行環境

CPU

GPU/TPU/專用硬件

LLM（作為服務或在設備上）

核心技能

算法思維、語言語法

數據科學、機器學習工程

提示設計、領域知識、系統設計

示例

simple_sentiment 函數

訓練好的二元分類器

You are a sentiment classifier... 提示

軟件范式對比（1.0、2.0、3.0）

這張表格清晰地總結了Karpathy所介紹的基礎概念，為理解后續內容奠定了堅實的基礎。它將抽象的1.0、2.0和3.0概念具體化、可比較化，極具參考價值。

02大語言模型作為新的計算平臺

在本部分中，將深入分析卡帕西用以闡釋LLM本質及其市場動態的三個關鍵類比。這三個類比——“效用設施”、“晶圓廠”和“操作系統”——共同構建了一個理解當前AI技術格局的強大心智模型，將其定位為一個全新的、基礎性的計算平臺。

2.1 LLM作為一種公共事業或效用設施（Utility）

卡帕西引用了吳恩達（Andrew Ng）的名言“AI是新的電力”，將LLM類比為一種基礎的效用設施或公共服務 。

●資本支出（CAPEX）與運營支出（OPEX）：訓練一個基礎模型的巨大前期投入（例如，xAI公司擁有10萬塊H100 GPU的“巨像”計算集群 ），相當于建設一座“發電廠”的資本支出。而持續提供模型推理服務的成本，則構成了運營支出 。

●計量訪問與同質化API：用戶通過一個日益標準化的API（輸入提示詞，輸出文本）接入這個“智能電網”，并根據使用量付費（例如，按百萬令牌計費），這與支付電費的方式如出一轍 。

●可靠性與“斷電”：用戶要求服務具有高正常運行時間和低延遲，就像要求電網提供穩定的電壓一樣。當像OpenAI這樣的主要供應商服務中斷時，整個數字經濟都會經歷一次“智能斷電”（intelligence brownout） 。

演講中將OpenRouter比作電力系統中的“轉換開關”（Transfer Switch） 。OpenRouter是一個API網關，它將開發者的請求路由到來自不同供應商（如OpenAI、Anthropic、Google等）的數百個不同模型。這使得開發者可以根據成本、性能或可用性等因素在不同模型之間靈活切換，其功能與能夠在市電、備用發電機和電池之間切換的轉換開關完全相同。這揭示了AI技術棧中一個新興的層次：提供彈性和成本優化的“元效用設施”或“聚合器”，它們建立在主要供應商的基礎之上。

2.2 LLM作為一座晶圓廠（Fab）

這個類比將LLM訓練中心比作半導體制造的晶圓廠 。

●深度技術與商業機密：兩者都涉及巨額的資本支出、深度的研發投入和專有的技術秘密（“secret sauce”）。

●“無廠”與“整合”模式：像Anthropic或Mistral這樣在NVIDIA的GPU上訓練模型的公司，類似于“無廠”（fabless）芯片設計公司（如AMD或蘋果），它們依賴臺積電（TSMC）的晶圓廠進行制造。而像Google這樣使用自研芯片（TPU）進行訓練的公司，則類似于“整合設備制造商”（IDM）（如英特爾），它們擁有自己的晶圓廠 。這種區別對成本、控制能力和供應鏈安全具有重大的戰略影響。潛在的xAI被視為垂直整合的參與者，它們“擁有自己的晶圓廠”。幻燈片中提到的xAI由10萬塊H100 GPU組成的“Colossus”集群，直接指向了埃隆·馬斯克正在孟菲斯建造的“計算超級工廠” 。

這一類比的意義超越了單純的成本考量，它揭示了人工智能計算的地緣政治維度。全球半導體供應鏈已是地緣政治博弈的核心戰場。同樣，能否獲得尖端的AI芯片（如NVIDIA的H100）以及運行它們所需的龐大能源，正迅速成為衡量國家實力的關鍵指標。卡帕西提及xAI的“巨像”集群，正是在強調構建一個頂尖LLM已成為一項需要國家級產業投入的行動，這與全球在半導體領域的競賽遙相呼應。“LLM即晶圓廠”的概念預示著，未來AI的發展將受到與芯片產業相同的產業政策、出口管制和資本投資力量的塑造。

將LLM訓練集群比作半導體制造工廠（晶圓廠）。

模型家族

具體模型

預估訓練成本

OpenAI

GPT-4

7800萬美元

Google

Gemini 1.0 Ultra

1.91億美元

Meta

Llama 3 (家族)

5億多美元

Anthropic

Claude 3 Sonnet

數千萬美元

基礎模型預估訓練成本

2.3 LLM作為一個操作系統（Operating System）這是卡帕西提出最具洞察力和核心地位的類比。他認為，LLM并非像電力那樣的簡單商品，而是一個復雜的、不斷演進的軟件生態系統，其性質更接近于一個操作系統 。 LLM OS的架構 ● 內核空間與用戶空間：模型的內部狀態和系統提示詞類似于操作系統的“內核空間”，而用戶輸入的提示詞則相當于“用戶空間” 。 ● 內存（RAM）：上下文窗口是LLM OS的“物理內存”或RAM。它是有限的、易失的，并且是所有計算發生的地方 。 ● 外圍設備（Peripherals）：LLM OS通過“工具使用”能力與各種“外圍設備”進行交互，這些設備可以是瀏覽器、文件系統、計算器，甚至是其他LLM 。 ● “大型機時代”：目前我們正處于這個新操作系統的“分時共享”（time-sharing）時代 。我們通過一個“終端”（即聊天界面 ）訪問部署在云端的、昂貴的大型中央LLM，計算資源在眾多用戶之間批處理和共享。 ● “個人電腦v2”的未來：隨著強大的本地模型在蘋果芯片（如M4 Mac上的Llama 4）等設備上的興起，預示著一個“個人電腦v2”時代的到來。在這個未來，操作系統將直接在個人設備上運行，就像大型機最終讓位于個人電腦一樣 。

論證LLM不僅僅是商品，更是一個復雜的軟件生態系統，類似于操作系統（OS）。幻燈片展示了一個帶有外圍設備的“LLM OS”示意圖 7。

● 這是Karpathy最核心的類比。

○內核/用戶空間：系統提示（開發者的指令）就像內核空間，而用戶提示則是用戶空間。這直接關聯到提示注入這一安全挑戰，即不受信任的用戶輸入可能會“攻擊”內核的指令 23。

○內存 (RAM)：上下文窗口是LLM的工作記憶。這是一個關鍵限制，導致了“順行性遺忘癥”（將在第三部分討論）。

○外圍設備：LLM可以與計算器、Python解釋器、瀏覽器甚至其他LLM等外部工具交互，將它們視為輸入/輸出設備。

將在一系列傳統操作系統（Windows、Mac、Linux）上運行應用（VS Code），與在一系列LLM“操作系統”（GPT-4、Claude、Gemini）上運行LLM應用（Cursor）進行類比 。

這個類比有力地強化了操作系統的概念。應用（如Cursor這樣的面向用戶的產品）正與底層的“內核”（基礎LLM）解耦。應用開發者可以、也將會為多個LLM進行開發，而用戶最終將能夠選擇或切換它們，就像我們為電腦選擇操作系統一樣。這創造了一個新的競爭層面，也催生了對OpenRouter（見第14頁）這類抽象層的需求。

將當前AI的發展階段比作20世紀50-70年代大型機的分時共享時代。隨后，通過在Apple Silicon上運行大型模型的例子，展示了“個人計算v2”的早期跡象。

●歷史類比與未來趨勢：

○分時共享：我們通過“終端”（聊天界面）訪問強大、集中的LLM（云端的“大型機”），計算任務被分批處理和流式傳輸。

○個人計算v2：強大的端側硬件，特別是蘋果的統一內存架構（Unified Memory Architecture），正在開啟一個新的范式。蘋果的M系列芯片最高可支持512GB的統一內存，能夠將擁有數千億參數的龐大LLM完全加載到本地內存中運行 24。幻燈片中展示的在多臺Mac上運行稀疏專家混合（Mixture-of-Experts, MoE）模型（如Llama 4和DeepSeek）的例子，正突顯了這一趨勢。MoE模型計算效率高，因為在處理任何給定token時，只有一小部分參數是活躍的，這使其非常適合在設備上進行推理 26。

將文本聊天界面比作圖形用戶界面（GUI）出現之前的終端，說明LLM如何顛覆了傳統的技術擴散模型

○聊天即終端：當前LLM的主要交互界面（如ChatGPT）就像命令行——功能強大但體驗原始。這暗示著LLM的“GUI”尚未被發明，這在UI/UX設計領域意味著巨大的機遇。

○顛覆性擴散：Karpathy指出，技術通常是從軍事領域擴散到企業，再到消費者（例如GPS、互聯網）。LLM卻顛覆了這一模式。最先進的模型幾乎在一夜之間就直接提供給了數十億消費者（“你好ChatGPT，怎么煮雞蛋？”），而企業和政府現在才開始追趕。這是一個獨特的歷史時刻，對創新和監管都具有深遠影響。28

第一部分核心觀點：LLM實驗室如同晶圓廠，LLM類似于20世紀60年代通過分時共享訪問的操作系統，而現在數十億人突然獲得了對其進行編程的能力 。

這部分內容為LLM作為一種新的、基礎性的計算平臺進行了全面的定位，為接下來探討其具體特性和所創造的機會鋪平了道路。

如果LLM是一個操作系統，那么一場新的平臺競爭將不可避免。正如Windows、macOS和Linux在功能、開發者生態和用戶體驗上各有千秋，來自OpenAI、Anthropic和Google的模型也展現出不同的“風格”和能力 。像Cursor這樣的AI原生應用雖然可以在不同的LLM上運行，但其行為可能會有細微差異，從而產生“轉換摩擦” 。

這為模型供應商創造了強大的動力去構建自己的生態系統——包括“驅動程序”（API、工具集成）和“應用程序”，以鎖定開發者和用戶，這與上世紀90年代的操作系統戰爭如出一轍。這個框架解釋了為何像Vercel AI SDK這樣的開發者工具具有重要的戰略意義，因為它們充當了跨平臺的兼容層 23。同時也說明了為什么像Stripe這樣的公司要構建特定的“驅動程序”（如其模型上下文協議MCP），以確保自己的“硬件”（服務）能與這個新操作系統良好兼容 26。

03LLM的涌現心理學本部分將探討卡帕西對LLM的定性描述：它們是存在缺陷的、“隨機的人類模擬”，或稱“人類心魂”（people spirits） 。理解這些“心理學”特質對于在軟件3.0范式下進行有效的“編程”至關重要。

本部分從技術和經濟類比轉向探討LLM的行為特征，即Karpathy所稱的“心理學”。

3.1 數字心智的二元性：百科知識與鋸齒狀智能● 天才的一面：LLM擁有百科全書式的浩瀚知識，能夠像天才一樣回憶起晦澀的知識點。卡帕西用電影《雨人》（Rain Man）來比喻其驚人的記憶力 。 ● 愚鈍的一面：然而，這種才華是“鋸齒狀的”（jagged）。同一個模型可以在一瞬間展現驚人的才智，下一秒卻在簡單的邏輯或算術問題上犯錯（例如，回答“2+2=5”）或在基本事實核查上失敗（例如，拼寫錯誤） 。這種不一致性使得它們在沒有適當監督的情況下變得不可靠。

將LLM描述為“人類的隨機模擬”（stochastic simulations of people），它們擁有一種涌現出的“心理學”。

“隨機鸚鵡”（stochastic parrots）一詞常被用作批判，但Karpathy將其重塑為“人類精神的模擬器”，這是一個更寬容的說法，承認了它們在模擬類人推理、知識和缺陷方面的能力。Transformer架構圖再次出現，旨在將這種涌現行為追溯到其底層架構 。

電影《雨人》的海報 ，百科全書式的知識/記憶

3.2 核心病癥及其安全隱患

●幻覺（Hallucination）：這是指LLM以極高的置信度生成事實不正確或無意義內容的行為 。

○技術背景：幻覺并非程序錯誤，而是自回歸模型（autoregressive model）的固有屬性。這類模型的設計目標是預測下一個最可能的token，而非最真實的token 27。幻覺的產生可能源于訓練數據中的錯誤、有缺陷的注意力機制，或是模型試圖“填補”其知識空白的結果 27。

○現實影響：幻覺是LLM在企業級應用中普及的主要障礙，尤其是在法律、金融等高風險領域，錯誤的輸出可能導致嚴重后果 28。這也是驅動像Perplexity這樣基于檢索增強生成（RAG）技術開發問答引擎的關鍵原因。

電影《恐懼拉斯維加斯》的海報幻覺

LLM傾向于生成看似合理但實際上不正確或毫無意義的信息。這是可靠性方面的一個主要問題，也是當前研究的重點領域。

參差不齊的智能（Jagged intelligence）

一個模型可能在簡單的算術或邏輯謎題上失敗。這種“參差不齊的智能邊界”使得在沒有驗證的情況下難以信任其輸出。

順行性遺忘癥（Anterograde amnesia）

LLM沒有超越其上下文窗口的長期記憶。這個窗口的功能類似于一個短暫的工作記憶 。它們不會通過與用戶的互動來將新知識固化到其權重中。卡帕西用電影《記憶碎片》（Memento）和《初戀50次》（50 First Dates）來比喻這種記憶缺陷 。為解決此問題，活躍的研究領域包括檢索增強生成（Retrieval-Augmented Generation, RAG）以及更復雜的持續學習技術，如自適應SVD，這些技術試圖在不覆蓋關鍵知識的情況下更新模型權重 29。

這兩部電影為LLM的記憶局限性提供了強大而直觀的類比，使一個復雜的技術問題變得易于理解。《記憶碎片》的主角無法形成新的長期記憶，《初戀50次》主角的記憶每天都會重置——兩者都是對LLM狀態限制的完美隱喻。

輕信（Gullibility），以及關于提示注入風險的警告

安全深度解讀：這指的是提示詞注入（prompt injection）漏洞，OWASP將其列為LLM應用面臨的頭號威脅 23。

○威脅模型：攻擊者將惡意指令嵌入到不受信任的數據中（例如，用戶評論、檢索到的網頁）。由于LLM無法區分可信指令和不可信數據，它可能會遵循惡意指令 23。

○防御機制：研究重點在于防御機制，如StruQ（結構化指令調優）和SecAlign（特殊偏好優化）。這些方法通過微調模型來忽略數據部分的指令，通常使用特殊的分隔符標記，并從用戶輸入中過濾掉這些標記 23。

此部分總結概括了LLM的雙重性：在某些方面（如知識回憶）超乎常人，但在其他方面（如可靠性、記憶、安全）則存在嚴重缺陷。這種心理畫像決定了可以構建何種類型的應用，以及需要采取何種保障措施。

04

新軟件時代的機會 （人工智能時代的戰略機遇）

本部分將卡帕西的理論框架轉化為具體的商業機會，重點關注應用程序和智能體的構建，這是演講中最長、最實用的部分，為清晰起見，分為三個小節進行分析。

4.1 部分自主應用的興起與“鋼鐵俠戰衣”

卡帕西主張，當前的戰略重點應該是構建“鋼鐵俠戰衣”（即增強人類能力的工具），而非追求“鋼鐵俠機器人”（即完全自主的系統） 。最直接的機會在于開發“部分自治應用”（partial autonomy apps），或稱“Copilot for X”類產品，它們旨在增強而非取代人類。

這類應用的核心用戶體驗模式是一個緊密的循環：AI負責生成方案，人類負責驗證。產品的成功取決于兩點：一是讓這個循環過程盡可能快速、便捷；二是將AI“拴在一條短繩上”，確保其生成的內容質量高且易于驗證。

產品分析：Cursor——程序員的“鋼鐵俠戰衣”

Cursor是一款AI原生的代碼編輯器，是Visual Studio Code的一個分支，專為AI輔助編程而設計。

Cursor的工作流程體現了“生成-驗證”循環：(1) 將當前狀態（代碼、文件、錯誤信息）打包到上下文窗口中；(2) 編排對LLM的調用以生成代碼修改建議；(3) 提供一個定制化的圖形界面（GUI），讓用戶可以方便地審查差異（diff）并一鍵接受或拒絕修改。

Cursor通過其功能設計體現了“自治滑塊”（autonomy slider）的概念。其自動化程度從簡單的代碼補全（按Tab鍵），到交互式聊天問答（Cmd+K），再到能夠執行多步驟任務的智能體模式（Cmd+L），為開發者提供了不同層次的AI輔助 。

產品分析：Perplexity AI——研究者的“鋼鐵俠戰-衣”

Perplexity是一款“對話式問答引擎”，它將LLM與實時網絡搜索相結合，旨在提供有來源可查的、準確的答案。

其工作流程是：(1) 接收用戶查詢；(2) 編排網絡搜索和LLM調用，對信息進行綜合處理；(3) 在一個定制化的GUI中呈現附有引用來源的答案，并提供建議的后續問題。這套流程是解決LLM幻覺問題的直接方案。

Perplexity的自治滑塊體現在其搜索模式上，用戶可以選擇從“快速搜索”到“深度研究”，從而控制AI在信息收集過程中的深度和廣度。

將“Copilot”或“Cursor for X”作為主要應用模式

詳細分解了Cursor AI代碼編輯器的界面及其核心組件 。

分解了Perplexity AI問答引擎的構成 。

公司

主要功能

最新估值

主要投資者

Hugging Face

AI社區/模型中心 ("AI界的GitHub")

45億美元 (2023年8月)

Google, Amazon, Nvidia, Salesforce

Perplexity AI

AI問答引擎

90億美元 (2024年12月)

IVP, Jeff Bezos, Nvidia, Databricks

Cursor

AI原生代碼編輯器

99億美元 (2025年6月)

Thrive, Accel, a16z, DST

xAI

基礎模型與基礎設施

私有 (馬斯克生態系統的一部分)

關鍵AI原生公司市場快照這張表格提供了具體的財務數據，證實了Karpathy關于新軟件時代機遇的論斷。它表明他所討論的概念并非理論，而已催生出估值巨大的公司，為報告的目標受眾清晰地描繪了當前的市場格局。

部分自主的普適性挑戰

Adobe Photoshop和Unreal Engine等復雜軟件的界面，并提問LLM如何能在其中“觀察”和“行動” 。

Karpathy將這一模式推廣開來。要構建一個“Photoshop的Copilot”，核心挑戰是相同的：如何給予AI感官輸入（看到畫布、圖層、工具）和運動控制（在其中執行操作）以及如何讓用戶保持在監督環路中？這定義了下一代軟件的工程任務。

人機協作的UI/UX循環

成功的部分自主應用的關鍵在于一個緊湊、快速的生成-驗證循環。AI生成一個建議，人類快速驗證它。為了實現這一點，AI的建議必須是小規模、增量式且易于理解的。nilenso的提示示例展示了一個“深思熟慮”的提示，它將AI限制在一個具體、可驗證的任務上，與寬泛、開放式的提示形成對比。這是構建可靠AI輔助工具的關鍵最佳實踐。

完全自主的“從演示到產品的鴻溝”

使用特斯拉Autopilot的“自主性滑塊”和自動駕駛汽車的漫長發展歷程來說明實現完全自主的難度。

一個演示（demo）是works.any()——它只需成功一次就足以令人印象深刻。而一個產品（product）是works.all()——它必須在所有邊緣情況下都可靠地工作。Karpathy借鑒他在特斯拉的經驗警告說，彌合這一鴻溝需要付出巨大的努力，尤其是在高可靠性至關重要的領域。這是對圍繞完全自主的炒作的一個重要警示。

4.2 智能體的十年：跨越“演示到產品”的鴻溝

卡帕西對“2025年是智能體元年”的說法提出了質疑 ，并給出了一個更為現實的預測：“2025到2035年是智能體的十年” 。

他引入了一個至關重要的概念：“演示到產品的鴻溝”。一個成功的演示（demo）意味著系統在某個時刻成功運行了一次（works.any()），而一個成熟的產品則要求系統在所有情況下都能可靠地運行（works.all()） 。對于可靠性至關重要的自治系統而言，這條鴻溝尤為巨大。

歷史的鏡鑒：自動駕駛（特斯拉 vs. Waymo）

卡帕西用2015至2025年這“駕駛智能體的十年”作為前車之鑒 。

●Waymo：代表了追求works.all()的路徑。自2009年（作為谷歌項目）成立以來，Waymo專注于深度研發、定制硬件（激光雷達、雷達、攝像頭），并在有限的地理區域內（地理圍欄）實現完全無監督的自動駕駛 40。其商業模式是成為“Waymo司機”——一個可授權的自動駕駛系統供應商。

●特斯拉：代表了從works.any()到works.all()的迭代路徑。其Autopilot和FSD（受監督）系統是駕駛輔助功能，依賴純視覺方案（軟件2.0），并進行廣泛部署以收集數據，通過數據驅動的方式不斷改進系統 6。這恰好反映了卡帕西所倡導的“部分自治”或“鋼鐵俠戰衣”的哲學。

特斯拉與Waymo的對比，為整個智能體市場提供了兩種發展路徑的范本。一些公司將效仿Waymo，致力于為狹窄但高價值的場景構建高度可靠的全自動智能體（例如，一個能完全自動化特定財務審計流程的智能體）。另一些公司則將遵循特斯拉的模式，構建“副駕駛”和“助手”，在廣泛的任務中增強人類能力，并隨著時間的推移逐步提高其自主性。卡帕西對“部分自治”的強調表明，他認為后一種模式對于初創公司而言是更具可行性的近期戰略。

能體的十年——增強先行

○AI投資的“鋼鐵俠”理論：

1. 首先，演講確立了“部分自主”（增強）是當前最直接、最切實的機遇，并以Cursor和Perplexity數十億美元的估值作為市場證據。這就是“鋼鐵俠戰衣”模式。

2. 接著，演講明確警告了完全自主（“代理”）的巨大困難，引用了“從演示到產品的鴻溝”和自動駕駛的漫長發展時間線。這就是“鋼鐵俠機器人”模式。

3. 外部研究也證實了構建可靠企業級代理面臨的巨大挑戰：集成復雜性、安全性、上下文管理以及成熟工具的缺乏 35。

4. 綜合以上幾點，可以得出一個戰略路線圖：在短期到中期內，最穩妥且最有利可圖的路徑是構建“鋼鐵俠戰衣”——即增強人類能力的工具。而開發完全自主的“鋼鐵俠機器人”則是一項更長期、風險更高的研發任務。這個框架有助于區分近期的產品戰略和長期的研究愿景。

4.3 氛圍感編程（Vibe Coding）：創造的民主化與風險

卡帕西引入了“氛圍感編程”這一新概念，它描述了一種全新的創造方式：創造者“忘記代碼的存在”，僅通過高層次的、對話式的指令來引導LLM，并且常常不經審查就接受其生成的代碼 。

●民主化：這種方式極大地降低了創造的技術門檻，使得非技術背景的用戶甚至兒童都能構建功能性的應用程序。演講中展示的MenuGen應用 和關于9-13歲兒童編程活動的推文 都是力證。

●隱藏的復雜性：然而，卡帕西在關于構建MenuGen的博客文章中揭示了一個關鍵點：“代碼是最簡單的部分！” 。真正的挑戰在于那些傳統的“軟件1.0”任務：管理API密鑰、部署（Vercel）、域名、支付等。演講中關于使用Clerk添加谷歌登錄的例子 完美地詮釋了這一點——這是一個漫長的、手動的過程，需要在不同的儀表盤之間點擊和復制密鑰，而這些任務目前還難以通過“氛圍感編程”來自動化。

通過Karpathy的推文、一個模擬的維基百科條目以及兒童使用它的例子來定義“Vibe Coding”。

“Vibe Coding”是指通過自然語言向LLM描述期望的結果來構建軟件，引導和完善AI生成的代碼，而無需完全理解每一行代碼。Karpathy在2025年2月創造了這個詞 3。它代表了軟件開發的終極民主化，使非專家也能構建真實的應用。

如果“氛圍感編程”讓編寫核心邏輯變得輕而易舉，那么新的瓶頸就轉移到了其他所有環節：基礎設施、部署、認證、支付等。這為那些提供簡單、近乎“無代碼”解決方案的公司創造了巨大的市場機會。Clerk、Vercel和Stripe等公司正處于這個風口。對許多人來說，未來的開發模式可能是在一個強大且易于使用的托管服務框架之上，通過“氛圍感編程”來構建核心業務邏輯。“氛圍感編程”并沒有消除復雜性，它只是將復雜性從代碼本身轉移到了基礎設施層面。

案例研究——MenuGen

它通過拍攝菜單照片并為每個菜品生成圖片來可視化菜單。并指出“代碼是最簡單的部分！”，并列出了真正的挑戰。

結合Karpathy博客的深度解讀：Karpathy的博客文章《Vibe coding MenuGen》41 提供了他構建一個真實世界應用時“痛苦跋涉”的第一手資料。

■“簡單”的部分：本地原型很快就創建好了。

■“困難”的部分（集成噩夢）：大部分工作不是編碼，而是在“瀏覽器里點點點”：

■API：處理來自OpenAI和Replicate的速率限制、廢棄的端點和令人困惑的文檔。

■部署 (Vercel)：調試只在Vercel服務器上出現的構建錯誤，以及管理環境變量。

■認證 (Clerk)：為生產環境進行復雜的設置，包括自定義域名和與Google Cloud的OAuth配置 42。

■支付 (Stripe)：集成另一項服務，管理更多的密鑰，并讓LLM修復其自身實現中的一個關鍵設計缺陷。

集成的痛苦——谷歌登錄展示了通過Clerk添加谷歌登錄的復雜、多步驟的文檔截圖 。

○“膠水層”作為下一個重大機遇：

1. Karpathy的論點是LLM（軟件3.0）是一種新的、強大的編程范式。

2. 他的“Vibe Coding”經歷表明，雖然核心的生成（“做什么”）變得容易，但集成各種不同的服務——即“膠水”——卻極其困難和令人沮喪
。

3. 他所使用的服務（Vercel、Clerk、Stripe）本身都是現代化的、對開發者友好的平臺。復雜性源于它們之間的交互。

4. 由此可以推斷：實現“Vibe Coding”和AI驅動開發全部潛力的主要瓶頸，并非LLM本身，而是由API、認證和部署構成的脆弱、復雜的“膠水層”。這意味著，能夠抽象掉這種集成復雜性、創建從“想法到部署應用”的無縫管道的平臺或工具，存在著巨大的市場機會。解決這個“膠水”問題的公司將釋放巨大的價值。

05構建智能體優先世界的基礎設施

這一部分展望未來，概述了支持一個以AI智能體為主要參與者的世界所需的基礎設施。

5.1 一類新的用戶：為AI智能體而設計卡帕西提出了一個深刻的觀點：數字信息的消費者/操縱者出現了第三個類別。前兩類是（1）人類（使用GUI）和（2）計算機（使用API），而現在新增了（3）智能體——一種行為類似人類的計算機 。這意味著，未來的網絡和軟件必須為這第三類用戶進行設計。

5.2 標準化智能體交互：協議與可操作API● 可讀性（Readability）- llms.txt： ○ 概念：由杰里米·霍華德（Jeremy Howard）提出的一個類似于robots.txt的文件規范 50。 ○ 功能：與robots.txt告訴機器人不要爬取什么不同，llms.txt提供一個經過精心策劃的、對LLM友好的Markdown格式的網站內容摘要，引導智能體關注最重要的信息 。這使得網站的知識能被智能體“閱讀”。

信息的三種消費者引入為代理而構建的想法，并列出了數字信息的三種消費者：人類（GUI）、計算機（API）和新的類別——代理（類人計算機）。

這是設計思維的根本性轉變。幾十年來，我們為人類的眼睛（GUI）或機器的解析器（API）設計界面。現在，我們需要為第三類消費者設計：AI代理，它們以一種介于兩者之間的方式消費信息。

● 可操作性（Actionability）- 模型上下文協議（MCP）： ○ 概念：一個為LLM提供工具的開放協議 53。 ○ 功能：像Stripe這樣的公司正在實施MCP服務器 ，將其API暴露為一組智能體可以調用的“工具”。Vercel在其文檔中添加cURL命令也是出于同樣的目的 。這使得一項服務能被智能體“操作”。

以人為中心 vs. 以智能體為中心的網絡協議

下表清晰地展示了從一個純人類使用的網絡向一個人機共存、智能體感知的網絡范式的轉變。

協議

目標“用戶”

目的

類比

robots.txt

網絡爬蟲（計算機）

控制/限制訪問

“禁止入內”標志

HTML/GUI

人類

展示/交互

“商店櫥窗”

llms.txt

LLM智能體

引導/提供知識

“精心準備的歡迎禮包”

MCP/可操作API

LLM智能體

賦能行動/工具使用

“配備工具的服務臺”

llms.txt——AI的robots.txt

■ 由Answer.AI的Jeremy Howard于2024年9月提出，llms.txt是一個為網站內容提供干凈、Markdown格式、LLM友好版本的標準 44。

■ 它類似于robots.txt或站點地圖，但不僅僅是控制訪問，而是為AI代理提供一個權威的、易于解析的真實來源，剝離了復雜的HTML、CSS和JavaScript。

實踐中的llms.txt展示了面向人類的文檔（Vercel、Clerk）和它們對應的面向LLM的llms.txt或.md版本（Vercel、Stripe）。

市場采納：這不僅僅是一個提案，主流科技公司正在采納它。Vercel和Stripe現在都提供其文檔的機器可讀版本 46。這表明業界已經認識到“為代理而構建”的必要性。

為代理設計的動作——從點擊到cURL

將Manim（一個基于代碼的動畫引擎）作為機器可讀格式的例子（第65頁），并展示了Vercel在其文檔中用cURL命令替代了之前的“點擊”說明（第66頁）。幻燈片還介紹了Stripe的模型上下文協議（Model Context Protocol, MCP）。

■cURL命令：這是一個簡單但意義深遠的轉變。提供API命令（cURL）而非人類指令（“點擊”），使得文檔能被代理直接執行。

■模型上下文協議 (MCP)：這是一個更高級的標準。MCP是一個開放協議，用于標準化應用程序向LLM提供上下文和工具的方式 48。Stripe的MCP服務器允許AI代理（如Cursor中的代理）被賦予一套工具，以結構化的方式直接調用Stripe API并搜索其知識庫 46。它是一個正式的“代理API”。

5.3 自動化上下文構建：“攝取”層

●問題所在：要讓一個智能體處理復雜任務（例如，重構一個代碼庫），必須將整個項目的狀態“打包到上下文窗口中” 。手動完成這項工作非常繁瑣。

●解決方案：上下文構建器：一類新的工具正在涌現以自動化此過程。

○Gitingest：該工具能攝取一個GitHub倉庫，并輸出一個對提示詞友好的文本摘要，包括文件結構和內容，為LLM做好準備 。

○Devin的DeepWiki：該工具更進一步，不僅攝取代碼，還能生成高層次的文檔和系統架構圖，幫助智能體（或人類）理解代碼庫的宏觀結構 。

上下文構建器——Gitingest和DeepWiki

展示了兩款能自動將整個GitHub倉庫準備成LLM上下文的工具 。

■Gitingest：一個能抓取整個Git倉庫并將其文件結構和內容打包成一個巨大文本文件的工具，非常適合粘貼到具有大上下文窗口的LLM中（如Gemini 2.0 Pro）49。它大規模地解決了代碼的“上下文打包”問題。

■DeepWiki：一個來自Cognition AI（Devin的創造者）的更高級的工具，它超越了簡單的文本連接。它能分析一個公共GitHub倉庫，并自動生成文檔、架構圖和一個交互式問答界面 51。它為人類和AI都創建了一個關于代碼庫的結構化、語義化的理解。

在軟件2.0時代，編譯器將人類可讀的源代碼轉換為機器可執行的代碼。在軟件3.0的世界里，這些“上下文構建器”扮演了一種新型編譯器的角色。它們接收一個復雜的、結構化的產物（如一個Git倉庫），并將其“編譯”成一種新的“CPU”（即LLM）能夠理解和處理的格式（即上下文窗口中的提示詞）。這是智能體基礎設施中一個至關重要但目前服務尚不完善的環節。

本文最后對卡帕西的愿景進行綜合總結。范式轉變的回顧：從軟件1.0到3.0的旅程，不僅是一次技術變革，更是一場關于軟件如何被創造、由誰創造以及其本質構成的根本性重構。雙軌并行的未來：卡帕西為未來指明了兩條并行的發展道路：1.應用層：構建“鋼鐵俠戰衣”式的產品，提供部分自治能力，務實地解決當今用戶的真實問題，并謹慎地跨越“演示到產品”的鴻溝。2.基礎設施層：為智能體優先的世界打造“鐵鍬和鎬頭”——即支撐下一個十年發展的協議（llms.txt, MCP）、上下文構建器（Gitingest）以及簡化的外圍服務（Clerk, Vercel）。

一個名為“Operator”的產品的截圖，這是一個可以使用自己的瀏覽器來為用戶執行任務的代理 。

這是一個前瞻性的例子，展示了該領域的發展方向：更自主的代理，能夠與現有的網絡（為人類構建的GUI世界）進行交互。這彌合了“LLM操作系統”與龐大的人類中心界面遺產之間的鴻溝。

完整愿景——統一示意圖 一張綜合性圖表，將所有主要概念聯系在一起：位于中心的LLM OS、三種軟件范式、人機交互循環，以及“為代理而構建”的需求。

Andrej Karpathy的演講展現了卓越的戰略遠見。他為當前AI熱潮的混亂局面提供了一個連貫的心智模型，并規劃出一條清晰、可行的路線圖。文章認為，最大的機遇不僅在于構建下一個華而不實的智能體演示，更在于建設那些能夠讓“智能體的十年”成為現實的、強大的、可靠的、標準化的基礎設施。這場轉型過程將是復雜的，LLM的“心理”缺陷仍將是關鍵挑戰，但發展軌跡已然明確：軟件正在再次改變，而那些深刻理解這個新“操作系統”的建設者，將定義下一個科技時代。

基于對Andrej Karpathy演講的全面分析，為不同角色的利益相關者提供以下戰略建議：

●對于開發者：

○角色轉變：應將重心從編寫底層邏輯轉向成為“系統架構師”和“AI編排者”。熟練掌握提示工程、上下文管理以及“給AI套上韁繩”的藝術至關重要。

○掌握“膠水層”：學習如何使用和集成各種服務（部署、認證、支付等）將成為核心競爭力。

●對于企業領導者：

○平臺思維：認識到AI不僅是另一個工具，而是一個全新的計算平臺。應優先構建能夠增強員工能力的“鋼鐵俠戰衣”式應用，以實現立竿見影的投資回報。

○數據與接口準備：投資于數據質量，并開始通過采納llms.txt等標準和開發內部API，使內部系統和文檔“為代理做好準備”。

●對于投資者：

○關注應用層：最大的機會可能不在于構建下一個基礎模型（“晶圓廠”業務），而在于其上的各個層面。

○尋找價值所在：應尋找那些正在構建卓越“鋼鐵俠戰衣”（特定垂直領域的Copilot）、創造“AI的GUI”，或者——最關鍵地——通過簡化AI與現實世界產品集成的復雜性來解決“膠水層”問題的公司。Cursor和Perplexity的估值表明這已經發生。Karpathy的“Vibe Coding”經歷揭示了當前最大的痛點，也因此指向了最巨大的機遇。

1. Andrej Karpathy | Keynote Speaker - AAE Speakers Bureau, accessed June 20, 2025, https://www.aaespeakers.com/keynote-speakers/andrej-karpathy

2. Andrej Karpathy - Artificial Intelligence, accessed June 20, 2025, https://schneppat.com/andrej-karpathy.html

3. Andrej Karpathy - Wikipedia, accessed June 20, 2025, https://en.wikipedia.org/wiki/Andrej_Karpathy

4. Andrej Karpathy Academic Website - Stanford Computer Science, accessed June 20, 2025, https://cs.stanford.edu/people/karpathy/

5. Andrej Karpathy is starting Eureka Labs, an "AI Native School" - Community, accessed June 20, 2025, https://community.openai.com/t/andrej-karpathy-is-starting-eureka-labs-an-ai-native-school/870047

6. Scale AI: Accelerate the Development of AI Applications, accessed June 20, 2025, https://scale.com/

7. Software in the era of AI.pdf

8. Software 2.0 is one of 10 most important trends wh... - Databricks Community, accessed June 20, 2025, https://community.databricks.com/t5/data-engineering/software-2-0-is-one-of-10-most-important-trends-which-will-shape/td-p/25344

9. Software 2.0: An Emerging Era of Automatic Code Generation - The Softtek Blog, accessed June 20, 2025, https://blog.softtek.com/en/software-2.0-an-emerging-era-of-automatic-code-generation

10. Software 2.0 - Breakfast Bytes - Cadence Blogs, accessed June 20, 2025, https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/software-2-0

11. #72: Software 2.0 in the Enterprise – Celebrating the learning and curious mindset, accessed June 20, 2025, https://thinklikesocrates.com/2022/11/27/software-2-0-in-the-enterprise/

12. [N] Software 2.0 - Andrej Karpathy : r/MachineLearning - Reddit, accessed June 20, 2025, https://www.reddit.com/r/MachineLearning/comments/7cdov2/n_software_20_andrej_karpathy/

13. HuggingFace Statistics – Originality.AI, accessed June 20, 2025, https://originality.ai/blog/huggingface-statistics

14. Sell or Invest in Hugging Face Stock Pre-IPO | 1% Fee on Trades - Nasdaq Private Market, accessed June 20, 2025, https://www.nasdaqprivatemarket.com/company/hugging-face/

15. Attention is all you need: Discovering the Transformer paper | Towards Data Science, accessed June 20, 2025, https://towardsdatascience.com/attention-is-all-you-need-discovering-the-transformer-paper-73e5ff5e0634/

16. How Transformers Work: A Detailed Exploration of Transformer Architecture - DataCamp, accessed June 20, 2025, https://www.datacamp.com/tutorial/how-transformers-work

17. Attention is all you need: Discovering the Transformer paper ..., accessed June 20, 2025, https://towardsdatascience.com/attention-is-all-you-need-discovering-the-transformer-paper-73e5ff5e0634

18. Building the Software 2.0 Stack by Andrej Karpathy [video] - Hacker News, accessed June 20, 2025, https://news.ycombinator.com/item?id=17280454

19. Artificial intelligence (AI)—An Inflection Point In the Global History and its Significance For a National Strategy, accessed June 20, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC6785349/

20. Andrew Ng: Why AI Is the New Electricity | Stanford Graduate School ..., accessed June 20, 2025, https://www.gsb.stanford.edu/insights/andrew-ng-why-ai-new-electricity

21. AI Cheat Sheet: Large Language Foundation Model Training Costs, accessed June 20, 2025, https://www.pymnts.com/artificial-intelligence-2/2025/ai-cheat-sheet-large-language-foundation-model-training-costs/

22. NAACP files intent to sue Elon Musk's xAI company over Memphis ..., accessed June 20, 2025, https://www.pbs.org/newshour/nation/naacp-files-intent-to-sue-elon-musks-xai-company-over-memphis-supercomputer-air-pollution

23. Defending against Prompt Injection with Structured Queries (StruQ ..., accessed June 20, 2025, https://bair.berkeley.edu/blog/2025/04/11/prompt-injection-defense/

24. Apple unveils new Mac Studio, the most powerful Mac ever - Apple, accessed June 20, 2025, https://www.apple.com/newsroom/2025/03/apple-unveils-new-mac-studio-the-most-powerful-mac-ever/

25. Profiling Apple Silicon Performance for ML Training - arXiv, accessed June 20, 2025, https://arxiv.org/pdf/2501.14925

26. What is mixture of experts? | IBM, accessed June 20, 2025, https://www.ibm.com/think/topics/mixture-of-experts

27. What is Mixture of Experts (MoE)? How it Works and Use Cases - Zilliz Learn, accessed June 20, 2025, https://zilliz.com/learn/what-is-mixture-of-experts

28. Blog | karpathy, accessed June 20, 2025, https://karpathy.bearblog.dev/blog/

29. Sculpting subspaces: How we solved continual learning in LLMs ..., accessed June 20, 2025, https://developers.redhat.com/articles/2025/04/04/sculpting-subspaces-how-we-solved-continual-learning-llms

30. [2502.14802] From RAG to Memory: Non-Parametric Continual Learning for Large Language Models - arXiv, accessed June 20, 2025, https://arxiv.org/abs/2502.14802

31. www.cursor.com, accessed June 20, 2025, https://www.cursor.com/blog/series-c#:~:text=Series%20C%20and%20Scale%20%7C%20Cursor%20%2D%20The%20AI%20Code%20Editor&text=We've%20raised%20%24900m,frontier%20of%20AI%20coding%20research.&text=Today%2C%20we're%20announcing%20new,%2C%20Andressen%20Horowitz%2C%20and%20DST.

32. Series C and Scale | Cursor - The AI Code Editor, accessed June 20, 2025, https://www.cursor.com/blog/series-c

33. Perplexity AI Statistics And Facts (2025) - Electro IQ -, accessed June 20, 2025, https://electroiq.com/stats/perplexity-ai-statistics/

34. Perplexity AI - Wikipedia, accessed June 20, 2025, https://en.wikipedia.org/wiki/Perplexity_AI

35. Building AI agents: 5 common hurdles and fixes - Cohere, accessed June 20, 2025, https://cohere.com/blog/building-ai-agents

36. New Research Uncovers Top Challenges in Enterprise AI Agent Adoption, accessed June 20, 2025, https://www.architectureandgovernance.com/artificial-intelligence/new-research-uncovers-top-challenges-in-enterprise-ai-agent-adoption/

37. Why Your Enterprise Isn't Ready for Agentic AI Workflows - Gigster, accessed June 20, 2025, https://gigster.com/blog/why-your-enterprise-isnt-ready-for-agentic-ai-workflows/

38. Overcoming the Hurdles: Common Challenges in AI Agent Integration (& Solutions) - Knit, accessed June 20, 2025, https://www.getknit.dev/blog/overcoming-the-hurdles-common-challenges-in-ai-agent-integration-solutions

39. AI Agent Development: 5 Key Challenges and Smart Solutions - Softude, accessed June 20, 2025, https://www.softude.com/blog/ai-agent-development-some-common-challenges-and-practical-solutions

40. Developers building AI agents - what are your biggest challenges? : r/AI_Agents - Reddit, accessed June 20, 2025, https://www.reddit.com/r/AI_Agents/comments/1kf4qgx/developers_building_ai_agents_what_are_your/

41. Vibe coding MenuGen | karpathy, accessed June 20, 2025, https://karpathy.bearblog.dev/vibe-coding-menugen/

42. Welcome to Clerk Docs, accessed June 20, 2025, https://clerk.com/docs

43. Clerk Authentication - Introduction | Devias Kit Pro Docs, accessed June 20, 2025, https://material-kit-pro-react-docs.devias.io/clerk-authentication

44. Mastering llms.txt: Your Essential Guide to GenAI-Optimized Website ..., accessed June 20, 2025, https://wordlift.io/blog/en/mastering-llms-txt-for-genai-optimized-indexing/

45. Meet LLMs.txt, a proposed standard for AI website content crawling - Search Engine Land, accessed June 20, 2025, https://searchengineland.com/llms-txt-proposed-standard-453676

46. Build on Stripe with LLMs | Stripe Documentation, accessed June 20, 2025, https://docs.stripe.com/building-with-llms

47. How we're adapting SEO for LLMs and AI search - Vercel, accessed June 20, 2025, https://vercel.com/blog/how-were-adapting-seo-for-llms-and-ai-search

48. Model Context Protocol (MCP) - Anthropic API, accessed June 20, 2025, https://docs.anthropic.com/en/docs/mcp

49. The power of large context windows for your documentation efforts, accessed June 20, 2025, https://glaforge.dev/posts/2025/02/15/the-power-of-large-context-windows-for-your-documentation-efforts/

50. GitIngest - Turn any Git repo to a LLM-friendly prompt - Chrome Web ..., accessed June 20, 2025, https://chromewebstore.google.com/detail/gitingest-turn-any-git-re/adfjahbijlkjfoicpjkhjicpjpjfaood

51. DeepWiki - Devin Docs, accessed June 20, 2025, https://docs.devin.ai/work-with-devin/deepwiki

52. DeepWiki: Your AI-Powered Guide to GitHub Repositories - Apidog, accessed June 20, 2025, https://apidog.com/blog/deepwiki/

【AI技術與應用交流群｜僅限受邀加入】

AI算力領域TOP級從業者專屬圈層

√ 與頭部算力企業深度對話

√ 與AI上下游企業深度對話

√ 獲取一手全球AI與算力產業信息

√ 獲取AI熱點及前沿產業獨家信息

√ 隨時了解全球AI領域高管最新觀點及實錄全文

√ 有機會參與AI主題產業交流活動

掃碼驗證身份（需備注姓名/公司/職務）

不止有 DeepSeek，更有 AI產業的未來！

| 文章來源：數字開物

? END?

【專欄】精品再讀