权限系统怎么设计提示词（RBAC 角色权限表结构、菜单与按钮权限、数据权限）
做管理后台、SaaS 或内部系统需要设计权限模块时用：让 AI 根据组织结构和权限需求设计 RBAC 模型，覆盖功能权限（菜单、按钮、接口）和数据权限（只能看本部门、只能看自己的），给出表结构、鉴权流程和常见越权漏洞的检查清单。
通用大模型 对话模型通用
你是一名做过多个企业级后台权限系统的架构师。请帮我设计权限模块。 需求： - 系统类型：[如内部运营后台、多租户 SaaS] - 组织结构：[如公司、部门、小组三级；有没有多租户] - 角色举例：[如超级管理员、部门经理、客服、财务] - 需要控制的功能：[如菜单可见、按钮可点、接口可调用] - 数据范围的要求：[数据范围的要求]（例：客服只能看自己负责的客户、经理能看本部门及下级） - 特殊需求：[如临时授权、权限审批、操作审计] - 技术栈：[技术栈]（例：Spring Boot + MySQL + Vue） 请输出： 1. 模型选择：基础 RBAC 是否够用；什么情况下需要角色继承、用户组、基于属性的规则（ABAC）作为补充；不要为了「完整」引入用不到的复杂度。 2. 功能权限设计：权限点的粒度与命名规则（如「模块:资源:操作」），菜单、按钮、接口三类权限如何对应；前端只负责显示隐藏，真正的拦截必须在后端。 3. 数据权限设计：数据范围的几种类型（全部、本部门、本部门及下级、仅本人、自定义），如何在查询中统一注入过滤条件，而不是在每个接口里手写。 4. 表结构：建表语句，包括用户、角色、权限、用户角色关联、角色权限关联、数据范围配置；多租户时每张表如何隔离。 5. 鉴权流程：一次请求从认证到功能鉴权、数据过滤的完整流程；权限缓存在哪里、修改权限后如何及时生效。 6. 管理功能：角色的增删改、权限分配界面的交互建议、防止管理员把自己锁在门外。 7. 安全检查清单：水平越权（改 URL 里的 ID 访问别人的数据）、垂直越权（普通用户调用管理员接口）、批量接口和导出接口的数据范围、权限修改本身的审计日志。 每个设计决定附一句理由。
高亮处换成你自己的内容：[如内部运营后台、多租户 SaaS]、[如公司、部门、小组三级；有没有多租户]、[如超级管理员、部门经理、客服、财务]、[如菜单可见、按钮可点、接口可调用]、[数据范围的要求]、[如临时授权、权限审批、操作审计]、[技术栈]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[数据范围的要求] 是权限系统里最容易被低估的部分。功能权限（能不能点这个按钮）大家都会想到，但「能看到哪些数据」往往到开发后期才发现需要，到时候每个查询都要返工。
常见坑：
- 只在前端隐藏按钮，后端接口不做校验。任何人用接口调试工具都能直接调用。
- 数据权限在每个接口里手写过滤条件，总会有遗漏，尤其是导出、统计、批量操作这些「非主流程」接口。
- 权限放在登录令牌里且有效期很长，管理员撤销了某人的权限，对方在令牌过期前仍能操作。
追问技巧：设计完成后追问「列出 10 个具体的越权测试用例（包括导出接口和批量接口）」，交给测试同学执行。也可以追问「如果以后要支持某个用户临时代理另一个人的权限，现有设计要怎么扩展」。
示例输出
示例，仅供参考（节选）
权限点命名：customer:list:view、customer:detail:edit、order:refund:approve
sql
CREATE TABLE role_data_scope (
role_id BIGINT NOT NULL,
resource VARCHAR(64) NOT NULL, -- 如 customer
scope_type VARCHAR(32) NOT NULL, -- ALL / DEPT / DEPT_AND_CHILDREN / SELF / CUSTOM
PRIMARY KEY (role_id, resource)
);| 角色 | 客户数据范围 | 说明 |
|---|---|---|
| 客服 | SELF | 只看负责人是自己的客户 |
| 部门经理 | DEPT_AND_CHILDREN | 通过部门路径字段做前缀匹配查询 |
| 财务 | ALL（只读） | 没有编辑权限点 |
数据过滤：在数据访问层统一拦截查询，根据当前用户角色的 scope_type 拼接过滤条件；导出接口复用同一套逻辑。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～