RACI职责草案

用途

把事项说明与干系人名单，整理成一张 RACI 职责草案表，便于会议对齐：

• R 负责执行
• A 批准拍板（每行活动建议仅 1 个 A）
• C 咨询后执行
• I 事后知会

空表见 references/raci-template.md。

本技能产出草案：需干系人确认后才算数；不改 HR/组织系统，不代替正式任命，不编造未提供的人名与职责。

适用场景

• 适合: 跨部门项目启动、活动上线、职责模糊需要一张表对齐。
• 不适合: 改岗位编制、绩效打分、会后待办拆解、对外公关声明。

怎么使用(普通用户)

在 AI 助手里直接说，例如:

• 「用 RACI职责草案，把下面事项理成一张表」
• 「这件事谁负责谁拍板，帮我做 RACI」
• 「职责有争议的标出来，别擅自定」

使用步骤

1. 收集输入

缺干系人时先问，不凭空补组织架构。

2. 拆活动行

从素材抽出 3–10 条可分配活动（动词开头）。过大活动拆开；过细合并。

3. 填 RACI 并检查

• 每行优先保证有 R 与唯一 A
• 多人争 A、无人 R、同一人既 R 又 A 且用户未说明时：写入「规则检查」与「待确认」，不擅自裁定
• 不确定格子用 ?

4. 输出草案

使用下方格式；标题标明「草案（待对齐确认）」。

输出格式

# RACI 草案：{事项}

## 元信息
- 事项范围: …
- 干系人: …
- 状态: 草案（待对齐确认）

## RACI 表
| 活动 | …角色列… |
| --- | --- |

## 规则检查
- …

## 待确认
- …

## 一句话提醒
不构成组织任命；以确认后版本为准。

示例

示例 1: 职责清晰(可直接成表)

输入:
事项: 新品落地页上线
干系人: 产品小王、设计小李、研发老周、运营小陈、市场总监赵总
素材: 小王出需求，小李出视觉，老周开发，小陈配投放，上线由赵总最终点头；文案需咨询小陈。

输出:
# RACI 草案：新品落地页上线

## 元信息
- 事项范围: 需求→设计→开发→投放配文→上线批准
- 干系人: 产品小王、设计小李、研发老周、运营小陈、市场总监赵总
- 状态: 草案（待对齐确认）

## RACI 表
| 活动 | 小王 | 小李 | 老周 | 小陈 | 赵总 |
| --- | --- | --- | --- | --- | --- |
| 需求说明与验收口径 | R | C | C | I | A |
| 视觉设计 | C | R | I | C | A |
| 页面开发与联调 | C | C | R | I | A |
| 投放文案与渠道配置 | I | I | I | R | A |
| 上线批准 | C | I | C | C | A |

## 规则检查
- 每行 A: 当前均落在赵总（若需「活动级授权」是否拆分 A，待确认）
- 无人 R: 无
- 冲突: 无

## 待确认
- 「需求说明」的 A 是否必须是赵总，或可由小王自批
- 设计验收是否需要单独活动行

## 一句话提醒
不构成组织任命；以确认后版本为准。

示例 2: 争 A / 无人 R / 既 R 又 A(冲突场景)

职责本来就没理清时，本技能不替用户裁定：冲突格子填 ?，把三类问题写进规则检查，并在待确认里给出可直接拿去开会问的具体问法。

输入:
事项: 跨部门经营看板
干系人: 数据组老张、业务组小刘、IT 老陈、合规小周
素材: 看板要展示哪些指标，业务组和数据组都说应该自己定。取数脚本还没定谁写，两边都说不是自己的活。老陈说底层接口他开发、也由他自己验收。小周只要求上线前知会他一声。

输出:
# RACI 草案：跨部门经营看板

## 元信息
- 事项范围: 指标口径定义→取数脚本→底层接口开发与验收→上线知会
- 干系人: 数据组老张、业务组小刘、IT 老陈、合规小周
- 状态: 草案（待对齐确认）—— 存在 3 处未裁定冲突

## RACI 表
| 活动 | 老张 | 小刘 | 老陈 | 小周 |
| --- | --- | --- | --- | --- |
| 指标口径定义 | R/A? | R/A? | I | I |
| 取数脚本开发 | ? | ? | I | I |
| 底层接口开发 | I | I | R | I |
| 底层接口验收 | ? | ? | A? | I |
| 上线知会 | C | C | C | I |

## 规则检查
- **多人争 A**: 「指标口径定义」老张与小刘均主张拍板权，双方均标 `R/A?`，未裁定
- **无人 R**: 「取数脚本开发」两侧均表示非本方职责，整行无 R，全部标 `?`
- **既 R 又 A**: 「底层接口」老陈自开发自验收，已拆为开发/验收两行；验收行 A 标 `A?`，提示自验风险
- 唯一 A 规则: 5 行中仅 2 行满足（底层接口开发行无 A，需补）

## 待确认
- 「指标口径定义」最终由谁拍板？建议二选一：业务组定业务口径、数据组定计算口径，拆成两行分别给 A
- 「取数脚本开发」归属：是数据组承接，还是由 IT 统一开发？若均不承接，需上级指派 R，否则该活动无法启动
- 「底层接口验收」是否接受开发者自验？若需第三方验收，候选为老张或小刘
- 小周的知会时点：上线前多久、以什么形式（邮件/群/工单）

## 一句话提醒
不构成组织任命；以确认后版本为准。

对照要点：示例 1 素材已给出明确分工，可直接成表；示例 2 的三类冲突都如实暴露在规则检查里，不用「一般来说数据组定口径」这类行业常识替用户拍板。? 与 A? 是有意保留的信号，供开会时逐个消解。

常见问题(FAQ)

• 只有角色没有人名: 可用角色名填表，并在待确认写「需落到具体人」。
• 用户要求指定某人当 A: 按其指定填写，并注明来自用户指令。
• 与会后待办混淆: 本技能不产出截止日期待办表；需要时请用行动清单类技能。

已知限制

• 不连接组织架构/HR/项目管理系统。
• 不做薪酬或编制建议。
• 复杂治理（双 A、委员会）需用户说明规则后再填。

变更说明

• 0.1.1: 补「争 A / 无人 R / 既 R 又 A」冲突场景完整对照示例，演示 ? 与 A? 的用法、规则检查三类问题的写法，以及不用行业常识替用户裁定的边界。
• 0.1.0: 首发。把事项与干系人整理成 RACI 职责草案表供对齐确认。