5.2 KiB
5.2 KiB
讲师手册
授课定位
本案例不是 JeecgBoot 功能讲解课,也不是代码生成演示。它训练的是学员如何用 TRAE 在真实后台项目中建立可靠上下文,控制 AI 输出质量,并把复杂业务拆成可验证的工程产出。
讲师要反复强调三点:
- 先让 TRAE 找依据,再让它下结论。
- 工单模块是教学案例,不代表当前 JeecgBoot 源码已经实现了完整工单。
- 复杂业务不能从“写代码”开始,要从权限、状态、审计、异常态和验收开始。
2 小时版本
适合放在第 3 天或第 4 天中间,作为一个集中演练。
| 时间 | 内容 | 讲师动作 | 学员产出 |
|---|---|---|---|
| 10 分钟 | 案例介绍 | 打开 README.md,说明任务边界 | 明确非目标 |
| 20 分钟 | 项目地图 | 带读 source-map.md,演示如何问 TRAE 找依据 | 源码依据记录表 |
| 25 分钟 | 需求拆解 | 使用 prompts.md 的需求拆解 Prompt | 需求拆解表 |
| 25 分钟 | 权限与状态 | 分组生成 RBAC 权限矩阵和状态流转表 | 权限矩阵、状态流转表 |
| 20 分钟 | 审计与异常态 | 让学员列出必须记录和必须防御的场景 | 审计表、异常态清单 |
| 15 分钟 | Review | 用 acceptance-checklist.md 做小组互评 | Review 记录 |
| 5 分钟 | 收束 | 指向 assets-index.md | 课后资产列表 |
半天版本
适合完整覆盖第 3 天后半段或第 4 天前半段。
| 模块 | 时长 | 重点 |
|---|---|---|
| 项目地图和上下文包 | 40 分钟 | 学员必须从 JeecgBoot 实际路径中提取依据 |
| 工单需求和接口契约 | 50 分钟 | 输出字段、接口、页面状态、异常状态 |
| RBAC 权限和状态机 | 60 分钟 | 先做矩阵和流转表,再谈实现计划 |
| 审计、异常态、看板 | 50 分钟 | 把复杂业务补齐,而不是停在 CRUD |
| Review 和交付验收 | 30 分钟 | 要求每组展示“依据、设计、风险、验收” |
1 天版本
适合企业内部二开训练。上午做理解和设计,下午做修改计划和 Review。
| 阶段 | 时间 | 任务 |
|---|---|---|
| 上午 1 | 60 分钟 | 读 JeecgBoot 项目知识库和源码定位图 |
| 上午 2 | 90 分钟 | 工单需求拆解、接口契约、页面状态 |
| 上午 3 | 60 分钟 | 权限矩阵、状态流转、非法流转 |
| 下午 1 | 60 分钟 | 审计日志、异常态、防重复提交 |
| 下午 2 | 60 分钟 | 研发效能看板指标设计 |
| 下午 3 | 60 分钟 | 修改计划、测试点、Review 报告 |
| 下午 4 | 30 分钟 | 小组展示和资产沉淀 |
演示路径
- 打开
../../../JeecgBoot/docs/project-knowledge/README.md,说明项目知识库的阅读顺序。 - 打开
../../../JeecgBoot/jeecg-boot/CLAUDE.md,强调后端二开约束和修改痕迹规则。 - 打开
../../../JeecgBoot/jeecgboot-vue3/CLAUDE.md,强调前端路由、Pinia、API 层和 alias 约定。 - 打开 source-map.md,说明课堂只使用已定位路径,不接受泛泛总结。
- 打开 prompts.md,现场复制一个“项目理解 Prompt”,要求 TRAE 输出依据、推断、建议和不确定点。
- 打开 worksheets.md,示范如何把 TRAE 输出转成课堂交付物。
讲师提醒
- 当学员直接问“帮我写工单模块”时,要让他们退回 worksheets.md 的上下文包。
- 当 TRAE 输出没有文件路径时,要要求补充“依据文件、函数、接口、配置”。
- 当学员只做列表 CRUD 时,要追问权限、状态流转、审计、异常态和验收。
- 当学员想让 TRAE 决定角色权限时,要提醒:角色权限是业务事实,TRAE 只能生成初稿。
- 当学员要改后端代码时,要提醒
update-begin/update-end注释规则。 - 当学员要改前端代码时,要提醒复用项目已有组件、请求层、路由和权限方法。
常见翻车点
| 问题 | 表现 | 讲师处理 |
|---|---|---|
| 上下文过泛 | TRAE 输出 JeecgBoot 通用介绍 | 要求先填源码依据记录表 |
| 直接写代码 | 没有权限矩阵和状态表 | 打回到需求和设计阶段 |
| 权限只隐藏按钮 | 后端接口没有权限边界 | 要求列页面级、按钮级、接口级控制 |
| 状态靠口头约定 | 没有非法流转清单 | 要求列出允许流转和拒绝流转 |
| 审计字段太少 | 只记录操作人和时间 | 补字段前后值、动作、来源、请求 ID |
| 看板指标不可算 | 没有口径、维度和过滤条件 | 要求补指标口径和数据来源 |
| Review 只说“没问题” | 没有证据和风险 | 用 acceptance-checklist.md 逐项检查 |
收束话术
今天这个案例的重点不是让大家记住 JeecgBoot 某个目录,而是掌握一套可迁移的方法:拿到真实项目后,先建立项目地图,再组织上下文,再让 TRAE 基于证据输出设计和计划。只要任务涉及权限、状态、审计、异常态和看板,就不能从“写代码”开始。真正可交付的 AI 协作,是每一步都有依据、每个设计都有验收、每个不确定点都被标出来。