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