400-188-1518AI会议纪要输出模板：结构要素与填写规范
AI会议纪要输出模板应包含四类结构要素：会议基本信息、议题与讨论要点、结论与决策、行动项。要让纪要既能还原讨论过程、又能直接用于后续跟踪，关键是把结论、决策和行动项拆成独立表格，行动项逐条落到唯一责任人和可核对的截止时间，并保留来源议题编号与状态字段。下面提供一套可直接复制填写的空白表格、字段填写口径、必填规则和一份完整示例。
Table of Contents
要点总览（TL;DR）
- AI会议纪要模板按四张表组织：会议基本信息、议题与讨论要点、结论与决策、行动项跟踪，表间用议题编号关联。
- 便于跟踪的关键是行动项逐条落到唯一责任人、具体截止时间和可核对的验收标准，并保留来源议题编号与状态字段。
- 必填字段以“缺失后无法理解或无法跟踪”为标准：会议名称、时间、参会人、记录人、会议目标，结论内容与决策人，以及行动项的待办、责任人、截止时间、验收标准、状态。
- 决策类会议保留全部四张表；同步类会议可只保留会议信息、议题要点和行动项，结论表记录已确认事项。
- AI生成的纪要属于草稿，定稿前需核对结论、决策与责任人，重点区分讨论观点和已确认结论。
可复制空白模板：AI会议纪要标准表格
以下四张表构成一份完整纪要。使用时按会议实际情况填写，表格之间的关联靠“议题编号”完成：讨论要点、结论决策、行动项都引用同一个议题编号，便于回溯某条待办是在哪个议题下产生的。
表一：会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议名称 | |
| 会议时间 | |
| 会议地点 / 形式 | |
| 主持人 | |
| 记录人 | |
| 参会人 | |
| 缺席人及原因 | |
| 会议目标 | |
| 会议类型 |
表二：议题与讨论要点
| 议题编号 | 议题名称 | 关键观点 | 提出人 | 分歧点 | 是否形成结论 |
|---|---|---|---|---|---|
表三：结论与决策
| 关联议题编号 | 结论 / 决策内容 | 决策依据 | 决策人 | 待定事项 | 待定原因与下次确认时间 |
|---|---|---|---|---|---|
表四：行动项跟踪
| 行动项编号 | 关联议题编号 | 待办内容 | 责任人 | 截止时间 | 验收标准 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|
| 待开始 | |||||||
| 待开始 | |||||||
| 待开始 |
字段说明：每个结构要素回答什么问题
四张表分别回答不同问题：会议信息回答“这场会是什么会”，议题讨论回答“讨论了什么、分歧在哪”，结论决策回答“定了什么、依据是什么”，行动项回答“谁在什么时间前交付什么”。字段设计围绕这四个问题展开，避免把讨论过程、结论和待办混在同一段文字里。
| 结构要素 | 字段 | 回答的问题 | 填写口径 |
|---|---|---|---|
| 会议基本信息 | 会议名称 | 这场会讨论什么主题 | 写清对象与阶段，如“订单模块 V2.3 迭代评审会” |
| 会议基本信息 | 会议时间 | 讨论发生在何时 | 精确到日期与起止时间 |
| 会议基本信息 | 参会人 | 谁参与了讨论、谁有决策权 | 列出姓名与角色，决策人单独标注 |
| 会议基本信息 | 会议目标 | 本次会要达成什么 | 用一句话写可判断是否达成的目标 |
| 议题与讨论要点 | 议题编号 | 这条内容属于哪个议题 | 按 T1、T2 顺序编号，全篇唯一 |
| 议题与讨论要点 | 关键观点 | 各方提出了什么 | 每条观点注明提出人，保留原意 |
| 议题与讨论要点 | 分歧点 | 哪里没有达成一致 | 写清分歧双方立场，未解决时如实记录 |
| 结论与决策 | 结论 / 决策内容 | 最终定了什么 | 写可执行的结论，避免“继续讨论”式表述 |
| 结论与决策 | 决策依据 | 为什么这样定 | 记录数据、约束或评审意见来源 |
| 结论与决策 | 待定事项 | 哪些还没定 | 注明待定原因与下次确认时间 |
| 行动项 | 待办内容 | 要做什么 | 以动词开头，写清交付物 |
| 行动项 | 责任人 | 谁负责 | 只写一个主责人，协作人放备注 |
| 行动项 | 截止时间 | 何时完成 | 写具体日期，避免“尽快”“下周” |
| 行动项 | 验收标准 | 做到什么程度算完成 | 写可核对的结果，如“提交评审通过的测试报告” |
| 行动项 | 状态 | 当前进展如何 | 按待开始、进行中、已完成、已取消流转 |
行动项与议题的关联方式统一用议题编号：每条行动项必须填写关联议题编号，这样在复盘时可以顺着编号找到当时的讨论和决策依据，也便于判断某条待办是否偏离了原议题范围。
必填与选填：哪些字段不能空缺
必填字段的判断标准是：缺失后会导致纪要无法被他人理解或无法跟踪。会议信息中的会议名称、时间、参会人、记录人，结论决策中的结论内容和决策人，行动项中的待办内容、责任人、截止时间、验收标准，都属于这一类。其余字段可按会议类型裁剪。
| 结构要素 | 必填字段 | 选填字段 | 可空缺情形 |
|---|---|---|---|
| 会议基本信息 | 会议名称、会议时间、参会人、记录人、会议目标 | 会议地点 / 形式、缺席人及原因、会议类型 | 线上临时同步会可不填地点；无缺席人员时缺席栏留空 |
| 议题与讨论要点 | 议题编号、议题名称、关键观点 | 提出人、分歧点、是否形成结论 | 纯信息同步议题可省略分歧点；观点来源明确时可省略提出人 |
| 结论与决策 | 关联议题编号、结论 / 决策内容、决策人 | 决策依据、待定事项、待定原因 | 无待定事项时对应栏留空并标注“无” |
| 行动项 | 待办内容、责任人、截止时间、验收标准、状态 | 行动项编号、关联议题编号、备注 | 行动项编号可按需启用；备注在无补充信息时留空 |
空缺处理遵循三条规则：必填字段确实无法当场确定时，填写“待确认”并指定确认人和确认时间，不能直接留白；选填字段留空表示“不适用”，与“尚未填写”区分开；行动项的责任人或截止时间缺失时，该行动项视为未成立，需在会后 24 小时内补齐后再纳入跟踪。同步类会议可以只保留议题要点和行动项两张表，决策类会议则必须完整填写结论与决策表。
填写示例：一次迭代评审会的完整纪要
以下示例为演示情景，展示四张表如何对应填写。示例中的项目、人员和时间均为虚构，用于说明填写方式。
会议基本信息示例
| 字段 | 填写内容 |
|---|---|
| 会议名称 | 订单模块 V2.3 迭代评审会 |
| 会议时间 | 2025-03-11 14:00–15:30 |
| 会议地点 / 形式 | 线上会议 |
| 主持人 | 李敏（产品负责人） |
| 记录人 | 王哲（产品经理） |
| 参会人 | 李敏、王哲、陈涛（开发负责人）、赵倩（测试负责人）、周航（运营） |
| 缺席人及原因 | 无 |
| 会议目标 | 确认 V2.3 迭代范围与上线时间，明确遗留问题处理方案 |
| 会议类型 | 迭代评审会 |
议题与讨论要点示例
| 议题编号 | 议题名称 | 关键观点 | 提出人 | 分歧点 | 是否形成结论 |
|---|---|---|---|---|---|
| T1 | V2.3 迭代范围 | 本期聚焦订单批量导出与异常订单提醒两项功能 | 李敏 | 运营希望增加对账报表，开发评估工期不足 | 是 |
| T2 | 上线时间 | 开发评估需 3 周，测试需 1 周 | 陈涛 | 运营要求提前一周上线配合活动 | 是 |
| T3 | 遗留缺陷处理 | 当前有 2 个中优先级缺陷未关闭 | 赵倩 | 无 | 是 |
结论与决策示例
| 关联议题编号 | 结论 / 决策内容 | 决策依据 | 决策人 | 待定事项 | 待定原因与下次确认时间 |
|---|---|---|---|---|---|
| T1 | V2.3 只做批量导出与异常提醒，对账报表放入 V2.4 | 开发工期评估与本期目标优先级 | 李敏 | 对账报表的排期 | 需结合 V2.4 需求池评审，3 月 18 日确认 |
| T2 | 上线时间定为 4 月 8 日，不提前 | 开发 3 周加测试 1 周的排期评估 | 李敏 | 无 | 无 |
| T3 | 2 个中优先级缺陷在提测前关闭 | 测试准入标准 | 陈涛 | 无 | 无 |
行动项示例
| 行动项编号 | 关联议题编号 | 待办内容 | 责任人 | 截止时间 | 验收标准 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|
| A1 | T1 | 更新 V2.3 需求范围说明并同步运营 | 王哲 | 2025-03-13 | 范围说明文档更新完成并经李敏确认 | 进行中 | 运营周航参与确认 |
| A2 | T2 | 输出 V2.3 排期计划 | 陈涛 | 2025-03-14 | 排期计划包含开发、测试、上线节点 | 待开始 | |
| A3 | T3 | 关闭 2 个中优先级缺陷 | 陈涛 | 2025-03-21 | 缺陷状态为已关闭且回归通过 | 待开始 | 赵倩负责回归验证 |
| A4 | T1 | 整理对账报表需求并提交 V2.4 评审 | 周航 | 2025-03-18 | 需求说明提交至需求池并进入评审 | 待开始 |
调整与维护方法：让纪要模板持续可跟踪
模板的价值在于长期使用后仍能支撑跟踪。团队规模、会议类型和跟踪节奏不同，字段需要相应裁剪，同时要建立模板版本记录和 AI 生成内容的核对机制。
按会议类型裁剪字段
- 决策类会议（评审会、立项会）：保留全部四张表，结论与决策表必须完整填写决策人和依据。
- 同步类会议（站会、周会）：保留会议基本信息、议题要点和行动项，结论表可只记录已确认事项。
- 专题讨论会：议题表可增加“待澄清问题”列，结论表重点填写待定事项和下次确认时间。
- 小团队可合并主持人与记录人字段；跨部门会议建议保留缺席人及原因，便于判断决策有效性。
行动项状态流转与复盘节奏
行动项状态按“待开始—进行中—已完成—已取消”流转，取消时需在备注写明原因和批准人。复盘节奏建议与会议周期对齐：周会产生的行动项在下次周会前核对状态，迭代评审会的行动项在迭代结束前统一检查。逾期行动项在复盘中单独列出，由责任人说明进展或调整截止时间，调整记录保留在原行备注中，不直接覆盖原截止时间。
模板版本与字段变更记录
模板本身也需要版本管理。建议在模板文件头部记录版本号、修订日期和修订人，字段增删或口径变化时写清变更原因。例如新增“验收标准”字段时，注明是为了解决行动项完成标准不一致的问题。历史纪要保留原版本字段结构，避免新旧模板混用导致跟踪口径不一致。
AI 生成内容的核对与修订要求
AI 生成的纪要属于草稿，定稿前需由记录人或主持人逐项核对：结论和决策是否与会上确认一致，责任人是否唯一且本人知悉，截止时间是否为会上明确的时间，待定事项是否标注了确认时间。模型可能把讨论中的提议写成已确认决策，核对时重点区分“讨论观点”和“已确认结论”，发现偏差直接修订并在备注中说明。定稿后的纪要再进入跟踪环节。
当行动项需要进入项目管理系统持续跟踪时，可以把纪要中的行动项转为工作项，保留责任人、截止时间和状态字段，并在工作项中回链纪要页面。ONES 的智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，并将结果保存为工作项或 Wiki 页面，减少从纪要誊抄到跟踪系统的重复录入；具体字段映射方式需按团队实际配置确定。这样纪要负责还原讨论与决策，工作项负责推进执行，两者通过议题编号和行动项编号保持对应。
常见问题
会议纪要里的“讨论要点”和“结论决策”为什么要分成两张表？
两者回答的问题不同：讨论要点记录各方提出了什么、分歧在哪里，结论决策记录最终定了什么、依据是什么。分开后，复盘时能看清某个结论是在哪些观点和分歧基础上形成的，也能避免把讨论中的提议误读为已确认决策。如果会上某议题未形成结论，讨论表照常记录，结论表标注待定事项和下次确认时间即可。
行动项的责任人写了两个人，是否可行？
建议每条行动项只写一个主责人，协作人放在备注栏。两个责任人的写法在跟踪时容易出现互相等待、无人推进的情况。如果一项工作确实需要多人分工，拆成多条行动项，各自对应唯一责任人和截止时间，并分别关联来源议题编号。
会上没来得及确定截止时间，纪要该怎么写？
行动项的责任人或截止时间缺失时，该行动项视为未成立，需在会后24小时内补齐后再纳入跟踪。纪要中可以填写“待确认”，同时指定确认人和确认时间，不要直接留白。补齐后更新原行，并在备注中记录补充时间，便于复盘时区分会上确定和会后补充的信息。
AI生成的会议纪要可以直接发出去吗？
建议把AI输出当作草稿。定稿前由记录人或主持人逐项核对：结论和决策是否与会上确认一致，责任人是否唯一且本人知悉，截止时间是否为会上明确的时间，待定事项是否标注确认时间。模型可能把讨论中的提议写成已确认决策，核对时重点区分讨论观点和已确认结论，发现偏差直接修订并在备注中说明。
纪要中的行动项如何进入项目管理系统持续跟踪？
可以把行动项转为工作项，保留责任人、截止时间和状态字段，并在工作项中回链纪要页面，让纪要负责还原讨论与决策、工作项负责推进执行。ONES 的智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，并将结果保存为工作项或 Wiki 页面，减少从纪要誊抄到跟踪系统的重复录入；具体字段映射方式需按团队实际配置确定。
