一个月上线2500个PR：pstack作者的AI软件工厂方法论

Matt Pocock 与 pstack 作者 poteto（grokbot、Cursor 开发者）的这场深度对谈，围绕一个让人瞠目的数字展开——上个月，poteto 向生产环境推送了约 2500 个 PR，相关帖子在 X 上收获了近 300 万浏览量。但这期对话真正的价值不在数字，而在于拆解背后那套可以复制的工作方法：如何沿着与智能体之间的"信任阶梯"一步步往上爬，如何用验证、环境和确定性把人从流程里剥离出来。

信任阶梯：从人肉中介到放手合并

poteto 的故事要从离开 Meta 后说起。当时他请了一个月假，顺手开了个副业项目，自然用 AI 来写代码。但很快他发现自己花了好几个小时在微观管理一个智能体——写技能文件、盲目摸索输出效果。这段经历后来成了 pstack 的雏形。

加入 Cursor 后做智能体窗口的性能优化时，同样的瓶颈再次出现：他成了"人肉代理"，在智能体和 Chrome 开发者工具之间手动充当中介，抓 trace、拍快照、把结果再喂回去。"我才是那个瓶颈"，这个反复出现的觉悟，是整套方法论的起点。

信任阶梯的核心逻辑是：你越信任智能体，就越能让它做更复杂的事，或者扩展到更大的规模。而想往上爬，关键不是等模型变强，而是改造智能体运行的环境。poteto 特别强调一个常被忽视的立场——你改不动 Claude Code 的内部，但你完全可以改变代码库、给智能体验证工具、让它自己校验工作。

验证：工具箱里唯一最重要的技能

如果只能保留一个技能，poteto 的答案是"验证"（verification）。他用一个很形象的比喻：验证就是给智能体装上一双手和一双眼睛，让它能像真人用户那样运行代码、交互、调试、抓 trace、拍快照。

没有验证，所谓的"循环"（loop）就不成立。"一个循环之所以能成为循环，最重要的部分就是验证，因为智能体能验证自己的工作，这样就把你从等式里拿掉了。"这也是他加入 Cursor 后搭建的第一个技能，正是它让他在信任阶梯上往前迈了关键一步。

如今 Cursor 和 SpaceX AI 旗下每款应用都带有一个自动维护的 Verification 技能，已成为团队的关键基础设施。他甚至借鉴了实验室常提的 Hill Climbing（爬山法）思路——建立一套评分标准，让智能体持续迭代改进。

Hill Climbing（爬山法）源自优化领域的经典启发式算法：从当前状态出发，每次只向"评分更高"的相邻状态移动，直到找不到更优解为止。在机器学习评估体系中，这个概念被扩展为"持续以可量化指标驱动迭代"的工作范式——不追求一步到位的最优解，而是通过密集的小循环不断逼近目标。poteto 将其迁移到智能体工程的含义是：为每个验证技能制定可打分的评估标准（例如渲染帧率、交互响应时间、断言通过率），让智能体在每次修改后自动评分，并只保留分数提升的变更。这种做法的关键优势在于把"好不好"从主观判断变成可程序化比较的数值，从而让智能体在无人监督的情况下也能沿着正确方向爬升。

确定性与非确定性的梯度

poteto 把智能体和技能看成一种梯度：有些工作完全依赖判断（需要拼接多段上下文去思考），有些则高度机械（比如把代码从一种模式重构到另一种）。

他为验证技能专门做了定制 CLI，灵感来自早期对上下文窗口的焦虑——与其让每个智能体都重新造一遍轮子、自己写脚本去验证，不如把确定性的部分提取成脚本或 CLI 放进技能里。这样既节省上下文，又提升速度和一致性。

"技能就像一层封装，外层带一些轻量指令，说明如何使用内置的自定义工具。"这种做法本质上是在压缩信息、藏起复杂度，让智能体更稳定地做一致的事。做技术栈迁移时也是同理，Codemod、AST（抽象语法树）这类确定性手段能替代智能体完成机械转换。

Codemod 是一类用于批量自动化重构源代码的工具，Facebook 最初为大规模迁移 React API 而开发并开源。它的工作原理是将源代码解析为 AST（抽象语法树，Abstract Syntax Tree）——一种将代码结构表示为树形节点的中间表示——然后对节点进行模式匹配与替换，最后重新生成代码文本。与直接用正则表达式替换字符串相比，基于 AST 的转换能理解代码的语法结构，因此可以精确处理嵌套、作用域、运算符优先级等复杂情况，几乎不会引入破坏性改动。在技术栈迁移场景下，Codemod 可以在数秒内完成数千个文件的机械性改写，而不需要大语言模型参与任何推理——这正是 poteto 所说"用确定性手段替代智能体完成机械转换"的典型实践。

米其林厨房而非软件工厂

poteto 不太喜欢"软件工厂"这个说法——它容易让人联想到流水线，而忽略品质和工艺。他更愿意用"米其林厨房"来比喻：从家庭厨师独挑大梁（自己切菜、备菜、收拾），到成为主厨带领一支团队，核心不是为了分工而分工，而是让整体"大于部分之和"。

主厨几乎就像技术负责人——不一定亲手做每道菜，但要组织整个厨房，考虑食材采购、储存、备料的时机。映射到工程上，就是你不再自己写代码，但你的名字、你的声誉仍与最终产出绑定。所以你如何布置厨房、搭建技能和环境，就成了构建产品的新原料。

这个比喻也呼应了他对环境的执着：好的代码库是容易做改动且不出问题的代码库，意味着大量护栏把智能体和人都约束在很窄的正确路径上。

把错误固化进环境

poteto 认为工程师新的工作就是"把时间花在环境上"。他构建了一个内部框架 Deon（类似 Electron 应用里的内部 Next.js），带有极其严格的 Lint 规则和约定俗成的目录结构——做某件事"实际上只有一种方法"。

这套思路与他的 TypeScript 背景一脉相承。他最喜欢 TypeScript 的类型收窄：从宽泛的类型出发，通过类型守卫和运行时检查缩小空间。约束代码库的本质也是如此——限制可能出现的状态，让写出烂代码变得困难。

关键动作是观察智能体如何失败。每次看到它出错，就退一步想：怎么把这个变成一条 Lint 规则？怎么让代码库从根本上杜绝这种情况？Grokbot 最初版本由 8 个上万行的巨型文件组成，正是这种观察推动他拆成了可被注册表发现的功能目录。这样一来，环境既释放了人的脑力，也让智能体"只会觉得只有一种做法"。

内循环、外循环与幕僚长智能体

2500 个 PR 的真正秘密，在于打通"内循环"和"外循环"。内循环是他的智能体工程师在代码上朝着意图工作；外循环则是散落在 Slack、Linear、X 上的 bug 报告和需求。过去 poteto 得自己当中间人，手动把外部上下文转交给智能体。

像 Grokbot 这样的连接器工具（连接邮箱、日历、Slack 等）负责自动化外循环。他借用在 Netflix 学到的管理理念"给背景不给控制"——不事无巨细地管，而是训练智能体自给自足。

具体运转是：多个 Grokbot 持续订阅各频道，发现 bug 就自动在 Cursor 的新功能 Projects 里创建任务。Projects 本质是云端的协调智能体（他称之为"幕僚长"或"行政主厨"），自己不干活，而是派生、编排、管理子智能体。当 30 个相关问题同时涌来，协调智能体会一次性接收载荷、生成最优的智能体拓扑结构，避免多个智能体重复劳动——有时多份略有不同的 bug 报告反而帮助从更高层面看清全局。

他还分享了一个日常技巧：让一个智能体持续监控代码中的不良模式，但不立即修复，而是追加到文档形成"缓冲区"，隔几天回看，往往会发现它们其实是同一个问题。

"给背景不给控制"（Context, not control）是 Reed Hastings 在 Netflix 管理文化手册《不拘一格》中提炼的核心原则：管理者的职责是向团队充分传递战略背景、目标与约束，而非通过审批和微观指令来控制执行过程，从而让高密度人才在信息充分的前提下自主决策。poteto 将这一原则平移到智能体管理上：与其为每个任务手动撰写详细步骤，不如投资于技能文件、代码库约束和验证工具——这些基础设施本身就是"背景"的载体。智能体读取这些上下文后，能在没有人类实时介入的情况下做出符合预期的决策。这也解释了为什么他把环境搭建而非单次提示工程视为核心杠杆：背景一旦固化进系统，就能被每一个派生的子智能体自动继承。

评审、黑灯工厂与可验证性边界

2500 个 PR 显然无法逐一审查。poteto 的做法是抽样——像工厂的质量主管，每天看一看 PR 质量和智能体重复的坏模式。一旦发现多个智能体犯同样的错，就不是改那一个智能体，而是退出来改造环境（skills、约束、Lint、类型系统）。

当环境约束足够充分，他已经能做到让智能体"自行合并自己的 PR"。pstack 里的 Full Autopilot 模式会为每个 PR 派出一批验证智能体做模糊测试（fuzz testing）：真正运行应用、像真人一样点击、找回归和 bug，再自行修复到可合并状态。"验证加上环境，这两者合在一起让我可以走开。"

不过他对"黑灯工厂"保持清醒。这不是 Vibe Coding 式的忘掉代码——恰恰相反，"代码和环境都是必须的，垃圾进垃圾出"。更贴切的说法还是餐厅：即便开了连锁，老板还是会时不时回店里尝尝菜。

面对医疗、法律、金融等高风险场景和"单向门"（不可逆操作）的提问，poteto 坦言没有标准答案，但核心仍回到可验证性：如果工作能被程序化地高质量验证，单向门某种意义上就变成了双向门。他看好未来会出现更多面向智能体、将编程与证明结合的语言（他提到了 Bend）。

模糊测试（Fuzz Testing）是一种通过向程序输入大量随机或半随机数据来发现意外行为、崩溃和安全漏洞的自动化测试技术，最早由威斯康星大学 Barton Miller 教授在 1988 年系统化提出。传统 Fuzz 工具关注的是输入边界（如畸形文件、超长字符串），而 poteto 在 pstack 中将这一思路扩展到 UI 交互层面：派出验证智能体像真实用户一样在界面上随机点击、填写表单、触发边缘操作，而非仅仅运行预定义的测试用例。这种方式能发现仅凭静态分析或单元测试难以捕获的回归问题，尤其适合 UI 层和状态管理逻辑复杂的前端应用。与传统 Fuzz 不同的是，这里的"模糊"来自智能体对"真实用户行为"的泛化模拟，而非纯粹的随机字节流，因此在发现真实场景下的可用性问题上往往比传统工具更有针对性。

技能即流程：从对话记录里挖宝

谈到 pstack 与 Matt 的技能框架如何结合，两人的共识是：技能本质上就是把流程变成书面文字，"说到底就是 Markdown 而已"。

poteto 建议每个人翻查自己的对话记录——那是"宝藏般的上下文库"，是流程的具象化。让智能体看看你用过的所有模式、你不得不介入纠正的时刻，把这些高层经验提炼成 Lint 规则或可复用技能。他在 pstack 里做的 Recall 技能正是干这件事：把"回看过往记录"的流程压缩成一个技能。

随着模型变强，技能会越来越小、越来越聚焦于工作流本身，而非具体的脚本和命令。"如果说里面有什么魔法，就是所选的词和所用的短语"——这也呼应了 poteto 对语言的痴迷：自然语言与编程语言在智能体时代汇合，本质上都是交流。