本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

Maven 课程 "How Cursor Turned AI Agents Into Better Engineers"，主讲人 Lauren Tan @poteto

Lauren 认为：Agent 的产出质量上限，取决于你为它搭建的"环境"：可验证的反馈闭环 + 硬性约束的代码库 + 可被评测的技能。她用五个月从"盯着一个 Agent 逐行看"走到"Agent 自动合并 PR、我事后在 main 上审阅"，核心是信任被系统性地建立起来。

核心框架：Agent 信任曲线

Lauren 用"工程管理"作为贯穿全场的类比：不信任下属的经理只能微观管理，不信任 Agent 的工程师只能待在循环里逐条盯输出，无法并行。

  • 起点：1–3 个本地 Agent，人是唯一的验证者，也是瓶颈。
  • 中段：Agent 能自己运行、测试、复现问题，人从"验证者"退为"审阅者"。
  • 终点：Agent 在云端自主领任务、开 PR、自动合并；人审阅已落地的代码。

她的个人数据：入职第一个月几乎没产出，上个月合并约 1000 个 PR，本月（12 号）已近 800 个。她明确表示这条曲线没有捷径，因为它反映的是你个人对 Agent 的信任程度；在信任不足时直接上百个云端 Agent，只会烧掉大量 token。

第一支柱：验证能力是最重要的技能

"验证"指 Agent 能真实运行应用并观察结果：跑代码、抓 CPU trace、拿 heap snapshot、打开 iOS 模拟器、通过 Chrome DevTools Protocol 操控 Electron/Web 应用。

  • 它不保证代码"好"，但保证代码"对"，这是信任的第一块基石。
  • 没有验证技能时，人要手动复现、截图、粘贴报错再喂回 Agent，整个流程无法并行化。
  • 她在 Cursor 的第一个技能就是 control-glass（glass 是 Agents Window 的内部代号），教 agent 用 CDP 驱动应用、抓性能 trace。

关键细节：Feature Map（功能地图）

只有控制能力还不够。Agent 能打开应用，却不知道"左侧边栏"或"PR 标签页"在哪、怎么到达，于是在代码里乱翻、原地打转。Feature Map 是一份 Markdown 文档，从用户视角描述每个功能的入口、子功能、快捷键，以及用于 CDP 选取的 DOM 属性。有了它，一张只带三个问号的模糊截图式 bug 反馈，agent 也能定位并复现。pstack 里的 create-verification 技能会扫描代码自动生成初版地图，maintain-verification 负责持续更新。

第二支柱：Skills 与评测 Evals

pstack 的由来

pstack（"Potato Stack" 😃）并非规划出来的产品，它是逐个 Skill 自然堆积的结果。方法论只有一条：在早期极度"在循环里"，逐条读 Agent 的工具调用和思考块，每发现一种失败模式就把纠正方式写成技能。

一个典型例子：Agent 信心满满地宣称找到"罪魁祸首"，但工具调用记录显示它根本没读相关代码。对应的 Skill 就是：禁止猜测，先搜代码、多用 sub-agent、把证据查实再下结论。

她对 Skill 的理解：Markdown 本身没有魔力，但高质量的起始 token 会把模型"拉到更聪明的潜空间"——就像给一个能力很强但零业务上下文的新员工一份入职手册。

用 Evals 维护 Skill

针对"产品在变，Skill 怎么维护"的提问，她的回答是把 eval 当作 Skill 的单元测试：

  • 主协调 Agent 先写评分 rubric，再派多个 sub-agent 分别在独立目录里执行任务。
  • 目录名刻意伪装，避免 sub-agent 察觉自己在被测试——Agent 发现被评测时会改变行为。
  • 用不同厂商的模型做 judge，交叉校验，防止单模型偏见。
  • 借助 Cursor 多模型支持，在你常用的模型矩阵上跑同一份 eval。
  • eval 产出分数后可以"爬山"：用 /loop 持续迭代 Skill 直到全部满分。她的 control Skill 就是这样几乎无人值守地打磨出来的。

pstack 的 eval-playbook 收录了这套流程。她也坦承：维护 Skill 很难，需要品味和长期观察，本质上是做一个挑剔的"副驾驶"。

从本地到云端

建议路径：先在本地建验证 Skill，因为你能亲眼看到 Agent 如何与应用交互；信任建立后再迁到云端。云端的价值在于杠杆——一套验证 Skill 不只让你一个人变强，更是让全团队、全公司受益。案例是内部 Agent "Benny"：自动接收 bug 报告，在云端桌面里启动 Cursor，用同样的控制 Skill 复现问题。她展示的一例中 Benny 复现了 bug 并确认 main 上已修复，只需发版即可——省下的是原本要人陪 Agent 排查一小时的工作。

第三支柱：为 Agent 重构代码库，用硬约束替代人工审查

这是她认为最有争议、也最重要的部分。

"有机架构"的风险

纯 vibe-coding 的全新项目没有任何护栏，Agent 会用最省事的方式解题，代码库逐渐长成人类看不懂、只为捷径优化的形态。她的判断：

  • 大厂式的褐地代码库（框架、约定、权限隔离齐备）其实处境不错——那些为"团队里最弱的工程师"设计的基建，恰好也约束住了 Agent。"AI slop 之前先有 human slop。"
  • 从零开始的新项目风险最大，机会也最大。

案例：GrockBot 与 Dune 架构

GrockBot 是 Cursor 刚发布的新应用（类 iMessage 界面，可以给 Agent 命名、组建 Agent 团队并编排）。它最初是快速 vibe-code 出来的原型，Lauren 花了约 600 个 PR 把它重构到自建的 "Dune" 架构上（可理解为"面向 Agent 编写的 Electron 版 Next.js"）。结果是她"基本不再看代码"，PM、设计师、GTM 同事都能直接提交功能，且不用担心半夜被性能回归吵醒。

Dune 的设计原则和具体约束：

  • 最短路径即最佳路径：Agent 天生爱走捷径，那就让捷径成为正确做法。
  • 强约定：feature、entry point、transcript card 等是框架里的"名词"，每个 feature 的所有代码同目录共置，80% 的工作不出该目录。agent 擅长模仿现有模式，约定本身就是最强的执行力。
  • 禁用 useEffect：React 最大的坑，直接 CI 失败。
  • 禁止代码注释：她观察到 99% 的 agent 注释是无关的历史叙述（甚至出现"Lauren 说过不要这样做"这类把一次性 PR 反馈误当全局规则的注释）。
  • 进程隔离由依赖图检查强制：electron-main 与 electron-renderer 目录互相导入会挂 CI，防止重计算或 IO 误入渲染线程、打破 16ms 帧预算。这是 Agents Window 至今反复性能回归的根因，她计划把 Dune 的经验反向移植回去。
  • 原则：凡是 Agent 做不好的事，一律禁掉。

约束的分层与硬软之分

她把执行手段分层：代码库架构 > 静态分析（lint、编译器诊断、CI 检查）> Rules / Skills / Bugbot / 风格指南。前两层是硬约束，CI 变红；后面几层是软约束，Agent 会遗忘或不一致地应用。她的警告很直接：只靠 rules、skills、Bugbot 和风格指南，代码库变成垃圾只是时间问题。

由此引出一条可操作的判据：每当你需要在 code review 里人工提醒"这里不该这样写"，就应该视为一个反模式信号——问自己如何把它变成 lint 规则、CI 失败，或者在架构层面彻底消灭这类问题。技术栈选型也算在内：Rust 走红的原因之一就是编译器替人扛下了大量验证。

工程实践细节（Q&A 中的回答）

  • PR 大小：无硬上限，从几十行到上千行不等，但鼓励 Agent 拆分成原子 PR。理由是 Git 历史是宝贵的上下文，原子 PR 便于回滚和定位问题，而不是让 bug 淹没在四万行的巨型 PR 里。
  • 主持人的路径复述得到确认：先建验证 → 本地建立信任 → 扩展到云端让 Agent 自主领任务 → 最终自动合并、事后审阅。

关于 token 成本与 ROI

她承认自己身处 AI 实验室、token 近乎无限，不要求所有人照搬。但她把这归结为 ROI 判断：前期重构和加约束确实要烧大量 token，但换来的是"一个人在前 Agent 时代几年都做不完的事"——独自设计并落地一整套强约束框架。对工程负责人而言，问题变成"招一个人做这件事"还是"花 token 把代码库整备到连最笨的 Agent 也能写出好代码"。达到那个状态后，小模型也能高质量产出，非工程角色也能可持续地贡献。她还提到当天发布的 Grok 4.6 单 token 成本与 4.5 持平，Cursor 优化的是成本-智能的帕累托前沿而非最大模型。

对产品团队的影响

被问到"工程提速后其他职能如何跟上"，她的回答是 GrockBot 本身就是答案：Cursor 的 IDE/CLI/Agents Window 都是开发者工具，GrockBot 则是非技术人员的"Cursor 时刻"——PM 用 Agent 汇总她昨晚做了什么，也直接修 bug 提 PR，而她审阅后往往直接通过。这被她视为 Dune 架构成立的证据：足够严格的约束让非专家也能高水平贡献。

我的几点观察

  • 全场最有迁移价值的不是 pstack 本身，更是那条工作方法：早期极度介入、逐条读工具调用、把每种失败模式固化为技能，再用 eval 守住技能不退化。她本人也建议不要盲信 pstack，应 fork 后改成自己的版本。
  • "把 review 评论转化为硬约束"是最具杠杆的单条建议，它把工程师的角色从"逐个 PR 把关"转为"设计让错误无法发生的环境"——对应她的主厨类比：不亲自炒每一道菜，去设计厨房和流程。
  • 她对 Agents Window 性能问题的坦率承认，反过来说明这套方法在 Cursor 内部也还在推进中，并非已完成态。
  • 课程开头表明她的立场偏保守：AI 最好的用法是结对编程伙伴，而不是外包思考；她自己用 AI 节省的写码时间，相当一部分被花回到审阅和纠错上——这正是她后来投资于验证与约束的动因。