会议纪要的需求很具体：一场 60 分钟的会，参与者想要的是结论、待办和责任人，而不是逐字稿。AI 会议纪要 API 的价值，是把“录音”变成“可检索、可分配、可追踪”的结构化记录。但真正落地时，难点往往不在模型，而在转写质量、长会议切分、说话人分离的边界，以及会议内容的权限控制。
本文给出一套可执行的企业落地方案，覆盖架构、模型选择、提示词、权限、成本与测试。
说明：不同厂商的语音识别与语言模型接口存在差异，本文以常见的“转写 API + OpenAI 兼容对话接口”为例；模型与价格以站内 模型价格 为准。
一、整体架构
一条完整的会议纪要链路通常包含五段：
录音/会议流
→ 对象存储（加密、生命周期）
→ ASR 转写（含时间戳、说话人分离）
→ 文本清洗与分段
→ LLM 摘要（结构化 JSON）
→ 纪要库（权限、检索、导出）
几个工程要点：
- 原始音频与转写文本分开存储，设置不同的保留期限。
- 转写结果保留时间戳，摘要中的每条结论都能回链到原话。
- 摘要生成异步执行，前端先展示“转写中/摘要中”的状态。
- 失败可重试，重试幂等，避免重复计费与重复写入。
二、转写层：先选对 ASR
会议场景的转写分两类：
| 类型 | 适合场景 | 优点 | 限制 |
|---|---|---|---|
| 实时转写 | 线上会议、直播、字幕 | 延迟低，可边开边看 | 断句和说话人可能不稳定 |
| 录音文件转写 | 线下会议、访谈、复盘 | 准确率与分段更稳 | 需要等待，适合异步 |
选型时重点看：
- 中文普通话与口音的识别表现。
- 是否返回时间戳、标点、数字格式。
- 是否支持说话人分离（diarization）。
- 单文件时长、格式、采样率限制。
- 是否支持热词/自定义词汇（人名、产品名、缩写）。
- 数据留存与地域合规。
如果会议里专业术语多，热词表往往比换模型更有效。把公司名、项目代号、产品名整理成词表，能明显减少后续摘要的“同音错字”。
三、模型选择：转写与摘要分开
不要把转写和摘要交给同一个模型。合理的分工是：
- ASR 模型负责“听清”，关注字错率、时间戳和说话人。
- 小模型负责清洗、分段、去口语词。
- 强模型负责最终摘要、行动项抽取和冲突识别。
一场两小时的会议，转写文本可能有两三万字。直接把全文塞给强模型，成本和延迟都高。常见的做法是先用小模型按议题分段、压缩冗余，再让强模型做汇总。模型是否可用、上下文长度与单价，以站内 模型价格 为准。
四、长会议怎么切分
切分的目标不是“切得均匀”，而是“不切断语义”。建议按以下顺序处理：
- 优先按议程或章节切分。
- 没有议程时，按静音段和话题转换切分。
- 单段控制在 8–15 分钟，段间保留少量重叠。
- 每段单独摘要，再合并成全局纪要。
- 合并时去重，保留分歧与未决事项。
“分段摘要 + 全局汇总”的 map-reduce 方式，比一次性长上下文更可控，也更容易定位错误来自哪一段。注意在合并阶段保留每段的会议角色和时间范围，否则容易出现“张冠李戴”。
五、说话人分离的现实边界
说话人分离能标出“谁在说”，但它不等于身份识别。实际限制包括：
- 多人抢话、重叠发言时容易合并或错分。
- 远场麦克风、会议室混响会降低分离效果。
- 说话人数越多，错误率越高。
- 同一人跨设备、跨会议的音色可能不一致。
- 无法自动对应到企业通讯录里的真实姓名。
因此产品设计上要留人工校正入口：允许用户把“说话人 1”改成真实姓名，并把校正结果用于该场会议，而不是悄悄写进全局身份库。对外宣传时，建议写“说话人分离”而不是“自动识别参会人”。
六、提示词与输出结构
摘要提示词的关键是“限定输出结构 + 要求引用原文”。示例：
你是会议纪要助手。根据带时间戳的转写文本，输出 JSON：
{
"title": "会议主题",
"summary": "不超过 200 字的结论",
"decisions": [{"content": "", "time": ""}],
"action_items": [{"task": "", "owner": "", "due": "", "time": ""}],
"risks": [{"content": "", "time": ""}],
"open_questions": [{"content": "", "time": ""}]
}
规则：
1. 只依据转写文本，不补充外部事实。
2. 无法确定负责人或截止时间时，填 null 并注明“待确认”。
3. 每条结论尽量附时间戳。
4. 区分“已决定”和“待讨论”，不要混淆。
工程上再加一层 JSON Schema 校验；字段缺失或类型不对时自动重试一次，仍失败则降级为纯文本摘要并标记人工复核。
七、权限与数据隐私
会议内容常常包含人事、合同、并购等敏感信息，权限必须做在服务端，而不是交给模型判断。
- 按会议成员授权：只有参会人与被授权者能看纪要。
- 按租户隔离：索引、对象存储、缓存都带租户标识。
- 最小权限：摘要服务只读当前会议，不跨会议检索。
- 加密：传输与存储加密，密钥独立管理。
- 保留策略：音频、转写、摘要分别设置保留期，支持到期删除。
- 审计：记录谁在何时查看、导出、分享。
- 敏感会议：允许管理员设置“禁止 AI 处理”或“仅本地处理”。
- 供应商数据条款：确认音频与文本是否用于训练、保留多久。
如果使用第三方模型，建议在会前告知参会者录音与 AI 处理情况，并保留撤回机制。这既是合规要求，也是内部推广的前提。
八、成本怎么估
会议纪要的成本由三部分组成：
单场成本 =
音频时长 × 转写单价
+ 输入 Token × 输入单价
+ 输出 Token × 输出单价
+ 重试与存储成本
降低成本的常见手段：
- 只对需要纪要的会议开启，不做全量录音。
- 先转写、后摘要，摘要失败不重复转写。
- 分段摘要用小模型，最终汇总用强模型。
- 对重复的例会模板化，减少提示词与上下文。
- 设置单场与每月预算上限，异常时长自动告警。
具体单价以站内 模型价格 为准；不要用“每分钟几分钱”这类固定数字做长期预算，模型和转写价格都会变化。
九、测试与上线
建议准备 30–50 场真实会议作为评测集，覆盖：
- 线上/线下、单人/多人。
- 清晰/嘈杂、普通话/带口音。
- 有无议程、有无专业术语。
- 短会/长会、有无重叠发言。
核心指标：
| 指标 | 说明 |
|---|---|
| 转写字错率 | 抽样人工校对，按领域词汇单独统计 |
| 说话人准确率 | 分段是否正确，是否能人工校正 |
| 行动项召回率 | 真实待办是否被完整抽出 |
| 行动项准确率 | 负责人、时间是否错配 |
| 幻觉率 | 是否出现原文没有的结论 |
上线节奏建议先灰度一个部门，人工复核两周，再逐步放开。不要用一场“演示效果很好”的会议代表整体质量。
常见问题
AI 会议纪要 API 能直接识别参会人姓名吗？
通常不能。说话人分离只能区分“声音 A/声音 B”，要对应真实姓名，需要企业通讯录或人工校正。
多长的会议适合自动摘要？
30–90 分钟的会议效果较稳。超过两小时建议按议程分段，否则摘要容易丢失细节。
录音一定要上传到云端吗？
取决于合规要求。敏感会议可以选择本地部署或私有化转写；使用云端服务时，要确认数据保留与训练条款。
摘要出现错误怎么办？
保留时间戳回链、允许人工编辑，并记录修改。对行动项设置确认环节，不要直接写入任务系统。
能支持方言和外语吗？
取决于 ASR 模型的语言支持。中英混合会议建议先测试实际口音与术语，再决定是否上线。
下一步
如果你的团队正要上线会议纪要，建议先用一条真实会议链路做 POC：转写、分段、摘要、权限、导出各跑通一遍，再评估成本。需要统一模型入口和用量管理，可以先 注册中商起航 AI 网关，模型与价格以 模型价格 为准。
相关阅读：
