編譯 | Tina

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

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

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

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

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

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

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

這筆交易相當(dāng)于是把 AI 時代“創(chuàng)建、評審、合并代碼”的最佳工具組合到了一起。這三件事里，Cursor 實際上只做了其中一件——寫代碼，另兩件則是 Graphite 的強(qiáng)項。交易交割后，整個 Graphite 團(tuán)隊都會加入 Cursor 繼續(xù)推進(jìn)相關(guān)產(chǎn)品研發(fā)。

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

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

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

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

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

與此同時，上下文正在快速流失。當(dāng)我們自己寫代碼時，往往會順帶把代碼庫的結(jié)構(gòu)、演進(jìn)脈絡(luò)這些上下文一起“吸收”進(jìn)去；而 code review 也會在團(tuán)隊協(xié)作中把這部分上下文再“分發(fā)”一輪——你在 review 別人的改動時，會重新理解一遍系統(tǒng)為什么這么設(shè)計、現(xiàn)在往哪里走。

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

因此，code review 系統(tǒng)的負(fù)擔(dān)更重了；合并系統(tǒng)、部署系統(tǒng)也更重了。軟件開發(fā)的那整套“外循環(huán)”（outer loop）正在被挑戰(zhàn)、被卡住。

在這種新負(fù)載下，很多團(tuán)隊開始意識到：把 agent 當(dāng)成“自動駕駛”是不現(xiàn)實的，它更像一群“初級、異步、數(shù)字化員工”——你可以一次性放出一群去干活，但它們天然缺上下文、缺架構(gòu)性思考，也更容易在關(guān)鍵細(xì)節(jié)上“跑偏”。

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

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

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

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

他提到他上周一還專門帶著團(tuán)隊去了 Cursor 辦公室，坐下來連續(xù)吐槽了兩個小時他們在使用過程中遇到的各種 bug。Cursor 團(tuán)隊隨后承諾，接下來一段時間將暫緩新功能開發(fā)，進(jìn)入“硬核修 bug 模式”，并且每天同步修復(fù)進(jìn)展：修了哪些 bug、發(fā)現(xiàn)了哪些新 bug、下一步準(zhǔn)備怎么處理?！八麄兇_實在非常認(rèn)真地解決這些問題?！彼u價道。

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

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

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

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

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

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

而 GitHub 在 code review 這塊，“很多東西很久沒怎么變了?！?/strong>在 Tomas Reimers 看來，當(dāng)他們說“Facebook 的工程工具在創(chuàng)新層面領(lǐng)先將近十年”時，那就是字面意義的“領(lǐng)先十年”。

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

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

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

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

最終，2021 年 11 月，團(tuán)隊做出了轉(zhuǎn)型決定：把 Pancake 從一個高度定制的內(nèi)部工具，打磨成一款真正對外的代碼評審產(chǎn)品。那是一段高度集中的工程沖刺期——需要把所有“寫死在內(nèi)部場景里”的假設(shè)逐一剝離，把只服務(wù)自家工作流的工具，改造成任何團(tuán)隊都能接入、可規(guī)?；\(yùn)行的系統(tǒng)。

為什么是 stacking

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

Tomas Reimers 在 Meta 工作了兩年半，他對 stacking 的解釋非常直白：“作為一種方法論，stacking 讓開發(fā)者能夠繞開對 main 分支的依賴所帶來的延遲，從而實現(xiàn)真正的、持續(xù)的并行開發(fā)?！?/p>

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

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

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

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

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

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

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

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

當(dāng)你開始讓 coding agent 去堆疊改動、把一個大任務(wù)拆成很多小 PR，它會開始在這些 stacks 之上應(yīng)用一種“鏈?zhǔn)剿伎肌?。你能看到它會自己拆步驟：“好，先寫函數(shù)；然后寫單測；然后在其上加 endpoint……”它開始模塊化、逐步測試、逐步推出。而且事實是：AI 這樣做出的結(jié)果往往比你讓它“一把梭”生成一個大 PR 更好。

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

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

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

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

3 寫在最后

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

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

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

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

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

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

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

技術(shù)人的年度儀式感！ 年度盤點(diǎn)與趨勢洞察 啟動！

《2025 年度盤點(diǎn)與趨勢洞察》由 InfoQ 技術(shù)編輯組策劃。覆蓋大模型、Agent、具身智能、AI Native 開發(fā)范式、AI 工具鏈與開發(fā)、AI+ 傳統(tǒng)行業(yè)等方向，通過長期跟蹤、與業(yè)內(nèi)專家深度訪談等方式，對重點(diǎn)領(lǐng)域進(jìn)行關(guān)鍵技術(shù)進(jìn)展、核心事件和產(chǎn)業(yè)趨勢的洞察盤點(diǎn)。

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