Poteto 的 2,500 个 PR：让 AI 自己验证工作

原始视频：LIVE: Poteto (creator of pstack) on shipping 1,000’s of PR’s a month at SpaceX

Matt Pocock 频道 · 直播日期：2026-10-02 · 时长：1 小时 5 分 36 秒

主持：Matt Pocock · 嘉宾：Lauren Tan，网名 poteto，pstack 作者，访谈中介绍了她在 Cursor／SpaceXAI 的工程实践。

整理说明：依据完整英文自动字幕改写，人名、产品名和技能名称结合官方资料校正。PR 数量与内部工作流来自嘉宾自述，未经独立审计。

一个月交付 2,500 个 PR，接下来最容易被问到的就是：谁把这些代码看完了？

Lauren Tan 在与 Matt Pocock 的对谈中，把答案放在了代码生成之前。她花了大量时间教智能体运行软件、检查结果、读取外部反馈，也不断调整代码库，让常见错误更难发生。等这套工作方式逐渐稳定，才有了持续并行和自动合并的空间。

2,500 个 PR 是她对上个月工作量的自述，其中包含大量维护、重构和代码整理，不能等同于 2,500 个新功能。 访谈也没有给出可独立核对的 PR 清单、缺陷率或成本对比。这组数字适合用来理解她的工作规模，无法单独证明效率或质量。

比起“软件工厂”，Tan 更喜欢“米其林厨房”的比喻。一个人做饭，可以包办采购、备菜、烹饪和清洁。厨房里多了几位厨师，就需要分工、工具和稳定流程。主厨开始负责整个厨房的运转，依然要为端出去的菜负责。她认为，使用多个编程智能体也遵循类似的逻辑。

信任从实际运行中积累

加入 Cursor 后，Tan 曾参与智能体窗口的性能优化。最初，她自己打开 Chrome DevTools，查看火焰图和内存快照，再把观察到的情况转述给智能体。

这个过程让她成了人工中转站。智能体负责修改代码，她负责启动应用、观察现象、解释结果。每轮迭代都要经过她，并行规模自然受到限制。

她最早补上的能力，就是让智能体获得检查真实软件的手段：启动程序，像用户一样操作，采集性能信息，判断修改是否有效。智能体看到失败后，还能继续定位、修改并再次验证。

“完成”需要对应可观察的行为。 测试通过可以构成证据，应用里的目标流程能否真正走通也需要检查。对谈中，两人还批评了那些只重复实现逻辑、无法发现真实错误的测试。增加测试数量，并不能自动增加信心。

pstack 的公开实现能帮助理解这一点。创建验证技能会为具体项目整理启动方式、操作手段和功能地图，并要求实际运行验证；维护验证技能则让这份地图随应用变化更新。验证说明本身也会过时，需要持续维护。

Tan 说，这类能力后来成了团队共用的基础设施。它降低了每个智能体重新摸索应用的成本，也让工程师逐步获得放手的依据。对应视频片段

把重复动作固化成工具

刚开始让智能体自己验证时，Tan 又发现一种浪费：每次任务都会重新写一套控制和检查脚本。上一轮已经跑通的办法被丢在一边，下一轮从头摸索，操作方式还各不相同。

她把其中稳定、机械的部分提取成命令行工具。比如，通过 Playwright 和 Chrome DevTools Protocol 操作应用、采集信息，就可以封装成可重复调用的步骤。技能只需说明何时使用，以及怎样判断结果。

这里有一条实用的分界线：分析多个线索、选择方案、判断取舍，适合交给模型；固定格式转换、重复操作、已经确定的代码迁移规则，可以交给脚本。她以按语法结构进行代码转换的工具为例，说明迁移任务也能把判断与机械执行分开。

已经解决的重复动作，应当成为下次任务能直接使用的工具。 这样既减少上下文消耗，也省去反复创建、调试临时脚本的时间。对应视频片段

把经常犯的错误变成工程约束

工具解决了操作效率，代码库的结构决定智能体容易写出什么样的代码。

Tan 提到，早期 Grok Bot 曾由大约 8 个巨型文件组成，每个文件至少有 10,000 行。这个内部案例来自她的回忆，也解释了她后来为什么强调按功能拆分目录。

她介绍了一套名为 Dune 的内部框架，把它形容为用于 Electron 应用的内部版 Next.js。它通过明确约定、功能目录、自动发现机制和严格的 lint 规则，缩小实现同一需求时的随意选择空间。这套框架没有开源，访谈提供的是设计思路。

发现智能体反复把代码塞进大文件，工程师可以调整模块边界；发现相同的错误模式，就考虑用类型、静态检查或构建规则拦截。原来需要人一次次提醒的要求，逐渐进入代码库本身。

这也是她所说的“磨刀”。持续盯着每次修改，会挤占改进工具的时间；投入一段时间建设环境，后续任务才可能减少相同的返工。重复出现的问题，值得修正产生它的条件。对应视频片段

把外部反馈接进开发过程

可靠地完成一个任务以后，下一道问题是：任务和上下文从哪里来？

Tan 把自己的工作分为内外两层。内层是智能体理解目标、修改代码、验证结果；外层是 Slack、Linear、X 和邮件里的缺陷报告、用户需求，以及团队新发现的限制。

如果内层只拿到任务开始时的一份需求快照，外面的信息更新了，人就得再次搬运。她在访谈中介绍的配置，是让 Grok Bot 持续收集这些信息，再把相关内容发送给 Cursor Projects。

项目中的协调智能体负责整理目标、安排任务、把上下文传给执行者并跟进进度。它不必亲自完成每一处修改。Tan 把这类角色比作行政总厨：知道有哪些订单，知道谁在处理什么，也能发现几份订单之间的关系。

因此，她没有手动启动 2,500 次聊天。持续到来的反馈和已有任务，会经过协调后转成具体工作。这是她当时使用的系统组合，访谈没有证明所有用户都已具备相同的产品能力和配置。对应视频片段

先积累问题，再找共同原因

收到一条缺陷报告，就立即分配一个智能体修复，看起来很直接。但同一处性能问题可能产生多条报告，逐条处理容易形成重复补丁，也容易漏掉更上层的原因。

协调者的价值就在这里。它能把相关报告放在一起，识别共同点，再决定应该如何分工。Tan 还分享了一个更克制的做法：她让智能体持续查找 React 中的不良写法，先把发现追加到文档里。

她每隔几天查看这些记录，常常会发现多处问题其实属于同一种模式。这个缓冲区给人和智能体都留下了观察全局的机会，避免刚看到表面症状就急着修改。

处理得更快，也需要保留发现共同根因的时间。 扫描、汇总、判断和修复可以分成不同阶段。适合统一调整结构的问题，就不必拆成一串彼此孤立的小修补。对应视频片段

自动合并以后，人仍然检查结果

Matt 最关心的追问，终于回到了审查：这么多 PR，Tan 是否每个都看过？

她介绍的做法是抽样检查与事后复查。她会严格查看部分 PR 和代码，观察智能体是否重复使用捷径、临时绕法或低质量模式。若相同问题持续出现，就调整技能、规则和环境；已经合并的改动有问题，也会撤回或修改。

据她描述，当时已有超过 10 名类似“参谋长”的协调智能体，分别负责性能、用户缺陷等方向，相关任务可以 24/7 运行。部分项目还只是探索性实验，例如尝试用其他语言重新构想桌面应用，不能把这些活动都理解成正式产品功能。

她使用的自动合并流程，会在每个 PR 上安排验证智能体运行应用、尝试用户操作、寻找回归问题，发现问题后修复并再次检查。满足这套流程的要求后，智能体才推进合并，她随后查看提交历史。

这套方法也有明确成本。Tan 说，多轮、多智能体验证非常消耗 token。她举例，可以把 10 个验证智能体调整成 1 个，或者让执行者检查自己的工作，但验证投入会随配置而变化。

她获得的信任来自长期改进验证和环境。 她明确提醒，安装 pstack 并不会立即得到同样的工作方式，达到这个阶段需要大量时间和有意识的调整。对应视频片段

验证能力决定放手到哪一步

访谈没有回避自动合并的边界。Matt 提出，有些修改可以合并后再撤回，有些却可能造成数据丢失，很难恢复。对这类工作，该如何处理？

Tan 的回答保留了不确定性。能够明确验证结果的领域，更容易建立这种工作方式；如果工作很难通过程序验证，就很难达到同样程度的自主运行。她也谈到形式化验证和面向智能体的语言，但承认自己没有通用答案。

从这段讨论看，自动合并应当和可验证性、可恢复性一起考虑。通过某组测试，无法让已经发生的不可逆操作变得可逆；有限的检查，也不能覆盖所有系统后果。这是从访谈边界延伸出的判断。

PR 吞吐量不适合作为授权尺度。更有用的问题是：当前任务能拿出哪些完成证据，哪些后果仍然无法检查，以及出错后有没有可靠的恢复方式。对应视频片段

从反复接管的地方提炼自己的技能

对谈最后，两人讨论了如何使用彼此的技能库。Tan 鼓励开发者形成自己的工具组合。别人的技能可以借鉴、组合，具体工作方式仍要经过理解和试用。

她给出的起点很具体：回看过去与智能体的聊天记录，找出那些不得不反复纠正、解释背景和接手操作的地方。真实记录里，既有失败方式，也有后来跑通的过程，可以据此提炼新技能，或改进类型和检查规则。

pstack 的 recall 就来自这样的需要。她在处理 Cursor 的虚拟化相关缺陷时，经常希望把上次聊天的有用背景带入下一次任务，于是把寻找、恢复旧上下文的过程整理成了技能。

她还判断，模型能力增强后，技能会逐渐减少具体命令的说明，更多保留流程、步骤与判断依据。这是她对技能演进的看法。项目独有的知识，以及怎样算完成，仍然需要被清楚表达。pstack 官方说明也把少写代码、保持质量和建立可信的并行能力放在核心位置。

这与她在访谈开头对专业经验的判断相呼应：理解业务、知道理想结果是什么的人，更容易向智能体传达准确的意图。模型越能执行，人的目标、品味和验收标准就越需要清楚。

这场访谈提供了一条可借鉴的改进顺序：先识别一个反复需要人工接管的环节，让智能体能完成并验证它；再把已经证明有效的过程沉淀成工具和规则；当结果足够稳定，才扩大任务规模。主厨依然决定菜单，也依然对端上桌的成品负责。对应视频片段