smart
67837df8d0
- 新增全套考试卷、评估卷、参考答案与考试培训包模板 - 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象 - 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求 - 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块 - 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语 - 新增考试输出模板与TRAE使用记录文档
194 lines
7.7 KiB
Markdown
194 lines
7.7 KiB
Markdown
# 模块 1：RBAC 权限模型设计
|
||
|
||
<div class="mt-6 text-sm">
|
||
|
||
工单模块不是普通 CRUD。复杂度不在字段多少，而在谁能看、谁能改、什么条件下能改，以及出问题后能否追溯。
|
||
|
||
</div>
|
||
|
||
<div class="grid grid-cols-5 gap-3 mt-8 text-sm">
|
||
<div class="p-3 rounded-xl bg-blue-500/10 border border-blue-500/30 text-center">管理员</div>
|
||
<div class="p-3 rounded-xl bg-emerald-500/10 border border-emerald-500/30 text-center">负责人</div>
|
||
<div class="p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-center">研发</div>
|
||
<div class="p-3 rounded-xl bg-purple-500/10 border border-purple-500/30 text-center">测试</div>
|
||
<div class="p-3 rounded-xl bg-gray-500/10 border border-gray-500/30 text-center">只读用户</div>
|
||
</div>
|
||
|
||
<!--
|
||
第四天从权限矩阵开始，不是因为权限最容易写，而是因为权限最容易被 AI 简化成 CRUD 默认逻辑。
|
||
工单模块看起来只是增删改查，但真实企业系统里，不同角色看到的数据、能执行的动作、承担的责任完全不同。
|
||
如果不先设计矩阵，AI 很容易把新增、编辑、删除、指派、关闭这些按钮都生成出来，后面再补权限就会很被动。
|
||
-->
|
||
|
||
---
|
||
|
||
# 先矩阵，后代码
|
||
|
||
<div class="grid grid-cols-2 gap-6 mt-7 text-sm">
|
||
<div class="p-4 rounded-xl bg-red-500/10 border border-red-500/30">
|
||
<div class="font-bold mb-2">错误顺序</div>
|
||
|
||
1. 先生成页面和接口
|
||
2. 再临时隐藏按钮
|
||
3. 最后补权限说明
|
||
</div>
|
||
<div class="p-4 rounded-xl bg-emerald-500/10 border border-emerald-500/30">
|
||
<div class="font-bold mb-2">推荐顺序</div>
|
||
|
||
1. 先定义角色和动作
|
||
2. 再生成权限矩阵
|
||
3. 最后落到菜单、按钮、接口、数据范围
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mt-6 p-3 rounded-xl bg-amber-500/10 border border-amber-500/30 text-sm">
|
||
权限矩阵是后续代码生成、Review 和验收的依据，不是交付后的补充说明。
|
||
</div>
|
||
|
||
<!--
|
||
这里要强调开发顺序。
|
||
AI 辅助开发最常见的问题，是先让它把 CRUD 做出来，再问“怎么加权限”。
|
||
这样会导致权限变成页面装饰，而不是业务规则。
|
||
正确做法是先用矩阵约束代码生成：哪些角色能看、能改、能流转、能删除、能看审计。
|
||
后面所有页面按钮、后端接口、数据范围和测试账号，都要回到这张矩阵。
|
||
-->
|
||
|
||
---
|
||
|
||
# RBAC 权限矩阵
|
||
|
||
<div class="mt-3 text-[11px] leading-tight">
|
||
|
||
| 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
|
||
|---|---|---|---|---|---|
|
||
| 查看列表 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
|
||
| 查看详情 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
|
||
| 新增工单 | Y | Y | Y | Y | N |
|
||
| 编辑工单 | Y | 条件允许 | 条件允许 | 条件允许 | N |
|
||
| 删除工单 | Y | N | N | N | N |
|
||
| 指派工单 | Y | 条件允许 | N | N | N |
|
||
| 提交验证 | Y | 条件允许 | Y | N | N |
|
||
| 关闭工单 | Y | 条件允许 | N | Y | N |
|
||
| 查看审计 | Y | 条件允许 | 条件允许 | 条件允许 | N |
|
||
| 查看看板 | Y | Y | 条件允许 | 条件允许 | 条件允许 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这张矩阵是课堂产出，不是讲师单方面给答案。
|
||
AI 可以生成初稿，但最终必须由业务和团队确认。
|
||
“条件允许”不能只写四个字，必须落到条件：只能看自己创建的工单、只能处理指派给自己的工单、只能关闭待验证状态的工单，还是只能查看所在团队的数据。
|
||
如果条件写不清，后端数据权限和测试用例就没法落地。
|
||
-->
|
||
|
||
---
|
||
|
||
# 条件允许要展开
|
||
|
||
<div class="mt-5 text-sm">
|
||
|
||
| 条件类型 | 示例 | 验收方式 |
|
||
|---|---|---|
|
||
| 数据范围 | 只能看本人、本人团队、本人负责的工单 | 不同账号列表数量不同 |
|
||
| 状态限制 | 只有待验证才能关闭 | 非目标状态接口返回拒绝 |
|
||
| 角色叠加 | 负责人兼管理员时按更高权限 | 用双角色账号验证 |
|
||
| 字段限制 | 研发只能改处理说明，不能改优先级 | 提交非法字段被拒绝 |
|
||
| 时间限制 | 已关闭工单超过窗口不能重开 | 超时重开失败 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这是原来矩阵里容易被忽略的知识点。
|
||
RBAC 不是只有允许和拒绝，真实业务里大量规则都是条件允许。
|
||
条件允许一旦不展开，AI 生成代码时就会把它理解成允许，测试时也不知道怎么验证。
|
||
所以矩阵之后必须补条件表，让权限从“角色判断”扩展到“角色 + 数据 + 状态 + 字段 + 时间”的组合判断。
|
||
-->
|
||
|
||
---
|
||
|
||
# 权限矩阵 Prompt
|
||
|
||
<div class="mt-5 text-sm">
|
||
|
||
```md
|
||
请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。
|
||
|
||
角色：
|
||
管理员、负责人、研发、测试、只读用户。
|
||
|
||
功能点：
|
||
查看列表、查看详情、新增、编辑、删除、指派、
|
||
提交验证、关闭、驳回、查看审计记录、查看看板。
|
||
|
||
要求：
|
||
1. 区分允许、拒绝、条件允许。
|
||
2. 条件允许必须展开为数据、状态、字段或时间条件。
|
||
3. 每个敏感操作给出后端接口验收方式。
|
||
4. 标注哪些权限属于业务待确认。
|
||
5. 不要直接生成代码。
|
||
```
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这里训练学员不要直接让 AI 改代码。
|
||
先生成矩阵，再确认业务边界，最后才进入权限控制方案。
|
||
Prompt 里一定要写“不要直接生成代码”，因为这一页的目标是规则设计，不是实现。
|
||
另外要让 AI 标注待确认项：谁能删除、谁能导出、谁能查看审计日志，这些不能让 AI 自己拍板。
|
||
-->
|
||
|
||
---
|
||
|
||
# AI 容易漏掉的权限风险
|
||
|
||
<div class="mt-5 text-sm">
|
||
|
||
| 风险 | 表现 | Review 问法 |
|
||
|---|---|---|
|
||
| 前端按钮替代权限 | 按钮隐藏，但接口可直接调 | 无权限账号直接请求会怎样 |
|
||
| 数据范围缺失 | 所有人看到同一批工单 | 普通用户能否看到他人数据 |
|
||
| 条件允许泛化 | “条件允许”被实现成允许 | 条件在哪里校验 |
|
||
| 审计权限遗漏 | 审计日志对不该看的人开放 | 谁能看 old/new value |
|
||
| 删除权限过宽 | 负责人或研发能删除工单 | 删除是否只限管理员 |
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这一页是给后续 Review 铺垫。
|
||
AI 很容易把权限理解成“有没有按钮”，但企业系统真正的风险在接口和数据范围。
|
||
课堂里可以让学员拿这张表去追问 TRAE：这个权限风险在哪个文件、哪个接口、哪个测试账号可以验证。
|
||
这样权限矩阵就不是一张漂亮表，而是 Review 和验收的入口。
|
||
-->
|
||
|
||
---
|
||
|
||
# 可直接复制到 rules：权限安全
|
||
|
||
<div class="mt-5 text-xs">
|
||
|
||
```md
|
||
## 敏感操作必须四层校验
|
||
- 级别：硬约束
|
||
- 适用场景：新增、编辑、删除、指派、状态流转、查看审计、查看看板。
|
||
- 必须：同时覆盖页面/菜单权限、按钮权限、后端接口权限、数据范围权限。
|
||
- 禁止：只做页面或按钮控制。
|
||
- 验收方式：授权角色能完成；未授权角色前端不可见且直接请求接口失败；越权数据访问失败。
|
||
|
||
## 权限字符必须有来源或标记为建议
|
||
- 必须：来自现有菜单、权限配置、前端权限指令、后端鉴权注解或团队规范。
|
||
- 禁止：凭空编造权限字符并当成事实。
|
||
- 验收方式：权限字符在前端、菜单配置、后端接口之间一致。
|
||
|
||
## 数据权限不得被查询条件替代
|
||
- 必须：后端统一校验当前用户可访问的数据范围。
|
||
- 禁止：只依赖前端传入 userId、deptId、tenantId 或筛选条件。
|
||
```
|
||
|
||
</div>
|
||
|
||
<!--
|
||
这页把交付包里的 security-permission 规则压缩成课堂可直接使用的版本。
|
||
重点不是让学员背规则，而是让他们知道第四天的权限实操必须写进 rules，并且每条 rules 都要有适用场景、必须、禁止和验收方式。
|
||
后续权限矩阵、权限控制方案和阶段 Review 都要回到这几条规则。
|
||
-->
|