会议记录的价值在于留下可执行的决议和行动项，让下次会议能逐项核对进展。本文给出一份完整的项目周会记录示例，按会前议程、会中讨论、决议与行动项表格逐段展示填写方式，再解释每个字段的写法依据，并说明如何迁移到评审会、复盘会等场景。示例中的团队、人名和项目均为演示情景，用于说明填写方法；记录形成后转入行动项跟进，可借助ONES的工作项与文档协作能力承载，本文只在与该环节相关处提及。
要点总览（TL;DR）
- 一份合格的会议记录要留下决议和行动项：决议能追溯到议题，行动项有负责人、动作、截止时间和验收标准，状态可供下次会议核对。
- 示例采用“基本信息—议程—讨论要点—决议—行动项”五段结构，行动项用表格呈现，会上未定人选的先写“指定人员”，把确认人选本身作为待办。
- 行动项写法要避免“跟进一下”“尽快”这类模糊表述，改为具体对象、具体动作和可核对的时间点，验收标准说明怎样算完成。
- 迁移到评审会、复盘会、决策会时骨架不变，按会议类型调整详略：评审会增加评审意见段，复盘会按原因分析组织，决策会保留备选方案和论据。
- 示例为演示情景，不构成真实案例或实测效果；决策类、对外会议和敏感信息场景需要调整记录范围与留痕要求，排期与看板流转归任务管理。
示例要解决什么问题：一份能推动行动项闭环的会议记录
会议记录的核心用途是留下决议与行动项，供未参会者了解结论、供参会者会后执行。逐字复述发言既耗时又难检索，读者真正需要的是：这件事定了什么、谁去做、什么时候做完、怎么算做完。示例围绕这四个问题组织内容，展示一份记录从空白到可跟进状态的完整样子。
判断一份会议记录是否合格，可以用下面几条标准核对：
- 决议可追溯：每条决议能对应到具体议题和讨论依据，读者知道结论是怎么来的。
- 行动项要素齐全：每项待办都有负责人、具体动作、截止时间和完成标准，缺一项就容易在跟进时扯皮。
- 状态可跟进：行动项带有状态字段，下次会议前能快速筛出未完成项。
- 讨论与结论分离：讨论要点压缩记录，结论单独成条，避免读者在长段落里找答案。
- 信息可定位：会议主题、时间、参会角色、记录人齐全，便于日后检索和追溯。
示例情景设定如下：某产品团队召开项目周会，主题为“版本发布准备”，参会角色包括产品负责人、研发负责人、测试负责人、设计负责人和记录人，会议时长一小时。团队、人名、项目名和日期均为虚构，仅用于演示字段填写方式，不代表任何真实客户案例或实测效果。
完整示例：一次项目周会的会议记录全文
以下是一份填写完整的会议记录，从基本信息到行动项表格一次呈现。读者可以对照自己的会议记录模板，检查字段是否齐全。
会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | 版本发布准备周会（演示） |
| 会议时间 | 2025年3月10日 14:00–15:00 |
| 参会角色 | 产品负责人、研发负责人、测试负责人、设计负责人、记录人 |
| 缺席与代参会 | 无 |
| 记录人 | 记录人（产品团队） |
| 会议目标 | 确认发布范围、遗留缺陷处理方式和上线检查项分工 |
会前议程
- 确认本次发布范围与冻结时间（产品负责人，10分钟）
- 遗留缺陷清单与处理意见（测试负责人，20分钟）
- 上线检查项与分工（研发负责人，20分钟）
- 行动项确认与下次会议时间（记录人，10分钟）
按议题记录的讨论要点与结论
议题一：发布范围与冻结时间。讨论要点：产品负责人说明本期范围包含三个功能模块，其中报表导出模块依赖外部接口联调；研发负责人提出联调进度存在不确定性。结论：本期发布范围维持三个模块不变，代码冻结时间定在3月14日18:00，联调未完成的部分顺延至下一版本。
议题二：遗留缺陷处理。讨论要点：测试负责人列出当前遗留缺陷共12个，其中2个为高优先级；研发负责人评估修复工作量后认为可在冻结前完成高优先级缺陷修复。结论：2个高优先级缺陷必须在冻结前修复并回归通过，其余10个中低优先级缺陷记录到下一版本处理，不在本期阻塞发布。
议题三：上线检查项与分工。讨论要点：团队逐项核对上线检查清单，发现监控告警配置和回滚方案两项尚未明确责任人。结论：监控告警配置由研发负责人指定人员完成，回滚方案由测试负责人牵头编写，两项均在发布前完成评审。
决议清单
- 本期发布范围维持三个功能模块，代码冻结时间为3月14日18:00。
- 2个高优先级缺陷在冻结前修复并回归通过；其余10个缺陷转入下一版本。
- 监控告警配置与回滚方案在发布前完成并经过评审。
行动项表格
| 编号 | 行动项 | 负责人 | 截止时间 | 验收标准 | 状态 |
|---|---|---|---|---|---|
| A1 | 完成报表导出模块外部接口联调 | 研发负责人 | 3月13日18:00 | 联调环境跑通三个主流程，结果记录在联调文档 | 进行中 |
| A2 | 修复2个高优先级缺陷并提交回归 | 研发负责人 | 3月14日12:00 | 缺陷状态变为已修复，测试负责人回归通过 | 未开始 |
| A3 | 编写回滚方案并组织评审 | 测试负责人 | 3月13日17:00 | 方案文档完成，评审记录留存，评审结论为通过 | 未开始 |
| A4 | 完成监控告警配置 | 研发负责人指定人员 | 3月13日18:00 | 关键接口告警规则生效，触发一次测试告警验证 | 未开始 |
| A5 | 整理本期遗留缺陷清单并转入下一版本 | 测试负责人 | 3月12日18:00 | 10个缺陷已关联下一版本，清单在项目文档中可查 | 未开始 |
下次会议时间：3月17日14:00，议程为逐项核对上述行动项状态并确认发布结果。记录人在会后当天将本记录发送至参会角色，行动项同步进入团队的任务跟进清单。
逐项解释：每个字段为什么这样填
示例中的字段并非越多越好，每一项都对应一个后续动作。下面拆解关键字段的填写依据，并给出常见写法的对照。
议题与讨论要点：压缩到可回溯的程度
讨论要点记录的是“谁提出了什么关键信息、分歧在哪里”，不记录发言顺序和口语细节。示例中议题一保留了“联调进度不确定”这一关键风险，因为它直接影响了冻结时间的决议；寒暄和重复确认则省略。判断标准是：读者只看记录，能否理解结论形成的依据。如果某个讨论点与任何决议和行动项都无关，可以只留一句概括或不记。
决议与讨论：分开写，结论单独成条
讨论是过程，决议是结果。示例把决议从议题段落中抽出，单独列为清单，原因是跟进时人们只查决议，不重读讨论。写法上，决议用陈述句写明“定了什么”，避免“大家讨论了……”“倾向于……”这类模糊表述。一条决议对应一个明确结论，包含多个结论时拆成多条，便于逐条核对落实。
行动项：负责人、动作、截止时间、验收标准四要素
行动项最容易出问题的地方是写得像愿望。对照下面的正误写法可以看出差别：
| 要素 | 模糊写法 | 示例中的写法 | 差别说明 |
|---|---|---|---|
| 动作 | 跟进一下联调 | 完成报表导出模块外部接口联调 | 写明具体对象和完成动作，避免“跟进”这类无法判断完成与否的动词 |
| 负责人 | 研发那边 | 研发负责人 | 落到具体角色或人，团队名义容易无人认领 |
| 截止时间 | 尽快 | 3月13日18:00 | 给出可核对的时间点，与后续会议节奏衔接 |
| 验收标准 | 做完就行 | 联调环境跑通三个主流程，结果记录在联调文档 | 说明怎样算完成，减少交付时的争议 |
示例中A4的负责人写作“研发负责人指定人员”，是因为会上尚未确定具体人选。这种写法保留了责任人链条，同时把指定动作本身作为待办，下次会议核对时先确认人选是否已定。
状态与跟进字段：为下次会议准备筛选条件
状态字段（未开始、进行中、已完成、阻塞）的作用是让下次会议不必逐条询问，直接按状态筛出未完成和阻塞项。示例中A1标为“进行中”，其余为“未开始”，下次会议只需重点核对A1的进展和其余项的启动情况。状态由负责人更新、记录人汇总，更新时点定在下次会议前一天，保证会上看到的是接近真实的情况。
记录形成后，行动项需要进入团队日常的任务跟进载体。ONES支持将工作项与文档关联，记录中的行动项可以作为工作项分配负责人、设置截止时间并更新状态，会议记录文档与工作项相互引用，下次会议前按状态筛选即可完成核对。这一衔接适合行动项数量较多、需要跨角色跟踪的团队；行动项很少的小团队用共享文档加状态列也能运转。
可迁移规律：换一个会议场景怎么套用
示例的结构可以拆成“基本信息—议程—讨论要点—决议—行动项”五段，迁移到其他会议时，调整的是各段的详略和字段侧重，骨架保持不变。
记录结构随会议类型调整
| 会议类型 | 结构侧重 | 调整方式 |
|---|---|---|
| 项目周会 | 进度与行动项 | 沿用示例结构，行动项表格为重点，讨论要点从简 |
| 方案评审会 | 评审意见与结论 | 增加“评审意见”段，逐条记录意见、提出人和处理方式；决议写明通过、有条件通过或不通过 |
| 项目复盘会 | 原因分析与改进项 | 讨论要点按“发生了什么—为什么—下次怎么做”组织，行动项侧重改进措施和验证方式 |
| 决策类会议 | 备选方案与决策依据 | 记录各备选方案的关键论据和最终选择理由，留痕要求更高，讨论要点不宜过度压缩 |
行动项提取的通用步骤
- 会中每形成一个结论，追问一句“接下来谁做什么”，当场记录为候选行动项。
- 会后由记录人逐条补齐负责人、截止时间和验收标准，缺项的标注“待确认”并在当天向相关角色确认。
- 把行动项与对应决议编号关联，保证每条行动项都能追溯到决议来源。
- 将行动项同步到团队的任务跟进清单，设定状态更新时点和下次核对时间。
议程与模板的复用方法
会前议程按“议题—主讲角色—时长”三列准备，每个议题写明期望产出的结论类型（如“确认范围”“确定处理方式”），这样会中记录时可以直接按议题归档讨论和决议。模板复用指固定字段而非固定内容：基本信息、议程、讨论要点、决议、行动项五段作为默认结构，评审会在此基础上增加评审意见段，复盘会增加原因分析段。模板每季度按实际使用情况调整一次字段，删去长期空置的字段，补充反复出现的遗漏项。
记录到跟进的分工与节奏
记录人负责会中记录和会后当天整理发送；各行动项负责人负责在约定时点前更新状态；会议主持人在下次会议开场用五分钟核对行动项，未完成项说明原因并重新约定时间。节奏上，记录在会后当天发出，状态更新在下次会议前一天完成，核对放在下次会议开头，形成“记录—执行—核对”的固定循环。
适用边界：示例不能直接照搬的情况
本文示例为演示情景，团队构成、项目内容和时间安排均为虚构，用于说明填写方法。它不构成真实客户案例，也不代表任何工具的实际使用效果；读者照用时需要替换为自己的会议信息和角色分工。
以下情形需要调整记录方式，不宜直接套用示例：
- 决策类会议：涉及资源投入、方案取舍的会议，记录需要保留备选方案、关键论据和反对意见，讨论要点不能像周会那样压缩，留痕要求更高，必要时需参会人确认记录内容。
- 对外会议：与客户、供应商或合作方的会议，记录范围、措辞和共享对象需要事先约定，涉及商务条款的内容应单独存档，不并入内部周会模板。
- 敏感信息场景：涉及人事、薪酬、未公开经营数据的会议，记录应限定字段范围，只记决议和行动项，讨论细节另行保管或不予记录，并明确记录的查阅权限。
- 与任务排期的边界：会议记录负责留下决议和行动项，具体排期、优先级调整和看板流转属于任务管理范畴，记录中只需写明行动项的去向，不必在记录里维护完整排期。
记录详略还应与会议频率匹配：高频短会可以只保留决议和行动项两段，低频长会再补全讨论要点。判断是否照搬示例的标准是：记录发出后，未参会者能否据此了解结论，负责人能否据此执行，下次会议能否据此核对。三条都满足，记录就是可用的。
常见问题
会上没来得及确定负责人和截止时间，行动项该怎么记？
先把行动项本身写清楚，负责人和截止时间留空并标注“待确认”，会后当天由记录人向相关角色确认后补齐。示例中A4的负责人写作“研发负责人指定人员”，就是把指定人选这个动作本身作为待办，下次会议核对时先确认人选是否已定。这样处理保留了责任人链条，也避免因为当场定不下来就漏记整条行动项。
会议记录和会议纪要是一回事吗，需要写多详细？
日常使用中两个说法常混用，关键差别在详略。本文示例偏向执行导向的记录：讨论要点压缩到能解释结论依据的程度，决议和行动项完整保留。如果记录只用于内部跟进，高频短会可以只保留决议和行动项两段；如果会议涉及方案取舍或对外留痕，讨论要点需要更完整，必要时请参会人确认记录内容。
行动项同步到任务工具后，会议记录还需要维护状态吗？
建议只在一处维护状态，避免两边不一致。常见做法是会议记录保留行动项表格作为决议留痕，状态以任务跟进清单为准，下次会议前从清单筛选未完成和阻塞项。示例中记录人负责会后汇总、负责人更新状态、主持人开场核对，分工明确后记录文档不必逐条追着改。
评审会和复盘会能直接套用这个模板吗？
骨架可以沿用，字段需要增减。评审会在讨论要点之后增加“评审意见”段，逐条记录意见、提出人和处理方式，决议写明通过、有条件通过或不通过；复盘会按“发生了什么—为什么—下次怎么做”组织讨论，行动项侧重改进措施和验证方式。直接照搬周会模板容易漏掉评审结论或原因分析这两类关键信息。
涉及人事或未公开数据的会议，记录范围怎么控制？
先约定记录字段范围，只记决议和行动项，讨论细节另行保管或不予记录，并明确记录的查阅权限和共享对象。对外会议的记录措辞和共享范围也需要事先约定，涉及商务条款的内容单独存档。这类会议不宜直接套用内部周会模板，记录发出前最好由会议主持人确认。
