会前准备最费心的部分，往往是把散落的信息接起来：邀请里写着“讨论续约”，历史笔记记录过交付问题，客户记录中还有一条尚未确认的需求。AI 可以帮助整理这些材料，但简报是否有用，取决于参会者能否看清：本次要讨论什么，哪些结论已有依据，哪些问题仍需要确认。
因此，会前简报的设计重点应当是可核对。每个关键判断都能找到来源，每条信息都有时间背景，冲突和缺失被明确展示，参会者才能据此准备问题、补齐材料，并判断哪些内容可以带入会议。
一、从“发送提醒”到“整理讨论上下文”
Kuse 的《AI 工作流程 vs 传统自动化：真正重要的关键差异》给出了具体的会议准备示例：传统自动化可以发送日历提醒，AI 工作流程则可以读取邀请内容、先前笔记、账户历史与文件，并在会议前建立准备简报。这说明，会前准备涉及的不只是触发通知，还包括阅读、比较和组织上下文。
该资料也指出，简单、可预测、每次需要相同结果的任务适合规则式自动化；阅读、摘要、比较和写作等输入经常变化的任务，更适合 AI 工作流程。落实到开发中，可以让固定规则负责会议筛选、时间触发和数据获取，让 AI 负责将材料整理为议题、历史结论和待确认事项。
例如，系统可以在会议开始前的指定时间启动任务，读取最新邀请、关联客户记录、检索相关笔记，然后生成简报。这里的触发时间属于产品配置建议，资料没有给出统一的最佳时间，也不能据此声称某种配置已经获得效率提升。
二、先确定本次会议，再扩展关联材料
跨系统聚合的第一步，是明确会议对应的客户、项目和讨论范围。邀请可以作为入口，但不应单凭标题中的几个词就认定所有同名记录都相关。
建议从邀请中提取会议时间、参会者、议题描述、附件和已有链接，再尝试关联客户或项目的稳定标识。若只能通过名称匹配，应保留“关联待确认”的状态。例如，两条记录都含有同一个公司简称，并不足以证明它们属于同一次客户讨论。
三类输入可以承担不同职责：
| 输入来源 | 主要用途 | 需要保留的信息 |
|---|---|---|
| 会议邀请 | 确定本次讨论范围与参会安排 | 会议标识、时间、议题、更新时间、原始链接 |
| 历史笔记 | 提取过去的讨论、决策和未完成事项 | 会议日期、记录作者、结论原文或片段、文档位置 |
| 客户记录 | 补充客户状态、需求和跟进背景 | 客户标识、字段含义、记录时间、更新者、记录链接 |
邀请中的“计划讨论”不能直接归入“已有结论”；历史笔记中的“建议采用”也不能自动改写成“已决定采用”。整理时需要保留这些语义差异，否则简报虽然顺畅，却可能改变原始材料的意思。
三、连接器、知识图谱和文档搜索分别解决什么问题
AWS 的《AI 办公是什么？智能协作与自动化办公 - Amazon Quick - AWS》介绍，AI 办公助手可以通过标准化连接器，即 API 集成，对接邮件、即时通讯、日历、项目管理和文档系统。该资料还介绍了从文档、邮件和消息中提取人物、项目、决策及其关系，构建工作知识图谱的方式。
这两项能力在会前准备中有不同作用：连接器提供获取信息的通道，实体与关系帮助判断信息属于哪个客户、项目或讨论。开发者仍需设计关联规则和证据保留方式，接入多个系统本身并不能保证生成内容正确。
同一篇 AWS 资料指出，文档智能搜索可以索引用户有权访问的文档库，支持语义搜索，而非仅依赖关键词匹配。这适合处理表述变化：邀请写“续约条件”，历史笔记可能写“下一年度服务范围”，相关信息未必使用相同关键词。
实现时可以先用客户标识、项目标识和时间范围缩小候选集合，再在集合内进行语义检索。检索结果应保留原始片段及文档位置，供后续生成引用和人工核对。这里需要区分两件事：检索找到了相关材料，代表它值得阅读；材料是否足以支持某个结论，还要继续判断。
四、把简报固定为三类信息
一份便于核对的简报，可以围绕“本次议题、已有结论、待确认事项”组织。
“本次议题”主要依据最新邀请及明确关联的材料，说明会议准备解决什么问题。AI 可以对冗长描述进行归纳，但新增的讨论建议应单独标注，避免被误认为邀请方已经确定的议程。
“已有结论”应包含明确的决定、确认结果或状态记录，同时保留适用条件。比如，原始笔记中的结论只适用于某一期交付，摘要就应保留这一范围，避免扩展成整个客户项目的长期承诺。
“待确认事项”则容纳未完成动作、来源冲突、缺少依据和可能已经过时的信息。它应尽量转化为会上可以回答的问题，而不是停留在“信息不完整”这样的泛泛描述。
下面是一个用于说明格式的假设示例，不代表真实客户记录或实际运行结果：
本次议题：确认下一阶段交付范围。依据：会议邀请，邀请更新时间为 T1。
已有结论：上一轮会议记录了第一阶段的交付范围。依据：历史笔记，会议日期为 T0，附原文位置。
待确认事项：客户记录中出现了新增需求，但未找到对应的范围确认记录。建议会上确认该需求是否纳入下一阶段，并确定后续记录负责人。
这样的输出同时提供信息和核对入口，参会者可以沿着链接判断摘要是否准确。
五、来源和时间应成为结构化字段
如果引用只放在文末，读者仍然需要猜测某句话来自哪份材料。更实用的做法是为每条关键陈述绑定来源，并在生成前保存结构化证据。
可以采用如下字段设计：
| 字段 | 用途 |
|---|---|
claim | 简报中的具体陈述 |
category | 本次议题、已有结论或待确认事项 |
source_id、source_url | 定位原始记录 |
source_location | 定位段落、消息或具体字段 |
evidence_text | 保存支持该陈述的原始片段 |
event_time | 事情发生或会议举行的时间 |
updated_at | 来源记录最后修改的时间 |
retrieved_at | 本次获取资料的时间 |
status | 标记明确记录、存在冲突或缺少确认等状态 |
三个时间字段尤其需要分开。文档昨天被修改，不意味着文档中的决定是昨天作出的；今天检索到的客户状态，也可能是在更早时间录入的。简报中应优先展示与判断有关的时间，未知时明确标为“时间未记录”。
对于“已确认”“已完成”“已批准”等确定性表述，可以在生成后增加校验：是否存在支持片段，片段是否确实表达了该状态，来源时间和适用范围是否被保留。校验无法替代人工判断，但能让缺少依据的强结论更容易暴露出来。
六、显式呈现冲突，让参会者做决定
当历史笔记与客户记录不一致时，AI 不应为了让文字流畅而自行选定答案。可以将冲突集中展示为“事项—来源差异—待确认问题”。
例如，假设笔记写着“需求仍待评估”，客户记录却显示“需求已确认”。简报应分别列出两条记录的时间和来源，并提示：“两处状态不一致，请确认是否存在后续批准记录。”
处理冲突时，可以采用以下原则：
- 有明确后续决定时，引用该决定，并说明它更新了哪条旧结论。
- 只有更新时间差异时，保留冲突，不把“更新较晚”直接等同于“内容正确”。
- 不同来源描述不同范围时，先拆开范围，避免把它们误判为同一事项。
- 缺少关键材料时，说明检索范围和缺失内容，生成具体的确认问题。
“未找到批准记录”描述的是本次检索结果，不能据此断言“从未批准”。这种措辞差异直接影响参会者对事实的理解。
七、应用范围、验证方式与局限
这类流程适合需要反复阅读和关联材料的会议准备，例如客户跟进、项目评审、跨团队协调。对于只有固定议程和少量结构化字段的例行会议，模板填充与规则自动化可能已经足够，无需增加复杂的信息推理。
开发者可以先选取材料较完整、关联关系清晰的一类会议，建立输出模板，再检查三个方面：关键陈述能否回到原始记录，时间和范围是否准确，冲突与缺失是否被保留下来。评价重点应落在内容质量和可核对性上；没有实际测量时，不应宣称节省了多少时间或提高了多少准确率。
实际使用也有边界。文档缺失、客户名称歧义、记录长期未更新，都可能导致聚合结果不完整。权限同样需要贯穿数据读取和简报分享：生成者能够读取的材料，未必适合向所有参会者展示。若简报需要多人共享，应根据接收者的权限检查引用和摘要内容。
Kuse 的会议准备示例提供了清晰的应用方向，AWS 对连接器、知识图谱和文档搜索的介绍提供了组织跨系统信息的技术思路。落实到产品时，可以先做出一份范围受控、逐条带来源和时间的简报，再逐步扩大数据来源。这样，参会者面对每个关键结论时，都有明确的位置可以查看依据，也有明确的问题可以带到会上确认。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。
- AI 工作流程 vs 傳統自動化：真正重要的關鍵差異 | Kuse Blog
- AI 办公是什么？智能协作与自动化办公 - Amazon Quick - AWS
