Cursor大神实战：如何用Grok Bot一月合入2000个PR

SpaceX AI 的 GrokBot 工程师 Lauren（X 上 ID 为 Poteto）在一次技术分享中抛出了一个惊人数字：上个月，她向生产环境合入了 2000 个 pull request。这不是靠加班堆出来的，而是靠一套完整的"信任"体系——把自己作为工程师的全部知识，注入到一支由 AI Agent 组成的"团队"中。

她拒绝"软件工厂"这个说法，更喜欢用"米其林厨房"来打比方：工程师不再亲手烹饪每一道菜的原料，但依然对最终成品负责，关键在于如何布置厨房、训练厨师、配置设备。这篇文章梳理她分享中最核心的方法论。

一切的核心是"信任"

Lauren 认为，从"1 到 5 个 Agent"跃迁到"100 个 Agent"的最大障碍，不是算力也不是工具，而是信任。在早期阶段，你必须盯着每一个对话、不断纠正 Agent，一旦离开它们就会出错。她直言这个阶段"最难走出来"，因为路径并不清晰。

如果你不信任 Agent 的产出，却贸然启动 100 个子 Agent 或云端 Agent，结果只会是海量的回归 bug 和一堆没人满意的代码。所以真正的问题是：如何让自己更信任 Agent？

她的答案分成几个可操作的层次，而这套方法正是她能在一个月内处理 2000 个 PR 的底层逻辑——"我意识到我自己才是瓶颈，我需要把工程师的知识灌输给我的 Agent 团队，这样我就不必成为每件事的阻塞点。"

验证技能：让 Agent 自己证明代码能跑

六个月前 Lauren 刚加入 Cursor 时，负责优化 Cursor Agent 窗口的性能问题。她很快发现，面对不断涌入的 PR，手动用 Chrome DevTools 排查性能就像面对"一堵永远推不倒的墙"。

于是她构建了第一个验证技能（verification skill），代号 Control。它通过 Chrome DevTools Protocol 教会 Agent 自己运行应用、采集性能 trace、抓取内存快照，并定位性能热点。这个技能有两个关键组件：

一个 CLI：放在 skill 目录里，让 Agent 每次都能可复现地运行应用、收集"代码确实能工作"的经验证据，而不是每次临时写脚本、在不同会话间产生差异。
一个 Feature Map：这是她自创的概念，类比网站的 sitemap。它是一种"物化记忆"，记录应用有哪些功能、用户如何触达（键盘快捷键、要点击哪个 DOM 元素）、每个功能做什么，并由自动化持续维护。

CLI 放在 skill 目录中供 Agent 复用

当 CLI 和 Feature Map 结合，Agent 不仅能可复现地操控应用、采集数据，还能理解内外部用户提交的模糊需求（比如一张截图加三个问号的 Slack 报告）。Control 技能因此成了团队的"关键基础设施"。

验证解决的是"正确性"——这个功能到底能不能用，结账按钮到底会不会结账。但它管不了性能和代码质量。

Chrome DevTools Protocol（CDP）是 Chrome 浏览器暴露的一套底层调试接口，允许外部程序以编程方式控制浏览器的几乎所有行为——包括页面导航、DOM 操作、网络请求拦截、JavaScript 执行、性能 trace 录制和内存快照抓取。通常开发者需要手动打开 DevTools 界面才能获取这些数据，而 CDP 让这一切可以自动化、可编程地完成。Lauren 利用 CDP 构建的 CLI，本质上是让 AI Agent 拥有了一双"会操作浏览器"的手和一套"会读性能数据"的眼睛——Agent 不再需要人类坐在旁边打开 DevTools 截图告知结果，而是可以自主完成"运行 → 采集 → 分析"的完整闭环。这正是"验证技能"得以规模化的技术基础。

让 Agent 像真正的软件工程师那样写代码

验证之上，Lauren 构建了一个名为 P-Stack 的插件，本质是一组技能集合，把她多年在不同平台做软件工程的工作流沉淀下来——调试、功能开发、原型设计等等，每种任务都有对应的 playbook 和 skill，教 Agent "按你想要的方式写代码"。

她强调，这正是团队里资深工程师能发挥价值的地方：搭建一个团队共享的技能仓库，让所有 Agent 一下子变聪明。当质量技能与验证技能叠加，Agent 就能既证明代码正确，又能采集真实的性能指标和遥测数据来保证质量。

重构架构，让代码库对 Agent 友好

信任的五个层次：从代码库到风格指南

Lauren 给出了一个"信任阶梯"，按有效性从高到低排列，这也是她建议的投入顺序：

代码库本身：这是 Agent 最好的记忆形式。LLM 天然倾向于扩展它在上下文中看到的既有模式，而 Agent 读取的文件就是上下文的一部分。所以要让好模式无处不在。
静态分析：linter、编译器诊断、CI。当 Agent 反复犯同一个错，就把它写成 lint 规则；更好的做法是重构代码库，让这个错误"在类别上不可能发生"。
规则、Bug Bot、技能：属于"引导"而非"硬约束"，Agent 大多会用，但也可能忘记读某条规则。
风格指南：只能靠人在 code review 中执行。在 PR 洪流下，指望人逐行 review 根本不现实。

她特别提醒：不要只依赖风格指南。人工 review 只适合用来发现"缺了什么"，真正该投入时间的是前几层。

DUNE 框架：让"捷径"就是"正路"

GrokBot 的底层架构叫 DUNE，是团队打造的"Agent 友好框架"。它的核心洞察是：Agent 特别爱走捷径。那么，如果我们把框架设计成"最简单的路径恰好就是正确的路径"呢？

为 Agent 收益而设计的代码库

DUNE 的代价是它对人类工程师并不友好——极度锁死、限制重重，但恰恰因此为上下文极少的 Agent 创造了完美环境。Lauren 指出，未来代码库的贡献者不再只是工程师，还可能是设计师、产品经理甚至 CEO，所以必须让"没什么上下文的忙人"也能默认写出好代码。

DUNE 的架构还硬性隔离了很多东西，比如 Electron 中主进程的代码不允许被渲染进程导入。这源于 Cursor Agent 窗口的教训：慢代码一旦被误引入渲染线程，就会拖垮 UI 流畅度。要保证 60 帧就得让每帧任务不超过 16 毫秒，120 帧则是 8 毫秒。DUNE 通过导入和依赖图强制执行这些边界。

渲染线程的帧率与毫秒约束

Electron 是一个用 Web 技术（HTML/CSS/JavaScript）构建跨平台桌面应用的框架，其架构分为两类进程：主进程负责操作系统级别的任务（文件系统访问、原生窗口管理、进程间通信等），渲染进程则运行每个界面窗口的 UI 代码，本质上是一个沙箱化的 Chromium 浏览器实例。两者之间有严格的安全边界，通信需要通过 IPC（进程间通信）机制。Cursor 本身就是基于 Electron 构建的编辑器，因此其性能瓶颈与 Electron 架构直接相关：一旦计算密集型代码（如文件索引、语法分析）被错误地引入渲染进程，就会阻塞 UI 线程，导致掉帧、卡顿。DUNE 通过静态分析导入关系、在构建期强制隔离两类进程的代码，从架构层面消除了这类错误的可能性。

反模式会像病毒一样扩散，你需要一个"园丁"

Lauren 用"花园"作比：代码库里那些看似无害的 workaround，会因为 Agent 爱抄袭既有模式而疯狂扩散，几天内就变成"事实标准"，最后留下一个难以维护、性能糟糕的"氛围编码"代码库。

她举了一个非常反直觉的例子——Agent 在代码里写注释。起初她觉得这挺像人类工程师做的事，但很快发现 Agent 常把注释当成"为什么不真正解决问题"的借口，用一句注释把临时补丁合理化。于是在 DUNE 里，他们干脆禁止写注释。

因此她主张每个团队都需要一个"园丁"角色，及时把杂草、害虫"扼杀在萌芽状态"。DUNE 的三条原则是：

删除已有的技术债；
为最佳实践强制"单一铺好的路径"，让 Agent 无需猜测；
一旦发现坏模式，第一反应是写 lint 规则"止血"，不一定要立刻清理，但至少阻止它蔓延。

目标是让代码库始终保持在"即便 Agent 照抄你也满意"的状态。

外循环：用 GrokBot 把一切串起来

如果说 Cursor 提供了写代码的"内循环"，GrokBot 则擅长"外循环"。它能连接 Slack、Datadog、Sentry、PlanetScale 等各种服务，聚合信息做决策。有人称之为"公司大脑"，但 Lauren 认为不必搞得那么复杂——Agent 本就擅长用工具。

通过 GrokBot Routines，你可以订阅 Slack 线程、Sentry 告警，自动触发云端 Agent；再配合 Cursor Automations 和 SDK，就能搭建更多复用同一套 Agent 基础设施的 Bot。她展示的自动化案例包括自动复现 bug 报告、自动开 PR，为整个团队持续创造价值。

她最后强调，无需投入大量基础设施，靠这些相互复利的组件——代码库、规则、技能——就能为自己搭起一个"个人米其林厨房"。

内循环（inner loop）与外循环（outer loop）是软件工程中描述开发节奏的常用概念。内循环指单个开发者在本地完成的高频迭代：编写代码、运行测试、调试、再修改，通常以秒或分钟为单位。外循环则指跨越团队和系统边界的低频协作流程：代码审查、CI/CD 流水线、监控告警响应、跨服务数据聚合等，通常以小时或天为单位。Cursor 作为 AI 辅助编码工具，主要加速的是内循环——帮工程师更快地写出和修改代码。GrokBot 则专注于外循环的自动化：它监听来自 Slack 的团队讨论、Sentry 的错误告警、Datadog 的性能指标，自动触发 Agent 进行分析和响应，从而让工程师从大量重复的"信息搬运和初步判断"工作中解放出来。两个循环的有机结合，正是 Lauren 能以一人之力处理 2000 个 PR 的完整闭环。

唯一要记住的一张幻灯片

Lauren 说，如果只带走一个要点，那就是：每当你在纠正、干预 Agent 时，按"代码库架构 → 静态分析 → 规则/Bug Bot/技能"的顺序思考，找出最有效的那一步去提升信任。当你把这些层次都做到位，环境就足够可信，你的 Agent 便可以"自由奔跑"。

这不是什么秘密，而是大量扎实的工程投入。正是这套体系，让一个人一个月合入 2000 个高质量 PR 成为现实。