研发平台权限矩阵把角色、平台对象和可执行操作放在同一张表里交叉排列，用来回答“谁在什么范围内能查看、创建、编辑、审批、导出或管理配置”。本文直接给出可复制的空白模板，包括角色清单表、对象清单表和权限矩阵主表，并说明每个字段的含义、必填与选填的划分、一条完整权限行的填写方式，以及矩阵上线后的调整与复核方法。
要点总览（TL;DR）
- 模板由角色清单、对象清单和权限矩阵主表三张表组成，主表按角色、对象、操作三轴交叉排列，并附数据范围、授权方式、审批要求、有效期、复核周期、复核责任人等治理字段。
- 最小可用矩阵必填权限行编号、角色、对象、操作、数据范围和复核责任人；多项目、外部协作或涉及生产配置时，补齐授权方式、审批要求、有效期和复核周期。
- 填写时一个单元格只写一种操作，多种操作拆成多行；角色和审批人写岗位而非人名，数据范围写清边界，临时权限写明确切到期条件。
- 矩阵上线后按复核周期例行检查，人员转岗、项目结项、对象下线时触发权限回收，每次变更保留变更记录并按版本存档。
- 权限申请、审批、开通与到期复核可在平台内以工作项流转，使矩阵字段与实际授权状态保持对应。
可复制空白权限矩阵模板
填写顺序建议从两张辅助表开始：先列清角色和对象，再在主表中逐行组合。这样能避免主表出现同一角色多种叫法、同一对象多种粒度的问题。三张表都可以直接复制到文档或表格工具中使用。
表一：角色清单
| 角色编号 | 角色名称 | 角色类型 | 所属组织/项目 | 角色说明 | 角色负责人 |
|---|---|---|---|---|---|
| R-01 | |||||
| R-02 | |||||
| R-03 |
表二：对象清单
| 对象编号 | 对象名称 | 对象层级 | 所属模块 | 敏感级别 | 对象负责人 |
|---|---|---|---|---|---|
| O-01 | |||||
| O-02 | |||||
| O-03 |
表三：权限矩阵主表
| 权限行编号 | 角色 | 对象 | 操作 | 数据范围 | 授权方式 | 审批要求 | 有效期 | 复核周期 | 复核责任人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| P-001 | ||||||||||
| P-002 | ||||||||||
| P-003 |
权限矩阵字段说明
主表字段分为三类：角色、对象、操作构成权限的核心定义；数据范围、授权方式、审批要求、有效期、复核周期、复核责任人构成治理信息；备注用于记录例外情况。字段含义和取值口径需要在团队内统一，否则同一张表在不同人手里会填出不同结果。
| 字段 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 权限行编号 | 唯一标识一条权限授予 | P-001 | 按“P-序号”连续编号，删除行后编号不复用 |
| 角色 | 被授权的岗位或角色组 | 项目管理员、测试工程师、外部协作方 | 填写角色清单中的角色名称，不直接写个人姓名 |
| 对象 | 权限作用的平台资源 | 需求、代码仓库、构建流水线、环境配置 | 填写对象清单中的对象名称，粒度到可独立授权的最小单位 |
| 操作 | 允许对该对象执行的动作 | 查看、创建、编辑、审批、导出、配置管理 | 一个单元格只写一种操作，多种操作用多行表达 |
| 数据范围 | 权限生效的资源边界 | 本部门、指定项目、全平台、仅本人创建 | 写清范围边界，避免只写“全部”而不说明范围对象 |
| 授权方式 | 权限如何被赋予 | 角色继承、手动授予、审批后自动开通 | 区分默认继承与临时授予，临时授予需配合有效期 |
| 审批要求 | 开通该权限是否需要审批及审批人 | 无需审批、对象负责人审批、双人审批 | 写明审批角色而非具体人名，人员变动时无需改表 |
| 有效期 | 权限的存续时间 | 长期、90天、项目结束日 | 长期权限也应设置复核周期；临时权限写明确切到期条件 |
| 复核周期 | 多久检查一次该权限是否仍必要 | 每季度、每半年、项目里程碑 | 高敏感对象缩短周期，稳定岗位可适当延长 |
| 复核责任人 | 负责确认权限保留或回收的人 | 对象负责人、部门负责人 | 填角色，确保责任落到岗位而非临时人员 |
| 备注 | 例外说明与补充信息 | 外部协作方仅限本项目周期内 | 记录例外原因和依据，便于复核时判断 |
常见歧义集中在三处。第一，“编辑”与“管理配置”容易混用，前者指修改对象内容，后者指调整对象的结构或规则，应分列。第二，数据范围写成“全部”时没有说明是全部项目还是全部部门，复核时无法判断是否越权。第三，审批要求写成人名，人员调岗后表格失效，应统一写审批角色。
必填与选填字段的划分
矩阵的字段要求可以分两档。团队规模较小、平台对象不多时，用最小可用矩阵即可跑通授权管理；当平台承载多项目、多外部协作方，或需要应对内外部检查时，再补齐治理字段。
| 字段 | 最小可用矩阵 | 完整治理矩阵 | 说明 |
|---|---|---|---|
| 权限行编号 | 必填 | 必填 | 保证每行可被引用和追踪 |
| 角色 | 必填 | 必填 | 核心字段 |
| 对象 | 必填 | 必填 | 核心字段 |
| 操作 | 必填 | 必填 | 核心字段 |
| 数据范围 | 必填 | 必填 | 缺少范围，权限边界无法判断 |
| 复核责任人 | 必填 | 必填 | 没有责任人，矩阵无法持续维护 |
| 授权方式 | 选填 | 必填 | 用于区分继承权限与临时授予 |
| 审批要求 | 选填 | 必填 | 涉及敏感对象时建议提前纳入 |
| 有效期 | 选填 | 必填 | 临时权限、外部协作场景必须填写 |
| 复核周期 | 选填 | 必填 | 与复核责任人配套使用 |
| 备注 | 选填 | 选填 | 记录例外情况 |
取舍建议：十人左右、单一项目的团队，最小可用矩阵已能覆盖日常授权；平台接入多个项目、存在外部协作方或生产环境配置权限时，应直接采用完整治理矩阵，因为这类场景下临时权限和审批缺失最容易造成权限沉淀。合规要求较高的组织还可以在完整矩阵基础上增加“权限来源依据”列，记录授予所依据的申请单或审批记录编号。
填写示例：一条完整权限行
下面以“测试工程师对构建流水线的查看与执行权限”为例，演示一条权限行从角色到复核责任人的完整填写。示例中的角色和对象名称均为演示情景，实际填写时替换为团队自己的清单条目。
| 字段 | 填写内容 | 填写说明 |
|---|---|---|
| 权限行编号 | P-014 | 接续已有编号，不复用已删除行 |
| 角色 | 测试工程师 | 对应角色清单 R-05，不写个人姓名 |
| 对象 | 构建流水线 | 对应对象清单 O-07，粒度到流水线这一层 |
| 操作 | 查看 | 单独一行只写一种操作 |
| 数据范围 | 所属项目 | 限定在本项目内，不跨项目 |
| 授权方式 | 角色继承 | 随角色自动获得，无需逐人开通 |
| 审批要求 | 无需审批 | 只读权限风险较低 |
| 有效期 | 长期 | 配合复核周期控制 |
| 复核周期 | 每半年 | 与项目季度评审错开，减少集中工作量 |
| 复核责任人 | 构建平台负责人 | 写岗位，人员变动不影响表格 |
| 备注 | 执行权限另起一行 P-015 | 提示同一角色同一对象的其他操作单独成行 |
这条示例对应两行权限：查看与执行分别记录。填写时最容易漏掉的是数据范围和复核责任人——前者决定权限是否越界，后者决定这张表半年后还有没有人维护。另一个易漏点是有效期：只读权限写“长期”可以接受，但涉及生产环境配置的操作应写明到期条件，例如“项目上线后30天回收”。
矩阵的调整与维护方法
权限矩阵是活文档，组织调整、项目立项或结项、平台新增模块时都需要同步更新。维护的重点是让变更可追溯、让过期权限能及时回收。
新增角色或对象时的扩展规则
- 新增角色先进入角色清单，分配唯一编号并写明角色类型和负责人，再在主表中引用；同一职责不重复建角色。
- 新增对象先判断层级：模块级对象可独立授权时进入对象清单；仅作为已有对象属性存在的，不单独建行。
- 新增对象默认不继承任何角色权限，需要逐条补充权限行，避免新对象上线即对所有角色开放。
- 平台新增功能模块时，先确认其对象归属，再决定是扩展现有对象还是新增对象条目。
定期复核与权限回收的触发条件
- 按复核周期执行例行检查，重点核对高敏感对象和临时授予的权限行。
- 人员转岗、离职或外部协作方合同结束时，触发对应角色的权限回收检查。
- 项目结项或阶段交付完成后，回收仅在该项目周期内有效的权限。
- 平台对象下线或合并时，同步删除或迁移相关权限行，并在备注中记录去向。
变更记录与版本管理
每次修改矩阵应保留变更记录：记录变更日期、变更人、变更的权限行编号、变更前后内容和变更依据。矩阵本身按版本存档，例如每季度定稿一个版本，历史版本可查。这样在复核或出现权限争议时，能追溯到某条权限是何时、由谁、依据什么授予的。
当权限变更和复核需要在平台内流转时，可以把“权限申请—审批—开通—到期复核”做成工作项：申请人提交权限行信息，审批人按矩阵中的审批要求处理，开通结果回写到对应权限行，复核到期时自动生成待办交给复核责任人。ONES 的工作项与审批能力可以承载这类流程，让矩阵中的字段与平台内的实际授权状态保持对应；具体配置方式按团队现有的项目与角色结构设计。
常见问题
团队只有十几个人、一个项目，权限矩阵可以简化到什么程度？
可以只保留最小可用矩阵的六个必填字段：权限行编号、角色、对象、操作、数据范围和复核责任人。这一档能回答“谁对什么能做什么、范围到哪里、由谁负责复核”。如果平台里已经出现外部协作方、生产环境配置或跨项目共享资源，建议直接补齐授权方式、审批要求、有效期和复核周期，因为这几类场景最容易出现权限沉淀。
权限矩阵和平台里实际配置的角色权限不一致，以哪个为准？
矩阵是授权规则的书面依据，平台配置是规则的执行结果，两者应当对应。出现不一致时，先确认是矩阵未及时更新，还是平台中存在未经登记的临时授权。处理方式是把差异逐条登记：属于规则变更的更新矩阵并记录变更依据，属于临时授权的补填有效期和复核责任人，属于误配的直接回收。定期复核时把“矩阵与平台配置比对”作为固定动作，可以避免差异长期积累。
外部协作方的权限行应该怎么填？
外部协作方建议单独建角色，不与内部岗位混用。数据范围写到具体项目或指定资源，有效期写明确切到期条件，例如合同结束日或项目验收后若干天，授权方式标注为临时授予，审批要求写明由谁审批。备注中记录协作依据，便于复核时判断是否续期。这样在合同结束时可以按角色一次性回收，不必逐人排查。
矩阵建好后，新增一个平台模块需要改哪些表？
先判断新模块是否构成可独立授权的对象：是则进入对象清单，分配编号、标注层级和敏感级别；仅作为已有对象属性存在的，不单独建行。随后在主表补充该对象的权限行，新对象默认不对任何角色开放，需要逐条授予。如果新模块引入了新的职责分工，再同步更新角色清单。三张表改完后记录一次变更，写明变更日期、变更人和依据。
复核周期应该怎么定，所有权限行都用同一个周期可以吗？
可以按敏感级别分档，不必所有行统一。高敏感对象如生产环境配置、代码主干权限，周期可以短一些；稳定的只读权限可以适当延长。临时授予的权限以到期条件为准，到期即回收，不依赖例行复核。复核周期与复核责任人配套填写，责任人写岗位，人员变动时只需调整岗位承担者，不必逐行改表。
