本文提供一份可直接复制到文档或表格中的会议纪要模板，由会议基本信息、议题与讨论要点、决议、行动项四块组成，并逐字段说明填写口径、必填与选填的划分，附一次产品评审会的完整填写示例。模板适合周会、评审会、复盘会等常见团队会议；行动项需要转入任务清单持续跟进时，可借助ONES的任务与项目协作能力承接状态回填与关闭。
要点总览（TL;DR）
- 模板由会议基本信息、议题与讨论要点、决议、行动项四块组成，另设会后确认区，可直接复制到文档或表格使用。
- 行动项是模板的关键：每条写清做什么、谁负责、何时完成、当前状态，负责人写具体个人，截止日期写到日。
- 必填字段为会议名称、时间、主持人、记录人、决议、行动项描述、负责人、截止日期；决策会需补决议依据与生效条件，状态在会后跟进阶段转为必填。
- 行动项转入任务清单后，状态在任务侧更新并回填纪要，避免两处各记一套；模板按周会、评审会、复盘会派生变体并定期回顾。
可复制空白会议纪要模板
下面这张表可以直接复制到在线文档或表格工具中使用。会议开始时先填基本信息，讨论过程中记录要点，会议结束前补齐决议与行动项，会后按行动项区逐条跟进。表格按四个功能区加一个确认区排列，复制后可按需增删行。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 会议基本信息 | 会议名称 | |
| 会议时间 | ||
| 地点或线上方式 | ||
| 主持人 | ||
| 记录人 | ||
| 参会人与缺席人 | ||
| 议题与讨论要点 | 议题 | |
| 讨论要点 | ||
| 结论倾向 | ||
| 决议 | 决议内容 | |
| 决议依据 | ||
| 生效条件 | ||
| 行动项 | 编号 | |
| 行动项描述 | ||
| 负责人 | ||
| 截止日期 | ||
| 优先级 | ||
| 状态 | ||
| 备注 | ||
| 关联决议 | ||
| 会后确认 | 纪要发送范围 | |
| 确认方式 | ||
| 确认截止时间 |
如果会议议题较多，议题与讨论要点区按议题逐条展开，每个议题占一行或一个小节；行动项区按条编号，一条行动项占一行。复制使用时保留表头，清空“填写内容”列即可作为空白模板反复使用。
每个字段记录什么：字段说明
同一份模板由不同人填写，结果常常差异很大：有人把讨论过程写进决议，有人把行动项写成“跟进一下”。字段说明的作用是统一口径，让不同记录人写出的纪要可以对比、可以检索、可以交接。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 会议名称 | 本次会议的主题标识 | 写清会议类型与主题，如“XX产品V2.3需求评审会” | 只写“周会”“评审会”，事后无法区分 |
| 会议时间 | 会议发生的日期与时段 | 写到分钟，如“3月12日 14:00–15:30” | 只写日期，跨时区或补记时无法核对 |
| 地点或线上方式 | 会议发生的场所或会议工具 | 写会议室名称或线上会议入口名称 | 留空导致远程参会人无法回溯 |
| 主持人 | 对会议进程负责的人 | 写姓名加角色，如“李敏（产品负责人）” | 只写姓名，重名时难以确认 |
| 记录人 | 负责整理纪要的人 | 写姓名，便于会后核对与补充 | 多人同时记录，版本冲突 |
| 参会人与缺席人 | 实际到会与应到未到的人员 | 写姓名加角色，缺席人单独列出 | 只写“全体”，无法确认谁需要确认纪要 |
| 议题 | 本次会议要讨论的事项 | 一个议题一行，用名词短语表述 | 把多个议题合并成一句 |
| 讨论要点 | 讨论过程中的主要观点与分歧 | 记录关键论据、不同意见和待确认点，不逐字记录 | 把讨论要点直接写成结论 |
| 结论倾向 | 讨论后形成的方向性判断 | 写“倾向方案A，待评估成本后确认”这类带条件的表述 | 把倾向写成已定决议 |
| 决议内容 | 会议最终确定的事项 | 一条决议一句话，写清确定的是什么 | 与讨论要点混在一起，无法区分是否已定 |
| 决议依据 | 做出该决议的理由 | 写数据、评审意见或约束条件 | 只写“大家同意”，事后无法解释 |
| 生效条件 | 决议开始执行的前提 | 写“经技术负责人确认后生效”等条件 | 默认立即生效，忽略审批环节 |
| 行动项描述 | 需要完成的具体动作 | 写成可执行动作，包含对象和交付物，如“输出V2.3接口文档初稿” | 写“跟进一下”“再看看”这类模糊表述 |
| 负责人 | 对行动项结果负责的人 | 写具体个人姓名，不写部门或团队 | 写“产品组”，无人真正负责 |
| 截止日期 | 行动项应完成的日期 | 写到日，如“3月18日” | 写“下周”“尽快”，无法判断是否逾期 |
| 优先级 | 行动项的紧急与重要程度 | 使用统一取值，如高、中、低 | 每人自定一套等级，无法排序 |
| 状态 | 行动项当前进展 | 使用统一取值，如待开始、进行中、已完成、已取消 | 状态写法五花八门，统计困难 |
| 备注 | 补充说明 | 写依赖关系、阻塞原因或相关链接 | 把行动项描述塞进备注 |
讨论要点与决议的区分是填写中最容易出错的地方。讨论要点记录的是过程：谁提出了什么观点、分歧在哪里、哪些问题尚未确认；决议记录的是最终确定的事项，一条决议应当能独立读懂，不依赖上下文。会议结束时如果某个议题只有讨论没有结论，就留在讨论要点区，不要勉强写成决议。
行动项描述要写成别人拿到就能执行的动作。“跟进接口文档”不如“输出V2.3接口文档初稿并发送给前端负责人评审”，后者明确了交付物和接收对象。负责人写具体个人，是因为部门或团队无法对结果负责；截止日期写到日，状态使用统一取值，后续统计按期关闭率时才有可比口径。
必填与选填怎么划分
模板字段过多，轻量周会也要填半小时；字段过少，正式评审会又缺少依据。合理的做法是先划定一组必填字段保证纪要可用，再按会议类型调整。
| 字段 | 默认要求 | 说明 |
|---|---|---|
| 会议名称 | 必填 | 纪要的检索入口 |
| 会议时间 | 必填 | 确定纪要对应的时点 |
| 主持人 | 必填 | 确认会议组织责任 |
| 记录人 | 必填 | 确认纪要维护责任 |
| 决议 | 必填 | 无决议的会议可写“本次无决议” |
| 行动项描述 | 必填 | 会议产出的核心 |
| 负责人 | 必填 | 行动项落地的前提 |
| 截止日期 | 必填 | 判断是否按期完成的依据 |
| 地点或线上方式 | 选填 | 线上会议可记录入口名称 |
| 缺席人 | 选填 | 需要补会时填写 |
| 优先级 | 选填 | 行动项较多时启用 |
| 备注 | 选填 | 有依赖或阻塞时填写 |
| 附件链接 | 选填 | 有演示材料或数据时补充 |
按会议类型调整时，可以遵循以下建议：决策会必须填写决议依据和生效条件，否则事后无法解释决议从何而来；评审会建议保留结论倾向字段，记录未通过项的修改方向；周会可以省略决议依据，把重点放在行动项和状态更新上；复盘会则需要保留讨论要点中的分歧记录，便于后续改进。
行动项状态在会议当场可以留空或写“待开始”，进入会后跟进阶段后转为必填。这样记录人不必在会议中反复确认状态，跟进人按周更新即可。状态字段一旦启用，就应保持取值统一，避免同一团队出现“进行中”“处理中”“在做”三种写法。
填写示例：一次产品评审会的完整纪要
以下示例为演示情景，展示各字段如何落地，以及一条行动项从记录到关闭的写法。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 会议基本信息 | 会议名称 | XX产品V2.3需求评审会 |
| 会议时间 | 3月12日 14:00–15:30 | |
| 地点或线上方式 | 三楼会议室A | |
| 主持人 | 李敏（产品负责人） | |
| 记录人 | 王磊（产品经理） | |
| 参会人与缺席人 | 参会：李敏、王磊、陈晨（前端负责人）、赵宇（后端负责人）、周婷（测试）；缺席：孙浩（设计） | |
| 议题与讨论要点 | 议题 | V2.3批量导入功能是否纳入本期范围 |
| 讨论要点 | 陈晨提出批量导入涉及文件解析，前端改造量约三天；赵宇认为后端接口可复用现有导入服务；周婷指出缺少大文件场景的测试用例。孙浩缺席，交互稿尚未评审。 | |
| 结论倾向 | 倾向纳入本期，待交互稿评审和测试用例补充后确认 | |
| 决议 | 决议内容 | V2.3纳入批量导入功能，范围限定为单次不超过5000行 |
| 决议依据 | 后端接口可复用，前端改造量在排期内可消化；超过5000行的场景留待V2.4 | |
| 生效条件 | 交互稿评审通过后生效 | |
| 行动项 | 编号 | A-01 |
| 行动项描述 | 输出批量导入交互稿并组织评审 | |
| 负责人 | 孙浩 | |
| 截止日期 | 3月15日 | |
| 优先级 | 高 | |
| 状态 | 待开始 | |
| 备注 | 依赖设计排期，评审需陈晨参加 | |
| 关联决议 | V2.3纳入批量导入功能 | |
| 会后确认 | 纪要发送范围 | 参会人、缺席人及项目群 |
| 确认方式 | 文档内回复“已确认” | |
| 确认截止时间 | 3月13日 18:00 |
同一张表中还可以继续列出A-02、A-03等行动项，例如“补充大文件导入测试用例，负责人周婷，截止3月19日”“评估前端改造排期并回复，负责人陈晨，截止3月14日”。每条行动项都包含动作、负责人、截止日期和状态，与S1模板字段一一对应。
状态变化按同一行更新即可。A-01在3月13日交互稿初稿完成后，状态改为“进行中”，备注补一句“初稿已发评审群”；3月15日评审通过后，状态改为“已完成”，备注更新为“评审通过，交互稿已归档”。这样一条行动项从“待开始”到“进行中”再到“已完成”的过程都留在同一行，事后回看能还原推进节奏，也便于统计按期关闭情况。
模板的调整与长期维护
一份模板用久了会出现两种问题：字段越加越多，填写负担变重；或者字段长期没人看，形同虚设。维护的重点是让字段与会后跟进的实际动作保持对应。
按会议类型派生变体是常见做法。周会版保留基本信息、行动项和状态更新，讨论要点从简；评审会版强化结论倾向、决议依据和生效条件；复盘会版增加讨论要点中的分歧记录和改进项。三个变体共用同一套字段口径，只在必填范围和行数上做取舍，避免每个团队各写一套。
字段增删可以用一个标准判断：新增字段是否会被会后跟进使用。如果某个字段只在会议当场填一次、之后无人查阅，就不必加入模板；如果它会影响行动项的排序、验收或统计，就值得保留。例如“关联决议”字段在行动项较多时能帮助追溯来源，值得保留；“会议时长”对跟进没有直接作用，可以省略。
行动项与任务跟踪的衔接决定了模板能否长期运转。纪要中的行动项转入任务清单后，状态应在任务侧更新并回填到纪要，避免两处各记一套。使用ONES时，可以把行动项建为工作项，指定负责人和截止日期，按状态流转推进，会议纪要文档与工作项关联，会后查看任务状态即可同步纪要中的行动项进展。这样纪要负责记录会议产出，任务系统负责持续推进，两者通过同一批行动项对应起来。
模板本身也需要定期回顾。建议每月或每季度统计一次行动项的按期关闭情况：哪些行动项逾期、逾期集中在哪些负责人或哪类会议、哪些字段从未被填写。按期关闭率偏低时，先检查行动项描述是否足够具体、截止日期是否合理，再考虑调整字段；如果某个选填字段长期空白，可以从默认模板中移除，需要时再临时补充。调整后在团队内同步一次变更说明，保证不同记录人使用同一版本。
常见问题
会议没有形成决议，纪要里决议区怎么填？
在决议内容中写明“本次无决议”，并简要说明原因，例如议题需要补充数据后再议。讨论要点区保留分歧和待确认事项，结论倾向区记录下一步安排。这样处理后，读者能区分“讨论过但未定”和“遗漏未记”，后续复盘也有据可查。
行动项负责人是跨部门协作时，应该写谁？
写对结果负责的具体个人，并在备注中注明需要配合的部门或角色。例如“输出接口文档初稿”由后端负责人承担，备注写“需前端负责人提供字段清单”。负责人写个人，配合方写备注，行动项才有明确的责任落点，也方便会后按人跟进。
纪要发出后有人提出修改意见，怎么处理？
在确认截止时间前收集意见，由记录人统一修订并标注版本或修订说明，避免多人同时改出多个版本。涉及决议或行动项变更的，在纪要中保留变更记录，写清原内容和调整后内容。确认截止后仍未回复的，按默认确认处理并在下次会议开头说明。
行动项转入任务清单后，纪要还需要继续更新吗？
需要。纪要保留会议当时的记录，行动项状态以任务侧为准并回填到纪要，两处保持同一批行动项对应。回填频率可以按周，也可以跟随任务状态变化即时更新。这样纪要既能还原会议产出，也能反映当前进展，统计按期关闭情况时不必在两个系统间反复核对。
轻量周会也要用完整模板吗？
不必。周会版可以只保留基本信息、行动项和状态更新，讨论要点从简，决议依据和生效条件可省略。字段口径保持一致，只在必填范围和行数上取舍。会议类型变化时切换到对应变体，避免每次临时改表导致版本混乱。
