feat：update 3 4

cases/jeecgboot-work-order/instructor-guide.md

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