会议记录的价值在于会后能直接分派任务、持续跟进。一份完整的会议记录，核心是把讨论过程压缩成三类信息：决议、行动项和待定事项。下面以一次产品周会为演示情景，给出一份填写完整的会议记录示例，并逐项解释写法、可迁移规律与适用边界。
要点总览（TL;DR）
- 会议记录的核心是把讨论压缩成决议、行动项和待定事项三类信息，让会后能直接分派和跟进。
- 示例采用“会议信息—议题与结论—行动项表—待定与风险”四段结构，行动项逐条写清单一负责人、交付物和截止时间。
- 决议要写成能判断完成与否的句子；待定事项要标注决策人和下次确认时间，避免悬空。
- 这套结构可迁移到评审会、复盘会和跨部门协调会，议题颗粒度和行动项侧重需随会议类型调整。
- 示例为演示情景，涉及敏感信息的会议、信息同步会以及任务排期与看板管理不适用照搬。
这份会议记录示例要解决什么问题
这份示例面向需要写工作会议纪要、并在会后推动落实的读者。它演示一次产品周会从会议信息到行动项分派的完整记录形态，目标是让读者拿到结构后能直接照着填。示例为演示情景，人物、议题和数据均为虚构，不代表任何组织的真实会议或实际效果。
判断一份会议记录是否达到“可跟进”标准，可以看三条：
- 决议可判断：每条决议写成能判断完成与否的句子，读者不看讨论过程也能知道定了什么。
- 行动项可分派：每项行动有单一负责人、明确交付物和截止时间，会后无需再追问“谁做、做什么、什么时候交”。
- 待定项有出口：未决问题标注决策人和下次确认时间，避免悬空。
记录对象限定为内部工作会议，包括周会、评审会、复盘会、跨部门协调会等。会议室设备调试、视频会议技术方案、会展策划不属于本文范围。
完整示例：一次产品周会的会议记录
以下为演示情景下的完整会议记录，可直接照抄结构替换内容。
会议基本信息
| 字段 | 内容 |
|---|---|
| 会议名称 | 产品周会（第 12 周） |
| 时间 | 周三 10:00–11:00 |
| 主持 | 产品负责人 |
| 记录人 | 产品运营 |
| 参会 | 产品、设计、研发、测试各 1–2 人 |
| 缺席 | 数据同事（已提前请假，相关议题顺延） |
议题一：新版本上线范围确认
讨论要点：研发反馈两个功能模块联调时间紧张；测试提出回归用例需提前一天准备；设计确认交互稿已定稿。讨论集中在“全量上线”与“分批上线”两种方案的时间与风险对比。
决议：本期版本按分批上线执行，首批包含模块 A 与模块 B，模块 C 顺延至下一版本；测试在首批上线前完成模块 A、B 的回归用例执行。
议题二：用户反馈处理机制
讨论要点：近期反馈集中在导出功能；现有处理流程缺少统一入口，反馈分散在多个渠道。讨论涉及是否设立固定处理节奏。
决议：设立每周一次的用户反馈集中处理，由产品运营汇总后分派；导出功能相关问题列为下周优先处理项。
行动项
| 事项 | 负责人 | 交付物 | 截止时间 | 状态 |
|---|---|---|---|---|
| 输出分批上线排期 | 研发负责人 | 含模块 A、B 节点与依赖的排期表 | 本周五 | 进行中 |
| 准备模块 A、B 回归用例 | 测试负责人 | 回归用例清单及执行记录 | 下周二 | 未开始 |
| 汇总各渠道用户反馈 | 产品运营 | 按问题类型归类的反馈汇总表 | 下周一 | 未开始 |
| 输出导出功能问题分析 | 产品经理 | 问题原因与处理建议说明 | 下周三 | 未开始 |
待定事项与需升级决策的问题
| 待定事项 | 决策人 | 下次确认时间 |
|---|---|---|
| 模块 C 顺延后的上线窗口 | 产品负责人 | 下次周会 |
| 用户反馈处理是否设固定值班人 | 产品负责人与研发负责人 | 下周一前书面确认 |
逐项解释：每条内容为什么这样写
示例中的每个字段都对应一个后续动作，写法差异会直接影响记录能否被使用。下面拆解关键字段的填写理由，并给出正误对照。
讨论要点只保留影响决策的信息
议题一的讨论要点写了三方各自的约束条件，因为这些条件直接支撑“分批上线”的决议。与决策无关的寒暄、重复陈述、已达成共识的细节可以省略。讨论要点的作用是让没参会的人理解决议从何而来，篇幅控制在一段以内即可。
决议写成可判断完成与否的句子
“本期版本按分批上线执行，首批包含模块 A 与模块 B”这样的句子，读者能直接判断是否执行到位。对照之下，“大家讨论了上线节奏，倾向于稳妥推进”只记录了讨论状态，没有形成可核对的结论。决议应包含对象、动作和范围，必要时写明例外。
行动项必须有单一负责人和明确交付物
示例中每项行动只写一个负责人，交付物写成可验收的产物，如“含模块 A、B 节点与依赖的排期表”，而非“跟进排期”。截止时间写到具体日期或星期，状态字段用于会后更新。多人共同负责容易导致无人推进，需要协作时在交付物中说明配合方，负责人仍保持单一。
| 写法 | 示例 | 问题或效果 |
|---|---|---|
| 模糊待办 | 尽快推进导出功能 | 无交付物、无时间，无法验收 |
| 可跟进行动项 | 产品经理于下周三前输出导出功能问题分析 | 负责人、交付物、时间齐全，可直接分派 |
待定事项标注决策人和下次确认时间
待定事项与行动项的区别在于：行动项是已决定要做的事，待定事项是尚未形成决议的问题。示例中“模块 C 顺延后的上线窗口”标注了决策人和确认时间，避免问题在会议结束后失去跟踪。需要升级到更高层级决策的问题，单独列出并写明升级对象。
从这份示例可以迁移的写法
示例的结构可以复用到评审会、复盘会和跨部门协调会，但议题颗粒度和行动项侧重需要随会议类型调整。
- 按会议类型调整议题颗粒度：评审会按评审对象拆分议题，每个议题写明评审结论（通过、有条件通过、退回）；复盘会按“目标—结果—原因—改进”组织，行动项侧重改进措施；跨部门协调会按部门职责划分议题，决议中写明各方承诺。
- 行动项与任务系统衔接：会议记录定稿后，把行动项逐条录入任务系统，保留负责人、交付物和截止时间三个字段，记录中的行动项表与系统中的工作项一一对应，后续状态以系统为准。ONES 支持将任务与文档放在同一项目空间内协作，记录人可在分发纪要时把行动项转为工作项，由负责人在系统中更新状态，减少会后另行同步的成本。
- 记录人在会后的确认与分发：记录人在会后当天整理纪要，先发给主持人和关键负责人确认决议与行动项表述，确认后分发至参会人及相关方，并注明反馈截止时间。
- 定期回看上次行动项：每次会议开头用几分钟核对上次行动项的完成情况，未完成的说明原因并重新约定时间，形成闭环习惯。
适用边界：哪些情况不适合照搬
这份示例是演示情景下的结构示范，不代表任何组织的实际会议效果，也不能作为会议质量的评价依据。以下情形需要调整或另作处理。
- 决策会与信息同步会的重点不同：决策会以决议和待定事项为主，讨论要点可精简；信息同步会以传达内容为主，行动项可能很少，照搬行动项表会显得冗余。
- 敏感信息的记录与分发受限：涉及人事、合同、未公开经营数据的会议，记录范围、留存方式和分发对象需按组织规定执行，示例中的全量分发做法不适用。
- 记录不替代任务排期与看板管理：会议记录负责固化决议和行动项，任务的排期、依赖管理和进度可视化需要在任务系统中完成，两者分工不同。
- 示例数据不可引用：文中人物、议题、时间和状态均为虚构，读者应替换为真实会议内容，不应把示例中的结构当作行业统一标准。
常见问题
会议记录和会议纪要是一回事吗，写的时候要区分吗？
日常使用中两个词常混用，本文按同一份产出处理。区别在于侧重点：记录偏向过程留痕，纪要偏向结论传达。工作会议的实用做法是合并成一份文档，讨论要点只保留支撑决策的信息，重点放在决议和行动项上，让没参会的人也能据此执行。
行动项负责人涉及多个部门时，怎么保证有人推进？
每项行动只设一个负责人，跨部门配合方写进交付物说明里，例如“研发负责人牵头，测试提供用例支持”。负责人对交付物和截止时间负责，配合方按约定提供输入。若确实需要两个部门各自交付，就拆成两条行动项，分别指定负责人和时间，避免一条行动项挂多个名字导致无人推进。
会上没形成结论的问题，记成待定事项还是行动项？
看是否已经决定要做。已经决定要做、只差执行的事写进行动项；尚未形成决议、需要进一步讨论或升级决策的问题写进待定事项，并标注决策人和下次确认时间。两者混写会让读者分不清哪些事已经在推进、哪些还悬着。
会议记录定稿后，行动项怎么跟进才不遗漏？
常见做法是记录定稿后把行动项逐条录入任务系统，保留负责人、交付物和截止时间三个字段，记录中的行动项表与系统中的工作项一一对应，后续状态以系统为准。ONES 支持将任务与文档放在同一项目空间内协作，记录人分发纪要时可以把行动项转为工作项，由负责人在系统中更新状态。每次会议开头再花几分钟核对上次行动项的完成情况，未完成的说明原因并重新约定时间。
涉及人事、合同这类敏感内容的会议，记录怎么处理？
记录范围、留存方式和分发对象按组织规定执行，示例中的全量分发做法不适用。可以只记录决议和必要的行动项，讨论过程从简，分发范围限定在必要人员内，并明确文档的访问权限和留存期限。
