Lauren Tan：用可执行的检查让 AI 生成的代码更可信

Lauren Tan 说，她上个月向生产环境提交了 3000 个拉取请求。智能体可以让更多工程师大幅提高产出；挑战是产出增加时如何保持甚至提升代码质量。她认为信任的基础是智能体运行的环境，而不是盲目信任智能体。

Tan 说，她花了六个月投入基础建设，才达到能提交数千项修改的程度，其中包括睡觉时完成的修改。她的信任金字塔从代码和架构开始，接着是静态分析和测试，再往上是运行时或形式化验证。规则、技能和 AGENTS.md 则作为较小的一层，处理需要判断的工作。

代码库是智能体最大的输入来源之一。Tan 建议，纠正智能体时先想想能否把纠正转化为自动检查，而不是在指令里再加一行：可执行规则更容易复现，也更值得信赖。

她将代码库比作花园。当几个拉取请求变成数百个，代码就像源源不断的水流；架构和防护措施则是代码围绕生长的固定结构。临时修补、废弃代码和其他坏例子可能扩散，因为智能体会把现有做法当作既定模式来模仿。

她的团队为 Grok Bot 构建了客户端框架 Dune，她把它比作 Electron 应用的 Next.js。她说，框架的重要之处在于一系列约束和 lint 规则，将开发桌面应用的经验固化下来。

例如 React 的 useEffect：Tan 说它有正当用途，但正确使用需要细致判断，智能体往往做不好。团队禁止在产品代码中使用它，只允许在某些 Dune API 内使用。这样就消除了代码审查中的一类反复出现的问题，不必依赖审查者逐一发现。

目录结构也能提供上下文。Tan 在 Cursor 工作时看到智能体将 Electron 主进程代码导入渲染进程，导致长任务和界面卡顿。在 Grok Bot 和 Dune 应用中，独立的 electron-main 和 electron-renderer 目录让边界明确；依赖分析和 lint 规则禁止跨边界导入。

Tan 还见过智能体在文档和注释中为捷径辩护，或者把一次小纠正变成不可变通的规则。她举例说，智能体使用命令式定时器，临时弥补 VS Code 命令式架构与 React 声明式风格之间的冲突。反复创建和清理定时器损害了性能，而注释则解释这些权宜之计为何看似合理。

在 Grok Bot，团队选择禁止约 99% 的注释：Tan 说注释容易过时，也不能自行强制执行。相反，lint 报错应引导智能体修复根因。她的原则是把纠正变成检查，或通过 API 和架构设计消除出错的可能性。

Tan 说，随着检查不断积累，人工审查每项修改需要关注的内容会减少，智能体便可以合并许多自己的修改。她的团队越来越多地审查视频、截图、图表和形式化检查等验证证据。

运行时验证让智能体能够运行软件，并使用 Chrome DevTools Protocol 等调试工具。功能地图从用户视角描述应用，让人与智能体对功能有共同的称呼。可重复使用的命令行工具和驱动程序让这些技能可以测试，也能减少重复消耗的 token。

团队开始尝试形式化验证，用 TLA+ 对跨设备通知等流程建模，并用 Lean 检查算法，包括自研的虚拟化库。Tan 说，这些方法已经发现了一些问题，但它们只是额外的一层防线，并非万能解法。

团队也在尝试用 Bombadil 进行基于属性的 UI 测试，已经发现一些界面问题。Tan 引述另一位工程师的观察：每天 70% 的 token 用于验证；她说自己的 token 也大多用在验证上。她认为，智能体能降低编写和维护这些成熟测试技术的成本。

形式化模型还可以帮助澄清预期行为，以及智能体是否理解这些意图。Tan 的 pstack 插件包含一个 statechart 技能，从用户视角可视化状态机；她认为配合截图和视频，这样的结果更容易审查。

Tan 称，Grok Bot 团队 10 月向生产环境提交约 1.1 万个拉取请求，大约每天发布一个稳定客户端版本。她说，当月至少提交一个拉取请求的有 227 人，其中包括对项目背景了解较少的临时贡献者。

Tan 说，尽管修改数量增加，相对回滚率仍维持在约 0.5%。她称，自产品发布以来，启动、输入、打开聊天和切换聊天的速度都有改善，同时也承认 Electron 客户端存在性能上限。

Tan 建议，在建设软件工厂前先改进代码库：为反复出现的反模式添加 lint 规则，清理已有问题，并加强验证。如果内部编码循环本身产生低质量代码，自动化只会产出更多同类代码，还会消耗更多 token。

Tan 说，基础建设完成后，可以通过连接器、例行任务和项目，让 Grok Bot 编排外部流程。每次发布之后，团队会自动启动一个 Cursor 项目，运行和测试构建产物、发现问题并提交修复；她说，由于有周围的检查，这些修复随后可以自动合并。