Grok Bot 实战：Lauren Tan 的 AI 自主交付代码方法论

从「人肉验证」到「一觉醒来 20 个 PR 已合并」

Cursor 工程师 Lauren Tan 在分享中抛出了一个让许多工程师既兴奋又警惕的场景：她早上醒来时，发现 agent 已经自动合并了约 20 个 PR，而且质量都不错。上个月她个人合并了约 1000 个 PR，本月才到 12 号就已经接近 800 个。

这听起来像是「AI 垃圾代码制造机」的极端案例，但她的核心论点恰恰相反：高 velocity 的前提是先建立起对 agent 的信任，而信任来自可验证的工程约束。她把这条路径类比成技术管理——如果你不信任手下的工程师，你只能微观管理，盯着每个人的屏幕；只有当信任建立起来，你才能真正并行化，把工作交给更多执行者。

这条「信任曲线」与她在 Cursor 五个月的贡献量几乎反向同步：刚入职时对代码库不熟、对 agent 也不信任，产出很低；随着验证能力和约束体系逐步完善，产出才快速爬升。

验证（Verification）是最重要的基本功

Lauren 认为，与 agent 协作时最关键的技能是验证：让 agent 能够真实运行代码、抓取 CPU trace、生成 heap snapshot、启动 iOS 模拟器，以及用一切用户触达产品的方式实际测试。

验证不能保证 agent 写出「好代码」，但能保证它写出「正确的代码」——这是信任的前提。她用自己的亲身经历说明了缺失验证的代价：加入 Cursor 第一周就被拉去做 agent window 的性能优化，她手动打开 Chrome DevTools 抓 trace、看 flame graph，再把截图发给 agent。agent 每次都「自信地」指出问题所在，但修完发现根本不是那个原因。

在没有验证 skill 的情况下，人就是验证器，也是整个流程的瓶颈。你让 agent 写代码，然后自己打开本地 dev build 检查，再把截图和 console 错误复制给 agent，循环往复——这样根本不可能并行化，更不可能扩展到几十上百个 agent。

Chrome DevTools Protocol (CDP) 是 Chromium 浏览器暴露的一组底层调试接口，允许程序化地控制浏览器、检查 DOM、抓取性能 trace、模拟用户输入等。在 agent 协作场景中，CDP 使 agent 能够像人类开发者一样打开 DevTools、录制性能剖析、读取 console 错误，而无需人工截图转发。类似地，Apple 的模拟器工具（如 xcrun simctl）让 agent 可以启动 iOS 模拟器、安装应用、截屏和注入事件。这些接口把原本依赖人眼和手的验证动作转化为 agent 可调用的工具，是构建自动化验证 skill 的技术基础。

两个关键 Skill：控制应用 + 功能地图

Lauren 为 Cursor 内部代号 Glass 的 agent window 构建了第一个控制类 skill：教 agent 通过 Chrome DevTools Protocol 或 Apple 的模拟器工具，以编程方式控制应用、抓取 trace。

但光能控制应用还不够。agent 虽然能启动 dev build，却不知道「左侧边栏」指的是什么、怎么在 UI 里导航到某个功能，于是只能到处乱点。为此她引入了 feature map：一份告诉 agent 如何抵达所有功能的文件，包含用户视角的入口、快捷键，甚至用于 CDP 选择元素的 DOM 属性。

这个组合在真实工作流中威力很大。Cursor 内部有一个收集反馈的 Slack 频道，很多报告质量极差——一张截图配三个问号。有了 feature map，agent 才能把模糊报告映射到具体功能模块，真正去复现问题。

她把这些能力打包成了插件 PStack（名字是调侃 Y Combinator CEO Gary Tan 的 GStack，两人同姓但无亲属关系）。PStack 提供创建和持续维护验证 skill 的能力，可以自动探索代码库生成初始 feature map。

用 Eval 像单元测试一样测试 Skill

Skill 本质上是 markdown 文件，承载指令和上下文。Lauren 引用社区的说法：给 agent 高质量的 token 开头，相当于把它「拉到一个更聪明的潜空间」里做模式匹配。

但 skill 会随产品演进而失效，所以需要 eval。她的心智模型是「eval 就是 agent 的单元测试」，PStack 中的 eval playbook 做法相当严谨：主协调 agent 先产出评分 rubric，再派生出多个子 agent 在各自目录中执行任务，目录命名会刻意避免让子 agent 意识到自己正在被评估——因为 agent 一旦察觉，行为会改变。

一个巧妙之处是利用 Cursor 支持多模型的特性，把同一个 skill 放到不同模型矩阵上评测。还可以用不同模型的 judge agent 交叉校验，避免评分偏差。更进一步，可以用 /loop 让 eval 持续循环爬山，直到全部达到满分。

她坦言维护 skill 很难，需要大量「品味和观察力」——要像结对编程时坐在同事旁边那样不断追问，而不是做被动观察者。打开所有 tool call、读 agent 的思考块，才能发现它在哪里偷懒、在哪里猜测。

潜空间（latent space） 是神经网络内部表示的高维向量空间。模型在生成时，输入 token 会映射到该空间中的某个区域，后续输出基于此进行模式匹配。给 agent 高质量的指令和上下文（如精心编写的 skill markdown），相当于将其引导到训练数据中更优质模式所在的区域，从而提升输出质量。这就是「把 agent 拉到更聪明的潜空间」这一比喻的含义——并非模型本身变聪明，而是输入分布使其激活了更可靠的生成路径。

LLM-as-a-judge 指用另一个大模型对目标输出进行评分或比较，替代人工评估。在 eval 中，judge agent 根据 rubric 打分。为避免单一模型的偏好偏差，可用不同模型交叉校验，取共识或平均分。但需注意 judge 本身也可能存在位置偏差、冗长偏好等问题，因此 rubric 的设计和 judge 的校准同样重要。

云 agent 与自动合并：信任的杠杆效应

验证 skill 的价值不止于个人效率。Lauren 目前已基本全面转向云 agent，因为云 agent 能把个人能力放大到整个团队。

她举了内部 agent「Benny」的例子：Benny 接收所有 bug 报告，在云端的独立桌面环境中运行 Cursor，用同一套控制 skill 操作应用复现问题。有一次 Benny 成功复现了 bug，同时发现它在当前分支上已被修复，于是只需要再发一个 build 即可——这个结论原本需要人坐下来花一小时确认。

节奏上她给出了清晰的路径：先在本地建立验证能力，观察 agent 如何与应用交互；信任建立后再扩展到云端 agent 和自动化；最后才是让 agent 自动合并 PR、自己在 main 上做后置 review。她特别警告不要跳过阶段——在没有建立起对一个 agent 的信任时就 spawn 成百上千个云 agent，只会浪费大量 token 且成本高昂。

重构与「有机架构」：约束才是生产力

Lauren 提出了一个反直觉的观点：棕地应用（brownfield）反而处于有利位置，绿地应用风险最大。

大厂的基础设施本来就是为「团队里能力最弱的工程师」设计的——框架、约定、guardrail、凭证限制，目的是防止实习生清空生产数据库。这些约束对 agent 同样有效，甚至更有效，因为 agent 非常擅长模仿既有模式。

真正的危险来自 vibe coding 出来的原型。Grok Bot 就是一个典型案例：极短时间内快速搭建，人类几乎没读代码。她称之为「有机架构」——agent 总是选择最方便的方式解决问题，日积月累，代码库会螺旋失控，因为没有人真正理解它。

她的解法是为 Grok Bot 构建了一套叫 Dune 的架构，可以理解为「面向 Electron 应用的 Next.js」，专为 agent 编写而设计。核心是让最短路径恰好是最好的路径：既然 agent 爱抄近道，就把正确做法设计成近道。

具体约束包括：

• 每个 feature 的所有代码集中在单一目录，80% 的工作都在封装范围内完成
• 禁止使用 useEffect——React 最大的 foot gun，CI 直接失败
• 禁止写代码注释——她发现 99% 的情况下 agent 写的注释描述的是无关的历史信息，甚至会把某次 review 的临时意见当成永久规则
• ElectronMain 与 ElectronRenderer 目录之间的 import 由 CI 检查依赖图强制阻断，防止计算密集或 IO 密集代码意外跑进渲染线程，挤占 16ms 的帧预算
• 对已知坏模式配置大量 lint、编译器诊断、BugBot 规则

棕地（brownfield） 与 绿地（greenfield） 是软件工程中的比喻：棕地指在已有代码库上继续开发，绿地指从零开始的新项目。传统观点认为绿地更灵活、风险更低，但在 agent 协作语境下，棕地项目自带多年积累的架构约定、CI 流水线、lint 规则和权限约束，这些「护栏」能有效限制 agent 的随意发挥，反而降低了失控风险。绿地项目缺乏这些约束，agent 容易采用最便捷但不可持续的方案，快速积累技术债。

vibe coding 指开发者几乎不阅读生成代码、仅凭自然语言描述和运行结果来驱动 AI 编写软件的方式。它适合原型验证，但若用于长期维护的产品，会因缺乏人类理解和架构约束而形成「有机架构」——代码像生物一样随意生长，最终无人能掌握其全貌。

分层约束：硬规则优先于软规则

Lauren 强调约束是分层的，可靠性差异极大。

最硬的层级是代码库架构本身——约定俗成的构建方式，因为 agent 最爱复制现有模式；以及 CI、lint、编译器诊断、import 阻断这些「硬失败」机制。

较软的是 rules、skills 和 BugBot 这类指导性约束。它们有用，但 agent 可能遗忘、可能不一致地应用。她的判断很直接：如果只有 rules、skill 和风格指南，代码库变成垃圾只是时间问题。

她给出一条可操作的准则：每次你在 PR 评论里告诉别人「这里不该这么写」，都应该把它视为代码异味——问自己能否把这条意见转成 lint 规则、CI 失败或架构层面的彻底消除。

这也解释了她对技术栈选择的看重：Rust 编译器严格、有 borrow checker，只要确保 agent 不写 unsafe 块，代码能编译通过就能获得相当程度的信心——这种信心正是让人不再需要亲自逐行 review 的前提。

Borrow checker 是 Rust 编译器的一部分，在编译期静态检查引用的所有权和生命周期，确保内存安全且无数据竞争。它强制开发者明确资源归属，拒绝存在潜在别名或悬垂引用的代码。对 agent 而言，borrow checker 是一道极硬的失败关卡：只要编译通过，就排除了大量内存安全和并发错误，这为「不逐行 review 也能获得相当信心」提供了基础。类似地，TypeScript 的严格模式、Go 的 vet 工具等静态检查也能起到部分作用，但 Rust 的严格程度在系统级语言中尤为突出。

成本与现实边界

面对「不是人人都有无限 token」的质疑，Lauren 承认自己在 AI lab 工作、token 不受限，不能要求所有人照搬。

但她给出的 ROI 框架值得参考：价值不在于省下每一个小任务的 token，而在于做以前做不到的事。以她个人之力，在 agent 之前要花数年才能构建出这样一套框架、完成重构并逐一验证；而现在她花了大量 token、重构了约 600 个 PR，才把代码库推到「不再需要亲自看代码」的状态。

对工程负责人的权衡是：雇一个人来做，还是花 token 把代码库建设到连最「笨」的 agent 都能写出好代码的程度。后者的回报不止于自己——设计师、PM、GTM 人员都能直接提交 feature，不必担心半夜被性能回归叫醒。

Grok Bot 被她说成是「非技术人员的 Cursor 时刻」：界面像 iMessage，agent 可以起名字、有独立身份、可以编排，PM 能让 agent 总结「Lauren 昨晚做了什么」，也能自己修 bug 后请她 review。她提到实际体验是「基本完美，直接盖章」。

编辑观察

这套方法论最值得借鉴的不是具体某条规则，而是它的因果结构：信任 → 并行化 → 杠杆。大多数人卡在第一步，因为把 agent 当黑盒，用人工 review 充当验证；Lauren 的路径是把验证本身工程化，再用硬约束把「正确做法」变成 agent 的默认路径。

需要保留的怀疑是：她的环境有专属架构团队、无限 token 和自研代码 review 工具，这些条件在中型团队难以完整复现。另外「不看代码」的前提是约束体系已经过大量迭代验证，直接跳过建设阶段去追求高 PR 数量，很可能得到的是加速产生的技术债。

（本文基于 B 站公开分享内容整理，观点归属演讲者本人。）