角色与权限

功能概述

角色定义一类人通常能做什么，权限定义具体某个动作能不能做。
两者组合后，平台才具备稳定的多人协作和长期治理能力。

适用场景

适合：

• 平台出现多个团队或多个管理员
• 需要限制发布、删除、授权等高风险操作
• 希望把权限规则沉淀成标准角色，而不是逐人维护

前置条件

开始前建议准备：

• 组织中的典型岗位清单
• 各岗位需要的核心操作
• 一份高风险操作清单

操作步骤

第 1 步：进入角色页，先看当前角色是否已经失控

管理员先进入后台 角色 页面，确认现在到底有多少角色。
重点判断：

• 角色是否过多
• 是否存在含义不清的临时角色
• 是否已经出现“一人一角色”的迹象

如果角色数量已经很多，先做整理方案，再继续新增。

第 2 步：先定义稳定角色，再映射权限

推荐先确定 3 到 5 个长期稳定角色，例如：

• 平台管理员
• 团队管理员
• 普通成员
• 查看者

先有稳定角色，后面的权限分配才不会越来越乱。

第 3 步：进入权限页，按资源类型分配能力

映射权限时，建议围绕资源类型思考，而不是围绕单个用户：

• 用户与团队
• Agent 与工作流
• 知识库与文档
• 模型、工具与 API Key
• 站点设置、通知和审计

这样后续新增资源类型时，也更容易继续扩展。

第 4 步：优先收紧高风险权限

建议先重点确认下面这些动作谁可以做：

• 删除资源
• 发布正式版本
• 管理 SSO、通知和站点设置
• 调整团队成员和角色
• 管理 API Key 和高成本模型

高风险权限默认应从紧，而不是默认开放。

第 5 步：用真实账号验证，而不是只看配置页

配置完成后，必须用不同角色账号实际登录验证。
重点看：

• 菜单是否正确显示
• 按钮是否正确禁用或隐藏
• 实际提交操作时是否真的被拦住

结果验证

一套可维护的角色权限体系，至少应满足：

• 角色数量有限且含义清晰
• 高风险权限被收紧
• 不同角色登录后的可见范围和可操作范围符合预期
• 角色调整后，实际效果会立即反映到账户上

常见问题

为什么不建议为每个人单独造角色

因为长期维护成本极高，而且一旦人员变动，权限几乎无法系统化交接。

为什么只看权限配置还不够

因为很多问题会出现在实际页面和提交行为中，而不是配置表里。

为什么高风险权限要单独优先确认

因为误删、越权发布、错误授权带来的后果，通常远大于普通读写问题。

注意事项

• 角色数越少越稳定，但前提是边界清晰
• 每次权限调整后，都应做一次真实登录回归
• 权限体系应随资源类型扩展而维护，不要等混乱后再补救