feat(slidev): update 3 4

slidev/pages/day4/m1-rbac-permission-model.md

@@ -2,7 +2,7 @@
 
 <div class="mt-6 text-sm">
 
-工单模块不是普通 CRUD。不同角色看到的数据不同、能做的动作不同、承担的责任也不同。
+工单模块不是普通 CRUD。复杂度不在字段多少，而在谁能看、谁能改、什么条件下能改，以及出问题后能否追溯。
 
 </div>
 
@@ -15,9 +15,42 @@
 </div>
 
 <!--
-第四天从权限矩阵开始。
-工单模块看起来像 CRUD，但真实业务里管理员、负责人、研发、测试、只读用户的权限边界完全不同。
-如果不先设计矩阵，AI 很容易按默认 CRUD 生成所有按钮。
+第四天从权限矩阵开始，不是因为权限最容易写，而是因为权限最容易被 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 做出来，再问“怎么加权限”。
+这样会导致权限变成页面装饰，而不是业务规则。
+正确做法是先用矩阵约束代码生成：哪些角色能看、能改、能流转、能删除、能看审计。
+后面所有页面按钮、后端接口、数据范围和测试账号，都要回到这张矩阵。
 -->
 
 ---
@@ -28,23 +61,47 @@
 
 | 功能 | 管理员 | 负责人 | 研发 | 测试 | 只读 |
 |---|---|---|---|---|---|
-| 查看列表 | Y | Y | Y | Y | Y |
-| 新增工单 | Y | Y | N | Y | N |
-| 编辑工单 | Y | Y | 条件允许 | 条件允许 | N |
+| 查看列表 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
+| 查看详情 | Y | 条件允许 | 条件允许 | 条件允许 | 条件允许 |
+| 新增工单 | Y | Y | Y | Y | N |
+| 编辑工单 | Y | 条件允许 | 条件允许 | 条件允许 | N |
 | 删除工单 | Y | N | N | N | N |
-| 指派工单 | Y | Y | N | N | N |
-| 提交验证 | Y | Y | Y | N | N |
-| 关闭工单 | Y | Y | N | Y | N |
-| 驳回工单 | Y | Y | N | Y | N |
-| 查看审计 | Y | Y | 条件允许 | 条件允许 | N |
-| 查看看板 | Y | Y | 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 生成代码时就会把它理解成允许，测试时也不知道怎么验证。
+所以矩阵之后必须补条件表，让权限从“角色判断”扩展到“角色 + 数据 + 状态 + 字段 + 时间”的组合判断。
 -->
 
 ---
@@ -60,13 +117,15 @@ AI 可以生成初稿，但最终必须由业务和团队确认。
 管理员、负责人、研发、测试、只读用户。
 
 功能点：
-查看列表、查看详情、新增、编辑、删除、指派、提交验证、关闭、驳回、查看审计记录、查看看板。
+查看列表、查看详情、新增、编辑、删除、指派、
+提交验证、关闭、驳回、查看审计记录、查看看板。
 
 要求：
-1. 区分允许、禁止、条件允许。
-2. 条件允许必须说明条件。
-3. 每个敏感操作给出验收方式。
-4. 不要直接生成代码。
+1. 区分允许、拒绝、条件允许。
+2. 条件允许必须展开为数据、状态、字段或时间条件。
+3. 每个敏感操作给出后端接口验收方式。
+4. 标注哪些权限属于业务待确认。
+5. 不要直接生成代码。
 ```
 
 </div>
@@ -74,4 +133,29 @@ AI 可以生成初稿，但最终必须由业务和团队确认。
 <!--
 这里训练学员不要直接让 AI 改代码。
 先生成矩阵，再确认业务边界，最后才进入权限控制方案。
+Prompt 里一定要写“不要直接生成代码”，因为这一页的目标是规则设计，不是实现。
+另外要让 AI 标注待确认项：谁能删除、谁能导出、谁能查看审计日志，这些不能让 AI 自己拍板。
+-->
+
+---
+
+# AI 容易漏掉的权限风险
+
+<div class="mt-5 text-sm">
+
+| 风险 | 表现 | Review 问法 |
+|---|---|---|
+| 前端按钮替代权限 | 按钮隐藏，但接口可直接调 | 无权限账号直接请求会怎样 |
+| 数据范围缺失 | 所有人看到同一批工单 | 普通用户能否看到他人数据 |
+| 条件允许泛化 | “条件允许”被实现成允许 | 条件在哪里校验 |
+| 审计权限遗漏 | 审计日志对不该看的人开放 | 谁能看 old/new value |
+| 删除权限过宽 | 负责人或研发能删除工单 | 删除是否只限管理员 |
+
+</div>
+
+<!--
+这一页是给后续 Review 铺垫。
+AI 很容易把权限理解成“有没有按钮”，但企业系统真正的风险在接口和数据范围。
+课堂里可以让学员拿这张表去追问 TRAE：这个权限风险在哪个文件、哪个接口、哪个测试账号可以验证。
+这样权限矩阵就不是一张漂亮表，而是 Review 和验收的入口。
 -->