人一直替 Agent 检查，就很难同时推进更多任务

Lauren 刚加入 Cursor 时，需要帮助优化 Agent 窗口的性能。应用用 React 开发，发布期限很近，代码库对她和 Agent 都很陌生。最初的做法是她打开开发者工具，记录性能轨迹，把截图或文件交给 Agent 分析。Agent 经常很确定地指出一个原因，改完却发现问题仍然存在。

这个过程里，写代码可以交出去，观察应用的工作却仍然压在人身上。Agent 说做完了，人打开开发版本，发现问题，再复制截图和报错回去。一轮轮往返的速度，取决于人能检查多少次。再多开几个 Agent，也会一起等这个人验收。

因此，Lauren 首先补的是验证能力：让 Agent 能启动应用、操作界面、采集 CPU 性能记录和内存快照，必要时运行模拟器。它应当接触用户实际使用的那一层，看到改动前后发生了什么，而不能只根据自己写出的代码判断成功。

这能回答“这个问题是否解决”，但好架构、可维护性和业务判断还需要其他约束。一次运行通过，只覆盖那次实际验证到的行为。

Lauren 用手绘曲线描述这段过程。她在分享中说，自己已经经历过一觉醒来有约 20 个 PR 自动合入的情况。PR 是提交给代码库审查、合并的一组改动。她还提到上个月合入约 1,000 个 PR，当月到 12 日已接近 800 个。这些数字说明她当时处理改动的频率；每个 PR 的内容和规模不同，不能据此计算生产力倍数。

给 Agent 一张功能地图，让它能找到并验证问题

让 Agent 能操作应用，很快又暴露出一个问题：它能打开窗口，却不知道产品功能在哪里。

用户说“左侧栏卡了”或“右边的 PR 标签页不工作”，人通常能联想到具体位置。新来的 Agent 缺少这种认识，只能一边翻代码，一边试着点击。甚至反馈只有一张截图和几个问号，它连问题指向哪个功能都不确定。

Lauren 为验证技能增加了 Feature Map，功能地图。它把用户眼中的功能和实际到达路径联系起来：从哪进入、有哪些子功能、怎样操作、有什么快捷键，以及程序化操作界面时能使用哪些元素属性。Agent 因而能把一句模糊反馈，转换成一段可执行的导航过程。地图负责讲清产品怎样使用；需要理解内部实现时，仍要回到代码。

可以用下面这组问题检查自己的地图是否有用：

这张表可作为整理功能地图的起点，具体路径和元素需要根据自己的产品填写。复制另一款产品的导航文档，并不能让 Agent 理解当前应用。

Lauren 把创建和维护验证技能的办法放进了 pstack。维护与创建同样关键：入口、快捷键和交互变了，旧地图就会把 Agent 带到错误位置。验证工具负责让它“能操作”，功能地图负责让它“知道怎样到达要验证的地方”。

把反复踩的坑，整理成可复用的工作方法

pstack 最初是 Lauren 在日常工作中积累的一组技能。Skill 可以理解为给 Agent 使用的任务说明和操作方法，常以 Markdown 保存，并配合执行工具。它的价值来自具体经验：某一种失败反复出现，就把正确处理方式写下来。

例如，Agent 一口咬定某个故障原因时，她去看实际工具调用，发现它根本没有读取应当相关的代码。对于这种问题，仅仅补一句“认真一点”很难改变工作。她需要明确要求它先搜索、阅读相关实现，必要时分头调查，再根据证据解释原因。

这也说明，早期观察不能只看最终回答。回答听起来很合理，实际动作却可能没有支撑它。查看读了什么、运行了什么、验证了什么，才能知道应当补哪一种能力。

用实际任务评估，确认技能有没有帮助

写进 Skill，不代表 Agent 就会稳定照做。Lauren 用 eval，也就是针对 Agent 行为的评测，来检查技能修改是否产生了预期结果。她的方法包括：先明确任务与评判标准，再让多个 Agent 在独立目录中执行，观察它们能否做对；对常用的不同模型重复评测；必要时用另一种模型作为裁判，交叉检查判断。

她还会尽量避免让目录命名等线索直接暴露“你正在参加评测”，因为她观察到 Agent 识别出评测场景后可能改变行为。这里关注的是日常执行的可靠性，而不只是某次展示是否漂亮。

她也描述了让协调 Agent 反复修改技能、运行评测、提高得分的做法，验证技能本身就经过这样的迭代。评测达到满分，表示它满足了那套任务和评分标准；不能由此保证所有新任务都正确。评测能否暴露真实工作里的失败，仍需要人持续观察和判断。

这些基础工具也可以由 Agent 帮忙建设。Lauren 让 Agent 参与编写控制应用的命令行工具、改进验证技能，再通过评测检查效果。人负责选定要解决的问题和判断标准，Agent 参与实现与迭代。这样，过去因为缺少人手而一直没建起来的工程工具，也有机会逐步补齐。

这条改进路径可以落到一个小范围上：先选一个经常失败的任务，记录 Agent 漏掉了哪一步；补一条具体方法；用能触发该问题的任务检查它是否改变了行为。等这一类问题稳定下来，再扩大技能覆盖范围。

把反复出现的错误，变成自动检查

验证能力解决了“运行起来有没有达到目标”，代码库还要解决“功能越加越多后，整体会不会变差”。

Lauren 认为，这和大规模工程团队遇到的问题很相似。许多人同时提交代码时，不能只靠每个人始终记住所有原则；需要框架、约定、权限和自动检查。Agent 提交改动的速度提高后，小团队也会遇到这种协调压力。

因此，已有成熟约束的老项目可能更适合 Agent。风险较高的反而是迅速拼出来的新原型：每个任务都按当时最方便的方式解决，久而久之，功能之间的依赖变得混乱，修改一处又破坏另一处。

为避免每个功能各走各的路，她把 Grokbot 这款 Agent 应用重构到一套共同的工程约定中，称为 Dune。它规定代码怎样组织、哪些依赖不允许出现，并通过自动检查执行这些限制。Lauren 将它描述为一组原则和设计，没有承诺把它作为通用框架开源。

Dune 最具体的例子，是限制哪些代码可以进入界面渲染一侧。Electron 是构建桌面应用的一种技术，界面绘制与其他工作需要合理分工。Lauren 说，Agent 窗口过去常因隔离不清，让重计算或大量 I/O 意外进入渲染路径，和界面更新争抢时间。

60 FPS 意味着每秒显示 60 帧，每帧预算约为 16.7 毫秒，分享中将其近似为 16 毫秒。如果其他工作占用了这段时间，界面就容易掉帧、卡顿。只在审查时提醒“别引入卡顿”，很难追上频繁合入的改动。

她在 Dune 中把相关代码放进明确分开的目录，再通过 CI 检查依赖图，阻止违反边界的导入。CI 是代码提交后自动运行的一组检查；违反可检测的约束，检查就失败。这样，错误不必等到人读 PR 时才被发现。

其中，Bugbot 是辅助审查代码的工具。几种约束分别承担不同工作：

Lauren 还举了禁用代码注释的项目约束。她观察到，Agent 会把一次局部修改意见写成貌似永久有效的注释，让后来的执行者误以为那是全局规则。她也在 Dune 中禁用 React 的 useEffect——一个常用于让组件与外部系统同步的接口，她认为它容易被用错。这些属于她对那套代码库的选择，不能直接推广成所有 React 项目或所有团队的规则。

她提到 Rust 时，强调的也是编译器能替人强制一部分约束。编译检查的价值在于提前拦截它能够识别的错误；业务是否正确、界面是否流畅，仍有各自的验证问题。

对团队更有用的动作是：如果同一种审查意见反复出现，就检查它能否成为 lint（自动检查代码模式的规则）、CI 检查，或通过架构调整消除那条错误路径。人的判断由此沉淀到之后每一次提交中。

让正确的写法，成为最省事的写法

硬约束多了，会不会让开发越来越麻烦？Lauren 的另一半设计是，让正常工作有一条清楚、就近、容易模仿的路径。

比如一个功能的相关代码集中放在一个目录，新增功能也遵循相同的组织方式。Agent 处理新手引导时，就能主要围绕对应功能目录工作，不必在代码库各处寻找碎片。框架中的功能、入口和聊天卡片等概念，也有约定的创建方法。

Dune 还要求，每个需要长期保存的状态值，都有一个明确的写入者；新增产品功能尽量增加独立文件，避免不断给共享入口添加分支；确需例外时，范围要小、意图要明确，并按架构变更接受审查。这些约定让状态由谁修改、功能在哪里扩展、边界怎样调整，都有清楚的处理方式。

这利用了 Agent 喜欢沿用已有模式的特点。好模式容易找到，照着做就符合约束；坏路径由自动检查拦住。架构因此同时给出了正向示范和错误边界，Agent 少做一些不必要的选择，也更容易把已有做法用对。

减少不必要的判断，还可能降低任务对模型能力的要求。Lauren 说，在这套环境准备好后，能力不及最大模型的 Agent 也能把代码工作做好。她没有给出统一的成本降幅，但这提供了一个可检验的方向：先把任务路径和工程边界讲清楚，再用自己的任务评估是否还需要更强的模型。

工作拆分同样服务这个目的。Lauren 鼓励把改动拆成多个含义完整的 PR，让每个 PR 说明一小块工作在干什么。这样，Git 历史能留下可理解的上下文，出问题时也更容易定位和回滚。

她没有给 PR 设统一行数上限。她描述的规模从约 50 行到上千行不等，也可能主要是删除代码。因此“小 PR”的重点，是改动能独立说明、检查和撤回，而非所有提交都控制在同一个数字之下。

先在本地跑可靠，再交给云端和团队使用

Lauren 建议从本地建立验证流程，因为人在现场能看见 Agent 是否进入了正确界面、调用了什么工具、有没有实际完成检查。等这套能力可信，再放进云端，才容易让多人复用。

她展示的 Benny 是一个处理反馈的 Agent。它收到 bug 报告后，在自己的云端电脑里启动 Cursor，用同一套控制技能尝试复现。一个具体回报是：它在旧提交上复现了问题，但发现 main，也就是主干代码，已经修好。

这份回报的价值很直接：团队知道修复已经存在，下一步是发布包含修复的新构建。无需再派一个人和 Agent 来回确认一个小时，也无需重复修改已修好的代码。

云端复用放大的，就是这类已经建立的能力。验证工具、功能地图和环境配置不再只帮助 Lauren，还能帮助接收反馈的同事。反过来，如果单个 Agent 的操作还不可靠，直接扩到大量云端实例，只会把空转与错误一起扩大。

让更多同事用起来，还需要合适的入口。Lauren 提到，IDE 和命令行偏向开发者，产品经理、设计师未必用得顺手；Grokbot 采用更接近日常聊天的界面，便于他们提出任务、查看进展和参与修改。容易使用的入口负责让人进得来，后面的验证与工程约束负责支撑改动质量。

自动合并也处在这段历程的后面。Lauren 的实践可以用来理解它需要哪些支撑，但其中没有一份适合所有项目的自动合并条件。团队仍需根据自己的工程标准，确认哪些结果足以支持下一步操作。

这套改造值不值，要看整个团队能否持续受益

Lauren 为了把 Grokbot 重构到这套架构，投入了 600 多个 PR，也消耗了大量 token。她明确承认自己在 AI 实验室工作，拥有非常充裕的 token 资源，其他团队不能假设同样的投入条件。

所以，这套方法的成本要和后续收益一起看。前期需要建立控制工具、整理功能地图、迭代评测、迁移架构、补齐检查；收益则是减少后续重复验证，让更多贡献者在同一套约束下完成工作。她描述的回报还包括产品经理和设计师能借助 Agent 修复问题、提交功能，再由工程同事审查。

前面的框架、检查和验证环境，把一部分专业经验变成了其他同事也能使用的条件。她没有提供通用的回本周期；判断是否值得投入，应当看这些设施能否被持续复用，以及是否确实减少了重复的人工介入。

如果要开始实践，范围可以收得很小：选一个反复出现、能在本地观察的故障，让 Agent 独立跑通复现与验证；补齐这条路径的功能地图；把一次常见的违规写法变成可执行检查。等同类任务不再反复依赖人工补步骤，再把能力扩展到其他功能和云端。

工程师的工作也随之变化：除了解决眼前的问题，还要把这次解决问题所依赖的知识、动作和边界留下来。下一次执行者能直接用上这些条件，可靠的自主工作才有可能持续增加。

原文参考

Lauren Tan，How Cursor Turned AI Agents Into Better Engineers，Maven，2026 年 8 月 12 日。视频章节包括验证与功能地图（08:35）、技能评测（20:04）、云端 Agent（26:34）、重构与约束（32:34）、Dune 架构（41:00）和成本（50:38）。

观看原始分享

公司归属：Cursor 于 2026 年 8 月 14 日宣布正式被 SpaceX 收购，团队在官方公告中明确表示加入 SpaceXAI。原分享和产品中的 Cursor 名称按当时称呼保留。收购公告 · 团队归属说明