# 开完会以后，怎样把共识变成一张行动单？

- 作者: Andrew David W.Y.
- 来源: https://yutengfei.com/zh/journal/meeting-consensus-to-action/
- 版本: V1.0
- 发布: 2026-10-19
- 修订: 2026-10-19
- 内容状态: 已公开全文
- 内容类型: 方法 (methods)
- 研究专题: 利益相关者资本治理 (stakeholder-governance)
- 生态视角: 资源生态 (resource) · 客户生态 (customer) · 运管生态 (operations) · 资本生态 (capital)

## 如何使用这项资源

**用途**: 把会议讨论转为可执行安排：区分已决定与待决定，写清目标、交付、分工、时间、依赖和验收；沿任务执行、阻塞处理、成果核对与复盘持续推进。附两张机制图和可下载行动单模板。

**使用条件**: 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。

**方法 · 步骤、输入与完成条件**

**依据与验证边界**: 文中案例用于演示分析和操作。应用时请用实际业务记录替换示例条件，再核对判断和结果。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。

这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。

## 正文

开会的时候，大家对方向都挺认同。说到具体事情，也都觉得应该推进。

散会以后，再问进展，答案却不太一样：有人以为还要等方案，有人已经开始做了，有人认为应该由另一个团队负责。过了几天，事情又回到会上重新讨论。

问题可能就出在从讨论到行动的这一步。

“这个方向可以”，后面还有几件事需要说明白：这次到底定了什么，谁来推进，先交出什么，需要等谁，做到哪一步算完成。

我觉得，一场会开完，至少应该留下两份清楚的记录：**可以执行的行动，和还没有决定的事项。**

可以执行的事情，写进一张行动单。还没决定的，也要明确谁补什么、由谁确认、什么时候回来继续处理。这样，讨论才有机会往前走。

## 一、先把已经决定和还在讨论的事情分开

会上的一句“没问题”，可能有不同含义。有人认可目标，有人认可某个思路，有人只是说明自己的部分可以配合。

如果直接把它们记成“全体通过，立即执行”，就可能把没有解决的问题藏进会议纪要。

我建议，整理会议结果时，先分两类。

**一类是已确认、可以进入执行的事项。**

把决定内容、适用范围和必要条件写清楚，核对作出决定的权限，以及需要参与的协作方是否已经确认承接。

**另一类是待决定的事项。**

可能缺资料，可能需要进一步比较，也可能需要有相应权限的人确认。把缺什么、谁处理、何时反馈写出来。

待决定的事情也可以有具体动作。比如，下一步先收集资料、做一个小范围验证，或者提交备选方案。这些准备工作本身也需要确认范围，不能在收集资料的时候，就默认后面的方案已经获批。

明确暂不推进的内容，也应留下理由和重新评议的条件，避免过几天又被当成漏办事项。

**“已经讨论过”与“已经形成可执行安排”，需要有一个明确的确认过程。**

## 二、一项行动，先说清楚六件事

行动单不用做得很复杂。真正需要的是，让不同的人看到同一行内容，能理解接下来做什么。

我建议，每项行动至少写清六件事。

| 要素 | 需要回答的问题 | 怎样写得更清楚 |
| --- | --- | --- |
| 目标 | 这件事要解决什么问题？ | 写出希望改善的具体情况 |
| 交付 | 这一步要交出什么？ | 明确文件、样稿、数据、实物或可验证的工作结果 |
| 分工 | 谁负责推动，谁需要配合？ | 推动人和协作人分别列出，核对承接情况 |
| 时间 | 哪个节点需要交付或反馈？ | 区分目标日期、已确认日期和待确定时间 |
| 依赖 | 开始或完成之前，需要具备什么？ | 资料、权限、资源、前一项成果，以及提供方 |
| 验收 | 谁来核对，按什么判断？ | 写出标准、核对人和结果记录方式 |

“完善方案”可以继续往下问：这次要完善哪些部分？交一份初稿，还是提交可供审批的完整版本？谁看，重点核什么？

“加强协同”也可以具体一点：双方要交换哪些信息，用哪个版本，遇到差异交给谁确认？

这些问题问清楚，行动单里的动词才会对应到实际成果。

一项任务最好有明确的推动人，协作职责另列。跨团队安排要核对权限和承接情况，不能只在表里填上别人的名字，就当作对方已经接受。

时间也一样。尚未确定的，可以先写“待确认”，同时安排确认动作。不要为了让表格显得完整，替别人填一个没有商量过的日期。

[![图一：从会议讨论到行动单，先核对决定与承接，再明确六项执行要素](https://yutengfei.com/journal/meeting-consensus-to-action/discussion-to-action-zh.svg)](https://yutengfei.com/journal/meeting-consensus-to-action/viewer-1-zh.html)

图一说明讨论怎样分流为可执行事项与待决定事项。待决定事项补齐资料、核对权限和承接后，再回到确认环节。

[放大查看、拖动浏览 ↗](https://yutengfei.com/journal/meeting-consensus-to-action/viewer-1-zh.html)[下载图1 SVG ↓](https://yutengfei.com/journal/meeting-consensus-to-action/discussion-to-action-zh.svg)

## 三、依赖关系写出来，才知道事情卡在哪

一项任务没有往前走，先看看它需要的条件齐了没有。

内容制作可能在等业务资料，数据分析可能在等统计口径，发布工作可能在等审核结论。如果这些依赖没有记录，到了节点，大家就只看见“还没完成”。

我建议，每个重要依赖至少写清：**需要什么，由谁提供，何时需要，未具备会影响哪一步。**

任务受阻时，反馈也可以沿着这几件事说：

> 现在完成到哪一步了，还缺哪项输入，影响哪个交付节点，需要谁作出什么确认。

有些工作可以并行，有些需要等前一项通过后才能继续。把这些关系画出来，就容易判断先推进哪一步、哪里需要协调。

负责推动的人需要及时说明阻塞，提供条件的人也需要回应。遇到超出双方权限的问题，再交给适当的人协调或决定。

这样做，能让催进度有具体对象。追问围绕缺口和下一步展开，先不要用一个“执行力不够”概括所有情况。

## 四、提交以后，还要有一个验收结果

“已经发出去了”，说明发生了提交动作。后面还需要知道：对方收到的是哪个版本，核对了哪些内容，是否满足约定标准。

行动单里可以把状态写得简单一些：待开始、进行中、受阻、已提交、已验收。需要取消或调整的，另留确认记录。

状态变化要有对应依据。进入“已提交”，附成果和版本；进入“已验收”，记录由谁、按什么标准得出的结论。

验收没有通过，反馈应指向具体差距。哪一项没满足，补到什么程度，谁再核一次。只说“再优化下”，执行的人仍然不知道下一步该改哪里。

如果验收时新增了原来没有的要求，就把新增范围、工作量、依赖和时间影响拿出来确认。修改可以继续，但原安排怎样变化，需要让相关人知道。

**交付验收与目标实现，也要分开看。** 一份分析报告可能已经符合交付标准，后面是否改善了经营决策，还要经过使用和观察。行动单记录交付结果，复盘再看它有没有帮助原来的问题得到解决。

## 五、用一个小例子，把过程走一遍

下面是专门编写的假设情境，不对应任何真实企业、会议或团队。

假设一个团队开会，准备更新一份对外介绍。大家认为旧版本的信息比较分散，希望让读者更容易看清服务范围。

如果会议结果只记一句“优化介绍材料，由内容组跟进”，执行时还会遇到不少问题：哪部分能改，数据以谁的为准，要不要重做视觉，最后由谁确认。

可以先形成这样的安排：

-   目标：让读者清楚理解现有服务范围和主要交付。
-   本步交付：一份结构稿，暂不进入完整视觉制作。
-   推动与协作：内容负责人统筹，业务负责人核对范围及事实；分工需由相关人确认。
-   依赖：先提供现行服务清单和可对外使用的依据。
-   时间：核对依赖后确认提交节点；依赖延迟时，及时反馈对节点的影响。
-   验收：业务负责人按“范围准确、事实可核对、没有未经确认的承诺”检查结构稿。

会上还有人提出，可以顺便增加一项新服务。它尚未确定，由相应负责人补充条件，之后另行确认。结构稿先按现有服务推进，不把新建议直接写成已经提供的能力。

结构稿提交后，如果发现两处服务描述与现行清单不一致，就指出位置、依据和修改要求。修正通过后，记录验收版本，再按已确认的安排进入后续制作。

这一步交付完成了。等材料真正被使用，还可以观察读者是否更容易理解、哪些问题仍被反复问到，把反馈带进下一轮修改。

## 六、复盘要回答，下一轮具体改什么

复盘可以从行动单本身往回看。

原来想解决什么？实际交出了什么？哪里出现偏差？当时具备哪些信息和条件？哪些安排需要调整？

如果资料反复迟到，看看提供方、所需范围和反馈节点是否明确。如果验收不断返工，看看标准是不是事前没有说清。如果每次都在等同一个人确认，就看看权限和决策安排是否适合当前工作。

原因没有核清的时候，先保留为待核实，不急着给人下结论。

复盘以后，留下能够进入下一轮的改变：补一个检查项，调整一个依赖顺序，明确一个决定入口，或者缩小一次交付范围。

新的安排再回到行动单，交给相关人确认。复盘才和下一次执行接上。

[![图二：任务执行、交付验收和复盘改进的闭环，分别处理阻塞、返工和范围变更](https://yutengfei.com/journal/meeting-consensus-to-action/execution-review-loop-zh.svg)](https://yutengfei.com/journal/meeting-consensus-to-action/viewer-2-zh.html)

图二将提交与验收分开，也将交付通过与实际效果分开。受阻、未通过和新增要求分别处理，变更经过确认并留下记录。

[放大查看、拖动浏览 ↗](https://yutengfei.com/journal/meeting-consensus-to-action/viewer-2-zh.html)[下载图2 SVG ↓](https://yutengfei.com/journal/meeting-consensus-to-action/execution-review-loop-zh.svg)

**下载空白行动单**

包含当前行动、待决定事项和记录原则，可按自己的协作情境填写。

[下载行动单模板（MD） ↓](https://yutengfei.com/journal/meeting-consensus-to-action/action-template-zh.md)

## 七、一张可以直接用的行动单

复杂项目可以拆成更多表格。一般协作，先用下面这张单就能开始。表里写的是实际确认的安排；未知事项保留待定状态，再明确补齐动作。

| 字段 | 填写内容 |
| --- | --- |
| 行动编号、依据与版本 | 对应哪次讨论或决定，当前版本与更新日期 |
| 目标 | 希望解决什么问题，后续怎样观察改善 |
| 本步交付 | 成果名称、范围、格式或可验证结果 |
| 推动人与协作人 | 分别做什么，是否确认承接 |
| 时间节点 | 提交、反馈或确认的节点；未定的写明确认动作 |
| 前置依赖 | 需要什么、谁提供、何时需要、未具备的影响 |
| 验收 | 核对人、标准、成果依据与结论 |
| 当前状态 | 待开始、进行中、受阻、已提交、已验收；取消另记依据 |
| 阻塞与变更 | 问题、影响、需要的决定，以及谁确认了调整 |
| 下一步与复盘 | 下一动作、负责人、反馈节点和需要保留的改进 |

另设一块“待决定事项”：记录问题、所缺信息、补充人、决定或确认方、返回讨论的节点，以及已经允许开展的准备工作。

每项任务的成果、决定和变更尽量放在能够互相查到的位置。换人接手时，看记录就知道当前状态，不用把之前所有人再问一遍。

## 结语

我觉得，会议的价值，要沿着会后的行动继续看。共同方向需要变成明确安排，安排需要对应成果，成果要经过核对，再回到实际使用中检验。

先把这一次定了什么、还缺什么、下一步谁做说清楚。做完以后，再把哪里有效、哪里需要改留在记录里。

事情就是这样，一步一步往前推进的。

**相关研究**

[繁、简、易、图：商业逻辑设计的思考方法 ↗](https://yutengfei.com/zh/journal/fan-jian-yi-tu/)[利益相关者共创共享的经营逻辑与实施方法 ↗](https://yutengfei.com/zh/journal/stakeholder-co-creation-method/)

[CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/)

原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。

[查看 AI 使用说明](https://yutengfei.com/zh/journal/ai/)