逐字稿正确，不代表说话人也标对了
Otter 和 Fireflies 都允许用户手动修改说话人标签，并在修改后重新生成摘要。转录内容和说话人归属需要分开核对；标签改了，已经生成的摘要也要更新。具体操作可查阅 Otter 的说话人管理说明和 Fireflies 的标签修改说明。
行动项还多一层判断。2025 年 EMNLP 的一项会议摘要研究指出，会议中的关键信息会散落在不同的发言轮次中，并依赖相隔较远的上下文；现有的大语言模型摘要仍会遗漏信息或补出原文没有的内容。任务、负责人和期限很少在一句话里同时说清，负责人有时要结合“我来处理”或“你能跟进吗”前后的回应才能确认。
逐字稿生成后，团队还要检查采集方式有没有留下身份信息、说话人标签是否可信、提议和决定有没有混在一起，以及最终记录能不能回到原始片段。这些检查决定了纪要能否直接进入任务系统。
还在挑选软件的团队，可以先看 2026 年 AI 会议助手指南。本文从工具接入之后讲起，重点放在采集、核验和发布。
逐字稿、摘要和会议记录各有用途
语音转文字解决“说了什么”。会议记录还得回答“这段话对后续工作有什么影响”。
从录音到可执行记录，中间经过四层处理：逐字稿保存原话；说话人归属记录谁在什么时间发言；语义判断区分问题、提议、异议、决定和承诺；最后才把确认过的信息写进任务系统、决策日志、CRM 或知识库。
任何一层都可能出错。转录模型可能听错日期，说话人分离可能把正确的话分给错误的人，摘要模型则可能把试探性的建议写成已经通过的决定。
| 比较维度 | 原始逐字稿 | AI 摘要 | 已核验的会议记录 |
|---|---|---|---|
| 主要用途 | 保存发言内容 | 快速了解会议 | 支持执行和责任追踪 |
| 说话人 | 可能只有 Speaker A/B | 经常省略 | 使用核验过的姓名，存疑时明确标注 |
| 决策状态 | 藏在多轮对话中 | 可能混淆提议与决定 | 区分已确认、待讨论、暂缓和撤销 |
| 行动项 | 分散在上下文里 | 自动抽取 | 核对任务、负责人和时间 |
| 上下文 | 完整但难查 | 容易压缩掉条件 | 保留限制、异议和依赖关系 |
| 可追溯性 | 有原文，但查找费时 | 通常较弱 | 附时间戳和来源片段 |
| 能否直接发布 | 不能 | 通常不建议 | 人工核验后可以 |
排版越完整，人越容易放松警惕。NIST 生成式 AI 风险管理资料把自动化偏见、模型虚构和信息完整性列为需要管理的风险。NIST 对高完整性信息的描述也很具体：事实、意见和推断要分开，不确定性要写出来，内容要能连回原始证据，并保留清楚的流转记录。
会议记录同样需要这些约束。
录制前先定清楚要留下什么
很多团队先打开转录功能，会后才开始想纪要该怎么写。顺序倒过来更省事：先确定这场会需要留下什么结果。
项目周会通常关心阻塞、风险和负责人；客户访谈要保留原话与研究备注，却不能把每个需求都写成产品承诺；事故复盘看重时间线；决策会则要留下提案、反对意见和最终状态。
最低限度的记录结构可以这样设计：
会议
├── 参与者
├── 摘要
├── 已确认的决定
├── 尚未确认或暂缓的决定
├── 行动项
├── 待回答问题
├── 风险与异议
└── 来源引用
固定字段的好处，是缺失信息会直接露出来。没有人接下任务，负责人就写“未分配”；讨论过某个日期，但没有形成共识，它就不能变成截止日。
录制前还要说清楚谁能启动录音、参与者如何收到通知、是否需要明确同意、音频和纪要由谁访问、资料保留多久、哪些会议禁止录制，以及能否让第三方转录机器人加入。
平台设置可以承担其中一部分。Google Meet允许管理员要求参与者在录音、转录或启用“帮我记笔记”前明确同意。自动笔记可以按摘要、决定、后续步骤和讨论详情整理，访问范围则由主持人的共享设置控制。这项功能一次只支持一种会议语言，混合语言会议目前不在支持范围内。具体限制见 Google Meet 官方帮助。
各地对会议录音和同意的要求并不相同。团队需要按所在地区、参与者身份和使用目的核对适用规则。本文只讨论工作流程，不构成法律意见。
采集方式决定了证据能留下多少
录音方式会直接影响后面的说话人识别、复核和纠错。方便不等于合适；一份缺少身份信息的录音，可能把省下的设置时间全都还给人工审核。
| 采集方式 | 参与者识别 | 是否保留音频证据 | 参与者可见性 | 主要限制 | 更适合的场景 |
|---|---|---|---|---|---|
| 平台原生转录 | 可以使用平台内的参与者信息 | 取决于平台设置 | 通常会在会议界面提示 | 受平台、套餐和语言限制 | 日常内部会议 |
| 会议机器人 | 可以结合参会名单和采集音频 | 通常会保存音频或视频 | 作为参会者出现 | 需要准入、通知和权限管理 | 跨平台会议 |
| 本地系统音频 | 经常只能得到通用说话人标签 | 由本机控制 | 可能不会出现在参会名单中 | 身份映射弱，管理负担较高 | 个人笔记和兼容性场景 |
| 上传已有录音 | 取决于音轨和录音质量 | 保留原始文件 | 会后处理 | 缺少实时身份和会议元数据 | 访谈与存档录音 |
六款产品，差别在复核时能回到哪里
它们都能生成会议笔记，但留下的核验材料不同。选工具前先问一句：纪要发生争议时，审核者能回到录音、带时间戳的逐字稿、可修改的说话人标签，还是只能看到整理后的笔记？
| 产品 | 采集与输出 | 更适合的工作流 | 复核时要留意 |
|---|---|---|---|
| Google Meet | 平台内生成笔记，并通过 Google Docs 和日历事件分享 | 已经使用 Google Workspace，希望由管理员统一控制同意和共享范围 | 一次只支持一种会议语言；混合语言会议需要另行处理 |
| Otter | 生成逐字稿和摘要，支持重命名或合并说话人 | 经常需要人工修正说话人，再更新会议摘要 | 改完说话人后要重新生成摘要，旧摘要不会自动变成可信记录 |
| Fireflies | 可通过会议机器人、本地系统音频或上传文件采集 | 会议平台不统一，需要按场景切换采集方式 | 不同模式留下的证据不同；本地系统音频可能只有通用说话人标签，也不保存音视频 |
| Fathom | 可加入 Zoom、Meet 和 Teams，生成摘要、录制链接与行动项 | 销售或客户会议结束后，需要把行动项继续送入业务系统 | 自动提取的行动项要先核对负责人，再进入 CRM 或任务系统 |
| Tactiq | 通过浏览器或桌面端采集逐字稿，可修改说话人姓名并导出 PDF 或 TXT | 不想让会议机器人加入，主要交付物是文字记录 | 改名会作用于该说话人的全部片段；多人被合并时仍要逐段检查 |
| Granola | 从本机音频生成逐字稿，并结合手工速记整理笔记；不保存会议音频 | 更重视低打扰和人工笔记，希望会中先标出重点 | 会后没有原始录音可回放；高风险会议需要确认逐字稿和手工笔记是否足够支撑复核 |
Fathom 的设置说明列出了自动行动项、摘要与录制分享方式；Tactiq 的说话人修改说明说明改名会应用到整份逐字稿，导出说明则列出了 PDF 和 TXT 两种格式。Granola 的安全说明明确写明它只保留逐字稿和笔记，不保存会议音频。
同一款产品换一种采集方式，拿到的证据也会不同。Fireflies在官方文档中说明，机器人模式会采集说话人标签并保存音视频；本地系统音频模式只显示通用说话人标签，也不会保存音视频文件。产品没有换，后续能核验的材料已经变了。细节见 Fireflies 桌面端采集说明。
如果需要比较具体产品，可以继续看 Fireflies、Otter.ai 与 Fathom 对比。工作流这里要解决的问题更窄：选择能保留身份、时间戳和来源材料的采集方式。
音频之外的材料也要留
一句“采用第一个方案”，单听录音很难知道它指什么。答案可能在共享的幻灯片里，也可能在会议聊天中。邀请信息和参会名单、议程、演示文稿、聊天记录、白板、相关项目资料，以及主持人的手工备注，都可能补上逐字稿缺失的指向关系。
共用会议室麦克风、电话接入、背景噪声、频繁打断、多人重叠发言、混合语言或参会者姓名缺失，都应该记进采集说明。这些条件会提高说话人归属出错的概率，后续审核不能按普通会议处理。
先校正说话人，再重做摘要
说话人分离（speaker diarization）负责把录音切成 Speaker A、Speaker B、Speaker C 等片段，回答“谁在什么时候说话”。说话人识别再把这些标签对应到真实姓名。
这一步并不稳定。新出现的人可能一直没有姓名，声音相近时可能互相混淆，共用麦克风还会把几个人压进同一个标签。Interspeech 2025 的 MISP 会议转录挑战仍把音视频说话人分离单列为核心任务，参赛系统也要专门处理会议中的复杂声学环境和重叠发言。多人同时开口时，不能只看逐字稿文字是否正确。
处理顺序建议固定下来：
生成逐字稿
→ 检查说话人切分
→ 对应真实姓名
→ 修正合并或重复的人物标签
→ 重新生成决定、行动项和摘要
说话人标错之后，单改逐字稿还不够，之前生成的摘要可能继续保留错误归属。Otter支持重命名说话人、合并重复身份，并在修正后重新生成摘要。最后一步能避免旧错误继续留在会议笔记中，详见 Otter 说话人管理说明。
身份无法确认时，不必硬猜。未知说话人、可能是 Jordan、多人重叠发言、会议室参与者、身份待核验 都比一个错误姓名安全。涉及审批、任务归属或客户承诺时尤其如此。
提议、决定和行动项要分开记
会议里有很多听起来像任务的话，实际并没有形成承诺。
“我们下周可以发布”是一项提议；“我可以准备初稿”可能只是在表达意愿；“周四发布，初稿由 Maya 负责”更接近决定和任务分派，但仍要确认团队是否接受了这两项安排。
决策记录可以使用四种状态：
confirmed：团队或有权限的决策者已经批准。proposed：有人提出，但尚未通过。deferred：讨论过，决定暂缓。reversed：后续发言替换或撤销了前面的决定。
每条决定建议保留以下字段：
决定内容
当前状态
决策人或批准群体
时间戳
原因或限制条件
考虑过的替代方案
异议
来源片段
来源片段不必复制大段逐字稿，只要足以说明它为什么被记为决定。
一条行动项至少要写清三件事
落到任务系统，一条行动项至少要留下任务内容、负责人和截止日期或时间范围。缺失的字段应该暴露出来，不能让模型自动补齐。前文提到的 EMNLP 2025 会议摘要研究把决策、行动项和上下文分开处理，并要求生成内容只能使用逐字稿中能够核验的事实。
产品方给出的提醒也很直接。Microsoft Teams 的会议回顾说明明确写着 AI 生成内容可能不准确或不完整；当用户把摘要和后续任务发成邮件时，界面还要求发送前先编辑核对。
落到记录中，可以保存这些字段：
任务
负责人
截止日期或时间范围
状态
依赖关系
来源时间戳
核验状态
没有的信息就留空：
负责人：未分配
截止日期：未说明
不要因为没人被点名，就把任务塞给会议组织者；不要把“下周也许可以”换算成周五截止；提出问题的人也没有自动接下解决问题的责任。
待回答问题、被否决的选项、暂缓提案、风险、异议和仍需验证的假设，也应该留在记录里。删掉这些内容，摘要会更整齐，后来的人却看不出团队当时为何作出选择。
优先核对会改变责任归属的字段
普通闲聊不必逐字审校。姓名、决定、承诺和日期值得花时间。
优先检查参与者和公司名称、产品名、日期、金额、百分比、否定表达、条件与例外、决定状态、行动项负责人、客户承诺，以及法律、医疗、安全或财务相关表述。
每一条已确认的决定和行动项，都应附上四项依据：来源时间戳、说话人、简短原文片段，以及逐字稿或录音链接。记录还要显示它目前是 AI 生成、待核验、人工确认，还是 核验后修正。读者不该把模型初稿误认成人工确认结果。
一旦修正了说话人、日期、金额或原句，决定提取、行动项提取、摘要和一致性检查都要重跑。逐字稿已经改对，旧摘要仍然可能错。
自动化做到哪一步，要看出错代价
内部逐字稿里的错别字通常只会添点麻烦。客户纪要里多出一项从未承诺的交付，后果可能落到合同、收入或信誉上。
| 工作步骤 | 是否适合自动化 | 仍需核对的内容 | 建议控制方式 |
|---|---|---|---|
| 语音转文字 | 可以 | 姓名、数字、日期和否定词 | 标记低置信度片段 |
| 说话人切分 | 可以 | 重叠发言和共用麦克风 | 保留未知标签 |
| 会议摘要 | 可以 | 是否丢掉限制和异议 | 分享前快速复核 |
| 决定提取 | 辅助自动化 | 是否真的获得批准 | 强制附时间戳和原文 |
| 行动项提取 | 辅助自动化 | 任务、负责人和日期 | 缺失字段不得推断 |
| 创建内部任务 | 有条件自动化 | 项目和负责人映射 | 增加确认步骤或撤销窗口 |
| 发送客户纪要 | 不宜全自动 | 承诺、价格、日期和措辞 | 发送前人工批准 |
| 删除录音 | 按政策自动化 | 保存期限和调查需求 | 按会议类型设置规则 |
信息离开会议后传播得越远，审核门槛就该越高。内部摘要可能只需快速看一遍；跨部门派发任务要确认负责人；客户邮件和正式决策日志则需要明确的批准人。
写入任务系统时，来源别丢
不同信息应进入各自负责的系统。已确认的决定写进决策日志，行动项进入项目管理工具，客户承诺写入 CRM，可复用的背景材料进入知识库，完整逐字稿则留在受控的会议档案中。
只有一句任务描述，信息不够：
更新新用户引导流程。
保留来源之后，记录会变成这样：
任务：更新新用户引导流程
负责人：Maya Chen
截止日期：10 月 12 日
来源：32:18～33:04
会议：10 月 3 日增长复盘
状态：人工确认
逐字稿：[来源链接]
负责人看到错误时有依据提出异议，后来接手项目的人也能分清：这项承诺来自会议，还是会后由管理者补进去的任务。
来源记录发生修改后，要同步修正逐字稿、摘要、决策日志和任务系统，并留下更正说明。如果责任归属发生变化，还要通知受影响的人。静默修改很容易让团队同时拿着两个版本工作。
权限和保留期限按会议类型设置
一段会议录音可能同时包含员工讨论、客户信息、商业计划、个人资料和声音特征。需要执行某条任务的人，未必需要听完整录音。
音视频、完整逐字稿、AI 摘要、决策日志、行动项，以及用于识别说话人的声音资料，应该分别设置访问权限。
在 GDPR 适用的场景中，欧盟委员会现行的数据处理原则说明列出了目的限制、数据最小化、准确性、存储期限和安全等要求。EDPB 2024 年关于 AI 模型的第 28 号意见又强调，AI 模型涉及个人数据时，匿名性、法律依据和个人可能受到的影响都要按具体情况评估。落到会议资料上，组织需要说得清楚：为什么收集每一种资料、谁可以查看、什么时候删除，以及是否会被用于原定目的之外的处理。
日常周会、客户电话、研究访谈、绩效谈话、事故复盘和董事会会议，很难共用一个保存期限。有些记录为了追责要保存更久；有些音频包含敏感内容，核验后的书面记录足够使用，就应尽快删除。
全部永久保留会扩大权限、安全和合规风险，录音一生成就删除又会失去纠错依据。保存时间应跟着会议用途、敏感程度和复核需要走。
用团队自己的会议做验收
厂商公布的准确率很难代表一家公司里的真实表现。姓名、口音、麦克风、会议形式和行业术语都会改变结果。
测试样本不用很大，但要覆盖团队常见的麻烦场景：两人通话、多人项目会、快速抢话、重叠发言、会议室共用麦克风、混合语言、没有形成最终决定的讨论，以及前半段作出决定、后半段又撤回的会议。
验收时至少观察这些指标：
- 说话人归属准确度：重要发言有没有记到正确的人名下。
- 决策精确率：提取出的决定是否真的已经确认。
- 决策召回率：实际形成的决定有没有遗漏。
- 负责人准确度：原始对话是否支持这项任务分派。
- 日期准确度：截止日期是否明确说过，解释是否正确。
- 上下文保留度：条件、异议和依赖是否仍在。
- 可追溯性：审核者多久能找到原始依据。
- 纠错时间：发布前需要投入多少人工时间。
文字错误率再低，也补不回两类事故：把正确的话记到错误的高管名下，或把被否决的方案写成已经批准。
会后 15 分钟怎么复核
一小时会议不需要从头到尾重听。审核时间可以集中在身份、决定和任务上。
0～2 分钟：确认会议信息
核对标题、日期和参会名单，选择会议类型，再补上已知的音频或语言限制。
2～5 分钟：检查说话人标签
抽查开场、主要转折和重要片段。能确认身份就替换通用标签，不能确认就保留未知；同时留意多人被合并或重叠发言的地方。
5～8 分钟：检查决定
把已确认的决定和提议分开，检查后面的发言是否推翻了前面的决定，并为每条确认结果附上时间戳。异议、依赖和条件不要删。
8～11 分钟：检查行动项
核对任务内容，确认负责人确实接受了安排。截止日期没有说清就留空，再附上支撑这项分派的原始片段。
11～13 分钟：重新生成并对齐
修改完成后重做摘要，对照决定和行动项清单，处理姓名、日期与状态之间的冲突。
13～15 分钟：批准发布
确认接收人，把不同内容送入对应系统，应用访问权限和保存期限，最后将记录标记为已审核。
普通内部会议可能用不了 15 分钟。涉及客户承诺、事故调查或受监管业务时，复核时间应该增加。
常见问题
语音转录和说话人分离有什么区别？
语音转录记录“说了什么”。说话人分离按发言人和时间切分录音，通常先得到 Speaker A、Speaker B 一类标签；说话人识别再把这些标签对应到真实姓名。
一句话可以转录得完全正确，却被记到错误的人名下。
AI 能自动生成准确的会议纪要吗？
AI 可以生成可用的初稿。决策状态、负责人、截止日期、价格、客户承诺和敏感表述，仍应回到逐字稿或录音核验后再发布。
生成逐字稿后还要保留原始录音吗？
是否保留取决于会议用途、敏感程度、纠错需求、组织政策和适用法律。录音便于事后核验，也会增加隐私和安全风险。不同会议类型应设置不同的保存期限。
怎样避免 AI 擅自补出行动项负责人？
每一项任务分派都要附来源时间戳。逐字稿没有显示谁接受了任务，就把负责人记为“未分配”。职位、参会角色，以及谁先提出问题，都不能单独作为归属依据。
使用 AI 录制和转录会议合法吗？
录音和同意规则会随司法辖区、参与者所在地、组织身份和使用目的而变化。团队应通知参与者，说明记录用途，执行适用的同意流程，并在需要时咨询法律专业人士。
发布决定或分派任务前，用五个问题检查记录：原话是什么，谁说的，它是提议还是已经确认，哪些上下文会改变含义，审核者能去哪里核验。少一项，就先留在待核验状态。
