“Cursor的bug太多了，他們直接買下一家代碼評審公司來修！”

編譯 | Tina

12 月 19 日，Cursor 宣布將收購代碼評審初創公司 Graphite。

Cursor 主要在編寫代碼階段為程序員提供輔助；而 Graphite 則聚焦于代碼完成之后的流程，幫助團隊評審變更、判斷代碼是否已具備上線條件。Graphite 聯合創始人 Tomas Reimers 與 Cursor CEO Michael Truell 的共識是：“AI 的引入意味著會有更多代碼被寫出來，也就必然意味著，需要被評審的代碼只會更多。”

在 AI 大幅加速代碼編寫的同時，代碼評審流程卻幾乎沒有發生變化，反而正在占用工程團隊越來越多的時間，這正是這筆交易發生的現實背景。Michael Truell 在一份聲明中表示：“在過去 2.5 年里，Cursor 已經讓編寫生產級代碼變得快了很多。但對大多數工程團隊而言，代碼評審的方式看起來仍然和三年前幾乎一模一樣。”

Graphite 成立于近五年前，并于今年 3 月完成了 5200 萬美元 B 輪融資。這家公司目前為 500 多家企業、數萬名工程師提供服務，客戶包括 Shopify、Snowflake、Figma 以及 Perplexity AI。

Cursor 目前估值約 293 億美元。公司由四位 MIT 畢業生于 2022 年創立，近幾年增長迅猛，其 AI 編程工具于 2023 年首次發布。就在一個月前，Cursor 宣布其年化營收已達到 10 億美元，而此次交易也是該公司的第三次收購。此前，Cursor 曾在 2024 年 11 月收購 AI 編程助手 Supermaven，并在同年 7 月從人工智能 CRM 初創公司 Koala 吸納了一批人才。

對于這次收購，兩家公司表示，Graphite 將繼續以獨立產品形態運營，同時與 Cursor 的代碼編輯平臺進行更深度的集成。此前，Graphite 本身有 VS Code extension，使用 VS Code、Cursor、Windsurf 編輯器的話，可直接在擴展商店安裝 Graphite 。

未來幾個月，他們將會加碼打造更好的 stack PR 平臺和 merge queue；做 Cursor 與 Graphite 之間深思熟慮的集成，把本地開發、background agents、pull request 串起來；利用 Cursor 在 coding models 上的經驗讓 Graphite 的 AI 功能更聰明；還計劃將自家的 AI Reviewer 與 Cursor 的 Bugbot 進行融合，打造“市場上最強的 AI 代碼審查工具”。

這筆交易相當于是把 AI 時代“創建、評審、合并代碼”的最佳工具組合到了一起。這三件事里，Cursor 實際上只做了其中一件——寫代碼，另兩件則是 Graphite 的強項。交易交割后，整個 Graphite 團隊都會加入 Cursor 繼續推進相關產品研發。

寫代碼“一把梭”了，code review 就成了瓶頸

AI 編程工具，可能是整個科技行業里變化最快的一個品類。

所有做過開發的人都知道，代碼評審這件事非常不穩定。效果好不好，取決于是誰在 review、他有沒有動力、有沒有認真看。有時候你只會收到一句 “LGTM（Looks Good To Me）”。而現在，代碼生成量暴漲，再加上 LLM 往往不太擅長“簡潔”，代碼評審反而成了一個被嚴重低估的關鍵環節。

根據 Graphite 公司分享的數據，相比 2023 年，現在每位工程師產出的代碼量大約多了 70%。主要問題在于，代碼可以指數級增長，但工程師的時間仍然是人類尺度的時間。作為一線工程師，你不得不 review 更多內容；作為系統本身，合并隊列、merge conflict、自動化 bot 帶來的連鎖反應也開始堆積，整個合并與交付體系承壓明顯。

而且，更微妙的變化在于“信任模型”被打破了。過去看到一個 PR，你心里往往會想：“這是熟悉的同事寫的，我大概知道他會怎么寫、為什么這么寫。”但現在，這種確定性正在消失——也許是他寫的，也許只是盯著屏幕一直按 Tab 鍵；甚至在更極端的情況下，這段代碼可能從頭到尾沒有任何人類認真讀過，而你恰好成了第一個。

與此同時，上下文正在快速流失。當我們自己寫代碼時，往往會順帶把代碼庫的結構、演進脈絡這些上下文一起“吸收”進去；而 code review 也會在團隊協作中把這部分上下文再“分發”一輪——你在 review 別人的改動時，會重新理解一遍系統為什么這么設計、現在往哪里走。

但如果我們寫代碼的時候并不是帶著很主動、很清醒的思維去寫，而是大量內容被半自動生成、再被半機械地接受，那么我們掌握的上下文就會越來越少。久而久之，整個團隊會越來越說不清楚：代碼庫里到底發生了什么、為什么會變成現在這樣。這會隨著時間推移變成一個非常危險的問題。

因此，code review 系統的負擔更重了；合并系統、部署系統也更重了。軟件開發的那整套“外循環”（outer loop）正在被挑戰、被卡住。

在這種新負載下，很多團隊開始意識到：把 agent 當成“自動駕駛”是不現實的，它更像一群“初級、異步、數字化員工”——你可以一次性放出一群去干活，但它們天然缺上下文、缺架構性思考，也更容易在關鍵細節上“跑偏”。

真正拉開差距的 best practice，反而很樸素：中間可以是 agent，但開頭和收尾必須是人。

開頭往往需要資深工程師、Staff 級別、經驗非常豐富的工程師，把上下文組織清楚（設計文檔、約束原則、依賴核對、任務拆解），讓 agent 先“讀懂再動手”；收尾同樣由強工程師把質量關守住（review、CI、回歸定位與迭代），確保每一次合并都能解釋得清、追得回、兜得住。這也是為什么與 AI agent 協作最有效的，往往是資深工程師：他們不僅能在輸入端把問題講明白，還能在輸出端把風險控住。

現在一個很實用的協作模式是：先認真寫一份 markdown 設計文檔，再把它交給 Claude Code 或 Cursor 執行。但也正因為生成代碼變得太容易，讓 Claude Code、Cursor 這類工具一次性產出 2000 行、3000 行的 PR 并不難。這種情況下，人類 reviewer 很容易眼睛“發直”，最后又回到那句熟悉的 “LGTM”，或者“我看不完，直接合吧。”

這種“外循環被卡住”的現實，也很快投射到了 Cursor 自己身上。T3 Chat 公司創始人、Cursor 投資人 Theo 在一次分享中直言：Cursor 對“更快交付、構建更多功能”這件事至關重要，但你甚至能從編輯器本身感受到這種壓力——“它看起來像是在慢慢散架”。

他提到他上周一還專門帶著團隊去了 Cursor 辦公室，坐下來連續吐槽了兩個小時他們在使用過程中遇到的各種 bug。Cursor 團隊隨后承諾，接下來一段時間將暫緩新功能開發，進入“硬核修 bug 模式”，并且每天同步修復進展：修了哪些 bug、發現了哪些新 bug、下一步準備怎么處理。“他們確實在非常認真地解決這些問題。”他評價道。

也正是在這個語境下，他拋出了 X 上的那句調侃：“Cursor 的 bug 太多了，他們買了一家 code review 公司來修它。”

這當然是個玩笑，但玩笑背后并非沒有現實邏輯：當代碼生成量暴漲、交付節奏被拉到極限時，代碼審核往往成為了系統中的瓶頸，對一個以高頻迭代著稱的 AI IDE 來說也是一樣。

Graphite：繼承自 Meta 的 code review 工程方法論

如果只看今天的定位，很容易以為 Graphite 是一家“順應 AI 浪潮而生的代碼評審公司”。但實際上，Graphite 其實完全不是從“代碼審查公司”開始的。

這家公司最初做的是一套幫助移動應用 QA 團隊的工具，由一群曾在 Apple、Meta（Facebook）等大型科技公司工作過的工程師組成。他們在離開大廠之后，對“熟悉的開發體驗突然消失”產生了強烈落差感。

在他們看來，Meta 內部的開發者工具鏈幾乎是“另一個世界”。對沒在那套體系里工作過的人，可以用一個直觀的對比來理解：GitHub 在 2011 到 2013 年左右定義了 Pull Request 這種協作范式，而 Meta 內部也構建了類似的東西——但不同的是，Meta 從那之后幾乎沒有停過對這套工具的持續迭代。

而 GitHub 在 code review 這塊，“很多東西很久沒怎么變了。”在 Tomas Reimers 看來，當他們說“Facebook 的工程工具在創新層面領先將近十年”時，那就是字面意義的“領先十年”。

因此，在他們離開 Facebook、重新回到 GitHub 體系之后，覺得十分不適應。最初，他們只是懷疑自己是不是變挑剔了？但大約六個月后，這種自我懷疑逐漸消失，取而代之的是一個更明確的判斷：這不是習慣差異，而是工程工具本身的巨大斷層。

也正是在這個階段，他們開始問一個問題：如果那套被驗證過的開發體驗如此之好，有沒有可能把它重新做出來？

于是團隊開始一點一點為自己搭工具，這套內部工具后來被叫做Pancake，完全是為內部使用而生的：代碼里寫死了倉庫名、GitHub handle，很多邏輯都是圍繞團隊自身的工作流設計的。

隨著越來越多前 Meta 的同事離開大廠，加入創業公司或新團隊，一個問題開始反復出現：“外面的 code review 怎么和記憶里的完全不一樣？”最后他們往往會找 Tomas Reimers 團隊聊起自己曾經習慣的那套評審體驗，并希望他把團隊內部正在使用的工具開放出來，讓他們也能直接用上。

最終，2021 年 11 月，團隊做出了轉型決定：把 Pancake 從一個高度定制的內部工具，打磨成一款真正對外的代碼評審產品。那是一段高度集中的工程沖刺期——需要把所有“寫死在內部場景里”的假設逐一剝離，把只服務自家工作流的工具，改造成任何團隊都能接入、可規模化運行的系統。

為什么是 stacking

Graphite 的核心理念，并不是某種“全新的 AI 發明”，而是一套早已在超大規模工程組織中被反復驗證的模式：stacked diffs。

Tomas Reimers 在 Meta 工作了兩年半，他對 stacking 的解釋非常直白：“作為一種方法論，stacking 讓開發者能夠繞開對 main 分支的依賴所帶來的延遲，從而實現真正的、持續的并行開發。”

傳統的 Git 工作流，往往把每一個功能等同于一個 PR：一個 PR 對應一個分支，由多個 commit 組成。典型的、非 stacking 的流程是這樣的：完成一個功能、提交一個 PR、等待 PR 被評審、通過后合并回 main。

Pull Request 與 stacked diffs 工作流上的差異

一旦 PR 合并完成，你就會開始下一個功能，于是再次從 main 拉分支繼續開發。哪怕流程再順，這個節奏依舊很慢，PR 往往會在等待評審的狀態下停留數小時甚至數天。他們甚至分析過 1500 萬個 PR 的歷史數據，發現有些 PR 會“等上好幾年才合并”。

Stacking 的核心變化在于：把變更的基本單位從 PR，變成了單個 commit。在 stacking 模式下，你會把一個大的改動拆成許多個小改動。每一個改動——也就是一個 commit——都可以被單獨測試、評審、合并，甚至單獨回滾。

這些由小改動組成的集合，也就是所謂的 stack，可以一層一層地持續構建。工程師可以在不被阻塞的情況下持續向前推進。舉個很現實的例子：你經常會在完成一個功能之后，立刻想基于它繼續做下一個功能。在 stacking 模式下，你不需要等第一個功能被評審、合并完成，就可以直接在它之上繼續工作。

“如果兩個人同時提交 5000 行代碼，沖突概率極高。如果兩個人都在小步快跑，問題會少得多。”

在 Graphite 里 AI review 的規則是“最多 review 100 行代碼”。Tomas 表示他們的判斷是：“超過 100 行，基本已經是一次重構了，不適合做 AI review。 ”

他認為這也是 stacking 的意義：PR 大了，就該拆。甚至對 AI Agent 來說，“Stacking 也在幫它壓縮上下文”。

當你開始讓 coding agent 去堆疊改動、把一個大任務拆成很多小 PR，它會開始在這些 stacks 之上應用一種“鏈式思考”。你能看到它會自己拆步驟：“好，先寫函數；然后寫單測；然后在其上加 endpoint……”它開始模塊化、逐步測試、逐步推出。而且事實是：AI 這樣做出的結果往往比你讓它“一把梭”生成一個大 PR 更好。

如果出現 merge conflict ，Graphite 會把你直接帶進 Git 的沖突解決流程里，把沖突文件修好之后，它會繼續幫你把 stack 后面的 rebase 都跑完，同時也會將這些歷史都記錄下來。

另外，在評審反饋上，據 Graphite CTO Greg Foster 的說法，他們很大一部分的工作就是：

“拿一些非常強的模型（我們不會自己訓練模型），可能來自 Anthropic、Gemini、OpenAI 這些公司，有時候也會混用幾家模型。我們把 diff 喂進去；再把用戶自定義的規則和風格指南也喂進去；再把之前上傳 / 下載過的評論也一起納入；把這些東西拼起來，然后盡量在 PR 上給出有價值的反饋。”

特別優化的方向，是留下可執行、可落地的行內評論（actionable inline comments）。Greg 強調，如果對某個問題沒有足夠把握，Graphite 會選擇盡量保持安靜。因為在這類新興 AI 工具里，“信任”是硬通貨：信息對了當然很好，但錯一次就會迅速消耗耐心。因此他們寧愿少打擾，也要確保一旦開口，就“值得你停下來讀”。

從歷史上看，stacking 模式本身并不新。早期 Linux 內核通過郵件往返 patch，本質上就是最原始的 stack；更早還有 IBM 在 1970 年代提出的 Fagan Review：工程師把代碼打印出來，技術負責人逐行審，結果 bug 數量顯著下降。后來是 Google 的 Mondrian，再到 GitHub Pull Request。

真正變化的不是工程原理，而是協作“原語”的重心：行業逐漸從以 commit 為單位，滑向了以 branch / PR 為單位。Graphite 所做的，也不是顛覆 Git，而是把 Git 原本就隱含的“堆疊視角”重新拉回到工程協作層面：讓改動足夠小、可獨立 review，并且能更順滑地推進合并與交付

它最典型、也最成熟的落地之一正是 Facebook / Meta 的工程文化。Meta 和 Google 這類少數不依賴 GitHub 的公司，長期形成了相似的工具模式：stacking、inbox、精細化 merge queue、動態 CI……

這些方法存在了十年以上，過去只有處理百萬級提交的組織才“被迫”把它們用到極致；但在 AI codegen 把改動量抬上來之后，越來越多團隊也開始遇到同樣的外循環瓶頸——這正是 Cursor 選擇收購 Graphite 的意義。

即便最終只是一支擅長 code review 的團隊加入 Cursor，幫 Cursor 把產品打磨得更好，建立一個流程，避免他們繼續頻繁發 bug——那這筆收購都值了。如果他們能真正改變整個流程：從“我有個想法”→“我去實現”→“我發起評審”→“我合并上線”，把這整條鏈路都拉順，那可能會是巨大的變化。

https://fortune.com/2025/12/19/cursor-ai-coding-startup-graphite-competition-heats-up/

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

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

https://www.youtube.com/watch?v=7iNfTgF2hfg

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

https://newsletter.pragmaticengineer.com/p/stacked-diffs

技術人的年度儀式感！ 年度盤點與趨勢洞察 啟動！

《2025 年度盤點與趨勢洞察》由 InfoQ 技術編輯組策劃。覆蓋大模型、Agent、具身智能、AI Native 開發范式、AI 工具鏈與開發、AI+ 傳統行業等方向，通過長期跟蹤、與業內專家深度訪談等方式，對重點領域進行關鍵技術進展、核心事件和產業趨勢的洞察盤點。

力求以體系化視角幫助讀者理解年度技術演化的底層邏輯、創新方向與落地價值，并為新一年決策提供參考。內容將在 InfoQ 媒體矩陣陸續放出，歡迎大家持續關注。

今日薦文

你也「在看」嗎？