把智能体当同事：验证、架构与自动合并PR的工程实践

当工程师开始让智能体自动合并PR，甚至一觉醒来发现20个PR已经进入主分支，这背后不是盲目的信任，而是一套精心设计的验证与约束体系。在Growth Bar的实践中，一位五个月内提交上千PR的工程师分享了从「微观管理」到「工程经理」的转变路径。

信任曲线：从盯着每一个输出到放手并行

刚开始使用智能体写代码时，大多数工程师会陷入一个紧密的循环：输入提示词、盯着每一条输出、检查代码、发现问题、再反馈。这种模式让人无法并行处理任务，因为你始终是验证瓶颈。

讲者用一张手绘图描述了这种心态变化：最初只敢绑定一个或少数几个智能体，每件事都要亲自确认；随着对智能体信任的建立，才逐渐敢于同时启动更多任务。过去五个月，他的信任曲线稳步上升，如今已经允许智能体自动合并拉取请求。当天早晨醒来时，已有20个PR合入主分支，且质量确实不错。

这种转变的核心类比是工程管理：如果你不信任团队成员，就会变成微观管理者，站在每个人背后反复检查。而当你建立起信任，才能像工程经理一样设计环境、分配任务，而不是亲手完成每一行代码。

验证技能：让智能体真正运行自己的代码

建立信任最关键的一步是「验证」。智能体不能只写出代码就宣布完成，它必须有能力把应用跑起来——采集性能跟踪、获取内存快照、打开模拟器，亲自确认功能是否正常。这不能保证代码优雅，但至少能保证功能正确。

以内部代号为Glass的智能体窗口为例，讲者入职第一周就面临发布压力，当时只能自己打开Chrome开发者工具采集火焰图，而智能体同样一头雾水，自信地指出错误位置却往往不准。于是他把控制Chrome开发者工具协议、启动应用、采集性能数据的能力封装成技能，让智能体可以自主操作。

但光有操作能力还不够。应用启动后，智能体不知道该点哪里、如何进入特定功能，只能到处乱找。为此他引入了「功能地图」——一份明确记录每项功能入口、键盘快捷键、DOM元素属性的文件。当用户报告含糊到只丢一张截图加三个问号时，智能体也能借助地图理解上下文，而不是回答「我完全不知道」。

这套能力后来被整理成pstack插件（名字是对Gary Tan的gstack的玩笑式致敬），其中包含创建验证技能的工具，可以自动探索代码生成功能地图，并在应用变化时持续维护。

Chrome 开发者工具协议（CDP） 是一套基于 WebSocket 的远程调试接口，允许外部程序以编程方式控制 Chrome 浏览器：打开页面、执行 JavaScript、捕获网络请求、采集性能跟踪（Performance Trace）和内存快照（Heap Snapshot）等。对于智能体而言，CDP 相当于一双可以操作浏览器的“手”——它不必依赖人类手动打开 DevTools 采集火焰图，而是可以直接调用协议命令启动应用、录制性能数据、定位卡顿函数。将 CDP 封装为技能后，智能体就具备了闭环验证能力：写代码、跑应用、采数据、判断功能是否正常，从而摆脱“只写不验”的盲区。

评估手册：给技能做单元测试

技能写好后并非一劳永逸。讲者强调，维护技能需要持续的判断和品味，就像结对编程时坐在同事旁边不断提出改进意见。

他采用的方法叫「评估」，本质是给技能做单元测试。具体做法是：启动多个子智能体，主协调智能体先制定评分标准，子智能体在独立目录中执行任务——目录命名会刻意避免让子智能体察觉自己正在被评估，因为智能体一旦发现被测试就会改变行为。pstack支持多种模型，可以把同一个技能放到不同模型上形成对照，尤其关注日常真正使用的模型组合。

评估的迭代性很强：可以让协调智能体评分，再引入不同模型的裁判智能体交叉检查，避免单一模型偏见；还可以使用循环命令反复运行，直到所有项目拿到满分。

子智能体（Sub-agent） 是指由一个主协调智能体派生出来、在独立上下文中执行特定任务的智能体实例。它们各自拥有独立的对话历史和工作目录，互不干扰，因此可以并行执行多个测试用例而不会互相污染上下文。在评估场景中，主协调智能体负责制定评分标准、分配任务和汇总结果，子智能体则像被测试的“考生”一样在隔离环境中完成任务。这种架构既提高了评估的并行效率，也避免了单个智能体在长对话中遗忘早期指令的问题，是多智能体系统常见的任务分解模式。

架构约束：让最快的路径成为最好的路径

当智能体可以自动合并PR时，代码库的质量靠什么保障？讲者的答案是分层约束体系。

第一层是代码库本身的结构：功能入口点、对话记录卡片等概念都有明确命名和固定创建方式，一个功能完整放在同一个目录里。智能体特别喜欢复制现有模式，因此清晰的惯例是最强的约束。第二层是静态分析和持续集成检查，把规则变成硬性失败——比如在Growth Bar的架构中直接禁止使用useEffect，甚至禁止写代码注释，因为智能体写的注释99%在讲与当前代码无关的历史。

讲者特别看中一个原则：最短的路径应该同时也是最好的路径。智能体天生寻找捷径，那就把最快的路设计成最好的路。

再往后才是规则文档、技能和bugable等软约束。他警告说，如果只靠软约束，代码库迟早会乱，这只是时间问题。技术栈选择因此变得重要——Rust的严格编译器和借用检查器就是硬约束的例子。

useEffect 是 React 中用于处理副作用的钩子函数，常在组件挂载或依赖变化时执行数据请求、订阅事件或操作 DOM。它功能灵活，但也容易导致竞态条件、重复请求、内存泄漏和难以追踪的渲染循环，尤其当智能体大量生成代码时，滥用 useEffect 会迅速累积技术债。Growth Bar 在架构层面直接禁止使用 useEffect，实质上是把“不要用这个钩子”从代码规范提升为编译/检查阶段的硬性失败，迫使开发者（和智能体）采用更可预测的数据流方案，例如在路由层或状态管理器中集中处理副作用。

成本与协作：投入产出比才是关键

对于「普通额度用户能否复制这套做法」的疑问，讲者承认自己在AI实验室工作、token几乎不限量，但他认为这首先是投入产出问题。前期在token上投入重构代码库、搭建约束，换来的是整个团队的效率提升——设计师和产品经理也能提交高质量代码，甚至直接修复问题后请工程师审查。

他用Growbot举例：这个新应用让非技术同事迎来了属于自己的「Cruiser时刻」，界面像iMessage一样自然，每个人可以协调多个有独立身份的智能体。产品经理已经习惯让智能体总结工程师昨晚完成的工作，也能直接交付功能。

代价并非不存在。为了把Growth Bar重构到新架构，他做了600多个PR；但正因为这些前期投入，现在他几乎不再逐行读代码，CI会严格把关，半夜也不必担心有人合入性能倒退的改动。

从验证开始，到本地建立信任，再扩展到云端智能体自动接单，最后才允许自动合并——这条路径没有捷径，因为它取决于每个工程师自己的信任程度和工程质量标准。

Rust 的借用检查器（Borrow Checker） 是 Rust 编译器的一部分，在编译期静态验证引用的生命周期与所有权规则，确保不会出现悬垂指针、数据竞争或释放后使用等内存安全问题。对智能体而言，这意味着许多在 JavaScript/Python 中能悄悄通过的逻辑错误，在 Rust 中会直接导致编译失败，智能体必须修正后才能继续。这种“硬约束”把代码质量保障从人工审查前移到了编译阶段，减少了 CI 之后才发现的深层缺陷。技术栈选择因此不只是性能偏好，也是约束智能体行为、降低验证成本的手段。