RACI矩阵填写模板是一张以任务为行、以角色为列的空白表，每个交叉格只填R、A、C、I中的一个字母。本文提供可直接复制到文档或表格工具中的空白模板，逐项说明四个字段的判断标准与必填规则，并用一个研发迭代的演示示例把表格填满，方便你对照完成自己团队的职责矩阵。
要点总览（TL;DR）
- 空白模板以任务为行、角色为列，单元格只填R、A、C、I四个字母，可直接复制到文档或表格工具中使用。
- R是实际执行任务的人，A是对结果最终负责并拥有批准权的人，C在决策前提供意见，I在结果确定后被通知。
- 每行必须有且只有一个A、至少一个R；C和I按需填写，没有对应角色的格子留空。
- 研发迭代示例覆盖需求评审、技术方案设计、功能开发、测试用例编写、版本发布和迭代复盘，演示了A与R分离及合并两种情形。
- 角色增减、任务拆分或人员变动时同步更新矩阵，并让矩阵中的负责人与实际工作项保持一致。
可复制空白RACI矩阵模板
下面这张表可以直接复制到Word、Excel、在线文档或项目管理工具中。第一列写任务或活动，后面每一列写一个角色名称，交叉格填字母。表格保留了三行占位行，复制后按实际任务数量增删行即可。
| 任务/活动 | 角色1（填写角色名称） | 角色2 | 角色3 | 角色4 | 角色5 |
|---|---|---|---|---|---|
| 任务A（替换为具体活动） | |||||
| 任务B | |||||
| 任务C |
使用时有几条约定需要先固定下来。列头写角色而不是人名，例如“产品经理”“后端开发”“测试负责人”，人员变动时只换人、不改表结构。单元格只允许出现R、A、C、I四个字母，需要补充说明时写在表格下方的备注区，不往格子里塞文字。任务列尽量用动词开头，写成“完成需求评审”“提交测试报告”这类可判断完成状态的活动，避免“需求”“测试”这类名词导致职责边界模糊。
如果团队习惯在表格工具中操作，可以把首行冻结、给四个字母设置下拉选项，减少误填。空白模板本身不区分项目阶段，需要按阶段分组时，在任务列前增加一列“阶段”，或在任务之间插入分组标题行。
R、A、C、I四个字段分别怎么填
四个字母对应四种不同的参与方式，判断时看这个人在该任务中实际做什么，而不是看他的职级高低。下表把含义、填写时机和常见误填放在一起对照。
| 字段 | 含义 | 填写判断依据 | 常见误填 |
|---|---|---|---|
| R（Responsible） | 实际执行任务、产出结果的人 | 问“这件事谁动手做”，答案就是R；可以有多个R，按分工分别标注 | 把审批人填成R；把只提供资料的人填成R |
| A（Accountable） | 对结果最终负责、拥有批准权的人 | 问“结果不合格时找谁”，答案就是A；每行只能有一个 | 一行填两个A；把A留给整个团队或“所有人” |
| C（Consulted） | 在决策或产出确定之前被咨询意见的人 | 问“这件事定下来之前必须听谁的意见”，双向沟通，意见可能改变方案 | 把事后才知道的人填成C；把所有人都填成C导致决策拖慢 |
| I（Informed） | 在结果确定之后被通知的人 | 问“结果出来后谁需要知道”，单向通知，不参与决策 | 把需要参与讨论的人降级为I；漏掉依赖该结果的上下游角色 |
判断顺序建议从A开始：先确认每件事谁最终拍板，再找实际执行的人填R，最后补充决策前需要征求意见的C和结果后需要知会的I。这个顺序能避免出现“人人都是R、没人对结果负责”的情况。C和I的区别在于时机和方向：C在决策前介入、意见会影响结论；I在结论形成后接收信息、不改变结论。同一个角色在不同任务中可以承担不同字母，例如测试负责人在“编写测试用例”一行是R，在“版本发布”一行可能是C或I。
必填与选填：哪些格子必须填、哪些可以留空
每一行有两个硬性要求：A必须有且只有一个，R至少有一个。这两项缺失，这一行的职责就没有交代清楚。C和I按实际需要填写，没有对应角色的格子留空即可，留空表示该角色在这项任务中不参与，不需要用字母填满整行。
- 必填项：每行一个A、至少一个R。填写完成后逐行检查，缺A的行说明没人对结果负责，缺R的行说明任务没有执行者。
- 选填项：C和I。数量没有上限，但C过多会让决策变慢，I过多会让通知变成噪音，建议每行C控制在两到三个、I控制在必要范围内。
- 同一格出现多个角色：如果一个格子需要表达“既执行又提供意见”，优先拆成两行任务，或把该角色填为R并在备注中说明其咨询职责。强行在一个格子里写“R/C”会让矩阵失去快速阅读的价值。
- 一行出现多个A：这是最常见的错误。修正方法是回到任务定义，问“最终由谁批准”，把A收敛到一个人，其余人改为C或R。如果确实存在联合批准，说明这项任务需要拆成两个子任务，各自有独立的A。
建议在模板底部加一行校验提示：每行A数量等于1、R数量大于等于1。用表格工具的条件格式或简单计数公式就能自动标出不合规的行，评审时先看校验结果再看内容。
研发项目填写示例：一个迭代的RACI矩阵
以下是一个研发迭代的演示示例，角色包括产品经理、开发负责人、测试负责人和项目经理，任务覆盖从需求评审到迭代复盘的典型环节。示例为演示情景，不对应任何真实项目，团队可按自己的角色设置替换列头。
| 任务/活动 | 产品经理 | 开发负责人 | 测试负责人 | 项目经理 |
|---|---|---|---|---|
| 需求评审 | A | C | C | R |
| 技术方案设计 | C | A/R | I | I |
| 功能开发 | I | A/R | I | I |
| 测试用例编写 | C | C | A/R | I |
| 版本发布 | I | R | C | A |
| 迭代复盘 | C | C | C | A/R |
逐行看这张表，可以核对字段说明是否一致。“需求评审”由项目经理组织执行（R），产品经理对评审结论最终负责（A），开发和测试在评审前提供可行性意见（C）。“技术方案设计”和“功能开发”由开发负责人既执行又对结果负责，这里A和R由同一人承担，在小型团队中很常见，前提是这个人确实既有执行动作又有批准权。“版本发布”把A放在项目经理、R放在开发负责人，体现发布决策与发布操作的分离；测试负责人在发布前提供质量意见，属于C。“迭代复盘”由项目经理组织并对改进结论负责，三个角色都在复盘前提供输入。
填写时注意两点。第一，示例中的“A/R”表示同一角色同时承担两个字母，如果团队要求每格只填一个字母，可以拆成两列或在该行备注中说明。第二，示例只列了四个角色，实际项目中如果有运维、设计、数据等角色，按需增加列，但每行的A仍然只能有一个。矩阵填完后，建议让每个角色确认自己所在列的内容，尤其是被标为C和I的格子，确认他们认可这个参与方式。
模板的调整与维护方法
RACI矩阵填完只是开始，团队角色和任务结构变化后如果不更新，矩阵会变成一份过期文档，反而误导协作。维护的重点是明确什么情况下改、改哪里、由谁负责。
| 调整触发条件 | 需要执行的动作 | 建议责任人 |
|---|---|---|
| 团队新增或减少角色 | 增加或删除对应列，检查受影响行的A和R是否仍然成立 | 项目经理 |
| 任务粒度过粗，一行包含多个交付物 | 拆分为多行，每行重新确认唯一A和至少一个R | 任务所属角色的负责人 |
| 出现职责争议或推诿 | 回到争议行核对A是否唯一、C是否在决策前介入 | 项目经理牵头，相关角色参与 |
| 迭代或项目阶段结束 | 复盘时同步评审矩阵，记录变更并更新版本号 | 项目经理 |
| 人员岗位变动 | 列头保持角色名称不变，更新角色对应的人员映射 | 项目经理 |
任务粒度方面，一行对应一个可判断完成状态的活动比较合适。如果一行里出现“设计并开发并上线”这类跨多个环节的描述，说明需要拆分。拆分后行数会增加，但每行的责任更清晰，评审时也更容易发现遗漏。版本管理上，可以在表格标题旁标注版本号和更新日期，重大调整时保留旧版本，方便追溯职责变化的原因。
矩阵还需要和日常的任务分配衔接起来，否则表上写的A和R与实际工作项中的负责人对不上。在ONES中，项目与工作项管理可以把任务分解、负责人和状态流转放在同一处，团队可以按RACI矩阵确定每类任务的负责人和协作角色，再落到具体工作项上执行；迭代复盘时对照矩阵检查职责是否按预期运转。这样矩阵不只是文档里的一张表，而是和任务执行保持同步的职责依据。角色增减或任务拆分后，同步更新矩阵和工作项中的负责人设置，能减少“表上有人负责、实际没人推进”的情况。
常见问题
一个小团队里，A和R可以由同一个人承担吗？
可以。A和R由同一人承担的前提是这个人既实际执行任务，又拥有对结果的批准权。研发示例中的“技术方案设计”“功能开发”就是这种情况，开发负责人既动手做也对结果负责。团队规模较小时这种安排很常见，能减少沟通环节。需要留意的是，当任务涉及跨角色验收或对外交付时，把A与R分开更有利于形成制衡，例如“版本发布”一行由项目经理承担A、开发负责人承担R。
矩阵里同一个格子想同时表达执行和咨询，应该怎么处理？
建议优先拆行。把“既执行又提供意见”的活动拆成两个可判断完成状态的任务，各自确认唯一的A和至少一个R，咨询关系放到对应行里表达。如果确实无法拆分，可以把该角色填为R，并在表格下方的备注区说明其咨询职责。不建议在格子里写“R/C”这类组合字母，它会让矩阵失去快速扫读的作用，评审时也容易产生歧义。
C填得太多会有什么影响，怎么控制数量？
C表示决策前必须征求意见的人，人数过多会拉长决策周期，也容易让责任边界变模糊。控制方法是从任务本身出发，只保留意见会实质影响方案的角色，每行C通常控制在两到三个。对于只需要了解进展、不改变结论的角色，填I更合适。矩阵填完后可以让被标为C的角色确认自己是否真的需要在决策前介入，避免出于习惯把相关方都列为C。
矩阵填好后，怎么和实际的任务分配对上？
矩阵确定的是角色层面的职责关系，落地时需要把每类任务的A和R对应到具体工作项的负责人。可以在迭代开始时按矩阵设置工作项负责人，迭代复盘时对照矩阵检查实际执行是否偏离。在ONES中，项目与工作项管理支持任务分解、负责人设置和状态流转，团队可以据此把矩阵中的职责落到具体工作项上，减少表上有人负责、实际没人推进的情况。角色或任务调整后，两边同步更新。
跨部门项目里角色很多，列数太多怎么处理？
列数过多时，可以按项目阶段拆成多张矩阵，例如需求阶段、开发阶段、发布阶段各一张，每张只保留该阶段实际参与的角色。也可以把职责相近的角色合并为一个列头，例如把多个开发岗位合并为“开发团队”，再在备注中说明内部分工。无论怎么拆，每行的A仍然只能有一个，R至少一个，这条规则不随列数变化。拆分后的多张矩阵建议统一编号和版本，方便对照。
