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

2026年11月5日

RACI矩阵填写模板是一张以任务为行、以角色为列的空白表，交叉格填写R（执行）、A（最终负责）、C（事先咨询）、I（事后知会）四类字母。本文提供可直接复制的精简版与完整版空白表、四个字段的填写判断、必填与选填规则，并用一个迭代从需求评审到上线发布的研发示例演示如何填满整张表，最后说明团队和项目变化后如何调整维护。

Table of Contents

要点总览（TL;DR）

RACI矩阵填写模板以任务为行、角色为列，交叉格填R（执行）、A（最终负责）、C（事先咨询）、I（事后知会）四类字母，本文提供精简版和完整版两张可直接复制的空白表。
填写时每行必须有且只有一个A，至少一个R；C和I按需设置，留空表示该角色不参与这项任务。
判断字母时问四句话：谁动手做（R）、谁最终拍板负责（A）、产出前必须听谁的意见（C）、结果确定后要通知谁（I）。
研发示例覆盖需求评审、方案设计、编码开发、测试验收、上线发布五个环节，每行一个A，A通常落在产品经理或研发负责人身上。
矩阵在项目启动时确认、阶段节点复核，角色列和任务行随团队与项目阶段调整，A变更时由新旧A共同确认交接。

可复制空白RACI矩阵模板

下面两张表可以直接复制到文档或表格工具中使用。精简版适合3–4个核心角色的项目组，完整版适合角色分工更细的研发团队。复制后先保留表头，按项目实际情况增删角色列和任务行，再逐格填写字母。

精简版（3–4个角色）

任务编号	任务/活动	交付物	角色1	角色2	角色3	角色4	备注
T01
T02
T03
T04
T05

完整版（6–8个角色）

任务编号	任务/活动	交付物	角色1	角色2	角色3	角色4	角色5	角色6	角色7	角色8	备注
T01
T02
T03
T04
T05
T06
T07
T08

复制到表格工具后，把“角色1、角色2……”替换为实际岗位名称，例如产品经理、研发负责人、开发工程师、测试工程师、项目经理。任务行按项目阶段顺序排列，交付物一列写清该任务产生的具体产物，备注用于记录“需法务会签”“仅本迭代适用”等特殊约定。角色列超过8个时，建议先合并相近职责，避免矩阵过宽难以阅读。

R、A、C、I四个字段分别怎么填

四个字母对应四种参与方式，填写时对每个交叉格问一句判断问句，答案明确就落字母，不参与就留空。判断的核心是区分“动手做”“拍板负责”“事前征求意见”“事后被告知”四件事。

字母	含义	判断问句	填写规则	常见填错
R	执行者，实际动手完成任务的人	这件事主要由谁动手完成？	可以多人，按任务实际投入填写	把只提建议的人填成R
A	最终负责，对结果拍板并承担最终责任	结果出问题时，最终由谁拍板并负责？	每行有且只有一个A	一行填两个A，导致无人真正负责
C	事先咨询，决策或产出前需征求意见	产出前必须听谁的意见？	双向沟通，按需设置，可多人	把只需知会的人填成C，增加沟通成本
I	事后知会，结果确定后被告知	结果确定后需要通知谁？	单向沟通，按需设置，可多人	把需要参与决策的人降为I

R与A可以由同一人承担，也可以分开。小团队里产品经理既执行需求文档撰写又对需求结果负责，同一格可填A、另一格填R；角色分工较细时，开发工程师是编码任务的R，研发负责人是该任务的A。判断一行是否合格，看两点：至少有一个R，说明事情有人做；有且只有一个A，说明结果有人负责。

空格是合法填写，表示该角色不参与这项任务。留空要有依据，不能因为暂时没想到就空着。填写时可以先粗填一遍，再逐行检查：每个空格问一句“这个角色真的不参与吗”，每个字母问一句“这个参与方式准确吗”。C和I的数量要克制，C过多会让决策变慢，I过多会让知会流于形式。

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

一张合格的RACI矩阵，任务信息和责任归属必须完整，参与方式按实际需要设置。下表给出各列的填写要求。

列	填写要求	说明
任务编号	必填	用于引用和后续调整，建议按阶段或顺序编号
任务/活动	必填	用动词开头描述具体活动，避免“相关事项”这类模糊表述
交付物	建议填写	写清任务产出的具体文档、代码或版本，便于验收
A列	必填，每行一个	没有A或出现多个A都视为不合格
R列	必填，至少一个	按任务实际执行情况填写，可多人
C列	选填	留空表示不需要事先咨询
I列	选填	留空表示不需要事后知会
备注	选填	记录特殊约定、例外条件或待确认事项

提交前用下面这份清单自查：每行是否都有任务编号和任务名称；每行是否恰好一个A；每行是否至少一个R；C和I是否都有明确的沟通理由；备注中的待确认事项是否已闭环。出现一行多个A、整行无A、整行无R这三种情况，需要退回修改后再使用。

研发项目填写示例：一个迭代的需求到上线

以下示例为演示情景，角色设置为产品经理、研发负责人、开发工程师、测试工程师、项目经理，任务覆盖一个迭代从需求评审到上线发布的五个环节。示例遵循前文的字段规则：每行一个A、至少一个R，C和I按需设置。

任务编号	任务/活动	交付物	产品经理	研发负责人	开发工程师	测试工程师	项目经理	备注
T01	需求评审	评审通过的需求说明	A/R	C	C	C	I	评审结论需记录
T02	方案设计	技术方案文档	C	A	R	C	I	涉及接口变更需同步测试
T03	编码开发	可提测的代码与自测记录	I	A	R	I	I	按任务拆分到开发工程师
T04	测试验收	测试报告与验收结论	C	A	C	R	I	验收标准以需求说明为准
T05	上线发布	上线记录与发布说明	I	A	R	C	I	发布窗口由项目经理协调

逐行看分配理由。需求评审的A是产品经理，因为需求范围和优先级由产品经理最终拍板，产品经理同时承担撰写和讲解的R；研发负责人、开发工程师、测试工程师列为C，是因为评审前需要他们从技术可行性和可测性角度提意见；项目经理列I，只需在评审后了解结论并安排后续排期。

方案设计的A是研发负责人，对技术方案的最终质量负责，开发工程师是主要执行者；产品经理和测试工程师列C，分别确认需求覆盖和可测性。编码开发的A仍在研发负责人，R落到具体开发工程师，产品经理和测试工程师列I即可，避免开发过程中被频繁打断。

测试验收的A是研发负责人，对交付质量承担最终责任，测试工程师是R，负责执行测试并输出报告；产品经理列C确认验收标准，开发工程师列C以便快速定位缺陷。上线发布的A是研发负责人，开发工程师执行发布操作，测试工程师列C确认上线前回归结果，产品经理和项目经理列I，在发布完成后获知结果。整张表每行恰好一个A，与前一节的必填规则一致。

矩阵确认后，职责需要落到日常协作的载体上。ONES可以在工作项和文档中记录任务负责人、协作人与评审记录，让矩阵里的A和R对应到具体工作项，C和I对应到评审与通知环节，减少矩阵与实际执行脱节的情况。具体字段配置以团队实际使用的功能为准。

模板的调整与维护方法

RACI矩阵在项目启动时确认，在阶段节点复核，团队或任务发生变化时同步更新。矩阵过期比没有矩阵更容易造成误解，维护动作要跟着项目节奏走。

角色列增删：团队结构调整时，先确认新角色的职责是否已被现有角色覆盖，能合并就合并；新增角色列后，逐行检查该角色在各项任务中的参与方式，避免整列空白或整列都是I。
任务行拆分或合并：项目进入新阶段时，把跨阶段的大任务拆成可验收的小任务，例如把“开发与测试”拆成编码开发和测试验收两行；阶段性任务结束后可合并归档，保持表格聚焦当前迭代。
维护节奏：项目启动会上确认初版矩阵，迭代计划会、里程碑评审等节点复核一次，重点检查A是否仍然唯一、R是否与实际分工一致。
变更通知：调整后把变更点和影响范围通知相关角色，涉及A变更时由新旧A共同确认交接，避免责任真空。
与职责文档衔接：矩阵中的角色定义与岗位职责说明保持一致，任务分配时以矩阵中的A和R为依据，评审和通知环节对应C和I，形成从职责定义到任务执行的闭环。

维护时保留变更记录，注明调整日期、调整原因和确认人，下次复核时可以直接对照。矩阵长期不更新时，优先检查任务行是否还对应真实工作，再检查角色列是否还对应现有团队。

常见问题

小团队角色少，RACI矩阵还需要每个字母都填吗？

不需要。R和A是每行的必填项，C和I按实际沟通需要设置。三四个人的小团队里，很多任务的事先咨询和事后知会可以通过日常沟通完成，对应格子留空即可。判断标准是：如果漏掉某个角色的意见会导致返工，就填C；如果结果确定后不通知会影响其后续工作，就填I。其余情况留空，矩阵反而更清晰。

同一项任务里，A和R可以是同一个人吗？

可以。R与A是否分开取决于角色分工的粗细。小团队里产品经理既撰写需求文档又对需求结果负责，同一行里产品经理可以同时承担R和A；分工较细时，开发工程师是编码任务的R，研发负责人是该任务的A。需要守住的是每行只有一个A，R可以多人，A与R是否重合不影响合格判定。

矩阵填好后，怎么和日常任务分配衔接起来？

把矩阵中的A和R对应到具体工作项的负责人和协作人，C和I对应到评审环节与通知对象。矩阵确认后，职责需要落到日常协作的载体上。ONES可以在工作项和文档中记录任务负责人、协作人与评审记录，让矩阵里的A和R对应到具体工作项，C和I对应到评审与通知环节，减少矩阵与实际执行脱节的情况，具体字段配置以团队实际使用的功能为准。矩阵本身作为职责依据保留，任务分配时以它为准，避免两套口径。