一场项目复盘会结束，录音文件躺在共享盘里。过去，写纪要的人要重听、摘取、归类；现在，把转写文本交给大语言模型，几十秒就能得到一份结构清楚的草稿。省下来的时间很直观，但新的问题也随之出现：当模型把一段含糊的讨论整理成“已达成共识”，谁来判断这句话是否越过了事实边界？
会议纪要看似简单，实际包含三层工作：听清说了什么，判断哪些重要，以及用组织内部能理解的方式写下来。大语言模型擅长第一层和第二层的部分环节，它能压缩长文本、识别话题、把口语改成书面表达。但“重要”的标准往往不在文本里，而在项目背景、人员分工和未说出口的约束中。模型看不到会议前的私下沟通，也分不清一句反问和一项决定。
流畅不等于准确
使用大语言模型时，最容易被误读的是“流畅”。一段文字通顺、结构完整，会让人默认它可靠。可会议纪要的风险恰恰藏在细节：谁提出异议、哪项任务尚未确认、哪个时间点只是暂定。模型可能把这些模糊信息写成确定句，或者为了段落平衡补上并不存在的过渡。对写作者来说，这类补全很自然；对阅读者来说，却可能变成错误依据。
所以，比较稳妥的做法不是让模型直接产出终稿，而是把任务拆开：先转写，再让模型做带时间戳的摘要，最后人工核对关键句。涉及任务分配、时间节点和对外表述时，保留原文链接比追求漂亮排版更重要。企业如果要把这套流程固定下来，也需要明确谁负责复核，而不是把“模型生成”当成责任转移。
提示词之外，还有工作流
很多人讨论大语言模型，会把注意力放在提示词上。提示词当然重要，但会议纪要的质量更依赖输入和流程。录音是否清晰、发言者是否区分、术语表是否提前给出，都会影响结果。与其反复修改一句指令，不如先确认转写文本的说话人标签是否准确，再把内部缩写和项目名整理成简短说明。模型不需要知道全部背景，但需要知道哪些词不能被改写。
另一个常被忽略的环节是输出格式。纪要给谁看，决定了它该多长、该保留多少细节。给执行团队看，任务、负责人和截止时间要清楚；给管理层看，争议点和待决策项更关键。让模型一次生成“通用纪要”，往往得到一份看似完整却不够用的文本。更实际的方式是准备两个模板，分别约束信息密度和语气，再由人做取舍。
- 先确认转写质量，再谈摘要效果；说话人混淆会直接污染后续判断。
- 要求模型保留不确定表述，例如“暂定”“待确认”，不要自行改成肯定句。
- 把复核放在发布前，而不是等读者发现错误后再补救。
这些做法并不复杂，却比追逐新工具更接近日常工作的真实需求。大语言模型可以承担大量重复性整理，让写纪要的人把精力放回判断上。它更像一个反应很快的初稿作者，而不是会议现场的参与者。清楚这一点，使用时就不会把省事误当成省心。