新智元报道
同时跑 20 多个智能体，上个月交付 1000 多个 PR，8 月的目标是翻倍。
这位 GrokBot 工程师拉出 GitHub 贡献曲线：五个月，3000 多个 PR。
提 PR、跑验证、合进主干，整个链条智能体自己跑完，中间不用她过手。
用她的话说：一觉醒来，20 个 PR 已经躺在主干分支上了。而且翻了一遍，写得还不错。
她也知道，这话听着有点让人怀疑这些代码的质量，紧跟着补了一句：
这么说显得我像个批量制造垃圾代码的人，我保证我不是。
她的做法，是同时跑 20 多个 GrokBot，装在她自己开源的 pstack 里，配合/loop、/goal 和/swarm，让智能体完整地拥有一个任务，自己干，自己验，自己交。
这位工程师叫 Lauren Tan。
她是前 Cursor 工程师，此前待过 Meta 和 Netflix，在 Netflix 当过两年工程经理，现在负责 SpaceXAI 的 GrokBot。
Lauren Tan 在 GrokBot 团队工作坊上分享。
AI 写代码已经不稀奇。
真正让人好奇的，一个人一个月提交 1000 多个 PR，马上就要直奔 2000 个，而且没把代码库变成一堆垃圾。
她是怎么做到的？
一条曲线
五个月心路
Lauren 分享了一张曲线图，她说这不是什么科学图表，是她这五个月的心路。
Lauren Tan 分享的信任曲线。纵轴是信任，横轴是能同时开的智能体数量，从 1 到成千上万。
一年前，几乎没什么人用智能体写代码。
那时候的模式是，你时刻盯着一个智能体，或者几个，眼睛不离屏幕，每一行输出都要看，坐在那儿一句一句提示。
这一切没办法并行，因为你不信它。
你连一个智能体的输出都不信任，怎么可能同时开一百个。
每个用过智能体的人，都尝过信任崩塌的滋味。
有一次她报了个 bug，问智能体这功能为什么不工作。
智能体一口咬定，肯定是这儿的问题。她翻开工具调用记录一看，它压根没读那段本该相关的代码。
几次之后，她想明白一件事：智能体在猜，而且它不知道自己在猜。
对这样的下属，你还敢放权吗？
Lauren 打了个比方。
你是工程经理，手下带着一队工程师，你不信任他们，那工作模式就只剩一种：整天站在下属背后，盯着他们别把 bug 捅到线上去。
Lauren 在 Netflix 当过两年工程经理，也当过技术负责人，她发现管人的技巧和管智能体的技巧，重合度高得惊人。
五个月前她刚入职 Cursor，第一个月产出很低，代码库完全陌生，什么都看不懂。
五个月后，她把自己从曲线最左端那个点，挪到了 10 到 20 这一格。
从盯着一个智能体不敢眨眼，到放手让 20 个智能体自己合并主干，这中间她做了什么？
给智能体造一双眼睛
这是 Lauren 干的第一件事，她认为重要的技能不是提示词，而是验证。
她是这样定义验证的：
让智能体真的能把代码跑起来：能抓 CPU 耗时记录，能抓内存快照，能自己打开 iOS 模拟器点一遍。用户在你的应用上怎么用，它就怎么走一遍，然后自己测，自己验。
没有这一层，瓶颈就是你自己。
这样的画面，你可能太熟悉了。
你让它改个东西，它写完，你打开本地构建，发现不对，截图，复制控制台报错，粘回去，它慢慢理解，再改一版。
你在这个循环里当「人肉传送带」：一个都忙不过来，还谈什么并行。
所以 Lauren 进 Cursor 后，写的第一批技能之一，就叫 control glass。
这个技能教智能体自己去调 Chrome DevTools 协议，自己跑起应用，自己截图、点击、读控制台。
真正关键的是配套的那份文件，叫 feature map。
因为技能造好之后她发现，智能体能跑起来应用了，但它不知道这个应用是什么。
有人报「左边栏卡」，有人报「右边的 PR 标签页不工作」，智能体就在界面里乱撞，翻半天代码也找不到这个功能长在哪儿、怎么点得到。
feature map 把这些全写下来：每个功能从用户视角怎么进入，快捷键是什么，甚至连选元素该用哪个属性都列好。
效果立竿见影。
Cursor 内部有个 Slack 频道收用户反馈，质量普遍很差，很多人就丢一张截图，配三个问号。
有了 feature map，智能体也能顺着查下去。
Benny 值夜班
不给结论，只给证据
然后是 Benny。
Benny 是她做的一个自动化智能体，在 Slack 里专门接 bug 报告。
它跑到云端，开一台自己的电脑，在里面运行 Cursor，用同一套 control glass 技能操作应用，试着把问题复现出来。
有一次，它这样回话：在修复前的提交上复现出来了，修复后消失。附上一条云端运行记录的链接，你想翻就能翻。
它给的不是一句「应该已经修好了」，而是一组能对照的证据。
Lauren 说这条信息价值极高，省下的是她原本要和智能体耗上一小时才能搞清楚的事。
Lauren 提到的 Benny，就是 GrokBot 的前身。
她做它的初衷，就是让智能体在她睡觉的时候把 bug 报告修掉。
后来很多人追着问她这东西怎么做的，这些提问长成了今天的 GrokBot。
最后，是她怎么验证这些技能本身好不好用。
她的做法有点狠。
她派出一堆子智能体跑评测，给它们的目录起一些看不出来的名字，不让它们知道自己正在被评估。
原因是，智能体能察觉到自己在被测，一旦察觉，行为就会变。
再叫一个不同模型家族的智能体当裁判，交叉复核，防止自评偏袒。分数不满意就用/loop 接着刷，一直刷到 10 分。
验证不能保证智能体写出好代码。但它能保证智能体写出对的代码。
这就是信任的前提。
她把每句评审都变成了红灯
Lauren 敢撒手，靠的不是模型变强，是让护栏变硬。
她花了很大的力气在代码库上，其中一部分开源成了 pstack，就在 Cursor 官方插件仓库里。
GrokBot 的架构有个内部代号叫 Dune。她的形容是，可以理解成给 Electron 应用的 Next.js，专门为智能体书写而设计。
这套架构有多严？
写过 React 的都知道 useEffect 是最大的坑之一。在 Dune 里，useEffect 被禁了。用了 CI 直接报红。
更绝的是，代码注释也被禁了。
理由是她观察下来，99% 的情况智能体写的注释都在描述一些跟代码无关的历史片段。
它会写下「Lauren 说永远不要这么干」。可她当时的意思只是这个 PR 很烂，你改一下那部分，根本不是什么全局规则。
她的结论是，智能体对人类的理解没那么好，还特别爱脑补。
所以，凡是它们干不好的事，一律封杀。
再往下是进程隔离。
Electron 有渲染线程和主线程，agents window 在这块分得不清楚，经常有代码被误拉进渲染线程。
要跑 60 帧，每帧只有 16 毫秒预算，一旦混进重计算或者大量 IO，画面立刻开始卡。
Dune 的做法是直接分出 electron main 和 electron renderer 两个目录，CI 去检查依赖图，跨目录乱引用直接失败。
把这些串起来，是她的分层模型。
最硬的一层，是代码库架构本身。智能体天然爱抄现成的模式，你把正确的写法做成唯一的写法，它就只会那么写。
然后是 CI、lint 规则和编译器诊断。这一层能让构建变红，是硬约束。
最软的是 rules、skills 和代码审查机器人。这层智能体会忘，会漏，不会稳定执行。
她的原话是：
如果你只有规则、机器人、技能和一份代码风格指南，你的代码库变成一堆垃圾只是时间问题。
支撑整套架构的核心哲学，只有一句：最短的路，就是最好的路。
智能体解决问题时永远挑最省事的方式，那就把最省事的方式做成最正确的方式。
这笔账她刚算过：把 GrokBot 重构到这套架构，用掉了 600 多个 PR。
这 600 多个 PR，还债的成分居多。
GrokBot 当初是氛围编程堆出来的原型，速度极快，没人读代码，智能体拿到任务就挑最省事的路走，架构野蛮生长到失控。
她还常开一个玩笑：在 AI 的垃圾代码之前，先有人类的垃圾代码。
在 Meta，几万工程师共用一个巨型仓库，代码质量其实没那么好。
但大厂那套照着「最不熟练的工程师」设计的框架、约定、凭据限制，恰好就是智能体需要的护栏。
过去被嫌弃官僚的东西，现在成了资产。反而是白手起家的新项目，最危险。
那护栏该从哪儿加起？她给出一条判断标准：
当你在代码评审里靠打字告诉别人「这里不能这么写」的时候，这件事本身就是 code smell。
正确的动作是问自己：怎么把它变成一条 lint 规则？变成一次 CI 失败？或者干脆，让这个问题从根上不可能发生？
你在 PR 评论里说过三遍的话，就该变成一条会让构建变红的规则。
1000 个 PR 之后
工程师还剩下什么
Lauren 用了一个词来形容自己的定位：主厨。
不再自己炒每一道菜，手底下有配菜的，有二厨，有各个灶台。你的活儿变成了设计厨房，安排工位，分派任务。
她说现在 GrokBot 团队里，产品经理和设计师会直接提交代码。
经常是有人跑来说，这儿有个 bug 我修好了，你看一下。她点开，确认没问题，盖章。
一个从没写过前端的人，代码能进主干，靠的不是他突然会写了，是那套严格到烦人的架构约束替他兜住了底。
自动合并之后，PR 这道流程一点都没少。
所以，这背后不是程序员要失业了，是他们的位置在上移。
被机器接走的，是干活、跟进度、跑测试、盯 PR 这些事，人的角色移到了定目标、划权限、设验收标准的位置上。
程序员留在牌桌上的筹码，从「我会写代码」变成了「我能判断怎样写代码才算对了」。
参考资料：
https://maven.com/p/e23d9c/how-cursor-turned-ai-agents-into-better-engineers
https://github.com/cursor/plugins/tree/main/pstack
编辑：元宇
