月合1000个PR:Cursor工程师如何让Agent变得可信

Cursor工程师用信任曲线、验证skill与分层约束,将Agent协作推进到每月千PR级别的自动合并。
一位Cursor工程师分享了他如何通过近一年的实践,将与AI Agent的协作从"微观管理每一步输出"推进到"Agent自动合并PR"的完整路径。核心方法论包含三层:首先建立验证能力,通过Feature Map和CDP工具让Agent能自主运行应用并抓取性能数据,把"验证者"角色从人手中解放出来;其次用Eval给Skill做单元测试,以爬山优化持续打磨skill质量;最后将约束固化进代码库架构、静态分析和CI,使"最快的路径"成为"最好的路径"。他强调信任是不可跳过的,从并行运行少数Agent到实现自动合并,需要品位、大量验证工程与分层护栏的共同支撑。
从微观管理到放手:一条信任曲线
一位来自 Cursor 的工程师在分享中抛出了一个惊人的数字:上个月他一共提交了 1000 个 PR,而本月刚到 12 号,就已经合入将近 800 个。更疯狂的是——他现在让 Agent 自动合并 PR,早上睁眼时已有约 20 个改动落地在 Main 分支上。
这听起来像是在批量生产垃圾代码,但他强调事实恰恰相反。走到这一步的核心,不是模型变强了多少,而是他沿着一条"信任曲线"一路爬了上来。
他用了一个非常贴切的类比:带团队。如果你是一个不信任下属的工程经理,你必然会陷入微观管理——花大量时间盯在别人肩膀后面,检查代码有没有把 bug 带到线上。跟 Agent 协作也是同理。一年前几乎没人真正用 Agent 写代码,那时你只能和一两个 Agent 死死绑在同一个回路里,盯着每一条输出,一遍遍写提示词,根本无法并行——因为你连一个 Agent 的输出都不敢信,又怎么可能一次拉起 100 个?
他坦言,写了很多年代码的工程师对"什么是好工程"有一大堆主张。当你看到 Agent 一本正经地胡说、第一百次信誓旦旦地宣称"找到了铁证"却根本不是真正的问题时,信任会流失得非常快。而一旦失去信任,Agent 的价值就无从谈起。
验证:Agent工具箱里最重要的能力
在他看来,与 Agent 协作时最关键的一项能力是验证(verification)。所谓验证,就是让 Agent 真正有能力把代码跑起来——去抓 CPU trace、拿 heap snapshot、打开 iOS 模拟器,以用户真实使用应用的方式实打实地跑一遍。
"这才是真正把闭环合上的那一步。它不能保证 Agent 写出好代码,但至少能让 Agent 写出正确的代码。"
他分享了一个 Cursor 内部的真实故事。五个月前刚入职时,他被临时调去做 agent window(内部代号 Glass)的 React 相关工作,而距离发布只剩一周。当时他只能打开 Chrome DevTools 的性能面板,盯着火焰图硬看,试图找出性能瓶颈。他把 trace 截图和文件喂给 Agent,Agent 非常笃定地说"就是这个问题",但改完发现根本不是。整个过程极其缓慢——你自己才是那个验证者,你就是瓶颈。
于是他写下了 Cursor 最早的一批 skill 之一:control glass。这个 skill 本身代码并不复杂,教会 Agent 使用 Chrome DevTools 协议(或苹果那边的模拟器工具)即可。

Feature Map:让Agent学会"导航"产品
真正的关键在于 skill 里附带的一个特殊文件——Feature Map(功能地图)。他发现,即便 Agent 能把应用跑起来、能抓 trace,它压根不知道 agent window 到底是个什么东西。用户反馈"左边侧边栏有点卡"或"右边 PR 页签用不了"时,Agent 只会疯狂翻代码、乱点界面,完全找不到目标位置。
Feature Map 解决了这个问题:它教会 Agent 如何走到产品里的每一个功能——侧边栏是什么、下面有哪些子功能、从用户视角要怎么一步步点进去、快捷键是什么、甚至连通过 CDP 选中元素时用到的 data 属性都写在里面。
有了这份地图,哪怕用户只丢来"一张截图配三个问号",Agent 也能把模糊描述对应到具体功能上。他将这套能力封装进了自己开源的插件 PStack(potato stack,一个致敬 Y Combinator CEO Gary Tan 的 gstack 的玩笑名字),其中 create verification skill 能自动探索代码库、生成初始功能地图,maintain verification skill 则负责持续维护。
用Eval给Skill做"单元测试"
面对"产品一直在变,skill 如何维护"和"如何相信验证本身足够好"这两个问题,他给出的答案是 Eval。
他的心智模型很直接:Eval 就相当于给 Agent 写的单元测试。你不需要什么专门框架,想做得多严谨都可以。他的具体做法是:让主协调 Agent 先针对 skill 目标制定一份评分标准,再拉起一大批子 Agent,每个子 Agent 单独建一个精心命名的目录——
"目录名是精心起过的,为的是不让子 Agent 察觉到自己正在被考核。因为 Agent 一旦察觉,行为就会变。"
借助 Cursor 支持多模型的优势,同一个 skill 可以在整个模型矩阵上都跑一遍,摸清它在不同模型上的表现。每次改动 skill,他都会跑一遍对应的 eval playbook 来确认结果符合预期。

更进一步,Eval 能产出一个分数,这意味着你可以对它做"爬山优化(hill climbing)":让 Cursor 的 sash loop 盯着这个 eval 一直循环,直到每一项都拿满分。为避免打分模型偏袒,还可以再放一个用不同模型的裁判 Agent 做交叉核对。
他强调,维护 skill 是相当难的事,需要大量的"品位"和观察。在早期攒 skill 的阶段,你必须牢牢坐在驾驶位上——把所有工具调用展开来读、读代码、读 Agent 的思考过程,看清它们究竟栽在什么地方,然后针对性地写 skill。
重构、护栏与架构:把约束固化进代码
分享中最有争议的部分,是关于重写与重构的观点。传统智慧几乎一致劝人"别重写",但他认为在 Agent 时代要看具体情况。
他把问题拆成两类应用:
- 存量大厂应用(如 Meta 的巨型单体仓库):这类系统本来就是照着"迁就团队里能力最弱的工程师"的前提设计的,充满了框架、规范和护栏。"在有 AI 糊弄之前,我们早就有人类糊弄了。"正因为护栏齐全,Agent 在这里反而能干得相当不错。
- 全新的绿地项目:风险最大也机会最大。纯靠 vibe coding 堆出来的应用没有任何护栏,Agent 会用最省事的路径解决问题,时间一长代码库彻底失控——他称之为"有机架构"。

他用 Grokbot(内部架构代号 Dune)作为正面案例,展示了如何把约束硬性固化。他为整个代码库重构投入了超过 600 个 PR,如今已经到了"基本不看代码"的地步。这套架构的核心原则是:
"最短的那条路径,就是最好的路径。因为 Agent 天生喜欢抄近路,那就把最快的路直接修成最好的路。"
分层的约束体系
他提出了一个分层模型,从硬到软:
- 代码库架构本身(最硬约束):一个 feature 的全部代码就近放在同一个目录里,Agent 只需在这一个目录干活,80% 的工作就被封装好了。
- 静态分析与CI检查(会让 CI 变红):比如在 Dune 里直接禁用 useEffect、禁止代码注释(因为 99% 的 Agent 注释都在描述无关历史),以及通过依赖图检查强制 Electron main 线程与 render 线程的进程隔离——这源于 agent window 反复出现的性能退化教训(每帧必须在 16ms 内完成)。
- Rules、Skill、Bugbot(偏软约束):Agent 仍可能忘记或执行不一致,只能作为叠加手段,不能当唯一强制。

他的核心方法论是:每次你不得不在 PR 评审里留言指出问题,都该把它当成一种"代码坏味道"——问自己能不能把这条变成一个硬规则、一条 lint 规则、一次 CI 失败,从根上彻底消灭。这也是为什么技术栈选择很重要,比如 Rust 的编译器极其严格,只要代码能编译通过、不写 unsafe 块,你就有几分底气它能跑。
Token成本与ROI:值不值得这么做
面对"普通人没有无限 token"的现实质疑,他坦承自己在 AI 实验室工作、token 无限,绝不建议所有人原样照搬。但他认为不烧穿钱包也能走到这一步,关键是把它当作一个 ROI 问题。
前期确实要花不少 token——重构整个代码库、逐条加约束。但如果你正走向一个"Agent 写掉所有代码"的世界,又想保持精简(不想变成一个一万人的工程组织),那么真正的权衡是:
"你是花钱招一个人来做这件事,还是把这些 token 花出去,把代码库整治到连最笨的 Agent 都能干得不错的程度?"
他强调,Agent 的价值本质在于让你做到以前做不到的事,而不是在鸡毛蒜皮上省 token。靠他一个人手动搭这套框架、做完所有重构和验证,得花好几年。而现在这套投入的回报不只在他自己身上——产品经理、设计师、甚至不熟悉 Grokbot 的工程师,都能以很高的水准直接提交代码并上线。
他也顺带提到刚发布的 Grok 4.6:在各项基准上表现优异,而单位 token 价格与 4.5 持平——用同样成本换到更高智能,这正是在"成本与智能的帕累托前沿"上做优化的思路。
结语:信任无法被跳过
这场分享最有价值的洞见,或许是那句"没有捷径"。从盯着两三个 Agent 的每一步,到让它们自动合并 PR,这条路取决于你个人对 Agent 的信任程度,而信任需要品位、判断力,以及大量的 skill 与验证工程去支撑。
他给出的清晰路线是:先在本地建立验证能力(确保 Agent 至少产出正确代码),再扩展到云端(让 Agent 自动接收反馈、复现问题、给出 PR),最后才是自动合并。他强烈警告不要一步跨过去——否则只会白白烧掉大量 token。
对于此刻还停留在"本地跑两三个并行"阶段的大多数工程师而言,真正该做的第一件事,是把那些反复出现的评审意见变成硬性约束。因为归根到底,这一切都回到"信任"两个字:当你能把自己对好工程的标准全部编码进 skill,并验证 Agent 确实照做了——你才能真正沿着这条曲线往上爬。
相关推荐

Harbor:统一80+基准的AI Agent评估框架详解
深入解析Harbor Adapters和Harbor-Index如何通过统一适配器层整合80+基准测试,开展8模型×54基准的大规模AI Agent评估实验,并构建82个高质量任务的元数据集,推动Agent评估标准化。

日元跌破160关口:央行干预为何难挡贬值趋势
日元兑美元再度跌破160关键心理关口,日本央行外汇干预效果被迅速侵蚀。本文深入分析美日利差、套利交易、输入型通胀等核心因素,解读日元持续走弱的结构性原因及未来走势展望。

Grok代理模式实测:一句话自动生成完整视频流程详解
实测Grok 4.6代理模式,用一句话自动完成儿童睡眠视频制作全流程。详解图片生成、视频转换、配乐拼接的自动化效果,以及SUNO配乐协同和剪辑优化技巧。