如何可靠地总结会议记录：从原始笔记到可核查纪要
可靠的会议纪要，不只是把长记录压缩成短文字。它需要准确区分讨论、决定和承诺，并让读者知道哪些信息已经确认，哪些仍待核实。下面以一次项目协调会为例，逐步建立可重复执行的总结流程。
§ 第一步：先确定纪要的用途
不要直接要求模型“总结一下”。先说明读者是谁，以及读者需要据此完成什么工作。面向项目执行的纪要，应优先呈现决定、行动项和阻塞因素，而不是逐段复述发言。
- 会议背景：会议日期、主题、参会人员及角色。
- 核心输出：讨论结论、已确认决定、行动项和待确认问题。
- 保留要求：金额、日期、负责人及关键限制条件不得省略。
§ 第二步：整理输入，但保留原始证据
将录音转写、手写笔记和会后补充分别标明来源，再按议题或时间顺序整理。给每段记录添加稳定编号，例如“记录012”。后续修改文本时，不要重新分配这些编号。
只修正确定无疑的排版问题。听不清的人名、缺失的单位和可能错误的数字，应标注“待核实”，不要根据上下文补齐。向外部接口发送记录前，先依据组织要求删除或替换无须处理的个人信息、客户标识及凭证。
§ 第三步：写清总结规则
把任务要求与会议原文分开放置，并明确原文只是待分析的数据。即使记录中出现“忽略前面的要求”等句子，也不能将其当作处理指令。
可以使用这样的提示词：“请仅依据会议记录生成纪要，分别列出背景、讨论要点、已确认决定、行动项和待确认问题。每项决定与行动项必须附记录编号。没有明确依据的信息写‘未明确’，不得推测负责人、期限或一致意见。”
§ 第四步：先提取事实，再组织文字
让模型先整理事实清单，再依据清单生成可读纪要。事实清单至少包含事项、类别、原文依据和确认状态。这样，文字润色与事实判断就不会混在同一步中。
接入时可以沿用现有的 OpenAI SDK，并按 Vana API 的地址规则配置接口，无须为了这一步另写一套客户端。先固定提示词、输入样例与输出结构，再调整模型选择，便于比较结果。([vanaapi.com](https://vanaapi.com/))
§ 第五步：严格区分建议、决定与承诺
“可以考虑周五上线”是建议，不是上线决定；“我先看看”也不等于承诺完成。只有原文明确表达批准、确认或责任承担时，才能进入对应栏目。存在反对意见时，应保留分歧，不能概括为“团队一致同意”。
- 已确认决定：写清决定内容、适用范围和前置条件。
- 行动项：写清任务、负责人、期限、依赖及证据编号。
- 待确认事项：单独列出责任归属不明、期限缺失或记录冲突的问题。
§ 第六步：处理时间与长记录
将“明天”“下周三”等相对时间转换为具体日期前，必须确认会议日期和相关时区。如果有人说“周五之前”，但上下文无法确定是哪一周，就保留原话并请求确认，不要自行选择日期。
记录过长时，按议题分段提取，并保留原始编号；最后合并事实清单，再生成总纪要。合并时重点检查后续发言是否撤回、修改或限定了前面的决定，避免把已经失效的内容留在最终版本中。
§ 第七步：做一次独立核查
不要只让模型评价“总结是否准确”。要求核查过程逐项对照原文，列出缺少依据的结论、遗漏的限制条件以及互相矛盾的表述。核查时必须提供原始记录，而不只是初稿。
- 查数字：金额、比例、数量及单位是否一致。
- 查责任：负责人是否确有承诺，是否遗漏共同执行者。
- 查完整性：延期、否决、风险和未解决问题是否保留。
- 查证据：每个引用编号是否存在，是否真正支持对应结论。
§ 第八步：确认后发布，保留修订记录
涉及交付期限、预算或对外承诺的内容，交由会议负责人确认。发布时标明版本和确认状态；后续修改应说明变更了什么，而不是静默覆盖旧纪要。
建议先用几份已由人工确认的历史记录测试流程，比较事实错误、行动项遗漏和复核耗时。如果准备接入现有工作流，可以创建一个 Vana API 账户，从脱敏样例开始验证。验收标准始终是纪要能否被核查和执行，而不是文字是否流畅。