会议纪要示例通常把会议信息、讨论要点、决议、行动项、待确认事项五类内容放在同一份文档里，其中行动项要写清负责人、截止时间和验收标准。下面给出一份虚构但完整的项目周会纪要范例，逐项说明字段写法，并示范换成评审会、复盘会时如何调整；行动项需要持续跟踪时，可借助ONES把纪要中的事项落到可跟进的工作项。
要点总览（TL;DR）
- 会议纪要示例通常包含五类内容：会议基本信息、讨论要点、会议结论、行动项、待确认事项，五类分区保留即可适配多数团队例会。
- 行动项要一条一事、一人负责，写清截止时间和可核验的验收标准，并保留状态字段，让纪要能持续更新而不是一次性记录。
- 讨论要点记录谈了什么，结论记录定了什么，两者分开写，读者不必从讨论中自行提炼决定。
- 换成需求评审会、方案决策会或复盘会时，调整各部分的详略和行动项颗粒度，决策会重点保留备选方案与决策依据。
- 示例为虚构演示情景，涉及敏感信息、对外正式文件或跨项目议题时，需按组织制度调整分发范围并增加复核环节。
示例目标：这份会议纪要要解决什么问题
本文的范例设定为一次虚构的“星河项目”周会，项目处于开发中期，参会角色包括项目经理、产品负责人、前端负责人、后端负责人、测试负责人和设计负责人。会议时长一小时，讨论版本进度、两个阻塞问题和下一阶段排期。所有项目名称、人名、日期和数据均为演示用途，不指向任何真实客户或团队。
这份示例希望达成三个目标。第一是可追溯：会后任何人翻看纪要，都能知道会上讨论了什么、结论是什么、依据是什么。第二是可执行：每条行动项都能直接派给一个人，并在约定日期判断是否完成。第三是可交接：缺席成员或后续接手的人，只读纪要就能补齐上下文，不需要再找人复述。
围绕这三个目标，范例在写法上做了取舍：讨论过程压缩为要点，结论单独成段，行动项统一进表格，未定事项不混入决议。读者可以按自己团队的会议节奏调整篇幅，但五类内容的分区建议保留。
完整示例：一次项目周会的会议纪要全文
以下为虚构示例的纪要全文，可直接参照其结构填写。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议名称 | 星河项目第 12 次周会 |
| 时间 | 2025 年 3 月 10 日 14:00–15:00 |
| 地点 | 线上会议 |
| 主持人 | 项目经理 林某 |
| 记录人 | 产品助理 周某 |
| 参会人 | 林某、陈某（产品）、吴某（前端）、赵某（后端）、孙某（测试）、郑某（设计） |
| 缺席人 | 钱某（运维），已提前请假 |
讨论要点
- 版本进度：前端页面完成约七成，后端接口联调受登录模块阻塞，测试环境尚未部署最新构建。
- 登录模块问题：第三方鉴权回调在测试环境偶发超时，后端初步判断与网络策略有关，需要运维配合排查。
- 设计稿变更：个人中心页面交互有调整，设计侧已出第二版，需产品确认后同步前端。
- 上线时间：原定 3 月 21 日提测，按当前进度存在风险，会上讨论了两个备选方案。
会议结论
- 提测时间维持 3 月 21 日不变，登录模块问题作为最高优先级处理，若 3 月 14 日前未解决，则顺延至 3 月 24 日并同步通知相关方。
- 个人中心页面采用设计第二版，产品在 3 月 11 日前完成确认，前端据此排期。
- 测试环境部署由运维在 3 月 12 日前完成，部署完成后测试负责人启动冒烟验证。
行动项
| 序号 | 事项 | 负责人 | 截止时间 | 验收标准 | 状态 |
|---|---|---|---|---|---|
| 1 | 排查登录模块回调超时，给出原因说明与修复方案 | 赵某（后端） | 3 月 14 日 | 测试环境连续三次登录成功，附排查记录 | 进行中 |
| 2 | 确认个人中心第二版设计稿并回复设计侧 | 陈某（产品） | 3 月 11 日 | 在设计稿评论区给出确认或修改意见 | 未开始 |
| 3 | 完成测试环境最新构建部署 | 钱某（运维） | 3 月 12 日 | 测试环境可访问，版本号与开发分支一致 | 未开始 |
| 4 | 部署完成后执行冒烟用例并反馈结果 | 孙某（测试） | 3 月 12 日 | 冒烟用例执行完毕，结果记录在测试文档 | 未开始 |
| 5 | 更新项目排期表，标注提测风险与备选日期 | 林某（项目经理） | 3 月 11 日 | 排期表可见两个提测日期及触发条件 | 未开始 |
待确认事项
- 登录模块问题若由外部网络策略导致，修复责任方是运维还是后端，需在 3 月 13 日临时沟通中明确。
- 个人中心第二版是否影响已完成的自动化用例，待测试负责人评估后补充结论。
下次会议安排
下次周会定于 2025 年 3 月 17 日 14:00，线上进行，重点回顾行动项完成情况与提测准备状态。会议纪要于会后一个工作日内发出，行动项同步到项目跟踪工具。
逐项解释：每个字段为什么这样写
范例中的每个字段都对应一个具体判断，理解写法理由比照抄格式更重要。
行动项为什么必须写负责人和截止时间
行动项只写“跟进登录问题”，会后无法判断谁在做、做到哪一步。写上单一负责人，责任才可落到人；写上截止时间，才能在下次会议前判断是否逾期。验收标准进一步回答“做到什么程度算完成”，例如“连续三次登录成功”比“修复问题”更容易核验。状态字段则让纪要从一次性记录变成可持续更新的清单。
常见错误有三类：一是负责人写成部门或“相关同学”，导致无人认领；二是截止时间写成“尽快”，无法排期；三是把多个动作塞进一条行动项，完成一半时状态难以标注。拆成一条一事、一人负责，后续跟踪会顺畅很多。
结论与讨论过程如何区分记录
讨论要点记录“会上谈了什么”，结论记录“会上定了什么”。范例中登录模块的排查思路属于讨论，提测时间维持不变并设定顺延条件属于结论。两者分开写的好处是：读者不必从大段讨论中自行提炼决定，执行时也不会把某个人的临时观点误当成团队决议。讨论要点宜用短句概括，结论宜用完整句写清条件和结果。
待确认事项单独列出的作用
会上没有形成结论的问题，如果混在结论里，容易被误读为已定事项；如果直接删掉，又会丢失上下文。单独列出待确认事项，并写明由谁在什么时间前确认，可以把悬而未决的问题显性化。范例中登录问题的责任归属和自动化用例影响评估，都属于这类内容。
缺席人员如何补位阅读
缺席成员读纪要时，最需要知道的是与自己相关的行动项和结论变化。范例在基本信息区标注缺席人，在行动项中保留其负责事项，并在下次会议安排中说明回顾重点，缺席者据此可以快速定位需要补做的动作。若缺席者负责的事项需要会上讨论才能推进，记录人应在待确认事项中注明补充沟通安排。
可迁移规律：换成评审会、周会怎么改
五段式结构是通用骨架，不同会议类型调整的是各部分的详略和行动项的颗粒度。
五段式结构在不同会议类型中的取舍
| 会议类型 | 结构重点 | 可精简部分 |
|---|---|---|
| 项目周会 | 进度、阻塞、行动项、风险 | 背景介绍可省略 |
| 需求评审会 | 评审对象、评审意见、修改结论、待补充材料 | 讨论过程可压缩为意见条目 |
| 方案决策会 | 备选方案、评估依据、最终决策、决策条件 | 行动项可减少，重点记录决策理由 |
| 项目复盘会 | 事实回顾、原因分析、改进措施、责任分工 | 会议信息区可简化 |
以需求评审会为例，讨论要点改为“评审意见”，逐条记录评审人对需求文档的具体意见；结论改为“评审结论”，写明通过、有条件通过或不通过；行动项聚焦文档修改和补充材料，验收标准写成“修改稿覆盖全部评审意见”。以方案决策会为例，结论部分要写清选择了哪个方案、依据是什么、什么条件下需要重新评估，避免只留一句“方案 A 通过”。
行动项颗粒度的把握
颗粒度以“一个人在一个截止时间内能独立完成并接受验收”为准。周会行动项通常在一到两周内可完成；评审会行动项多为修改文档、补充材料，周期更短；复盘会的改进措施可能跨月，此时应拆成阶段性节点，每个节点单独设截止时间。颗粒度过粗会导致状态长期停在“进行中”，过细则增加跟踪成本。
纪要与任务跟踪的衔接方式
纪要是静态文档，行动项需要进入团队日常跟踪的载体，否则容易在两次会议之间被遗忘。常见做法是会后把行动项逐条录入任务工具，保留负责人、截止时间和验收标准三个关键字段，并在下次会议前核对状态。ONES 的文档与工作项协作可以承接这一环节：会议、反馈和文档可以转化为可执行的需求，行动项落到工作项后按状态推进，减少纪要与执行两张皮的情况。具体字段映射和操作方式以团队实际配置为准。
会议纪要归档与检索的基本做法
归档时按“项目—会议类型—日期”组织，文件名包含会议名称和日期，便于按时间线检索。纪要正文保留行动项表格的最终状态，或在文末附状态更新记录。涉及多次会议延续的议题，可在新纪要中链接上一次纪要的对应条目，形成可追溯的讨论链。团队规模较大时，可约定统一的纪要模板和存放位置，降低查找成本。
适用边界：哪些情况不适合照搬这份示例
这份示例适用于节奏稳定、议题明确的团队例会，以下情形需要调整写法或另行处理。
- 决策会与复盘会的记录重点不同。决策会需要完整保留备选方案和评估依据，复盘会需要区分事实与推断，照搬周会的简写方式会丢失关键判断依据。
- 涉及敏感信息或合规要求的会议，纪要的分发范围、留存期限和脱敏要求应按组织制度执行，示例中的公开分发方式不适用。
- 示例中的角色、日期和验收标准均为演示设定，读者应替换为真实信息，不能直接引用示例数据作为项目依据。
- 本文不构成对任何工具功能、版本或价格的承诺，工具选型与配置请以实际产品和团队需求为准。
- 会议室设备调试、视频会议技术问题不在本文讨论范围，相关事项应另行记录和处理。
当会议议题跨多个项目、参会人超过一定规模，或需要形成对外正式文件时，建议在五段式基础上增加议题分节和审批环节，并由专人复核后再分发。
常见问题
会议纪要里的行动项，负责人写部门还是写具体的人？
写具体的人。负责人写成部门或“相关同学”，会后往往无人认领，也无法在下次会议前判断进度。如果一项工作确实需要多人配合，可以指定一名主责人，其余协作人写在事项描述里。同时给这条行动项配一个截止时间和验收标准，例如“测试环境连续三次登录成功，附排查记录”，完成与否就能直接核验。
会上没有形成结论的议题，应该写进会议纪要吗？
建议写，但单独列在“待确认事项”里，不要混进会议结论。混进结论容易被误读为已定事项，直接删掉又会丢失上下文。写法上注明待确认的问题、由谁在什么时间前给出结论，例如“登录问题若由外部网络策略导致，修复责任方需在 3 月 13 日临时沟通中明确”。这样悬而未决的问题就变成了一条可跟进的事项。
纪要发出后，行动项怎么避免在两次会议之间被遗忘？
常见做法是会后把行动项逐条录入团队日常使用的任务跟踪载体，保留负责人、截止时间和验收标准三个关键字段，下次会议前先核对状态。ONES 的文档与工作项协作可以承接这一环节，会议、反馈和文档可以转化为可执行的需求，行动项落到工作项后按状态推进。具体字段映射和操作方式以团队实际配置为准。
缺席成员应该怎么读会议纪要？
先看基本信息区的缺席标注，再定位行动项表格中由自己负责的事项，最后看会议结论中与自身工作相关的变化。如果缺席者负责的事项需要会上讨论才能推进，记录人应在待确认事项中注明补充沟通安排。纪要中保留缺席者的负责事项，是为了让责任不因缺席而悬空。
涉及敏感信息的会议，纪要写法要改吗？
要改。示例中的公开分发方式只适用于一般团队例会。涉及敏感信息或合规要求的会议，纪要的分发范围、留存期限和脱敏要求应按组织制度执行，必要时在五段式基础上增加审批环节，由专人复核后再分发。议题跨多个项目或需要形成对外正式文件时，也建议增加议题分节和复核步骤。
