会议行动项清单要能直接推动会后执行，至少应包含六类信息：行动项描述（做什么、交付什么）、唯一负责人、协作人、截止时间、状态与验收标准；再按会议类型补充来源会议与议题、优先级、依赖与风险、进展记录和关闭确认。清单以表格落地，每行一个行动项，会后24小时内发出并请负责人确认，之后按固定节奏更新状态。下面的空白模板可直接复制到文档或表格工具中使用，字段说明、必填选填对照和填写示例保持同一口径。
要点总览（TL;DR）
- 会议行动项清单至少包含六类信息：行动项描述、唯一负责人、协作人、截止时间、状态与验收标准；再按会议类型补充来源会议与议题、优先级、依赖与风险、进展记录和关闭确认。
- 最小可用字段集是行动项描述、负责人、截止时间、状态、验收标准五项，缺少任何一项行动项都无法独立执行和验收；跨部门项目会建议全字段填写。
- 行动项描述用“动词＋对象＋交付物”写清动作和产出，验收标准写成可核验的条件，把描述和验收标准交给未参会同事看，对方能判断做没做完就算合格。
- 清单在会后24小时内发出并请负责人确认描述、截止时间和验收标准，之后按固定节奏更新状态，状态变更时同步补一条进展记录。
- 逾期行动项由负责人说明原因和新的预计完成时间，依赖未满足的注明阻塞点和需要谁推动；完成后由确认人填写关闭确认，项目结束时归档到项目文档。
可复制空白行动项清单模板
将下表复制到文档或表格工具中，删除示例行即可开始填写。每行只放一个行动项，同一议题拆出的多个动作分别占行，便于分别指派和跟踪。表头中的字段与后文字段说明一一对应，团队可以整表沿用，也可以按会议类型删减选填列。
| 序号 | 行动项描述 | 负责人 | 协作人 | 截止时间 | 状态 | 验收标准 | 来源会议/议题 | 优先级 | 依赖与风险 | 进展记录 | 关闭确认 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | （做什么＋交付什么） | （单一姓名） | （姓名，可多人） | （YYYY-MM-DD） | （未开始/进行中/待验收/已完成/已取消） | （可核验的完成标志） | （会议名称＋日期＋议题） | （高/中/低） | （前置条件、外部依赖、已知风险） | （日期＋进展＋下一步） | （确认人＋确认日期） |
| 2 | （做什么＋交付什么） | （单一姓名） | （姓名，可多人） | （YYYY-MM-DD） | （未开始/进行中/待验收/已完成/已取消） | （可核验的完成标志） | （会议名称＋日期＋议题） | （高/中/低） | （前置条件、外部依赖、已知风险） | （日期＋进展＋下一步） | （确认人＋确认日期） |
| 3 | （做什么＋交付什么） | （单一姓名） | （姓名，可多人） | （YYYY-MM-DD） | （未开始/进行中/待验收/已完成/已取消） | （可核验的完成标志） | （会议名称＋日期＋议题） | （高/中/低） | （前置条件、外部依赖、已知风险） | （日期＋进展＋下一步） | （确认人＋确认日期） |
填写时保持列顺序不变，新增字段追加在末尾，避免不同会议的清单结构互相冲突。若团队使用在线表格，可将“状态”列设为下拉选项，将“截止时间”列设为日期格式，减少录入歧义。
每个字段记录什么：字段说明
字段口径统一，清单才能在多人填写、多次更新后仍然可读。下表逐项说明每个字段的含义和填写要求，主持人或记录人可据此检查清单是否合格。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 行动项描述 | 这件事要完成什么 | 用“动词＋对象＋交付物”写清动作和产出，例如“整理评审意见并输出修订版需求文档”，避免只写“跟进一下”“优化体验”这类无法验收的表述 |
| 负责人 | 对结果负责的人 | 只填一个姓名。负责人负责推进、协调和交付，协作人再多也不改变责任归属；负责人缺席会议时，应在发出清单时单独确认 |
| 协作人 | 参与执行或提供输入的人 | 列出需要配合的具体人员或角色，注明配合内容更佳；协作人不承担最终交付责任 |
| 截止时间 | 承诺完成的日期 | 精确到日期，格式统一为YYYY-MM-DD；需要具体时点的，在描述中补充时间。跨天任务写最终交付日，不写“尽快”“下周” |
| 状态 | 行动项当前所处阶段 | 使用固定选项：未开始、进行中、待验收、已完成、已取消。状态由负责人更新，验收类状态在确认人验收后变更 |
| 验收标准 | 判断完成与否的依据 | 写成可核验的条件，例如“修订版文档已上传至项目文档库并经评审人确认”，避免“质量达标”这类主观判断 |
| 来源会议/议题 | 行动项的出处 | 记录会议名称、日期和对应议题，便于回溯讨论背景，也方便未参会成员理解上下文 |
| 优先级 | 相对紧急与重要程度 | 用高、中、低三档，结合截止时间和业务影响判断；同一会议内优先级口径应一致，避免全部标为高 |
| 依赖与风险 | 影响按期完成的前置条件 | 写明依赖的对象和已知风险，例如“依赖测试环境就绪”“等待供应商报价”；无依赖时留空或写“无” |
| 进展记录 | 执行过程中的关键更新 | 按“日期＋进展＋下一步”追加，不覆盖历史记录；每次状态变更时同步补一条 |
| 关闭确认 | 行动项结束的凭据 | 记录确认人和确认日期；验收通过后填写，取消的行动项注明取消原因和确认人 |
其中“行动项描述”和“验收标准”最容易写得含糊。一个实用的检查方法是：把描述和验收标准交给未参会同事看，如果对方能判断这件事做没做完，字段就算合格。
必填与选填：按会议类型取舍字段
字段并非每场会议都要全填。最小可用字段集保证行动项可指派、可跟踪；其余字段按会议规模和跨团队程度补充。下表给出必填与选填的划分建议。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 行动项描述、负责人、截止时间、状态、验收标准 | 缺少任何一项，行动项都无法被独立执行和验收 |
| 建议必填 | 来源会议/议题、协作人 | 多人会议或需要配合时填写；单人短会可简化 |
| 选填 | 优先级、依赖与风险、进展记录、关闭确认 | 跨部门项目、周期较长的行动项建议全部填写；例行短会可按需使用 |
例行站会、周会这类短会，议题集中、参与人少，保留必填五项加协作人即可，清单当天发出、下次会议前核对。跨部门项目评审会涉及多方交接，建议全字段填写，尤其要写清依赖与风险，避免执行到中途才发现前置条件未满足。季度规划类会议行动项周期长，进展记录和关闭确认应作为固定动作，否则清单很快会失去时效。
字段缺失时的处理方式要提前约定：负责人未确定，由会议主持人在清单中标注“待指派”并指定临时跟进人，24小时内补齐；截止时间无法确定，先填一个可评估的日期并注明“待确认”，下次更新时修正；验收标准当场写不出的，由负责人补充后回复确认，不能长期留空。任何“待补”字段都应有补齐期限，否则清单会在几轮更新后失效。
填写示例：一次项目评审会的完整清单
以下为一次需求评审会的已填写清单（演示情景，非真实项目数据），展示各字段如何配合。会议于2025-03-10召开，议题为“V2.1需求范围评审”。
| 序号 | 行动项描述 | 负责人 | 协作人 | 截止时间 | 状态 | 验收标准 | 来源会议/议题 | 优先级 | 依赖与风险 | 进展记录 | 关闭确认 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 整理评审意见并输出V2.1需求修订版文档 | 李敏 | 王强、赵蕾 | 2025-03-13 | 进行中 | 修订版文档上传至项目文档库，评审人张涛确认意见已全部处理 | 需求评审会 2025-03-10 / V2.1需求范围 | 高 | 依赖王强提供接口变更说明；风险：接口方案未定稿可能延后 | 2025-03-11 已汇总12条意见，待接口说明补齐后完成第5、7条修改 | — |
| 2 | 补充V2.1接口变更说明文档 | 王强 | 李敏 | 2025-03-12 | 待验收 | 说明文档覆盖新增3个接口的入参、出参和错误码，经后端负责人确认 | 需求评审会 2025-03-10 / V2.1需求范围 | 高 | 无 | 2025-03-11 初稿完成；2025-03-12 提交后端负责人确认 | — |
| 3 | 更新测试用例清单，覆盖V2.1新增场景 | 赵蕾 | 测试组成员 | 2025-03-17 | 未开始 | 用例清单中新增场景均有对应用例，并通过测试负责人评审 | 需求评审会 2025-03-10 / V2.1需求范围 | 中 | 依赖行动项1的修订版文档 | — | — |
| 4 | 确认V2.1上线时间并同步至项目计划 | 张涛 | 李敏、王强 | 2025-03-14 | 已完成 | 项目计划中的上线日期已更新，并在项目群公告 | 需求评审会 2025-03-10 / V2.1需求范围 | 中 | 无 | 2025-03-11 与各方确认日期；2025-03-11 计划已更新并公告 | 张涛 2025-03-11 |
示例中可以看到字段之间的配合：行动项3的依赖直接指向行动项1，负责人据此知道何时可以启动；行动项2进入“待验收”后，验收标准写明了确认对象，避免状态长期停在待验收；行动项4完成后填写了关闭确认，其他人不必再追问进度。进展记录采用“日期＋进展＋下一步”的写法，读起来就是一条简短的时间线。
清单的调整与维护方法
清单的价值在会后持续更新中体现。建议按以下步骤维护，每一步都有明确的动作和完成标志。
- 会后发布与确认。会议结束当天整理清单，24小时内发给全体参会人和负责人。发布时请每位负责人回复确认，重点确认描述、截止时间和验收标准三项；有异议当场修改，避免执行阶段才发现理解不一致。
- 固定更新节奏。例行短会可在下次会议前由负责人更新状态；跨部门项目建议每周固定时间更新一次。状态变更时同步补一条进展记录，保持记录与状态一致。
- 逾期与阻塞处理。截止时间已过且未完成的行动项，由负责人在更新时说明原因和新的预计完成时间，主持人判断是否需要调整优先级或协调资源。存在依赖未满足的，在“依赖与风险”列注明阻塞点和需要谁推动，必要时升级到项目例会讨论。
- 关闭确认与归档。行动项达到验收标准后，由确认人核对并填写关闭确认，状态改为“已完成”。项目或阶段结束时，将清单归档到项目文档中，保留来源会议信息，便于后续复盘和追溯。
- 字段随实践调整。运行一段时间后，如果某字段长期为空，考虑删除或改为按需填写；如果反复出现同类问题，例如验收争议多，则强化验收标准的写法要求。调整字段时同步更新模板和填写说明，保证团队使用同一版本。
当清单需要多人协作维护时，可以把表格放进支持版本记录和权限控制的文档工具中。ONES Wiki 支持富文本编辑与在线评论，成员可以在清单页面上直接补充进展或提出异议；页面版本记录便于查看每次修改，误删内容可从回收站恢复。若希望行动项与项目任务联动，ONES Wiki 的文档可关联项目任务并嵌入任务进度，清单中的行动项在任务模块推进后，文档侧能同步看到进展。模板库支持一键创建制式化文档，团队可将上述空白清单固化为统一模板，减少每次会议重新搭表头的重复工作。具体模板是否预置、各版本功能范围，以实际使用版本为准。
常见问题
会议结束后多久发出行动项清单比较合适？
建议会议结束当天整理，24小时内发给全体参会人和负责人。发布时请每位负责人回复确认，重点确认描述、截止时间和验收标准三项。间隔太久，讨论细节容易遗忘，负责人对任务的理解偏差也更难在发布时纠正。
如果会议在临近下班时结束，可以次日上班后第一时间发出，但应在会议结束时就告知清单的发出时间，让负责人有预期。
负责人暂时定不下来，行动项还能先写进清单吗？
可以，但要标注清楚并设定补齐期限。常见做法是由会议主持人在清单中标注“待指派”，同时指定一名临时跟进人，约定24小时内补齐负责人。截止时间无法确定的，先填一个可评估的日期并注明“待确认”，下次更新时修正。
关键是任何“待补”字段都要有补齐期限和跟进人，否则清单会在几轮更新后失效，行动项无人认领。
例行站会的行动项清单可以简化到什么程度？
例行站会、周会议题集中、参与人少，保留必填五项（行动项描述、负责人、截止时间、状态、验收标准）加协作人即可，清单当天发出、下次会议前核对。优先级、依赖与风险、进展记录、关闭确认这些字段可以按需使用。
简化不等于省略验收标准。短会行动项通常较小，验收标准一句话就能写清，例如“文档已更新并通知相关同事”，省掉这一项反而容易在下次核对时产生争议。
行动项逾期了，清单上应该怎么记录？
截止时间已过且未完成的行动项，由负责人在更新时说明原因和新的预计完成时间，主持人判断是否需要调整优先级或协调资源。存在依赖未满足的，在“依赖与风险”列注明阻塞点和需要谁推动，必要时升级到项目例会讨论。
不建议直接改掉原截止时间了事，保留原日期并在进展记录中写明延期原因，后续复盘时才能看出哪些环节反复卡住。
用文档工具维护清单，和用表格相比有什么要注意的？
用文档工具维护的好处是清单和会议记录、项目资料放在一起，成员可以在页面上直接补充进展或提出异议，版本记录便于查看每次修改。以 ONES Wiki 为例，它支持富文本编辑与在线评论，页面版本记录可随时查看与回滚，误删内容可从回收站恢复；文档还可关联项目任务并嵌入任务进度，行动项在任务模块推进后，文档侧能同步看到进展。
要注意的是，文档工具里的清单不会自动提醒逾期，更新节奏仍需团队约定并执行。若希望状态流转和提醒更自动化，需要配合任务管理模块使用，具体配置方式以实际使用版本为准。
