RACI矩阵用一张“任务×角色”的表格，把每项任务上的角色标成R、A、C、I：R负责实际执行并交付结果，A对结果负最终责任并拥有拍板权，C在定稿前提供意见，I在结果确定后收到通知。本文先给一份可直接复制的空白表格，再逐字段说明填写标准、必填规则，并用一个版本发布任务演示完整填法。
要点总览（TL;DR）
- RACI矩阵用“任务×角色”的表格把每项任务的职责标成R、A、C、I：R是实际执行并交付结果的人，A是对结果负最终责任并拍板的人，C是定稿前需要征询意见的人，I是结果确定后需要被告知的人。
- 填写顺序是：先列任务与交付物，再列角色，然后逐行填字母；每行必须有且仅有一个A，至少有一个R，C和I按需选填。
- 判断填谁看动作不看职级：谁动手做填R，谁最终拍板填A，不问会返工的人填C，不通知会影响后续工作的人填I。
- 研发示例中，版本范围确认由产品经理A/R，功能开发由研发负责人A/R，回归测试报告由测试负责人A/R，发布上线由运维负责人A/R，发布通知与复盘由项目经理A/R，其余角色按需标C或I。
- 矩阵填好后要随任务拆分、角色交接和阶段推进更新，由项目经理或协作负责人组织确认，并保留版本与变更记录。
可复制空白RACI矩阵模板
下面这张表可以直接复制到文档或表格工具中使用。左侧列任务与交付物，右侧列参与角色，交叉格填写R、A、C、I中的一个或多个字母。角色列按项目实际情况增删，任务行按交付物逐条拆分。
| 任务 / 交付物 | 角色1 | 角色2 | 角色3 | 角色4 | 角色5 |
|---|---|---|---|---|---|
| 任务一（写明交付物名称） | |||||
| 任务二 | |||||
| 任务三 | |||||
| 任务四 | |||||
| 任务五 |
使用时有三个填写位置需要留意：表头第一列写任务或交付物，避免只写“开发”“测试”这类笼统动作，最好带上产出物，例如“发布说明文档”“回归测试报告”；表头其余列写角色名称，写岗位或具体人名均可，同一张表内保持一致；交叉格只填字母，不写备注，需要说明的内容放在表格下方的注释里。
如果任务较多，可以在第一列后增加“所属阶段”列，方便按阶段分组阅读；如果角色超过八个，建议拆成两张表，分别覆盖不同阶段，避免单表过宽难以核对。
R、A、C、I四个字段分别怎么填
四个字母的判断依据是“这个人在该任务上做什么动作”，而非其职级高低。填写时逐个任务追问：谁动手做、谁最后拍板、谁的意见必须在定稿前听到、谁在结果出来后必须知道。
R：实际执行并交付结果的人
R填给真正动手完成任务、产出交付物的人。判断标准是：任务完成后，交付物出自谁手，谁就对得上R。一个任务可以有多个R，例如前后端各一人共同完成一个功能开发，两人都填R，但要在注释中写清各自负责的部分，避免出现“都以为对方在做”的空档。
A：对结果负最终责任的人
A填给对这项任务结果负责、拥有拍板权的人。判断标准是：结果出问题时，谁需要最终解释并决定返工或放行。每行只能有一个A，这是RACI矩阵最关键的约束。常见误填是把部门负责人都标成A，导致决策链模糊；正确做法是每项任务只落到一位最终负责人，其余管理者通过C或I参与。
C：定稿前需要被征询的人
C填给意见会影响交付物内容、且必须在定稿前被问到的人。判断标准是：如果没问这个人，交付物很可能被推翻或返工，就应标C。C是双向沟通，填写时最好在注释中写明需要征询的具体方面，例如“安全合规意见”“接口兼容性意见”，让被征询者知道该看什么。
I：结果确定后需要被告知的人
I填给只需在结果确定后收到通知的人，通常是上下游依赖方、需要同步进度的管理者或后续接手团队。判断标准是：这个人不需要参与过程讨论，但不知道结果会影响其后续工作。I是单向通知，填写时应明确通知时机，例如“发布完成后同步”“测试报告出具后同步”。
四个字母的常见误填
| 误填情形 | 问题 | 调整方式 |
|---|---|---|
| 一行出现两个及以上A | 决策责任分散，出现分歧时无人拍板 | 合并为一位A，其余改为C |
| 只有A没有R | 有人负责但无人执行，任务落空 | 补充实际执行角色为R |
| 把所有人都标成C | 征询范围过大，定稿周期被拉长 | 只保留意见会改变结果的人为C |
| 把I当成“顺便抄送” | 通知对象过多，重要信息被淹没 | 只保留结果影响其后续工作的人为I |
| 同一人在一行同时标A和R | 小团队中常见，但需确认是否真的既拍板又执行 | 可以保留，需在注释中说明，避免责任混淆 |
必填与选填：每行至少要有哪些字母
一行RACI是否合格，可以用两条硬规则加一条检查规则来判断。硬规则决定这行能不能用，检查规则决定这行填得好不好。
- 必须有且仅有一个A。这是每行的必要条件。缺少A，任务没有最终负责人；出现多个A，责任无法收敛。发现两个A时，先确认谁拥有最终拍板权，另一位通常应改为C。
- 至少有一个R。没有R的行意味着任务无人执行，即使有A也只是挂名。若任务确实由外部团队完成，也应把外部对接人填入R列，或在注释中写明执行方。
- C和I按需选填。不是每个任务都需要C和I。判断方法是：不问会返工的人填C，不通知会影响后续的人填I，两者都不成立就留空。
关于同一角色在一行兼任多个字母，边界在于是否会产生责任冲突。R与C由同一人担任通常没有必要，因为执行者对自己的产出自然有意见，此时保留R即可；A与R由同一人担任在小团队中常见，可以保留，但要在注释中说明该角色既拍板又执行；A与I由同一人担任没有意义，保留A即可。填写完成后逐行扫描：每行是否只有一个A、是否至少有一个R、是否有整列全空或全满的角色，这三项检查通过，矩阵基本可用。
研发项目填写示例：一个版本发布任务
以下示例为演示情景，用于说明字段如何落到具体任务上，不代表任何真实项目。假设一个研发团队准备发布V2.3版本，涉及产品、研发、测试、运维和项目经理五类角色。
任务清单按交付物拆为五项：版本范围确认、功能开发与自测、回归测试报告、发布上线、发布通知与复盘记录。角色清单为：产品经理、研发负责人、测试负责人、运维负责人、项目经理。
| 任务 / 交付物 | 产品经理 | 研发负责人 | 测试负责人 | 运维负责人 | 项目经理 |
|---|---|---|---|---|---|
| 版本范围确认 | A/R | C | C | I | I |
| 功能开发与自测 | C | A | I | I | |
| 回归测试报告 | I | C | A/R | I | |
| 发布上线 | I | C | C | A/R | I |
| 发布通知与复盘记录 | C | C | C | C | A/R |
逐行说明填写理由。“版本范围确认”由产品经理起草并拍板范围，因此产品经理为A/R；研发和测试需要在范围定稿前评估可行性，标C；运维和项目经理在范围确定后知晓即可，标I。“功能开发与自测”由研发负责人对交付质量负最终责任并组织执行，标A/R；产品经理对需求理解提供意见标C；测试和项目经理在开发完成后获知进度标I。
“回归测试报告”由测试负责人出具报告并对结论负责，标A/R；研发负责人需要就缺陷修复口径提供意见，标C；产品经理和项目经理在报告出具后知晓结果，标I。“发布上线”由运维负责人执行发布并对上线结果负责，标A/R；研发和测试在发布前提供变更与验证意见，标C；产品经理和项目经理在发布完成后获知，标I。“发布通知与复盘记录”由项目经理组织撰写并定稿，标A/R；其余角色在复盘前提供各自环节的输入，标C。
这张示例表体现了两个填写习惯：一是A与R合并时在格内写“A/R”，并在表下注释说明该角色既拍板又执行；二是每行只保留一个A，跨角色的意见通过C表达，避免出现多个拍板人。
模板的调整与维护方法
RACI矩阵在项目启动时填好只是第一步，任务拆分变化、角色交接和阶段推进都会让原表失效。维护的重点是让矩阵始终反映当前的任务与角色对应关系。
什么时候需要更新
出现以下情况时应修订矩阵：新增或取消交付物；任务从一个人交接给另一个人；角色发生替换或离岗；评审中发现某行缺少A或R；项目进入新阶段，原C或I的参与方式改变。更新时只改受影响的行，并在变更记录中写明修改原因和日期。
由谁评审和确认
矩阵的评审责任应落在项目经理或指定的协作负责人身上，由其组织各角色确认自己所在行的字母是否符合实际。确认方式可以是评审会上逐行过一遍，也可以由各角色在文档中留言确认。涉及A变更的行，必须由新的A本人确认，避免出现“被负责”的情况。
版本与变更记录怎么留
建议在矩阵下方保留一张变更记录表，字段包括修改日期、修改行、修改内容、修改人和确认人。矩阵本身按版本号管理，例如V1.0为启动版，V1.1为角色交接后的修订版。使用支持页面版本记录的协作工具时，可以直接查看历史版本并回滚，减少手工维护成本。
矩阵与任务分配、资源技能的边界
RACI矩阵回答的是“每项任务上谁扮演什么角色”，它不替代任务分配，也不解决人员技能是否匹配的问题。任务派给谁、某人是否具备完成能力，需要在任务管理和资源安排中另行处理。把矩阵当作职责共识的载体，把任务分配和技能匹配放在相应流程中，两者配合使用效果更清晰。
矩阵落地后，需要有一个团队都能访问、能持续更新的载体。ONES Wiki 支持页面模板库，可一键创建制式化文档，适合把RACI矩阵固化为可复用的页面模板；文档实时同步并记录页面版本，支持随时查看与回滚，便于保留每次修订的痕迹；同时支持为不同角色配置读写权限，让矩阵的编辑权限集中在维护人手中，其他角色按需查看。矩阵中的任务行还可以关联项目任务，使职责表与项目执行保持对应。具体可用范围以实际开通的版本功能为准。
常见问题
一个任务能不能有两个A？
不能。每行只能有一个A，这是RACI矩阵最关键的约束。出现两个A意味着决策责任分散，遇到分歧时无人拍板。发现两个A时，先确认谁拥有最终拍板权，另一位通常改为C，通过征询意见的方式参与。
小团队人手少，同一人既当A又当R可以吗？
可以，但要在表格注释中说明该角色既拍板又执行。A与R由同一人担任在小团队中常见，前提是这个人确实既对结果负责又实际动手。需要留意的是，R与C由同一人担任通常没有必要，执行者对自己的产出自然有意见，保留R即可；A与I由同一人担任没有意义，保留A即可。
C和I是不是每个任务都要填？
不需要。C和I按需选填，判断方法是：不问会返工的人填C，不通知会影响后续工作的人填I，两者都不成立就留空。把所有人都标成C会拉长定稿周期，把I当成顺便抄送会让重要信息被淹没。
矩阵填好后，任务拆分变了怎么办？
新增或取消交付物、任务交接、角色替换或离岗、评审中发现某行缺少A或R、项目进入新阶段时，都应修订矩阵。更新时只改受影响的行，并在变更记录中写明修改原因和日期。涉及A变更的行，必须由新的A本人确认。
RACI矩阵能代替任务分配吗？
不能。RACI矩阵回答的是每项任务上谁扮演什么角色，任务派给谁、某人是否具备完成能力，需要在任务管理和资源安排中另行处理。把矩阵当作职责共识的载体，把任务分配和技能匹配放在相应流程中，两者配合使用更清晰。
矩阵放在哪里维护比较方便？
矩阵需要有一个团队都能访问、能持续更新的载体。ONES Wiki 支持页面模板库，可一键创建制式化文档，适合把RACI矩阵固化为可复用的页面模板；文档实时同步并记录页面版本，支持随时查看与回滚，便于保留每次修订的痕迹；同时支持为不同角色配置读写权限，让编辑权限集中在维护人手中。矩阵中的任务行还可以关联项目任务，使职责表与项目执行保持对应。具体可用范围以实际开通的版本功能为准。
