Lauren Tan（poteto）Lauren Tan 在 X 上叫 poteto，在 SpaceXAI 做 Grok Bot，之前在 Cursor 和 React 团队。她说自己上个月往生产环境发了 2,000 个 pull request（PR），但这从来不是她的目标：她做的所有技能、工具和代码库改造，最后都指向同一件事，让自己敢信任智能体的产出，哪怕她不在旁边盯着。
这场演讲原本是为伦敦的 Cursor Compile 准备的，她没能到场，就免费发在了 X 上。
关键是信任
她不喜欢「软件工厂」这个说法，更喜欢「米其林厨房」：我们不是在流水线上批量生产，做产品本身是有创造性的。有了智能体，我们不再亲手做每一道菜的每个部分，但依然要对端上桌的结果负责，要操心整个厨房怎么布置：厨师、副厨、帮厨各配什么工具、受过什么训练、比例是多少。
她把用智能体的人分成几个阶段：
- 同时开 1 到 5 个智能体： 每段对话都得盯着，不停纠正方向。人一走开，智能体就做错。她认为这是最难走出的一个阶段，因为不知道该怎么走出去。
- 想一下开 100 个： 卡住你的不是工具，而是你还不信任智能体的产出。没有信任就硬开 100 个子智能体，只会得到一堆质量很差的 PR、性能倒退和 bug。
所以问题变成：怎么才能更信任你的智能体？
第一步：让智能体自己验证
她刚到 Cursor 时，被派去解决新的智能体窗口（替代原来的 Cursor 编辑器）的性能问题。PR 合进来的速度太快，她根本不知道性能有没有被拖慢，只能天天开着 Chrome 开发者工具手动抓性能追踪、拍内存快照。手动到烦了，她想：都有智能体了，我这是在干什么？
于是她开始做验证技能：教智能体自己把应用跑起来，自己抓性能追踪、读懂结果、找出热点，一点点把性能往上调。
验证有深有浅：
- 浅的一头： 验证技能，教智能体怎么运行应用，用 Chrome DevTools 协议之类的调试协议去调试、抓追踪、拍快照。
- 深的一头： 形式化验证，用 Lean、TLA+ 这类语言去证明业务逻辑永远成立。这很难，很少有人真在做。
她的看法是：就算做不了形式化验证，光靠验证技能就能走很远。她在 Cursor 做的第一个技能就是这种，靠 Chrome DevTools 协议控制应用、抓追踪。它后来有两个关键部分：
- 一个命令行工具（CLI），放在技能目录里。 与其让智能体每次临时写脚本（每次都不一样），不如给它一个固定的工具，每次都用它，可重复地跑应用、收集证据，证明代码能用、性能达标。这个工具要认真打磨，能应付各种情况。
- 一张「功能地图」。 用户在 Slack 里发来一张模糊的截图、配三个问号，智能体能跑起应用，却只能瞎猜对方在说哪里。功能地图有点像网站地图：应用有哪些功能、用户怎么到达（快捷键、点哪个元素）、每个功能做什么。它就存在技能里，有自动化流程负责维护。
CLI 加上功能地图，智能体不仅能可重复地操控应用，还能看懂内部和外部用户报上来的问题。这套验证技能后来成了团队离不开的基础设施。
第二步：教智能体像工程师一样写代码
验证解决的是正确性：结账按钮点了，是不是真的结了账。它给你实打实的证据，却说明不了性能和代码质量。
这时就要用另一类技能，教智能体照真正的软件工程师那样干活。她做了一个插件叫 pstack，是一组技能，来自她自己多年做调试、开发功能、做原型的工作方法。团队里经验丰富的工程师，最能在这里出力：把自己的做法写成团队共用的技能库，智能体就聪明很多。
验证技能加上这类技能，智能体既能确认自己做对了，也能确认做得好，而且因为能跑验证，还能拿到真实的性能数据。
第三步：让代码库替你管住智能体
她认为最重要的一件事，是把代码库和架构改得对智能体友好。如果你真相信以后代码都由智能体来写，代码库就该设计成「默认就做对」。
她把建立信任的手段排成一串，越靠前越硬、越可靠：
- 代码库本身就是最好的记忆。 智能体很爱照着已有的写法往下写，它读到的文件就在它的上下文里。所以它不会在每个 PR 里帮你重构，只会沿着现有的样子扩展。
- 让错误根本写不出来。 用更好的数据结构和架构，让智能体常犯的那种错误在结构上就不可能发生。
- 静态分析： lint 规则、编译器诊断、持续集成（CI）。你纠正智能体后它还是反复犯的错，就写成 lint 规则。
- 规则、Bugbot 和技能： 这一层是引导，不是强制。智能体大多数时候会用，但可能忘了读，或者用它的人直接忽略了。
- 代码风格指南： 只能靠人在代码审查时盯。PR 来得这么快，人根本看不过来，所以别只靠它。不过人工审查里反复出现的意见，正好说明前面几层还缺什么。
Dune：一个故意「管得很死」的框架
Grok Bot 的代码库里有一套她们叫 Dune 的框架，专门为智能体设计。核心原则是：智能体爱走捷径，那就让捷径恰好是对的路。
这样的代码库对人来说可能挺烦的，什么能做、什么不能做都卡得很死，但对智能体是理想环境，尤其是上下文很少的智能体。因为现在往代码库里提交的不只是工程师，还有设计师、产品经理，甚至 CEO。代码库要设计到：哪怕是忙人随手指挥的、背景知识很少的智能体，默认也能做好。
反过来也成立：坏写法会像病毒一样传开。 一个小小的临时绕过，或者一段解释绕过的注释，智能体会很快学过去，几天到几周就到处都是，变成事实上的标准写法。
她举的例子是代码注释。人写注释很正常，可她在 Cursor 的代码库里发现，智能体会拿周围的注释当理由，不去解决真正的问题，只贴个创可贴。所以 Dune 干脆禁止写注释，免得这种写法被复制得到处都是。
她因此主张每个团队都需要一个「园丁」角色，专门盯着那些悄悄长出来的杂草，在它们蔓延之前掐掉。Dune 背后的几条原则：
- 删掉已有的技术债。
- 大多数事只留一条铺好的路： 只有一种约定俗成的写法，智能体不用猜，代码库、CI 和 lint 规则里有足够的引导。
- 看到坏写法，第一反应是写一条 lint 规则。 不一定马上清理干净，但至少先止血，不让它继续扩散。然后再让智能体慢慢清理，让代码库一直处在「被智能体照抄也没关系」的状态。
一个具体例子：Dune 里严格划分了在 Electron 主进程跑的代码和在渲染进程跑的代码。在 Cursor 的智能体窗口里，她们见过慢代码被误引入渲染进程，界面就卡了。渲染进程每一帧只有 16 毫秒（60 帧）甚至 8 毫秒（120 帧），所以 Dune 通过 import 和依赖关系强制隔开两边，让这类性能问题从结构上不可能出现。
她强调重点不在 Dune 本身，而在于做一个你自己的、对智能体友好的框架：把团队里最好的工程师脑子里的经验，从「代码审查时留评论」的方式里抽出来，写进框架和代码库本身。代码库就是你希望智能体照着延续的那份快照，要干净到下一个智能体来了，大概率也会把它保持得很好。
外层循环：让 Grok Bot 自己开工
她说 Grok Bot 和 Cursor 搭配起来很合适：Grok Bot 负责「外层循环」。它能接上 Slack、Datadog、Sentry、PlanetScale 等各种服务，把信息汇总起来自己做判断。有人把这叫「公司大脑」，她觉得用不着那么复杂，因为智能体本来就很会用工具。
用 Grok Bot 的定时任务（routines）订阅 Slack 讨论串、Sentry 报警，就能自动派出云端智能体去干活；再用 Cursor 的自动化和 SDK 搭更多机器人，复用前面这些基础设施，处理更复杂的任务。她们团队已经在自动复现用户报的 bug、自动开 PR。前面每一层投入都会叠加起来。
只记一件事
她说如果只带走一页，就是这一页：每次你发现自己在纠正、干预智能体时，想一想上面那五层里，哪一层最能根治这个问题，并且按顺序考虑：先看能不能靠代码库、架构和数据结构让这种错误不可能发生；不行再上静态分析；最后再叠加规则、Bugbot 和技能。
做到这些，你会信任整个环境，信任到可以放手让智能体自己跑。她说这不是什么秘诀，就是大量的苦工。
新手怎么理解
- 智能体就是会自己动手干活的 AI 编程助手，比如 Cursor、Claude Code 里的那种：你说需求，它自己读代码、改代码、提交 PR。
- 「信任」说的是：你不在旁边盯着，也敢把它的改动合进去。 她的整套做法都在提高这份信任，而不是一味多开智能体。开得多但不可信，只会制造更多要你收拾的烂摊子。
- 先让它能自己验证。 能自己把应用跑起来、看到结果的智能体，比只会写代码的可靠得多。这就是一种技能：把做事的方法和工具打包好，交给智能体按需使用。
- 每次纠正，都想办法变成「下次不会再犯」。 嘴上说一遍，它下个对话就忘了；写成 lint 规则、改掉代码结构，才会一直管用。这也是给智能体搭运行环境的思路。
- 2,000、2,500 个 PR 都是她自己报的数字，没有第三方核实；值得借鉴的是做法，不是数字。