# 第 3 天：TRAE 能力体系与 Agent 工作方式 # 第 0 部分：从规则治理到 Agent 工作流 --- ## Slide 0-1：第 1 天到第 3 天 ### PPT 页面内容 ```Plain Text 第 1 天： 让 TRAE 看懂若依代码 第 2 天： 让 TRAE 按团队规则参与若依研发 第 3 天： 切换到 JeecgBoot 工单案例 把 TRAE 能力接入 Agent 工作方式 核心变化： 从单次对话 到可复用、可验收、可协作的 Agent 工作流 ``` ### 讲师逐字稿 前两天我们一直围绕若依项目来训练。 第一天，大家学习的是如何让 TRAE 看懂陌生代码库。我们不是泛泛问“这个项目是什么”，而是沿着登录、用户信息、菜单路由、按钮权限这条链路，找入口、追文件、查函数、标注依据。 第二天，我们进一步学习上下文工程和 rules。也就是说，不只是让 AI 看懂代码，还要让 AI 按团队规则做事。比如不能把前端按钮权限当安全边界，涉及敏感接口必须检查后端权限，敏感操作必须检查操作日志。 第三天我们切换到 JeecgBoot 工单管理模块。原因很简单：若依更适合训练读代码和规则治理，JeecgBoot 更适合训练企业应用开发、代码生成、页面配置、权限接入和功能验收。 今天不是单纯介绍产品功能。今天要回答的是：在 JeecgBoot 工单模块开发中，团队如何把常用 Prompt、规则、检查清单、浏览器验证、Plan 和 Review 组织成一套可以反复使用的 Agent 工作流。 --- ## Slide 0-2：第三天训练主线 ### PPT 页面内容 ```Plain Text 今天训练六个动作： 规则分层 任务分级 能力封装 工具接入 浏览器验证 Plan / Review 闭环 最终产出： JeecgBoot 工单 Agent 工作流资产草案 v0.1 ``` ### 讲师逐字稿 今天的主线有六个动作。 第一，规则分层。第二天我们写了 rules.md，今天要把这些规则迁移到 JeecgBoot 工单模块里，形成前端、后端、权限、审计、测试和交付规则。 第二，任务分级。不是所有任务都适合让 Agent 全托管。拆工单需求、生成接口契约、审查代码生成结果、修改状态流转、修复 CI，它们的风险、上下文需求和验收方式都不同。 第三，能力封装。前两天大家写了很多好 Prompt，今天要把它们升级成 Commands 和 Skills。 第四，工具接入。Agent 不只看代码，还可能接 Git、CI、浏览器、文档库和内部平台。 第五，浏览器验证。尤其前端改动，不能停留在“代码看起来对”，必须能打开页面、操作流程、截图复核。 第六，Plan 和 Review 闭环。高风险任务必须先计划，再执行，再审查。 今天最终产出不只是代码，而是一套围绕 JeecgBoot 工单模块的 Agent 工作流资产草案 v0.1。 --- ## Slide 0-3：贯穿案例 ### PPT 页面内容 ```Plain Text 贯穿案例： JeecgBoot 工单管理模块开发与审查 从一次 Prompt 到一套 Agent 工作流： 需求 -> 契约 -> 代码生成 -> Command -> Skill -> Browser 验证 -> Plan -> Review ``` ### 讲师逐字稿 今天我们切换到新的贯穿案例：JeecgBoot 工单管理模块开发与审查。 这个案例包含工单列表、工单详情、状态、优先级、指派人、评论记录、按钮权限、接口权限和基础验收。它比前两天的“读代码和规则审查”更接近真实开发交付。 今天我们不再只问 TRAE：“帮我写一个工单模块。” 今天我们要把这个任务拆成一套工作流： 先把需求拆清楚，再设计字段、接口契约和页面状态；再判断哪些高频动作适合 Command，哪些复杂流程适合 Skill；如果涉及页面，就要设计 Browser 验证；如果涉及状态流转、删除、指派等高风险修改，就要进入 Plan 模式；最后再用 Review 模板检查风险。 这就是从单次对话升级到 Agent 工作流。 --- # 模块 1：规则体系的演进 --- ## Slide 1-1：为什么第三天还要讲规则？ ### PPT 页面内容 ```Plain Text 第 2 天： 写出 rules.md v0.1 第 3 天： 让 rules 进入 Agent 工作流 规则不只是文档 规则是 Agent 的执行边界 ``` ### 讲师逐字稿 第二天我们已经写过若依 rules.md v0.1，为什么第三天还要继续讲规则？ 因为规则写出来只是第一步。第三天要做的是把这些规则迁移到 JeecgBoot 工单模块开发中，让 Agent 在需求拆解、代码生成、权限接入、浏览器验证和 Review 中都能正确读取、触发和执行这些规则。 比如“前端按钮权限不是安全边界”这条规则，到了 JeecgBoot 工单模块里，就会影响新增、编辑、删除、指派、状态变更等按钮设计，也会影响后端接口权限注解和无权限访问验证。 所以第三天讲规则，不是重复第二天，而是把 rules 从静态文档推进到 Agent 工作流的执行边界。 --- ## Slide 1-2：规则资产的演进路径 ### PPT 页面内容 ```Plain Text 规则资产演进： .vscode 统一编辑器和格式化 .cursorrules / .mdc 告诉 AI 项目偏好 .trae/rules/ 按场景拆分规则 AGENTS.md 跨工具共享协作约定 ``` ### 讲师逐字稿 规则资产有一个演进路径。 最早我们用 `.vscode` 统一编辑器、插件、格式化和调试配置。这类配置主要服务人和 IDE。 后来出现 `.cursorrules`、`.mdc` 这类文件，开始把项目偏好告诉 AI。比如用什么框架、什么代码风格、什么测试方式。 再往后是 `.trae/rules/` 这类分层规则目录。它不只是一个大文件，而是可以按前端、后端、安全、测试、交付拆开。 最后是 `AGENTS.md` 这样的跨工具约定。同一个仓库可能被 TRAE、Cursor、Claude Code、Codex 等不同 Agent 读取，跨工具规则可以减少重复维护。 课堂里大家不用纠结哪个文件名更先进，关键是理解：团队规则正在从人读的文档，变成 Agent 能读取和执行的工程资产。 --- ## Slide 1-3：从散装规则到分层规则 ### PPT 页面内容 ```Plain Text .trae/ └── rules/ ├── global.md ├── frontend.md ├── backend.md ├── security.md ├── testing.md └── delivery.md ``` ### 讲师逐字稿 第二天我们写 rules.md v0.1 时，为了课堂统一，先写成一个文件。 真实团队里，如果规则越来越多，一个文件会很快变长，最后没人愿意维护，也很难判断规则什么时候触发。 所以更合理的做法是分层。 `global.md` 放所有任务都必须遵守的规则，比如输出要标注依据、不确定内容要说明、修改前要说明影响范围。 `frontend.md` 放前端页面、api 模块、权限按钮、异常态和防重复提交规则。 `backend.md` 放 Controller、Service、权限注解、事务、参数校验规则。 `security.md` 放密钥、账号、权限、敏感日志、越权风险。 `testing.md` 放测试覆盖要求。 `delivery.md` 放 PR、Review、CI、发布和回滚要求。 --- ## Slide 1-4：规则迁移课堂练习 ### PPT 页面内容 ```Plain Text 练习： 把 Day 2 的 rules.md v0.1 迁移到 JeecgBoot 工单模块 要求： 每组至少迁移 5 条规则 说明目标文件、触发场景、验收方式 ``` ### 讲师逐字稿 这一页开始做第一个课堂练习。 请大家从第二天写的 rules.md v0.1 中挑出至少 5 条规则，把它们迁移到 JeecgBoot 工单模块的分层规则里。 不要只是说“这条放 security.md”。要说明为什么。 比如“前端按钮权限不是安全边界”，它可以放进 `security.md`，因为它本质是安全边界问题；同时也可以在 `frontend.md` 中引用，因为它会影响工单新增、编辑、删除、指派、状态变更等按钮实现方式。 再比如“新增接口调用必须放入 api 模块”，这明显属于 `frontend.md`。在 JeecgBoot 工单模块里，列表、详情、评论、状态变更都应该通过对应 api 文件调用。 每条规则都要写清楚三个信息：目标文件、触发场景、验收方式。 ### 课堂产出 ```md | 原规则 | 目标文件 | 触发场景 | 必须动作 | 验收方式 | |---|---|---|---|---| | 前端按钮权限不是安全边界 | security.md / frontend.md | 工单新增、编辑、删除、指派、状态变更 | 检查后端权限注解 | 标注接口、权限字符和无权限验证 | | 新增接口调用必须放入 api 模块 | frontend.md | 工单列表、详情、评论、状态变更接口 | 新建或复用工单 api 文件 | 页面不直接拼接 URL | ``` --- # 模块 2：Token、Cue 与任务成本 --- ## Slide 2-1：Token 经济学不是省字数 ### PPT 页面内容 ```Plain Text 早期关注： Prompt 越短越好 Token 越省越好 现在关注： 任务边界是否清楚 上下文是否有效 输出是否可验收 返工是否减少 ``` ### 讲师逐字稿 很多人一听 Token 经济学，会以为是教大家怎么把 Prompt 写短。 这不是今天的重点。 企业真正要管的不是一两句话多花了多少 token，而是一次 AI 任务是否减少了返工。 如果任务边界不清楚，AI 反复猜、反复改、反复跑偏，看起来每次调用不贵，但整体成本很高。 如果上下文给得很准，输出格式清楚，验收标准明确，即使单次上下文更长，总体上也可能更省。 所以第三天讲 Token，不是讲个人省字数，而是讲团队如何设计稳定的上下文管道。 --- ## Slide 2-2：JeecgBoot 工单任务的成本差异 ### PPT 页面内容 ```Plain Text 低成本任务： 解释生成代码、生成摘要、补充注释 中成本任务： 拆解需求、审查代码生成结果、生成测试点 高成本任务： 状态流转、权限逻辑修改、审计日志、CI 修复 ``` ### 讲师逐字稿 在 JeecgBoot 项目里，不同任务的 AI 成本差异很大。 解释一段工单列表查询代码，通常只需要 `#Code`，成本低，风险也低。 分析工单列表到详情的完整链路，就需要 `@workspace` 找入口，再用 `#File` 聚焦前端页面、api 文件、Controller 和 Service，成本和复杂度都上升。 如果是修改工单删除、指派或状态流转逻辑，并补权限判断和审计日志，这就是高风险任务。它不仅需要上下文，还需要 Plan、测试和 Review。 所以不能一上来就说“交给 Agent”。要先判断任务类型。 --- ## Slide 2-3：Tab、Cue 与 Agent ### PPT 页面内容 ```Plain Text Tab： 补下一行 Cue： 理解上下文，做更智能的补全和编辑 Agent： 围绕目标执行多步任务 计划、修改、验证、交付 ``` ### 讲师逐字稿 大家可以把 AI 编程能力分成三个层次理解。 第一层是 Tab，也就是早期补全。你写到一半，它补下一行。 第二层是 Cue。Cue 强调上下文理解，不只是补一行，而是理解当前文件、周边代码和意图，给出更完整的建议。 第三层是 Agent。Agent 不只是补代码，而是围绕一个目标执行多步任务：理解需求、找文件、制定计划、修改代码、运行检查、解释结果。 企业培训里最重要的是：不要把这三层混在一起。 解释函数可以用局部能力。跨模块修改必须进入 Agent 工作流。 --- ## Slide 2-4：课堂练习：任务成本与能力匹配 ### PPT 页面内容 ```Plain Text 练习： 判断以下JeecgBoot 工单任务适合哪种能力 解释生成代码 拆解工单需求 审查代码生成结果 修改状态流转 生成 PR 说明 分析 CI 失败日志 ``` ### 讲师逐字稿 现在做第二个课堂练习。 我给大家六个 JeecgBoot 工单任务，请每组判断：它的风险高不高，需要什么上下文，适合用对话、Cue、Command、Skill、Agent Plan 还是 Review。 注意，答案不是唯一的。 比如“审查代码生成结果”可以用 Command，也可以进入 Skill。区别在于：如果只是一次固定格式检查，用 Command 就够；如果要按步骤查字段、查询条件、字典、权限、审计、异常态和测试缺口，那就更像 Skill。 ### 课堂产出 ```md | 任务 | 风险 | 上下文需求 | 推荐能力 | 验收方式 | |---|---|---|---|---| | 解释工单列表查询代码 | 低 | #Code | 对话 / Cue | 能说清输入、输出、异常 | | 拆解工单需求 | 中 | 需求说明 + 项目规则 | Agent 分析 | 有用户故事和验收标准 | | 审查代码生成结果 | 中 | 生成代码 + rules | Command / Skill | 输出代码生成 Review 清单 | | 修改工单状态流转 | 高 | 相关文件 + rules + 测试 | Plan 后执行 | 状态机验证 + Review | | 生成 PR 说明 | 低 | diff | Command | 说明变更、测试、风险 | | 分析 CI 失败日志 | 中 | 日志 + diff | Agent / CLI | 定位原因和修复建议 | ``` --- # 模块 3：从 Commands 到 Skills --- ## Slide 3-1：Commands 解决重复输入 ### PPT 页面内容 ```Plain Text Commands： 把常用话术封装成快捷入口 适合： 固定问法 固定格式 固定检查 固定输出 ``` ### 讲师逐字稿 前两天大家已经写过很多 Prompt。 比如“请拆解 JeecgBoot 工单管理需求”，比如“请审查代码生成结果”，比如“请检查工单删除、指派、状态变更是否有后端权限和审计日志”。 如果这些 Prompt 每次都手打一遍，就会出现两个问题。 第一，容易漏条件。第二，每个人写法不一样，输出不稳定。 Commands 的价值，就是把这些高频、固定、可复用的 Prompt 变成快捷入口。 它适合固定问法、固定格式、固定检查和固定输出。 --- ## Slide 3-2：JeecgBoot 工单适合沉淀哪些 Commands？ ### PPT 页面内容 ```Plain Text 建议沉淀： /模块结构分析 /工单需求拆解 /接口契约生成 /代码生成 Review /操作日志检查 /生成测试点 /生成 PR 说明 ``` ### 讲师逐字稿 结合 JeecgBoot 工单案例，最适合先沉淀这些 Commands。 `/模块结构分析` 用来快速建立模块认知。 `/工单需求拆解` 用来把原始需求拆成用户故事、功能边界、非目标范围和异常场景。 `/接口契约生成` 用来生成工单列表、详情、评论、状态变更等接口契约。 `/代码生成 Review` 用来审查 JeecgBoot 生成的 CRUD 代码是否满足字段、查询、分页、字典、权限和异常态要求。 `/操作日志检查` 用来检查敏感操作是否记录日志。 `/生成测试点` 用来从正常流、异常流、权限流、边界值生成测试清单。 `/生成 PR 说明` 用来把 diff 转成标准 PR 描述。 这些都不是抽象能力，而是 JeecgBoot 工单开发当天会反复使用的任务。 --- ## Slide 3-3：坏 Command 示例 ### PPT 页面内容 ```Plain Text /检查代码 问题： 目标太泛 范围不清 没有输入要求 没有输出格式 没有验收标准 ``` ### 讲师逐字稿 Command 不是随便起个名字就行。 比如 `/检查代码` 就是一个坏 Command。 它的问题和坏 Prompt 一样：目标太泛、范围不清、没有输入要求、没有输出格式、没有验收标准。 AI 看到这个命令，可能检查格式，可能检查 bug，可能检查权限，也可能泛泛说“代码结构清晰”。 这样的 Command 进入团队资产库，反而会制造噪声。 --- ## Slide 3-4：好 Command 示例 ### PPT 页面内容 ```Plain Text /代码生成 Review 输入： 生成的前端页面、api 文件、后端 Controller、Service、rules 输出： 字段一致性、查询条件、分页排序、字典使用、权限按钮、异常态、不确定点 ``` ### 讲师逐字稿 更好的 Command 要明确场景。 比如 `/代码生成 Review`。 它的使用场景是：JeecgBoot 根据工单表生成基础 CRUD 之后，正式进入人工调整前使用。 它的输入包括生成的前端页面、api 文件、后端 Controller、Service、数据表字段和当前 rules。 它的输出必须覆盖字段一致性、查询条件、分页排序、字典枚举、权限按钮、异常态和不确定点。 这样它就不是一句口号，而是可以执行、可以验收的团队资产。 ### 课堂产出 ```md # /代码生成 Review ## 使用场景 JeecgBoot 基于 work_order 表生成工单模块基础代码后使用。 ## 输入 - 数据表字段说明 - 生成的前端页面 - api 模块文件 - 后端 Controller - 后端 Service - 当前 rules ## 执行要求 1. 检查字段是否和数据模型一致 2. 检查查询条件、分页、排序是否完整 3. 检查状态、优先级、类型是否使用字典或枚举 4. 检查新增、编辑、删除、导出按钮是否需要权限控制 5. 检查 loading、empty、error、forbidden 状态是否缺失 6. 标注不确定点 ## 输出格式 | 检查项 | 文件 | 现状 | 问题 | 建议 | 验收 | |---|---|---|---|---|---| ``` --- ## Slide 3-5：Skills 解决完整流程 ### PPT 页面内容 ```Plain Text Command： 封装一句标准化指令 Skill： 封装一套完整工作流 Skill 可以包含： 说明、步骤、模板、脚本、检查清单、示例 ``` ### 讲师逐字稿 Command 解决的是重复输入。 Skill 解决的是完整流程。 比如“代码生成 Review”可以做成 Command，因为它主要是一套固定输出格式。 但“JeecgBoot 工单模块开发审查”更适合做成 Skill，因为它要分步骤执行：先拆需求和接口契约，再审查生成代码，再检查按钮权限、后端接口、操作日志、异常态和测试缺口，最后输出风险与验收建议。 Skill 还可以携带模板、脚本、检查清单和示例。 所以当一个任务需要多步判断、多个输入、多个输出，并且希望团队反复复用时，就应该考虑 Skill。 --- ## Slide 3-6：JeecgBoot 工单模块开发审查 Skill 设计 ### PPT 页面内容 ```Plain Text 课堂任务： 设计一个“JeecgBoot 工单模块开发审查 Skill” 必须包含： 触发场景 输入材料 执行步骤 输出格式 验收标准 ``` ### 讲师逐字稿 现在每组设计一个“JeecgBoot 工单模块开发审查 Skill”。 注意，这里不是让大家写代码，也不是写一个很长的 Prompt。 我们要写的是一张 Skill 设计卡片，让团队知道这个 Skill 在什么情况下触发，需要什么输入，按什么步骤执行，输出什么结果，怎么判断合格。 ### 课堂产出 ```md # JeecgBoot 工单模块开发审查 Skill ## 触发场景 涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。 ## 输入材料 - PR diff 或相关文件 - 工单需求说明 - 数据模型与接口契约 - `.trae/rules.md` - 前端页面文件 - api 模块文件 - 后端 Controller / Service ## 执行步骤 1. 识别需求范围和非目标范围 2. 检查字段、接口契约和页面状态是否完整 3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态 4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限 5. 检查操作日志、数据权限和测试缺口 6. 输出风险、不确定点和验收建议 ## 输出格式 需求拆解表、接口契约表、代码生成 Review 清单、权限风险表、日志风险表、测试缺口清单、不确定点清单。 ## 验收标准 每个关键结论必须标注文件、函数、注解或调用链依据。 ``` --- ## Slide 3-7：MCP 与 CLI 的位置 ### PPT 页面内容 ```Plain Text CLI： 命令稳定、脚本成熟、轻量接入 MCP： 结构化能力描述、交互式工具、平台化接入 Skill： 把使用方法和流程一起交付 ``` ### 讲师逐字稿 MCP 不要讲成抽象技术名词。 企业真正关心的是：Agent 怎么接入已有工具。 如果一个能力已经有稳定命令，比如跑测试、查日志、生成报告，优先用 CLI 封装，简单、直接、可维护。 如果一个能力需要长期连接、交互式操作、结构化描述，比如浏览器、数据库、设计工具、内部平台，那 MCP 更合适。 如果一个能力不只是工具调用，还需要说明、模板、步骤和示例，就适合放进 Skill。 所以 CLI、MCP、Skill 不是互相替代，而是不同层次的封装方式。 ### 课堂产出 ```md | 需求 | 推荐封装 | 理由 | 验收 | |---|---|---|---| | 生成 PR 说明 | Command | 固定格式、低风险 | PR 模板字段完整 | | JeecgBoot 工单模块开发审查 | Skill | 多步骤、多文件、多规则 | 输出风险表和依据 | | 读取 CI 日志 | CLI | 已有命令或 API | 能定位失败阶段 | | 操作浏览器验证页面 | Browser / MCP | 需要点击、输入、截图 | 有截图和步骤记录 | ``` --- # 模块 4：从单 Agent 到 Agent Teams --- ## Slide 4-1：为什么需要多个 Agent？ ### PPT 页面内容 ```Plain Text 单 Agent： 一个助手处理全部任务 SubAgent： 主 Agent 拆出子任务 Agent Teams： 按角色分工协作交付 ``` ### 讲师逐字稿 小任务用一个 Agent 就够了。 比如解释一个函数、生成一个 PR 说明、整理一段测试点，一个 Agent 可以完成。 但任务复杂之后，一个 Agent 很容易同时承担需求分析、代码修改、测试、Review、文档生成等职责，输出会混在一起。 多 Agent 的价值不是“看起来更智能”，而是分工。 就像真实研发团队里有开发、测试、Review、运维一样，Agent 也可以按角色承担不同职责。 --- ## Slide 4-2：JeecgBoot 工单场景中的 Agent 分工 ### PPT 页面内容 ```Plain Text JeecgBoot 工单模块开发审查可以拆成： 代码理解 Agent 规则审查 Agent 测试建议 Agent Review Agent 文档整理 Agent ``` ### 讲师逐字稿 还是看 JeecgBoot 工单管理模块开发与审查。 需求拆解 Agent 负责把原始工单需求拆成用户故事、功能边界和验收标准。 代码生成审查 Agent 负责检查 JeecgBoot 生成的前后端代码是否符合字段、接口、字典和页面状态设计。 测试建议 Agent 负责输出正常流、无权限流、异常流、边界值和状态流转测试点。 Review Agent 负责基于 diff、rules 和测试结果输出问题等级、文件位置、风险解释和修复建议。 文档整理 Agent 负责把过程整理成报告或资产库条目。 这比让一个 Agent 直接“帮我检查一下”更稳定。 --- ## Slide 4-3：Agent 分工表 ### PPT 页面内容 ```Plain Text 每个 Agent 都要定义： 输入 动作 输出 验收 边界 ``` ### 讲师逐字稿 Agent 分工不能只写名字。 比如“测试 Agent”这个名字没有意义。 必须说清楚它的输入是什么，是 diff、需求、接口契约，还是测试报告？ 它的动作是什么，是生成测试点，还是补单测，还是分析失败日志？ 它的输出是什么，是测试清单、测试代码，还是失败原因报告？ 它的验收方式是什么？ 它不能做什么？比如测试 Agent 不应该擅自改业务逻辑。 ### 课堂产出 ```md | Agent | 输入 | 动作 | 输出 | 验收 | 边界 | |---|---|---|---|---|---| | 需求拆解 Agent | 原始需求 | 拆用户故事、边界、异常 | 需求拆解文档 | 有验收标准 | 不直接写代码 | | 代码生成审查 Agent | 生成代码、字段表、rules | 查字段、查询、字典、异常态 | 代码生成 Review 清单 | 能指向文件和问题 | 不直接合入 | | 测试建议 Agent | 需求、diff | 生成测试点 | 测试点清单 | 覆盖正常/异常/权限/状态 | 不替代人工验收 | | Review Agent | PR diff、测试结果 | 审查风险 | Review 报告 | 有等级、位置、建议 | 不替代最终审批 | ``` --- ## Slide 4-4：Trae Solo 的协作信号 ### PPT 页面内容 ```Plain Text Trae Solo 体现的方向： 设计能力 开发能力 部署能力 验证能力 全托管不是无人负责 而是更需要边界和验收 ``` ### 讲师逐字稿 Trae Solo 这类模式，体现的是 Agent 能力从辅助走向全流程执行。 它可能帮助做设计、写代码、部署、验证。 但这里要提醒大家：全托管不是无人负责。 越是全托管，越需要明确边界和验收。 低风险任务可以让 Agent 多做一点，比如整理文档、生成摘要、补测试点。 高风险任务，比如权限、状态流转、工单删除、审计日志、生产缺陷修复，就必须有 Plan、Review 和人工确认。 --- ## Slide 4-5：产品形态分化 ### PPT 页面内容 ```Plain Text Trae IDE： 专业开发者主工作台 Trae Solo： IDE 内全托管 Agent 模式 Trae Work： 面向任务结果 Trae CLI 企业版： 接入 Git、CI、协作平台和内部系统 ``` ### 讲师逐字稿 AI 编程产品会出现不同形态。 IDE 面向专业开发者，适合在代码现场使用。 Solo 面向更完整的任务托管，在 IDE 内完成设计、开发、验证。 Work 更偏任务结果，可能让非专业开发者也能发起需求。 CLI 企业版适合接入 Git、CI、飞书、钉钉、GitLab、GitHub 和内部平台。 这里不是让大家记产品名，而是理解不同入口服务不同场景。 --- ## Slide 4-6：AI 时代付费模式 ### PPT 页面内容 ```Plain Text 免费版： 体验与轻度使用 个人付费版： 高频开发者，更强模型与更多额度 企业版： 团队与组织，权限、合规、审计、私有化、集成 ``` ### 讲师逐字稿 这一页是大家现场已经讲到的位置。 AI 产品和传统互联网产品不太一样，因为每次调用都有真实计算成本。 免费版更多是让用户建立习惯。 个人付费版解决高频开发者的额度和模型能力问题。 企业版真正解决的是团队治理问题：谁能用、怎么用、用什么模型、能不能审计、能不能接内部系统、能不能做权限和合规控制。 所以企业落地 AI 编程，不是简单买账号，而是要把 AI 放进研发流程里治理。 --- ## Slide 4-7：从付费模式转回课堂实操 ### PPT 页面内容 ```Plain Text 讲到付费模式之后，要落回三个问题： 什么任务值得交给 Agent？ 交给哪个 Agent？ 交付后怎么验收？ ``` ### 讲师逐字稿 讲到付费模式之后，不要停留在商业模式。 要把它转回工程问题。 既然每次 AI 调用都有成本，企业版又强调权限、审计和集成，那么团队就必须回答三个问题。 第一，什么任务值得交给 Agent？ 第二，交给哪个 Agent 或哪种能力？ 第三，交付后怎么验收？ 接下来我们就进入浏览器验证、Plan 和 Review，这些都是为了回答第三个问题：Agent 做完之后，怎么证明它做对了。 --- # 模块 5：Browser Preview 与 Browser Use --- ## Slide 5-1：为什么前端任务必须浏览器验证？ ### PPT 页面内容 ```Plain Text 代码通过不等于页面可用 前端至少验证： 页面能打开 主流程可操作 异常态可见 权限态正确 截图可复核 ``` ### 讲师逐字稿 前端任务有一个特点：代码看起来没问题，不代表页面真的可用。 JeecgBoot 工单管理页面也是这样。 列表能不能加载？标题、状态、优先级、指派人筛选有没有生效？重置按钮有没有清空？分页能不能切换？无权限用户是否看不到删除、指派、状态变更按钮？接口失败时页面有没有提示？ 这些不能只靠读代码。 所以第三天要引入 Browser Preview 和 Browser Use。 --- ## Slide 5-2：Browser Preview 与 Browser Use ### PPT 页面内容 ```Plain Text Browser Preview： 人在 IDE 中看页面效果 Browser Use： AI 操作浏览器完成验证 一个服务视觉反馈 一个服务任务验收 ``` ### 讲师逐字稿 Browser Preview 和 Browser Use 要分开。 Preview 是给人看的。它让开发者不用频繁切换窗口，可以在 IDE 里快速看页面。 Browser Use 是给 Agent 执行验证用的。它可以点击、输入、跳转、提交表单、截图，帮助完成流程验证。 一个服务视觉反馈，一个服务任务验收。 企业前端研发里，这两者都很有价值。 --- ## Slide 5-3：JeecgBoot 工单管理页面验证项 ### PPT 页面内容 ```Plain Text 工单列表/详情页面验证： 打开页面 按标题查询 按状态筛选 重置条件 分页切换 新增/修改/删除/指派/状态变更按钮权限 无权限访问 接口失败提示 ``` ### 讲师逐字稿 还是以 JeecgBoot 工单管理页面为例。 浏览器验证不要写成“页面正常”。 要拆成具体动作。 打开页面，页面是否加载成功。 输入工单标题查询，列表是否刷新。 选择状态或优先级筛选，结果是否符合条件。 点击重置，查询条件是否清空。 切换分页，列表是否变化。 不同角色账号访问时，新增、修改、删除、指派、状态变更、导出按钮是否按权限显示。 无权限用户直接请求接口，是否返回 403。 接口失败时，页面是否有错误提示。 这些才是可执行的 Browser 验证。 ### 课堂产出 ```md | 步骤 | 操作 | 预期结果 | 证据 | 备注 | |---|---|---|---|---| | 1 | 打开工单列表/详情页面 | 页面正常加载 | 截图 | 记录 URL | | 2 | 输入工单标题查询 | 列表按条件刷新 | 截图/接口 | 记录查询参数 | | 3 | 按状态、优先级筛选 | 结果符合筛选条件 | 截图/接口 | 记录筛选参数 | | 4 | 点击重置 | 查询条件清空 | 截图 | 检查默认值 | | 5 | 无权限账号查看删除/指派按钮 | 按钮不可见或接口 403 | 截图/响应 | 不能只看前端 | ``` --- ## Slide 5-4：浏览器驱动的三条路线 ### PPT 页面内容 ```Plain Text Playwright： 稳定、可复现，适合自动测试 Agent Browser： 集成度高，适合复杂网页任务 指针模拟： 接近真人操作，适合临时验证 ``` ### 讲师逐字稿 浏览器驱动有几条路线。 Playwright 适合工程化测试，稳定、可复现，适合进入 CI。 Agent Browser 更偏专用环境，集成度高，适合复杂网页任务。 指针模拟更接近真人操作，适合临时视觉验证。 课堂里不用深入实现细节，大家先理解能力边界。 真正落地时，稳定流程优先 Playwright，临时验证可以用 Browser Use。 --- ## Slide 5-5：代码库索引的两种路线 ### PPT 页面内容 ```Plain Text 向量化索引： 语义搜索强，适合大仓库概念查找 关键词搜索： 实时、可解释，适合定位文件和函数 结论必须回到文件、函数、调用点 ``` ### 讲师逐字稿 Agent 要理解代码，离不开代码库索引。 向量化索引适合语义搜索，比如“不知道权限在哪里，但想找权限相关逻辑”。 关键词搜索适合精确定位，比如搜 `queryById`、`工单按钮权限`、`@PreAuthorize`。 两种路线都有价值。 但无论用哪种，最终结论必须回到文件、函数和调用点。 这也是第一天反复强调的：AI 输出必须有依据。 --- ## Slide 5-6：Markdown 是 AI 时代的一等文档格式 ### PPT 页面内容 ```Plain Text Markdown 的价值： 结构清楚 易读写 可 diff 可版本管理 可转换 ``` ### 讲师逐字稿 前两天的产物，包括代码理解报告、rules、检查清单、Prompt 模板，本质上都适合用 Markdown 保存。 原因很简单：结构清楚、容易读写、可以 diff、可以版本管理，也方便转换成 Word、PDF、网页或知识库。 AI 最擅长处理结构化文本。 所以企业资产库建议先用 Markdown 管核心内容，再按需要转换格式。 --- ## Slide 5-7：水合与脱水 ### PPT 页面内容 ```Plain Text 脱水： 从 Word、PPT、PDF 抽出结构和模板 生成： 用 Markdown 生产正文 水合： 把 Markdown 注入目标格式 ``` ### 讲师逐字稿 这里讲一个实用概念：水合与脱水。 复杂格式文档，比如 Word、PPT、PDF，不适合让 AI 直接自由编辑。 更稳定的流程是先脱水：从旧文档里抽出结构、模板、样式要求。 然后生成：让 AI 用 Markdown 写正文。 最后水合：把 Markdown 内容注入模板，输出 Word、PPT 或 PDF。 这套思路对后续课程资产库建设也很重要。 --- # 模块 6：Plan、Review 与第三天交付验收 --- ## Slide 6-1：Agent 参与度光谱 ### PPT 页面内容 ```Plain Text 纯手工 AI Copilot 辅助 手动触发全托管 Loops 全托管 参与度越高 越需要清楚的边界和验收 ``` ### 讲师逐字稿 Agent 参与研发有一个光谱。 最左边是纯手工，人自己写。 再往右是 Copilot 辅助，AI 补全、解释、给建议。 再往右是手动触发全托管，人给目标，AI 执行。 最右边是 Loops 全托管，AI 自主循环，人主要负责审阅。 越往右，AI 参与度越高，人越不能只靠感觉管理。 必须有边界、计划、验证和 Review。 --- ## Slide 6-2：Plan 模式 ### PPT 页面内容 ```Plain Text Plan 阶段： 理解目标 划定范围 列出步骤 标注风险 执行阶段： 修改文件 运行检查 汇报 diff 给出验证结果 ``` ### 讲师逐字稿 Plan 模式本质上是把“想清楚再动手”显性化。 高风险任务不要让 Agent 直接改代码。 比如修改工单删除逻辑、调整权限判断、修改数据权限过滤、修复生产缺陷，都应该先进入 Plan。 Plan 里要写清目标、范围、不做什么、涉及文件、步骤、风险、验证方式。 人审过 Plan，再让 Agent 执行。 这样可以减少误改和返工。 --- ## Slide 6-3：JeecgBoot 高风险任务 Plan 模板 ### PPT 页面内容 ```Plain Text 示例任务： 调整工单管理删除逻辑 Plan 必须写清： 目标、范围、不做什么、步骤、风险、验证 ``` ### 讲师逐字稿 我们用一个JeecgBoot 工单任务举例：调整工单管理删除逻辑。 这个任务看起来只是删除工单，但它实际涉及前端按钮、api 调用、后端接口、权限注解、操作日志、数据权限、异常处理和测试。 所以必须先写 Plan。 ### 课堂产出 ```md # Plan：工单管理删除逻辑调整 ## 目标 检查并补齐工单删除逻辑中的权限校验、操作日志和异常处理。 ## 范围 - 工单列表/详情页面删除按钮 - 工单 api 模块 - 工单删除 Controller 接口 - 工单 Service 删除逻辑 - 权限注解和操作日志 ## 不做什么 - 不调整角色模型 - 不修改数据库结构 - 不修改无关页面 ## 修改步骤 1. 定位前端删除按钮和权限字符 2. 定位删除 API 调用 3. 定位后端删除接口 4. 检查权限注解 5. 检查操作日志 6. 补充异常处理或测试建议 ## 风险点 权限绕过、误删、日志缺失、数据权限遗漏。 ## 验收方式 正常删除、无权限删除、非法参数、重复提交、日志记录。 ``` --- ## Slide 6-4：自动 Review 的输入输出 ### PPT 页面内容 ```Plain Text 输入： PR diff、项目 rules、测试结果、历史问题 输出： 风险点、规则命中、测试缺口、回归提醒 验收： 有文件、有行号、有原因、有建议 ``` ### 讲师逐字稿 Review Agent 不能只说“代码不错”。 自动 Review 必须结构化。 输入包括 PR diff、项目 rules、测试结果和历史问题。 输出包括风险点、规则命中、测试缺口和回归提醒。 每个问题都要能落到文件、行号、规则、风险解释和修复建议。 如果证据不足，要写不确定点，而不是猜。 ### 课堂产出 ```md # AI Review 报告 ## Review 输入 - PR diff： - 相关 rules： - 测试结果： - 业务背景： ## 问题清单 | 等级 | 文件 | 问题 | 触发规则 | 风险 | 建议 | 测试 | |---|---|---|---|---|---|---| | P1 | WorkOrderController.java | 删除接口缺少权限校验 | 敏感接口必须检查后端权限 | 可能绕过前端删除工单 | 增加权限注解 | 无权限账号请求返回 403 | ## 不确定点 列出缺少代码、日志或业务依据的结论。 ## 是否建议合入 通过 / 暂缓 / 阻断，并说明原因。 ``` --- ## Slide 6-5：最后 30 分钟交付验收会 ### PPT 页面内容 ```Plain Text 最后 30 分钟： 整理第三天资产 小组互评 补验收标准 选出可进入资产库的版本 ``` ### 讲师逐字稿 第三天最后也要像第二天一样做交付验收会。 不要只停在概念总结。 每组至少拿出三类材料：一个 Command，一个 Skill 设计卡片，一个 Plan 或 Review 模板。 然后小组之间交叉 Review。 Review 的标准仍然是：是否有触发场景，是否有输入要求，是否有执行步骤，是否有输出格式，是否有验收方式。 最后选出可以进入团队资产库的版本。 ### 课堂安排 ```md | 时间 | 动作 | 输出 | |---|---|---| | 8 分钟 | 整理一个 JeecgBoot 工单 Command | Command 模板 | | 8 分钟 | 设计一个 JeecgBoot 工单 Skill | Skill 设计卡片 | | 6 分钟 | 补一个 Plan 或 Review 模板 | Plan / Review 模板 | | 5 分钟 | 小组互评 | 改写建议 | | 3 分钟 | 选入资产库候选 | 候选资产 | ``` --- ## Slide 6-6：第 3 天交付物 ### PPT 页面内容 ```Plain Text 第 3 天交付物： 01 规则迁移清单 02 任务成本与能力匹配表 03 Command 模板 04 Skill 设计卡片 05 CLI / MCP / Skill 封装决策表 06 Agent 分工表 07 Browser 验证清单 08 Plan 与 Review 模板 ``` ### 讲师逐字稿 第三天最终交付八个产物。 第一，规则迁移清单。把第二天的 rules.md v0.1 拆成分层规则。 第二，任务成本与能力匹配表。判断不同任务适合哪种 AI 能力。 第三，Command 模板。把高频 Prompt 变成快捷入口。 第四，Skill 设计卡片。把完整流程封装成团队能力。 第五，CLI、MCP、Skill 封装决策表。判断不同工具和任务如何接入 Agent。 第六，Agent 分工表。明确代码理解、规则审查、测试建议、Review、文档整理等角色的输入输出。 第七，Browser 验证清单。让前端改动有可复核的验收记录。 第八，Plan 与 Review 模板。让高风险任务先计划、后执行、再审查。 这些材料共同构成第三天的 Agent 工作流资产草案 v0.1。 --- ## Slide 6-7：交付物验收标准 ### PPT 页面内容 ```Plain Text 验收标准： 能复用 能触发 能执行 能验证 能进入资产库 ``` ### 讲师逐字稿 第三天的交付物，也要有验收标准。 能复用：不是一次性聊天记录，下个 JeecgBoot 类后台项目能改名继续用。 能触发：写清楚什么场景使用，不是泛泛的“检查一下”。 能执行：有输入、有步骤、有输出格式。 能验证：有验收标准、有证据要求、有不确定点处理。 能进入资产库：命名清楚，版本清楚，适合放进团队 `ai-dev-assets` 目录。 ### 验收表 ```md | 交付物 | 通过标准 | |---|---| | 规则迁移清单 | 每条规则有目标文件、触发场景、验收方式 | | Command 模板 | 有使用场景、输入、执行要求、输出格式 | | Skill 设计卡片 | 有触发场景、输入材料、步骤、输出、验收 | | Browser 验证清单 | 覆盖页面打开、主流程、权限态、异常态、证据 | | Plan 模板 | 有目标、范围、不做什么、步骤、风险、验证 | | Review 模板 | 有等级、文件、规则、风险、建议、测试 | ``` --- ## Slide 6-8：三天课程闭环 ### PPT 页面内容 ```Plain Text 第 1 天： 读得懂 第 2 天： 问得准、查得实 第 3 天： 封装得住、验收得了、接得上流程 最终能力： 从单次使用 TRAE 到团队级 Agent 工作流 ``` ### 讲师逐字稿 到第三天结束，前三天形成一个闭环。 第一天解决“读得懂”。拿到一个陌生代码库，能让 TRAE 帮我们看结构、找入口、追链路、查依据。 第二天解决“问得准、查得实”。通过上下文工程、幻觉控制、rules 和资产化，让 TRAE 输出更稳定、更可复核。 第三天解决“封装得住、验收得了、接得上流程”。把常用 Prompt 封装成 Command，把复杂流程封装成 Skill，把前端结果交给 Browser 验证，把高风险任务放进 Plan 和 Review。 这就是从个人使用 AI 工具，升级到团队级 Agent 工作流。 --- # 第 3 天最终资产目录建议 ```Plain Text ai-dev-assets/ ├── rules/ │ ├── global.md │ ├── frontend.md │ ├── backend.md │ ├── security.md │ ├── testing.md │ └── delivery.md ├── commands/ │ ├── 模块结构分析.command.md │ ├── 工单需求拆解.command.md │ ├── 接口契约生成.command.md │ ├── 代码生成Review.command.md │ └── PR说明生成.command.md ├── skills/ │ └── JeecgBoot 工单模块开发审查.skill.md ├── templates/ │ ├── Plan任务模板.md │ ├── AIReview报告模板.md │ └── Browser验证报告模板.md ├── checklists/ │ ├── 任务成本与能力匹配表.md │ ├── Agent分工表.md │ └── CLI-MCP-Skill封装决策表.md └── examples/ ├── 好Command与坏Command对照.md ├── 好Skill与坏Skill对照.md └── 好Plan与坏Plan对照.md ``` ## 讲师收束话术 第三天的重点不是让大家记住更多名词。 Commands、Skills、MCP、Browser、Plan、Review，这些词如果孤立看，容易变成产品功能介绍。 但放回JeecgBoot 工单案例里，它们其实是一条很清楚的线： 高频问法沉淀成 Command。 复杂流程沉淀成 Skill。 外部系统通过 CLI 或 MCP 接入。 前端结果通过 Browser 验证。 高风险任务先 Plan，再执行。 代码进入 PR 前后，用 Review 模板检查。 最终沉淀进团队资产库。 这就是第三天要带走的能力：不是会点更多按钮，而是能把 AI 编程能力组织成团队可复用的研发流程。