权限原型的核心不是在页面上放一个“权限管理”菜单，而是让团队看清谁能对什么资源执行什么操作，以及没有权限时会发生什么。建议先用一张权限矩阵确定角色、资源、操作，再用原型串起有权、无权、申请授权和授权后四条路径。需要把矩阵转成可点击页面时，可在墨刀原型中同时维护角色切换与页面状态。
一、先把权限问题拆成四个维度
用“角色—资源—操作—范围”描述权限，比只列“管理员、普通用户”更容易落地。角色回答谁在操作；资源回答项目、订单、报表等对象；操作回答查看、创建、编辑、导出、删除；范围回答全部数据、本人数据、所属部门或指定项目。
| 维度 | 示例 | 评审时要问 |
|---|---|---|
| 角色 | 项目管理员、成员、访客 | 一个人能否同时拥有多个角色？ |
| 资源 | 项目、任务、成员、数据报表 | 资源之间是否存在继承关系？ |
| 操作 | 查看、编辑、分享、导出 | 按钮隐藏还是点击后提示？ |
| 范围 | 全部、部门、本人、指定项目 | 切换范围后列表和统计是否同步？ |
二、用权限矩阵生成页面清单
以“项目空间”为例，先写出角色与操作矩阵，再从矩阵反推页面。管理员可以查看、编辑和管理成员；成员可以查看、编辑任务但不能修改成员；访客只能查看。页面清单至少包含项目首页、成员管理、邀请成员、任务详情、权限不足和授权申请。
- 把角色写在矩阵第一列，资源写在第一行。
- 每个交叉单元填入允许操作、数据范围和前置条件。
- 为每种结果建立页面状态：允许、无权、待审批、已拒绝和资源不存在。
- 把同一资源的列表、详情、编辑页放在同一页面流中，避免只画菜单。
三、必须画出的越权与恢复路径
权限评审最容易漏掉的是“页面已经打开后权限发生变化”。例如成员在任务详情页停留期间被移出项目，点击保存时应显示无权并保留未提交内容；访客打开导出链接时，应得到可解释的提示而不是空白页。
- 未登录：跳转登录，返回地址保留到原页面。
- 无权查看：说明当前账号缺少的权限，并提供联系管理员或申请访问入口。
- 无权操作：按钮可隐藏，也可保留为禁用态；两种选择应在原型中明确。
- 授权待处理：展示申请时间、审批人和当前状态，避免用户重复提交。
- 资源已删除：给出返回列表和查看操作记录的路径。
四、在墨刀中完成一次可验证评审
先创建角色切换控件，再为同一页面建立有权、无权和待审批三个状态。把“保存”“导出”“邀请成员”分别连接到对应结果，给每个页面加标注，写清触发条件和预期提示。评审时按一名管理员、一名成员、一名访客各走一遍，不要只看管理员路径。
交付前检查：矩阵中的每个允许操作都有入口；每个拒绝结果都能回到安全页面；角色切换不会遗留上一角色的数据；分享链接不能绕过页面权限。这样产出的权限原型既能讨论体验，也能给研发提供状态和边界。
五、适用边界
权限原型用于确认产品规则和交互，不等于后端鉴权实现。真实系统仍需校验接口权限、缓存、并发修改、审计日志和数据隔离。原型评审通过后，把矩阵和页面状态作为研发测试清单，而不是用页面隐藏按钮代替安全控制。
