AI生成会议纪要需要提供哪些上下文

AI生成会议纪要时，需要提供四层上下文：会议基本信息、过程记录、业务背景和输出约束。这四层决定了AI能否把口语化讨论转成可追溯的决议与待办。本文按“提供什么—怎么按会议类型调整—按什么顺序操作—由谁负责—如何验收”的顺序展开，范围限于纪要文档的产出与定稿，不涉及需求判断、风险判断或工具选型。

要点总览（TL;DR）

• AI生成会议纪要需要四层上下文：会议基本信息、过程记录、业务背景、输出约束；四层齐备，口语化讨论才能转成可追溯的决议与待办。
• 过程记录最容易缺，也最关键：记录决议原话、待办线索和未决问题，并对疑似决议标注“决议”或“待定”，能明显减少AI误判。
• 不同会议类型投入不同：评审会加厚决议原话与责任人确认，站会加厚进度状态与阻塞项，讨论会备足背景材料，对外会议划清信息边界。
• 操作按会前预置、会中记录、会后生成核对、定稿确认归档四步走，每步都有输入、输出和完成标志，会前预置与定稿确认不宜跳过。
• 验收看五项：决议可追溯、待办要素齐全、术语与背景一致、敏感信息合规、未决项显式标注；会上未定的信息标注“待确认”，不由AI推测填入。

四层上下文清单：每层提供什么、缺了会怎样

把上下文分成四层，是为了让采集工作有明确边界：前两层来自这场会议本身，后两层来自会议之外的项目环境和交付要求。四层齐备，AI才能把“刚才说的那个事”还原成“谁在什么时间前完成什么”。缺哪一层，就在对应环节补采，或在纪要中标注待确认。

层级	内容项	典型来源	缺失后果与补采方式
会议基本信息	会议时间、议题清单、参会人及角色、会议类型（决策评审、同步、讨论等）	会议通知、议程、参会名单	AI难以判断发言归属和议题边界，容易把不同议题的结论混在一起；会前补齐议程和角色表
过程记录	发言要点、决议原话、待办线索（谁提出、指向什么）、未决问题	录音转录、现场速记、聊天记录	只能生成泛泛的讨论摘要，决议和待办无法追溯；会后回听录音补录关键原话
业务背景	项目阶段、专有术语与缩写、相关历史决议和文档	项目计划、术语表、历史纪要、需求文档	术语被误解、结论与既往决议冲突；由项目管理者补充背景材料或术语对照
输出约束	纪要模板、篇幅要求、分发对象、保密与脱敏要求	团队模板、分发名单、保密规定	格式返工，或敏感内容进入不该看到的范围；会前确认模板与分发范围

四层之中，过程记录最容易缺。现场速记往往只记结论不记原话，而AI判断“这是决议还是讨论中的想法”，依赖的正是原话中的语气和限定条件。一个实用做法是：记录人对每条疑似决议标注“决议”或“待定”，再交给AI整理，减少误判。

按会议类型调整上下文颗粒度

四层清单是通用框架，不同会议对每层的投入并不相同。决策类会议要把过程记录做厚，同步类会议要把进度状态做准，讨论类会议要把背景材料备足，对外会议则要把信息边界划清。

会议类型	需要加厚的上下文	可以简化的部分	纪要产出重点
决策评审会	决议原话、评审结论、责任人当场确认	讨论过程的完整复述	决议条目、责任人与时间、被否决方案及理由
日常站会与同步会	进度状态、阻塞项、跨组依赖	背景介绍和术语解释	状态变化、阻塞项及升级对象
需求与方案讨论会	背景材料、备选方案、待定项清单	逐字记录	方案对比要点、待定问题及澄清责任人
对外或跨部门会议	参会方立场、敏感信息边界、对外口径	内部术语和内部代号	共识点、分歧点、对外承诺事项

以站会为例，会上很少产生正式决议，此时把大量篇幅用于记录发言原话价值有限；更有效的做法是提供任务看板上的当前状态和阻塞标记，让AI据此整理状态变化。反过来，评审会如果只提供结论不提供讨论中的反对意见，纪要就看不出决策依据，后续复盘时难以解释为什么这样定。

操作步骤：从会前准备到纪要定稿

下面四步按时间顺序排列，每步都说明输入、动作、输出和完成标志。团队可以按实际会议时长压缩步骤，但不宜跳过会前预置和定稿确认两个环节。

会前：确定议题与模板，预置背景

• 输入：会议目的、议程草稿、项目背景材料、团队纪要模板。
• 动作：把议程拆成带编号的议题；整理术语表和历史相关决议；确认模板字段（议题、结论、待办、未决项、参会人）。
• 输出：一份会前上下文包，包含议程、参会角色表、术语表、模板。
• 完成标志：每个议题都有明确的讨论目标和预期产出（决策、信息同步或方案方向）。

会中：记录决议原话与待办线索

• 输入：会前上下文包、录音或转录工具、速记模板。
• 动作：按议题编号记录发言要点；对疑似决议标注原话和提出人；对待办记录“动作+对象+提出人”，时间未定的标注待确认。
• 输出：带议题编号和发言人标记的过程记录。
• 完成标志：每个议题下至少有一条结论或一条明确的“未决”。

会后：按模板生成初稿并逐条核对

• 输入：过程记录、会前上下文包、输出约束。
• 动作：把四层上下文一并交给AI，按模板生成初稿；逐条核对决议是否与原话一致、责任人是否明确、术语是否统一。
• 输出：纪要初稿，决议与待办分列，未决项单列。
• 完成标志：每条决议都能指回某段发言或某份材料，每条待办都有责任人或标注“待确认”。

定稿：责任人确认、分发与归档

• 输入：纪要初稿、待办责任人名单、分发范围。
• 动作：请待办责任人确认各自条目；按分发范围发送；把纪要和待办归档到对应项目空间或文档库。
• 输出：确认后的正式纪要和已登记的待办。
• 完成标志：所有待办责任人已确认，纪要已归档且可被后续会议检索引用。

归档这一步常被省略，但它决定下次会议能否复用历史决议。把纪要与对应项目、迭代或文档关联存放，后续讨论同一议题时可以直接引用上次结论，AI整理新纪要时也有可对照的背景。在ONES中，会议纪要可以保存为Wiki页面，待办可以转为工作项继续跟踪，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作，减少在多个页面之间切换和重复录入。

角色分工与交付物

上下文无人负责，是纪要质量不稳定的常见原因。把四层上下文分配到具体角色，并在会前就明确，可以避免会后互相等待。

角色	负责的上下文	交付物	时间点
会议组织者	会议基本信息、输出约束	议程、参会角色表、纪要模板、分发范围说明	会前
记录人	过程记录	带议题编号和发言人标记的速记或转录稿	会中至会后当天
参会人	待办确认、术语澄清	对本人待办的确认或修正意见	初稿发出后一个工作日内
项目管理者	业务背景、历史决议	项目阶段说明、术语表、相关历史纪要索引	会前提供，会后负责归档

小团队中一人可能兼任多个角色，此时仍建议在流程上分开确认：组织者确认模板和范围，记录人确认原话准确，责任人确认待办。角色合并可以，确认动作不宜合并，否则容易出现“自己写、自己审、自己确认”的闭环。

示例：一次评审会的上下文供给与纪要产出

以下为演示情景，用于说明四层上下文如何落到一份纪要，不代表真实项目。

会议背景与议题

某项目进入版本发布前的方案评审阶段，召开一次评审会，议题为“登录模块改版方案是否进入开发”。参会人包括产品负责人、技术负责人、测试负责人和项目经理。

四层上下文的填写内容

• 会议基本信息：周三下午评审会，议题编号1，参会角色为产品（主持）、技术、测试、项目管理者（记录）。
• 过程记录：技术负责人提出“方案A的改造成本约两周，方案B可以复用现有组件”；产品负责人表示“本期优先保证上线时间，采用方案B”；测试负责人提出“方案B的兼容性用例需要补充”，会上未指定负责人。
• 业务背景：项目处于发布前两周，登录模块属于本期必交付范围；历史决议中曾确定“本期不引入新的第三方登录方式”。
• 输出约束：使用团队评审纪要模板，篇幅一页以内，分发给项目组和部门负责人，客户名称需脱敏。

生成的纪要素材

• 决议：本期登录模块改版采用方案B，复用现有组件，以保障上线时间。
• 待办：补充方案B兼容性用例，责任人待确认，建议完成时间为开发启动前。
• 未决项：兼容性用例的负责人和完成时间未在会上确定。

待确认项的处理方式

示例中“兼容性用例负责人”属于会上未定的信息。处理方式是在纪要中显式标注“待确认”，并在分发时点名请测试负责人补充，而不是由AI推测一个责任人填入。这样纪要既完整反映会议实际，也为后续补录留下明确入口。

完成检查：纪要可用性的核对项

纪要发出前，按下表逐项核对。每项都有可观察的通过标准，避免用“内容完整”“表述清晰”这类无法验证的判断。

核对项	通过标准
决议可追溯	每条决议都能指回具体发言人或某份评审材料，无凭空归纳的结论
待办要素齐全	每条待办包含动作、责任人、时间、验收口径；缺失项标注“待确认”
术语与背景一致	术语用法与术语表一致，结论与历史决议无未说明的冲突
敏感信息合规	客户名称、内部代号等已按分发范围脱敏，分发名单与保密要求一致
未决项显式标注	会上未形成结论的问题单独列出，写明待澄清内容和澄清责任人

五项全部通过，纪要即可分发。若“待办要素齐全”一项存在多处待确认，建议先完成责任人确认再分发，避免待办在流转中被遗漏。分发后把纪要与待办归档到对应项目空间，下一次会议的准备就可以直接引用这份记录作为业务背景。

常见问题

会议录音转写稿很长，直接交给AI整理可以吗？

可以，但建议先做一轮轻量标注再交给AI。转写稿里讨论、假设、玩笑和正式决议混在一起，AI难以稳定区分。记录人可以在转写稿上标出疑似决议的原话、待办线索和未决问题，再连同会议基本信息、业务背景、输出约束一起提供。这样AI整理时依据的是标注过的材料，初稿的决议条目更接近会议实际，核对工作量也随之下降。

会上没有形成明确决议，纪要该怎么写？

把未决项单独列出，写明待澄清的问题、当前讨论到的程度和下一步由谁推进。不要为了让纪要看起来完整而替会议补一个结论。未决项本身是有价值的信息，它告诉后续参与者哪些问题还开着。分发时可以点名请相关角色补充，并在下一次会议准备时把这条未决项作为背景材料带入。

待办的责任人当场没有确定，纪要里怎么处理？

在待办条目中保留动作和对象，责任人一栏写“待确认”，并在分发时点名请对应角色补充。责任人确认后再更新纪要并归档。让AI根据发言内容推测一个责任人填入，短期看纪要完整，长期会让待办落到错误的人身上，反而增加澄清成本。

涉及客户名称或内部敏感信息的会议，上下文提供要注意什么？

会前就确认分发范围和脱敏要求，并把这部分作为输出约束明确告诉AI，例如哪些名称需要替换、纪要发给哪些人。过程记录中的敏感内容在交给AI之前先做替换处理，比生成后再逐处删改更稳妥。分发前再核对一遍分发名单与保密要求是否一致。

纪要生成后，怎样让下一次会议能直接复用？

关键是归档时建立关联：把纪要与对应项目、迭代或文档放在一起，待办登记为可跟踪的条目。这样下次讨论同一议题时，可以直接引用上次的结论和未决项，作为业务背景提供给AI。在ONES中，会议纪要可以保存为Wiki页面，待办可以转为工作项继续跟踪，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作，减少在多个页面之间切换和重复录入。