研发平台权限矩阵模板：空白表、字段说明与填写示例

研发平台权限矩阵是一张按“角色×资源×操作”逐格标注授权结果的空白表，用于在平台配置前统一评审授权口径。本文提供可直接复制填写的空白矩阵表、字段定义、必填与选填判定规则、一份完整填写示例，以及矩阵随组织和项目变化时的调整维护方法，帮助研发负责人把权限讨论从口头约定落到可核对的表格上。

要点总览（TL;DR）

• 空白权限矩阵按“角色×资源×操作”逐行填写，授权结果统一使用“允许、只读、需审批、不授权”四种取值。
• 角色编号、角色名称、资源、操作、授权结果五项为必填；数据范围在授权生效时必填，审批人在“需审批”时必填。
• 留空表示尚未讨论，需在评审中补齐；显式写“不授权”表示已作出否定结论，可直接进入平台配置。
• 矩阵评审通过后按角色编号对应到平台权限配置，并以变更记录和复核周期维持矩阵与实际配置一致。

可复制空白权限矩阵表

空白表采用“一行一个角色、一列一个资源操作组合”的结构。复制到表格工具后，先保留表头，再按实际角色逐行填写。单元格只写授权结果，不写解释性长句，解释放在备注列，便于横向比较不同角色的差异。

表头字段约定如下：角色编号用于稳定引用；角色名称写岗位或职责称谓；资源写被访问的对象；操作写动作；授权结果按统一枚举填写；数据范围写可见或可操作的对象边界；条件写生效前提；审批人写授权决定者；复核周期写下次检查时间；备注写补充说明。

角色编号	角色名称	资源	操作	授权结果	数据范围	条件	审批人	复核周期	备注
R-01
R-02
R-03
R-04
R-05

单元格取值约定：授权结果统一使用“允许”“只读”“需审批”“不授权”四种取值，避免出现“可以”“视情况”等无法执行的表述。数据范围写具体边界，例如“本项目全部代码库”“本人负责的模块”“所在部门文档”。条件写触发前提，例如“仅工作日”“需项目负责人确认”。同一角色对同一资源的多个操作，分行填写，不合并到一格。

矩阵字段说明：每一列填什么

字段说明的作用是让不同部门填出的表可以互相对照。每个字段只承担一种信息，填写时按定义落到具体对象，避免同一列混入授权结论和背景描述。

字段	含义	填写口径
角色编号	角色的稳定标识	按“R-序号”编写，角色名称调整时编号不变
角色名称	承担该权限的岗位或职责	写岗位称谓或职责名，如“后端开发工程师”“项目负责人”，不写具体人名
资源	被访问或操作的对象	写平台中的对象类型或对象集合，如“代码库”“需求工作项”“构建流水线”“测试用例”
操作	对资源执行的动作	使用平台动作词，如“查看”“新建”“编辑”“删除”“导出”“配置”
授权结果	该角色对该资源该操作的授权结论	只填“允许”“只读”“需审批”“不授权”之一
数据范围	授权生效的对象边界	写项目、部门、模块或个人范围，范围要能被平台配置项对应
条件	授权生效的前提	写时间、流程或状态前提，无条件时填“无”
审批人	授权决定的责任人	写岗位而非人名，如“项目负责人”“部门负责人”“平台管理员”
复核周期	下次复核该授权的时间间隔	写“每季度”“每半年”“随项目结项”等可执行周期
备注	补充说明	写例外原因、关联制度或待确认事项

授权结果的四种取值含义需要统一：允许表示可直接执行；只读表示可查看不可修改；需审批表示操作前须经审批人确认；不授权表示该角色不具备该操作。数据范围与条件分开填写，范围回答“对哪些对象”，条件回答“在什么前提下”，两者混写会导致平台配置时无法对应。

必填与选填：哪些格子不能空

必填判定的目标是让每一行都能直接转化为平台配置项。角色编号、角色名称、资源、操作、授权结果五项构成一行授权的最小完整信息，缺任何一项，这一行都无法执行，也无法复核。

字段	必填/选填	判定理由
角色编号	必填	用于跨版本引用和变更记录定位
角色名称	必填	让人能识别授权对象
资源	必填	缺少资源则授权无对象
操作	必填	缺少操作则无法确定动作边界
授权结果	必填	空白格无法判断是未讨论还是不授权
数据范围	必填（授权结果为允许、只读、需审批时）	不写范围会导致授权被默认放大到全平台
条件	选填	无附加前提时填“无”，不适用时可留空
审批人	必填（授权结果为需审批时）	需审批必须有明确决定人
复核周期	必填	保证授权有到期检查点
备注	选填	用于记录例外和待确认事项

留空与显式标注“不授权”含义不同：留空表示该格尚未讨论或尚未确认，需要在评审中补齐；显式写“不授权”表示已作出否定结论，可以直接进入配置。评审时先统计留空格数量，留空格清零后再进入平台配置，可以避免把未讨论的权限默认放开。

填写示例：一个研发项目的完整矩阵

以下为演示情景：某研发项目组在平台中管理代码库、需求工作项、构建流水线和测试用例四类资源，角色设为项目负责人、后端开发工程师、测试工程师和访客四类。示例用于说明字段如何落到具体格子上，实际填写时按团队真实角色替换。

角色编号	角色名称	资源	操作	授权结果	数据范围	条件	审批人	复核周期	备注
R-01	项目负责人	代码库	配置	允许	本项目全部代码库	无	部门负责人	每半年	含分支保护规则配置
R-01	项目负责人	需求工作项	删除	需审批	本项目全部需求	需部门负责人确认	部门负责人	每半年	删除前留存导出记录
R-02	后端开发工程师	代码库	编辑	允许	本人负责的模块	无	项目负责人	每季度	跨模块修改需走评审
R-02	后端开发工程师	构建流水线	查看	只读	本项目全部流水线	无	项目负责人	每季度
R-03	测试工程师	测试用例	编辑	允许	本项目全部测试用例	无	项目负责人	每季度
R-03	测试工程师	代码库	查看	只读	本项目全部代码库	无	项目负责人	每季度	用于核对缺陷关联代码
R-04	访客	需求工作项	查看	只读	本项目已发布需求	仅项目周期内	项目负责人	随项目结项	结项后回收
R-04	访客	代码库	查看	不授权	—	—	项目负责人	随项目结项	已明确否定结论

关键格子的填写理由：项目负责人对代码库的“配置”写“允许”，因为分支保护规则属于项目内治理动作，由项目负责人承担；对需求工作项的“删除”写“需审批”，因为删除影响面大，保留部门负责人确认环节。后端开发工程师对代码库“编辑”限定在“本人负责的模块”，避免授权被放大到全项目。访客对代码库“查看”写“不授权”，是已作出的否定结论，与留空不同，配置时可直接关闭该入口。

矩阵评审通过后，需要把表中的角色、资源、操作和范围落到平台的角色配置中，并保留变更记录。以ONES为例，可以在平台管理侧按角色配置项目与工作项的访问和操作权限，矩阵中的授权结果对应到具体权限项，复核周期和备注可作为权限复查时的核对依据；矩阵作为评审底稿留存，平台配置作为执行结果，两者按角色编号对应，便于后续追溯某次授权调整的来源。

矩阵的调整与维护方法

权限矩阵在首次评审后进入维护阶段。维护的核心是让矩阵版本与平台实际配置保持一致，并在组织或项目变化时及时更新，避免出现表上已回收、平台仍开放的情况。

触发更新的常见情形包括：新增或撤销岗位、项目立项与结项、平台新增资源类型或操作、发生权限相关事件、组织架构调整。出现上述情形时，先定位受影响的行，再决定是修改授权结果、调整数据范围，还是新增角色行。

版本与变更记录建议保留以下字段：变更编号、变更日期、变更角色编号、变更字段、变更前取值、变更后取值、变更原因、审批人、生效日期。每次变更只记录实际改动的格子，不重写整张表，便于回溯。

定期复核按矩阵中填写的复核周期执行。复核时逐行核对授权结果与平台配置是否一致，重点检查“需审批”行是否仍有明确审批人、“只读”行是否被误改为可编辑、访客类角色是否在项目结项后回收。复核完成后更新复核日期，对已失效的角色行做清理，保留历史版本备查。

维护流程可以固定为：提出变更、评估影响行、审批、更新矩阵版本、同步平台配置、记录变更、到期复核。把这一流程与矩阵的复核周期字段绑定，可以让权限治理从一次性建表转为可持续的例行工作。

常见问题

矩阵里同一角色对同一资源有多个操作，应该合并成一行还是分行写？

分行写。每个“资源＋操作”组合占一行，授权结果、数据范围和条件都只针对这一格。合并到一行会让不同操作的授权结论混在一起，平台配置时无法逐项对应，复核时也难以判断哪一项被改动。

授权结果填“需审批”，审批人一栏可以写具体人名吗？

建议写岗位，例如“项目负责人”“部门负责人”“平台管理员”。岗位在人员变动时保持稳定，矩阵不需要因为换人而改版；具体人名可以放在备注或变更记录中，用于追溯某次审批的实际执行者。

项目结项后，矩阵中访客类角色的行怎么处理？

按矩阵中填写的复核周期或“随项目结项”这一条件执行回收：先在平台侧关闭对应权限，再在矩阵中更新该行状态或移入历史版本，并记录变更日期与审批人。保留历史版本便于后续查证结项时的授权口径。

矩阵和平台里的实际权限配置出现不一致，以哪个为准？

以评审通过的矩阵版本为授权口径，平台配置是执行结果。发现不一致时，先确认矩阵是否有已审批但未同步的变更，再修正平台配置或补记变更，使两者按角色编号重新对应。复核时逐行核对是发现这类偏差的主要方式。

团队规模较小，是否可以把角色合并，减少矩阵行数？

可以按实际职责合并角色，前提是合并后的角色在资源与操作上的授权结论一致。若两个岗位对同一资源的操作权限不同，仍应保留为不同角色行，否则矩阵无法表达差异，配置时容易把权限放大。