技术博主 Matt Pocock 与 Lauren Tan（网名 Poteto，开源项目 pstack 的作者、现任职于 SpaceX AI／Cursor）进行了一场深度对谈。

Lauren 介绍，自己正在参与 Grok Bot 这款 Agent 应用的工程工作，上个月合入了 2,500 个 PR。（PR 是提交给代码库审查和合并的一组改动）两人核心探讨的是：如何摆脱当 AI 的“人形搬运工”，借助 Agent 与工具链，让代码工作从写出来走到自行验证、合并，并达到她所描述的交付规模？

访谈里，Lauren 描述的工作方式，很少涉及怎样更快地输入提示词。她把大量时间花在另一件事上：找出 Agent 为什么还需要自己介入，再让系统接住这些工作。

pstack 是一套技能插件，把她的开发方法整理成 Agent 能使用的技能和工作流。她分享的 PR 数量包含许多代码维护变更，不能等同于数千个新功能。这个数字值得关注的地方，是持续交付不再要求她亲自启动、指导和检查每一项工作。

这恰好戳中了很多 AI 开发者的困境。代码生成变快了，人的一天却仍被“帮它看看”“给它补点背景”“再提醒一次规范”填满。Agent 能替你执行，但整套工作依然围绕你的注意力运转。一旦多开几个任务，等待你回答的问题也跟着增加。

要走出这个局面，需要改变工程经验的存放位置。原本只有你知道的检查方法、设计习惯和项目背景，必须逐渐进入工具、代码库与信息通道。Agent 才能在需要的时候获得它们，而不必每次停下来等你。

从人工介入的地方，找出系统缺少的能力

Lauren 最早的尝试并非发生在大规模团队里。离开 Meta 后，她休息了一段时间，又开始做个人项目。用 AI 写代码时，她发现自己花了很多时间微观管理单个 Agent，便开始把自己的工作方法写成技能。她想让 Agent 更像自己那样处理问题，而不仅是生成一段能用的代码。

这里有个容易被忽略的细节：她当时也很难衡量技能到底带来了多大改善。写出工作流文档，与证明 Agent 真能独立把工作做好，是两件事。

后来加入 Cursor，她参与智能体窗口的性能优化。界面为什么卡顿，需要查看性能火焰图，了解时间主要耗在哪些操作上；还要检查内存快照，判断内存使用是否异常，再据此寻找代码问题。最初，这些观察主要由她完成：她看工具，把发现告诉 Agent，Agent 改代码，她再回去检查。

在这条链上，真正稀缺的能力并非输入代码，而是获得结果并解释结果。只要这一步始终需要人，Agent 的下一次行动就始终依赖人。

因此，“哪里又需要我帮忙”可以成为一个具体的工程问题。它可能意味着 Agent 没有观察运行结果的工具；也可能意味着它不知道最新需求，或代码库没有表达清楚哪些做法不可接受。弄清缺的是哪一种能力，才能决定该补什么。继续加一句提示词，有时只会把同一个问题推迟到下一轮。

你经常在哪一步接手？

选一个困扰，对照需要补给 Agent 的能力，以及怎样判断它是否真的减少了等待。

当前困扰 全部对照 每次都要我打开应用检查 总要重复提醒代码规范 新反馈只能由我转述 任务越多，越容易重复施工

正在对照四种人工等待。

等你看结果 → 让它接触运行中的应用

补上启动、操作和采集结果的工具，让 Agent 能重复检查同一目标。

观察：修改后，它能否自行比较实际表现，而不是只说代码已完成？

读性能优化的例子 →

等你提醒规范 → 让环境在出错时反馈

把已经形成共识、能够自动检查的做法，放进目录约定和代码检查规则。

观察：同一种错误能否在当前任务中被拦下、修正，减少下一次提醒？

读 Dune 的代码约束 →

等你转述背景 → 让它找到实际信息

连接反馈渠道与项目工作，让新消息进入任务；收到故障报告后先调查、复现。

观察：它能否确认问题仍然存在，而不是看到一条反馈就开始改代码？

读 Slack 反馈如何进入工作 →

等你逐条派任务 → 先看问题之间的关系

用协调器分配相关工作，让巡检先积累发现，再识别重复模式。

观察：相关报告是否被一起理解，共同原因是否得到处理？

读协调与巡检的分工 →

看得见结果，Agent 才能从执行走向改进

性能优化提供了一个很清楚的例子。你要求 Agent 改善卡顿，它完成修改之后，必须能重新运行应用、重复相关操作，并读取新的性能数据。否则，它只能判断代码是否像一项优化，无法判断用户体验有没有改善。

Lauren 重视的验证能力，就是把这条反馈链接通。通过 Playwright、Chrome DevTools 协议等工具，Agent 可以运行应用、操作界面、抓取轨迹和快照，再用这些结果决定下一步。她强调的“眼睛和手”，指向的是对真实运行状态的访问。

有了可重复的检查，任务才会变成持续改进的过程：修改、运行、比较结果，再保留或调整方案。她用“爬山”描述这种方式——需要有可以判断进展的标准，Agent 才知道自己是否正在接近目标。循环的价值来自反馈，不来自多运行几轮本身。

但“让 Agent 自己验证”还会遇到新的浪费。Lauren 发现，没有固定工具时，Agent 常常每次重新编写检查脚本。前一个 Agent 已经解决的问题，后一个又要重新实现；有时工作还没开始，时间就耗在调试检查工具上。

她因此把重复操作做成命令行工具：启动环境、与浏览器通信、收集诊断数据等步骤，可以复用同一套实现。批量改变明确的代码模式，也可以交给脚本处理。Agent 则负责选择方案、理解结果，以及判断接下来该查哪里。

这是一种很实际的分工。能明确表达为程序的步骤，集中维护、反复使用；需要结合背景作判断的部分，留给模型。技能文档负责说明工作怎么推进，不必让每一次任务都从重新造工具开始。

这套能力也不止服务于她一个人。Lauren 说，团队已经为各个应用建立了自动维护的验证技能，大家共同使用。一个人把应用的检查方法接好，其他人的 Agent 就可以沿用，不必各自摸索一遍。验证因而成为团队的基础设施：它需要随应用持续维护，价值也会在不同任务中反复发挥。

检查方法本身仍然需要工程判断。两人谈到 Agent 会写“同义反复式测试”：测试看似在验证功能，实际只是重复实现逻辑，提供不了有意义的检验。把运行测试交给 Agent，不能省去人对“这项测试究竟能发现什么错误”的判断。有效的验收标准，才是可复用的能力。

代码库应该让经验在出错的那一刻发挥作用

观察结果解决的是“改动有没有效果”，代码库约束解决的则是“哪些做法不应该进入结果”。两者相互补充。

Lauren 提到，Grok Bot 早期版本曾由约八个上万行的大文件构成。Agent 在这样的结构里继续追加功能，最省事的办法往往就是再塞进一段逻辑。人可以反复要求它模块化，但目录和入口没有形成明确约定时，每一次新增都需要重新作出结构选择。

她介绍的内部桌面应用框架 Dune，为功能组织提供了更清楚的路径：每个功能有自己的目录，通过约定的注册和发现机制接入，再由代码检查规则约束不合适的写法。新增功能在哪里写、怎样接入，都已经体现在环境里。

这与她熟悉的类型收窄思路相通：减少可能路径，让当前允许的做法更明确。目的不是把所有判断都写死，而是避免每次都重新讨论那些已经形成共识的工程选择。

提示词可以说明标准，检查规则则能在违反标准时返回具体错误。一次不合适的修改被拦下来，Agent 就能在当前任务中修正。人的经验因此从“需要有人记住并提醒”，变成了“工作经过这里就会遇到的条件”。

这样的环境也帮助人类同事。Lauren 特别谈到新加入团队的工程师：清楚的约定能减少他们理解团队习惯的成本。团队的工作方法因此也更明确、更容易遵循。

多个 Agent 的难题，是怎样共享同一幅工作图景

当单个 Agent 能执行、观察并修正以后，仍有一类工作容易落回人身上：把新信息带给它。

一个任务开始时拿到的需求，只是当时的快照。用户继续报告问题，同事补充了限制，优先级也可能改变。如果这些信息留在 Slack、Linear、邮件或 X 上，Agent 可以很努力地完成一个已经过时的目标。人又会变成跨工具传话的人。

Lauren 所说的外循环与内循环，正是要连接这两边。外循环从外部工具获取持续变化的背景；内循环中的 Agent 使用这些背景推进代码工作。她使用 Grok Bot 的连接器收集相关信息，再把它送入 Cursor Projects。关键在于 Agent 能拿到实际信息，而不是在缺少背景时猜一个答案。

她举的例子，是让 Agent 订阅一个 Slack 频道，收到故障报告后先调查、复现。前面建好的验证技能在这里派上用场：检查问题是否仍存在于当前主分支，也要考虑用户的环境、数据或缺少依赖。收到消息只是开始；先判断问题是什么、是否需要改代码，才能决定如何处理。信息通道与验证工具连起来，才可能减少人既要转述反馈、又要替 Agent 判断反馈的双重负担。

信息到达之后，也不能机械地“一条报告派一个 Agent”。她和 Matt 讨论过一批相关性能问题的情况：报告略有不同，可能反而有助于看出共同原因。如果分开处理，每个 Agent 都可能只修眼前的症状，也可能重复同一项工作。

协调器的职责就在这里。它统筹任务、传递上下文、委派执行，让相关问题有机会一起被理解。Lauren 把这与自己在 Netflix 带团队的经验联系起来：提供背景，让执行者能作判断，才能减少逐步指挥。对于 Agent，这意味着既要告诉它目标，也要让它能找到作判断所需的信息。并行有价值的前提，是先弄清工作之间的关系。任务数量增加，不自动意味着有效产出增加。

代码巡检进一步说明了这一点。Lauren 有一个 Agent 持续寻找 React 中的不良模式，但发现后先追加到文档，而非立即全部修改。她隔几天查看累积的发现，就可能识别出同一类问题。一次改善共同的规则或设计，有时比逐个修补更有价值。

这给快速执行加上了一段必要的停顿：先保留发现，再观察模式。协调器与巡检记录都在帮助系统看见单项任务之外的关系，避免把“处理得很忙”误认成“解决得很好”。

把这些环节放在一起，人需要做的建设工作就更容易辨认：

这些能力不必一次全部建齐。表格的用途，是帮助你看清自己的注意力具体卡在哪个环节。Lauren 用“先建好一间厨房，再开更多餐厅”说明扩展的前提：先让一个项目里的工具、规范和验证足以承接工作，再把这种能力带到更多项目。多开几个 Agent 窗口，并不能代替这项建设。

人可以减少亲自执行，但仍要对整套工作负责

Lauren 说，她是从“怎样让 Agent 自己合并代码”这个问题倒推的。如果最终仍要由她逐项审查，交付规模就会卡在她能看多少代码上。前面那些验证工具、工程约束和上下文通道，都是为了让工作不必在每一步停下来等她。

在这套环境逐渐成熟以后，Lauren 描述了让 Agent 夜间自主工作、合并代码，自己第二天查看提交记录的方式。她也明确说，达到这个状态需要大量时间和精力，并非用了 pstack 就能轻松获得。

她的全自动模式会启动额外的验证 Agent，让它们运行应用、尝试用户操作、寻找回归和实现缺陷，再继续修复与检查。这样的验证消耗不少 token，验证 Agent 的数量也可以调整。节省人的逐项操作，需要付出工具维护与计算资源的成本。

与此同时，她仍会抽查代码。抽查的作用不只是发现一处问题，而是判断系统是否正在反复产生同一种坏做法。孤立问题可以局部修复；多个 Agent 都采取同一条不好的捷径，就需要回头检查技能、类型约束、代码规则或工具。

这让人的职责从处理眼前的每一步，延伸到改进以后所有任务经过的环境。一次人工判断如果只存在于聊天里，下次仍可能重来；如果它进入了合适的工具或规则，后续工作就能继续受益。

但放权仍然需要考虑后果。Matt 追问过容易回滚的“双向门”和可能造成数据损失的“单向门”。Lauren 将回答重点放在可验证性上：越容易通过程序检查的工作，越容易建立自主交付的信心；对于难以验证的领域，她没有给出通用答案。

可验证和可撤销需要分别判断。测试通过，说明被检查的条件满足了；它不会恢复已经丢失的数据。一个团队能放开多少自主权限，既取决于检查是否充分，也取决于判断出错以后会发生什么。访谈后面谈到形式化证明与面向 Agent 的语言探索，表达的也是对更强验证能力的期待，而非现有每项 PR 都已经获得数学证明。

这也是“米其林厨房”这个比喻真正有用的地方。主厨可以不亲自完成每一道工序，但仍要组织工作、准备工具、制定出品标准，并判断端出去的东西是否合格。少做一些操作，并不减少对最终结果的责任。

领域经验于是有了更多发挥的地方。知道用户真正要什么、什么实现值得保留、怎样的测试没有意义，都需要经验。模型越擅长实现，人越需要把这些判断表达清楚，放进它能够使用的工作环境。

访谈开头，Lauren 将瓶颈称为“意图的传递”：你脑中想要的产品，能否被清楚地表达出来。Matt 举了 TDD，也就是测试驱动开发的例子：先把预期行为写成测试，再完成实现。提到这种方法，会引导 Agent 优先考虑测试和预期行为，改变它安排工作的方式。专业经验的作用，在于知道要强调什么、排除什么，并能识别 Agent 有没有理解偏。若自己还说不清，两人也谈到让 Agent 通过追问帮助澄清想法。清晰目标可以在对话中形成，但判断“这就是我要的”仍需要人。

访谈最后，两人建议回看自己与 Agent 的历史对话。那些反复纠正、补充背景、重新说明步骤的记录，展示了工作实际怎么发生。Lauren 的 recall 技能就来自一个具体困扰：处理 Cursor 的虚拟化问题时，新对话需要承接旧对话中的背景。把这项过程做成技能，减少了每次重新写长篇说明的负担。

这种积累很个人化。Lauren 在发布这场访谈的原帖里，也建议将她与 Matt 的技能插件搭配使用，挑选适合自己工作流的部分。真正需要磨好的工具，是能承接你自己经验的那一套。Lauren 还观察到，随着模型更有能力，技能可以逐渐聚焦工作流，减少冗长的实现细节。技能要留下的是一项工作怎样推进、何时检查、接下来依据什么作判断；已经能由模型处理的细节，不必每次再写成长篇说明。对于希望改变工作方式的人，起点可以是最近一次不得不打断 Agent 的时刻：这次帮助，能否变成它下次自行获得的能力？

来源：Matt Pocock 与 Lauren Tan 完整访谈、Lauren 发布访谈的原帖。