1. 先把需求掰开会议记录到底卡在哪一步我第一次认真考虑用本地 AI 助手做智能会议记录是在连续两周的跨部门对齐会之后。那两周我手里攒了十几个音频文件每个四五十分钟人工整理一份纪要要两小时起步而且整理到第三个会的时候我已经记不清这个结论是周三那场还是周四那场定的了。后来我搭了一套跑在本地机器上的会议记录流程也就是标题里说的 Meetily 这一类本地 AI 助手录音进、文字出、要点成。它能顶掉的部分是听写、分段、说话人标注、初版摘要这四件重复劳动留下的是判断和取舍——那部分还得人来做。这类东西适合谁三类人受益最明显一是每周开三场以上会、纪要压身的项目推进者二是做访谈、用户调研、口述记录的内容工作者三是对数据不能出本机这件事有硬性要求的团队比如讨论产品路线、客户报价、内部评审这类内容。它不解决开会效率低这种大问题它解决的是会开完了结论没留下来这个具体的小问题。标题里本地两个字是关键也是本文大半篇幅要讲的东西。本地意味着模型在你自己的硬盘和显卡上跑音频不离开你的机器代价是你要自己管环境、管模型、管参数。所以这篇文章我不打算写成一个说明书而是按我自己的落地顺序讲为什么这么选、每一步的原理是什么、参数怎么算出来的、哪里会翻车。1.1 三个断点听不全、记不准、理不清把会议记录这件事拆细其实卡在三个地方任何一个没解决整条链就废。第一个断点是听不全。人耳在嘈杂会议室里能自动过滤空调声、键盘声、隔壁工位的聊天麦克风不能。笔记本内置麦克风在 3 米开外的拾音信噪比会掉到很难看的程度后面模型再怎么强也救不回来。我最早的一批录音就是这么废掉的——人声和底噪比例太差转写出来半篇是乱码。第二个断点是记不准。这里有两层一层是同音字和专有名词比如内部项目代号、产品模块名、人名通用模型大概率写错另一层是说话人归属一段这个方案我们下周再定如果不知道是谁说的价值直接归零。第三个断点是理不清。语音转成文字只是把 40 分钟变成一万多字信息密度并没有提升。真正的纪要需要的是结论 / 待办 / 负责人 / 时间点这四样东西。这一步靠本地大模型做结构化抽取但它的输出质量高度依赖提示词和上下文长度——这也是最容易做得潦草的一步。我把这三个断点对应到具体的技术环节就是采集质量决定上限、识别模型和热词表决定准确度、说话人分离决定可用性、摘要提示词决定最终成品的可读性。后面每一节其实都在给这三个断点找解法。1.2 本地化方案的取舍一张表看清楚很多人问我直接用在线服务不香吗为什么要自己折腾环境。这事儿没有标准答案我把当时的对比表贴出来你可以对着自己的场景打分。维度在线云服务本地 AI 助手Meetily 这类首次上手成本低注册即用中高装依赖、下模型、调参数音频数据流向上传至第三方全程留在本机磁盘长会议成本按时长或订阅计费越长越贵一次硬件投入之后边际成本接近零识别准确率通用场景很好通用模型接近垂直术语靠热词表补说话人分离通常内置且免调需自己跑分离模型耗时较高定制空间提示词、术语表受限提示词、模型、后处理全可改断网可用性不可用完全可用运维负担由服务方承担自己承担升级要手动我选本地的真实原因并不完全是在意隐私这个抽象概念而是长会议的成本结构我这类工作一小时会议是常态按量计费累积起来不便宜而且我需要反复重跑换提示词、换模型、补热词云服务每重跑一次都是钱本地重跑只是多花几分钟电费。这个可以随便重跑的自由度是我最看重的部分。反过来说如果你一个月只开两三次会、对术语准确率要求不高、也没有必须留在本机的约束老老实实用现成服务更划算别为了折腾而折腾。1.3 Meetily 这条链路的整体架构按本地会议助手的通用做法整条链路大致是这么串的我把它画成了一条文字流水线这里只讲结构具体实现以项目文档为准麦克风/系统内录 → 重采样为 16kHz 单声道 → VAD 切片 → 语音识别 → 词级时间戳 → 说话人分离 → 时间轴对齐 → 结构化存储 → 大模型摘要 → 导出每一段的作用和常见坑采集段决定信噪比。能用外接麦就别用内置麦能录系统内声音轨就别只录房间。预处理段统一成 16kHz、单声道、16bit PCM是因为绝大多数语音识别模型的输入就是按这个规格训练的采样率不对会直接掉准确率。VAD 段语音活动检测把静音和纯噪声切掉。它的作用是省算力——一场会议真实有人说话的时间可能只占 60%~70%剩下的都白算。识别段本地 Whisper 系列模型是当前最通用的一档中文效果好、多语言、有现成的高效推理实现。分离段说话人聚类常见方案是 pyannote 一类的声纹分离模型输出谁在第几秒到第几秒说话。对齐段把识别出来的词级时间戳和说话人区间做重叠计算判断每句话归属谁。摘要段本地大模型Ollama、llama.cpp 之类跑的量化模型按模板抽取结论和待办。这条链路有一个很现实的约束除了采集其他每一段的耗时都跟音频时长近似线性。所以一场两小时的会端到端跑十几分钟是正常的别指望点一下几秒出结果。理解这一点后面调参数时你就不会瞎折腾了。2. 环境准备硬件门槛、依赖顺序与模型选型这一节是我踩坑最多的地方。软件装错顺序、模型选大了一号、显存算错都会让你在第一步就卡住半天。2.1 硬件门槛怎么算含显存与磁盘估算先把账算清楚别凭感觉买卡或者选模型。磁盘16kHz、单声道、16bit 的原始音频每秒是 16000 × 2 32000 字节约 31.25 KB/s。算下来1 小时 3600 × 31.25 KB ≈ 112.5 MB按 1024 进制约 110 MiB3 小时的长会 ≈ 337 MB这是原始 wav 的体积。转成 16kbps 左右的压缩格式能压到十分之一但做识别时建议保留无损压缩引入的失真会直接吃掉准确率。显存以 Whisper 系列为例参数量和权重大小大致是这么个关系fp16 精度每个参数 2 字节模型档位参数量权重占用fp16推荐显存相对速度tiny39M≈ 0.08 GB2 GB极快base74M≈ 0.15 GB2 GB很快small244M≈ 0.5 GB3 GB快medium769M≈ 1.5 GB5 GB中large-v31550M≈ 3.1 GB8 GB 起慢注意权重占用只是静态部分实际跑起来还要加上激活值和缓存峰值通常是权重的 2~3 倍。我当时按 3.1 GB 权重估了 4 GB 显存结果 large-v3 一跑就爆最后是 8 GB 卡才稳住。这个错误的根源就是只算了权重没算中间张量。如果没有独显纯 CPU 也能跑但要有心理准备medium 在普通桌面 CPU 上的实时率RTF处理时长 ÷ 音频时长大概 0.5~1.0也就是一小时会议要跑 30~60 分钟。加量化int8能快 2~3 倍代价是准确率略降。内存识别本身不占太多内存但说话人分离模型和本地大模型是内存大户。我的经验值是——纯转写 8 GB 够用加上分离和摘要16 GB 是舒适线32 GB 就不用惦记了。2.2 依赖安装顺序与踩坑点装依赖这事顺序错了会互相打架。我按稳定可复现的顺序来# 1. 先固定 Python 版本3.10 或 3.11 最稳 python -V # 2. 建独立虚拟环境别往全局装 python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate # 3. 先装深度学习底座注意和 CUDA 版本匹配 pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu121 # 4. 再装识别与音频处理 pip install faster-whisper soundfile librosa numpy # 5. 最后装分离模型与前端依赖 pip install pyannote.audio几个必须提醒的点第一条不要先装项目依赖再装 torch。很多包会顺手拉一个 CPU 版 torch 进来等你发现跑在 CPU 上再想换得先卸载干净的依赖树很麻烦。第二条CUDA、驱动、torch 三者版本要对得上。判断方法很简单装完跑一句python -c import torch; print(torch.cuda.is_available())输出True才算通。输出False就先解决这个别往下走。第三条ffmpeg 这个外部可执行文件经常被忘掉。音频重采样、格式转换很多底层库要调用它缺了会报一个很难看懂的错。ffmpeg -version能出版本号就没问题。第四条路径里不要有中文和空格。这条是老生常谈但每年还是能看到有人被C:\Users\张三\Desktop\会议记录这种路径坑到。建议专门建一个纯英文的工程目录。2.3 模型选型别一上来就上最大号新手最容易犯的错是反正 large 最强直接上。我的建议反过来先用 small 把整条链路跑通再按需要往上加。理由很实在——链路中有五六个环节会出错你如果一上来用 large-v3转写一次一小时会议要 6~10 分钟调一次参数等一次一天下来调不了几轮人先崩了。用 small 的话同样时长可能只要 1~2 分钟你能快速验证采样率对不对、切片有没有问题、摘要模板通不通。我实际的演进路径是这样的tiny 起步只为了验证录音有没有声音、输出路径对不对。准确率别在意。small 打底跑通端到端验证说话人分离和摘要模板。medium 定稿日常用这一档中文普通话场景下 medium 的性价比最高比 small 明显准比 large 快一倍多。large-v3 兜底只对重要会议对外沟通、决策会用或者转写完发现某段明显有错时只对那一段单独重跑。这个分段重跑的技巧值得展开说你不需要为了修正三分钟的内容重跑两小时。把音频按 VAD 切好的段落单独导出指定时间区间重新识别再合并回时间轴就行。这一招在我这里省下的时间比任何参数调优都多。3. 核心链路拆解从声波到可读纪要3.1 音频采集与预处理先保证喂进去的是干净数据我得把预处理这一节放在识别之前因为采集阶段的损失是后面所有环节都补不回来的。采样率统一到 16 kHz。原因是语音的有效频带基本在 300 Hz ~ 8 kHz 之间按奈奎斯特采样定理16 kHz 采样率能无损覆盖到 8 kHz再高的采样率对语音识别没有增益只会让文件变大、计算变多。44.1 kHz 的录音重采样到 16 kHz用的是带抗混叠滤波的重采样不是简单抽点所以别自己写个[::3]去截。声道转单声道。双声道如果两轨内容相同比如立体声内录直接取平均但如果是左声道麦克风、右声道系统音这种分轨录制千万别混——混完会出现自己说话和自己的电脑声音重叠的情况识别质量崩掉。正确做法是分开转写再按时间轴合并。增益和降噪要克制。我试过给一段信噪比还行的录音做激进降噪结果转写准确率反而降了——降噪模型把辅音的气音也削掉了模型听到的是一片糊。经验是只有在底噪明显影响听感比如空调轰鸣、风扇直吹麦克风时才做降噪而且用温和档位音量太小就先归一化到 -3 dB 峰值别过度压缩。一个实操细节录音前先做 10 秒测试。让每个人正常音量说一句测试一二三我是某某回放听一遍。这 10 秒能提前发现麦克风增益太低、有明显回声、有人离麦太远这三类问题比会后再补救便宜太多。预处理这一段给个可复用的命令我用它把任意格式统一成识别友好的规格ffmpeg -i input.m4a \ -ac 1 \ -ar 16000 \ -sample_fmt s16 \ -af highpassf80,volume1.5 \ output.wavhighpassf80是切掉 80 Hz 以下的低频轰鸣桌面震动、空调低频几乎不会伤到人声基频volume1.5是我在安静环境下的常用增益如果你那边环境嘈杂先别加增益先解决噪声源。3.2 VAD 分段与流式转写的平衡语音识别模型不是喂多长都行。以 Whisper 系列为例它的训练窗口是30 秒一段超过这个长度会被内部再切分切分点如果正好落在词中间就容易出错。所以标准做法是用 VAD 先找出哪里有人在说话以语句为单位切片再送进模型。这样既省算力又避免在静音段产生幻觉文本模型在纯静音或噪声上偶尔会输出莫名其妙的句子这是已知现象。切片长度怎么定这是个平衡切片策略优点缺点适用固定 30 秒硬切实现最简单容易切断句子首尾丢词快速验证VAD 按静音切0.3~0.5 秒静音触发语义完整长句可能超过窗口日常推荐VAD 上限 25 秒强制切兼顾语义与窗口需处理超长句我目前的默认我用的参数是静音阈值 0.3 秒、最小语音段 0.25 秒、最大段长 25 秒、段首尾各留 0.2 秒余量。留余量这个细节很重要——不留的话句首的那、句尾的的话这类轻声音节很容易被切掉转写出来就是这个方案下周再这种缺字。关于流式还是离线我的判断标准是你需要实时看字吗如果需要比如远程会要边听边看字幕就走流式代价是准确率略低、上下文少如果只是会后出纪要就走离线整段处理准确率更高。我绝大多数场景是离线因为会后十分钟出结果完全够用没必要为实时性牺牲准确率。3.3 说话人分离与时间轴对齐这一步是可用和不可用的分水岭。没有说话人标注的转写读起来是一大段没有主语的独白有了标注才能看出张三提了方案、李四反对、最后折中。技术上分两块第一块是声纹分离。常见做法是用预训练的说话人分割模型对整段音频做滑窗提取每段语音的声纹嵌入向量然后做聚类——同一个人的声纹向量在空间里距离近聚成一类。这里有两个关键参数说话人数量能提前知道人数就填死比如这场是 4 个人准确率明显更高。自动估计在 3 人以上、有人中途插话的场景下容易多算或少算。最小语音时长低于 0.5 秒的片段不参与聚类否则嗯对这种短回应会制造出一堆幽灵说话人。第二块是时间轴对齐。识别输出的是词级时间戳分离输出的是说话人区间两者做区间交集def assign_speaker(word_start, word_end, segments): # segments: [(start, end, speaker), ...] 按时间排好序 best, overlap_max None, 0.0 for s, e, spk in segments: overlap max(0.0, min(word_end, e) - max(word_start, s)) if overlap overlap_max: overlap_max, best overlap, spk return best这段逻辑朴素但够用取重叠时长最大的那个说话人作为归属。实测下来90% 以上的词能正确归属剩下出错的多是两人抢话的瞬间——那部分本来人也听不清不必强求。还有一个细节值得提说话人标签要先编号再映射名字。先输出SPEAKER_00、SPEAKER_01然后在导出前统一替换成真实姓名。这么做的好处是某一次聚类错了你可以只改映射表不用重跑整条链路。3.4 摘要环节提示词模板与本地大模型参数转写稿变成纪要靠的是本地大模型。这一步的成品质量差异极大我用同一个模型、同一个提示词改了一个参数输出质量差了一倍——后面会说。先说上下文长度这个硬约束。一小时中文会议转写稿大概 8000~12000 字折算 token 大约 12000~18000。大多数本地量化模型的实际可用上下文是 4k~8k塞不进去。硬塞的结果是模型只看到开头和结尾中间全丢输出一份看起来像模像样但漏掉关键决策的纪要——这比不写还危险。我的解法是两段式分块抽取按话题或按 10 分钟切块每块单独跑一次抽取结论/待办/争议点输出结构化的小片段。汇总合并把所有小片段这时候总量小得多合成一份完整提示词再跑一次去重、合并、按主题归类。分块的切点我按 VAD 的静音边界找优先在长静音处切其次按时间均分。这个细节决定了抽取质量——在句子中间切开模型会读到一个断头的句子抽出错误结论。提示词模板我用的是这一版你可以直接抄你是会议纪要整理助手。以下是会议转写稿的一部分说话人已标注。 任务 1. 提取【结论】已经达成一致的决定只写确定的事不要写讨论了。 2. 提取【待办】包含负责人和时间点若原文未提及负责人写待定。 3. 提取【分歧】明确有人反对或未达成一致的点。 4. 提取【风险】被提到但未展开的隐患。 要求 - 每条不超过 40 字用原文表述不要自行推断。 - 原文没有的信息一律写未提及禁止编造。 - 输出用 Markdown 列表不要写引言和总结。 转写稿 {transcript_chunk}这个模板里最有用的一句是原文没有的信息一律写未提及禁止编造。本地小模型在信息缺失时非常爱合理补全把下周再定补成下周三定这种错误在纪要里是致命的。采样参数方面我固定用temperature0.2、top_p0.9摘要任务不需要创造性温度高了就开始自由发挥。这里就是我前面说的那个改一个参数差一倍的地方——我早期用默认温度 0.8输出全是漂亮但空泛的套话降到 0.2 之后才开始出干货。4. 实操全流程一场两小时会议的完整跑通记录这一节我把上周的一场两小时评审会的真实操作过程记下来参数都是实际用的。4.1 首次配置把参数一次性写进配置文件命令行敲参数敲两次就会烦所以我全部落到一个 YAML 里。这份配置是我目前用的版本注释里写了每个值的来由audio: sample_rate: 16000 # 与模型训练规格一致别改 channels: 1 vad_threshold: 0.5 # 语音概率阈值环境嘈杂调到 0.6 min_silence_ms: 300 # 静音超过 300ms 认为一句结束 min_speech_ms: 250 # 短于此视为噪声 max_segment_sec: 25 # 留 5 秒余量给 30 秒窗口 asr: model: medium # 日常档重要会换 large-v3 compute_type: int8_float16 # 显存紧张时用实测准确率损失很小 language: zh beam_size: 5 initial_prompt: 以下是普通话会议记录涉及产品评审、排期、接口联调。 # 热词注入 diarization: enabled: true num_speakers: 4 # 已知人数就填死自动估计容易飘 min_segment_sec: 0.5 summary: model: qwen2.5:7b-instruct temperature: 0.2 top_p: 0.9 chunk_minutes: 10 # 按 10 分钟一块做抽取 max_tokens: 1024 output: dir: ./meetings/2025-xx-xx-review format: [md, json]几个值的来由值得单独说compute_type: int8_float16这个量化档位我在 medium 上做过对比相对 fp16速度快约 2.2 倍显存占用降到一半多中文准确率的差距在我的测试样本上是 1~2 个百分点。除非是特别重要的会否则我认为这个交换值得。initial_prompt这个字段很多人忽略它是热词注入最便宜的入口。把这场会会出现的专有名词、项目代号、人名写进去能显著减少同音错字。我的做法是每次会前花一分钟更新这一行。beam_size: 5是默认值。调到 8 会更准一点但更慢调到 1 会快但错字变多。5 是平衡点。4.2 会议进行中的监控与干预会议进行时我不做转写只做两件事监录音量和记时间点。录音量很简单隔一会儿瞄一眼电平表如果发现某个人的电平一直很低有人离麦太远、或者习惯性小声中间休息时就提醒一句。这个动作能救回 30% 的识别错误比任何后处理都有效。记时间点更关键会上出现重要决策、数字、专有名词时我随手在记事本上记一个大概时间比如1:12:30 定了 Q3 只做两个模块。会后校对时我直接跳到这些位置逐字核对。这两小时的会议我只精校这五六个关键点其他段落接受 95% 的准确率。这是我认为最值得分享的一条工作方法——不要试图把转写稿校到 100%那是不划算的把关键结论校到 100%其余够读就行。另一个经验如果条件允许会后再补录一段 30 秒的口头总结自己对着麦克风说这场会定了三件事一是……二是……三是……。这段自述的识别准确率极高单人、近场、吐字清楚可以直接作为摘要的锚点让模型不至于跑偏。4.3 会后处理校对、导出与归档会后的完整流程我拆成五步全程大概 15 分钟两小时会议第一步跑识别与分离。这条命令是串起来的python -m meetily.transcribe \ --input ./audio/review.m4a \ --config ./config.yaml \ --out ./meetings/2025-xx-xx-review两小时音频、medium、int8、单张中端显卡实测跑了 11 分钟其中识别约 7 分钟、分离约 4 分钟。这个比例挺典型分离往往比识别还慢因为它要做滑窗和聚类。第二步看质量报告。好的流程会输出一份自检信息我关注三个数识别出的总字数、平均置信度、被判定为静音的时长占比。如果静音占比超过 45%说明录音有问题或者麦克风没收到多少人声如果平均置信度明显偏低先怀疑采样率和噪声别急着换大模型。第三步按时间点精校。打开 Markdown直接搜索我会上记的那几个时间点对应的关键词逐句核对。数字、人名、项目代号这三类是重灾区必须逐个确认。第四步生成纪要。跑摘要python -m meetily.summarize \ --transcript ./meetings/2025-xx-xx-review/transcript.md \ --template ./templates/review.md \ --out ./meetings/2025-xx-xx-review/minutes.md出来之后我一定会做一件事把纪要里的每一条待办回到转写稿里 grep 一遍原文。模型编造待办的情况我遇到过不止一次尤其是负责人这一栏它会从上下文里抓一个最近出现的人名填上去。花三分钟验一遍能避免会上没说的事被写进纪要。第五步归档。我的归档结构是这样的一年下来也不乱meetings/ 2025/ 2025-03-review-q3-plan/ audio.wav # 原始音频可压但不建议删 transcript.md # 带时间戳和说话人的转写稿 transcript.json # 结构化数据便于二次处理 minutes.md # 最终纪要 actions.csv # 待办清单单独一份便于汇总actions.csv这一份是我后来加的格式就四列事项,负责人,截止时间,来源会议。攒够一个月把它导进表格按负责人透视一下谁身上压了七件事一目了然。这个小动作的价值超出会议记录本身。5. 常见问题与排查速查表这一节是我半年下来攒的问题库按现象分类遇到问题直接查表。5.1 转写质量类现象最可能的原因排查动作解决整段输出乱码或重复同一句音频全静音或全是噪声用播放器听原音频检查麦克风是否静音、增益是否为 0中文里夹杂繁体或英文语言未指定或指定错误看配置里的 language固定zh并在 initial_prompt 里给中文样例专业名词频繁写错缺少热词引导对比错字是否集中在固定几个词写进 initial_prompt或在后处理做固定替换表句首句尾频繁缺字VAD 切太紧看转写稿是否句句断头段首尾各留 0.2 秒余量长句被切成两半且语义断裂最大段长设太小检查 max_segment_sec调到 25 秒或按静音优先切数字、金额识别错模型对数字不敏感抽查含数字段落会后必校或在提示词里要求数字保留原文写法说话人标签来回跳聚类不稳定、短片段太多看是否在抢话处跳固定 num_speakers提高 min_segment_sec 到 0.8这张表里我最想强调句首句尾缺字这一条。它太隐蔽了——你读转写稿觉得通顺但实际少了一两个字语义就变了比如这个方案不用改变成这个方案用改。这类错误靠通读发现不了只能靠对照音频抽查。我的习惯是每场会随机抽三段各 20 秒边听边对能抓出大部分切分问题。5.2 性能与资源类显存爆了怎么办按这个顺序降先开量化int8_float16再降模型档位large→medium再降 beam_size5→3最后才考虑分批处理。不要一上来就降模型量化带来的损失通常比降档小。跑得比预期慢很多先确认真的在用 GPU跑一句nvidia-smi看有没有 python 进程占着显存。我遇到过装了 GPU 版 torch 但实际跑 CPU 的情况原因是环境变量把设备固定成了 cpu白等了一小时。分离阶段特别慢分离模型对长音频是滑窗处理两小时音频做分离跑四五分钟很正常。如果明显更慢检查是不是在 CPU 上跑——分离模型换到 GPU 通常能快 3~5 倍。磁盘涨得飞快别只删音频transcript.json里的词级时间戳也很占地方一场两小时的会大概几 MB 到十几 MB。我的策略是音频保留三个月转写稿和纪要永久保留。5.3 稳定性与数据类中途崩溃了要重跑全程吗不用。好的实现会把中间结果落盘切片列表、已完成的段落转写崩溃后能从断点续跑。如果没有这个能力我建议你自己在流程里加一步每处理完一个切片就把结果 append 到一个 jsonl 文件里。这十几行代码能省下无数次重跑。数据安全这块要注意什么本地方案的核心优势就是数据不外流但有两件事仍然要做一是确认所有模型都是本地加载不存在首次启动时联网拉取的情况有些实现会做模型校验二是定期清理临时目录切片音频和中间结果经常会散落在/tmp里忘了删就是一份完整录音躺在临时文件夹。一句提醒本地不等于自动安全。硬盘没加密、共享目录权限开着、临时文件不清理这几种情况下本地的意义会打不少折扣。模型更新了要不要跟我的做法是主力环境不追新另建一个测试环境试用。语音识别模型换版本后输出格式、标点风格、时间戳粒度都可能变而你下游的对齐脚本、摘要模板是按旧格式调的。追新之前先在测试环境跑同一段音频对比输出差异确认无碍再换。6. 进阶把单机工具变成可复用的流程链路跑通只是开始真正让它有价值的是把它变成肌肉记忆一样的流程。6.1 术语表与热词注入这是我投入产出比最高的一项优化。做法很土建一个glossary.csv三列——正确写法, 常见误写, 备注。每次校对发现错字就加一行。正确写法,常见误写,备注 星轨计划,新鬼计划/星鬼计划,内部项目代号 联调窗口,联调窗口期/连调窗口,排期术语 灰度放量,灰度方量/辉度放量,发布术语攒到一百多条之后我做了两件事一是把正确写法拼成字符串塞进initial_prompt受长度限制只放最高频的三十个二是在转写完成后跑一遍正则替换把误写统一改正。两道防线下来专有名词错误率从我早期的大约每千字五六个降到每千字不到一个。这一步的价值不止于准确率。术语表其实是团队知识的沉淀——新同事拿到这份表比读十份文档更快搞懂大家在说什么。6.2 模板化输出与二次加工不同会议的纪要长得不该一样。我准备了几个模板决策评审会结论 / 分歧 / 待办 / 风险四块不写讨论过程。周会按人分块每人本周完成 / 下周计划 / 阻塞项。用户访谈按主题聚合原话引用保留语气不做归纳。复盘会时间线 / 根因 / 改进项改进项必须带负责人。模板本质上是给模型的输出约束。同一个转写稿用决策评审模板和访谈模板跑出来完全是两份东西。这也是本地方案的优势——模板随便改改完重跑不要钱。二次加工我常用一个偷懒的办法把transcript.json里的说话人维度聚合一下统计每个人的发言时长和发言次数。这个数据放在周会上意外地有用能看出谁一直在说、谁一直没说比凭感觉判断靠谱得多。6.3 我这套流程的边界在哪用了半年我清楚它哪儿不行说清楚比吹有用。多人抢话的场景基本无解。三个人同时说话分离模型会把整段判给音量最大的那个转写出来也是一团糊。这种会我的做法是会后单独找人补一句口述。强口音加快速连读准确率会掉到七成以下。这时候别硬调参数调不动直接上 large-v3 加人工校对更省时间。它不会替你判断。模型能抽出张三说这个方案有风险但它判断不了这个风险重不重要、要不要写进最终纪要。这一层始终是人干的活也是这份活里唯一没法自动化的部分。我现在对它的定位很清楚它是一个永不疲倦的记录员负责把说过的话一字不落地留下来、按人分好、按主题归好我负责决定哪些话值得留下。这个分工定下来之后我对它的容错度高了很多——它把下周听成这周我改一下就行它要是把整个决策漏了我会发现问题就出在我的校对环节上跟模型无关。最后分享一个小习惯每次会前我会把这套流程的耗时在心里过一遍——两小时的会识别分离 11 分钟校对 10 分钟摘要 3 分钟验待办 3 分钟。加起来不到半小时。而我手工整理一场两小时的会最快也要两小时。这个账算清楚之后你就知道该在哪个环节省时间、哪个环节别省。我踩过的坑基本都是想在校对这一环省时间结果每次都要返工。
全面解析：从发育机制到临床转化)
