会开完，纪要往往要拖到第二天才出来；等它出来，会上那句「先这样定」已经被忘得差不多了。录音和转写工具解决了「记不全」，但没人愿意读一份三小时的口语逐字稿。真正的工作量在后面：把流水账压成结论、把结论拆成待办、把待办落到人头上。这条流水线现在可以交给 AI，前提是你知道每一步该给它什么。
记纪要最难的不是记录，而是归纳
一场讨论里通常混着三种信息：结论、理由、以及被否掉的方案。逐字稿把它们按时间平铺，读者得自己重新梳理一遍才拿得到结论。人写纪要时做的正是这个梳理动作，AI 也能做，但它需要你明确说一句「按结论组织，不要按发言顺序组织」，否则它多半会把每段发言挨个概括一遍。
另一个常见误区是把纪要写成摘要。摘要是「讨论了什么」，纪要要回答「定了什么、谁去做、什么时候交」。前者读起来舒服但没法执行，后者才是一场会议真正留下的资产。判断一份纪要合不合格，用一条标准就够：不看记录、只看纪要，能不能直接开工。
纪要的价值不在完整，而在可执行——读完能回答「接下来谁做什么」就够了。
一条四段的流水线
第一段是转写。录音先过语音转文字，得到带时间戳的原始文本。这一步别省，也不要直接让多模态模型「听一遍录音」——长会议既慢又不稳，错一个词后面全跟着错。第二段是清洗：剔掉语气词、重复和跑题段落，同时保留发言人标签与大致议题边界，这份清洗稿是后续所有步骤的底稿。
第三段是结构化。把清洗稿按模板切块：会议信息、议题、每个议题的结论与分歧、待办清单。第四段是分发：待办按负责人拆成独立条目，写进任务工具或者直接发消息，别只躺在文档里等人来翻。四段里最容易被跳过的是第二段，但清洗做得糙，后面无论模型多强都只能对着一团口语做模糊概括。
提示词怎么写：给结构，不给文采
一个能反复用的模板大致长这样：先声明角色与任务（你是会议记录整理者，输出结构化纪要），再固定字段（时间、参会人、议题、结论、待办、待确认），最后给三条硬约束——只写会上明确说过的内容、不确定的标成「待确认」、待办必须带负责人和时间。字段固定之后，不同人整理出来的纪要看起来就像同一套体系。
分两次请求往往比一次到位更稳：第一轮只做清洗和分段，第二轮基于分段结果出纪要与待办。长会议一次性塞进去，模型容易在中段丢细节；拆开之后每一轮的输出都能单独检查。接口地址统一用 https://api.aigcbreeze.cn，选一个上下文足够长的模型，一小时会议的转写通常在一两万 token 量级，三小时的会要留出余量。
人工检查点放在哪
整条链路里有两处必须有人看：一是待办的负责人和时间，模型很容易把「我回头看看」当成承诺，写成「某人负责、周五前完成」；二是涉及数字与对外承诺的结论，转写错一个数字，纪要认真执行就是事故。
其余环节可以放心自动化：清洗、分段、摘要、排版。判断标准也简单——这一步错了会不会造成实际损失。会，就留人工复核；不会，就让它自己跑。把复核集中在两三个点上，比全篇通读省力得多，也不容易漏。
常见问题
会议录音需要征得同意吗？
需要。会前一句「本次会议会录音用于整理纪要」，既是礼貌也是合规底线；涉及客户或外部方的会议，最好提前书面确认。整理完的录音按团队的数据规范保存或删除，别无限期堆在网盘里——录音比纪要敏感得多。
方言重、口音杂，转写错误太多怎么办？
先在转写环节解决，别指望后面的模型自动纠正。选方言支持较好的语音模型，或者请参会人尽量说普通话；产品名、专有名词可以提前准备一份词表，多数转写服务支持热词配置。错误率压到一成以下，后面的归纳才有意义。
纪要该用什么格式交付？
内部同步用纯文本或 Markdown 最省事，粘到哪都能读；要发给外部方，再让模型转成一页纸的正式版本，去掉内部分歧与讨论细节。同一场会议可以出两个版本，但结论必须一致——这也是为什么值得保留结构化的中间结果。