一份合格的会议记录，会后应当让人不用再追问就能推进工作：谁在什么时候交什么，会上定了什么、还有什么没定，都能从记录里找到。本文给出一份完整填写的项目周会会议记录范例，逐项解释字段为什么这样写，再说明换成评审会、客户会时如何调整。示例为演示情景，不指向任何真实客户或会议；行动项需要交接为可跟踪的工作项时，可借助ONES承载相关任务与文档。
要点总览（TL;DR）
- 一份合格的会议记录要让人会后无需追问就能推进：基本信息完整、每个议题有结论或标注待决、行动项可验收。
- 行动项写成可验收的交付物，同时具备具体负责人、看得见的产物和写到日期的截止时间，避免“跟进”“推进”这类模糊动词。
- 讨论要点记录结论与分歧，不记录发言流水；待决事项单列，写明确认人与确认时间，不与行动项混写。
- 记录骨架固定为会议基本信息、议题讨论要点与结论、行动项表、待决事项与下次会议安排，换成评审会、客户会时只调整议题区与行动项区的详略。
- 示例适用于内部例会、项目周会、评审会等常规会议；行动项进入任务排期与看板后归任务管理，字段需按组织审批与归档要求调整。
这份会议记录示例要解决什么问题
这份示例演示的是一次常规项目周会：团队需要把讨论过程压缩成可回溯的结论，把会上承诺的事情转成可执行的行动项。记录的目标有两个层次。第一层是可回溯，会后任何人翻看记录，能知道某个决定是在哪次会上、基于什么讨论做出的；第二层是可执行，每条行动项都有明确的负责人、交付物和截止时间，接收人不需要再找主持人确认。
判断一份会议记录是否合格，可以用一个简单标准：会后无需再问就能推进。具体拆成三条可核验的检查项。其一，会议基本信息完整，包括主题、时间、主持人和参会情况，缺席者能据此判断自己是否需要补看某段内容。其二，每个议题都有结论或明确标注为待决，读者不会把讨论中的想法误当成已定事项。其三，行动项可以验收，负责人是具体的人，交付物是看得见的产物，截止时间写到日期。
需要说明的是，本文示例的字段是通用写法，用于说明记录结构，并非某个产品的预置模板还原。组织实际的审批流程、归档要求和保密规定不同，字段的取舍与详略应据此调整。
完整示例：一次项目周会的会议记录
以下为一份完整填写的会议记录范例，会议背景设定为某产品迭代项目的例行周会，内容为演示情景。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | XX项目第12次周会：迭代范围确认与上线准备 |
| 会议时间 | 2025年3月18日 14:00–15:00 |
| 会议地点/形式 | 线上会议 |
| 主持人 | 李敏（项目经理） |
| 记录人 | 王磊 |
| 参会人 | 李敏、王磊、张涛（研发）、陈静（测试）、赵宇（设计） |
| 缺席人 | 周琳（运营），已同步会议纪要 |
议题讨论要点与结论
议题一：本次迭代范围是否包含数据导出功能。讨论中张涛提出导出功能依赖的接口尚未联调完成，按当前进度存在延期风险；赵宇认为导出入口的设计稿已就绪，可以先做界面。结论：本次迭代暂不包含数据导出功能，移至下一迭代；本期保留导出入口的占位设计，由赵宇在3月21日前提供占位方案。分歧点：运营侧希望本期上线导出，该诉求记录为待决事项。
议题二：上线前的测试准入标准。陈静说明当前用例通过率为演示数据，核心流程用例已全部执行，剩余为边界场景。结论：以核心流程用例全部通过、无阻断级缺陷作为上线准入条件，边界场景问题可带入上线后首个补丁版本处理。
议题三：上线时间与灰度安排。李敏提出按原计划3月28日上线，先对内部账号灰度两天。讨论确认灰度范围与回滚预案由张涛负责整理。结论：上线时间维持3月28日，灰度方案在3月24日前评审。
行动项
| 编号 | 事项 | 负责人 | 交付物 | 截止时间 | 状态 |
|---|---|---|---|---|---|
| A1 | 提供导出入口占位设计方案 | 赵宇 | 设计稿链接及说明 | 3月21日 | 进行中 |
| A2 | 整理灰度范围与回滚预案 | 张涛 | 灰度方案文档 | 3月24日 | 未开始 |
| A3 | 组织灰度方案评审 | 李敏 | 评审会议纪要及结论 | 3月24日 | 未开始 |
| A4 | 输出核心流程用例执行结果 | 陈静 | 测试报告 | 3月26日 | 进行中 |
待决事项与下次会议安排
待决事项：运营侧提出的本期上线数据导出诉求，需在下次周会前由李敏与周琳确认优先级，再决定是否调整迭代范围。下次会议：3月25日14:00，同一会议形式，议题包括灰度方案评审结论同步与上线前最终检查。
逐项解释：每个字段为什么这样写
范例中的每个字段都对应一个具体的记录判断，下面拆解关键写法及其取舍依据。
讨论要点写结论与分歧，不写发言流水
议题一没有记录“张涛说接口没联调完，赵宇说设计稿好了”这样的发言顺序，而是把讨论收敛为风险、可行性和最终结论三部分，并单独标出分歧点。这样写的理由是：会议记录服务的是会后决策回溯，读者关心的是定了什么、为什么这么定，谁在第几分钟说了什么对推进工作没有帮助。发言流水会让记录变长，也会让结论淹没在过程描述里。
行动项写成可验收的交付物
对比两种写法：“A2 张涛 跟进灰度方案”与“A2 张涛 整理灰度范围与回滚预案，交付灰度方案文档，3月24日前”。前者只有模糊动词，接收人无法判断做到什么程度算完成；后者有明确的产物和日期，验收时可以对照文档是否存在、内容是否覆盖灰度范围和回滚预案。行动项的可执行性取决于三个要素同时具备：具体负责人、可验收的交付物、写到日期的截止时间。
负责人写具体的人，不写部门
“研发组负责”这类写法在会后往往无人认领，因为部门不是执行主体。范例中每条行动项都落到姓名，并在基本信息区标注了各人角色，读者能判断该找谁。若组织习惯以角色记录，也应写到“测试负责人陈静”这种可定位到人的程度。
状态字段支持会后跟踪
行动项表保留状态列，记录时统一填“未开始”或“进行中”，会后由负责人更新。状态字段的价值在于让会议记录从一次性文档变成跟踪入口，下次会议可以直接对照上周行动项的完成情况，而不必重新回忆。
待决事项单列，不与行动项混写
运营侧的数据导出诉求没有形成结论，也没有指定执行人，它属于待决事项而非行动项。把两者混在一起，会导致读者误以为已经有人在做。单列待决事项并写明“由谁在何时之前确认”，既保留了问题的可见性，也明确了推动责任。
| 字段 | 不推荐写法 | 推荐写法 |
|---|---|---|
| 讨论要点 | 按发言顺序逐条记录 | 风险、分歧、结论分段呈现 |
| 行动项 | 跟进导出功能 | 提供导出入口占位设计方案，交付设计稿链接，3月21日前 |
| 负责人 | 设计部 | 赵宇（设计） |
| 截止时间 | 本周内 | 3月21日 |
| 未定事项 | 混入行动项表 | 单列待决事项，写明确认人与时间 |
可迁移规律：换成周会、评审会、客户会怎么改
这份范例的骨架可以固定为四块：会议基本信息、议题讨论要点与结论、行动项表、待决事项与下次会议安排。换会议类型时，骨架不变，调整的是议题区的记录重点和行动项区的字段详略。
评审会的重点在结论与决策依据。议题区需要补充评审对象、评审意见和通过与否的判定，结论要写明依据了哪些材料或标准，便于后续追溯为什么做出该判断。行动项通常围绕修改意见展开，交付物写清修改后的版本或文档。
客户会需要增加对外承诺与跟进人。行动项中涉及对客户承诺的部分，应写明承诺内容、对接口径和内部跟进人，避免口头承诺无人落实。待决事项区要区分内部待决与需客户确认的事项，前者由内部推动，后者注明等待客户反馈的时间点。
项目例会与本文范例最接近，重点是上周行动项的完成情况与本周计划。可以在行动项表前增加一段上周行动项回顾，直接引用上次记录的状态列，形成连续跟踪。
记录长度随会议复杂度伸缩，字段不删只调详略。十五分钟的站会可以把议题区压缩为一句话结论，行动项表保留核心列；两小时的方案评审则需要完整的讨论依据和意见清单。字段的完整性保证了不同长度的记录都能被同一套方式阅读和检索。
当行动项需要进入任务排期和看板跟踪时，记录本身已经完成了交接。ONES Wiki支持会议记录的高效沉淀，并提供模板库一键创建各类文档；文档可关联项目任务、嵌入任务进度，使会议结论与后续执行保持在同一条信息链上。记录人可以在同一份文档中完成从纪要撰写到行动项交接的过程，减少会后二次转录。
适用边界与常见误用
这份示例适用于内部例会、项目周会、评审会等常规会议，核心是记录讨论结论与行动项。它不覆盖会议室设备调试、视频会议技术方案与会展策划等事务，这些属于会务与技术保障范畴。行动项一旦进入任务排期与看板，就归入任务管理，本文的范围到记录与交接为止，不展开排期方法与看板设计。
常见误用有几种。第一种是把会议记录写成发言实录，篇幅很长但找不到结论，读者需要自己从过程描述里提炼决定。第二种是行动项只有动词没有产物，比如“推进”“跟进”“落实”，会后无法判断是否完成。第三种是把待决事项写成行动项，制造已经有人在做的假象。第四种是截止时间写“尽快”“本周”，缺少可对照的日期。第五种是照搬示例字段而不顾组织实际，审批与归档要求不同的团队，应在骨架基础上增删字段，而不是原样套用。
使用这份示例时，建议先确认本组织的归档与保密要求，再决定记录的详略和可见范围。示例中的字段是通用起点，团队可以在此基础上形成自己的固定模板，让每次会议的记录结构保持一致，便于跨会议检索和对比。
常见问题
会议记录里的行动项和待决事项怎么区分？
判断标准是会上是否已经形成结论并指定了执行人。行动项有明确的负责人、交付物和截止时间，会后直接执行；待决事项是讨论过但没有定论、也没有指定执行人的问题，需要写清由谁在什么时间之前确认。把待决事项混入行动项表，读者会误以为已经有人在推进，问题反而被掩盖。
会议记录需要记录每个人的发言吗？
常规例会与项目周会不需要逐条记录发言。记录的重点是每个议题的风险、分歧和结论，读者关心的是定了什么、依据是什么。发言流水会让篇幅变长，结论被过程描述淹没。涉及决策依据的评审会，可以记录关键意见及其提出人，便于后续追溯判断来源。
行动项交给任务系统跟踪后，会议记录还要保留吗？
建议保留。会议记录承担的是回溯职能：某个决定在哪次会上、基于什么讨论做出，需要从记录中查证；任务系统承担的是执行跟踪。两者可以关联，记录中的行动项交接为工作项后，下次会议直接对照完成情况即可。ONES Wiki 支持文档关联项目任务并嵌入任务进度，会议结论与后续执行可以保持在同一信息链上。
十五分钟的站会也要用这套完整字段吗？
字段保留，详略压缩。站会可以把议题区收敛为一句话结论，行动项表保留事项、负责人、截止时间和状态四列，基本信息只留日期与参会人。字段不删的好处是不同长度的记录能被同一套方式阅读和检索，团队不必为每种会议维护不同的记录习惯。
示例中的字段可以直接作为团队固定模板吗？
可以作为起点，但需要结合组织的审批、归档与保密要求调整。例如需要走审批的会议可能增加审批状态字段，涉及敏感信息的会议要控制文档可见范围。ONES Wiki 支持为不同角色配置读写权限，并记录页面版本、支持查看与回滚，便于在统一模板下管理访问与修改痕迹。
