会议行动项清单至少要记录六类信息：行动项描述、唯一负责人、协作人、截止时间、当前状态和验收标准；再补充来源会议与决议、优先级、依赖与风险、进展记录和关闭确认。本文提供一张可直接复制的空白表格，逐字段说明填写口径，区分必填与选填，并用一次项目周会的完整示例示范如何落地。
要点总览（TL;DR）
- 会议行动项清单的必填字段是：行动项描述、唯一负责人、截止时间、状态、验收标准，再加一个编号即可运行。
- 行动项描述写清动作与交付物，负责人只填一个自然人，截止时间写到具体日期，验收标准写成可核验的完成条件。
- 状态建议统一为未开始、进行中、待确认、已完成、已关闭、已取消六种，把“执行人认为做完”和“验收人确认关闭”分开记录。
- 清单在会后当天发出并请负责人确认，每次例会先核对上次行动项，已关闭事项按月归档。
- 跨团队、需向上汇报或可能被追溯的事项，再补充协作人、优先级、来源会议与决议、依赖与风险、进展记录和关闭确认。
可复制空白行动项清单模板
下表可直接粘贴到在线表格或文档中使用。使用原则是：一行只放一个行动项，字段位置固定，状态列贯穿始终，关闭确认单独留列。表头下方保留两行空白填写行，便于复制扩展。
| 编号 | 行动项描述（做什么、交付什么） | 负责人 | 协作人 | 截止时间 | 优先级 | 状态 | 验收标准 | 来源会议与决议 | 依赖与风险 | 进展记录 | 关闭确认 |
|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队刚开始使用清单，可以先保留编号、行动项描述、负责人、截止时间、状态、验收标准六列，其余字段在需要时再加。字段一旦确定，后续会议沿用同一套表头，避免每次重新设计。
每个字段记录什么：字段说明
字段说明解决的是“怎么填”的问题。同一字段在不同会议中保持同一口径，清单才能被快速扫读和交接。下表逐字段给出含义、填写口径和示例值。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 编号 | 行动项的唯一标识 | 按“会议日期+序号”或团队统一规则生成，不重复 | 0715-03 |
| 行动项描述 | 要完成的动作和交付物 | 用动词开头，写清产出物名称，避免只写“跟进”“处理” | 输出登录模块接口文档初稿，覆盖鉴权与错误码 |
| 负责人 | 对结果负责的人 | 填单一自然人姓名，不填部门或多人 | 李敏 |
| 协作人 | 提供输入或配合执行的人 | 列出具体角色或姓名，注明配合事项 | 王强（提供测试账号） |
| 截止时间 | 承诺完成的时间 | 写到具体日期，必要时加时间点；不写“下周”“尽快” | 2025-07-18 |
| 优先级 | 相对紧急程度 | 统一取值，如高、中、低，并说明判定依据 | 高（阻塞联调） |
| 状态 | 行动项当前进展阶段 | 统一取值：未开始、进行中、待确认、已完成、已关闭、已取消 | 进行中 |
| 验收标准 | 判断完成的依据 | 写成可核验的条件，说明由谁确认、看什么结果 | 文档经架构评审通过并归档到项目文档库 |
| 来源会议与决议 | 行动项产生的上下文 | 记录会议名称、日期和对应决议条目 | 7月15日项目周会，决议第2条 |
| 依赖与风险 | 影响完成的前置条件 | 写明依赖对象和可能风险，便于提前协调 | 依赖测试环境开通，当前排队中 |
| 进展记录 | 过程中的关键更新 | 按日期追加，不覆盖历史记录 | 7-16 完成初稿；7-17 提交评审 |
| 关闭确认 | 完成后的确认人与确认时间 | 由验收人填写姓名和日期，未确认不关闭 | 张伟，2025-07-19 |
行动项描述和验收标准是最容易写空的两列。描述回答“做什么、交什么”，验收标准回答“凭什么算完成”。负责人一列只写一个人，多人负责往往等于无人负责；协作人单独列出，责任边界才清晰。
必填与选填：最小可用字段集
字段并非越多越好。必填字段保证行动项可执行、可追踪；选填字段服务于复杂会议和跨团队协作。下表给出对照。
| 类别 | 字段 | 作用 | 缺失时的风险 |
|---|---|---|---|
| 必填 | 行动项描述 | 明确做什么、交付什么 | 执行人理解偏差，产出不符合预期 |
| 必填 | 负责人 | 确定唯一责任人 | 事项悬空，无人推进 |
| 必填 | 截止时间 | 形成时间承诺 | 无限期拖延，无法排期核对 |
| 必填 | 状态 | 反映当前进展 | 无法判断哪些事项需要跟进 |
| 必填 | 验收标准 | 提供完成判断依据 | 完成与否各执一词，反复返工 |
| 选填 | 协作人 | 标明配合关系 | 跨角色事项缺少输入来源 |
| 选填 | 优先级 | 支持排序取舍 | 资源冲突时难以判断先后 |
| 选填 | 来源会议与决议 | 保留决策上下文 | 后续追溯时找不到依据 |
| 选填 | 依赖与风险 | 提前暴露阻塞 | 风险在截止前才被发现 |
| 选填 | 进展记录 | 保留过程信息 | 交接时缺少上下文 |
| 选填 | 关闭确认 | 形成闭环凭证 | 事项状态与实际不一致 |
精简版清单保留五个必填字段加编号即可运行，适合站会、小组同步会等节奏快、事项少的场景。完整版增加协作人、优先级、来源、依赖、进展和关闭确认，适合项目周会、评审会和跨团队协调会。取舍标准是：事项是否需要多人配合、是否需要向上汇报、是否可能被追溯。三项中占一项以上，就值得启用完整字段。
填写示例：一次项目周会的行动项清单
以下示例来自一次产品研发项目周会，会议时间为2025年7月15日，参会方包括产品、研发、测试三个小组。会议形成四项决议，对应四条行动项。示例中的团队与人员均为演示情景。
| 编号 | 行动项描述 | 负责人 | 协作人 | 截止时间 | 优先级 | 状态 | 验收标准 | 来源会议与决议 | 依赖与风险 | 进展记录 | 关闭确认 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 0715-01 | 输出登录模块接口文档初稿，覆盖鉴权流程与错误码 | 李敏 | 王强（提供测试账号） | 2025-07-18 | 高 | 进行中 | 文档经架构评审通过并归档到项目文档库 | 7月15日项目周会，决议第1条 | 依赖测试环境开通 | 7-16 完成初稿；7-17 提交评审 | |
| 0715-02 | 整理近两周线上问题清单，标注根因分类 | 陈璐 | 各模块负责人（补充根因） | 2025-07-17 | 中 | 待确认 | 清单覆盖全部线上问题，根因分类经测试负责人确认 | 7月15日项目周会，决议第2条 | 无 | 7-16 已整理23条，待补充3条 | |
| 0715-03 | 提交下一迭代排期草案，含人力分配与里程碑 | 张伟 | 李敏、陈璐（确认各自排期） | 2025-07-21 | 高 | 未开始 | 排期草案在迭代启动会上通过，并同步至项目计划 | 7月15日项目周会，决议第3条 | 依赖0715-01接口文档完成度 | ||
| 0715-04 | 更新需求变更记录，补充本次范围调整说明 | 王强 | 产品组（确认变更描述） | 2025-07-16 | 低 | 已完成 | 变更记录经产品负责人确认，版本号更新 | 7月15日项目周会，决议第4条 | 无 | 7-16 完成更新 | 张伟，2025-07-16 |
逐条看几个写法要点。第一条的描述写明了交付物是“接口文档初稿”及其覆盖范围，验收标准指向评审和归档两个可核验动作。第二条状态为“待确认”，表示工作已基本完成、等待验收人确认，这个中间状态能避免把“做完”和“确认完成”混为一谈。第三条在依赖列写明了与第一条的关联，排期评审时可以优先检查前置事项。第四条已完成并填写了关闭确认人，形成完整闭环。
状态取值建议统一为六种：未开始、进行中、待确认、已完成、已关闭、已取消。已完成指执行人认为做完，已关闭指验收人确认通过。两者分开，例会核对时就能快速区分“自认为完成”和“真正关闭”的事项。
清单的调整与维护方法
清单建立后，字段和节奏需要随会议类型与团队规模调整。调整的目标是让清单持续可用，避免越记越多、越记越乱。
按会议类型增减字段
- 每日站会：只保留编号、行动项描述、负责人、截止时间、状态，控制在当天可核对的粒度。
- 项目周会：启用完整字段，重点使用优先级、依赖与风险和来源会议与决议。
- 评审会与决策会：强化来源会议与决议、验收标准两列，确保决议可追溯。
- 跨团队协调会：强化协作人、依赖与风险，明确各方输入和交接点。
状态更新与例会核对节奏
| 时间点 | 动作 | 完成标志 |
|---|---|---|
| 会后当天 | 整理清单并发出，负责人确认接收 | 每位负责人回复确认或提出异议 |
| 每次例会开始 | 逐条核对上次行动项状态 | 过期事项有新的截止时间或取消说明 |
| 每周固定时间 | 更新进展记录，清理已关闭事项 | 清单中无超过一周未更新的进行中事项 |
| 每月末 | 归档已关闭行动项，统计完成情况 | 归档清单可查询，遗留事项转入下月跟踪 |
归档与历史查询
已关闭的行动项按月归档，保留编号、描述、负责人、关闭确认和来源会议，便于后续追溯某次决议的执行情况。归档清单与在用清单分开存放，例会只核对在用清单，减少干扰。
避免清单膨胀
- 一个行动项只对应一个交付物，范围过大的事项拆成多条。
- 超过一个月周期的事项，拆成阶段性行动项，每阶段单独设截止时间。
- 连续两次例会无进展的事项，重新确认负责人和截止时间，或标记取消并说明原因。
- 同一议题反复产生的行动项，回到决议层面检查是否缺少明确结论。
当行动项需要从会议记录转为可跟踪的工作项时，可以把清单放在支持文档与任务关联的协作工具中。ONES Wiki 支持使用模板库创建制式化文档，可用于沉淀会议记录；文档支持关联项目任务并嵌入任务进度，使行动项与项目工作保持关联。清单中的状态更新和关闭确认仍按团队约定执行，工具承担的是记录、关联和追溯的载体作用。
常见问题
行动项清单和会议纪要应该分开记，还是放在一起？
两者可以放在同一份会议文档里，但清单要单独成表。纪要保持叙述顺序，记录讨论过程和决议；清单按一行一个行动项组织，字段固定，便于逐条核对状态。放在一起的好处是来源清楚，每条行动项都能对应到决议条目；分开成表的好处是例会核对时只看清单，不被讨论内容干扰。如果团队会议较多，建议把清单汇总到一份持续维护的总表，会议纪要留在原文档中。
负责人临时变更或行动项需要取消时，清单怎么处理？
负责人变更时，在原行更新负责人姓名，并在进展记录中写明变更日期和原因，保留原负责人信息便于追溯。行动项取消时，把状态改为“已取消”，在进展记录中说明取消依据，例如决议调整或前置条件不再成立，不要直接删除该行。直接删除会让历史记录出现断档，后续核对时无法解释某条决议为何没有下文。归档时已取消事项与已关闭事项一并保留。
截止时间已过但事项仍未完成，清单上应该怎么标？
状态保持“进行中”或“待确认”，在进展记录中写明逾期原因，并在下次例会上重新确认截止时间。不建议把逾期事项直接改成新的截止日期而不留痕迹，否则时间承诺失去约束力。如果同一事项连续两次例会没有进展，按维护规则重新确认负责人和截止时间，或标记取消并说明原因。逾期本身不是问题，逾期后无人处理才是需要关注的情况。
小团队事项少，是否还需要完整的十二列清单？
不需要。精简版保留编号、行动项描述、负责人、截止时间、状态、验收标准六列即可运行，适合站会和小组同步会。当出现跨角色配合、需要向上汇报或可能被追溯的情况时，再补充协作人、优先级、来源会议与决议等字段。字段可以逐步增加，关键是同一时期团队使用同一套表头，避免每人一份格式。
把清单放进协作工具后，还需要保留表格版本吗？
通常不需要双份维护，但要保证工具中的记录能导出或按会议查询。以 ONES Wiki 为例，它支持使用模板库创建制式化文档，可用于沉淀会议记录，文档支持关联项目任务并嵌入任务进度，使行动项与项目工作保持关联。团队仍需约定状态更新和关闭确认的责任人，工具承担记录、关联和追溯的载体作用。归档与历史查询按团队节奏执行，避免在用清单越积越长。
