搜「AI总结会议记录怎么写」的人，多数目标很具体：手上已有一段会议录音、转写稿或聊天记录，想把它整理成能直接发出去、还能核对原文的纪要。真正卡住的通常是指令写法，直接复制。
AI 总结会议记录的可行路径，是「原始转写 → 带发言人和时间戳的分段材料 → 限定字段的结构化提示词 → 逐条回查原文」。适用场景：周会、评审会、客户沟通这类结论和待办较多的会议。操作上先固定输出字段（决议、待办、负责人、截止时间、待确认项），再要求每条结论附原文片段作为依据。验证时逐条比对转写稿，确认没有编造承诺和负责人。风险边界：转写缺失、多人抢话和口音问题会直接导致总结失真，音质差的会议要先修转写再谈总结。
总结会议记录：先把能核对的事实摆清楚
动手之前先确认三件事是否能核对到，否则总结出来也没法用。
- 转写稿在哪、长什么样：是平台自动生成的逐字稿，还是人工整理的发言记录。自动转写通常带时间戳，但人名、专有名词经常错，需要先粗看一遍。
- 有没有发言人和时间信息：会议记录里最容易被追责的是「谁承诺了什么」，没有发言人的转写稿，总结时只能写「会议讨论了」，不能写「张三负责」。
- 输出给谁看：发给参会人看的是过程纪要，要保留争议和分歧；发给没参会的人看的是决议摘要，只要结论和待办。这两种写法字段不一样。
可以先检查转写文件的基本情况，比如行数和时间戳分布，判断信息密度：
wc -l meeting_transcript.txt
grep -cE '^\[[0-9]{2}:[0-9]{2}' meeting_transcript.txt
head -20 meeting_transcript.txt如果带时间戳的行数远少于总行数，说明转写是整段输出的，没有分段。这种情况下要先把材料按议题或发言段落切开，再喂给模型，否则长文本会被模型自行压缩，细节容易丢。
这一步先不下结论：材料不完整时，写出来的纪要只能当草稿，不能直接当会议正式记录归档。
总结会议记录最容易搞错的一点
最常见的误解是把「模型总结得通顺」当成「总结得对」。模型很擅长把模糊的讨论写成语气确定的决议，比如会上只是说「这个方向可以考虑」，总结里就变成「会议决定采用该方案」。语气强度被抬高，是会议纪要里最难被发现、后果最直接的一类错误。
判断分界在于：每一条结论能不能在转写稿里找到对应原话。能对应上的，属于提炼；对应不上的，属于生成。
一个能区分这两种情况的检查动作：从总结里随机挑 3 条带负责人或时间节点的待办，用关键词在转写稿里反查。
grep -n '张三' meeting_transcript.txt
grep -n '下周三\|下周五\|月底' meeting_transcript.txt如果搜不到对应发言，说明这条待办是模型补出来的，需要回听或删掉。这个动作比通读全文快得多，也更容易暴露问题。
总结会议记录：一个照着就能做完的做法
下面这条提示词骨架可以直接替换使用。它的重点是固定输出字段，并要求每条结论附依据，减少模型自由发挥的空间。
你是会议记录整理助手。请只依据下面提供的转写内容整理纪要，不要补充转写里没有的信息。
输出格式：
1. 会议基本信息：议题、参会人（仅限转写中出现的名字）
2. 已达成共识：每条一行，末尾用【依据：原话片段】标注
3. 待办事项：表格形式，列为 事项 | 负责人 | 截止时间 | 依据
- 负责人或截止时间在转写中未明确时，写「未明确」，不要推测
4. 待确认或存在分歧的点：列出讨论中未收口的内容
5. 未提及但通常需要跟进的事项：单独列出，并标注「转写中未提及」
约束：
- 不要使用「决定」「确定」等强结论词，除非转写中出现明确表述
- 人名、项目名、数字保持转写原文写法，不要改写
- 输出语言与转写语言一致
转写内容：
{{TRANSCRIPT}}执行顺序建议如下：
- 把转写稿按议题切成若干段，单段建议控制在模型上下文容易处理的范围，长会议不要一次性提交。
- 先跑第一段，检查输出字段是否齐全、依据片段是否真的能在原文找到。这一步看到的是格式是否稳定，不是内容是否准确。
- 格式稳定后再批量跑剩余段落，最后合并。合并时重点处理跨段落的同一待办，避免重复列出。
- 合并后人工过一遍「待办事项」表，这是最容易被发出去、也最容易被追问的部分。
如果用的是带 API 的模型服务，参数上建议把温度调低，减少措辞发散；模型名称、上下文长度、计费方式和调用限额这类会变的东西，以你账号控制台或服务商文档页当前显示为准，不要照搬别人的配置。
总结会议记录：怎么验证结果对不对
验证分两层：结构完整性和事实可回溯性。
结构层面，检查输出是否包含约定的全部字段。可以直接数一下待办表的行数与转写中出现的行动类表述是否量级相当：
grep -cE '(我来|我负责|跟进一下|下周|回头)' meeting_transcript.txt如果转写里只有几处行动表述，总结却列出了十几条待办，大概率是模型在补全，需要逐条回查。
事实层面，正常结果应该长这样：每条共识后面都跟着一段能在转写中原样搜到的短句；待办表的负责人列要么是人名，要么写「未明确」，不出现「相关同事」这类模糊填写；分歧项里保留会上没说拢的问题，而不是被抹平成一致意见。
如果总结里出现了转写中完全没有的项目名、数字或日期，直接判定这一条不可用，不要试图修改措辞保留它。会议纪要的价值在于可追溯，一条编造的待办会让整份纪要失去可信度。