让 AI 代理值得信任：验证、硬性约束与惯例式架构
一句话要点：要放心让 AI 代理写程序，必须先让它能实际验证自己的成果，再用 CI、lint 等硬性约束与惯例式架构取代人工审查，信任才能逐步累积到让代理自动合并 PR。
关键观点
- 信任是整场分享的主轴：信任不足时只能紧盯少数代理、无法平行化，也不该一下子启动大量云端代理，否则只是浪费 token；她花 5 个月爬上信任曲线，才做到代理自动合并、醒来已有 20 个 PR 进主线。
- 验证是信任的起点：没有验证技能时人就是瓶颈，所以先教代理实际操作应用程序（control glass 技能与功能地图），再用 eval 当作技能的单元测试持续改进，之后才扩展到云端的 Benny 自动重现错误回报。
- 工程师的角色像主厨：不再亲手做每道菜，而是设计环境、分派工作；起点是本机，因为能看着代理如何操作，信任创建后才放大到云端与自动合并。
- 约束要能硬性运行才可靠：Dune 禁用 useEffect 与代码注解、以 CI 检查 main 与 renderer 的导入边界，并以「最短路径就是最佳路径」的惯例式架构引导代理；rules、skills 与 bugbot 只是软性补充，每次靠人工审查才发现的问题都该转成 lint 或 CI 规则。
- token 花费是投资报酬率问题：前期重构（超过 600 个 PR）花很多 token，但换来最笨的代理也能做好，连 PM、设计师都能安全贡献；不过她任职的实验室 token 不受限，不能要求每个人照做。
分段摘要
0:25AI 压力与规格优先的第一次实验
她认为 AI 最好的用法是当成一起写程序的伙伴，而不是取代写程序或外包思考。许多任务程师因为想被看成善用 AI，承受每周要交 100 个 PR 的压力；她自己的经验是，用 AI 虽然省下写程序的时间，却花更多时间审查与修正。她也试过先让 AI 写规格、审过规格再开发的流行做法。
▶ 从这里看1:25信任、长期累积的看法与曲线
主轴是信任：资深工程师累积了许多看法，看到代理乱猜、产生幻觉，还信誓旦旦说找到问题根源，信任就会流失，而信任不足就无法发挥代理的价值，如同不信任下属的经理只能微管理。回到约 1 年前还没什么人用代理写程序的时候，只能紧盯少数几个代理、无法平行化；过去 5 个月爬上信任曲线，现在代理会自动合并 PR，醒来就有 20 个 PR 已进主线且品质不错。她的贡献图与这条曲线相互对应：第 1 个月产出低，上个月合并的 PR 数量相当惊人，本月 12 日前已近 800 个。
▶ 从这里看
5:55验证是最重要的能力
在代理工作流程中，她认为最重要的技能是验证：代理要能真的运行代码、抓 CPU trace 或 heap snapshot、开 iOS 模拟器，像用户那样实际操作并测试。这能让循环闭合；虽然不保证写出好代码，至少能写出正确的代码，是创建信任的一大步。
▶ 从这里看
7:25Cursor 经历与教 Agent 看画面
她 5 个月前加入 Cursor，原本要进云端代理团队，但因为有 React 经验，被派去支持同为 React 应用的 agents window。第 1 周她自己看 Chrome DevTools 的火焰图看不懂，代理也看不懂，只会信心满满地乱指原因；没有验证技能时，人就成了瓶颈，得自己拷贝截屏与错误消息给代理。于是她做出 control glass 技能（Glass 是 agents window 的内部代号），教代理透过 Chrome DevTools Protocol 或 Apple 的模拟器工具操控应用程序。但代理能操作却不知道窗口里有哪些功能，因此需要额外的功能地图。
▶ 从这里看
11:40功能地图、Pstack 与技能评测
功能地图列出各功能如何操作到、键盘快捷键与 CDP 用的选取属性，让代理即使面对品质很差的回报（例如只有截屏加问号）也能对上功能；Pstack 插件附有创建与维护验证技能的功能。Pstack 的名字是调侃 Y Combinator 首席执行官 Gary Tan 的 GStack（两人同姓但无关），并非预先规划，而是从观察代理失败模式、逐一写成技能累积而成。技能本质是 markdown，等于在教毫无背景的新人。维护技能靠 eval，也就是代理的单元测试：协调代理订评分标准、派出多个子代理（刻意不让它们知道正在被评测），再由不同模型的裁判代理交叉检查，并可持续循环直到满分 10 分。但她坦言维护技能很难，需要品味与观察。
▶ 从这里看22:35主厨比喻：从本机导入到云端代理
她用主厨比喻角色转变：工程师不再亲手做每道菜，而是设计厨房环境、分派工作给团队。导入从本机开始，因为可以看着代理启动 CLI 或桌面应用、如何调用界面来操作；她自己则主要押注云端代理，名为 Benny 的代理会接手所有错误回报，在云端桌面运行 Cursor，用同样的控制技能重现问题，例如回报显示错误能重现但主线已修好，只需再发布新版。这让整个团队都受益，但必须先创建信任，别一下子启动大量云端代理而浪费 token。
▶ 从这里看27:15回顾与不盲目信任
访谈者回顾路径：先创建验证技能确认代码至少正确，在本机创建信任后扩展到云端、让代理自己接手回报并提交 PR，最后才是自动合并、再到主线审查。她同意，并说这条路没有捷径，因为信任取决于个人标准，也不希望任何人盲目信任她；插件能加速上手，但鼓励大家改造出自己的技能组，把自己的工程标准写进技能并验证代理确实遵守。
▶ 从这里看
29:35重写之争与代码漂移
她主张重写值得考虑：既有项目若已有框架、惯例与护栏，代理已能做得相当不错，因为大公司为了照顾能力最弱的工程师，早就建好这些限制；新建项目则是最大的风险，也是最大的机会。以全新开发的 Grockbot 为例，完全靠 vibe coding、人没读过代码时没有任何护栏，代理会用最方便的方式解决任务，代码久了就失控。她因此花了超过 600 个 PR 把 Grockbot 重构成新架构，现在几乎不再看代码；这花了大量 token，但让设计师、PM 等非工程人员也能放心加功能，因为 CI 有大量约束，代理吸收了写程序的麻烦。
▶ 从这里看35:25规模化强制运行与 PR 大小
被问到 CI 与 PR 大小，她说没有硬性上限，大小从约 50 行起跳，视内容可以大很多，例如删除大量文件的 PR 几乎都是删除。她仍要求代理把工作拆成多个 PR，让每个 PR 只描述单纯的小变动，git 历史就是丰富的脉络，也方便回退，不会出现 40000 行的 PR 不知道塞了什么。顺带一提，Grockbot 与 Cursor 的虚拟化是由新函数库 Pretext 驱动。
▶ 从这里看
38:15Dune 与惯例式架构
Dune 是 Grockbot 架构的内部代号，可想成给 Electron 应用用的 Next.js，专为代理写程序而设计。它的 CI 检查多到很烦：禁用 useEffect，也禁用代码注解，因为她发现 99% 的时间代理写的注解都是与程序无关的历史叙述。Electron 的 renderer 要维持 60 fps，每帧必须在 16 毫秒内完成，一旦不小心把重运算带进 renderer 就会卡顿，所以把这些经验写进框架成为硬性失败：分开 electron main 与 electron renderer 目录，CI 检查依赖图，禁止跨目录导入。她认为最强的强制层是惯例式架构，因为代理爱拷贝既有模式；例如单一功能的所有代码放在同一个目录，约 80% 的工作大致都封装在内。
▶ 从这里看
43:35最短路径、边界与软性规范
她的首要原则是最短路径就是最佳路径，因为代理爱走捷径，不如让最快的做法就是最好的做法；这套框架只是一组想法与原则，不会开源。强制分成多层：CI 检查、针对观察到的坏模式写的 lint、编译器诊断都会让 CI 变红，是硬性约束；rules、skills 与 bugbot 较软，代理仍可能忘记，只能叠加、不能单靠它们，否则代码迟早变垃圾。技术选择也重要，例如 Rust 编译器严格，只要禁止 unsafe 区块，编译通过就能有一定信心。若每次都靠人在代码审查指出限制，就是坏味道，应该改成 lint 规则、CI 失败，或干脆从根本消除问题。
▶ 从这里看49:45Token 投资报酬与产品同步
对工程主管来说，token 是投资报酬率问题：前期重构代码与创建约束要花大量 token，但如果代理负责写程序，就不必长成 10000 人的工程组织；这些事她单打独斗在代理时代之前要花好几年，因此取舍是雇人，还是花 token 让最笨的代理也能做好。她也坦言自己任职的 AI 实验室 token 不受限，不能要求每个人照做。被问到产品等部门如何跟上，她认为 Grockbot 是关键：界面像 iMessage，让非技术人员轻松使用代理，PM 与设计师甚至直接提交修正，她审查后觉得完美就直接盖章通过，显示 Dune 架构的严格约束让非专家也能高水准贡献。
▶ 从这里看