月产2500个PR：AI智能体的「信任阶梯」与米其林厨房式工程

当一位工程师宣称自己上个月向生产环境提交了 2500 个 PR，并在 X 上收获约 300 万次观看时，大多数人的第一反应是难以置信。这正是前 Meta React 团队、现任职于 Cursor（SpaceX AI）的工程师 Potato（推特昵称）在一场对谈中抛出的数字。他与另一位同样以「技能库」著称的开发者 Matt 的交流，系统拆解了 AI 智能体规模化工程背后的方法论——信任阶梯、验证循环、确定性与非确定性的划分，以及一套被他称为「米其林厨房」的思维模型。

从「人肉代理」到信任阶梯

Potato 的起点并不光鲜。离开 Meta 后，他在倦怠期做副项目，却发现自己把大量时间花在「微管理」单个智能体上。他把当时的自己形容为「meat proxy」（人肉代理）——夹在智能体和 Chrome DevTools 之间手动搬运信息。加入 Cursor 后负责优化 agent 窗口性能时，这种挫败感再次出现：他盯着火焰图和堆快照手动排查，仍然是整个流程的瓶颈。

所谓「信任阶梯」，指的是随着你对智能体的信任逐步提升，可以交给它越来越复杂的任务，也能并行调度越来越多的智能体。而攀登这个阶梯的关键第一步，是让智能体拥有「手和眼睛」——即验证能力。Potato 强调，他在 Cursor 搭建的第一个技能就是验证技能，正是它第一次真正把他从循环中解放出来。

值得一提的是，Potato 对「领域专长正在贬值」的流行观点持相反看法。在他看来，当模型越来越强（他特别提到喜欢 Opus 5.5），瓶颈不再是智能体本身，而是人类清晰表达意图的能力。拥有深厚领域知识又略懂技术的人，反而拥有巨大优势。

为什么是「米其林厨房」而非「软件工厂」

「软件工厂」是当下的热词，但 Potato 对这个比喻有所保留。工厂容易让人联想到标准化、缺乏质量与匠心，而这恰恰是技术人最在意的东西。他更偏爱「米其林厨房」这个更具抱负感的隐喻——既契合他「土豆」的饮食人设，也更精准。

这个比喻巧妙映射了信任阶梯。一名家庭厨师独自备菜、切菜、烹饪、清洗，是名副其实的「单人秀」。一旦厨房里挤进全家人，多数人会立刻陷入混乱——这正是从单智能体走向多智能体时的典型困境。而一名真正的主厨，不再亲自烹饪每道菜，而是像厨房的 CEO 或 tech lead，思考何时采购食材、如何储存、如何分工，让整体产出大于各部分之和。

对应到工程实践：工程师不再亲手写代码，而是对最终结果负责——你的名字、你的声誉仍与产出绑定。因此，如何设置你的「厨房」（技能、环境、代码库）就成了新的核心能力。

验证循环：最重要的那把刀

「即便你不用 pstack 或我的技能，验证也是工具箱里最重要的一项。」Potato 反复强调这一点。没有验证，智能体就无法看到自己工作的结果，也就无法真正迭代。所谓「agent loop」（智能体循环）之所以能成为循环，核心正是验证环节。

他举了「hill climbing」（爬山式优化）的例子：当你拥有某种评分标准或 rubric，再配合一个循环，智能体就能持续尝试改进并自我打分。这与 Andrej Karpathy 发布的 auto research 理念一脉相承。如今 Cursor 内部每个应用都配有自动维护的验证技能。

在验证的基础上，Potato 还构建了自定义 CLI。这个 CLI 的本质，是把技能中「确定性」的部分从智能体的判断中剥离出来，编码成脚本。他的核心原则是：把工作想象成一个判断力的梯度——需要思考、整合多源上下文的部分交给智能体；而机械、确定的部分（如代码模式重构、AST 遍历、code mod 迁移）则用脚本完成。CLI 像是一个带轻量说明的「包装器」，既节省上下文窗口，也让每个智能体复用同一套经过验证的能力，避免「每次都重建世界」的浪费。

「Hill climbing」（爬山算法）是一种启发式搜索优化策略：从当前状态出发，每次只向能改善评分的方向移动一步，直到找不到更优解为止。它不保证找到全局最优，但在有明确评分函数的场景下效率极高。应用到智能体工程中，其含义是：只要你能定义一个可量化的「好坏」标准（rubric），智能体就可以在每次迭代后自我评分，选择得分更高的版本继续改进，无需人类在每个步骤介入。这与传统软件测试的逻辑高度一致——单元测试本质上就是一个二元评分函数。Potato 所说的「验证技能」，正是为智能体提供这个评分函数的基础设施。没有它，智能体只能盲目输出，无法形成真正意义上的「循环」，也无法在人类离开后继续自主迭代。Code mod（代码模式迁移）工具如 jscodeshift，则是另一个关键配件：它通过 AST（抽象语法树）遍历对代码库进行大规模确定性变换，适合执行重命名、API 迁移等机械操作，不需要模型推理，直接用脚本完成更快更可靠。

环境即新代码：把错误变成约束

Potato 认为工程师的新职责，是把时间花在「环境」上。如果你不愿投入时间搭建信任与工具，就只能停留在信任阶梯底端，靠微管理勉强应付——就像一个只会用记事本、没听过 Git 的开发者，始终在用钝刀干活。

他的做法是：像鹰一样盯着智能体，每当发现它犯错或走捷径，就思考「如何把这变成一条 lint 规则？如何让代码库从结构上杜绝这个问题？」这与他深厚的 TypeScript 背景相通——类型收窄（type narrowing）的本质就是约束可能性空间，让你精确知道自己在处理什么。

他为团队的 Electron 应用构建了内部框架 Dune，带有大量严格的 lint 规则，使得「做一件事只有一种正确方式」。每个功能进入独立目录，由注册表自动发现。这套设计的灵感恰恰来自早期 Grokbot 那几个上万行的「上帝文件」——通过观察智能体如何失败，再逐步把经验沉淀为结构性约束。好的代码库，就是易于安全修改的代码库。

TypeScript 的「类型收窄」（type narrowing）是一种通过条件检查让编译器在特定代码分支中获得更精确类型信息的技术。例如，一个变量可能是 string | null，在经过 if (x !== null) 检查后，编译器知道该分支内 x 必然是 string，从而消除了一整类运行时错误的可能性。Potato 将这一思想迁移到智能体工程：通过 lint 规则、严格的目录结构和框架约束，把「智能体可能犯错的空间」从结构上压缩。这与类型系统的哲学一致——与其在运行时（或 PR review 时）发现问题，不如在编写时就让错误在语法层面无法表达。他所说的 Dune 框架中「做一件事只有一种正确方式」，正是将这种约束密度最大化：智能体在受限的代码库中，错误选择的数量大幅减少，正确行为的路径被刻意设计得比错误路径「阻力更小」。这种设计思路有时被称为「pit of success」——让正确做法成为默认，错误做法需要主动违反约束才能发生。

内外双循环：2500 个 PR 从何而来

真正解释 2500 这个数字的，是 Potato 对「内循环」与「外循环」的区分。内循环是智能体工程师们围绕某个意图快照写代码；但意图会过期——新的 bug 报告、功能请求散落在 Slack、Linear、X 等外部系统中。过去他要亲自把这些上下文搬运给智能体。

如今他用 Grokbot 这类「连接器」工具自动化外循环：它们订阅邮件、日历、Slack、Linear 等渠道，持续监听。而内循环则交给 Cursor 的新功能 Projects——一个云端的协调者智能体（coordinator agent），类似「参谋长」或「行政主厨」，自己不干活，只负责拆解、委派、调度子智能体。当一批相关 issue（比如一组性能问题）涌入时，协调者会识别关联、规避重复劳动，并以更优的拓扑结构分发任务。

他还提到一个反直觉的技巧：不要让智能体立刻修复发现的问题，而是先追加到一份文档里形成「缓冲队列」，过几天再回看。这个缓冲迫使你看见「森林」而非只盯着每棵「树」——多个相似 bug 放在一起，往往能揭示真正的根因。所谓 2500 个 PR，并非 2500 个功能，很大一部分是他称为「gardening」（园艺式打理）的持续维护工作。

「协调者智能体」（coordinator agent）的架构模式，在多智能体系统领域也被称为 Orchestrator-Worker 模式。协调者本身不执行具体任务，只负责理解高层意图、将其拆解为子任务、分配给具备对应能力的工作智能体，并汇总结果。这种分层设计解决了单一智能体上下文窗口有限、难以同时处理大型任务的问题。Cursor 的 Projects 功能将这一架构落地为产品：云端协调者持续运行，可以跨越人类睡眠时间异步调度多个子智能体并行工作。外循环的自动化则解决了另一个关键问题——「意图的保鲜期」。软件工程中，需求从来不是静态的，bug 报告、用户反馈、性能告警持续产生。如果工程师需要手动将这些信息搬运给智能体，他就成了系统的瓶颈，多智能体的并行优势荡然无存。Grokbot 这类连接器工具本质上是一个「上下文摄取层」，自动将分散在多个 SaaS 工具中的信息结构化后注入内循环，从而实现真正意义上的持续自治。

评审、黑灯工厂与一次性的门

「你真的尝过这 2500 道菜吗？」面对必然的质疑，Potato 的答案是：采样，而非逐一检查。就像工厂的质检员无法检查每一件产品，他每天抽查 PR，严格审视代码质量，发现多个智能体重复同一种错误时，就去修正「环境」而非单个智能体。

当环境足够约束、验证足够可信，他甚至实现了智能体在他睡觉时自行合并代码——某种意义上的「黑灯工厂」。他坦言第一次开启时非常害怕「会不会搞出线上事故」，但如今他有十余个「参谋长」各自负责不同领域（性能、桌面应用性能、用户 bug、乃至用另一种语言重写的实验玩具），24 小时运转。他只在早晨通过提交历史复查，发现问题就回滚、修改或新增 lint 规则。

不过他明确区分了自己与 Karpathy「vibe coding」的理念：后者近乎忘记代码存在，而他的方法恰恰相反——代码与环境是一切的根基，garbage in garbage out。他也诚实承认局限：这套打法依赖「领域的可验证性」。软件工程在很多情况下可验证，数学的部分证明也可以（他提到了融合编程与证明的语言 Bend），但对于金融、医疗、法律中那些「单向门」式、一旦出错难以回退的操作，目前仍没有好答案。

技能即流程：打造属于自己的刀

关于 pstack 与 Matt 技能库的「路线之争」，两人达成了共识：技能本质上就是流程的语言化，「说到底就是 Markdown，就是英语」。没有魔法，如果有，魔法就在于措辞的选择、以及把抽象流程提炼为语言所做的思考。

Potato 给出的实操建议是：去挖掘自己过去的对话记录（transcript）。那些你反复纠正智能体、不断介入的地方，正是「流程的实体化」——不是脑中的抽象想法，而是真实发生过的过程。把这些高频干预提炼成可复用的技能或 lint 规则，智能体就不会重犯。他在 pstack 中的 recall 技能正是如此诞生：把「翻看历史对话、迁移上下文」这一工作流压缩成一个技能。

他预测，随着模型变强，技能会越来越小、越来越聚焦于工作流本身，而非具体的脚本命令细节。每位厨师都该拥有自己的刀——信任源于对工具的深度理解与打磨。无论用谁的技能，最终都该结合自己的历史记录，锻造出专属的流程。