Excalidraw设计权限矩阵：RBAC模型绘制

Excalidraw 绘制 RBAC 权限矩阵：从草图到系统设计的协作跃迁

在一次典型的权限评审会议上，开发、产品和安全团队围坐在一起，面对一份长达十几页的文字权限说明文档。产品经理指着某段描述：“这里说运营只能查看订单，但不能导出——这个‘查看’是否包含打印？”工程师皱眉：“代码里我们按只读处理了，但如果要加导出功能，得重新走流程。”安全部门则追问：“有没有做职责分离分析？”

这样的场景在中大型系统建设中屡见不鲜。权限设计的本质不是技术实现，而是多方认知对齐的过程。而传统文档或表格工具难以承载这种高密度的信息沟通需求。直到我们开始用一张“手绘风格”的白板图来表达整个 RBAC 模型时，会议室的气氛变了——有人直接在屏幕上拖动角色框，有人用红笔圈出权限冲突点，讨论变得具体且高效。

这张图，往往就诞生于 Excalidraw。

Excalidraw 是一个开源的 Web 白板工具，初看像是孩子涂鸦的草图纸，实则暗藏工程智慧。它没有复杂的菜单栏，也不追求矢量精准，反而刻意让线条带上轻微抖动，模拟真实纸笔书写的感觉。这种“不完美”的视觉语言，意外地打破了技术沟通的心理壁垒。当一张权限模型以草图形式呈现时，人们更愿意提出修改意见，而不是把它当作不可更改的终稿。

更重要的是，Excalidraw 的底层数据结构完全开放。每个图形元素都以 JSON 格式存储，包含类型、坐标、文本内容等元信息。这意味着它不仅是绘图工具，还可以成为系统设计资产的一部分。你可以将.excalidraw文件提交到 Git，像管理代码一样管理设计演进；也可以通过脚本解析其中的文本内容，自动生成权限清单甚至初始化配置。

比如下面这段 Python 脚本，就能从导出的 JSON 文件中提取所有文本元素：

import json def parse_excalidraw_file(filepath): with open(filepath, 'r', encoding='utf-8') as f: data = json.load(f) elements = data.get('elements', []) texts = [] for elem in elements: if elem['type'] == 'text': text_content = elem.get('text', '').strip() if text_content: texts.append({ 'id': elem['id'], 'content': text_content, 'x': elem['x'], 'y': elem['y'] }) return texts # 示例调用 texts = parse_excalidraw_file('rbac_model.excalidraw') for t in texts: print(f"Text at ({t['x']}, {t['y']}): {t['content']}")

这看似简单的功能，实则是连接“可视化设计”与“程序化实现”的桥梁。设想一下：当你在画布上写下“admin: user:write”，脚本可以自动识别并生成对应的权限注册逻辑，或者校验其是否已在代码中正确定义。

RBAC（Role-Based Access Control），即基于角色的访问控制，是现代 IAM 系统的核心范式。它的基本思想很朴素：用户不直接拥有权限，而是通过被赋予的角色间接获得。这样一来，当新增一个管理员时，无需逐项配置权限，只需打上“admin”标签即可。

典型的 RBAC 模型包含四个关键要素：
-用户（User）：系统的实际使用者。
-角色（Role）：权限的集合，如“财务专员”、“内容审核员”。
-权限（Permission）：对资源的操作权，通常表示为resource:action形式，如invoice:approve。
-会话（Session）：用户登录后激活的角色子集，支持临时降权或角色切换。

这套模型的优势在于可维护性和合规性。相比 DAC（自主访问控制）中“张三能改李四的文件”这类零散授权，RBAC 提供了结构化的治理能力。企业可以根据组织架构定义角色层级，支持最小权限原则和职责分离（SoD），从而满足审计要求。

一个简化的 RBAC 判断逻辑可以用几行 Python 实现：

class RBACSystem: def __init__(self): self.permissions = {} # role -> [permission_list] self.user_roles = {} # user -> [role_list] def add_permission(self, role, permission): if role not in self.permissions: self.permissions[role] = [] self.permissions[role].append(permission) def assign_role(self, user, role): if user not in self.user_roles: self.user_roles[user] = [] self.user_roles[user].append(role) def has_permission(self, user, required_permission): if user not in self.user_roles: return False roles = self.user_roles[user] for role in roles: perms = self.permissions.get(role, []) if required_permission in perms: return True return False # 示例使用 rbac = RBACSystem() rbac.add_permission("admin", "user:read") rbac.add_permission("admin", "user:write") rbac.assign_role("alice", "admin") print(rbac.has_permission("alice", "user:read")) # True print(rbac.has_permission("bob", "user:write")) # False

这段代码虽然简单，但它与你在 Excalidraw 上绘制的权限矩阵应当保持一致。理想情况下，图表不只是静态文档，而应作为动态设计资产参与整个开发生命周期。

那么，如何真正用好 Excalidraw 来构建 RBAC 模型？

第一步是从业务出发梳理实体。打开画布后，先不要急着画格子，而是列出三个核心维度：
1.用户类型：谁在用系统？（如超级管理员、区域经理、普通员工）
2.资源模块：系统有哪些关键数据或功能？（如订单、客户资料、审批流）
3.操作类型：这些角色能做什么？（查看、编辑、删除、导出、审批）

接着，创建一个二维矩阵。纵轴放角色，横轴放权限项。每个单元格用 ✅ 或颜色填充表示授予权限。这时你会发现，Excalidraw 的自由布局反而成了优势——不像 Excel 那样受限于行列结构，你可以用彩色矩形框出“管理层”角色组，用虚线箭头表示角色继承关系，甚至插入一个小便签注明：“仅允许查看本部门数据”。

更有意思的是，一些 Excalidraw 的镜像版本已集成 AI 图形生成能力。输入提示词：“生成电商平台的 RBAC 矩阵，包含管理员、客服、供应商三种角色”，AI 会自动布局初步框架。虽然结果未必完美，但大大缩短了冷启动时间。人工再在此基础上调整细节，效率提升显著。

完成初稿后，分享链接给团队成员。实时协作模式下，每个人都能看到对方的光标移动和编辑过程。产品经理可以在“客服”角色旁添加注释：“当前无禁用用户权限，是否需要补充？”开发则可以直接在图上标注：“该权限需对接风控系统做二次验证”。这些互动痕迹本身就成了宝贵的设计记录。

最后，导出 SVG 或 PNG 插入 Confluence，同时保留.excalidraw原文件纳入 Git 版本管理。每当权限逻辑变更时，同步更新图表，确保“文档即代码”的一致性。

当然，工具再强大也需配合良好的实践习惯。

首先是保持简洁。一张图不宜承载过多信息。建议按子系统拆分多个小图，例如“用户中心权限”、“计费系统权限”分别建模，避免视觉混乱。

其次是命名规范。权限命名应统一采用resource:action格式，避免出现“查看”“读取”“浏览”混用的情况。清晰的命名能让非技术人员也能大致理解权限含义。

再者是定期审查。随着系统迭代，容易出现“权限膨胀”——某个角色积累了大量不再需要的权限。定期回顾 Excalidraw 图表，结合实际日志分析，及时清理冗余授权，是保障安全的重要环节。

最重要的是，让图表活起来。不要让它沉睡在 Wiki 的某个角落。在 PR 评审中引用它，在安全审计时展示它，在新人培训时讲解它。只有当一张图真正参与到团队的认知循环中，它才完成了从“绘图”到“设计语言”的跃迁。

回到最初的问题：为什么选择 Excalidraw 来画 RBAC 权限矩阵？

因为它不只是工具，更是一种协作哲学的体现。它用“草图感”降低表达门槛，用开放格式打通工具链，用实时协作加速共识达成。在这个越来越强调跨职能协同的时代，我们需要的不再是完美的 PPT 式文档，而是能够快速迭代、广泛参与、持续演进的设计媒介。

当你的权限模型不再是一份让人望而生畏的技术说明书，而是一张可以随时涂改、讨论、分享的手绘草图时，真正的团队共智才可能发生。而这，正是现代软件工程所需要的——不仅写出正确的代码，更要让所有人都理解它为何正确。