会议纪要示例的价值在于让读者看完就能照着填。本文提供一份完整的项目周会纪要范本，覆盖会前信息、议题讨论、决议、行动项和待定事项，并逐字段说明填写选择，再给出迁移到评审会、复盘会等场景的改写规则。文中会议名称、人员与议题均为演示情景，不代表真实客户案例。行动项跟进环节会自然衔接ONES的文档与工作项协作方式。
要点总览（TL;DR）
- 一份可照填的会议纪要包含六个区块：会议基本信息、议题与讨论要点、决议清单、行动项、待定事项、下次会议安排。
- 行动项按“事项—负责人—截止时间—验收标准—状态”填写，负责人写单人，验收标准写成可检查的结果。
- 讨论要点压缩为可回溯的记录，决议只放已达成一致、可对外引用的结论，待定事项单独成区并写明确认人和确认时间。
- 迁移到评审会、复盘会、跨部门协调会时，主要调整议题区与决议区的写法，行动项颗粒度随会议层级变化。
- 示例不覆盖会议室设备、视频会议技术、会展策划，也不展开任务排期与看板管理；字段数量按团队会议节奏取舍。
示例目标：这份会议纪要要解决什么问题
这份示例面向需要定期开项目周会、并把会议结论落到执行上的团队。它示范两个关键动作：把散落在讨论中的信息收敛为明确决议，再把决议拆成有负责人、有截止时间、有验收标准的行动项。读者可以把它当作填写模板，替换会议名称、参会人员和议题内容即可使用。
示例同时承担一个校准作用：让记录人知道哪些内容值得写、写到什么颗粒度、哪些讨论可以压缩。很多纪要写成了发言流水账，会后没人回看；也有纪要只写“已讨论某问题”，没有结论和后续动作。这份范本用固定区块把“讨论—决议—行动项”分开，避免两类问题。
需要说明的是，示例中的项目名称、人员姓名、日期和具体议题均为演示情景，用于展示填写方式，不代表任何真实客户案例，也不声称经过实测或产生特定效果。团队实际使用时，字段数量、议题数量和行动项颗粒度应按自身会议节奏调整。
完整示例：一份项目周会会议纪要范本
以下是一份填写完整的项目周会纪要示例。假设某团队正在推进“客户门户改版”项目，本周召开例行周会，讨论进度、风险和下周安排。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议名称 | 客户门户改版项目 第 12 次周会 |
| 会议时间 | 2025 年 3 月 14 日 14:00–14:50 |
| 会议地点/方式 | 线上会议 |
| 主持人 | 张明（项目经理） |
| 记录人 | 李婷 |
| 参会人员 | 张明、王磊（前端）、陈芳（后端）、赵宇（测试）、李婷（产品） |
| 缺席人员 | 周航（设计，请假，已提前提交设计进度说明） |
议题与讨论要点
议题一：登录模块改版进度
王磊汇报前端登录页已完成 80%，剩余验证码组件联调。陈芳说明后端接口已就绪，联调依赖前端提测时间。讨论后确认：验证码组件采用现有服务，不新增第三方依赖。
议题二：性能测试安排
赵宇提出性能测试需要稳定的测试环境，当前环境与开发共用，存在数据干扰。讨论后确认：由陈芳在下周三前提供独立测试环境，赵宇随后启动压测。
议题三：设计稿交付节奏
周航缺席，李婷代读其进度说明：剩余两个页面的高保真设计稿将于下周一交付。会议确认按此节奏推进，若延期由李婷同步影响范围。
决议清单
- 登录页验证码组件沿用现有服务，不引入新的第三方依赖。
- 性能测试使用独立测试环境，环境由后端在 3 月 19 日前提供。
- 剩余两个页面设计稿按 3 月 17 日交付，延期时由产品同步对排期的影响。
行动项
| 事项 | 负责人 | 截止时间 | 验收标准 | 状态 |
|---|---|---|---|---|
| 完成登录页验证码组件联调并提测 | 王磊 | 3 月 18 日 | 测试环境可完成登录全流程，无阻断性缺陷 | 进行中 |
| 提供独立性能测试环境 | 陈芳 | 3 月 19 日 | 环境可访问，测试数据与开发环境隔离 | 未开始 |
| 交付剩余两个页面高保真设计稿 | 周航 | 3 月 17 日 | 设计稿覆盖全部交互状态并经产品确认 | 进行中 |
| 启动性能压测并输出首轮报告 | 赵宇 | 3 月 21 日 | 报告包含关键接口响应时间与瓶颈定位 | 未开始 |
待定事项与下次会议
- 待定：门户首页改版范围是否纳入本期，需产品与业务方在 3 月 18 日前确认，确认人李婷。
- 待定：压测发现瓶颈后的修复排期，待首轮报告出来后评估。
- 下次会议：2025 年 3 月 21 日 14:00，线上会议，主持人张明，记录人李婷。
逐项解释：每个字段为什么这样填
范本可以直接照抄结构，但每个字段的填写方式决定了纪要是否好用。下面按区块说明填写选择，并给出常见错误写法对照。
讨论要点：压缩为可回溯的记录
讨论要点记录的是“谁提出了什么、依据是什么、讨论后倾向如何”，不逐句还原发言。示例中每个议题控制在两三句话，保留关键判断依据，例如“联调依赖前端提测时间”这类影响排期的信息。常见错误是把会议录音转成逐字稿，或只写“讨论了登录进度”而没有结论线索。判断标准是：一周后回看，能否还原当时为什么做出这个决定。
决议：写成明确结论
决议区只放已经达成一致、可以对外引用的结论。示例中“验证码组件沿用现有服务，不引入新的第三方依赖”是明确结论；模糊写法如“验证码问题后续再看”无法作为执行依据。每条决议尽量包含对象、选择和必要的条件，避免使用“尽快”“适当”等无法核验的词。
行动项：负责人、截止时间、验收标准三要素
行动项表格是整份纪要最需要较真的部分。示例中每条行动项都回答了四个问题：做什么、谁负责、什么时候完成、怎样算完成。验收标准要写成可检查的结果，例如“测试环境可访问，测试数据与开发环境隔离”，而不是“环境准备好”。状态列用于会后更新，初次记录时填“未开始”或“进行中”即可。
| 要素 | 推荐写法 | 常见问题写法 |
|---|---|---|
| 事项 | 完成登录页验证码组件联调并提测 | 跟进登录问题 |
| 负责人 | 王磊（单一负责人） | 前端组（多人共担，实际无人推进） |
| 截止时间 | 3 月 18 日 | 尽快、本周内 |
| 验收标准 | 测试环境可完成登录全流程，无阻断性缺陷 | 做完即可 |
缺席人员与待定事项的处理
缺席人员在基本信息区列明，并注明是否已提前提交材料，示例中周航请假但提交了设计进度说明，会议据此继续推进。待定事项单独成区，写明待定内容、确认人和确认时间，避免混入决议造成误解。下次会议时间在纪要末尾固定，便于参会人直接安排日程。
可迁移规律：换一种会议怎么改这份示例
这份范本的区块结构可以复用到多数工作型会议，变化主要在议题区和决议区的写法，以及行动项的颗粒度。下面按会议类型说明调整方式。
| 会议类型 | 议题区调整 | 决议区调整 | 行动项颗粒度 |
|---|---|---|---|
| 项目周会 | 按模块或任务线组织，突出进度与风险 | 记录排期、资源和范围变更 | 到具体任务，通常一周内可完成 |
| 方案评审会 | 按评审维度组织，记录评审意见与分歧点 | 记录通过、有条件通过或不通过的结论及修改要求 | 到修改项，明确修改人和复审时间 |
| 复盘会 | 按“预期—实际—差异—原因”组织 | 记录可复用的经验与需要改变的流程 | 到改进措施，注明责任人和验证节点 |
| 跨部门协调会 | 按部门关注点组织，记录各方诉求与约束 | 记录达成的协作约定与升级路径 | 到对接人和交付物，注明双方确认方式 |
行动项颗粒度随会议层级变化：周会行动项落到个人和具体任务，通常一周内可验收；评审会行动项落到修改项和复审节点；复盘会行动项落到流程改进措施，验收周期可能跨数周。记录详略的取舍原则是：与决策相关的信息保留，过程性发言压缩；涉及排期、资源、范围的内容优先保留，纯信息同步可以只留一句结论。
字段数量也应按团队节奏取舍。会议频率高、议题稳定的团队可以精简基本信息区；跨部门会议则需要更完整的参会与缺席记录，便于后续追溯谁确认过什么。
适用边界：示例不能替代的部分
这份示例聚焦纪要文本本身的写法，有几类内容不在覆盖范围内。会议室设备调试、视频会议平台的技术配置属于会务与IT支持范畴，示例不涉及。会展策划、大型活动的议程编排与场地安排同样不在本文讨论范围。
纪要写完之后的任务排期、看板管理和迭代规划属于任务管理范畴，本文只在下一节说明行动项如何进入跟进流程，不展开排期方法和看板设计。示例中的字段数量和议题数量是演示用的，团队应结合自身会议频率、参会规模和决策链条调整，照搬字段数量反而可能增加记录负担。
此外，示例不提供任何产品的价格、版本或认证信息，涉及工具选型时需以实际部署和官方说明为准。
从纪要到闭环：行动项如何进入协作流程
纪要写完只是起点，行动项能否被领取、更新和验收，决定了会议是否真正产生结果。一个可操作的闭环通常包含四步：纪要以文档形式归档，行动项逐条转为可分派的工作项，负责人领取并更新状态，到期前提醒并在下次会议或评审节点核对完成情况。
在这个流程中，纪要文档与行动项工作项需要保持对应关系。每条行动项在文档中有编号或链接，工作项中回指纪要出处，这样回看时既能读到当时的讨论背景，也能看到当前执行状态。负责人领取后更新状态，临近截止时间收到提醒，完成后由提出方或评审人按验收标准确认，未完成的事项进入下次会议议题。
ONES 可以在这一环节承载上述流程：ONES Wiki 用于知识库管理与纪要文档归档，ONES Project 用于项目管理与行动项工作项的跟踪，ONES Assistant 作为智能 AI 助手可在需求澄清等场景提炼要点与待澄清问题，方案层面还包含 MCP 服务用于智能体协作。具体模块的开通与配置以实际部署为准。对于希望让纪要不只停留在文档里的团队，可以把文档归档与工作项跟踪放在同一协作环境中，减少会后手工转抄和状态不同步。
常见问题
会议纪要里讨论要点写多细比较合适？
判断标准是回看时能否还原决策依据。每个议题保留“谁提出、依据是什么、讨论后倾向如何”，两三句话即可；涉及排期、资源、范围的信息优先保留，纯信息同步可以只留一句结论。把录音转成逐字稿，或只写“讨论了某问题”而没有结论线索，都会让纪要在会后失去参考价值。
行动项的负责人可以写一个团队吗？
建议写单一负责人。写“前端组”这类多人共担的表述，实际执行中容易出现无人推进的情况。如果一项工作确实需要多人协作，可以拆成几条行动项分别指定负责人，或在事项中注明主责人与配合人，主责人仍只写一个名字。验收标准同样要落到可检查的结果上，例如“测试环境可访问，测试数据与开发环境隔离”，避免“做完即可”这类无法核验的写法。
缺席人员没有提前提交材料，纪要该怎么处理？
在基本信息区列明缺席人员，并在对应议题下注明“未参与讨论”。涉及该人员职责的决议，要么改为待定事项，写明确认人和确认时间；要么由主持人当场指定代理人给出意见，并在纪要中记录代理关系。示例中缺席的设计人员提前提交了进度说明，会议据此继续推进；没有材料时，相关议题宜转为待定，避免形成未经确认的决议。
待定事项和行动项有什么区别，能不能合并？
两者性质不同。行动项是已经确定要做、有负责人和截止时间的事项；待定事项是尚未形成结论、需要进一步确认的内容，通常要写明待定内容、确认人和确认时间。合并会让读者分不清哪些已经定了、哪些还在等确认。待定事项确认后，可以在下次纪要中转为决议或行动项，形成连续记录。
纪要写完后行动项怎么跟进，避免只停留在文档里？
常见做法是把每条行动项转为可分派的工作项，负责人领取后更新状态，临近截止时间收到提醒，完成后由提出方或评审人按验收标准确认，未完成的事项进入下次会议议题。纪要文档与工作项之间保持对应关系，工作项回指纪要出处，回看时既能读到讨论背景，也能看到当前执行状态。ONES 可在这一环节承载：ONES Wiki 用于知识库管理与纪要文档归档，ONES Project 用于项目管理与行动项工作项的跟踪，ONES Assistant 作为智能 AI 助手可在需求澄清等场景提炼要点与待澄清问题，方案层面还包含 MCP 服务用于智能体协作，具体模块的开通与配置以实际部署为准。
