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
@@ -387,6 +387,59 @@ AI 可以帮助我们补漏，比如提醒我们“导出”“查看审计记

 ---

+## Slide 1-5：可直接复制到 rules：权限安全
+
+### PPT 页面内容
+
+```Plain Text
+权限安全 rules：
+
+敏感操作必须四层校验
+权限字符必须有来源或标记为建议
+数据权限不得被查询条件替代
+
+每条 rule 都要写清：
+适用场景、必须、禁止、验收方式
+```
+
+### 讲师逐字稿
+
+这里把权限矩阵进一步沉淀成 rules。
+
+rules 不是写给人看的口号，而是写给 AI 和团队共同执行的约束。
+
+权限相关至少要有三条硬规则。
+
+第一，敏感操作必须四层校验：菜单、按钮、接口、数据范围都要覆盖。
+
+第二，权限字符必须有来源。如果是新建议，要明确标记为建议，不能让 AI 凭空编一个权限字符就当成事实。
+
+第三，数据权限不能被前端查询条件替代。后端必须校验当前用户的数据范围。
+
+后面权限方案、代码修改和 Review 都要回到这些 rules。
+
+### 课堂产出
+
+```md
+## 敏感操作必须四层校验
+- 级别：硬约束
+- 适用场景：新增、编辑、删除、指派、状态流转、查看审计、查看看板。
+- 必须：同时覆盖页面/菜单权限、按钮权限、后端接口权限、数据范围权限。
+- 禁止：只做页面或按钮控制。
+- 验收方式：授权角色能完成；未授权角色前端不可见且直接请求接口失败；越权数据访问失败。
+
+## 权限字符必须有来源或标记为建议
+- 必须：来自现有菜单、权限配置、前端权限指令、后端鉴权注解或团队规范。
+- 禁止：凭空编造权限字符并当成事实。
+- 验收方式：权限字符在前端、菜单配置、后端接口之间一致。
+
+## 数据权限不得被查询条件替代
+- 必须：后端统一校验当前用户可访问的数据范围。
+- 禁止：只依赖前端传入 userId、deptId、tenantId 或筛选条件。
+```
+
+---
+
 # 模块 2：权限控制方案生成

 ---
@@ -661,6 +714,49 @@ RBAC 权限矩阵

 ---

+## Slide 2-7：rules 要落到这些位置
+
+### PPT 页面内容
+
+```Plain Text
+rule 不是单独文件
+
+要落到：
+菜单配置
+按钮权限
+Controller
+Service 查询
+审计展示
+验收记录
+```
+
+### 讲师逐字稿
+
+很多团队写了 rules，但代码生成时没有真正用上。
+
+第四天要强调：让 TRAE 改权限前，必须同时给它当前项目 rules、权限矩阵、权限控制方案和实际文件路径。
+
+比如“四层校验”这条 rule，就要落到菜单配置、按钮权限、Controller、Service 查询和验收记录。
+
+“权限字符有来源”这条 rule，要落到菜单表、路由、按钮指令和后端注解。
+
+“数据权限不得被查询条件替代”这条 rule，要落到列表、详情、导出和看板查询。
+
+这样 rule 才不是口号，而是代码修改和 Review 的检查依据。
+
+### 课堂产出
+
+```md
+| rule 条款 | 代码落点 | 课堂验收 |
+|---|---|---|
+| 四层校验 | 菜单配置、按钮权限、Controller、Service 查询 | 无权限账号不可见且接口失败 |
+| 权限字符有来源 | 菜单表、路由、按钮指令、后端注解 | 同一字符贯穿前后端 |
+| 数据权限后端校验 | 列表、详情、导出、看板查询 | 改请求参数不能越权 |
+| 敏感字段最小返回 | 列表接口、详情接口、审计展示 | 不暴露不必要 old/new value |
+```
+
+---
+
 # 模块 3：工单状态流转规则实现

 ---
@@ -995,6 +1091,57 @@ POST /workOrder/transition

 ---

+## Slide 3-8：可直接复制到 rules：状态流转
+
+### PPT 页面内容
+
+```Plain Text
+状态流转 rules：
+
+复杂业务状态必须先建模
+非法状态流转必须拒绝且状态不变
+
+验证重点：
+合法路径成功
+非法路径失败
+状态不被错误修改
+失败不写成功审计
+```
+
+### 讲师逐字稿
+
+状态流转表不是一次性课堂表格。
+
+它应该沉淀成团队 rules，后续遇到审批、发布、上下架、支付、归档等状态型业务都可以复用。
+
+第一条 rule 是复杂业务状态必须先建模。
+
+也就是先产出状态流转表，再进入代码实现，不能直接在代码里堆 if else。
+
+第二条 rule 是非法状态流转必须拒绝且状态不变。
+
+这条非常关键。非法请求失败后，数据库状态不能被改坏，也不能写一条成功审计。
+
+这类 rules 会直接进入后续 Review 和测试清单。
+
+### 课堂产出
+
+```md
+## 复杂业务状态必须先建模
+- 级别：硬约束
+- 适用场景：工单指派、处理、验证、驳回、关闭、重开。
+- 必须：先产出状态流转表，列出当前状态、动作、目标状态、允许角色、前置条件、后置动作和验收方式。
+- 禁止：直接在代码中堆状态判断而没有状态表。
+- 验收方式：每个状态动作都有合法路径和非法路径验证。
+
+## 非法状态流转必须拒绝且状态不变
+- 必须：集中校验非法流转；失败时返回明确错误，业务状态不变，不写成功审计。
+- 禁止：仅靠前端禁用按钮防止非法流转。
+- 验收方式：构造非法状态动作，接口失败且数据库状态不变。
+```
+
+---
+
 # 模块 4：审计日志设计

 ---
@@ -1267,6 +1414,57 @@ SOP 要写清：

 ---

+## Slide 4-7：可直接复制到 rules：审计日志
+
+### PPT 页面内容
+
+```Plain Text
+审计日志 rules：
+
+关键业务操作必须写审计
+审计和业务写入必须一致
+
+不能只写：
+“记录日志”
+
+必须说明：
+字段、时机、事务、失败行为、验收方式
+```
+
+### 讲师逐字稿
+
+审计 rules 要比“记录日志”具体得多。
+
+关键业务操作必须写审计，适用于创建、编辑关键字段、指派、状态流转、驳回、关闭、删除、导出、权限变更。
+
+审计字段要包含操作人、动作、目标对象、修改前、修改后、来源、请求 ID 或项目里的等价字段。
+
+第二条 rule 是审计和业务写入必须一致。
+
+如果状态更新成功但审计丢了，后续无法追溯。
+
+如果审计写成功但业务失败，也会产生错误记录。
+
+所以必须说明审计写入时机、事务关系、失败处理和验证方式。
+
+### 课堂产出
+
+```md
+## 关键业务操作必须写审计
+- 级别：硬约束
+- 适用场景：创建、编辑关键字段、指派、状态流转、驳回、关闭、删除、导出、权限变更。
+- 必须：记录 actor、action、target_id、old_value、new_value、source、request_id、created_at 或项目等价字段。
+- 禁止：只记录普通日志而没有业务审计；操作失败后写成功审计。
+- 验收方式：执行关键操作后可查询审计记录，字段与实际变更一致。
+
+## 审计和业务写入必须一致
+- 必须：明确审计写入时机、事务关系、失败处理和重试策略。
+- 禁止：业务成功审计丢失，或审计成功但业务失败。
+- 验收方式：模拟业务失败和审计失败，结果符合一致性策略。
+```
+
+---
+
 # 模块 5：异常态与防御性逻辑

 ---
@@ -1535,6 +1733,59 @@ Service 要保证失败时状态不变。

 ---

+## Slide 5-7：可直接复制到 rules：异常态测试
+
+### PPT 页面内容
+
+```Plain Text
+测试 rules：
+
+核心逻辑必须有测试或豁免说明
+权限必须做正反角色验证
+状态流转必须覆盖合法和非法路径
+
+禁止：
+只用管理员账号验证
+只说“已验证”
+只跑正常主链路
+```
+
+### 讲师逐字稿
+
+异常态模块最后要沉淀成测试 rules。
+
+第一，核心逻辑必须有测试或豁免说明。
+
+如果没法写自动化测试，也要写清手工验收步骤、证据和剩余风险，不能只说“已验证”。
+
+第二，权限必须做正反角色验证。
+
+至少一个授权角色、一个未授权角色；如果涉及数据范围，还要验证越权数据。
+
+第三，状态流转必须覆盖合法和非法路径。
+
+不能只测从创建到关闭的成功链路，也要构造 closed 重新处理、pending_verify 驳回无原因这类失败路径。
+
+### 课堂产出
+
+```md
+## 核心逻辑必须有测试或豁免说明
+- 级别：待确认约束
+- 适用场景：权限校验、状态流转、审计、看板指标、异常态修复。
+- 必须：优先补自动化测试；无法测试时说明原因、风险和手工验收方式。
+- 禁止：只说“已验证”但没有命令、样例、截图、接口响应或手工步骤。
+
+## 权限必须做正反角色验证
+- 必须：至少验证一个授权角色和一个未授权角色；涉及数据范围时验证越权数据。
+- 禁止：只用管理员账号验证。
+
+## 状态流转必须覆盖合法和非法路径
+- 必须：每个关键动作至少覆盖一条合法路径和一条非法路径。
+- 禁止：只测试从初始状态到成功终态的主链路。
+```
+
+---
+
 # 模块 6：研发效能看板指标开发

 ---
@@ -1801,6 +2052,52 @@ trend 返回每日新增和每日关闭趋势。

 ---

+## Slide 6-7：可直接复制到 rules：看板指标
+
+### PPT 页面内容
+
+```Plain Text
+看板指标 rule：
+
+看板指标必须手工抽样校验
+
+必须有：
+含义、公式、过滤条件
+时间字段、数据范围、样例数据
+
+禁止：
+只验证接口 200
+只验证页面有图表
+```
+
+### 讲师逐字稿
+
+看板最容易出现“页面很漂亮，但数字说不清”的问题。
+
+所以看板指标也要写成 rules。
+
+每个关键指标必须有含义、公式、过滤条件、时间字段、数据范围，并且用样例数据手工校验。
+
+比如平均关闭周期，至少要拿三条样例工单，人工算一次，再和接口返回对上。
+
+接口返回 200 不代表指标正确，页面有图表也不代表指标可信。
+
+课堂交付时，看板必须同时交付指标字典、接口契约和至少一组手工核对样例。
+
+### 课堂产出
+
+```md
+## 看板指标必须手工抽样校验
+- 级别：硬约束
+- 适用场景：统计卡片、趋势图、分布图、排行、效能指标。
+- 必须：每个关键指标有含义、公式、过滤条件、时间字段、数据范围，并用样例数据手工校验。
+- 禁止：只验证接口返回 200 或页面有图表。
+- 来源证据：指标字典、接口契约、样例数据、数据库查询或列表数据。
+- 验收方式：至少一组样例数据的手工计算结果与接口返回一致。
+```
+
+---
+
 # 模块 7：阶段代码审查与修复

 ---
@@ -1874,6 +2171,94 @@ AI Review 不能只给 diff。

 ---

+## Slide 7-2A：第 4 天要用的三个 Skill
+
+### PPT 页面内容
+
+```Plain Text
+三个 Skill：
+
+design-complex-business-module
+开工前设计控制面
+
+review-business-delivery
+阶段 Review 检查风险
+
+track-review-fix-loop
+修复后闭环并沉淀资产
+```
+
+### 讲师逐字稿
+
+前三天已经讲过 Skill 的概念。
+
+第四天要让大家看到具体怎么用。
+
+第一个 Skill 是 `design-complex-business-module`，用在开始写代码前，先设计权限、状态、审计、异常态和看板指标。
+
+第二个 Skill 是 `review-business-delivery`，用在阶段 Review 时，检查权限缺口、非法状态流转、审计缺失、异常处理薄弱、看板口径不清和测试缺失。
+
+第三个 Skill 是 `track-review-fix-loop`，用在修复 Review 问题后，把问题状态、修改文件、验证证据和资产沉淀记录下来。
+
+Skill 负责流程和质量门禁；rule 负责长期约束；template 和 checklist 负责稳定输出。
+
+### 课堂产出
+
+```md
+| Skill | 什么时候用 | 输入材料 | 输出产物 |
+|---|---|---|---|
+| design-complex-business-module | 开始写代码前 | 需求、项目规则、现有角色/API/表结构 | RBAC、权限方案、状态表、审计 SOP、异常清单、指标字典 |
+| review-business-delivery | 阶段 Review 时 | diff、业务产物、测试结果、验收记录 | 问题清单、证据缺口、待确认项 |
+| track-review-fix-loop | 修 Review 后 | Review 报告、修改文件、验证证据 | 修复记录、未闭环事项、资产更新建议 |
+```
+
+---
+
+## Slide 7-2B：design-complex-business-module 怎么用
+
+### PPT 页面内容
+
+```Plain Text
+用于开工前：
+
+先设计控制面
+再进入代码实现
+
+输出：
+RBAC、权限方案、状态表、非法流转、
+审计 SOP、异常清单、指标字典、接口验收记录
+```
+
+### 讲师逐字稿
+
+`design-complex-business-module` 的核心原则是：先设计控制面，再设计代码。
+
+它不是让 AI 直接写实现，而是先把复杂业务应该有的控制资产产出。
+
+课堂里可以把工单需求、项目规则、现有角色、菜单权限、接口、数据表和相似模块作为输入。
+
+如果缺少源码或配置证据，输出必须标记为“建议”或“待确认”，不能让 AI 把推断当成事实。
+
+### 推荐 Prompt
+
+```md
+请使用 design-complex-business-module，基于 JeecgBoot 工单模块设计复杂业务控制面。
+
+输入材料：
+1. 需求范围：工单权限、状态流转、审计、异常态、看板。
+2. 项目规则：security-permission、state-audit、testing、delivery。
+3. 现有证据：角色、菜单权限、接口、数据表、相似模块。
+
+输出必须包含：
+RBAC 权限矩阵、权限控制方案、状态流转表、非法流转清单、
+审计日志 SOP、异常态清单、看板指标字典、看板接口验收记录。
+
+要求：
+没有源码或配置证据的内容标记为“建议”或“待确认”。
+```
+
+---
+
 ## Slide 7-3：阶段 Review 报告模板

 ### PPT 页面内容
@@ -1919,6 +2304,59 @@ Review 输出必须结构化。

 ---

+## Slide 7-3A：review-business-delivery 怎么用
+
+### PPT 页面内容
+
+```Plain Text
+用于阶段 Review：
+
+输入不能只有 diff
+
+必须同时给：
+业务产物
+测试结果
+验收记录
+项目 rules
+
+输出问题优先，按 P0/P1/P2/P3 排序
+```
+
+### 讲师逐字稿
+
+`review-business-delivery` 的作用是防止 AI Review 只做代码风格点评。
+
+第四天 Review 的对象是业务交付，不只是代码 diff。
+
+所以输入材料必须包括当天 diff、RBAC 矩阵、权限控制方案、状态流转表、非法流转清单、审计 SOP、异常态清单、看板指标字典和测试结果。
+
+输出要问题优先，按 P0/P1/P2/P3 排序。
+
+每个问题必须有证据、风险、修复建议和验收方式。
+
+如果缺少证据，就列到“证据缺口”，不能让 AI 猜。
+
+### 推荐 Prompt
+
+```md
+请使用 review-business-delivery 对第四天工单模块交付做阶段 Review。
+
+输入材料：
+- 当天 diff 或修改文件清单
+- RBAC 权限矩阵和权限控制方案
+- 状态流转表和非法流转清单
+- 审计日志 SOP 和异常态清单
+- 看板指标字典和接口验收记录
+- 测试命令、接口响应、浏览器验证或手工验收记录
+
+输出格式：
+先列问题清单，按 P0/P1/P2/P3 排序；
+每个问题必须有证据、风险、修复建议和验收方式；
+缺少证据时单独列“证据缺口”，不要猜测。
+```
+
+---
+
 ## Slide 7-4：修复闭环

 ### PPT 页面内容
@@ -1994,6 +2432,58 @@ Review 问题

 ---

+## Slide 7-5A：track-review-fix-loop 怎么用
+
+### PPT 页面内容
+
+```Plain Text
+用于 Review 修复后：
+
+每个问题只能标记为：
+成立-已修复
+成立-暂不修复
+不成立
+需确认
+未闭环
+
+没有验证证据不能关闭
+```
+
+### 讲师逐字稿
+
+`track-review-fix-loop` 负责把 Review 问题真正闭环。
+
+它要求每个问题不能只写“已修复”。
+
+必须判断问题是否成立，列出修改文件或产物，提供验证证据，说明剩余风险，并判断是否要沉淀成资产。
+
+如果没有验证证据，就不能标记为完成，只能标记为未闭环。
+
+如果问题依赖业务决策，就标记为需确认。
+
+如果问题不成立，也要保留原因和证据，不要直接删除。
+
+### 推荐 Prompt
+
+```md
+请使用 track-review-fix-loop，把阶段 Review 问题转成修复闭环记录。
+
+输入材料：
+- 带编号的 Review 报告
+- 修改文件或产物
+- 测试输出、接口响应、浏览器截图或手工验收步骤
+- 现有 rules、checklists、prompts、examples、skills 目录
+
+每个问题状态只能是：
+成立-已修复 / 成立-暂不修复 / 不成立 / 需确认 / 未闭环
+
+输出必须包含：
+修复记录、未闭环事项、资产更新建议。
+资产类型从 rule、checklist、prompt、command、skill、example 中选择。
+```
+
+---
+
 ## Slide 7-6：第四天完整实操链路

 ### PPT 页面内容
@@ -2128,6 +2618,59 @@ Review 问题

 ---

+## Slide 8-2A：第 4 天资产包目录
+
+### PPT 页面内容
+
+```Plain Text
+第 4 天资产包：
+
+rules
+skills
+templates
+checklists
+prompts
+examples
+
+交付给团队的不是聊天记录
+而是可复用工程资产包
+```
+
+### 讲师逐字稿
+
+第四天最后要让学员看到：课堂产物不是聊天记录。
+
+真正交付给团队的，是一套可安装、可复用、可审查的工程资产包。
+
+rules 是长期约束，比如权限四层校验、状态先建模、审计一致性、看板手工抽样。
+
+skills 是可触发流程，比如复杂业务设计、阶段 Review、修复闭环。
+
+templates、checklists、prompts 和 examples 是 Skill 运行时会用到的材料。
+
+这样团队下次做审批、报销、发布、合同、库存这些复杂业务模块时，就不需要重新从聊天记录里找经验。
+
+### 课堂产出
+
+```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/
+```
+
+---
+
 ## Slide 8-3：交付物验收标准

 ### PPT 页面内容