每月合入2500个PR，她靠的是让Agent自己验证
本文是 Poteto 与 Matt Pocock 的一小时访谈实录。Poteto 和 Matt 都是 AI Skills 领域的资深开发者，话题从个人经验、Skills 构建，一直聊到多 Agent 协作，以及如何让 Agent 在你睡觉时继续写代码、验证和合入。
这次访谈的起点，是 Poteto 此前分享的一个数字：她上个月合入了 2,500 个 PR。
这个数字很容易让人把注意力放在产量上。但随着 Matt 一层层追问，支撑这件事的工作方式逐渐清楚了：她花了很多时间整理代码库、构建工具、完善验证，再把外部反馈接到 Agent 的工作流程里。
她也明确说，2,500 个 PR 里有大量代码维护工作，不能理解成 2,500 个新功能。这个数字是她的自述，访谈没有提供足够信息去比较每个 PR 的大小、复杂度和实际价值。
不过，把数字暂时放下，这场对话里仍然有很多可以借鉴的做法。尤其是那些每天都在使用 AI，却发现自己仍然需要不断纠正、解释和检查的人，应该能从里面看到一些熟悉的问题。
1. Skills 从你反复纠正 AI 的地方开始
Poteto 最初做个人项目时，已经在用 AI 写代码，但每天仍然花很多时间盯着一个 Agent。
她逐渐发现，自己反复做的事情，是教 Agent 按照她的方式写代码、处理问题、推进工作。Skills 成了她把这些经验交给 Agent 的入口。
Matt 对这一点很有共鸣。他做 Skills，也是在把日常工作中的流程提炼出来，用语言写清楚，让 Agent 可以重复执行。
这也引出了他们共同的判断：领域经验依然很重要。
模型能力越强，人的表达和判断就越容易成为瓶颈。你是否清楚自己想要什么，是否知道问题出在哪里，是否能描述一个好的结果，这些都会影响 Agent 最后做出来的东西。
对开发者来说，经验体现在如何定位问题、选择方案、判断质量。对其他行业的人来说，也可能是对用户需求、业务流程或专业问题的理解。
Skills 给了这些经验一种可以被调用的形式。但前提是，你得把经验里的关键步骤和判断条件整理出来。
例如，告诉 Agent“认真检查一下”，仍然留下了很多解释空间。如果你知道某类修改最容易破坏哪个行为，就可以把复现方式、检查路径和通过条件写清楚。
过去需要你临时补充的背景，开始变成 Agent 做事前就能拿到的东西。
2. 敢不敢放手，取决于 Agent 能不能验证自己的工作
Poteto 讲了一个很具体的经历。
她在做 Cursor Agents 窗口的性能优化时，需要看火焰图（Flame Graph）、内存快照，判断应用为什么卡顿。虽然代码可以让 Agent 写，但诊断过程仍然依赖她。
她形容自己成了 Agent 和 Chrome DevTools 之间的传话人。
Agent 改完代码，她去运行、观察，再把结果告诉它。只要这个环节还需要人，Agent 就很难自己完成一轮有效的迭代。
所以，她开始给 Agent 补上验证能力：运行代码、操作应用、读取调试信息、查看 traces 和 snapshots，再根据真实结果继续修改。
这是她开始建立信任的关键一步。
一次修改之后，Agent 能看到结果；结果不对，它能继续定位；再改一次，它又能检查。这样的循环，才让她逐渐从每一步都要盯着，走向可以把一段工作交出去。
性能优化尤其适合说明这一点。如果有稳定的测量方式和明确指标，Agent 就可以不断尝试改进，并判断修改是否有效。
这里的验证，也远不止“测试通过了”。
界面有没有真的打开？用户操作能不能完成？卡顿有没有改善？是否引入新的问题？这些都需要 Agent 接触运行中的应用。
Poteto 甚至说，即使不用她的 pstack，也不用 Matt 的 Skills，验证仍然是最值得先补上的能力。
3. 能固定下来的操作，就让工具负责
有了验证能力之后，Poteto 又发现了新的浪费。
不同 Agent 都在尝试验证，但每个 Agent 都会重新写脚本、重新搭工具，而且做法各不相同。上一个 Agent 已经解决的问题，下一个又重新来一遍。
于是，她把其中比较机械、确定的部分整理成 CLI，放进 Skills。
这样，Agent 可以调用已经可用的工具，把注意力留给需要判断的部分。
她在访谈里把工作看成一个连续的范围：有些事情需要理解背景、权衡方案；有些事情则是明确的机械操作。
比如，将代码从一种已知模式迁移到另一种模式，其中一部分可以通过脚本或 codemod 完成。没有必要让每个 Agent 每次都重新想一套实现。
这也解释了为什么一个实用的 Skill，可能只需要简短的流程说明，却带着很好用的工具。
文字负责告诉 Agent 什么时候使用、按什么顺序执行、怎样判断结果；脚本负责稳定地完成那些已经确定的步骤。
这种设计能减少上下文消耗，也能减少重复劳动和执行差异。
4. Agent 反复犯的错，值得变成代码库里的约束
工具之外，他们还花了不少时间聊工作环境。
Poteto 提到一个内部框架 Dune，可以理解成服务于他们 Electron 应用的内部框架。它有严格的 lint 规则，也有明确的目录和开发约定。
例如，每个功能有自己的目录。Agent 添加功能时，可以沿着既定结构做，不容易继续往一个越来越大的文件里堆代码。
这些约束来自她观察到的实际问题。
早期代码里出现过巨大的文件。Agent 容易沿着已有模式继续追加，文件就越写越大。她后来拆分结构，并通过规则限制这种做法。
她的思路是：每次发现 Agent 犯错，都退一步想，这个问题能否变成 lint 规则？能否通过代码库结构，让它更难再次发生？
这比在聊天里不断重复同一句提醒更容易积累效果。
因为聊天里的纠正，往往只影响当前这一次工作。环境里的约束，则可以帮助后续所有 Agent，也能帮助刚加入团队、缺少背景的新同事。
在这样的环境里，人和 Agent 都不必反复记住大量隐含约定，可以把精力放在当前的问题上。
5. 2,500 个 PR 背后，是接起来的内外两层循环
Matt 随后问了一个很直接的问题：你总不可能每个月手动开 2,500 个聊天吧？
Poteto 的回答是，她已经把多个工作循环接了起来。
她把代码开发称为“内层循环”：Agent 根据目标修改代码、运行、验证，再继续推进。
而“外层循环”负责接收代码库之外的新信息，例如 Slack 里的讨论、Linear 里的问题、用户在 X 上反馈的 bug。
如果这些信息只能由人收集，再逐条转发给 Agent，人仍然是中间的瓶颈。与此同时，Agent 手里的目标和背景也可能逐渐过时。
她描述的做法，是通过外层 Agent 收集相关信息，再送给内层的项目和协调 Agent。协调 Agent 负责管理任务、传递背景、安排执行 Agent。
整个过程可以理解成：
| 环节 | 主要工作 |
|---|---|
| 外部反馈 | 用户报告问题，团队补充需求和限制 |
| 外层 Agent | 收集相关背景，送到对应项目 |
| 协调 Agent | 关联问题、组织任务、分配工作 |
| 执行与验证 Agent | 复现、修改、检查结果、继续迭代 |
| 人 | 抽查产出，调整目标、工具和规则 |
协调 Agent 的价值，在多个问题有关联时尤其明显。
假设几个用户从不同角度报告应用卡顿，如果每条反馈都立刻交给一个独立 Agent，可能出现重复调查、重复修改，也可能错过共同原因。
把这些反馈放在一起，才更容易看清问题的范围，决定应该怎么分工。
因此，增加 Agent 数量只是其中一步。还需要让它们拿到相关背景，并且有人或协调 Agent 保持对整体工作的理解。
6. 发现问题之后，也可以先不急着修
访谈里有个细节，我觉得很适合日常使用 AI 的人参考。
Poteto 有一个 Agent，会持续寻找 React 代码中的不良模式。但她没有要求它发现一个就修一个，而是先把问题追加到文档里。
隔几天，她再集中查看。
这样做，可以看出一些分散的问题其实属于同一种模式。与其做很多次局部修补，可能更值得改一个公共抽象、增加一条规则，或者调整整个结构。
即时执行很容易让人只顾着清掉眼前任务。保留一段缓冲时间，则给了人和协调 Agent 寻找共同原因的机会。
这也为 2,500 个 PR 补上了必要的背景：大量工作属于代码维护。修 bug、清理不良模式、改善环境，都是其中的一部分。
PR 数量可以说明工作流的吞吐能力，但仅凭数量，还无法判断最终产生了多少用户价值。
7. 人的审查开始更多地影响整个流程
接下来就是最难绕开的问题：这么多 PR，怎么审？
Poteto 承认，规模上来以后，她无法逐个检查所有产出。她的做法是严格抽查代码和 PR，观察 Agent 的坏习惯，再修正整个工作环境。
如果多个 Agent 都在走同一条捷径，或者反复使用同一种 workaround，她会检查 Skills、lint、类型约束和工具，寻找可以统一解决问题的地方。
她也描述了更进一步的工作方式：让多个验证 Agent 实际运行应用、尝试操作、寻找回归，发现问题后继续修复和验证，达到可合入的状态。她早上再检查提交记录，必要时回滚或修改。
但她没有把这个过程说成安装 pstack 就能轻松实现。
她明确提到，这需要大量时间去观察失败、调整环境、建立约束。严格验证也会消耗不少 token，验证 Agent 的数量需要按实际情况调整。
访谈后面，Matt 还追问了不可逆修改，以及难以验证的领域。
Poteto 没有给出一个通用答案。她承认，能否可靠验证，是这种工作方式的重要条件；如果很难通过程序或工具确认结果，走到自动合入这一步就会困难得多。
所以，这里能够借鉴的是她建立信任的方法。自动化可以推进到哪一步，仍然要看具体工作有没有足够可靠的验证，以及出错后能否处理。访谈约 50—60 分钟。
8. 两人的 Skills 可以混用，你的聊天记录也能长出自己的 Skills
最后，他们聊到一个大家很容易问的问题：pstack 和 Matt 的 Skills，应该选哪一个？
两人的态度都很开放。
Skills 本来就是流程的表达，可以阅读、修改、组合。你可以取 Matt 的一些前期思考流程，再接上 pstack 的执行和验证，也可以根据自己的工作方式重新整理。
Poteto 用了一个贯穿访谈的比喻：每个厨师都有自己的刀，换一家餐厅工作，刀也会跟着走。
对使用 Agent 的人来说，也应该逐渐形成自己熟悉、信任的工具和流程。
而建立这些流程的一个好起点，就是过去的聊天记录。
看看自己在哪些地方经常纠正 Agent，哪些背景总要重新解释，哪些步骤每次都需要提醒。里面已经留下了真实的工作过程，可以从中提炼重复出现的经验。
Poteto 的 Recall 就来自这样的需求。她在处理相似问题时，总想把上一段聊天里的重要背景带到新聊天里，于是把这套过程整理成了 Skill。
从这个角度看，Skills 会随着使用逐渐变化。实际工作暴露问题，聊天记录留下过程，工具和规则再把这些经验固定下来。