docs: 更新TRA编程培训课程材料、课件与AI技能交付包

- 新增全套考试卷、评估卷、参考答案与考试培训包模板 - 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象 - 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求 - 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块 - 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语 - 新增考试输出模板与TRAE使用记录文档
2026-08-08 11:00:36 +08:00
parent e7d6db93c3
commit 67837df8d0
169 changed files with 6618 additions and 2887 deletions
@@ -57,7 +57,7 @@ AI 辅助开发最常见的问题，是先让它把 CRUD 做出来，再问“

 # RBAC 权限矩阵

-<div class="mt-5 text-xs">
+<div class="mt-3 text-[11px] leading-tight">

 | 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
 |---|---|---|---|---|---|
@@ -159,3 +159,35 @@ AI 很容易把权限理解成“有没有按钮”，但企业系统真正的
 课堂里可以让学员拿这张表去追问 TRAE：这个权限风险在哪个文件、哪个接口、哪个测试账号可以验证。
 这样权限矩阵就不是一张漂亮表，而是 Review 和验收的入口。
 -->
+
+---
+
+# 可直接复制到 rules：权限安全
+
+<div class="mt-5 text-xs">
+
+```md
+## 敏感操作必须四层校验
+- 级别：硬约束
+- 适用场景：新增、编辑、删除、指派、状态流转、查看审计、查看看板。
+- 必须：同时覆盖页面/菜单权限、按钮权限、后端接口权限、数据范围权限。
+- 禁止：只做页面或按钮控制。
+- 验收方式：授权角色能完成；未授权角色前端不可见且直接请求接口失败；越权数据访问失败。
+
+## 权限字符必须有来源或标记为建议
+- 必须：来自现有菜单、权限配置、前端权限指令、后端鉴权注解或团队规范。
+- 禁止：凭空编造权限字符并当成事实。
+- 验收方式：权限字符在前端、菜单配置、后端接口之间一致。
+
+## 数据权限不得被查询条件替代
+- 必须：后端统一校验当前用户可访问的数据范围。
+- 禁止：只依赖前端传入 userId、deptId、tenantId 或筛选条件。
+```
+
+</div>
+
+<!--
+这页把交付包里的 security-permission 规则压缩成课堂可直接使用的版本。
+重点不是让学员背规则，而是让他们知道第四天的权限实操必须写进 rules，并且每条 rules 都要有适用场景、必须、禁止和验收方式。
+后续权限矩阵、权限控制方案和阶段 Review 都要回到这几条规则。
+-->
@@ -102,3 +102,28 @@ work:order:dashboard
 课堂实操时，不要求只看代码。
 要用不同账号或模拟请求验证：前端不可见只是第一步，后端拒绝才是强制边界。
 -->
+
+---
+
+# rules 要落到这些位置
+
+<div class="mt-5 text-sm">
+
+| rule 条款 | 代码落点 | 验证项 |
+|---|---|---|
+| 四层校验 | 菜单配置、按钮权限、Controller、Service 查询 | 无权限账号不可见且接口失败 |
+| 权限字符有来源 | 菜单表、路由、按钮指令、后端注解 | 同一字符贯穿前后端 |
+| 数据权限后端校验 | 列表、详情、导出、看板查询 | 改请求参数不能越权 |
+| 敏感字段最小返回 | 列表接口、详情接口、审计展示 | 不暴露不必要 old/new value |
+
+</div>
+
+<div class="mt-4 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+让 TRAE 改权限前，先把相关 rule 和权限控制方案一起给它。
+</div>
+
+<!--
+这页解决一个常见问题：rules 写了，但代码生成时没有真正用上。
+课堂实操时，可以要求学员在提示词里同时附上当前项目 rules、权限矩阵和权限控制方案。
+这样 TRAE 在修改前端按钮、后端接口、查询条件和审计展示时，有明确约束。
+-->
@@ -89,3 +89,31 @@ POST /workOrder/transition
 指派和状态流转建议有明确接口。
 Service 层负责读取工单、校验权限、校验状态、更新状态、记录日志。
 -->
+
+---
+
+# 可直接复制到 rules：状态流转
+
+<div class="mt-5 text-xs">
+
+```md
+## 复杂业务状态必须先建模
+- 级别：硬约束
+- 适用场景：工单指派、处理、验证、驳回、关闭、重开。
+- 必须：先产出状态流转表，列出当前状态、动作、目标状态、允许角色、前置条件、后置动作和验收方式。
+- 禁止：直接在代码中堆状态判断而没有状态表。
+- 验收方式：每个状态动作都有合法路径和非法路径验证。
+
+## 非法状态流转必须拒绝且状态不变
+- 必须：集中校验非法流转；失败时返回明确错误，业务状态不变，不写成功审计。
+- 禁止：仅靠前端禁用按钮防止非法流转。
+- 验收方式：构造非法状态动作，接口失败且数据库状态不变。
+```
+
+</div>
+
+<!--
+这页把 state-audit 里的状态规则放到状态机模块。
+它的作用是提醒学员：状态表不是一次性课堂表格，而是后续开发和 Review 都要引用的团队规则。
+尤其是“非法流转状态不变、不写成功审计”，这是复杂业务上线前必须验证的底线。
+-->
@@ -93,3 +93,31 @@
 状态更新成功但日志失败，或者日志成功但状态失败，都会造成追溯问题。
 所以 Service 层要明确事务边界。
 -->
+
+---
+
+# 可直接复制到 rules：审计日志
+
+<div class="mt-5 text-xs">
+
+```md
+## 关键业务操作必须写审计
+- 级别：硬约束
+- 适用场景：创建、编辑关键字段、指派、状态流转、驳回、关闭、删除、导出、权限变更。
+- 必须：记录 actor、action、target_id、old_value、new_value、source、request_id、created_at 或项目等价字段。
+- 禁止：只记录普通日志而没有业务审计；操作失败后写成功审计。
+- 验收方式：执行关键操作后可查询审计记录，字段与实际变更一致。
+
+## 审计和业务写入必须一致
+- 必须：明确审计写入时机、事务关系、失败处理和重试策略。
+- 禁止：业务成功审计丢失，或审计成功但业务失败。
+- 验收方式：模拟业务失败和审计失败，结果符合一致性策略。
+```
+
+</div>
+
+<!--
+审计规则要比“记录日志”具体得多。
+课堂里可以让学员检查：有没有 old/new value，有没有 request_id 或来源，有没有失败行为说明，事务失败时审计和业务数据是否一致。
+如果这些说不清，审计日志就不能作为上线后的追溯依据。
+-->
@@ -88,3 +88,33 @@
 异常态修复很容易扩散。
 课堂里要控制边界：只补工单模块相关前端状态、后端校验、Service 状态保护和审计日志。
 -->
+
+---
+
+# 可直接复制到 rules：异常态测试
+
+<div class="mt-5 text-xs">
+
+```md
+## 核心逻辑必须有测试或豁免说明
+- 级别：待确认约束
+- 适用场景：权限校验、状态流转、审计、看板指标、异常态修复。
+- 必须：优先补自动化测试；无法测试时说明原因、风险和手工验收方式。
+- 禁止：只说“已验证”但没有命令、样例、截图、接口响应或手工步骤。
+
+## 权限必须做正反角色验证
+- 必须：至少验证一个授权角色和一个未授权角色；涉及数据范围时验证越权数据。
+- 禁止：只用管理员账号验证。
+
+## 状态流转必须覆盖合法和非法路径
+- 必须：每个关键动作至少覆盖一条合法路径和一条非法路径。
+- 禁止：只测试从初始状态到成功终态的主链路。
+```
+
+</div>
+
+<!--
+异常态规则放在这里，是因为很多团队会把“测试”理解成正常流程跑通。
+第四天必须把测试规则写进 rules：权限要正反角色，状态要合法非法路径，不能只用管理员账号看页面。
+如果没有自动化测试，也必须给出手工验收证据。
+-->
@@ -93,3 +93,31 @@ GET /workOrder/dashboard/trend
 看板页面不是能打开就算完成。
 验收要看权限、口径、空态和数字是否能解释。
 -->
+
+---
+
+# 可直接复制到 rules：看板指标
+
+<div class="mt-5 text-xs">
+
+```md
+## 看板指标必须手工抽样校验
+- 级别：硬约束
+- 适用场景：统计卡片、趋势图、分布图、排行、效能指标。
+- 必须：每个关键指标有含义、公式、过滤条件、时间字段、数据范围，并用样例数据手工校验。
+- 禁止：只验证接口返回 200 或页面有图表。
+- 来源证据：指标字典、接口契约、样例数据、数据库查询或列表数据。
+- 验收方式：至少一组样例数据的手工计算结果与接口返回一致。
+```
+
+</div>
+
+<div class="mt-4 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
+看板交付时要同时交付指标字典、接口契约和一组手工核对样例。
+</div>
+
+<!--
+这页把看板从“图表开发”拉回“指标开发”。
+企业看板最怕数字说不清来源，尤其是平均关闭周期、待处理数量、趋势图这类指标。
+所以规则要求公式、过滤条件、时间字段、数据范围和样例核对都必须齐全。
+-->
@@ -2,7 +2,7 @@

 <div class="mt-6 text-sm">

-第四天改动涉及权限、状态、审计、异常和看板，必须做阶段 Review。
+工单模块改动涉及权限、状态、审计、异常和看板，必须做阶段 Review。

 </div>

@@ -45,6 +45,61 @@ AI Review 不能只给 diff。

 ---

+# 复杂业务控制面的三个 Skill
+
+<div class="mt-5 text-xs">
+
+| Skill | 什么时候用 | 输入材料 | 输出产物 |
+|---|---|---|---|
+| design-complex-business-module | 开始写代码前 | 需求、项目规则、现有角色/API/表结构 | RBAC、权限方案、状态表、审计 SOP、异常清单、指标字典 |
+| review-business-delivery | 阶段 Review 时 | diff、业务产物、测试结果、验收记录 | 问题清单、证据缺口、待确认项 |
+| track-review-fix-loop | 修 Review 后 | Review 报告、修改文件、验证证据 | 修复记录、未闭环事项、资产更新建议 |
+
+</div>
+
+<div class="mt-4 p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-sm">
+Skill 负责流程和质量门禁；rule 负责长期约束；template/checklist 负责稳定输出。
+</div>
+
+<!--
+这里把 Skill 放在阶段 Review 前后承接处。
+前三天讲过 Skill 的概念，第四天要让学员看到具体怎么用。
+design-complex-business-module 用在开工前，review-business-delivery 用在阶段审查，track-review-fix-loop 用在修复闭环。
+这三个 Skill 串起来，正好覆盖复杂业务从设计、审查到沉淀资产的全过程。
+-->
+
+---
+
+# design-complex-business-module 怎么用
+
+<div class="mt-5 text-xs">
+
+```md
+请使用 design-complex-business-module，基于 JeecgBoot 工单模块设计复杂业务控制面。
+
+输入材料：
+1. 需求范围：工单权限、状态流转、审计、异常态、看板。
+2. 项目规则：security-permission、state-audit、testing、delivery。
+3. 现有证据：角色、菜单权限、接口、数据表、相似模块。
+
+输出必须包含：
+RBAC 权限矩阵、权限控制方案、状态流转表、非法流转清单、
+审计日志 SOP、异常态清单、看板指标字典、看板接口验收记录。
+
+要求：
+没有源码或配置证据的内容标记为“建议”或“待确认”。
+```
+
+</div>
+
+<!--
+这个 Skill 的重点是“先设计控制面，再设计代码”。
+它不是让 AI 直接写实现，而是先把权限、状态、审计、异常态、看板和验收资产凑齐。
+课堂里可以让学员用它生成第一版产物，再由主讲人结合已读源码补业务确认。
+-->
+
+---
+
 # 阶段 Review 报告

 <div class="mt-5 text-xs">
@@ -65,6 +120,36 @@ Review 输出必须结构化。

 ---

+# review-business-delivery 怎么用
+
+<div class="mt-5 text-xs">
+
+```md
+请使用 review-business-delivery 对本次工单模块改动做阶段 Review。
+
+输入材料：
+- 当天 diff 或修改文件清单
+- RBAC 权限矩阵和权限控制方案
+- 状态流转表和非法流转清单
+- 审计日志 SOP 和异常态清单
+- 看板指标字典和接口验收记录
+- 测试命令、接口响应、浏览器验证或手工验收记录
+
+输出格式：
+先列问题清单，按 P0/P1/P2/P3 排序；
+每个问题必须有证据、风险、修复建议和验收方式；
+缺少证据时单独列“证据缺口”，不要猜测。
+```
+
+</div>
+
+<!--
+Review Skill 的作用是防止 AI 只做代码风格点评。
+第四天 Review 必须把业务产物和代码 diff 一起看，否则无法判断权限是否闭环、状态是否非法、审计是否可查、指标口径是否正确。
+-->
+
+---
+
 # 修复记录

 <div class="mt-5 text-xs">
@@ -84,7 +169,38 @@ Review 不是结束。

 ---

-# 第 4 天交付物
+# track-review-fix-loop 怎么用
+
+<div class="mt-5 text-xs">
+
+```md
+请使用 track-review-fix-loop，把阶段 Review 问题转成修复闭环记录。
+
+输入材料：
+- 带编号的 Review 报告
+- 修改文件或产物
+- 测试输出、接口响应、浏览器截图或手工验收步骤
+- 现有 rules、checklists、prompts、examples、skills 目录
+
+每个问题状态只能是：
+成立-已修复 / 成立-暂不修复 / 不成立 / 需确认 / 未闭环
+
+输出必须包含：
+修复记录、未闭环事项、资产更新建议。
+资产类型从 rule、checklist、prompt、command、skill、example 中选择。
+```
+
+</div>
+
+<!--
+修复闭环 Skill 对应第四天最后的资产沉淀。
+它要求每个问题不能只写“已修复”，必须有证据和状态。
+如果问题反复出现，例如权限绕过、非法状态流转、审计缺失，就要判断是否沉淀为 rule、checklist、prompt、example 或新的 Skill。
+-->
+
+---
+
+# 复杂业务模块资产

 <div class="grid grid-cols-2 gap-3 mt-6 text-sm">
 <div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30">01 工单 RBAC 权限矩阵</div>
@@ -104,12 +220,47 @@ Review 不是结束。
 这些产物共同说明：工单模块不只是能运行，还具备权限、状态、审计、异常和指标的工程闭环。
 -->

+---
+
+# 复杂业务资产包目录
+
+<div class="mt-5 text-xs">
+
+```text
+ai-dev-assets/
+├── rules/
+│   ├── security-permission.md
+│   ├── state-audit.md
+│   ├── testing.md
+│   └── delivery.md
+├── skills/
+│   ├── design-complex-business-module/
+│   ├── review-business-delivery/
+│   └── track-review-fix-loop/
+├── templates/jeecgboot/
+├── checklists/jeecgboot/
+├── prompts/jeecgboot/
+└── examples/jeecgboot/
+```
+
+</div>
+
+<div class="mt-4 p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-sm">
+交付给团队的不是聊天记录，而是可安装、可复用、可审查的工程资产包。
+</div>
+
+<!--
+这一页把第四天的 rule 和 Skill 落到目录结构。
+rules 是长期约束，skills 是可触发流程，templates/checklists/prompts/examples 是 Skill 会调用的材料。
+这样学员能把课堂产物带回团队，而不是停留在一次性演示。
+-->
+
 ---
 layout: center
 class: text-center
 ---

-# 第 4 天总结
+# 复杂业务模块的控制面

 <div class="mt-8 text-lg">
 让工单模块从“能跑通”升级到“可控制、可审计、可验证、可 Review”。