一份可直接参照的会议记录示例，通常包含会议基本信息、议题与讨论要点、决议、行动项和待确认问题五部分。其中行动项要写成“动词+对象+结果”的可验收句式，并补齐负责人和截止日期。本文给出一份完整填写的项目周例会记录范例，逐项解释字段写法，并说明换到评审会、复盘会时如何调整。行动项需要落到可跟进的工作项时，可借助ONES Wiki把会议记录与项目任务关联起来。
要点总览（TL;DR）
- 一份完整的会议记录示例包含五部分：会议基本信息、议题与讨论要点、决议、行动项、待确认问题与下次会议安排。
- 行动项写成“动词+对象+结果”的可验收句式，负责人写到具体的人，截止时间精确到日，有前置依赖的写明条件。
- 决议记录已达成一致的结论并注明生效范围，讨论要点保留分歧与依据，两者分开写，避免把过程当结论。
- 换到评审会、复盘会或正式决策会时，按会议要产出的内容调整字段重点，记录长度随会议颗粒度取舍。
- 示例中的时间、人名、数据均为演示设定；正式决策留痕、敏感信息可见范围和归档工具需按组织规范确定。
示例目标：这份会议记录要解决什么问题
先交代示例的假设情景，避免读者把演示内容误读为真实客户案例。本文设定一个跨角色的项目周例会：项目负责人主持，产品、研发、测试、设计各有一名代表参加，另有一名成员因出差缺席。会议时长一小时，讨论版本进度、两个阻塞问题和下阶段排期。记录人由项目助理担任。
这份示例要达成两个目标。第一，让未参会者读完记录就能理解会议结论：讨论了什么、定了什么、还有什么没定。第二，让行动项可以被跟进：每项任务有明确负责人、截止时间和验收标准，会后能确认、能回写进展。两个目标对应两种读者——需要了解背景的协作方，和需要执行任务的负责人。
需要说明的是，示例中的项目名称、人名、日期和数据均为演示设定，用于展示字段如何填写，不构成真实客户案例，也不代表任何实际项目的进展或成效。读者套用时，应替换为本团队的真实信息，并按组织现有的会议规范调整字段。
完整示例：一份填好的项目周例会记录
以下是一份字段齐全、前后自洽的会议记录范例，可直接作为填写样板参照。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | “星河”版本 V1.2 项目周例会（第 8 周） |
| 会议时间 | 2025 年 3 月 14 日 14:00–15:00 |
| 会议地点/形式 | 线上会议 |
| 主持人 | 项目负责人 林岚 |
| 参会人 | 林岚（项目）、周恺（产品）、陈默（研发）、许宁（测试）、方雨（设计） |
| 缺席人 | 赵启（研发，出差），会后由陈默转达要点 |
| 记录人 | 项目助理 苏禾 |
议题与讨论要点
议题一：V1.2 版本开发进度。陈默汇报核心模块已完成 70%，剩余部分依赖接口联调。周恺提出联调接口文档上周五才定稿，研发启动时间被压缩。讨论后确认：联调顺延两天，但版本提测日期不变，测试阶段压缩一天缓冲。分歧点在于是否调整提测日期，最终以“提测日期不变、测试增加并行用例”收口。
议题二：两个阻塞问题。其一，测试环境数据库频繁超时，许宁反馈近三天出现四次，影响回归效率。陈默判断与近期数据量增长有关，需运维协助排查。其二，设计稿中两处交互与现有组件不一致，方雨与周恺对是否本期修改存在分歧，讨论后决定本期先按现有组件实现，交互优化放入下个版本。
议题三：下阶段排期。确认下周重点为联调收尾与提测准备，测试团队提前介入编写用例，设计团队输出下版本交互清单。
决议
- V1.2 版本提测日期维持 3 月 21 日不变，联调顺延两天，测试阶段采用并行用例补回一天缓冲。生效范围：本版本研发与测试排期。
- 测试环境数据库超时问题由研发与运维联合排查，排查结论在下次周会前同步。生效范围：测试环境维护。
- 设计稿中两处交互不一致，本期按现有组件实现，交互优化纳入下版本需求池。生效范围：本期开发范围与下版本需求。
行动项
| 事项 | 负责人 | 截止时间 | 验收标准 | 状态 |
|---|---|---|---|---|
| 完成剩余模块接口联调并提交联调记录 | 陈默 | 3 月 18 日 | 联调记录中全部接口标记通过，遗留问题列明处理人 | 进行中 |
| 编写 V1.2 回归用例并完成评审 | 许宁 | 3 月 19 日 | 用例覆盖本期全部需求点，评审记录留档 | 未开始 |
| 联合运维排查测试环境数据库超时并输出结论 | 陈默、运维接口人 | 3 月 20 日 | 输出排查结论，明确原因与处理方案 | 进行中 |
| 输出下版本交互优化清单 | 方雨 | 3 月 20 日 | 清单含问题描述、优先级与建议方案 | 未开始 |
| 向赵启转达本次会议要点 | 陈默 | 3 月 14 日 | 赵启确认已了解排期调整与本人相关任务 | 已完成 |
待确认问题与下次会议安排
- 测试环境数据库超时的根因尚未确定，待排查结论出来后判断是否影响提测。
- 下版本交互优化的范围需产品与设计进一步对齐，暂不列入本期决议。
- 下次周会：2025 年 3 月 21 日 14:00，线上会议，重点回顾行动项完成情况与提测准备。
逐项解释：每个字段为什么这样写
示例给的是成品，理解每个字段的判断依据，才能在自己的会议里写对。下面按关键字段逐条说明，并给出常见写法的对照。
行动项写成“动词+对象+结果”的可验收句式
行动项的价值在于会后能被判断“做完没有”。示例中“完成剩余模块接口联调并提交联调记录”，动词是“完成”和“提交”，对象是“接口联调”和“联调记录”，结果是记录中接口全部标记通过。这样的写法让负责人知道交付什么，也让跟进者知道凭什么判断完成。对照来看，“跟进联调进度”只有动作没有结果，无法验收；“联调问题尽快处理”缺少对象和完成标志，容易拖成悬空事项。
负责人写具体角色或姓名
示例中每项行动项都落到具体的人，涉及跨团队协作时写“陈默、运维接口人”，明确主责人与协作方。写“相关同学”“研发团队”看似覆盖全面，实际无人认领，会后确认时容易出现互相等待。如果某项任务确实需要团队共同完成，也应指定一名主责人，其余人作为协作方列出。
截止时间写到日，并说明依赖前置条件
示例中的截止时间都精确到日，与会议日期形成清晰的时间线。对于存在前置依赖的任务，要在事项描述或备注中写明条件，例如“待排查结论出来后判断是否影响提测”。只写“下周内”这类模糊表述，会让不同人对期限的理解产生偏差；写明依赖关系，则能在前置条件变化时及时调整后续安排。
决议与讨论要点分开记录
讨论要点记录的是过程：谁提出了什么、分歧在哪里、依据是什么。决议记录的是结果：已经达成一致、可以对外执行的结论，并注明生效范围。示例中“是否调整提测日期”的争论写在讨论要点里，最终“提测日期不变、测试并行补缓冲”写入决议。把讨论过程直接当结论，会让未参会者误以为尚未定论；只写结论不写依据，则后续复盘时难以还原判断逻辑。
待确认问题单列
会议中总有一些问题当场无法定论。示例把数据库超时根因、下版本交互范围单独列出，与决议和行动项区分开。这样做的好处是：悬空事项有明确归属，不会被误当成已决事项执行；下次会议可以直接从待确认清单接着讨论，减少重复沟通。
可迁移规律：换到评审会、复盘会怎么改
示例的字段结构来自会议类型，换会议类型时字段取舍也要跟着变。核心规律是：会议要产出什么，记录就重点写什么。评审会要产出结论和遗留问题，复盘会要产出原因分析和改进项，周会要产出进度判断和行动项。
| 会议类型 | 重点字段 | 可弱化字段 | 行动项特点 |
|---|---|---|---|
| 项目周例会 | 进度、阻塞问题、行动项 | 完整讨论过程 | 短期、可验收、按周回写 |
| 方案/需求评审会 | 评审结论、通过条件、遗留问题 | 背景介绍 | 修改项与复审时间绑定 |
| 项目复盘会 | 原因分析、改进项、责任归属 | 逐条过程记录 | 改进项带衡量指标与检查节点 |
| 正式决策会 | 决议原文、表决或确认情况、生效范围 | 讨论细节 | 决议执行项与留痕要求 |
行动项与决议的边界也需要按会议类型把握。决议是“定了什么”，通常不需要负责人，但需要生效范围；行动项是“谁在什么时候做什么”，必须有负责人和截止时间。一项决议可能对应多个行动项，例如“本期按现有组件实现”是决议，由此产生的“输出下版本交互优化清单”才是行动项。
记录长度按会议颗粒度取舍。周会记录可以只保留关键分歧和结论，不必逐句还原发言；评审会和决策会则需要更完整地保留结论表述和确认过程。会后节奏上，记录通常在会后当天分发，负责人确认行动项，之后按截止节点回写进展，下次会议开场先回顾上期行动项状态。
当行动项需要持续跟进时，可以把会议记录沉淀在文档中，并将行动项关联到项目任务。ONES Wiki 支持周报、会议记录高效沉淀，文档可关联项目任务，也支持嵌入任务进度和各类报表，便于在记录中直接看到行动项的推进状态；成员可以在线添加注释、评论，会后确认和补充说明都能留在同一份文档里。记录模板可通过模板库一键创建，减少每次从零搭结构的工作。
适用边界：示例不能直接套用的情形
这份示例适合日常项目周会、团队例会和一般性工作同步会，字段结构可以直接参照。换到其他情形时，需要先确认以下条件。
- 正式决策会议需要更严格的表述与留痕。涉及资源投入、范围变更、对外承诺等决策时，决议应写明决策依据、生效范围和生效时间，并按组织要求保留确认记录。示例中的简写方式不足以支撑这类会议的追溯要求。
- 敏感信息需控制可见范围。涉及人事、薪酬、客户合同或未公开计划的会议记录，应按组织的信息分级要求限定可见人员。ONES Wiki 支持为多种角色配置不同的读写权限，可作为控制可见范围的一种方式，具体配置仍以组织规范为准。
- 示例中的时间、人名、数据均为演示设定。读者应替换为真实信息，不将示例中的日期、进度和结论当作实际项目依据。
- 记录工具与归档方式按组织规范确定。有的团队用文档协作工具沉淀会议记录，有的用项目管理系统关联任务，选择时以团队已有的协作习惯和归档要求为准，不必为套用示例而更换工具。
把握住“结论可读、行动可跟”这两个目标，字段可以增删，格式可以调整；脱离这两个目标去追求模板完整，记录反而会变成会后无人翻看的存档。
常见问题
会议记录里的行动项和决议需要分开写吗？
建议分开写。决议回答“定了什么”，例如“本期按现有组件实现，交互优化纳入下版本”，需要注明生效范围；行动项回答“谁在什么时候做什么、做到什么程度”，必须有负责人、截止时间和验收标准。一项决议可能对应多个行动项，分开记录后，跟进时只看行动项表就能判断执行进度，复盘时也能对照决议检查执行是否偏离。
会上没有形成结论的议题怎么记录？
把这类议题放进“待确认问题”单列，写清楚当前卡在哪里、需要谁提供什么信息、计划在什么时间点继续讨论。不要把它混进决议，否则未参会者会误以为已经定案；也不要直接删掉，否则下次会议容易重复讨论。示例中数据库超时根因和下版本交互范围就是这样处理的，下次会议可以从这份清单接着推进。
用文档工具记录会议，行动项怎么保证会后有人跟进？
关键动作有三个：会后当天把记录分发给参会人和相关协作方；由每项行动项的负责人确认自己的任务、截止时间和验收标准；按截止节点回写进展，下次会议开场先回顾上期行动项状态。如果团队使用 ONES Wiki，会议记录可以沉淀在文档中，文档能关联项目任务并嵌入任务进度，成员也可以在线添加注释和评论，确认与补充说明都留在同一份文档里。
周会记录需要逐句还原每个人的发言吗？
通常不需要。周会记录的重点是进度判断、阻塞问题和行动项，讨论过程只保留关键分歧和判断依据即可。评审会、正式决策会则需要更完整地保留结论表述和确认过程，因为后续要据此追溯决策。记录颗粒度按会议类型和留痕要求确定，判断标准是：未参会者能否读懂结论，负责人能否据此执行。
涉及人事或合同的会议记录，在文档工具里怎么控制可见范围？
先按组织的信息分级要求确定哪些人能看，再在工具里配置对应权限。ONES Wiki 支持为多种角色配置不同的读写权限，可以作为控制可见范围的一种方式，具体角色划分和配置方式仍以组织规范为准。除了权限设置，记录标题和存放位置也建议做区分，避免敏感内容出现在公共页面树中。
