smart
1548 lines
42 KiB
Markdown
1548 lines
42 KiB
Markdown
# 第 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 编程能力组织成团队可复用的研发流程。
|