SpaceXSI Principal Engineer @poteto 在 AI Engineer Code Summit 2026 @aiDotEngineer 分享「All Code Is Slop (Except Mine)」

她真正想论证的是软件工程师的工作变化：在大幅提高产出的同时，维持甚至提高代码质量。

有人把这条路叫做软件工厂，她更愿意把它说成信任！ https://x.com/i/article/2121939973230518272

SpaceXSI 团队 Poteto「All Code Is Slop (Except Mine)」：Grok Bot 把纠正写进代码，一个月合 1.1 万 PR

SpaceXSI Principal Engineer Lauren Tan @poteto 在旧金山的 AI Engineer Code Summit 2026 主舞台做了这场 17 分钟的主题分享，题目是「All Code Is Slop (Except Mine)」。关于 AI Engineer Code Summit 2026 的整体介绍信息可以先看我的解读文章：

她开场说，自己上个月往生产环境合并了 3000 个 pull request，其中不少是在睡觉时合进去的。走到这一步花了大约六个月。她真正要论证的并不是数量本身，是软件工程师的工作正在变成：在大幅提高产出的同时，维持甚至提高代码质量。有人把这条路叫做软件工厂，她更愿意把它说成信任：不是盲目相信 agent，而把时间投进 agent 的工作环境，让人有理由相信它们会做对的事。

该把时间花在哪一层

她用一座倒金字塔来安排投入。最下面两层是确定性的，都落在代码本身：一层是接口设计、架构和重构，一层是 lint 规则、类型系统、编译器和测试。这两层合在一起，用来限制 agent 能写出什么，并迫使它默认走正确的路。再往上是验证，包括运行时验证和形式化验证，用来找缺陷、检查系统里应当始终成立的性质，也用来判断 agent 是否真的理解了目标和意图。最上面只留一点书面说明：规则、Skills、AGENTS.md，留给那些还需要判断、暂时写不进检查的事情。

她反复强调的纠正方式是：每次纠正 agent 时，先想能不能做成一条可重复执行的检查，而不是再往 AGENTS.md 里加一行。写进代码里的约束，比写在说明里的句子更容易复现，也更值得信任。

代码库是最大的输入，也是会扩散的花园

Agent 的输出取决于输入，而代码库往往是最大的那一份输入。2024 年她还记得上班时审同事写的三个 pull request；现在更接近 300 个。每个工程师身边都是几百甚至几千个 agent，代码几乎是连续涌进来的，像活的东西一样往外长。她把代码库比作花园：人立下的约束和护栏，是新代码会顺着生长的混凝土基础。于是工程师的工作，越来越像园艺。

这也带来一个很实际的后果。权宜之计、过时写法、技术债务，在 agent 看来都像是「这里的惯用做法」，下一个 agent 很可能会照着抄。杂草会自己蔓延。所以她主张把代码库尽量收拾干净，让 agent 总是在复制好的部分。

用框架和检查，把一整类错误从审查里拿掉

Grok Bot 团队为此做了一个客户端框架，叫 Dune。她说它在技术上并不特别新鲜，可以粗略理解成面向 Electron 应用的 Next.js；真正有意思的，是里面写进了大量做桌面应用时攒下来的约束和 lint 规则。

一个原则是：凡是用好需要很多分寸的接口，往往容易产出低质量代码。她举的例子是 React 的 useEffect。它有适用场合，但误用很常见，agent 也用不好。他们的做法不是继续在审查里盯着它，而是禁止在产品代码里使用，只在 Dune 的部分接口内部允许。这一类问题就此从代码审查里消失了。

另一个做法是用目录结构把约定说清楚。她提到在 Cursor 这个同样基于 Electron 的应用里，agent 经常把主进程的代码导入到渲染进程，造成长任务和卡顿。在 Grok Bot 和 Dune 里，顶层就分成名为 electron-renderer 和 electron-main 的目录，依赖分析器和 lint 规则禁止跨边界导入。规则本身并不复杂，但审查时又少了一件要反复盯的事。

再往后，审查里要盯的事情会越来越少。她说，做到一定程度，会发现几乎没有什么必须人看，大多数 pull request 可以交给 agent 自己合并。

注释和说明，可能变成绕开正确做法的借口

一场更意外的观察是：agent 会把 Markdown 当作为自己开脱的地方，包括文档、代码注释、规则和 Skills。它们会在那里写下「为什么这次可以不按正确方式做」；也可能把你随口说的一句小纠正，理解成永远不能打破的硬规则。

她举了在 Cursor 时的例子。当时 agent 很爱用 setTimeout、requestAnimationFrame、requestIdleCallback 这类命令式定时器，作为权宜之计，去修补 VS Code 的命令式风格和 React 的声明式风格之间的架构冲突。大量快速创建又销毁的定时器会加重垃圾回收，界面因此变卡。更糟的是，agent 还写下大量注释，解释这次权宜之计为什么合理。下一轮 agent 看到这些注释，会把它当成既定做法，定时器于是蔓延到各处，应用性能明显变差。她的判断是：当时的架构选择，把客户端和 agent 的表现都变差了。

到了 Grok Bot，他们选择禁止约 99% 的注释。理由不只是注释容易过时、人也很少认真读，更在于注释没法强制执行：你以为自己在告诉下一个 agent「不要这样做」，实际上什么都拦不住。他们改用带有清楚说明的 lint 报错，要求 agent 去修真正的根因，而不是在旁边打补丁。总原则是：每次纠正，要么变成一条确定性检查，要么通过更好的接口和架构，把这类问题从根本上拿掉。

审查的对象，从 diff 变成验证产物

信任的另一半是验证。她说，现在的代码审查已经收成主要看验证产物：录像、截图、图表、形式化验证的结果。

最基础的是运行时验证，说白了就是让 agent 自己把程序跑起来，并用开发者常用的调试工具，比如 Chrome DevTools 协议。他们的运行时验证技能里有一份功能地图（feature map），相当于从用户视角列出应用里有哪些功能的站点地图。这样你说「左侧栏里那个东西」时，agent 不必靠猜，双方有共同的叫法。技能里还配了可复用的命令行工具和驱动程序，既少花 token，也可以纳入测试。

形式化验证他们仍在试验，但已经用来处理一些关键路径。用 TLA+ 做模型检查，例如跨设备、跨平台的通知流程；用 Lean 证明某些算法，比如他们自己写的虚拟化列表库，用来排除闪烁和抖动。她说已经找到了不少缺陷，看起来有前途，但绝不是万能药，只是环境里的又一层工具。界面上他们还开始用名为 Bombadil 的库做基于属性的测试，也已经抓住过一些界面缺陷。

她提到 Cindy 的变化：六个月前，Cindy 还因为合进去的细微缺陷，不敢信任自己的 agent；六个月后，她说每天 70% 的 token 花在验证上。Tan 认为这和自己的体会一致，自己大部分 token 也花在验证上。这些方法本身并不新，只是从前写起来、维护起来太贵，现在 agent 把成本压了下来。她因此说，软件测试和验证正在进入黄金时期——不是因为验证变少了，而是因为可以验证得更广、更深。她还在自己的插件 pstack（potato stack）里做了一个名为 statechart 的技能，用来从用户视角把状态机画出来，和录像、截图放在一起审，比只看一次成功状态的截图更清楚。

先把内循环做可靠，再谈软件工厂

作为这些投入的回报，她给出一组团队自报数字：上个月 Grok Bot 团队往生产环境合并了约 11000 个 pull request；客户端大约每天切出一个稳定版；10 月有约 227 人至少贡献过一个 pull request，其中也包括上下文并不充分的顺便贡献者。相对回滚率不但没有升高，还稳定在大约 0.5%。她认为更值得看的是：在这样的速度和人数下，Grok Bot 的启动、输入、打开新对话、切换对话，都比发布时更快。它目前仍是 Electron 应用，表现有上限，但她认为已经比不少其他 agent 界面更快。

她把顺序讲得很明确。不要一上来就建软件工厂、把能自动的都自动掉。每次纠正 agent，先改代码库：先加 lint 挡住新的错误写法，再把旧的清理掉；同时把验证做扎实。这些本来就是自动化的前提。如果内循环本身在产低质量代码，把循环自动化，只会更快、更贵地制造更多低质量代码。

基础打好之后，外循环才变得容易。她举例说，现在每次切出新版本，Grok Bot 会自动拉起一个 Cursor 项目，对整个应用和构建做模糊测试，像真实用户一样操作，找到缺陷后分别开出修复的 pull request，并自动合并。听起来大胆，前提是代码库已经好到「默认就过得去」，大多数产品代码不再需要人做很深的审查。

我的一点读后感

这场分享非常强调：纠正该写到哪里。agent 反复犯同一类错时，最省事的反应是再往 AGENTS.md 里加一句；Tan 要人把这句话从说明里挪走，写成接口、目录约定或一条会报错的检查。注释和 Skills 文档在这里被重新估价：它们留存的往往是借口，不是约束。

另一层同样值得学习的，是验证正在变成主成本。她和 Cindy 都把大部分 token 花在验证上，形式化方法和基于属性的测试也因为 agent 变便宜了，重新变得划算。这和「让 agent 写得更快」不是同一件事，甚至可能相反：要放心地合并，就得把更多计算用在证明它做对了。

这些做法能走到自动合并，和 Grok Bot 自己掌控整条客户端技术栈有关。禁止 useEffect、禁止大部分注释。可迁移的是顺序：先让代码库和验证经得起信任，再放大自动化。内循环如果不可靠，外循环只会把问题放大。