一、问题引入：Agent 不是自动补全，而是一种新的工程协作对象
这支视频的出发点很直接：越来越多开发者已经不再逐行手写所有代码，而是在和编程智能体对话，让它搜索代码库、修改文件、运行命令、解释失败原因并准备 PR。真正的难点因此从“会不会写提示词”转移到了“能不能把一个含糊目标变成可验证、可审查、可迭代的工程任务”。
leerob 选择 Cursor 作为演示环境，但这节课的价值并不局限于 Cursor。视频反复强调的几个原则，适用于 Claude Code、Codex、GitHub Copilot Agent、Devin 类工具，甚至适用于你自己封装的内部 Agent：上下文要可控，意图要清楚，计划要先审，修改要小步，测试和代码审查必须接上。
课程的主线是为文档站新增模型详情页。这个任务足够真实：它需要理解现有路由、配置、组件、导航和测试，又不至于复杂到被业务细节淹没。借这个例子，视频把“理解代码库 → 制定计划 → 生成变更 → 迭代 UI → 调试失败 → 写测试 → PR 审查 → 沉淀规则”串成一个完整闭环。
二、核心概念：先把 Agent 的工作边界讲清楚
1. Harness：智能体真正运行的外壳
视频开头把 Cursor 的 coding agent 放在一个更通用的概念里：harness。可以把它理解为模型的运行外壳，由三部分组成：给模型的 instructions、可调用的 tools，以及你选择的 frontier model。模型本身只是推理核心，harness 决定它能看什么、能改什么、能运行什么命令、如何把结果返回给你。
这个视角很重要，因为很多团队讨论 Agent 时只比较模型名，却忽视工具权限、代码搜索、上下文注入、审批机制和运行环境。实际工程结果往往由这些外壳能力决定，而不是单纯由模型参数决定。
2. Context：工作记忆越大，越需要治理
对话消息、工具调用、读取过的文件、日志、截图、PR diff，都会进入智能体的工作记忆。上下文越丰富，回答越可能贴近真实系统；但上下文太杂，模型也更容易被旧信息、无关文件或错误假设带偏。视频建议：新功能最好开新会话；当 Agent 开始跑偏，重新整理上下文比继续追问更有效。
在大型代码库中，Cursor 会结合 literal search 和 semantic search：前者像 grep，找精确字符串；后者用 embedding 把自然语言问题映射到相关代码。两者结合，能让“认证逻辑在哪里？”这类问题找到没有直接包含 authentication 字符串的实现文件。
3. Sub-agent：把探索和主会话拆开
视频特别强调 explore sub-agent。它可以在独立上下文窗口里搜索代码库、总结发现，只把结论交还给主 Agent。这样做的收益是主会话不被大量文件内容撑爆，同时让探索阶段更快、更聚焦。对于陌生大仓库，先让 Agent 生成架构图或数据流图，也是减少误改的重要步骤。
4. Rules 与 Skills：团队知识要短、准、可维护
结尾部分讲到定制化。Rules 是每次会话都会带入的 Markdown 指令，适合放构建命令、测试命令、代码约定、关键目录和团队偏好的 canonical pattern。Skills 则适合偶尔才需要的专业知识。视频提醒不要把所有东西都塞进 rules，因为它会长期消耗上下文，还可能让 Agent 混淆优先级。
三、关键论点与实操步骤：把一次 AI 编程变成可交付流程
步骤一：不要直接下命令，先要求理解系统
视频中的反例是“帮我加一个页面”。这种提示会迫使 Agent 猜测布局、组件、样式和路由策略。更稳的方式是先让它找现有模式：哪些页面已经类似？数据从哪里来？导航在哪里注册？测试怎么写？这样 Agent 才会复用已有抽象，而不是凭空创建新的 utility、组件或目录结构。
步骤二：进入计划模式，但计划必须由人审
作者演示了一个刻意有点含糊的任务：“为支持的模型增加专用页面”。Cursor 先探索代码库，提出动态路由、配置查找、能力组件和侧边导航更新等步骤。真正关键的动作不是“点击 Build”，而是人在计划阶段删掉过大的范围、补充选择标准，并确认文件触点是否合理。
一个好计划应该回答三件事：要改哪些文件，为什么改这些文件，如何验证。视频中的计划还生成了 Mermaid 数据流图，帮助理解新页面如何从模型配置读取数据并进入现有文档站导航。
步骤三：生成后马上看 diff，不要等它堆成大变更
Agent 完成第一版后，作者先看 diff 和运行结果，再通过截图、语音和具体指令迭代 UI。这里的技巧是把反馈变成可观察信号：例如“这些 pills 需要更贴合设计系统”“图标可以保留，但颜色不要偏离品牌”。图片、浏览器状态和 DOM 元素选择都比抽象形容词更容易让模型改对。
步骤四：调试要回到工程基本功
视频中间把焦点转向 bug fixing：能复现、最小化、隔离变量、提出假设，再验证修复。Agent 可以帮忙跑命令、加日志、检查调用链，但它不能替代这些基本原则。如果一个失败无法复现，Agent 很容易给出看似合理但不可证明的改动。
步骤五：测试和 AI code review 是放权前提
作者把 PR 发给别人之前，会先自己审一遍，再用 AI code review 工具做额外检查。视频里 BugBot 找到了 clipped icon 和 duplicated function 两类问题。随后作者又要求 Agent 为新模型页面补测试，并让 Agent 做更长时间的端到端探索，例如搜索、复制页面、切换主题、分享反馈等。
步骤六：把学到的东西沉淀回 rules
完成折扣码案例后，作者把发现写回共享 rules 文件，让团队后续处理同类逻辑时能自动获得上下文。这是整节课最容易被忽略的部分：Agent 工作流不是一次性技巧，而是可以积累的团队资产。每次修复后的知识沉淀，都会降低下一次对话成本。
四、对比表格：什么时候该用哪种 Agent 工作模式
| 模式 | 适用场景 | 优点 | 主要风险 | 建议做法 |
|---|---|---|---|---|
| 直接实现 | 很小的 copy、样式、单文件修复，需求边界清楚。 | 速度快，沟通成本低。 | 任务稍复杂就容易猜错上下文。 | 限制改动范围，要求先显示 diff。 |
| Plan Mode | 新增功能、跨文件改动、需要复用现有模式。 | 先暴露假设，便于人类删减范围。 | 计划过大时会制造一口气大改。 | 审计划、删非必要步骤、确认验证命令。 |
| Explore Sub-agent | 陌生大仓库、调用链复杂、需要生成架构图。 | 减少主上下文污染，输出聚焦结论。 | 只看结论可能漏掉实现细节。 | 要求它引用文件和原因，再让主 Agent 决策。 |
| Debug Mode | 测试失败、线上缺陷、行为与预期不一致。 | 可以系统性跑命令、收集证据。 | 没有复现步骤时容易“猜修”。 | 先复现，再最小化，再隔离变量。 |
| Rules / Skills | 团队约定、构建命令、领域知识、重复流程。 | 把个人经验变成团队默认上下文。 | 过多 rules 会消耗上下文并互相冲突。 | 保持短、具体、指向真实例子，定期清理。 |
五、引用块：这节课最值得带走的判断
编程智能体会非常字面地执行你的请求；如果你不提供意图，它就只能用自己的最佳判断。
这句话解释了为什么许多 AI 编程体验会两极分化。不是 Agent “聪明或不聪明”这么简单，而是你是否让它看见了正确的上下文、正确的约束和正确的成功标准。工程团队越成熟，越应该把 Agent 当成会写代码的新同事：给背景、给边界、给计划、给审查，而不是只给一句目标。
六、时间戳目录：按视频脉络快速复习
七、相关推荐
如果你看完这节课，下一步可以沿两个方向继续：一是学习更底层的 Agent 工具协议与上下文治理，二是学习生产环境里如何审查、调试和沉淀团队规则。
返回 课程列表 可以浏览全部视频课程。