Lauren Tan's Cursor agent talk subtitled in Chinese

Tao Wang@Tao100086

Lauren Tan（@poteto）在一个视频中分享她在 Cursor 使用 AI 编程 Agent 的经验, 值得看一下。

我用我的skill，抓取字幕，翻译并重新烧录了双语字幕。

贯穿整场的观点是：要让 Agent 可靠地自主完成工作，工程师需要先建设好验证工具、项目知识和自动化约束。信任来自这些机制持续产出的可靠结果。

1. 信任决定了你能把多少工作交给 Agent。〔00:54–05:39〕

如果 Agent 经常凭猜测定位问题，你就不得不盯着每一步操作。此时，即使同时启动很多 Agent，你自己的检查能力仍然会成为瓶颈。

她描述的成长路径是：从紧盯一两个 Agent，到让它们独立完成任务，再到自动合并代码。她自述曾一个月合入约 1,000 个 PR，也有睡醒后发现 20 多个 PR 已经合入的经历；这些成果建立在前期大量建设工作之上。

2. 首先让 Agent 能够亲自验证自己的工作。〔05:40–13:37〕

Agent 应当能够启动应用、操作界面、复现问题、查看运行日志和性能数据，并检查修改后的实际表现。如果这些步骤都由人来完成，人就会一直困在“运行—截图—反馈—再修改”的循环里。

她特别强调 Feature Map，也就是“功能地图”：告诉 Agent 一个功能在哪里、如何进入、有哪些快捷键、怎样定位界面元素。这样，面对“侧边栏很卡”或一张模糊截图，它才知道应该去哪里检查。

这里有一个关键区分：验证用于判断功能是否解决了问题；代码是否清晰、易维护，还需要其他机制。

3. 把反复出现的失败，转化为可复用的 Skill，并检验它是否有效。〔13:37–23:56〕

她把 Agent 比作“很会写代码、但刚入职五秒钟的新同事”：缺少业务背景，也不了解团队的工作习惯。Skill 就是把这些背景、标准和操作方法写下来，供它反复使用。

她的 PStack 工具集来自持续观察：发现 Agent 没读相关代码就下结论，就补上调查流程；发现它不会验证，就补上验证能力。

Skill 本身也需要评估。她会设定评分标准，让多个 Agent 或模型执行任务、交叉检查结果，再根据表现修改 Skill。写下一条要求，并不等于 Agent 已经稳定掌握了它。

4. 先在本地建立可靠流程，再扩展到云端和自动化。〔24:32–30:11〕

起步阶段适合在本地观察：应用能否启动、Agent 会不会操作、是否真的复现和验证了问题。流程稳定之后，再把相同能力搬到云端。

她举了一个名为 Benny 的 Agent：它接收 Bug 报告，在云端启动应用并尝试复现。有一次，它确认问题在主分支中已经修复，只需要发布新版本，省去了人工重复排查。

她明确不建议在基础能力尚未可靠时，直接启动成百上千个 Agent，那会放大失败和费用。

5. 代码库本身需要适合 Agent 工作。〔30:17–38:54〕

她认为，有成熟规范和检查机制的老项目，可能比毫无约束的新项目更适合 Agent。快速拼出来的原型虽然交付快，但 Agent 不断选择眼前最省事的做法，会逐渐积累难以维护的结构。

因此，某些项目值得投入重构。她自述为迁移到新架构进行了超过 600 个 PR 的改动，目的是让后续开发更稳定，让整个团队受益。

她也鼓励把工作拆成目标单一的小 PR，便于理解修改、定位问题和回滚，没有规定统一的代码行数上限。

6. 把重要规范变成自动执行的检查，让最省事的路径就是正确路径。〔39:07–48:43〕

这是整场最重要的工程方法之一。她认为，规则文档、Skill 和 AI 审查都可能被遗漏，重要约束需要落实到项目结构、编译检查和 CI——也就是提交代码时自动执行的检查。

她介绍的 Dune 架构会把同一功能的代码集中存放，并检查模块之间的引用关系。例如，限制界面渲染部分引入不该承担的繁重计算，减少卡顿风险。

Agent 喜欢沿用已有模式、选择捷径，因此应该把项目设计成：照着现有方式做，就容易做对。

她在自己的项目中甚至禁用了 useEffect 和代码注释。这些是针对其项目失败模式制定的具体规则；更值得提炼的方法是：把反复出现的审查意见转化为可以自动检查的约束。

7. 前期建设有成本，回报要放到整个团队和长期使用中看。〔49:23–54:15〕

她承认自己拥有非常充足的 Token 资源，其他人不应原样照搬。重构、编写 Skill 和建立验证体系，都需要时间与费用。

她的判断是：如果这些投入能减少后续返工，让更多人持续贡献代码，甚至让能力较弱的模型也能做好工作，就可能带来可观回报。但分享中没有给出普通团队可直接套用的成本预算。

8. 工程师的职责，会更多地转向设计工作环境和质量标准。〔23:15–23:44；54:18–57:03〕

她用“主厨”作比喻：工程师不必亲自做每一道菜，而要设计厨房、制定流程、分配任务，并保证出品质量。

当工具、架构和检查足够完善后，产品经理、设计师也能借助 Agent 修改功能和修复问题。工程师的重要贡献，是让这种参与可以长期、稳定地进行。

按她的思路，可以把实践顺序整理为：
观察失败 → 补充项目知识和 Skill → 建立实际运行验证 → 评估并改进流程 → 把关键规范变成自动检查 → 逐步扩大自主工作的范围。