会议结束十分钟，纪要初稿已经躺在文档里。句子顺，结构清楚，待办事项也分了组。用大语言模型做这件事，门槛低到让人放松：录音转写、提示词、模板拼在一起，似乎就完成了从讨论到执行的交接。
但真正要检查的，往往不是“写得像不像”，而是它有没有替参会者做了不该做的判断。
压缩会丢掉什么
纪要的第一层工作是压缩。两小时讨论变成一页纸，必然有取舍。模型擅长合并重复表达，把口语整理成书面语，也能识别常见议题词。然而，压缩不只靠频率。某个人反复强调的一句“先别定”，可能在文本里只出现一次；某个被搁置的分歧，可能没有明确结论，却决定了后续动作的边界。纪要如果只留下“达成共识”，就把未决问题抹平了。
我会把这类风险称为“过度收束”：文本看起来完整，责任却变模糊。检查时不妨反过来问：哪些话被合并了？哪些异议没有进入正文？原讨论里有没有“暂缓”“待确认”的信号？这些信号不一定多，却是纪要的价值所在。
语境不是装饰
大语言模型在生成时依赖上下文。上下文给得足，它能把简称展开，把指代理清；给得不足，它也会用常见句式补出一个看似合理的说法。问题在于，会议里的很多含义并不在字面里。比如“按上次方案推进”，究竟指哪一版方案，需要团队内部知识；“这个风险可控”，背后可能有一组尚未写进文档的验证动作。
所以，模型可以帮忙整理，但不能替代语境确认。一个实用的做法是让它先输出“待确认清单”，而不是直接给终稿。清单列出指代不明、时间缺失、责任人不清楚的地方，再由人逐条回填。模型承担的是发现空缺，而不是假装没有空缺。
事实边界要留在人手里
会议纪要里常有数字、日期、名称和承诺。模型可能会把“周三”写成“周五”，把“初步”改成“确定”，也可能把假设性讨论写成已决定事项。它未必故意误导，而是在语言概率上选择更顺的表达。对读者来说，顺滑的句子反而降低了警觉。
因此，核查动作要具体，不能只写一句“人工复核”。可以拆成几类：
- 时间与数量：日期、周期、数量、版本号是否与原始记录一致。
- 动作与责任：谁做什么、做到什么程度、何时反馈，是否明确。
- 确定性：哪些是决定，哪些是建议，哪些仍待确认。
- 引用与名称：项目名、产品名、部门名是否准确，简称是否统一。
这些检查并不复杂，却很难完全交给生成环节。模型可以按清单标出可疑处，但最终确认仍需要了解讨论背景的人来完成。
把工具放回流程里
我更愿意把大语言模型看作初稿助手，而不是会议记录者。它的价值在于缩短整理时间，让人把精力放到判断上；它的边界也在这里：它不知道讨论里谁在保留意见，不知道某个词的内部含义，也不承担承诺兑现的后果。
如果团队要用它写纪要，流程上可以留出三个动作：保留原始转写，生成结构化初稿，再做一次针对“未决事项”的复核。原始转写不是为了逐字对照，而是为了在争议出现时有回看依据；初稿不必追求漂亮，关键是让议题、结论和待办各自归位；复核优先看会影响后续动作的句子。
会议纪要的终点不是一份读起来顺畅的文档，而是团队对下一步的共同理解。大语言模型能把语言整理得更快，但理解是否成立，仍要靠人补上那些没有被说透的部分。检查纪要时，我们检查的其实是：哪些判断被写进去了，哪些判断被悄悄省略了。