# Cursor 團隊：AI 時代的程式設計未來 > AI 程式設計工具 Cursor 的團隊談程式碼模型的訓練思路、開發者工作流的變化與程式設計的未來。 - 原標題：#447 – Cursor Team: Future of Programming with AI - 期數：第 447 期 - 釋出日期：2024-10-06 - 嘉賓 / 主題：Cursor 團隊 - 網頁版：https://lex.qiaomu.ai/tw/ep/cursor-team/ - 官方頁面：https://lexfridman.com/cursor-team/ - 精讀字數：約 19362 字（閱讀約 43 分鐘） > 本文為 lex.qiaomu.ai 基於原始訪談的 AI 改寫中文精讀，非官方翻譯；引用請註明出處並連結網頁版。 Cursor 內部有個說法，來自聯合創始人 Sualeh 後來的一次覆盤：2022 年 6 月，團隊裡有人打了個賭，賭 2024 年 6 月或 7 月，大模型能不能在 IMO（國際數學奧林匹克）上拿到金牌。Sualeh 本人是競賽選手，清楚這道題的分量，他當時的第一反應是「Aman 瘋了」。兩年後 DeepMind 的系統離金牌線只差一分。 這個賭局被當成了飯後談資，它幾乎定義了 Cursor 存在的前提。如果模型能力能這樣陡峭地爬升，那所有圍繞「程式設計師怎麼工作」的產品設計，都得在一個更激進的時間尺度上重做。 這期播客是 Cursor 四位創始人 Michael Truell、Aman Sanger、Sualeh Asif、Arvid Lunnemark 第一次集體出鏡，聊了將近兩個半小時。表面上是聊一個程式碼編輯器，往下挖，聊的是程式設計這件事本身會長成什麼形狀。 ## 程式碼編輯器到底是什麼 Lex 開場問了一個看起來很傻的問題：程式碼編輯器的意義是什麼？ Michael 的回答是，傳統上編輯器是程式設計師「用正式程式語言做文字編輯」的地方。對不寫程式碼的人，可以理解成一個為程式設計師做的、超級強化版的 Word。強化的理由很單純：程式碼有結構。正因為有結構，編輯器能替人做的事遠比普通文書處理器多。 從關鍵詞的語法高亮讓你能快速掃讀，到像瀏覽網頁超連結一樣在程式碼庫裡跳轉定義，再到錯誤檢查抓一些低階 bug，這些都是編輯器在「結構」上做文章。Michael 補了一句關鍵的話：**未來十年，程式碼編輯器是什麼，會發生很大變化**，因為「造軟體」這件事本身會變得不太一樣。 Arvid 補了一個常被低估的維度：編輯器得好玩。 > 很多我們做出來的東西，試完就扔了，因為它不好玩。而好玩很大一部分來自快。快就是好玩。（Arvid Lunnemark） 這句「Fast is fun」後來幾乎成了 Cursor 所有工程決策的隱形指揮棒。後面聊到的 KV cache、投機解碼、影子工作區，本質上都在服務這一條。 ## 從 Vim 到 VS Code，再到一個瘋狂的念頭 Cursor 四個人早期全是 Vim 使用者，純 Vim 加終端，連 Neovim 都不碰。轉折發生在 2021 年 Copilot 出來的時候。Aman 說他想試試 Copilot，而當時唯一能用的編輯器是 VS Code，結果一進去就再沒出來。 Lex 給 Copilot 的體驗做了個精妙類比：像一段親密友誼裡，朋友能替你把話說完。說得準的時候，那種「他懂我」的感覺會上癮；說得不準的時候，你就得手動刪掉重打。Arvid 補充了一個被忽略的細節：Copilot 即使錯了也不致命，因為你只要再敲一個字元，提示就會重新生成，錯一次的代價幾乎為零。 Sualeh 說，Copilot 真正的歷史意義在於，**它是第一個真正意義上的 AI 消費級產品**。在它之前，語言模型一直待在論文和 demo 裡。 但團隊的野心不止於自動補全。2020 年 OpenAI 的 scaling law 論文出來後，Michael 說那是一個「即使沒有新想法，只要加算力和資料就能變好」的時刻。真正讓所有事情閉合的，是 2022 年底拿到 GPT-4 的早期許可權。之前他們做過一些很具體的工具，比如給金融從業者在 Jupyter Notebook 裡用的小工具，也試過用模型做靜態分析。 GPT-4 的能力躍升讓他們看清了兩件事。第一，之前理論上預測的收益變成了現實。第二，整個程式設計流程都要穿過這些模型，給某一步加個 AI 助手不夠用。他們的判斷是要重做一個程式設計環境，給老環境打補丁這條路走不通。 ## 為什麼非要 fork VS Code 這個問題很多人問過。市面上已經有 Copilot 這樣的外掛，為什麼 Cursor 要重做一個編輯器？ Michael 的回答很直接：如果你只是現有編輯器的一個外掛，你能控制的就非常有限。而 Cursor 團隊的判斷是，模型會持續變強，程式設計方式會被徹底改寫，這時候被外掛的框架限制住，等於自斷手腳。他們想要的是「能做出最有用的東西」的自由度。 Aman 補了一個更深的行業觀察，這也能解釋為什麼 Cursor 敢和微軟正面競爭： > 過去的技術浪潮，往往是一個大東西出現，解鎖一批公司。但 AI 程式設計不一樣，每一年、每一次模型能力的躍遷，都會解鎖一批新特性。在 AI 程式設計裡，領先幾個月，甚至領先一年，產品就會好用得多。（Aman Sanger） 他把這個講得更狠：**一年後的 Cursor，必須讓今天的 Cursor 顯得過時**。一家創業公司如果不能自我作廢，就會被別人作廢。他評價微軟做了很多了不起的事，但不認為他們處在一個能持續做研究和實驗、把天花板往上頂的位置。 Sualeh 從另一個角度解釋了這個決策：「我們其實是做給自己用的。」當年用 Copilot 時，他能看到模型在變強，但 Copilot 的體驗幾個月都沒什麼變化。他當時的感受是：**天花板在往上抬，你們為什麼不做新東西？alpha 功能在哪裡？**一個賣得很好、卻沒有新東西的產品，對想要探索的人來說很難受。 Arvid 補了一個組織層面的關鍵點：Cursor 把「做 UI 的人」和「訓模型的人」放在同一間屋子裡，有時候乾脆是同一個人。「這樣你能做出一些，如果大家不交流、不做實驗就根本做不出來的東西。」 ## Tab：把「下一步」整個預測出來 Cursor 目前最被稱道的能力，圈內人叫它 Tab。Michael 把 Cursor 現在做得好歸納成兩件事： 第一，像同事一樣從你肩膀後面探頭，比你更快一步地猜出你下一步要做什麼。字元級別的補全只是這個想法的低配版，**Cursor 預測的粒度是整個下一次改動，是你下一處要跳過去的地方。** 第二，反過來，讓你跳到 AI 前面去，用指令驅動程式碼生成。 Sualeh 講了 Tab 這個想法怎麼來的。他們最初只是想讓模型能替人改程式碼，試了很多次才等到一個真正會改程式碼的模型。後來發現，一旦接受了一處改動，下一步該去哪兒其實是「明擺著的」。如果你是個 Vim 使用者，按 18JJ 就能往下走 18 行，但為什麼要人自己數？ > 所以想法是：你按一下 Tab，它跳到 18 行下面，給你看下一處改動，你再按 Tab。內部當時有個競賽，看我們能讓人按多少次 Tab。（Sualeh Asif） 他接著把這套想法抽象成一個更漂亮的概念：「零熵編輯」。當你已經表達了意圖，剩下的操作裡其實沒有新資訊了，但你還是得敲一堆字元讓電腦「理解」你在想什麼。**那模型就應該直接讀懂你的心思，把所有零熵的操作都 tab 掉。** Aman 從模型角度補了資料依據：程式碼的 bits per byte（按位元組歸一化的損失）比自然語言更低，意思是程式碼裡大量 token 是高度可預測的。而當你預測的物件從「補全程式碼」換成「人在編輯已有程式碼時下一步做什麼」，可預測性還會再被放大一個量級。Cursor Tab 的目標，就是**消滅編輯器裡所有低熵的動作，在意圖已經確定的地方，把你直接推到未來。** 這套東西技術上怎麼做？Aman 講了兩個關鍵點。 第一，這類任務需要極低延遲，所以得用專門訓練的小模型。它的特徵是「prefill token 消耗巨大，生成長度極小」，也就是要吃進大量上下文卻沒幾個輸出。這種負載形態跟稀疏模型天然契合，所以他們用了 MoE（Mixture of Experts）架構，在長上下文下效能提升明顯。 第二，他們做了一個叫 speculative edits（投機編輯）的東西，是投機解碼（speculative decoding）的變體。區別在於，投機解碼通常用小模型去起草、大模型來驗證；而程式碼編輯有一個天然的先驗：**你正在編輯的那段程式碼，本身就是最準的「草稿」**。 做法很樸素也很聰明：把原始程式碼塊直接喂回模型，模型絕大部分時候會同意「這段我照抄回去」。於是這些行可以並行處理。一直走到某一行模型開始不同意，真的生成新 token，再等匹配了足夠多之後重新投機。 Sualeh 提了一個 UI 上的額外好處：因為是流式輸出，人可以邊看邊審，不用盯著一個載入動畫乾等。 ## 那個被所有人低估的驗證問題 聊到一半，Lex 提到 Cursor 體驗裡的 diff 介面：紅綠對比，接受改動。他感嘆這背後的 UX 設計工程問題相當大。 Sualeh 講了他們為了這個介面推翻了多少版。最早是類似 Google Docs 的刪除線加上新程式碼並排顯示，太亂。後來試過「按住 Option 鍵才展示 AI 建議」的互動，藍色高亮提示這裡有建議，你按住 Option 才看到新程式碼，鬆開回到原文。這個設計思路本身是合理的，但 Lex 一針見血：**你首先得知道要按 Option。** Arvid 把這背後的本質挑了出來，叫它「驗證問題」： > 這些 diff 對小改動很好用。但一旦改動很大，或者涉及多個檔案，逐行審 diff 就變得很不人道了。（Arvid Lunnemark） 他提了兩個方向。一是把 diff 拆成「高資訊」和「低熵」兩類，重要的高亮出來，重複的灰掉。二是讓模型先看 diff，預判哪裡有 bug，用紅色波浪線標出來，告訴你「這段重點看」。他補了一句關鍵判斷：**當前的 diff 演算法只是普通演算法，設計裡有人類智慧，但執行時沒有智慧。** Aman 從產品層面說得更狠：程式碼審查這個互動，本來就是為「人給人 review」設計的。當程式碼的生產者是模型，你不需要照顧「作者」的體驗，可以完全圍繞審閱者重新設計。**而現在這種「把 AI 產出硬套成 PR」的做法，恰恰是想象力不足。** Arvid 還提了一個被忽略的細節：順序。真實的程式碼審查裡，你從上往下翻檔案列表，但邏輯上的正確閱讀順序其實不一樣。**讓模型來告訴你該先讀哪塊、再讀哪塊，這才是模型應該做的事。** Sualeh 把這個問題推到了更遠處： > 模型會變強，能提出的改動會越來越大。改動越大，人要做驗證的工作就越多，你就越得幫人減負。我不想把時間全花在審程式碼上。（Sualeh Asif） ## 一堆自研模型疊起來的東西 Lex 聊到這兒說了一句很準的話：這個編輯器裡跑著一堆機器學習。 Aman 講了其中的結構。Cursor 的工作方式是一套自研模型和前沿模型的「合奏」。前沿模型負責推理密集的部分，自研模型補它做不好的部分。有兩個典型例子。 第一是 Cursor Tab，前面講過，在特定任務上，專門的模型可以打贏前沿模型。 第二是 Apply。這個功能很少被外行注意，但它撐起了 Cursor 體驗的關鍵一環。前沿模型很擅長勾畫程式碼改動的草圖，但一到「生成精確的 diff」就開始翻車。Aman 說得很直白： > 你拿 Sonnet、o1，任何前沿模型去幹這事，它都會在特別蠢的地方搞砸，比如在大檔案裡數錯行號。（Aman Sanger） Sualeh 補刀：「跟很多人想的不一樣，靠確定性演算法根本解不了這個問題。」 聽到這裡能感到那個反差：把「建議」和「原文」合成一份精確的 diff，對人來說是幾乎不費吹灰之力的動作，對模型卻是硬骨頭。Cursor 的解法是讓模型先畫一個很粗的草圖，再訓練專門模型去把草圖落到檔案裡。Aman 說外面有些粗糙的模仿品，想用確定性匹配硬解，結果至少 40% 的時候會崩，產品體驗直接毀掉。 更妙的是，**Apply 還帶來了省錢和提速的副產品**。因為它讓最貴的推理模型只需要輸出極小規模的草圖，後面的實現交給更輕的模型去落地。Aman 判斷這個趨勢會繼續：越來越聰明的模型做規劃，實現細節交給次要的模型去做。o1 這種級別的模型只出一個高層計劃，被下級模型遞迴應用。 ## 到底哪個模型寫程式碼最好 Lex 問出了那個所有人都在爭的問題：GPT 還是 Claude？ Aman 的回答很乾：**沒有一個模型在所有維度上 Pareto 最優。**維度包括速度、改程式碼能力、處理超長上下文的能力、程式碼能力。就當下綜合最優而言，他認為答案是 Sonnet，並說這是社群共識。 o1 很有意思，推理能力確實強，做程式設計面試題、LeetCode 難題表現很好。但它對你「粗糙意圖」的理解，明顯不如 Sonnet。Aman 還提了一個更含蓄的批評：一些前沿模型在基準上的表現，跟它們在中間地帶的真實能力，是有落差的。在訓練分佈附近跑基準，分數很好看；一旦稍微出界，Sonnet 是那種「能力能保持住」的模型。 這引出了另一個問題：**基準和真實程式設計到底差在哪裡？** Sualeh 說得最直接：真實程式設計裡，人是半句半句說話的，有時候是「照我剛才那樣做」，有時候是「加這個，再做那個，順便把那個 UI 改一下」。所有這些都高度依賴上下文。**面試題的規格極其明確，而人的訴求極其不明確。** Michael 補了第二層難度：公開基準本身就被汙染了。他舉了 SWE-Bench 的例子，這是最流行的 agent 基準之一，但在基礎模型的訓練資料裡汙染嚴重。一個證據是，如果你讓模型做 SWE-Bench 的題，**但不給它任何程式碼庫上下文，它能直接幻覺出正確的檔案路徑和函式名。** Aman 接了句更狠的話：這些題目涉及的程式碼庫，大多是最流行的 Python 倉庫之一，比如 sympy。基礎模型公司不會為了保護這些基準的乾淨度，而把這些主流程式碼庫從訓練集裡剔除。 那怎麼辦？Michael 說，很多做系統或做模型的團隊用了一種土辦法：**找人來玩，做定性反饋。**有些基礎模型公司，專門有人幹這個。Cursor 內部也做大量定性評估，再加上一些私有評測集。 Arvid 給這件事起了個名字：「vibe」測評。Lex 馬上接話說，他自己也是這麼做的，讀論壇、讀 Reddit、讀 X，但使用者經常說「我覺得 Claude 變蠢了」，他自己有時候也這麼覺得，只是不確定是模型的問題還是他自己的問題。 Aman 提了一個有意思的猜測：AWS 用的是自家晶片，數值精度和 Nvidia 的 GPU 可能不一樣，有人猜 Claude 在 AWS 上表現變差，可能跟 Bedrock 上跑的是量化版本有關。Sualeh 補了一句：**晶片是髒的，bug 是極難避免的，這個難度怎麼高估都不為過。** ## 把 prompt 當成 React 元件來寫 Arvid 寫過一篇部落格，講 Cursor 內部的 prompt 系統，叫 Preempt。 他的思路起點是：早期模型（2023 年那批 GPT-4）上下文視窗只有 8K，而編輯器裡可用的上下文資訊一大堆：文件、加進來的檔案、對話歷史。你怎麼決定哪些塞進 prompt、哪些不塞？空間有限，怎麼排？ 他借了一個看似完全不相關的領域的思路：網頁設計。 > 做雜誌印刷，你確切知道內容放在哪。但做網頁的時候，輸入是動態的，你得讓它永遠能工作，輸入太大就得裁掉點東西。（Arvid Lunnemark） 於是他借鑑了 React 的宣告式寫法。**Cursor 內部確實是用 JSX 來寫 prompt 的。**有元件，有一個元件叫 File，輸入是游標位置。游標所在的那一行優先順序最高，往外每遠一行減一，渲染引擎（Preempt renderer）自動算能裝多少行，以游標為中心適配。 更妙的是，這個抽象讓 prompt 變得「可除錯」。因為原始輸入和渲染是分離的，你可以改渲染邏輯，然後在老 prompt 上回放，看這個改動在整套 eval 上到底有沒有提升。Arvid 說這個能力現在比當初更重要：早期 Preempt 是為了適配小視窗，現在更多是為了把資料切分和渲染解耦，讓除錯變得可能。 Lex 順著問：那使用者是不是也應該寫 JSX 來提問？Arvid 的回答很乾淨： > 我們的目標是你做你覺得最自然的事，我們的工作是想辦法把相關內容找出來，讓你的表達能被理解。（Arvid Lunnemark） 這跟 Lex 之前採訪 Perplexity 的 Aravind 聊過的觀點相通：讓使用者儘可能懶。但 Lex 也丟擲了一個張力：**對程式設計師，你是可以要求更多的。**那到底是讓使用者懶，還是讓系統去「啟發」使用者思考得更深？ Aman 的回答是另一種思路：當意圖傳達不夠時，可以有幾種解法。最樸素的是讓模型直接問，「這部分我不確定，你能說清楚嗎？」另一種是，如果搜尋空間不大，那乾脆生成五六個選項讓你挑。 Sualeh 提了一個 Cursor 最近做的功能：**在你打字時，系統會猜你在做什麼，主動建議你該加哪些檔案。**比如你在改 API，系統能根據你在同一檔案裡的歷史提交猜出 client 和 server 都很重要，主動建議你加進來。這個能力還在很早期，但方向是把「提示詞的構建」這件事從使用者手裡接過去一部分。 ## Agent 能幹什麼，這四個人怎麼判斷 Lex 問 agent 的實用程度。Arvid 先說了一句很坦誠的話： > Agent 很像人，看 demo 的時候會覺得自己離 AGI 更近了，非常酷。但對很多事情，agent 現在還不夠有用。我們正在接近它們真正有用的那個點。（Arvid Lunnemark） 他舉了一個具體的例子：Cursor 的聊天輸入框裡，有一個 bug 是 Command+C、Command+V 有時候不管用。這種任務規格極其明確：**「這裡壞了，幫我修」**，兩句話就能說清楚。他很想要一個 agent，自動找到相關檔案、復現 bug、修掉、驗證一遍，一天後他回來看結果。 接下來他講了 Cursor 團隊對 agent 最不主流的判斷： > 很多人相信 agent 會接管所有程式設計。我們不這麼看。因為程式設計裡很大一部分價值在迭代，你沒法事先把需求說清楚，因為你看到第一版之前根本不知道自己想要什麼。（Arvid Lunnemark） 大部分程式設計場景裡，人真正想要的是那種即時的東西：一秒鐘給一版初稿，立刻能改，改完再看下一版。派一個 agent 出門辦差，那是另一類需求，適合規格清楚、步驟固定的活兒。 他還補充了一個「背景 agent」的產品形態：在一個前後端都改的 PR 裡，你在前端工作時，後臺可以跑一個 agent 先摸後端，等你切到後端時，已經有一份初稿可以迭代。這個想法後來變成了 Cursor 的 Shadow Workspace。 ## 速度是產品的一部分，拆開講都是硬核工程 Lex 提了一個很妙的觀察：在 Cursor 裡，Apply 是唯一讓他覺得慢的功能，一兩秒而已。這個「一兩秒都覺得慢」本身，說明其他部分快到什麼程度。Arvid 聽到這句時臉上的痛苦，Lex 專門描述了。 Aman 系統講了幾個加速設計。 **一是 cache warming（快取預熱）。**使用者在打字時，系統能預測他大概會用到哪些上下文，提前把當前檔案內容預熱進 KV cache。等使用者按下回車，真正需要 prefill 的 token 已經很少，TTFT（time to first token）明顯下降。 **二是 KV cache 本身的機制。**Aman 解釋得很清楚：Transformer 能做上下文依賴，靠的是 attention 裡的 key 和 value。預設情況下，模型每生成一個 token，都要把所有歷史 token 的 key/value 重新算一遍。但如果把它們存在 GPU 上，生成第 N+1 個 token 時只需要跑最後一個 token 的前向，attention 時複用之前的 KV。這是 Transformer 裡唯一的序列依賴部分，**複用 KV 等於把這塊序列的代價砍掉大半。** **三是投機加快取的組合。**Cursor Tab 會在使用者按下 Tab 前，先假設他已經接受了當前建議，提前發起下一個請求。**如果使用者真的按了，下一個建議已經在快取裡等著他了。**Aman 說這是個混合了投機與快取的 trick，能達到「看起來很快」的體感，哪怕模型本身沒變過。 Sualeh 接了一句更理論的話：如果把 KV cache 做小，你就能更激進地投機。比如預測接下來 10 個可能動作，使用者只要命中其中一個就賺了。他管這個叫 power K 曲線現象，**單次取樣可能不好，但取樣多次，命中好答案的機率會高得多。**而 RL 本質上就是在利用這條曲線。 Aman 從模型架構上補了另一條線：老一代主要用 multi-head attention，現在往 group-query、multi-query 遷移，本質是壓縮 KV cache 的大小。這麼做的直接好處是生成 token 階段（memory bound）更快，而且 batch size 能做得更大。**更小的 KV cache 意味著你能同時處理更多請求，或者讓 prompt 更長，而不犧牲生成延遲。** Sualeh 還講了一個非常有意思的演算法：DeepSeek 的 MLA（multi-latent attention）。思路是把所有 head 的 KV 壓成一個共享的低秩向量（latent vector），再在需要時展開回去。省下的是記憶體頻寬，用算力換頻寬。他順帶給了一個判斷：多 query 注意力這類壓縮方案，本質都在犧牲 KV 的表達豐富度換效率，MLA 想把損失補回來一部分。 ## 影子工作區：讓 AI 在另一個宇宙裡跑程式碼 Arvid 寫過另一篇部落格，講 Shadow Workspace。 他先講了動機：如果你能在後臺燒算力，就能幫使用者做到超出「預測下面幾行」的事情，比如「未來 10 分鐘你會做什麼」，這需要更多算力和更長的思考視窗。但要讓後臺計算真的有用，你**必須給模型一個反饋訊號**。純靠模型多想一會兒這條路，o1 已經證明有效；另一種同樣成立的方式是讓模型迭代、拿到反饋。 對程式設計師來說，最重要的反饋訊號就是語言伺服器（language server）。每種語言各有一個，能做型別檢查、判斷你寫錯了什麼型別、能不能跳到定義、能不能找到引用。它們在 VS Code 裡透過 LSP（language server protocol）接入，好處是 VS Code 本身不用內建所有語言的編譯器，直接複用現成的編譯器基礎設施。 Shadow Workspace 的想法是：開一個隱藏的 Cursor 視窗，把 flag 一掛，它就隱形了。AI agent 可以隨便改這個視窗裡的程式碼，只要不儲存，就不會汙染原始檔（因為資料夾是同一個）。在隱藏視窗裡，agent 可以拿到 lint 反饋、跳定義、反覆迭代自己的程式碼。 Arvid 提到一個技術坑：Linux 上可以做檔案系統的記憶體映象，把 AI 的改動擋在記憶體層，它以為自己在改檔案，其實全在記憶體裡。Mac 和 Windows 上更難，但這也是他覺得有意思的原因。 Aman 提了一個「hack 但有趣」的替代方案：讓語言模型直接對儲存加個鎖。於是你編輯的其實是「未儲存的、只存在於記憶體裡的影子版本」，但仍然能收到 linter 報錯。你要跑程式碼時，會收到一個小警告說鎖被佔著，然後可以把控制權協商過來。 Lex 說，這個未來既激動人心又有點嚇人。**讓模型直接改檔案，讓 agent 跑一整夜，第二天回來像看同事的作品一樣看結果。**Aman 補了一個更細的判斷：幾分鐘級別的、嵌在使用者工作流裡的任務，本地跑合適；時間更長、改動更大的任務，應該放到遠端沙箱，但怎麼讓沙箱復現使用者環境到「等價」的程度，本身就是極難的問題。 ## 為什麼這些模型這麼不會找 bug Lex 說他設想的 agent 不止在程式設計裡，還在影片剪輯裡。他做播客的很多後期工作透過程式碼驅動 Premiere，包括上傳、翻譯、配音，他希望這些都能被 agent 自動化。回到程式設計，他最想要的 agent 能力是 bug 發現，尤其是邏輯層面的大方向。 Aman 接得很直接： > 這些模型在找 bug 上出奇地差。就算是最聰明的模型，甚至 o1，只要樸素地提示它們去找 bug，校準差得可怕。（Aman Sanger） 為什麼？Aman 的解釋有資訊量。這類模型是預訓練分佈的強烈反映，而預訓練裡最多的程式碼相關資料是「程式碼生成」和「問答」：GitHub 上的程式碼是萬億 token 量級，Stack Overflow、GitHub issues 上的問答也海量。但「在現有程式碼裡檢測真實 bug」，這件事在網上幾乎不存在。**所以當你讓模型去做 Cursor Tab 那種「預測下一處改動」的任務，或者去做 bug 檢測，脆弱性就露出來了。** Sualeh 補了一層更微妙的觀察：模型其實在內部「知道」某段程式碼有點可疑，但難點是**校準「有多可疑」**。同一段程式碼，你在做實驗時幾個 bug 無所謂，你在寫資料庫時一個邊界情況都不能錯。這中間的判斷需要「使用者有多偏執」的上下文，而這恰恰是模型最不擅長的。他還提了一個詞：資深工程師的價值一部分來自文化記憶，知道三年前有人寫過一段很可疑的程式碼把伺服器搞掛了，這種知識模型沒有。 他講了 Arvid 一個極端的實踐：如果一段程式碼能造成巨大破壞，就在函式里每一行都寫上全大寫的「DANGEROUS」，重複十遍。這套做法在今天的 AI 模型上確實有效，模型會對這種區域更警覺，更容易發現 bug。Sualeh 自己承認，從美學上他很難接受，但從實用上，人太容易遺忘，一個小失誤就能搞掛伺服器。 Arvid 順著這條線想到更遠的地方：**在形式化驗證（formal verification）普及之前，你永遠需要擔心「這裡會不會悄悄引入 bug」。**他設想的未來是，人不再寫測試，模型根據你的函式生成一份 spec，你審 spec，然後一個強力推理模型去證明實現符合 spec。Michael 追問：如果意圖本身很難被精確表達呢？Arvid 承認這確實是個真問題，spec 語言也需要演進。 但 Arvid 覺得整庫級別的形式化驗證也可行。他舉了一個很硬的例子：現在已經有工作做到把 C 程式碼形式化驗證到 GCC 編譯器、再到 Verilog、再到硬體。**如果這麼大的系統都能拆解驗證，大型程式碼庫原則上也可以。**Aman 追問了更難的問題：外部依賴怎麼辦？呼叫 Stripe API 怎麼證明？如果模型本身成了程式裡的原語，怎麼證明它？Arvid 說，他甚至覺得「證明一個語言模型對齊」在原則上也是可能的。Lex 說這就是他的「I have a dream」演說。 ## 基礎設施：Merkle 樹、分支資料庫、為什麼 AWS 還贏 聊到基礎設施，Lex 提了一個怪問題：為什麼 AWS 依舊贏，儘管它的介面那麼糟？Arvid 說，AWS 就是好，任何時候你用 AWS 產品，你就知道它能跑通，雖然走通配置流程的過程可能是地獄。Sualeh 一句「這就是贏家該有的樣子」把大家逗笑了。 Michael 講了一個更有價值的細節：每加一個數量級的 QPS，都會撞上新的坑。現在到了「表開始溢位」的規模。Cursor 自研的檢索系統（對程式碼庫做語義索引、回答問題）是其中最難擴的。 Sualeh 展開講了這套系統，這是整期播客裡資訊密度最高的一段。 Cursor 把使用者的程式碼分塊（chunk）上傳做 embedding，然後**只在資料庫裡存向量，不存程式碼本身**，所有細節加密在服務端，客戶端 bug 是他們的心腹大患。技術上最難的是保證「本地索引」和「服務端狀態」一致。每改一個檔案、刪一個檔案、切一個分支，都得同步。 樸素做法是每分鐘拉一次全量雜湊，但這樣會「砸爆使用者的 WiFi」，也會讓接近 20TB 的資料庫每秒被讀一遍。Cursor 的解法是分層雜湊：每個檔案一個雜湊，每個資料夾存它所有子節點雜湊的雜湊，一層層往上，直到專案根節點一個雜湊。**絕大多數情況下根雜湊對上就結束。一旦不對，才逐層下鑽，去找不一致的地方。**這套結構有個大名鼎鼎的名字：Merkle 樹。 Aman 補了一個很妙的經濟學細節：索引系統的成本瓶頸不在向量資料庫，而在**embedding 本身**。一個公司裡 N 個程式設計師用同一份程式碼，你沒理由給每個人都重新 embed 一遍。他們的做法是，對某個 chunk 算出的向量做快取，快取的 key 是這個 chunk 內容的雜湊。這樣公司裡第 N 個人做 embedding 時幾乎瞬間完成，切分支時也不用重算，還不用在服務端存原始程式碼。 Sualeh 提到一個未來的方向：Turbopuffer 這類資料庫正在給 write-ahead log 加分支（branch）能力，讓 AI agent 直接在資料庫分支上測試，而不用汙染主庫。他很喜歡這個隱喻：「所有東西都需要分支。」Aman 順著開腦洞：如果檔案系統也能分支呢？Sualeh 回了一句關於多重宇宙的玩笑收尾，說已經有極其聰明的演算法能保證不會真的佔掉太多空間和 CPU。 ## 為什麼不做本地模型 Lex 問一個反覆被提及的問題：為什麼 Cursor 不把 embedding 之類的計算放到本地？ Arvid 的回答很現實：Cursor 的使用者 80% 以上用 Windows 機器，很多效能一般。本地模型基本只在最新款 MacBook Pro 上可行，光是維護這些分支就要吃掉大量工程資源。**更關鍵的是，當模型越來越大，本地能做的事越來越少。** Sualeh 補了一個常被忽略的角度：這跟「使用者電腦弱」關係沒那麼大。哪怕你是大公司裡最強的程式設計師，在一臺頂級 MacBook Pro 上處理公司那種二十年積累的龐大程式碼庫，做近似最近鄰搜尋也會把記憶體和 CPU 榨乾。就算能勉強跑通，也不「好玩」了。 Aman 從模型側補了另一重困難：趨勢是 MOE 化，這對本地推理其實有利，因為 MOE 更受記憶體頻寬約束，而消費級硬體在記憶體頻寬上的劣勢比在算力上小。但壞訊息是，**總引數量越來越大，經常單臺機器放不下，得上多節點**，更別提塞進 MacBook。 接下來 Arvid 講了一段可能是整期裡最哲學也最動人的話。他說他有一個替代方案，還在研究階段，但特別令人期待：**用同態加密做語言模型推理**。你在本地加密輸入，傳到伺服器，伺服器在密文上跑你本地根本跑不動的模型，但伺服器看不到資料是什麼。結果傳回來，你解密，只有你能看到答案。他說這個技術現在還處在研究階段，瓶頸全在開銷，如果能把這個開銷壓下去，意義會非常大。 他接著講了為什麼這件事重要： > 當這些模型越來越好，它們會越來越有經濟價值，世界上越來越多的資訊和資料會流向一兩個中心化的玩家。如果全世界的明文資料都流經一個節點，那就有可能被以很壞的方式監控。一開始往往是好的理由，防止壞人惡意使用 AI，於是加上一些監控程式碼。然後換一個人進來，你就滑下去了，然後開始用全世界的海量資料做壞事。（Arvid Lunnemark） 他還順手做了一個和雲端計算的對比。今天你用雲服務，大多數時候可以自己管金鑰，雲廠商其實看不到多少東西。但模型推理這一層不一樣，服務商看到的就是完整的明文。 Sualeh 補了一個他真正擔心的畫面：隨著模型能力到 ASL-3、ASL-4，出於合理的安全考慮，你會想監控所有 prompt。這個出發點能理解，但如果全世界的資訊都要在這種監控下流動，那太集權了。他描述這種狀態是一條極細的線：**一邊是不想讓模型失控，一邊是不放心讓所有人的所有資訊流經三家模型公司。** ## 上下文這件事，為什麼自動算不乾淨 Lex 說這是他自己的痛點：寫 Python 時匯入了一堆庫，Cursor 大概能猜出你想放進上下文的東西，但猜得不夠好。 Michael 的回答裡有一個容易被忽略的取捨：**自動塞上下文不是免費的。**塞得越多，請求越慢越貴，你能做的模型呼叫次數就越少，後臺能跑的漂亮功能也就越少。更麻煩的是，很多模型在 prompt 塞滿時會犯糊塗。所以「自動上下文」的門檻其實很高，相關性不夠的寧可不放。 他提了幾條可能的路。一條是更工程化的：更好的檢索、更好的 embedding、更好的 reranker。另一條更學術：能不能讓模型自己理解一個新語料庫。這條路上有幾個層層遞進的問題。先問能不能讓上下文視窗無限長；如果能，再問模型是否真的會注意無限長的上下文；如果會，再問能不能對這種無限上下文做快取，不用每次都重算。還有一類思路更像微調，**把資訊學進權重，而非靠 in-context learning 臨時裝進來。**Michael 說，在權重層面學到的理解，可能和在上下文裡「臨時讀懂」的理解有質的不同，但這個問題目前還沒有定論。 Aman 給了一個現成的驗證案例：VS Code 的程式碼全公開，這些模型在預訓練時都見過，可能也見過圍繞著它的問答，然後再經過指令微調和 RLHF，所以你問它 VS Code 的問題，它有時候能答得挺好，當然也會幻覺。他追問：**那如果你專門去 post-train 一個模型，讓它真的「懂」某個程式碼庫呢？** 他講了具體做法，很樸素。做持續的預訓練，把通用程式碼資料和某個特定倉庫的資料混在一起喂進去。然後做指令微調，標準程式碼資料集之外，加上大量「關於這個倉庫」的問答。這些問答可以是真的人工標註，也可以用合成的方式造：拿最近改動過的程式碼片段，讓模型自己針對它提問，然後把問題和程式碼配對，做成訓練樣本。 這裡還有一個更深的分岔，Aman 說這仍是個開放問題：**你希望模型端到端地把檢索也做進內部，還是希望把檢索和前沿模型分開？**後一種情況下，幾個月後會出現一批遠超最好的開源模型的前沿模型，同時你可以專門訓一個很強的開源模型來當檢索器，負責給大模型喂上下文。 ## o1 出來了，然後呢 Aman 把訓練分成三段：預訓練、後訓練、測試時計算。他說測試時計算這條路有意思的地方在於，預訓練那邊大家開始撞到資料牆，靠加資料加引數繼續變好會越來越難，而**在推理時多花算力、換來對應幅度的效能提升**，是一條新的增長曲線。 他講了一個很實在的經濟學視角：有些問題可能需要萬億引數級、萬億 token 訓練的模型才能解，但這類請求可能只佔全部請求的 1% 甚至 0.1%。為了這種罕見需求去訓練一個超大模型，然後極低頻地呼叫，純屬浪費。**更合理的做法是訓練一個能覆蓋 99.9% 請求的模型，然後在遇到真正硬的問題時，讓它多跑一會兒。** o1 到底在內部怎麼工作，這事連圈內人都只能猜。Aman 說得很坦率：出了 OpenAI，甚至可能只有 OpenAI 內部少數人知道。他提了幾個公開研究裡露出的線索，比如用過程獎勵模型配合樹搜尋，或者大規模人工標註的思維鏈資料集。但這些都是推測。 他順帶把獎勵模型分了兩類。結果獎勵模型（outcome reward model）只看最後答案，給那個最終輸出打分。過程獎勵模型（process reward model）試圖給思維鏈的每一步打分。他提到一個關鍵判斷：現在公開文獻裡，過程獎勵模型最主流的用法是取樣一批候選答案，然後用它來排序挑最好的那個。**真正讓人興奮、但還沒有被驗證成功的方向，是用過程獎勵模型去做樹搜尋**，就是說如果每一步能被準確打分，你就可以在思維鏈裡分叉、探索多條路徑、再判斷哪條分支值得走下去。 Lex 追問這個過程裡有個隱含前提：分支的短期質量和最終結果的長期質量要高度相關。Aman 認可，這也正是難點所在。 關於 OpenAI 隱藏 o1 的思維鏈這件事，Michael 給了一個很有資訊量的猜測。他說一個可能的動機是防止能力被蒸餾：如果能看到模型走到答案的每一步，那麼復現這套技術的難度會顯著下降。他還聯絡了一個歷史細節，某些大模型 API 曾經開放 log probability 的訪問，後來又收回去了，理由可能類似，那些機率分佈同樣能給出大量蒸餾用得上的資訊。 Michael 也澄清了 Cursor 整合 o1 的實際狀態：o1 不參與任何預設體驗，團隊至今沒找到一種讓人每小時、甚至每天都想用的整合方式。原因之一是 o1 不流式輸出，對需要邊看邊監督的任務來說，盯著空白等一大段文字掉下來，體驗很糟。Sualeh 補了一句：想法是有的，只是要先做出真正有用的東西才放出去。 Aman 補了另一層難度：模型路由。什麼任務該用 4o、什麼該用 Sonnet、什麼才值得上 o1，這件事沒人真正解好。Cursor Tab 那邊有初步實現，但要在 4o、Sonnet、o1 之間切換就麻煩得多。他拋了一個很尖銳的自問：判斷「這題對 4o 來說太難了」需要什麼級別的智慧？不確定。 Lex 順勢問了一個網際網路上流傳的說法：GitHub Copilot 開始整合 o1 了，有人評論「Cursor 是不是完了」。Michael 的回答裡有這期最重要的一個判斷： > 這個領域的天花板高得離譜。三四年後最好的產品，會比今天最好的產品有用得多。你可以把護城河、品牌講得天花亂墜，但如果你停止在產品上創新，你就會輸。（Michael Truell） 他把這當成對創業公司利好的訊息：這意味著你永遠有機會靠做出更好的東西，去打敗那些已經有很多使用者的對手。Aman 補充，Cursor 相對其他工具的價值，大部分不來自「最快接上新模型」，而來自那些你意識不到自己在用的自研模型，以及每一個功能背後被反覆推敲過的互動。 ## 合成資料的三個種類 聊到這裡 Lex 讓 Aman 展開了他在內部講過的一套合成資料分類。這段對做模型的人最有用。 先定義清楚：非合成的自然資料，是人類在真實過程裡產生的資料。合成資料分三類。 **第一類是蒸餾。**讓一個語言模型輸出 token 或者 token 上的機率分佈，然後拿它去訓一個能力更弱的模型。這條路不會讓你得到比原模型更強的模型，但它能把一個昂貴、高延遲的模型能力，壓到一個小的專用模型裡。對產品來說，這就是延遲和成本的解藥。 **第二類靠的是「一個方向比反方向容易」。**最典型的例子是 bug 檢測：製造一個看起來合理的 bug，比找出 bug 容易得多。所以你可以讓一個不太聰明、沒訓多少資料的模型去製造 bug，用這些合成資料去訓一個擅長抓 bug 的模型。Aman 說這對人大概也成立。 **第三類是用語言模型生成「可以被輕易驗證」的文字。**他打了個極端的比方：如果有一個驗證器能判斷一段文字是不是莎士比亞水平，那你讓一群猴子在打字機上亂敲，敲足夠久也能湊出足以訓練出莎士比亞級模型的資料。數學是這一類最好的場景，因為形式化語言的驗證極其便宜。程式碼裡的 LeetCode 型題目也一樣，只要有測試集，跑通了就說明解對了。 Aman 的判斷是，第三類最有可能帶來巨大收益，但它也最難推廣。**對開放式任務、長週期任務，「完美的驗證器」這個前提就很難滿足。**Michael 補了一種中間狀態：讓模型去「執行」程式碼並真的理解輸出，相當於把人類的手工驗證交給模型做。Aman 認可這一點，說那大概是最有希望的一條路。 順帶聊到 RLHF 和 RLAIF。Aman 的解釋是：RLHF 的獎勵模型來自人類反饋標註，前提是你能拿到海量的人類反饋。RLAIF 的價值建立在一個前提上，即**驗證確實比生成容易得多**。他說 Cursor 的實際做法是兩者混合：模型本身往往已經相當正確，只需要 50 到 100 個樣本量級的人類偏好，把它原本的先驗校準到你想要的分佈上。這和傳統上花海量樣本訓獎勵模型的做法很不一樣。 Lex 順著「P 是否等於 NP」這個比喻往下問。Aman 說，如果你相信 P 不等於 NP，那有一大類問題，驗證比生成容易太多，這個直覺應該成立。Lex 打趣問：那 AI 會不會順手證明 P≠NP，然後順手拿個菲爾茲獎？誰來領這個獎？Michael 說，誰寫的那條 prompt 誰領。Sualeh 認真猜了個年份：2028 到 2030。 Arvid 認為菲爾茲獎會比諾貝爾獎更早被 AI 攻下，理由是數學可以被驗證，是一個封閉系統，容易設計獎勵。Aman 說他自己的直覺是：**我們可能會在 AGI 之前先拿到菲爾茲獎。**他還補了一句自我修正：當年他賭 IMO 金牌，是因為那時看得清路徑，已經能解幾道題，文獻裡也有一堆現成的 tactic 可以撿。但對真正開放的數學難題，他現在的直覺要弱得多，「我們連一條通往解法的路都看不清」。他專門提了 BSD 猜想（Birch and Swinnerton-Dyer conjecture）這類題目做例子，說明難點不在驗證，而在於連探索的方向都沒有。 ## Scaling law 比最初那篇論文複雜得多 Aman 講了一段對 scaling law 的修正史。OpenAI 最初那篇論文有點偏差，主要是學習率排程的問題。Chinchilla 給了一個更準確的版本，核心是在引數量和 token 數之間找到算力最優比例。但後來大家又開始偏離「算力最優」，轉而按**推理預算**做最佳化，寧可訓練時多花算力，換取部署時更便宜更快。 他說今天的曲線維度遠比當年多。推理時的算力是一個維度，上下文長度是另一個。他舉了一個漂亮的推論：如果你的核心訴求是「推理時延低 + 上下文超長」，那你可能該訓一個 SSM 架構，因為它在超長上下文的推理上便宜得多、快得多。**哪怕訓練時要多花 10 倍算力才能達到同樣的能力水平，也值，因為你最在乎的是推理那一端。** 對「更大是不是一定更好」這個問題，Aman 的回答很直接：**對原始能力而言，更大確實更好。**Sualeh 補了「原始智力」這個詞。Aman 接著說，他自己特別看好蒸餾：花極其昂貴的算力，訓練一個最強的教師模型，然後把它的能力壓進一個便宜的學生模型。他舉了 Gemma 的做法，訓練目標本來就是去最小化學生和 27B 教師之間的 KL 散度。這就是「用訓練教師的全部算力，換一個更小的模型」。這也部分緩解了資料牆：同樣的 token，你能從中榨出更多訊號。 Lex 丟擲一個假設性的問題：給你 10 萬億美元，投在接下來五年，怎麼分？ Sualeh 說答案可能很簡單，全買 GPU，研究人員自己去調。Aman 追問：那你到底是被算力和錢限制，還是被別的東西限制？Sualeh 說他更認同 Arvid 的判斷：**這個領域是被想法限制的。**Arvid 補了一句：但如果你有大量算力，你就能跑大量實驗。 Aman 想得更細。他說就算有全世界的資本，你也湊不齊人。全世界真正能在這件事上做出差別的人本來就不多，而且研究裡有大量工作是純粹極其艱苦的工程。**他拿 Transformer 論文舉例：把文獻裡那些有趣概念拼起來是一回事，寫出能真正把 GPU 效能打滿的程式碼、可能包括 CUDA kernel，是另一回事。**再往前一步，讓模型並行在幾千甚至幾萬張 V100 上跑通，本身就是一個巨大的工程壯舉。他說如果能把這種工程成本降低 10 倍，讓一個有好想法的人立刻拿到他設想的架構、且能跑到 40% 到 50% 的 GPU 利用率，那研究的整體速度會快一大截。 Sualeh 最後給了一個很務實的次序判斷：如果你看見一條清晰的改進路徑，就應該先撿低垂的果實。當一路加規模就能變好時，沒有理由停下來做實驗。**直到你必須靠新想法才能繼續，那時才回頭重新審視。**Aman 說，他們四個人大概都相信，要走到 AGI 一定需要新想法，也都相信這些想法可以在小規模上先驗證出來。難的是，對現在的大實驗室來說，一邊有一個「再加規模大機率還能漲」的核心路徑，一邊要分出極稀缺的研究和工程人力去探別的路，這個取捨非常難做。 ## 人坐在駕駛座上 Lex 把話題拉到最遠處：程式設計這件事，未來幾個月、一年、兩年、五年、十年會怎麼變。 Michael 講得最完整。他說 Cursor 押注的是一個「程式設計師長期坐在駕駛座上」的未來，關鍵詞是三個：**速度、主動權、控制權。**能改任何你想改的東西，能以極快的速度迭代你在做的東西。 他明確地和另一種流行想象劃了界：有一種畫面很吸引人，你對著電腦說話，它像一個工程師或者一個工程部門一樣替你把軟體造出來，一個孤零零的輸入框就搞定一切。他們不興奮於這個畫面，一部分原因是延遲，但更重要的是**那意味著放棄大量控制權。** > 如果你只能像對一個工程部門說話那樣跟一個東西溝通，你就會把大量極其重要的決策讓給這個機器人。但工程裡最好的那部分，恰恰是無數個關於「到底要造什麼」的微小決定，以及速度、成本和其他一切之間的艱難取捨。（Michael Truell） 他還順帶糾正了一個關於工程的誤解。不在工程裡的人容易以為，規格已經寫得清清楚楚，工程師只負責把它落到程式碼裡。但真正好的工程，恰恰是那些關於系統該怎麼權衡的微小判斷，速度、成本、複雜度、可維護性，這些東西事先根本寫不進規格。 他提了一個有點怪但很有意思的想法：**讓你能控制自己看程式碼庫的抽象層級。**你可以用虛擬碼的形式消化一整個程式碼庫，甚至可以編輯那段虛擬碼，然後讓改動落到真正的程式語言層面。你在任何一層抽象上都能對邏輯做手勢，同時保留文字編輯、保留鑽進程式碼裡的能力。他說這個想法目前還很模糊，細節要一項項填，成不成得看時間。 Lex 把這個問題落到最現實的地方：現在有很多年輕人害怕，他們喜歡程式設計，但怕這條路沒有未來。程式設計這門手藝會不會被根本性地改寫？ Michael 的回答很樂觀，理由具體：程式設計今天比 2012、2013 年那會兒好玩太多了，那時候的雜事、樣板程式碼、查各種刁鑽問題的比重高得多。今天的程式設計「越來越接近純粹的愉悅」。**那些把人吸引到程式設計裡的東西，快速造東西的能力、個人的掌控感，都正在被放大。**技能會變，人的品味和創意會被放大，樣板程式碼的文字編輯會變少，現在很重要的「小心翼翼」也會變得沒那麼重要。 Arvid 舉了一個他自己的經歷：他們決定把程式碼庫裡用的 AsyncLocalStorage 遷移到 context object，因為前者效能不好。這是影響整個程式碼庫的大遷移，他和搭檔花了五天，用著今天最強的 AI 工具。**他很期待未來只需要展示兩三個例子，AI 就能把改動鋪到所有位置**，遇到新情況就高亮出來問他，他示範一次，整件事十分鐘搞定。這樣你就不用事先站在黑板前反覆推演「成本太高了，必須一次做對」，可以先試一個方向，發現不對立刻改。 Aman 把這種心態講成兩種程式設計方式的對比：一種是先想清楚最優解，再用有限的工程時間去實現；另一種是先動手寫，看它長成什麼樣，然後快速迭代。他說**後一種更好玩。** 至於該怎麼學，Aman 說不同的人因為不同理由寫程式碼，但真正最好的程式設計師，是那種**純粹熱愛程式設計本身的人**。他講團隊裡有人下班回家，開啟 Cursor 寫自己的專案寫到凌晨三點，難過的時候說「我就是需要寫程式碼」。這種痴迷會讓人鑽進細節裡，去搞清楚事情到底是怎麼跑的。 Lex 追問：那這個人，當超級 Tab 成功、他只需要一直按 Tab 的時候，會變成什麼樣？ Sualeh 和 Arvid 幾乎同時回答：這個人會是團隊裡最愛 Cursor Tab 的人。Arvid 補了一層更細的理解：**按 Tab 是被動接受。你一直在往裡注入意圖。**有時候你拒絕，有時候你多敲幾個字元，這就是你在塑造正在被造出來的東西。Sualeh 用一個詞概括：頻寬。人對電腦的溝通頻寬，從「一個字一個字敲」變成「持續注入意圖」，這是好幾個數量級的提升。 這期節目最後，Lex 讀了 Cursor 團隊那份叫 Engineering Genius 的內部宣言。宣言裡寫，他們要造的是「未來的工程師」，一個比任何單個工程師有效十倍的「人機混合程式設計師」，這個混合體會對程式碼庫有毫不費力的掌控，沒有一次低熵按鍵，即使在最複雜的系統裡，也能**以判斷力的速度迭代**。宣言的最後一句是：在這條路上，至少我們會讓程式設計變得更有趣。 把整期聽完，最有意思的地方在於這四個人的判斷和行業主流敘事之間持續的張力。別人在說「agent 會接管一切」，他們說大部分程式設計的價值在迭代，而迭代需要人坐在駕駛座上。別人在比誰的模型引數更大，他們在比誰的 KV cache 更小、誰能在使用者按下回車前就把 cache 預熱好。別人在談護城河，Michael 說的是「停止創新你就會輸」。 Cursor 的差異不在某個單點。讓一家公司站住的是整套東西：一堆自研模型、一層被反覆推翻重做的 diff 介面、一套用 JSX 寫的 prompt 渲染引擎、一棵可以逐層下鑽的 Merkle 樹，以及一個敢把「快就是好玩」當產品原則的團隊。這些東西單拎出來都不性感，疊在一起才有那種「用過就回不去」的體感。 ## 如果你現在就想用起來 把這一期的資訊翻譯成能立刻動手做的事，大概是下面這些： - **把 Tab 當成主要輸入方式，而非補全按鈕。**多按幾次，看它能不能把你接下來幾步都帶過去。被拒絕了不要緊，那正是你在注入意圖的地方，順手多敲兩個字元往往就校準了。 - **給危險程式碼加顯式標記。**如果某段邏輯出錯能搞掛服務，就在函式里寫清楚，必要時用全大寫的警告重複幾遍。這不是給同事看的，是給模型看的，今天的模型確實會對這類區域更警覺。 - **不要指望模型替你找 bug。**它對「這段程式碼有多可疑」的校準很差。讓它找 bug 時必須給它足夠的上下文：執行日誌、呼叫鏈、型別定義，以及這段程式碼有多關鍵。 - **寫 prompt 時把「意圖」和「上下文」分開想。**先把你要什麼說清楚，再想它需要看到哪些檔案。如果它答非所問，先懷疑上下文沒給夠，別急著換措辭。 - **大改動別一次做完。**展示兩三個例子讓 AI 鋪開，遇到它不確定的地方你示範一次。這比事先在黑板上推演三天更划算，因為迭代成本已經被壓下來了。 - **把重複性、規格明確的活兒攢起來交給 agent。**比如「這個快捷鍵在某些情況下失效了，幫我修」，這類任務說清楚就能派出去。設計層面的取捨，留在自己手裡。 - **審 AI 產出時先要一份導讀。**多檔案大改動的話，與其從頭翻 diff，不如先讓模型告訴你該按什麼順序讀、哪幾塊最值得細看。 - **如果模型突然「變笨」，先懷疑部署。**同一家廠商不同雲上的晶片、量化版本、數值精度都可能不一樣，這類問題有真實的工程根源，不必先懷疑自己的判斷。 - **給自己留一個「跑實驗」的習慣。**這次訪談裡反覆出現的一個判斷是，這個領域仍然被想法限制。想到一個可能性就小規模跑一下，比在心裡推演三小時更值。 最後留一句 Lex 在節目末尾唸的、來自 Reddit 的段子：世界上沒有比一個能用的臨時方案更永恆的東西。這句話放在 AI 程式設計這個領域，意外的貼切。