SpaceXAI 的 GrokBot 工程师 Lauren Tan 表示，她现在会同时运行 20 多个智能体。按她的说法，上个月这些系统交付了 1000 多个 PR，8 月的目标是翻倍。
她还展示了一张 GitHub 贡献曲线图。5 个月时间里，相关产出累计超过 3000 个 PR。她说，如今从提 PR、跑验证到合入主干，整条流程很多时候都由智能体自己完成，中间不需要她逐一过手。
Lauren Tan的原话是：「一觉醒来，20 个 PR 已经躺在主干分支上了。」她补充说，自己也知道这听起来会让人怀疑代码质量，所以紧接着又解释：「这么说显得我像个批量制造垃圾代码的人，我保证我不是。」
她的做法，是把 20 多个 GrokBot 同时运行在自己开源的 pstack 里，并配合 /loop、/goal 和 /swarm，让智能体拿到完整任务后自己执行、自己验证、自己提交。
Lauren Tan 曾在 Cursor 任职，此前也在 Meta 和 Netflix 工作，并在 Netflix 担任过两年工程经理。现在她负责 SpaceXAI 的 GrokBot。上述内容来自她在 GrokBot 团队工作坊中的分享。
5 个月内把信任区间从 1 推到 10 到 20
Lauren 说，AI 写代码本身已不新鲜，更让人关心的是，一个人一个月提交 1000 多个 PR，且很快要冲向 2000 个，同时没有把代码库变成「一堆垃圾」，这背后的工作方式到底是什么。
她分享了一张「信任曲线」。按她的描述，这不是什么科学图表，而是自己过去 5 个月的心路。纵轴是信任，横轴是可同时开启的智能体数量，从 1 一直到成千上万。
她回顾说，一年前几乎没有多少人用智能体写代码。那时常见模式是盯着一个，或者几个智能体，眼睛几乎不离开屏幕，每一行输出都要看，每一句提示都要跟。这样的流程没法并行，原因很简单：你不信它。连一个智能体的输出都不信，自然不可能同时开 100 个。
Lauren 说，很多用过智能体的人都经历过「信任崩塌」。她举了一个例子：自己曾报过一个 bug，并问智能体为什么这个功能不工作。智能体很肯定地说问题就出在某处，但她翻开工具调用记录后发现，它根本没有读过那段本应相关的代码。
几次之后，她意识到，智能体很多时候是在猜，而且它自己不知道自己在猜。她把这种状态类比成带团队：如果你是工程经理，却不信任手下工程师，那最后只剩下一种工作模式——整天站在他们身后，盯着别把 bug 带到线上。
她提到，自己在 Netflix 做过两年工程经理，也担任过技术负责人，而她后来发现，管理人的技巧与管理智能体的技巧，重合度非常高。
Lauren 说，5 个月前她刚入职 Cursor 时，第一个月产出很低，因为代码库完全陌生，很多内容都看不懂。5 个月后，她把自己从这条曲线最左端的位置，推到了可同时运行 10 到 20 个智能体的区间。
从盯着一个智能体不敢松手，到允许 20 个智能体自己合并主干，她给出的第一个答案不是提示词，而是验证。
先让智能体看见应用，再让它自己验证
Lauren 认为，重要的能力不是提示词，而是验证。她对验证的定义是，让智能体真的把代码跑起来：能抓 CPU 耗时记录，能抓内存快照，能自己打开 iOS 模拟器点一遍；用户在应用里怎么操作，它就怎么走一遍，然后自己测试、自己验证。
她说，如果没有这一层，真正的瓶颈就是人本身。典型场景是：你让智能体改一个东西，它写完后，你自己打开本地构建，发现结果不对，再截图、复制控制台报错、粘回去，它慢慢理解后再改一版。人在这种循环里变成了「人肉传送带」，一个都忙不过来，更不用说并行。
因此，她进入 Cursor 后写的第一批技能之一，就叫 control glass。这个技能的作用，是教智能体自己调 Chrome DevTools 协议，自己把应用跑起来，自己截图、点击、读取控制台。
不过，她很快又发现，只有技能还不够。智能体虽然能运行应用，但并不知道这个应用是什么。
她举例说，有人报「左边栏卡」，也有人报「右边的 PR 标签页不工作」，如果没有额外信息，智能体会在界面里乱撞，翻很久代码也找不到相关功能具体在哪、该怎么点进去。
为了解决这个问题，她配了一份名为 feature map 的文件。这里会写清楚每个功能从用户视角怎么进入、快捷键是什么，连选元素时该用哪个属性都会列出来。
Lauren 说，这个做法见效很快。Cursor 内部有一个收用户反馈的 Slack 频道，很多报告质量并不高，经常只有一张截图，再配上几个问号。即便如此，有了 feature map，智能体也能顺着查下去。
Benny先找证据，不先下结论
在这套流程里，另一个关键角色是 Benny。Lauren 介绍，Benny 是她做的一个自动化智能体，专门在 Slack 里接 bug 报告。
它会跑到云端，启动一台自己的电脑，在里面运行 Cursor，再用同一套 control glass 技能操作应用，尝试把问题复现出来。
她提到，有一次 Benny 的回复是：在修复前的提交上复现出来了，修复后已经消失，并附上一条云端运行记录链接，方便继续核对。
Lauren 说，这类返回的价值很高，因为它提供的不是一句「应该已经修好了」，而是一组可对照的证据，能省掉她原本可能要花 1 小时和智能体来回确认的时间。
她还提到，Benny 就是 GrokBot 的前身。她最初做它，是希望自己睡觉时，智能体也能把 bug 报告修掉。后来很多人不断追问这套东西怎么实现，这些问题最终演变成今天的 GrokBot。
评测时故意隐藏测试身份，分数不够就继续循环
Lauren 还介绍了她如何验证这些技能本身是否好用。她的做法是派出一批子智能体去跑评测，并故意给这些目录取一些看不出来的名字，不让它们知道自己正在被评估。
她解释说，智能体能察觉到自己在被测试，一旦察觉，行为就会改变。
除此之外，她还会叫一个不同模型家族的智能体担任裁判，做交叉复核，避免自评偏袒。如果分数不满意，就继续用 /loop 刷，直到 10 分为止。
Lauren 给出的结论是，验证并不能保证智能体写出好代码，但能保证它写出对的代码，而这正是建立信任的前提。
靠的不是模型更强，而是把护栏做硬
Lauren 说，她敢真正放手，不是因为模型突然变强了，而是因为她把护栏做得更硬。
她在代码库上投入了很多精力，其中一部分已经开源成 pstack，放在 Cursor 官方插件仓库中。GrokBot 的架构在内部有个代号，叫 Dune。按她的描述，可以把它理解成「给 Electron 应用的 Next.js」，而且是专门为智能体书写设计的。
这套架构的限制相当直接。她提到，写过 React 的人都知道 useEffect 容易成为问题点，所以在 Dune 里，useEffect 被直接禁用，使用后 CI 会报红。
更严格的是，代码注释也被禁了。Lauren 解释，她观察下来，99% 的情况下，智能体写的注释都在描述一些和代码本身无关的历史片段。比如它会写「Lauren 说永远不要这么干」，但她当时真正表达的，只是那个 PR 很差，相关部分需要改，并不是一条全局规则。
她的判断是，智能体对人的理解没有那么好，而且很爱脑补。所以，凡是它们做不好的事，直接封杀。
再往下是进程隔离。她说，Electron 有渲染线程和主线程，但 agents window 在这块经常分不清，导致代码被误拉进渲染线程。由于渲染要跑 60 帧，每帧只有 16 毫秒预算，一旦混进重计算或大量 I/O，界面就会立刻卡顿。
Dune 的处理方式，是直接拆出 electron main 和 electron renderer 两个目录，再由 CI 检查依赖图，跨目录乱引用会直接失败。
在这之上，Lauren 建了一套分层模型。
- 最硬的一层，是代码库架构本身。她说智能体天然喜欢照抄现成模式，所以只要把正确写法做成唯一写法，它就只会那样写。
- 第二层是 CI、lint 规则和编译器诊断。这一层能让构建直接变红，属于硬约束。
- 最软的一层是 rules、skills 和代码审查机器人。她认为这部分智能体会忘，会漏，也不会稳定执行。
她的原话是：「如果你只有规则、机器人、技能和一份代码风格指南，你的代码库变成一堆垃圾只是时间问题。」
支撑整套架构的核心哲学，她概括为一句话：最短的路，就是最好的路。既然智能体解决问题时总会挑最省事的方式，那就把最省事的方式做成最正确的方式。
Lauren 还算过一笔账：只是把 GrokBot 重构到这套架构里，就用了 600 多个 PR。她说，这 600 多个 PR 很大一部分都在还债。
按她的说法，GrokBot 最初是靠「氛围编程」堆出来的原型，速度很快，但没人读代码，智能体拿到任务后总会挑最省事的路，结果架构野蛮生长到失控。
她还常开一个玩笑：「在 AI 的垃圾代码之前，先有人类的垃圾代码。」
Lauren 提到，在 Meta，那种几万名工程师共用一个巨型仓库的环境里，代码质量本身也谈不上天然很好。但大厂为了照顾「最不熟练的工程师」而建立的框架、约定和权限限制，恰好就是智能体现在需要的护栏。过去常被嫌官僚的东西，到了今天反而成了资产；相较之下，白手起家的新项目更危险。
同一句评审说了三遍，就该写成会报红的规则
那护栏该从哪里开始加？Lauren 给出了一条判断标准：如果你在代码评审里只能靠打字告诉别人「这里不能这么写」，那这件事本身就是 code smell。
她说，正确的动作是反过来问自己：怎么把它变成一条 lint 规则，或者变成一次 CI 失败，甚至干脆让这个问题从根上不可能发生。
她给出的经验是，你在 PR 评论里说过三遍的话，就该变成一条会让构建变红的规则。
1000多个PR之后，工程师的角色变成了「主厨」
谈到工程师还剩下什么工作时，Lauren 用了一个词来描述自己的定位：主厨。
她说，自己不再亲手炒每一道菜，下面有配菜的人、有二厨，也有各个灶台。工程师的工作开始变成设计厨房、安排工位、分派任务。
她透露，现在在 GrokBot 团队里，产品经理和设计师也会直接提交代码。经常有人跑来对她说，这里有个 bug 我已经修好了，你帮我看一下。她点开确认没问题后，就会盖章通过。
她认为，一个从没写过前端的人，代码也能进入主干，并不是因为这个人突然学会了写前端，而是因为那套严格到让人烦躁的架构约束帮他兜住了底线。
Lauren 还强调，自动合并出现后，PR 这道流程并没有消失。
因此，在她看来，这背后不是程序员要失业，而是程序员的位置在上移。被机器接走的，是干活、跟进度、跑测试、盯 PR 这些事务；人的位置则转向定目标、划权限、设验收标准。
她最后给出的判断是，程序员留在牌桌上的筹码，正从「我会写代码」转向「我能判断怎样写代码才算对了」。
参考资料与来源
Lauren Tan 在分享中提到的参考资料包括：
- https://maven.com/p/e23d9c/how-cursor-turned-ai-agents-into-better-engineers
- https://github.com/cursor/plugins/tree/main/pstack
本文来自微信公众号「新智元」（ID：AI_era），作者为 ASI启示录。MarsBit 页面信息显示，文章发表于 2026 年 8 月 31 日。