Cursor收购Graphite：AI加速代码生成，代码评审成工程新瓶颈

12 月 19 日，AI 编程工具头部公司 Cursor 正式宣布收购代码评审平台 Graphite，意图打通从代码生成到合并上线的全链路。

Cursor 的核心价值在于编程阶段实时辅助开发者；Graphite 则专注于代码完成后的评审流程，帮助团队高效判断变更是否具备上线条件。Graphite 联合创始人 Tomas Reimers 与 Cursor CEO Michael Truell 达成一致判断：随着 AI 大量介入编码，代码产量飞速提升，评审工作只会成比例增长，而非减少。

在 AI 将代码编写速度推至新高度的同时，代码评审这一环节却仍停留在多年前的工作方式上，逐渐成为团队交付压力的主要来源。Michael Truell 在公开声明中指出：“过去两年半里，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 月又从 AI 初创公司 Koala 引入一批技术人才。

根据双方披露，Graphite 将继续以独立产品形态运作，同时与 Cursor 代码编辑器深度集成。此前 Graphite 已提供 VS Code 扩展，用户可在 VS Code、Cursor、Windsurf 等编辑器中直接安装使用。

未来数月，双方计划重点优化 stack PR 平台与 merge queue，并在 Cursor 与 Graphite 之间构建精心设计的集成机制，将本地开发、后台 Agent 和 Pull Request 有机串联。同时，借助 Cursor 在代码模型方面的积累，进一步提升 Graphite 的 AI 能力，并将 Graphite 的 AI Reviewer 与 Cursor 的 Bugbot 融合，打造业界最强的 AI 代码审查工具。

这笔交易事实上将 AI 时代“编写、评审、合并”三大核心环节的最佳实践整合在了一起。此前 Cursor 仅深度参与了“编写”环节，而评审与合并正是 Graphite 的专长领域。交易完成后，Graphite 全员将加入 Cursor，持续推动相关产品研发。

1

写代码“一把梭”之后，代码评审已成为交付链条的最大短板

AI 编程工具的迭代速度，已是整个科技行业中最为剧烈的领域之一。

任何有过开发经验的人都清楚，代码评审是一项极不稳定的活动：最终效果高度依赖评审者的意愿、投入程度与专业判断，有时你甚至只会收到一条“LGTM（Looks Good To Me）”。如今，AI 生成的代码量呈指数级上升，且大语言模型天然倾向于产出冗长的实现，这使得评审环节反而成为最被低估却又最为关键的卡点。

Graphite 提供的数据显示，与 2023 年相比，现在每位工程师产出的代码量平均增长了约 70%。核心矛盾在于：代码可以近乎无成本地膨胀，而工程师的时间依然是人力尺度的时间。一线开发者不得不在评审上投入更多精力；系统层面，合并队列、冲突处理、自动化机器人带来的连锁反应也急剧增加，整个交付体系正承受前所未有的负荷。

更隐蔽的变化是信任模式的瓦解。过去，面对同事提交的 PR，你往往能预判他的思路与习惯。但现在，这种确定性正在消退——代码可能出自工程师之手，也可能只是他不断按 Tab 键接受 AI 补全的产物；极端情况下，一段代码甚至从未经过人类认真审视，而你恰好是第一个阅读它的人。

与此同时，上下文信息的流失正在加剧。当开发者独立编写代码时，往往会自然吸收代码库的结构逻辑与演进脉络；而代码评审本应成为团队内二次分发这些上下文的渠道——通过审视他人的改动，重新理解系统为何如此设计、未来向何处演进。

但如果编写过程并非建立在主动、清晰的思考之上，而是大量代码被半自动生成、半被动接纳，那么团队整体能够掌握的上下文就会日益稀薄。久而久之，没有人能清晰回答：代码库里到底发生了什么、系统为何演变成当前形态。这是一个随时间推移极具危险性的隐患。

正因如此，代码评审系统的负担显著加重；合并系统、部署系统的压力也在同步攀升。软件开发中整套“外循环”（outer loop）正在遭受挑战，并频频卡顿。

面对这种新局面，越来越多团队意识到：将 AI Agent 视为“自动驾驶”并不现实；它更像一群“初级、异步、数字化的新员工”——你可以一次派出多个 Agent 同时工作，但它们天然缺乏上下文、欠缺架构性思维，也更容易在关键细节上“脱轨”。

真正拉开差距的最佳实践反而相当朴素：中间环节可以交给 Agent，但起点与终点必须由人来把控。

起点通常需要资深工程师（Staff 级别或以上）将上下文梳理清晰——包括设计文档、约束原则、依赖核查、任务分解——确保 Agent 在充分理解后再动手实施；终点同样需要强有力的工程师守住质量关卡（评审、CI、回归定位与迭代优化），确保每一次合并都能被追溯、解释、兜底。这也是为何资深工程师往往能与 AI Agent 形成最高效的协作：他们不仅能在输入端把问题界定清楚，还能在输出端有效控制风险。

目前一种非常实用的协作模式是：先认真撰写一份 markdown 设计文档，再将其交给 Claude Code 或 Cursor 执行。但正因为生成代码变得太过容易，让 Claude Code、Cursor 这类工具一次性输出两三千行的 PR 已非难事。面对如此规模的改动，人类评审者极易视觉疲劳，最终仍以一句“LGTM”收场，或者干脆“看不完，直接合了吧”。

这种“外循环被堵死”的现实，很快也投射到了 Cursor 自身。T3 Chat 创始人、Cursor 投资人 Theo 在一场分享中直言：Cursor 对“更快交付、构建更多功能”至关重要，但你甚至能从编辑器本身感受到这种压力——“它看起来就像在慢慢散架”。

他提到，上周一他特意带团队去了 Cursor 办公室，连续吐槽了两个小时他们在使用中遇到的各种缺陷。Cursor 团队随后承诺，暂时放缓新功能开发，进入“硬核修 bug 模式”，并每天同步修复进展：已修了哪些 bug、新发现了哪些 bug、下一步计划如何处理。“他们确实在极其认真地解决这些问题。”他评价道。

也正是在这个背景下，他在 X 上调侃道：“Cursor 的 bug 太多了，所以他们买了一家 code review 公司来修它。”

这固然是句玩笑，但玩笑背后并非没有现实逻辑：当代码生成量激增、交付节奏被拉到极限，代码审核便成为系统中最为拥堵的路段，即便对于以高频迭代著称的 AI IDE 同样如此。

2

Graphite：源自 Meta 的代码评审工程哲学

如果仅从当前定位出发，很容易误以为 Graphite 是一家“为 AI 时代而生的代码评审公司”。但事实上，Graphite 的起点完全不是“代码审查”。

这家公司最初致力于为移动应用 QA 团队打造工具，创始团队由曾在 Apple、Meta 等大型科技公司任职的工程师组成。离开大厂后，他们强烈感受到“熟悉的开发体验突然消失”的落差。

在他们眼中，Meta 内部的开发者工具链几乎属于“另一个世界”。若未亲历过那套体系，可以通过一个直观类比来理解：GitHub 在 2011 至 2013 年间定义了 Pull Request 协作范式，而 Meta 内部也构建了类似功能——但区别在于，Meta 此后从未停止对这套工具的持续进化。

而 GitHub 在代码评审领域的迭代，“很多东西很久没怎么动过了。”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 工具中，“信任”是硬通货：信息正确当然很好，但错一次就会迅速消耗耐心。因此他们宁愿少打扰，也要确保一旦开口，就“值得你停下来读”。

3

写在最后

从历史上看，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