ABOUT THIS VIDEO
这一期,聊些什么?
SpaceX AI Grok Bot 团队的 Lauren Tan(X 上的 @poteto)分享了原定给 Cursor Compile London 的演讲:她如何在一个月内交付 2000 个生产环境的 pull request。核心观点是「信任」——与其把智能体当软件工厂的流水线,不如像经营米其林厨房一样搭建环境:用 Control Glass 验证技能让智能体自己运行应用、抓性能 trace,用 Feature Map 和 PStack 技能库沉淀工程经验,再通过代码库、静态分析、规则与 Bugbot 等分层约束,把代码库本身变成智能体的记忆。她还介绍了 Grok Bot 背后对智能体友好的内部框架 Dune。本页全程中文配音由阿里云通义千问 qwen3-tts-flash 生成(Lauren Tan (poteto) 为 Cherry 音色),并以低音量保留原视频声音作为背景。
配音与字幕辅助理解,内容以原视频为准。本站视频
RECAP · 图文回顾
看完再回顾:这一期讲了什么
点击任意时间戳,可跳到对应位置播放中文配音。
一句话核心观点
一个月交付 2000 个 PR 的秘诀不是更聪明的智能体,而是搭建一个让智能体默认就做对事的高信任环境:用验证技能证明正确性、用技能库沉淀工程师经验、用代码库与框架让错误在结构上不可能发生。
分章节要点
开场:一个月 2000 个 PR,靠的是信任
- Lauren Tan(X 上叫 Potato)在 SpaceX AI 做 Grok Bot,上个月交付了 2000 个 PR 到生产环境
- 她强调这不是目标,而是结果:核心是信任智能体在自己不在场时也能产出高质量工作
- 她的论点:把环境搭建得足够好,就能得到一座个人甚至团队的"软件工厂",以远超以往的速度产出高质量代码
为什么是米其林厨房,而不是软件工厂
- 她不喜欢"软件工厂"的说法:软件不是流水线量产,而是有创造性、近乎艺术的工作
- 更好的类比是米其林厨房:有了智能体,我们不再亲手"烹饪"每个部件,但仍对最终出品负责
- 厨房的布局——炒锅厨师、副主厨、设备、培训、洗碗工的比例——共同决定了最终成品
起点:Cursor agents window 的性能难题
- 六个月前她刚加入 Cursor(当时还未并入 SpaceX AI),面对全新代码库,没有任何智能体技能可用
- 当时 Cursor 正在打造取代 IDE 的新智能体窗口,存在大量性能问题;她有 React 团队背景,被经理请来帮忙
- 早期工作极其手动:整天盯 Chrome DevTools、做性能追踪、拍堆快照,而 PR 像高墙一样涌来,根本无从判断性能是否退化
- 挫败感促使她反思:"我们明明有智能体"——于是开始设想让智能体自己运行应用、采集轨迹、找热点、自动"爬山"优化性能
建立信任:从盯着 1 个智能体到放手 100 个
- 多数人卡在"1 到 5 个智能体"阶段:要盯着每次对话、不断纠偏,你不在场就什么都做不对
- 她认为这是最难摆脱的阶段,因为怎么走出来并不清晰
- 无法扩展到约 100 个智能体的根本原因是缺乏信任:贸然开出 100 个子智能体或 Cloud Agents,只会收获一堆垃圾 PR、回归和 bug
- 信任的建立始于"验证":从低端的验证技能(教智能体跑应用、采轨迹),到高端仍属开放问题的形式化验证(Lean、TLA+);即便没有形式化方法,验证技能也能带你走得很远
Control Glass:带 CLI 的验证技能
- 她在 Cursor 做的第一个技能叫 Control Glass,通过 Chrome DevTools 协议教智能体运行应用、采集轨迹
- 这类验证技能有两个组成部分,第一是 CLI:让智能体可复现地运行应用、收集代码能跑、性能达标的实证证据
- 与其让智能体每次现写互不一致的脚本,不如把 CLI 放进技能目录里,让所有会话统一使用,并持续投入把它做好
Feature Map:给智能体的物化记忆
- 痛点:用户在 Slack 里发一张模糊的 UI 截图加三个问号,智能体能跑应用却只能瞎猜用户意思
- Feature Map 受站点地图启发,是一种"物化的记忆":记录应用有哪些功能、用户如何触达(快捷键、点哪个 DOM 元素)、各功能做什么
- Feature Map 存在代码库的技能目录中,由自动化维护;与 CLI 结合后,智能体既能可复现地控制应用,又能理解内外部用户的请求
- 这套控制类验证技能因此成为团队的关键基础设施;智能体验证自己工作的能力,是建立信任的核心
PStack:教智能体像资深工程师一样写代码
- 验证解决的是正确性——"结账按钮点了真的能结账吗"——但管不了性能和代码质量
- 她做了插件 PStack:一整套技能与攻略,灵感来自她自己做调试、功能开发、原型设计时亲身使用的工作流
- 这是资深工程师发挥价值的地方:搭建团队共享的技能库,让智能体更聪明;与验证技能结合后,智能体不仅验证对错,还能验证质量,并拿到真实的性能指标与遥测数据
代码库即记忆:让错误在结构上不可能发生
- 她认为重构架构、让代码库对智能体友好,可能是一个工程团队能做的最重要的事之一
- 建立信任有层次:代码库是最好的记忆形式,因为大语言模型天性爱沿用上下文窗口里看到的现有模式——智能体打开的文件就是上下文的一部分
- 往上依次是静态分析(linter、编译器诊断、CI)、规则/Bugbot/技能(引导性强但可能被忽略),最后是只能靠人工评审执行的风格指南——面对 PR 洪峰,只靠风格指南根本不现实
- 关键动作:每次纠正智能体后,把教训写成 lint 规则;更好的做法是重构代码库,让那个错误从根本上(categorically)不可能发生
Dune:为智能体而生的框架,禁止注释
- Grok Bot 代码库里他们构建了 Dune——一个对智能体友好的框架,灵感来自 Cursor 智能体窗口的性能问题
- 核心原则:智能体爱抄近路,那就把框架设计得让最省力的路恰好是正确的路;这个代码库对人类可能"很烦"(限制极死),但对上下文极少的智能体是完美环境——未来贡献者可能是设计师、产品经理甚至 CEO
- 反面教训:已有的反模式会像病毒一样被智能体疯狂复制,几天到几周内一个小小的变通就会变成事实上的惯例
- 最典型例子是注释:智能体把注释当借口,用创可贴式方案糊弄而非解决真正的问题,所以 Dune 干脆禁止注释
- 她提出每个团队都需要"园丁"角色:代码库如花园,要把杂草扼杀在萌芽中;Dune 三原则——删除已有技术债、为最受认可的模式强制一条"铺好的路"、见到坏模式第一反应是写 lint 规则(先止血,再清理)
- Dune 的具体约定:功能集中在单一文件夹、入口点类似路由、宿主跑在 Grok Bot 虚拟机上;Electron 主线程代码禁止进入渲染线程(60fps 要求任务不超过 16 毫秒、120fps 不超过 8 毫秒),通过导入与依赖图强制边界
Grok Bot 外循环、自动化与总结要点
- Grok Bot 与 Cursor 配合:Grok Bot 提供"外环",连接 Slack、Datadog、Sentry、PlanetScale 等服务聚合信息、自主决策,再自动启动 Cloud Agents;无需自建复杂基础设施
- Grok Bot 例程可订阅 Slack 讨论串和 Sentry 告警并自动触发任务;代码库、规则、技能相互复利,还可用 Cursor 自动化和 SDK 搭建更多机器人复用这套智能体基础设施
- 成果展示:自动复现 bug 报告、自动开 PR,为整个团队持续增值
- 收尾建议:每当发现自己在纠正、盘问智能体时,按顺序思考五个环节——先通过代码库/架构/数据结构让坏模式不可能发生,再上静态分析,最后叠加规则、Bugbot 和技能;做到位后,你就能放心让智能体自由发挥
关键人物 / 产品 / 数字
人物
- Lauren Tan (poteto)
- 演讲者,X 账号为 potato 加 E(poteto);现任 SpaceX AI,负责 Grok Bot;此前在 Cursor 团队做 agents window 性能优化,更早曾在 React 团队工作
产品与概念
- Grok Bot
- SpaceX AI 的产品,由 Dune 框架驱动;擅长充当"外环",连接 Slack、Datadog、Sentry、PlanetScale 等服务聚合信息并自动启动 Cloud Agents
- Cursor agents window
- Cursor 打造的、用于取代 Cursor IDE 的新智能体窗口,曾存在大量性能问题,是本场分享许多经验的来源
- Control Glass
- Lauren 加入 Cursor 后构建的第一个验证技能,自带 CLI,通过 Chrome DevTools 协议教智能体运行应用、采集性能轨迹
- Feature Map(功能地图)
- 受站点地图启发的"物化记忆":记录应用功能、触达方式(快捷键、DOM 元素)与各功能作用,存在技能目录中并由自动化维护
- PStack
- Lauren 制作的插件,一整套技能与攻略的集合,教智能体按资深工程师的方式做调试、功能开发和原型设计
- Dune
- 为 Grok Bot 构建的对智能体友好的客户端框架/架构:高度约定、严格锁定,让最省力的路径成为正确路径,并禁止代码注释
- Bugbot
- 与规则、技能同层的引导性工具,智能体工作时大多会用到,但强制力弱于代码库和静态分析
- Cloud Agents
- 可由 Grok Bot 自动启动的云端智能体,配合外环事件自动复现 bug、自动开 PR
视频里提到的数字
- 2,000
- Lauren 上个月交付到生产环境的 PR 数量
- six months / 六个月
- 她加入 Cursor 至今的时间跨度,期间生产力"直线飙升"
- one to five / 1 到 5
- 新手阶段同时管理的智能体数量:仍需盯着每次对话、不断纠偏
- 100
- 建立信任后可以并行运行的子智能体/Cloud Agents 数量级
- 16 milliseconds / 60 frames per second
- 渲染线程要保持 60fps,任何任务不能超过 16 毫秒
- eight milliseconds / 120 frames per second
- 要达到 120fps,任务时长上限为 8 毫秒
金句摘录 · 中英对照
“I shipped 2,000 pull requests to production.”
我交付了 2000 个 PR 到生产环境。
— Lauren Tan (poteto) “we're still responsible for the final outcome”
我们仍然要对最终结果负责。
— Lauren Tan (poteto) “the codebase is really, like, the best form of memory, because agents love to extend existing patterns that they see.”
代码库其实是最好的记忆形式,因为智能体特别喜欢沿用它看到的现有模式。
— Lauren Tan (poteto) “So what if we designed a framework such that the shortcut, you know, the easy path is the right path for agents?”
那如果我们设计一个框架,让那条近路、那条最省力的路,恰好就是正确的路呢?
— Lauren Tan (poteto) “if you have existing anti-patterns, you will actually find that these will spread kind of like a virus”
如果代码库里已有反模式,你会发现它会像病毒一样扩散开来。
— Lauren Tan (poteto) “whenever you see tech debt or bad patterns, your instinct should be, "I need to write a lint rule against it."”
每当你看到技术债或坏模式,第一反应应该是:"我得写条 lint 规则来防它。"
— Lauren Tan (poteto) “you trust the environment so much that your agents can just be free, right?”
你无比信任这个环境,你的智能体可以完全放手去干,对吧?
— Lauren Tan (poteto) 可以借鉴的做法 / 启发
- 每次纠正智能体后,不要止步于口头纠偏:把教训固化成 lint 规则,能重构代码库让错误"结构上不可能发生"则更好——这是"先止血、再根治"的思路。
- 为智能体构建可复现的验证工具:把运行应用、采集性能轨迹的 CLI 放进技能目录,避免智能体每次现写不一致的脚本,并持续投入打磨。
- 给智能体准备一份"物化记忆":类似 Feature Map,写清应用有哪些功能、如何触达,让它能理解模糊的用户反馈而不是瞎猜。
- 把团队资深工程师的隐性经验(tribal knowledge)萃取进技能库和框架约定,而不是留在口口相传和人工评审里。
- 像园丁一样维护代码库:把反模式当杂草,尽早清除,因为智能体会把任何现有模式当模板疯狂复制;目标状态是"哪怕智能体照抄,你也放心"。
- 用"外环"自动化放大复利:把告警、用户反馈等事件源接入机器人,自动复现 bug、自动开 PR,而不必自建复杂基础设施。
回顾 / 思考问题
- 你现在处于"信任阶梯"的哪一级?你还在盯着每一次对话纠偏,还是已经能放心并行运行多个智能体?
- 你的团队最近一次纠正智能体犯的错误,有没有被固化成 lint 规则、CI 检查或代码库结构约束?还是只靠口头提醒?
- 你的代码库里是否存在"看似无害"的变通写法或注释?如果智能体把它们当成模板大规模复制,会发生什么?
- 如果让你为自己的应用写一份 Feature Map,你会记录哪些信息(功能、入口、快捷键、DOM 元素)?谁来维护它的时效性?
- 验证、技能、代码库结构、静态分析、规则/风格指南这几个层次中,你的团队目前最薄弱的是哪一层?按 Lauren 建议的顺序,下一步该投在哪里?
- 注释在你的代码库里扮演什么角色?它是在解释必要的边界情况,还是在为"不解决真正问题"提供借口?
本回顾由 AI 根据英文逐字稿整理,时间戳、引文与数字已对照逐字稿核对;如有出入,以原视频为准。