上个月，Grok Bot 团队的 Lauren 使用 AI Coding 把 2000 个 PR 合进了主干。
她说 2000 个 PR 并非她最初设定的目标，而是随着对AI Agent 信任度提升而自然产生的结果。
一开始我以为是噱头，但我发现她的 AI Coding 还是有很多真东西的，我看了 2 遍，接下来我按照她演讲的顺序，和我的理解，一步一步拆解一下她的理念。
本文观点大部分来自于 poteto/Lauren 发表的视频，如果想直接看原视频，直接拉到文章最底部获取
顺序大概如下图 
一、开场：一个卡顿的窗口
她之前在 React 团队待过，后来加入 Cursor。她加入时，团队正在重建 Cursor IDE 的新 Agent 窗口，那个窗口有严重的性能问题，她被安排去解决。
一开始全是纯人工干：打开 Chrome DevTools、跑性能追踪、拍堆快照，整个过程极其繁琐。干到某个程度，她意识到一件事：等等，我们有 Agent，我在干什么？
她把自己当时的角色叫人肉代理------夹在 Agent 和浏览器 DevTools 中间，来回搬数据。
二、信任是一切的基础
她的核心公式是一句话：只有当你信任Agent 能在你不在场时产出高质量工作，你才能真正规模化地使用 Agent。
如果不信任却强行派出 100 个子Agent，结果会是：
- 大量低质量的 PR
- 大量回归和 Bug
- 没有人满意
她把用 Agent 分成两个阶段：
- 1 对 1：你必须全程盯着每个对话，不断纠正 Agent。你一离开，Agent 就做错事。
- 规模化：Agent 自己干活，你只做最终审核和关键决策
从第一阶段跨到第二阶段，中间隔的就是信任。
三、验证技能：让 Agent 自己看结果
她写的第一个验证技能叫 ControlGlass ，也是她整个信任体系的起点。核心一件事：让 Agent 自己能看见干活的结果。
ControlGlass 干的事拆开是这样：
- 让 Agent 自己能跑起这个应用
- 通过 Chrome DevTools 协议（CDP，浏览器开放的调试接口）自动跑性能追踪
- 分析追踪结果，找出热点（可优化地方）
- 改一版，再跑一遍，分数涨了就留下，跌了就回退------这套做法叫爬山（hill climbing），有个能打分的指标，模型就能自己一步步往上走
它有两个组成部分
一个是命令行工具（CLI）。 放在技能目录里，Agent 每次都能一致地调用它来跑应用、收集证据------性能指标、截图这些，而不是每次自己现写脚本。
另一个是功能地图（Feature Map）。 团队用上 ControlGlass 之后遇到一个问题：用户在 Slack 上报 bug，经常只发一张模糊的界面截图加三个问号。Agent 能跑应用，但完全不知道用户指的是哪个功能。
功能地图就是解这个的。灵感来自网站的站点地图（sitemap），它是一份"物化的记忆"，写的是：应用有哪些功能、用户怎么到达（键盘快捷键、点哪个 DOM 元素）、每个功能做什么。它放在技能目录里，是代码库的一部分，还有自动化流程在维护它。
CLI 加功能地图，Agent 既能可复现地操控应用、把追踪跑回来，也能读懂内部同事和外部用户发来的问题。这个验证技能后来成了团队的关键基础设施，一直在维护。
但它只管"对不对"
验证技能回答的问题是：这段代码或这个功能，做了你想让它做的事吗？也就是正确性。
它不回答性能和代码质量问题。这就需要下一层。
四、编码技能与规则（Coding Skills & Rules）
她做的第二类技能是一套叫 pstack 的插件。灵感来自她自己多年软件工程里的实际工作流：调试、功能开发、原型设计。这些技能教 Agent 像资深工程师一样写代码。其实就类似我之前文章里面写的自研 8 大 Skills 去跑编程工作流
这类东西该谁写？她说得很明确：该让团队里最有经验的工程师来写。 把他们的经验编码成 Agent 能照着走的流程，放进团队的技能仓库。
两类技能叠起来：Agent 不光能验证自己做得对不对，还能保证做得好；通过验证，你可以收集真实的性能指标、数字、统计数据和遥测数据。
五、信任五层金字塔
建立信任的手段不止一种，强度差得很远。按优先级从高到低排，一共五层： 
| 层级 | 内容 | 特点 |
|---|---|---|
| ① | 代码库、架构（让错误模式在技术上不可能发生，比如 Dune 的导入依赖图） | 最强约束 |
| ② | 静态分析（lint 规则、编译器诊断、CI 持续集成） | 次强，能自动执行 |
| ③ | 规则、bug bot、技能 | 中等，Agent 可能忽略 |
| ④ | 代码质量技能（教 Agent 写出高质量代码） | 较弱，靠 Agent 执行 |
| ⑤ | 风格指南（只能靠人工 review） | 最弱，PR 量大时几乎不可行 |
每次纠正 Agent 的时候，不妨都往这五个方面想一想，它会让你的代码库质量越来越高
六、Dune：让 AI 严格遵守
她设计了一个思想框架叫 Dune。Dune 应用里强制分区：
- Feature 文件夹：一个功能的所有代码放一个目录里
- Entrypoint：类似 route 的入口
- Transcript Cards：GrokBot 聊天界面里的卡片
- Host：跑在 GrokBot 虚拟机/主进程侧
- Client：驱动整个 Dune 应用的前端侧
框架其实是架构层面的，有严格的模块划分和数据流向和边界，Dune 里代码被严格分区，比如主进程和渲染线程。规矩是：渲染线程的代码绝对不能引用主进程的代码 ，Agent 一旦这么写，系统就阻止。 
在 Dune 框架范围内的代码库内 AI 执行会被极度限制在能做什么、不能做什么。她设定的是以后往代码库里提 PR 的不一定都是工程师，可能是设计、产品，甚至是 CEO------得让没什么上下文的人也能默认做对。
我的理解，往小了说类似 SDD 里面的宪法级别的东西，往大了说，就是 Harness 框架
三大原则
- 删掉已有的技术债
- 强制执行单一的"铺砌路径"（Paved Path）：一件事只有一种常规做法，Agent 不需要猜
- 看到反模式立刻写 lint 规则：不一定马上清理干净，但至少阻止它扩散
导入依赖图：不是功能地图
Dune 通过导入依赖图（Import Dependency Graph）强制执行架构边界：构建的时候检查代码文件之间怎么互相引用，越界就报错。
这两个东西都像"给 Agent 一张地图"，但它们是两样：
| 功能地图（Feature Map） | 导入依赖图 | |
|---|---|---|
| 面向谁 | 面向 Agent | 面向代码架构 |
| 回答什么 | 这个应用怎么用、有什么功能 | 代码文件之间如何相互引用 |
| 用途 | 让 Agent 理解业务和 UI 操作 | 让 Agent 遵守架构规则 |
| 存储位置 | 技能目录 | 框架、构建系统 |
为什么把注释全禁了
我们会经常发现，AI 写的代码，特别多的注释，表面上，Agent 会用注释给糟糕的短期方案找借口。
再往深一层：Agent 看到一段奇怪的代码，旁边一句注释写着"为什么这里要这么处理"，它的思维就变成------这里有个注释解释了，那我的工作就完成了。 它不再尝试解决根本问题。
对人来说，我们看到注释会先怀疑它是不是过时了。对 Agent 来说，注释是一个处理到此为止的完成信号，很容易被当成收工。
再加上它的复制天性：一个注释模式被一个 Agent 留下，其他 Agent 看到就抄，几天之内整个代码库都是打了补丁的烂代码。
所以 Dune 里完全禁止注释，逼 Agent 直面代码本身。逻辑复杂，就把它写清楚，不能丢一句注释就跑。
七、花园，和园丁
她管代码库叫花园。
一开始都看着无害的小问题------一个 workaround、一句注释、一个反模式------因为 Agent 的复制天性会像野草一样疯长。很快你手里就是一个"凭感觉写出来"（vibe coded）的代码库：难以维护，性能问题一堆。
所以她的提议是，每个团队都需要一个园丁。这个人的职责是：
- 不断审视代码库
- 及时识别"杂草"，也就是反模式
- 在它扩散之前拔掉
- 让代码库始终处在一个状态：即使被 Agent 复制也没问题
这里有个心态上的转变：你应该希望代码库的每一个部分都被 Agent 复制。 如果哪一块你不想被复制，那说明它该清理了。
标准只有一句：这段代码，如果被 Agent 复制了，你会不会高兴？
八、内外循环协同
外循环：Grok Bot
外循环由 Grok Bot 负责。她能把它接到各种外部服务和工具上：Slack、Sentry（错误监控）、DataDog（性能监控）、PlanetScale（数据库），还有其他任何在用的服务。
接上之后，Grok Bot 做三件事：聚合信息、做决策、自动触发行动。真正省事的是 routines------订阅一个 Slack 频道或者盯住 Sentry 的告警，一出事自动触发；它判断该修，就自动起一个云 Agent 去处理。
有人管这套叫"公司大脑"。她的态度是：你不需要那么复杂的架构。 Agent 本来就擅长使用工具，把工具连上、让 Grok Bot 自动触发云 Agent，闭环就成立了。
内循环：Cursor
内循环是云 Agent 真正干活的地方，在 Cursor 环境里。它用的是你事先搭好的那一整套基础设施：Dune 的架构约束、lint 规则、编码技能、验证技能（ControlGlass 加功能地图）、规则和 bug bot。
一条报警走完全程
场景：线上出现一个性能回归，用户还没大规模投诉，监控先报了警。
角色：Grok Bot（外循环）+ Cursor 里的云 Agent（内循环）。
核心目标：没人介入的情况下修掉它，并且证明真修好了。
输入：Sentry 的一条性能告警。
处理流程：
- Grok Bot 收到告警，理解它
- 它自动决策：这是个要修的 bug，起一个云 Agent，把上下文一起带过去
- 云 Agent 用 ControlGlass 跑起应用，先复现------确认问题在主干上真的存在，而不是用户环境或者缺了个依赖
- 用功能地图定位是哪个功能、从哪个入口进
- 用编码技能改代码，跑 lint 和 CI 保质量
- 再用 ControlGlass 验一遍修复，提交 PR
输出与校验：一个带着修改前后性能数字的 PR。Grok Bot 会通知你"bug 修好了，看看 PR"------但你看不看都行，验证已经替你跑过一遍。
说到这里可能大家会混淆每一层的核心概念，我放一张图供大家参考
九、收尾：米其林厨房
她不喜欢"软件工厂"这个比喻，因为它暗示流水线式的批量生产。
她更喜欢米其林厨房。
- 你是主厨
- 你精心设置好一切：设备（工具）、流程（框架）、每个厨师（Agent）的技能和培训
- 最终的代码产品是创造性的艺术，而不是简单的组装
- 你花大量时间在"厨房设置"上，而不是亲自炒每一道菜
她最后的话：信任没有捷径，全靠辛苦的前置工作（Harness）。但等这些都搭好之后，你的团队就不再是一个需要时刻监督的作坊，而是一个能稳定产出高品质作品的米其林厨房。
欢迎大家关注我的公众号：深入浅出AI ，如果需要视频版本，私信发送
poteto,自动获取
