上月1000个PR，本月目标2000个，其中一个晚上自动合并了约20个。给出这组数字的人是Lauren Tan，前Cursor核心成员，之前在Meta React团队和Netflix待过，现在在SpaceXAI做Grok Bot。她开源了一套叫pstack的Cursor插件，在GitHub上拿了8.1k stars，还写了两篇长文解释这套东西怎么运作。
数字很唬人。但她在文章里自己拆了台：“600多个重构PR才是真实的基础设施。那晚自动合并的20个PR，只是输出。”
这句话基本概括了她整套方法论的立场。Grok Bot的代码库最初是个快速搭出来的原型，架构是“agent觉得怎么方便就怎么来”的状态。每个任务单独看都能完成，但目录结构、依赖关系、进程边界、状态管理随着时间越缠越紧。人能改，但越来越难信任这个系统。她的选择不是让agent继续往上堆功能，而是先把agent的工作环境重建一遍，这个架构她起名叫Dune。600多个重构PR就是花在这上面的。
先说第一篇文章，标题叫"Verification is All You Need"。她的原话是：“如果agent不能验证自己的工作，其他一切都不重要。你仍然是瓶颈，你的一整天都会花在babysitting agent上。”
这里说的验证不是跑测试，也不是build通过。她的定义有四个要素：驱动真实应用、执行真实流程、检查真实产物、给出可视证据。区别在哪？跑测试验证的是代码单元的行为，她要的是agent像人验收那样，在真实运行的东西上确认结果。不同类型的变更对应不同的验证方式：CLI变更要跑真实命令，拿命令输出和预期输出对比；UI变更要在运行的应用里走一遍流程，留下截图或录屏；解析器和迁移类变更要重放已保存的输入，看前后输出的diff；性能变更则前后各跑一次profile，拿性能数据对比。
pstack里有个/create-verification-skill命令，运行后会扫描你的仓库，自动识别项目类型并生成对应的验证技能。也就是说，验证方式本身也被固化成了agent可以反复执行的东西，而不是每次靠人临时口述。
我觉得这是两篇文章里更根本的一篇。agent写得快不是新闻，写得快还能自己确认写对了，才是能不能放手的前提。没有这一层，你省下的写代码时间会全部花在盯agent上，总量反而没变。
第二层是Dune架构，核心判断一句话：“Agent喜欢走捷径，所以让最短路径就是正确路径。”
具体做法有四条。Feature共置，一个功能的状态、组件、逻辑放在同一个目录，不分散，agent找东西和改东西都在一处。进程边界，主进程和渲染进程清晰隔离，重任务不挤UI线程。依赖图CI检查，机械地阻止跨层、跨进程的import。危险模式禁用，用lint把agent反复误用的模式直接编译报错，比如滥用useEffect。
四条里最值得展开的是最后两条背后的一个区分：规范是软约束，架构是硬边界。
拿“禁止UI包直接访问数据库”这条约束举例。写成规范，就是往docs/CODING.md里加一行“UI层不允许直接import数据库模块”。问题是，agent可能读到这个文件，也可能没读到；读到了，也可能在生成第50个文件的时候忘了。写成架构约束，则是往eslint.config.js里加一条no-restricted-imports规则，把@packages/db/*设为error，附上message“UI层禁止直接访问数据库，走@packages/api”。每次CI都强制执行，没有例外。
前者是“请你不要”，后者是“你不能”。规范要求agent每次都记得并遵守，依赖它的配合；架构约束直接让违规这条路不存在，不依赖任何配合。对概率性的执行者来说，这两者的可靠性差距比对人类大得多——人偶尔违规，agent在长任务里“偶尔”的频率会放大成常态。
这里有点意思的地方在于，这些道理没有一条是新的。Feature共置接近很多团队已经在做的模块化，进程边界是桌面应用的老话题，“用lint封路”也是前端圈多年的实践。区别只在执行强度：人类团队靠code review和自觉，能执行个七八成；agent团队必须执行到100%，因为你不在这个循环里。这套逻辑对人类团队同样成立，只是对人类团队更难推行——你没法给同事的useEffect上编译报错。
收尾回到Grok Bot这个产品本身。它是SpaceXAI在2026年8月11日发布的东西，定位是“有自己电脑的常驻agent”：每个Bot跑在一台持久的云端电脑上，带浏览器、文件系统和终端，任务在你的真实工具里完成，你合上笔记本它还在干活。Bot之间可以互相协作、在群聊里共享上下文、传递任务的所有权。官方文档里有个说法是“上下文随时间复利”——一个有名字的Bot跨会话保留记忆、文件、浏览器会话和偏好，而不是每个任务都从零开始。它还能从演示中学技能：你带着它走一遍多步骤流程，它把路径存成技能，之后按计划重跑。
把这些拼起来看，Lauren Tan的方法论和这个产品形态是同一件事的两面。当agent从“你问一句它答一句”变成“常驻的、有记忆的、在你真实环境里干活的队友”，它对环境的依赖会越来越深——环境乱，它就乱；环境有硬边界，它就被迫走正路。验证解决“它做的对不对”，架构解决“它下次还做得对不对”。前者管单次产出，后者管复利。
每月2000个PR这个数字本身，我倒觉得不必急着信或疑。值得盯的是那600多个重构PR的投入产出比能不能持续，以及验证技能在更复杂的项目上会不会失效——毕竟她的代码库是她自己一个人（加agent）维护的，换到一个几十人、历史包袱十年的仓库里，Dune还能不能立得住，是另一回事。