职场工具箱之 DACI：谁推动、谁拍板，会议自然短

短大纲（给忙人）

从文山会海到一天好几场会：我和"会议"这个老冤家

我跟会议打交道的历史，比很多读者的工龄都长。

最早是在国企。那时候的会叫"文山会海"——文件堆成山，会议开成海。大会套小会，小会套碰头会，碰头会结束还有"会后会"。一个议题经过传达、学习、讨论、汇报四轮下来，黄花菜都凉了。但你别觉得奇怪：在那种组织里，"开会"本身就是工作成果的一部分。 会议纪要写得好不好，比结论落没落地更重要。我当时也干过不少会议纪要的活，写了一摞又一摞，却很少见到有人把纪要里的"行动项"真正执行完。

后来到了外企，会议风格完全换了一套——短了、快了、密了。一天四五个在线会议是标配，有时候上一个会的 \"Thank you, bye\" 还没说完，下一个会的邀请已经弹出来了。在外企这些年我学到一个残酷的事实：会议多不等于协作好，反而说明异步沟通做得差。 很多会议本质上是一封 email 就能解决的事，但大家已经形成了\"不确定就拉个会\"的肌肉记忆。

更有意思的是：我第一家外企，就是做视频会议的。 按理说，会议工具做得越好，会议应该越少；现实往往相反——工具越顺手，大家越容易把\"拉个会\"当成默认选项。好在那种环境里我也学到一个非常救命的习惯：决策要 document down，会上定了什么、谁负责什么，必须写下来发出来。这个习惯救了我很多次。

两个时代，会议的形式变了——从线下大会议室变成视频会议小窗口，从纸质签到变成日历邀请——但病根一直没变：

谁在推动？谁来拍板？没人知道。

DACI 就是专治这个的。

1) DACI 是什么：把"推进"和"拍板"拆成两个动作

DACI 四个角色：

• D - Driver（推动者）：负责把决策推进到发生（拉人、收集信息、组织讨论、催截止日期）
• A - Approver（拍板者）：最终决策人，通常只有一个（最好只有一个）
• C - Contributors（贡献者）：提供数据、方案、风险评估的人（可以很多）
• I - Informed（知会者）：需要知道结果的人（不参与决策）

最重要的两句话：

• Driver 负责让决策发生。
• Approver 负责让结果成立。

回想国企时代，最大的问题就是"人人都是 Contributor，没有 Driver，Approver 在开另一个会"。到了外企，问题变了个形：Driver 倒是有了（通常就是发会议邀请的那个人），但 Approver 不明确——大家都觉得自己可以提意见，却不知道谁有权最终拍板。于是会议就在"我觉得""我建议""要不再想想"之间无限循环。

2) 开会前 10 分钟：写一张 DACI 决策卡

别高估会议的"临场发挥"。你只要试一次就知道：没决策卡的会议，很容易从"要不要做"聊到"当年我们为什么选了 Spring"。

在外企我就养成了一个习惯：每次自己发起会议之前，先在笔记本上写清楚"今天必须定下来的三件事"。写不出来的话，说明这个会还不该开。后来我把它整理成一张标准的"决策卡"，直接贴在会议邀请里当 Pre-read：

【决策标题】（一句话）
【今天要定的点】1) ___ 2) ___ 3) ___（最多 3 个）
【背景】两句话，不讲故事
【选项】A / B / C（每个选项 1-2 句）
【建议】我建议选 X，原因三点
【风险/代价】列 3 条（最好量化）
【截止时间】今天必须定 / 明天中午前定 / 本周五前定

【DACI】
- Driver：
- Approver：
- Contributors：
- Informed：

写这张卡的过程，其实是在逼自己回答两个问题：

1) 今天到底定不定？
2) 到底谁能定？

这两个问题如果回答不了，说明会前功课没做够——别急着发邀请，先把信息补齐。

3) 三个在线会议高频场景（直接抄）

场景 1：需求变更（PM 说"顺便加一下"）

低效版：

PM：顺便加个导出功能吧，不难的。
你：嗯……我评估一下。
（两天后）
你：要加一周。
PM：怎么这么久？我们再开个会吧。

这种对话在外企我经历了无数次。PM 总觉得"就加个按钮"，工程师总觉得"你不懂底层"，双方各自委屈，然后用一场又一场会来消化这个委屈。

DACI 改写（你可以直接照着说）：

我来当 Driver。我们今天只定三件事：做不做、做哪种、影响多大。
Approver 我希望你（PM）和 TL 当场给结论，不然这会没必要开。
我准备了三个选项：
- A（最小版）：只导出 CSV，1 天
- B（标准版）：CSV + 权限校验，3 天
- C（完整版）：支持筛选 + 异步任务，1 周
我建议选 B，原因三点……
你们拍板后，我把行动项写进纪要：Owner=我，DDL=下周三。

关键点：把"评估一下"变成"选项 + 拍板"。

场景 2：优先级冲突（两个团队都说自己最紧急）

低效版：

"这个很紧急。"
"我们那边也很紧急。"
"那就都做吧。"

在跨时区团队里，优先级冲突特别常见——美国那边觉得 feature A 紧急，中国这边觉得 bug B 紧急，大家在各自的早上发一通消息，等对方醒了又是新一轮讨论。不 DACI 起来，一件事能异步扯一个星期。

DACI 改写：

我当 Driver。今天只做一件事：把优先级定下来，并写清楚"谁被影响"。
Approver 是业务 Owner（不是声音最大的人）。
三个选项：
- A：先做业务 1（收益大，技术债后补）
- B：先还技术债（稳定性提升，业务延后）
- C：拆分并行（需要额外人力）
每个选项我都列了影响：用户/收入/风险/工期。请 Approver 当场拍板。

关键点：优先级不是吵出来的，是用影响量化出来的。

场景 3：技术方案落地（大家都支持，但没人推进）

这种场景在技术团队特别常见：人人都说"好"，但没人写任务、没人拉排期、没人追进度。

我在外企见过不止一次同样的"死法"：一个很好的技术方案在架构评审会上获得了所有人的赞同，然后在接下来的三个月里没有任何进展，因为没有人觉得"推这件事"是自己的活。

DACI 改写（会后 5 分钟就能落地）：

• Driver：你（或某个最关心结果的人）
• Approver：TL/架构负责人（确认优先级与投入）
• Contributors：SRE/QA/安全（给输入）
• Informed：会受影响的团队

会后纪要只写三行也行：

决定：采用方案 B（Approver：X）
行动：拆成 3 个任务（Owner/DDL/验收标准）
知会：同步到 Y 群/邮件（Informed）

关键点：没有 Driver 的"好主意"，最后会变成"我们当年也讨论过"。

4) DACI 落地三板斧：会前 / 会中 / 会后

DACI 解决的是"谁干什么"，但光有角色还不够——你还需要一套"会议执行纪律"把它真正跑起来。下面三招是我自己这些年带会议攒出来的，比 DACI 本身更实用，因为它们管的是会议的全生命周期。

会前：会议三件套（Pre-read / Agenda / Action）

很多会议低效不是因为会上没讨论，而是因为会前没准备、会后没落地。

国企时代的会，准备工作倒是充分——领导讲话稿打印三份，座位牌按级别摆放——但那些准备跟"高效决策"没什么关系。到了外企，反过来了：会议邀请随手一发，连 agenda 都没有，到了会上才开始想"今天聊什么"。

我的做法是：每次发会议邀请时，强制附上三样东西：

你会发现：Pre-read 发出去之后，一半的"讨论"其实在会前就解决了。 真正需要会上解决的，只剩下"拍板"和"分歧"。

有人会说"我没时间写 Pre-read"。我的回答是：你没时间写一页纸，但你有时间开三次会？ 在外企那些一天好几场会的日子里，我刻意观察过一段时间：凡是有 Pre-read 的会议，整体上明显更短、更不容易跑偏。

会中：控场四句口令

会议一旦开始跑偏（在线会议尤其容易），Driver 需要一套"口令"把节奏拉回来。我自己用得最顺的是这四句：

1. "今天的目标是什么？" ——把注意力聚焦
2. "今天要定什么？" ——把"讨论"收窄为"决策"
3. "如果今天不定，会怎样？" ——制造紧迫感，逼出优先级
4. "我建议下一步：谁、做什么、什么时候完成。" ——把共识变成行动

这四句口令的妙处是：你不需要"拍桌子"，你只需要"问对问题"。 第三句尤其好用——当大家开始绕圈子时，一句"如果今天不定会怎样"往往能把会议从 brainstorming 模式拉回 decision 模式。

实际操作中，我通常在会议第 5 分钟抛出第 1、2 句，把"气氛组"拉回正题；在讨论陷入胶着时丢出第 3 句当"刹车片"；最后 5 分钟用第 4 句"钉钉子"。这个顺序用熟了，30 分钟的会基本能在 20 分钟内结束。

做跨时区会议的时候，这套口令更加救命。因为有些同事是半夜参会，你每多浪费一分钟，人家就多熬一分钟。逼自己用口令控场，其实也是对别人时间的尊重。

会后：三段式纪要（结论 / 依据 / 行动）

会议纪要写得好不好，决定了这次会是"白开"还是"值回票价"。

我见过两种纪要：

没人看的纪要：三千字会议记录，把谁说了什么全写进去，像法庭速记。国企时代我干过不少这种活，每次整理纪要到深夜，发出去之后石沉大海——因为没人有耐心从三千字里找"到底定了什么"。

有人抄的纪要：三段话搞定——

【结论】我们决定采用方案 B（Approver：X 确认）

【依据】
- 方案 A 风险太高（安全评审不过）
- 方案 C 工期超出 Q2 窗口
- 方案 B 满足核心需求，且 3 天可交付

【行动】
1. 张三：实现导出功能（DDL：2/14，验收标准：CSV 可下载 + 权限校验通过）
2. 李四：更新需求文档（DDL：2/10）
3. 知会：同步到 #product 频道（Informed）

三段式纪要的核心：让没参会的人 3 分钟读懂，让参会的人没法赖账。

再补一个我个人很偏爱的做法：我以前做过两年秘书，开会时我习惯一边主持/控场，一边把关键点实时记下来（别追求字字转录，抓“结论/依据/行动”三件事就够了）。

到了会议快结束的最后 2 分钟，我会把刚才记录的三段内容当场念一遍（或者共享屏幕让大家看一眼），逐条问：

• 结论有没有歧义？
• 依据有没有漏关键约束？
• 行动项的 Owner / 截止时间 / 验收标准有没有写错？

这一步看起来“啰嗦”，但它能把后续 80% 的扯皮和返工，直接挡在会议室门口。 一个小技巧：纪要发出后加一句"如有异议请在 24 小时内回复，过时视为确认"——这句话的威力比你想象的大。

5) 技术人最容易踩的坑（别问我怎么知道的）

• Approver 不在场：会开完再去请示，等于又开了一次会。国企时代的经典剧情——科长开完会要向处长汇报，处长再向局长请示，一个决策走三遍。当然，现实中 Approver 确实不一定能每次都到场，退而求其次的做法是：会上先按建议方案达成共识，会后把三段式纪要抄送 Approver，并提前约定清楚“默认同意”规则（例如：“请在 24 小时内确认或否决，过时视为批准”）。这样至少不用再开第二场会。

这里的关键不在于“耍小聪明”，而在于把规则写在台面上：你给 Approver 充分的否决权，同时也给团队一个明确的推进节奏。 - Driver 不敢催：怕"显得我很急"，结果项目"很礼貌地"延期。我见过最离谱的是一个方案 review 排了三周都没排上，因为 Driver 不好意思催老板的时间。 - 把 Contributor 当 Approver：专家意见很重要，但专家不一定承担业务结果 - I（Informed）太多：知会名单长得像通讯录，真正执行的人反而没写 - 没有 Pre-read：所有人到会上才第一次看到信息，前 20 分钟全在"补课" - 纪要只记过程不记结论：写了三千字，但没人知道"到底定了什么" - 会议膨胀症：本来 30 分钟能定的事，硬要排 1 小时"以防讨论不完"。日历上经常看到 1 小时的会实际 25 分钟就散了——那为什么不一开始就排 30 分钟？

6) 关于"会议效率"的几点反思

在不同的组织文化里开了这么些年的会，我慢慢总结出几条朴素的道理：

最好的会议是不需要开的会。 如果一个问题能用一封邮件或一条消息说清楚，就不要拉会。在外企的时候，我一度养成了"发会议邀请之前先问自己：这件事用异步沟通能不能解决？"的习惯，不少会议就这样被我在发邀请之前\"劝退\"了。

会议的数量跟组织的信任度成反比。 国企开会多，有一部分原因是信任链条太长——层层审批、层层汇报，不开会就没有"知情权"。外企的会多则是因为另一种不信任：大家不相信 email 能解决问题，不相信文档能传递上下文，所以"拉个会聊聊"成了万能胶。

会议效率的天花板不在工具，而在文化。 哪怕视频会议工具再好、协作平台再强，如果团队没有"会前准备、会上决策、会后落地"的纪律，开出来的会照样又臭又长。反过来，哪怕你只用一个电话，只要角色清楚、议程明确，10 分钟一样能定大事。

对程序员来说，减少会议最好的办法是写好文档。 代码有注释，方案有 design doc，进度有 dashboard——别人不用找你问就能获取信息，自然就不会拉你开会。我在外企观察到的规律是：文档写得好的团队，会议量明显少于文档写得差的团队。

总结：DACI + 三板斧，从"开会"到"定事"

一句话：谁推动、谁拍板写清楚，会议自然短。

DACI 管的是角色，三板斧管的是节奏。两件事配合起来：

• 会前：决策卡 + Pre-read（10 分钟搞定，省掉 1 小时扯皮）
• 会中：四句口令控场（聚焦 → 收窄 → 紧迫 → 落地）
• 会后：三段式纪要（结论/依据/行动，24 小时内发出）

从国企的文山会海到外企的一天好几场会，我花了不少时间才把这些东西攒齐。希望你花 10 分钟读完，下一场会就能用起来。

自检清单（开会前 30 秒）

• [ ] 这个会真的需要开吗？（能异步解决的就别开）
• [ ] 今天要定的点不超过 3 个
• [ ] Driver 是谁写清楚了
• [ ] Approver 在场（不在场就别开；实在排不上，会后纪要抄送 Approver 限时批准）
• [ ] 选项至少 2 个（别把会议变成"求批准"）
• [ ] Pre-read 提前 24 小时发了
• [ ] 纪要模板准备好了（结论/依据/行动）

最后给你一张思维导图，方便收藏。

@startmindmap
<style>
mindmapDiagram {
  node { BackgroundColor #FAFAFA }
  :depth(0) { BackgroundColor #FFD700 }
  :depth(1) { BackgroundColor #E3F2FD }
  :depth(2) { BackgroundColor #F5F5F5 }
}
</style>
* DACI + 落地三板斧
** 两个时代的会
*** 国企：文山会海
*** 外企：一天好几场会
** 四角色
*** Driver：推进到发生
*** Approver：最终拍板
*** Contributors：给输入
*** Informed：做知会
** 决策卡
*** 今天要定什么（<=3）
*** 选项 A/B/C
*** 风险与代价
*** 截止时间
*** DACI 名单
** 三个场景
*** 需求变更
*** 优先级冲突
*** 技术方案落地
** 落地三板斧
*** 会前：Pre-read / Agenda / Action
*** 会中：控场四句口令
*** 会后：三段式纪要
** 反思
*** 最好的会是不开的会
*** 会议数 ∝ 1/信任度
*** 写好文档 = 减少会议
** 常见坑
*** Approver 不在场
*** Driver 不敢催
*** 没有 Pre-read
*** 会议膨胀症
@endmindmap

系列串读

1. DACI / RAPID 总览：别再"拉齐共识"了，把拍板权写在纸上
2. DACI：谁推动、谁拍板，会议自然短（本篇）
3. RAPID：把红线和拍板权拆开，跨部门少扯皮（下一篇）

扩展阅读

• Atlassian 团队手册：DACI 决策框架
• HBR：如何开好高效会议（管理者实用建议）
• GitLab 手册：远程会议怎么开（会前/会中/会后）
• GitLab 手册：Live Doc 会议最佳实践（边开边写、全程留痕）

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。