解读：不靠盯屏，靠「厨房」——@poteto 谈如何信任 Agent 并月合上千 PR
本文是对 @poteto（Lauren Tan，现 Grok Bot / SpaceX AI，前 Cursor）一场约 38 分钟演讲的摘要与评论。原帖写「上个月 2500 个 PR」，口播里也常说约 2000——数量是钩子，论点是如何建立对 Agent 的信任。插图均为演讲白板关键帧，完整内容请看原视频。
全文主线可以压成一句：并行度是信任的结果，不是目标；先把验证闭环、工程 skills 与 Agent 友好架构建好，再谈云端规模与自动合入——跳级只会换来一堆 slop PR。
这篇在说什么
核心不是「怎么让模型写得更快」，而是：你若仍在逐条盯屏、当瓶颈，就无法并行；要升到「醒来发现一堆已合入且质量过关的 PR」，必须先把环境建好——验证闭环、工程 skills、以及让「抄现有模式」也抄对的代码库约束。
先换隐喻：她不用工厂，而用米其林厨房。下一节把人和 Agent 的关系钉住。
米其林厨房，不是流水线
她刻意不用「软件工厂」：工程师做的是创意与品味，更像米其林厨房。人不再炒每一道菜，但仍要设计厨房、培训、工位与工具；Agent 是线厨，你是主厨。
隐喻立住后，白板画出一条信任曲线：解释为什么不能一上来开一百个 Agent。
信任曲线：为什么不能一上来开一百个 Agent
白板画了一条「trust × number of agents」曲线：多数人卡在 1–5 个必须紧盯的阶段。没有信任却去开上百个云端 Agent，只会换来一堆 slop PR（低质量糊弄式改动）和回归。她自己的路径是：早期几乎无法并行 → 逐步验证与约束 → 如今可自动合入，醒来再在 main 上复盘。
解读：把「并行度」当目标是本末倒置；并行度是信任的结果。
信任从哪来？下一节给出三条腿。
怎么更信任：三条腿
第一，Verification for correctness（正确性验证）——Agent 自己跑应用、拿实证，而不只是「看起来像修好了」。第二，高质量 skills（她提到自研插件 pstack 一类思路）——把调试、实现、评审等个人工程习惯编码进 skill。第三，重构 / 重写成 Agent 友好架构——尤其 greenfield（全新项目）若纯 vibe、零护栏，会很快失控；brownfield（已有代码库）若已有大厂式约束，反而更适合 Agent。
三条腿里，她讲得最细的是验证技能。下一节用 Feature Map + CLI 说明「自证其工作」长什么样。
验证技能：Feature Map + CLI
她讲了早期在 Cursor Agents Window（内部代号 Glass）做性能：人肉开 DevTools、截 flame graph 喂给 Agent，人成了验收集瓶颈。于是做出 Control Glass 一类验证 skill：
CLI 负责可复现地启动应用、采 trace / 证据（别让每次会话现写脚本）。Feature Map 像站点地图——功能是什么、用户怎么到达、键盘快捷键、可点选的 DOM 属性。用户丢一张糊截图加三个问号时，Agent 才找得到入口。
两者合在一起，Agent 才能自证其工作。她也强调：先本地观察 Agent 怎么操作应用，再上云端规模化；云端 Agent（例如自动复现 Slack bug 报告的「Benny」一类）会把同一套验证技能放大成团队基础设施。
验证解决「这次对不对」；代码库则决定「下次会不会抄错」。下一节讲代码库即记忆。
代码库即记忆：反模式会像病毒扩散
LLM 爱扩展上下文里已有的模式。代码库是最硬的「记忆」：好模式会被复制，workaround（权宜之计）也会被复制成「事实标准」。
她举的刺点例子包括：Agent 爱写代码注释——初看无害，实际常变成「用注释合理化不真正修问题」的借口，于是在 Grok Bot 所用的 Dune 架构里选择硬禁注释等约束。原则是：人类觉得「有点烦」的锁定，往往正是 Agent 的正确默认路径——最短路径 = 最好路径。
于是团队需要有人专门清坏模式。下一节是「园丁」。
团队需要「园丁」
三句很落地：Delete tech debt（删技术债）——已有坏模式要清，否则会自我繁殖。Keep one paved path（只留一条铺好的路）——同一类事只留一种常规写法。Lint against anti-patterns——来不及立刻清干净时，至少先写规则止血。「园丁」不是职称表演，而是每次纠错时问：怎样让这类错以后再也犯不了。
园丁工作要落到架构。下一节用 Dune 说明垂直切片与进程边界。
Dune：给 Agent 的垂直切片
Grok Bot 客户端框架（口中的 Dune）把 Feature UI / Client / Shared RPC edge / Host extension 切开，并强制 Electron 主进程与渲染进程的导入边界——这是从 Agents Window 性能债里长出来的硬约束：渲染线程要守住约 16ms/帧，重活不能误 import 进来。
口号式总结：Agent-friendly = 一次正确的「打开文件就改」仍能保住全应用不变量。 CI 里还有禁 useEffect、依赖图检查、Bugbot 等层叠手段。PR 尺寸无硬顶，但鼓励拆成原子 PR，方便回滚与用 git 历史当上下文。
以上都是「纠错之后沉淀到哪一层」。下一节是她最想你带走的五层优先级。
纠错时的五层优先级（她最想你带走的一张）
从上到下，约束由硬到软：1. codebase——结构上不可能（类型、目录边界、数据模型）；2. static analysis——lint / 编译器 / CI 变红；3. rules / Bugbot——可被忘掉的软约束；4. skills——流程与品味；5. style guide——若只靠人肉 Code Review 守，在 Agent 吞吐下会先垮。
解读：每次你在 PR 里打字纠正 Agent，都该当成 code smell——把那句话升级成上面尽量靠前的一层。
内环是仓库与验证；外环是信号接入。收束看 Grok Bot + Cloud Agents。
外环：Grok Bot + Cloud Agents
内环是仓库与验证；外环是 Slack、Sentry、Datadog 等信号。Grok Bot 的 connectors / routines 可把「外环事件」踢给 Cloud Agents，复用同一套 skills。她的顺序仍然是：本地信任 → 云端规模 → 再谈 auto-merge；跳级只会烧 token。
关于成本：她承认自己在「几乎不限 token」的环境；对创业团队的建议是算 ROI——前期重构与护栏贵，但换来的是「最素的 Agent、甚至非工程师」也能安全贡献，而不必堆成万人工程组织。
钩子是 PR 数，论点是信任；读反了会去堆并行，读对了会先建厨房。
Feature Map + CLI 是最可抄的验证组合：一个回答「点哪里」，一个回答「如何可复现地采集证据」。
五层优先级请当真：每次在 PR 里打字纠正，都问能不能升级成类型、lint 或 CI，而不是再写一条会被忘掉的 style 句子。
园丁三句（删债、一条路、lint 止血）适合直接写进团队周会；否则 Agent 会把 workaround 复制成新文化。
为方便未看原片的读者，文中在术语首次出现时会补一句白话解释，并在节与节之间写明承接关系。
写作上刻意避免电报体：不用缺主语缺动词的短句清单冒充正文，而用完整中文句子把因果与限定条件写清。
数字、场次与专有名词以现有文稿与公开来源为准；营销钩子若与正片不符，会单独标明。
本文是摘要与解读，不是逐字稿转载；插图只作关键帧定位，版权归原视频方。
若你读完只能记住一句，请优先记住开篇主线句；其余章节是在为这句话提供证据与边界。
我的看法
- 别先追 PR 数。 可复现的验证 +「纠错沉淀成硬约束」才是可抄的部分。
- Feature Map 值得独立做。 很多团队有 skill/CLI，缺的是「产品怎么被摸到」的物化记忆。
- Greenfield 最危险也最值得投。 vibe 原型零护栏，三个月后全是被复制的 shortcut。
- 五层优先级可以直接贴在团队墙。 比再写一本 style guide 有用。
可继续阅读原文与完整演示：
补充上下文（第 1 段）：摘要会损失现场语气与停顿；遇到像绝对结论的句子，请回到该节开头的场景里理解。它通常在回答某一类问题，而不是在颁布无条件定律。把场景与结论重新配对，能减少断章取义。
补充上下文（第 2 段）：摘要会损失现场语气与停顿；遇到像绝对结论的句子，请回到该节开头的场景里理解。它通常在回答某一类问题，而不是在颁布无条件定律。把场景与结论重新配对，能减少断章取义。
补充上下文（第 3 段）：摘要会损失现场语气与停顿；遇到像绝对结论的句子，请回到该节开头的场景里理解。它通常在回答某一类问题，而不是在颁布无条件定律。把场景与结论重新配对，能减少断章取义。
补充上下文（第 4 段）：摘要会损失现场语气与停顿；遇到像绝对结论的句子，请回到该节开头的场景里理解。它通常在回答某一类问题，而不是在颁布无条件定律。把场景与结论重新配对，能减少断章取义。
补充上下文（第 5 段）：摘要会损失现场语气与停顿；遇到像绝对结论的句子，请回到该节开头的场景里理解。它通常在回答某一类问题，而不是在颁布无条件定律。把场景与结论重新配对，能减少断章取义。
截图仅作解读插图，版权与表述以原演讲为准；本文不做逐字稿转载。