帮你用一张表消掉交付项目里大半的后期扯皮。
文中核心拆解是：交付中最常见的冲突不是技术问题，而是「谁负责」的默会假设不一致——客户以为厂商负责数据质量，厂商以为客户负责，双方都按自己的假设投入，验收时才发现错位。开工第一周画出 RACI 并与客户共同确认，把假设变成显性契约。最容易出现误用的地方是一行任务出现两个 A（Accountable），等于没人敢拍板或两人互相等待。
相比把 RACI 当项目管理形式主义的普遍看法，这篇强调它在 AI 交付里尤其关键：数据准备、指标确认、验收判定这些任务的归属天然模糊。表格不值钱，值钱的是双方共同确认的过程。
建议你为当前项目列出十项最关键任务，逐项填上四类角色并与客户对一遍，并约定人员变动的更新规则。
—— FDEChina编辑部 · 实战派
定义
RACI 矩阵用四类角色为每项关键任务标注责任归属：Responsible 执行、Accountable 拍板负责、Consulted 被咨询、Informed 被告知，是交付项目最常用的责任澄清工具。
展开
FDE 交付中最常见的冲突不是技术问题，而是「谁负责」的默会假设不一致：客户以为厂商负责数据质量，厂商以为客户负责，双方按各自假设投入，验收时才发现错位。开工第一周画出 RACI 并与客户共同确认，把假设变成显性契约，后期扯皮量会明显下降。确认过程本身也是一次范围对齐，很多误解在填表阶段就被提前化解。
常见误用是一行任务出现两个 A：要么没人敢拍板，要么两人互相等待，矩阵反而制造僵局；另一类是矩阵做完就归档，人员变动后不更新，引用时发现早已过时。与干系人地图的分工：干系人地图回答「影响谁、找谁」，RACI 回答「谁做、谁定」，前者用于关系经营，后者用于任务执行，配套使用效果最好。