自动摘要最危险的地方，不是偶尔漏掉一句话，而是把“讨论过”加工成“已经确认”，把“可以考虑”改写成“必须交付”。一旦这类内容进入报价单、项目计划或客户邮件，转写误差就会变成范围争议。因此，自动摘要只能作为记录初稿，不能直接作为交付依据。

先区分信息的确定性

会议纪要至少应把内容分成四类：已确认、待客户确认、内部判断、待验证事项。客户表达了一个痛点，不等于提出了明确需求；对某个方向表示兴趣，也不等于同意纳入本次范围；会议中暂时没有异议，更不等于正式承诺。

摘要审核时，应重点检查以下内容：

• 人名、产品名、技术术语、数字、日期和时间；
• “暂不支持”与“支持”等否定表达；
• 说话人归属，以及带有条件的承诺；
• 会议讨论、建议、决定和假设之间的区别。

尤其要警惕摘要自动补全负责人和截止时间。如果会议没有明确说明，就应写成“负责人待确认”或“时间待确认”，而不是生成一个看似完整的任务。

把行动项写成可验收任务

“研究一下支付方案”不是合格的行动项。可执行的记录至少应包含负责人、动作、交付物、截止时间和完成标准，例如：“我在周五前比较两种支付方案，并提交包含费用、接入工作量和风险说明的表格，供客户周一选择。”

会后核对不能只看摘要本身，还要回到原始文字或音频，确认结论对应的上下文。涉及范围、价格、交付时间和客户承诺的内容，应优先人工复核；如果工具无法定位原文、修改错误或导出完整记录，就不适合承担关键交付环节。

让客户确认，而不是让摘要替客户确认

对外发送的纪要应只保留已确认事项、待确认问题、明确的行动项，以及本次不包含的内容。开头可以说明：这是会议整理稿，若有理解不准确或遗漏，请在指定时间前指出；未确认事项不视为已纳入本次交付范围。

自动化的价值，是减少逐字记录，把时间转移到核对和跟进。只要没有完成事实核对、范围标注和客户确认，摘要越快生成，错误也可能越快进入交付流程。