从个人瓶颈到信任阶梯的起源
本次访谈的核心背景是嘉宾 Lauren Pocock（昵称 Potato）近期在 X 平台上发布的一场演讲，主题是如何将 2500 个 PR 上线至生产环境。这一话题引发了巨大反响，浏览量达到 300 万。访谈旨在深入探讨他如何构建与 AI Agent 的信任阶梯（Trust Ladder），即随着对 Agent 能力的信任加深，如何逐步扩大其使用规模。
Lauren 回顾道，这段经历始于离开 Meta React 团队后的一个月休整期。当时他因倦怠开启了一个业余项目，并尝试使用 AI 编写代码。然而，他发现自己在事无巨细地盯着 Agent上花费了过多时间，成为了效率的瓶颈。尽管当时（2024 年初）终端编排工具尚未普及，但他意识到需要解决“如何让 AI 编程环境更高效”的问题。这一探索促成了 PS Stack（Potato's Software Factory）的基础，并诞生了他开源的 potato/noodle 仓库。该仓库包含了他早期提炼出的 Skill（技能），其核心理念是将个人的专业能力和工作流程转化为 Agent 可执行的指令，从而让 Agent“像他一样”写代码。
“我意识到自己花了这么多时间，事无巨细地盯着一个 agent……我也在做 skill，但发现很难衡量产出。”
随后加入 Cursor 团队（现 SpaceX AI）后，Lauren 负责优化 Agent 窗口的性能。起初他依靠手动分析火焰图和堆快照，再次发现自己成为了人肉代理（Human-in-the-loop bottleneck）。他逐渐意识到，早期在个人项目中积累的关于验证（Verification）和严谨做事的经验至关重要。他观察到，即使是最先进的 Agent 也倾向于走捷径、选择容易而非正确的路径。因此，他的 Skill 设计核心在于：如何让“容易做的事”同时成为“正确且最好的做法”。这种将日常专业经验流程化的方法，成为了他后续构建软件工厂方法论的基石。
“我做的很多 skill 都围绕着一个问题：怎么让容易做的事儿就是正确的事儿？怎么让它也是最好的做法？”
领域专业性与语言精确性的新价值
针对“随着 AI 能力增强，人类专业知识是否变得无用”这一常见观点，Lauren 持相反意见。他认为领域专业知识比以往任何时候都更重要。随着模型（如 Opus 5.5）变得极其强大，瓶颈已从 Agent 的执行能力转移到了人类意图的表达清晰度。拥有深厚领域知识（如医生、律师或资深工程师）且具备一定技术好奇心的人，能够更清晰地构想并传达目标，从而利用 Agent 创造出卓越的产品。
Lauren 特别强调了对语言精确性（Linguistic Precision）的痴迷。他指出，自然语言与编程语言在 Agent 时代交汇于底层沟通逻辑。通过不断追问和精炼词汇，可以引导 Agent 理解深层意图。例如在测试驱动开发（TDD）的讨论中，重点不在于是否强制使用 TDD 框架，而在于让 Agent“思考”测试、编写测试并重新排列优先级。他特别推崇使用冗余（Redundancy）或消除重复等精确词汇，因为这些词压缩了丰富的意图和含义。Lauren 提到自己戏剧专业的背景让他对语言结构有着天然的敏感度，这种能力在指挥 Agent 时成为了关键杠杆。
“我觉得现在真正的瓶颈就是把你的意图和构想传达给 agent。”
他进一步解释，当 Agent 抓住某个关键词时，人类可以通过强化该词来引导思考过程。这种互动使得“不断追问”成为一种有效策略，因为它能迫使 Agent 将隐含的理解显性化，从而确认双方认知的一致性。这种对语言微观结构的掌控力，是驾驭复杂 Agent 系统的关键软技能。
“我发现测试驱动开发就是早期的一个例子……让 agent 去思考测试驱动开发，让他写测试，让他用跟以前不同的方式安排优先级。”
米其林厨房隐喻与验证作为核心基础设施
在讨论“软件工厂”这一热门概念时，Lauren 提出了米其林厨房（Michelin Kitchen）的替代比喻。他认为“工厂”一词容易让人联想到低品质或机械化，而“厨房”则关联着手艺、品质和用户体验。这个比喻生动地描绘了从单人烹饪到团队协作的演进：就像主厨（Lead Engineer）不再亲自切每一块食材，而是负责组织厨房、管理供应链和流程一样，工程师的角色从“写代码”转变为配置环境和管理 Agent 团队。主厨需要对最终菜品负责，正如工程师对代码库和 Skill 环境的质量负责。
Lauren 指出，许多开发者误以为 Agent 已经足够好，无需额外干预。但他强调，改变 Agent 的工作环境（Environment）是提升产出的关键手段之一。其中最重要的工具就是验证（Verification）Skill。他将验证比喻为给 Agent 装上“手和眼”，使其能够运行代码、模拟用户交互、调试并记录结果。这是 Lauren 加入 Cursor 后开发的第一个 Skill，也是他真正开始攀登信任阶梯的转折点。
“如果没有验证……agent 实际上看不到自己的工作结果，它就根本没法迭代。”
通过引入循环（Loop）概念——即 Agent 尝试改进并自我验证的过程，Lauren 实现了爬山优化（Hill Climbing）。例如在 Cursor Agent 窗口性能优化中，他利用验证 Skill 让 Agent 自动评估改进效果。如今，在 Cursor/SpaceX AI 内部，验证 Skill 已成为关键基础设施（Key Infrastructure），每个应用都配备自动维护的验证机制。这种从“人肉中间人”到“自主闭环迭代”的转变，是支撑其将 PR 数量扩大至数千级别的核心技术支柱。
“验证大概是 PS Stack 和很多其他工具集里最重要的技能。我觉得这是最值得花精力的事儿。”
验证技能与确定性工具：从上下文管理到代码封装
Andrej Karpathy 曾发布过一个名为 Auto Research 的项目，其中包含了类似的思路。在我看来，验证（Verification）大概是 PS Stack 以及许多其他工具集中最重要的技能之一，这也是我认为最值得投入精力去打磨的部分。我们内部现在拥有许多验证技能，例如 Cursor 或 SpaceX AI 的每个应用都配备了自动维护的验证机制。这已经成为团队的关键基础设施，因为所有人都依赖它。
你在这方面钻研得很深，甚至专门为此开发了一个命令行工具。这其实是我早期学到的一个窍门：去年年底或今年一月，社区特别关注上下文窗口（Context Window）的管理。当时大家讨论最多的就是如何高效利用有限的上下文，因为早期的摘要压缩效果不佳，甚至流传着一个梗：“只要 Agent 做过一次摘要或压缩，它在本次会话剩下的时间里就会变得有点傻”。
因此，我开发命令行工具的初衷是为了让上下文使用更高效。虽然现在的 Agent 和运行框架在生成摘要方面的能力有了巨大进步，但我依然认为保持上下文窗口干净是有好处的。这个命令行工具的核心作用是将技能中那些做法确定（Deterministic）的部分写成脚本，从而省掉原本不必要的判断。Agent 和技能的工作范围是一个连续谱：有些工作完全依赖非确定性（Non-deterministic）的判断，需要结合多条上下文信息进行推敲；而有些工作则是机械的、确定的操作（如代码重构），不需要 Agent 每次都重新思考新做法。
因此，技能在某种程度上像是一层封装。它包含简单的说明来指导如何使用内部的定制工具（如与 Playwright 或 Chrome DevTools Protocol 交互的 API）。虽然这些代码本身并不新颖，但它是一种隐藏信息、压缩体积的方式。通过让 Agent 调用现成的脚本而非每次从头编写，我们不仅节省了上下文和速度成本，还确保了操作的一致性。早期我注意到 Agent 每次验证工作时都会重新搭建所有组件且做法各异，这非常低效。现在，将确定性部分提取为代码，只把真正需要判断的部分留给 Agent，是高效利用确定性与非确定性边界的核心原则。
构建“厨房”环境：通过约束与类型系统缩小行动空间
将确定性工作从 Agent 手中拿走，并将其放入环境（Environment）中，是提升代码质量的关键。好的代码库定义很简单：容易修改且不会破坏其他部分。这意味着我们需要建立许多防护措施，限制 Agent 或人类只能在很窄的范围内操作。
这与我学习 TypeScript 的经历相通。TypeScript 中最迷人的特性之一是类型收窄（Narrowing）：从一个宽泛的类型开始，通过守卫和运行时检查缩小范围。这与在代码库中设置约束异曲同工——我们在限制可能存在的类型数量，从而让 Agent 准确知道正在处理什么。
我们内部开发了一个名为 Dune 的框架（类似 Electron 应用的 Next.js），它拥有极严格的 Lint 规则和约定模式。例如，每个功能都有独立的目录，通过注册表发现。这种设计营造了一个很难写出糟糕代码的环境。Agent 只需遵循“新功能放入新目录”的规则，而不必向一个包揽一切的大文件追加代码。这一灵感源于早期 Grokbot 版本中那些长达一万行以上的“大文件”，我通过观察 Agent 的错误，将每一个潜在问题转化为一条 Lint 规则或环境约束。
工程师的新工作就是花时间建设这个“厨房”环境。如果你不花时间为 Agent 建立信任、配置技能和工具，你就会卡在低信任度的状态：不得不事无巨细地盯着 Agent，就像拿着钝刀切菜或只用记事本写代码一样低效。通过建立环境（如严格的 Lint、类型约束），规则就存在于环境中，Agent 会在操作时自然遇到这些边界并被挡回。这样既减轻了 Agent 的记忆负担，也让你从微观管理中解放出来，去关注更高层面的效率问题。
规模化生产：连接内循环与外循环以消除瓶颈
如何从精心构建的环境扩展到每月 2000+ PR 的规模？前提依然是那个完善的“厨房”。一旦环境建立好，我不需要时刻待在那里。我将每个大型对话或项目比作一家餐厅：我有几家同时在运转，我在它们之间巡视，根据参与深度分配注意力。
然而，外部触发事件（如 Slack、Linear 或 X 上的 Bug 报告）往往无法直接触及我的“内循环”。内循环（Inner Loop）是 Agent 工程师根据我意图的快照进行开发的过程；但快照会过时，新的信息需要被引入。如果没有自动触发机制，我就必须充当中间人，手动收集外部上下文并传递给 Agent。
为了解决这个问题，我们需要自动化外循环（Outer Loop）。例如，通过 Slack MCP 或自定义框架订阅特定频道，当有人报告 Bug 时，Agent 自动进行初步排查、分类和复现。利用我们之前建立的验证技能和其他配置，Agent 能自信地确认 Bug 是否在主分支存在，排除用户环境或依赖问题。
建立这两个循环并将它们连接起来，是扩大工作规模的关键。核心主题始终是：在流程中识别瓶颈。为什么我的 Agent 需要我来回答这个问题？如果是因为缺乏外部上下文，那就通过工具将外循环接入内循环。这种自动化不仅让 Agent 能自我获取上下文，更让你从“人肉中间件”的角色中解脱出来，实现真正的规模化交付。
从控制到赋能：构建自主获取上下文的Agent循环
建立验证技能并配置好相关工具，让我对 Agent 能够独立定位 Bug、确认其在主分支上的存在性（而非用户环境或依赖问题）充满了信心。构建并连接这些自动化循环，尤其是思考“我在流程中哪个环节成了瓶颈”以及“如何让 Agent 通过真实数据而非幻觉自行获取信息”，是扩大工作规模的关键。这并非复杂的“公司大脑”概念，而是教会 Agent 自主获取原本需要我手动传递的上下文。正是这种机制让我能处理 2000 个 PR，就像开设连锁餐厅一样，通过协调 Agent（如 Cursor Projects）分派任务给子 Agent 执行，而非我亲自创建数千次对话。
在具体工具链上，我将 Grokbot 视为“外循环”，负责连接 Slack、邮件等外部服务以收集上下文；将 Cursor Projects 视为“内循环”，作为云端运行的协调 Agent（类似行政总厨或幕僚长）。当大量问题涌入时，协调 Agent 会智能分派任务。这种结构避免了为每个 Bug 单独启动 Agent 导致的重复劳动，而是让多个相关报告共同触发更高层面的问题洞察。正如管理理念中“提供上下文而非控制”的原则，良好的环境能让新人或 Agent 从第一天起就产出高质量代码。
“对我来说，就是 agent 需要一些信息，本来得由我亲自去传给他，那我怎么教会他自己去获取，对吧？这样就不需要我介入了。”
“有时候修 bug 拿到几份略有不同的 bug 报告会很有帮助。因为这能让你退后一步，看清真正的问题。”
质量管控：从全量审查到基于环境的抽样与约束
面对海量 PR，不可能像厨师品尝每一道菜那样进行全量审查。作为“工厂质量监督员”，核心策略是抽样检查与流程优化。我会定期查看 Agent 生成的代码，识别低效写法或共性错误。如果多个 Agent 重复犯同样的错（如套用同一种变通办法），这表明需要调整“厨房”或“工厂”的基础设施，例如优化技能约束、代码检查规则（Lint）和类型系统。通过迭代调整环境，使 Agent 默认就能做对，从而减少对人工干预的依赖。
此外，引入缓冲区机制至关重要。例如，我有一个 Agent 专门查找 React 中的不良写法，但不立即修复，而是将问题追加到文档队列中。这种“留白”迫使我或 Agent 从全局视角审视规律，避免陷入只处理眼前订单的局部执行状态。这种参谋长式的 Agent 既能执行任务，又能观察全局模式。
“如果你真的发现好几个 agent 都遇到了同样的问题……这就说明你该去想想怎么改进你的厨房或者你的工厂了，对吧？”
“有时候留个缓冲区会迫使你考虑全局……如果只是一回解决一个 bug，你可能就会漏掉这些规律。”
黑灯工厂模式：高强度验证下的自主合并
实现 2000+ PR 突破的核心在于让 Agent 能够自主合并代码。这并非“黑灯工厂”式的完全无人化（即忽略代码质量），而是一种高强度验证循环。在 PS Tech 的全自动模式下，每个 PR 会触发一批严格的验证 Agent，包括模糊测试（Fuzz Testing）——即模拟真人操作应用以发现潜在故障。Agent 会尝试修复发现的问题并重新验证，直到 PR 达到可合并状态。
这种模式虽然消耗大量 Token，但极大提升了效率。我现在可以在睡觉时让 Agent 工作（7x24小时），并在早上通过查看提交历史进行事后审查。如果发现严重问题，我会回退代码并添加新的防护规则。尽管初期担心夜间事故需要巨大勇气，但经过环境打磨后，这种“先合并、后审查”的模式已成为可能。对于高风险的“单向门”PR（如数据丢失风险），仍需依赖 Agent 极高的验证能力或人工介入，但对于大多数可回退的“双向门”PR，自动化合并是安全且高效的。
“我想应该说是验证加上环境，对吧？这两样结合起来，我才能放手离开，说 agent 们去把你们做的东西合并吧。”
“我现在睡的好多了……现在我睡觉的时候，我的 agent 已经能自己合并代码了。”
单向门与双向门的验证困境
在讨论自动化合并 PR（Pull Request）时，“抽查”而非“全量拦截”的思路至关重要。对于医疗、法律或金融等对安全极度敏感的行业，PR 的性质决定了风险等级：有些 PR 如同双向门，合并后若出问题可以低成本回退；而另一些则像单向门，一旦执行可能导致数据丢失或难以撤销的改动。面对大量“单向门”场景时，核心挑战在于 Agent 能否完成高置信度的验证。如果工作成果难以通过程序化手段进行形式化验证，自动化合并的难度将呈指数级上升。软件工程之所以能成为这一趋势的先行者，是因为其成果在很大程度上是可验证的（如编译通过、测试覆盖）。类似地，数学证明也是可验证的领域。目前行业正期待出现更多专为 Agent 设计的编程语言（如 Bend），这类语言将编程与形式化证明结合，利用求解器检查代码是否覆盖所有静态条件。一旦 Agent 能通过编译和形式化证明双重验证，直接合并 PR 在逻辑上是成立的。
Skill、PS Stack 与个人工作流的融合
关于 Skill（技能）与 PS Tech/Stack 的关系，两者本质上是互补的。Skill 本质上是用 Markdown 或自然语言编写的流程描述，而 PS Stack 提供了执行框架。建议开发者通过回顾历史对话记录（Chat History）来提炼 Skill：分析自己在哪些环节频繁纠正 Agent、介入过多，将这些隐性经验转化为显性的 Lint 规则或新 Skill。这就像厨师带着自己的刀换工作一样，信任源于对自己工具的熟悉与打磨。随着模型能力的提升，Skill 正在从包含具体脚本命令的“实现细节”演变为更精简、抽象的工作流程步骤。Lauren 开发的 Recall Skill 就是一个典型案例，它解决了跨会话上下文丢失的问题，将“回顾历史对话”这一繁琐动作浓缩为单一指令。Skill 的优势在于其透明性和易改性，用户可以根据信任度自由组合不同来源的 Skill（如 Wayfinder 与 Potato 模式），构建个性化的自动化工作流。