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