两小时的会议录音文件拖出来一看播放时长 1 小时 58 分。放在以前我的处理流程是这样的先完整听一遍边听边在文档里敲关键词遇到重点再倒回去重听确认最后整理成纪要再手动把里面提到的待办一条条摘出来分派到对应的负责人。整个过程下来三个小时打底而且听完第二遍的时候脑子已经有点糊了漏掉一两项待办是常有的事。这次我换了个思路用 WorkBuddy 把这段录音直接跑成结构化纪要和待办清单。从上传音频到拿到可用的输出前后不到二十分钟其中大部分时间还是在等转写跑完。这篇文章就把我这次实操的完整过程拆开讲清楚——包括我怎么设计提示词、怎么处理转写里的口语噪音、怎么让待办输出直接对接飞书待办接口、以及中间踩过的几个坑。如果你也是经常要处理会议纪要的人不管是团队负责人、项目经理还是行政岗这套流程可以直接抄作业。1. 为什么我没有直接用会议软件的自动纪要先说一个很多人会问的问题现在很多会议软件本身就带自动转写和纪要功能为什么还要多此一举用 WorkBuddy 再处理一遍我实测下来的感受是会议软件自带的转写解决的是把声音变成文字这一步但纪要的核心价值不在于文字本身而在于信息的结构化重组。一场两小时的会议转写出来可能是一万五千字左右的文本里面夹杂着大量的口语重复、跑题讨论、语气词、多人抢话导致的断句混乱。你拿到的是一坨原始文本而不是一份能直接发给团队的东西。会议软件自带的智能纪要通常做的是抽取式摘要——从原文里挑几句看起来重要的话拼在一起。这种做法的问题在于它不理解会议的决策链条。比如会上讨论了三套方案最后拍板选了 B 方案附带两个前提条件这种讨论过程 最终决策 附加条件的结构抽取式摘要是还原不出来的。WorkBuddy 这类工具的价值在于它可以按照你定义的输出结构对整段文本做生成式重组。你可以告诉它我要的不是摘要我要的是决议事项、待办清单、风险点、下次会议议题这四个板块每个板块按什么格式输出。这才是纪要和摘要的本质区别。另外还有一个现实原因会议软件的纪要功能往往绑定在特定的会议平台上如果我的会议是在线下开的或者用的是别的录音设备那套功能就用不上。而 WorkBuddy 处理的是音频文件本身来源不限这一点灵活性对我来说很重要。1.1 结构化纪要和普通摘要的本质差异我把这两种输出的差异整理成了一张表方便你判断自己到底需要哪一种维度普通摘要结构化纪要输出形态一段或几段连续文字分板块、带层级的结构化内容信息取舍按重要性抽取原句按预设框架重组信息待办处理混在正文里需要人工摘独立成清单带负责人和时限可追溯性弱不知道结论从哪来强可关联到讨论段落直接可用性需要二次加工基本可直接分发这张表里最关键的一行是待办处理。我见过太多团队会议开得挺好纪要也发了但待办事项散落在纪要正文的各个角落没人认领下次开会一问全都没动。把待办独立成清单并且明确负责人和时间节点这是让会议真正产生行动的关键一步。1.2 WorkBuddy 在这条链路里扮演的角色需要说清楚的是WorkBuddy 不是一个会议纪要专用工具它更像是一个能理解你指令、能调用各种能力来完成任务的工作助手。转写只是它的能力之一真正让它区别于普通转写工具的是它的指令理解和任务编排能力。我这次用到的能力链路是这样的音频转写 → 文本清洗 → 按框架重组 → 生成待办 → 对接飞书待办接口。这条链路里转写是基础能力后面的每一步都是通过自定义指令来驱动的。这也是为什么我在文章里会花不少篇幅讲提示词设计——因为同样的转写文本指令写得好不好输出质量差距非常大。提示如果你只是偶尔需要把一段录音变成文字用任何转写工具都行。但如果你需要的是能直接用的会议产出物那重点应该放在后处理环节的指令设计上而不是纠结转写准确率那百分之几的差异。2. 从音频到文本转写环节的实操细节这一节讲转写本身。虽然转写是整条链路里最自动化的一步但有几个细节如果没处理好后面所有环节都会受影响。2.1 音频预处理别跳过这一步我拿到的原始录音是会议室的录音笔导出的格式是 WAV采样率 44.1kHz双声道文件大小接近 200MB。直接上传也能跑但我做了两步预处理效果明显更好。第一步是降采样和转单声道。会议录音里人声的有效频率范围大概在 300Hz 到 3400Hz 之间44.1kHz 的采样率对语音转写来说是浪费。我用 ffmpeg 把它转成了 16kHz 单声道ffmpeg -i meeting_raw.wav -ar 16000 -ac 1 -c:a pcm_s16le meeting_16k.wav这一步把文件从 200MB 压到了 70MB 左右上传速度快了不少转写准确率我对比下来没有明显差异。16kHz 是语音转写领域的常用采样率绝大多数转写引擎在这个采样率下表现最好。第二步是音量归一化。会议室录音有个常见问题离麦克风近的人声音很大远的人声音很小。我用了 ffmpeg 的 loudnorm 滤镜做了一次响度归一化ffmpeg -i meeting_16k.wav -af loudnormI-16:TP-1.5:LRA11 -ar 16000 meeting_norm.wav参数里的I-16是目标响度单位 LUFSTP-1.5是最大真峰值LRA11是响度范围。这套参数是广播行业常用的标准用在会议录音上效果不错能让远场说话人的声音也清晰可辨。注意如果你的录音本身底噪很大比如空调声、键盘声建议先做一次降噪再归一化。我这次录音质量还行就跳过了降噪。降噪做过头会导致人声失真反而降低转写准确率这个度要把握好。2.2 转写参数怎么设说话人分离是关键WorkBuddy 的转写环节我关注的核心参数是说话人分离speaker diarization。两小时的会议如果转写出来是一整段没有区分的文字后面做纪要的时候根本分不清谁说的待办也没法指派给具体的人。我这次会议一共 6 个人参与我在转写配置里把说话人数量设成了 6。这里有个经验宁可多设一个不要少设。如果实际是 6 个人但你设了 4 个转写引擎会把两个人的话合并到同一个说话人标签下后面很难拆开。如果设多了最多是出现一个空的说话人标签不影响使用。转写完成后我拿到的输出大概是这个样子的[00:03:12] 说话人1: 那我们先过一下上周的进度小李你那边... [00:03:45] 说话人2: 上周主要是把接口联调做完了但是... [00:04:20] 说话人1: 等一下你说的这个接口是哪个接口带时间戳和说话人标签的格式对后面做纪要和待办追溯非常关键。我在指令里明确要求保留时间戳这样纪要里每条待办都能标注来自 00:47:30 的讨论方便回溯。2.3 转写文本的清洗口语噪音怎么处理两小时的会议转写出来大概一万六千字里面充斥着口语噪音。我统计了一下主要有这么几类语气词和填充词嗯那个就是说对对对这类词占了大概 8% 的篇幅重复和改口我们下周不对是下周三下周三之前把这个东西弄完跑题段落中间有大概十分钟在聊周末团建的事跟会议主题无关多人抢话导致的断句转写引擎在多人同时说话时会把句子切得很碎这些噪音如果不处理直接丢给后面的重组环节会严重影响输出质量。我的处理方式是在指令里加一段清洗规则而不是手动去删。手动删一万六千字那还不如自己写纪要。我在指令里是这样写的转写文本中可能包含语气词、重复表述、跑题内容。请在生成纪要前先做一次清洗删除无意义的语气词和填充词将重复改口的表述合并为最终版本识别并剔除与会议主题无关的闲聊段落但保留其中提到的任何待办或决议。这里有个细节值得说跑题段落里有时候藏着待办。比如聊团建的时候有人说对了团建那个场地你记得订一下这其实是一条待办。所以我在指令里特别强调了保留其中提到的任何待办或决议避免清洗的时候把有用信息一起删掉。3. 指令设计让 WorkBuddy 输出我要的纪要结构这是整篇文章最核心的部分。转写只是把声音变成文字真正决定输出质量的是指令设计。我前后改了四版指令才拿到满意的输出。3.1 第一版指令的失败输出太聪明了我第一版指令写得很简单请把这份会议转写整理成会议纪要。结果 WorkBuddy 给我的输出是一篇八百字的流畅文章读起来很顺但完全没有结构。决议、待办、讨论过程混在一起待办事项散落在段落中间我需要再读一遍才能把待办摘出来。这等于把人工摘待办的活儿又还给我了。问题出在哪儿我给了任务但没给输出结构。WorkBuddy 不知道我要的是分板块的结构化内容它默认按写一篇通顺的纪要来理解于是产出了一篇散文式的纪要。3.2 第二版定义输出框架第二版我加上了输出框架请按以下结构输出会议纪要 一、会议基本信息 二、核心决议 三、待办事项 四、风险与待确认事项 五、下次会议议题这一版好多了至少有了板块划分。但还是有问题待办事项那一块它只写了完成接口联调确认场地这种短语没有负责人没有时间节点。而会上其实是明确说了小李负责下周三之前的。我意识到光给框架不够还要给每个板块的字段定义。3.3 第三版给每个字段定义格式第三版我在待办板块加了字段要求三、待办事项 每条待办按以下格式输出事项[具体要做什么]负责人[会上明确指派的负责人如果没明确写待指派]截止时间[会上提到的时间节点如果没提到写待确认]来源[对应的时间戳]这一版输出就基本可用了。待办清单变成了这样- 事项完成支付接口的联调测试 负责人小李 截止时间下周三具体日期需确认 来源[00:47:30]有了负责人和时间节点这份待办清单就可以直接分发出去了。3.4 第四版加入判断规则和边界处理第三版还有个问题会上有些讨论是可能要做但没定下来的WorkBuddy 把它们也当成待办列进去了。比如有人说我们要不要考虑一下做个灰度发布这只是一个提议不是决议。但它被列进了待办清单。第四版我加了判断规则判断一条内容是否为待办的标准会上有明确的行动指向且有人认领或即将认领。仅仅是提议、讨论、假设性表述如要不要可以考虑如果……的话不算待办应归入风险与待确认事项板块。同时我还加了边界处理规则如果转写文本中某段内容含义模糊、无法确定是否为决议或待办不要猜测将其原文摘录放入待确认事项并标注时间戳。这两条规则加上之后输出的准确度明显提升。指令设计的核心不是写得长而是把判断标准写清楚。你告诉它什么算待办比告诉它帮我找待办有用得多。3.5 完整指令模板把我最终用的指令模板整理出来你可以直接改改就用你是一个专业的会议纪要整理助手。以下是一场两小时会议的转写文本包含时间戳和说话人标签。 请完成以下任务 第一步清洗文本删除语气词和填充词合并重复改口的表述剔除与会议主题无关的闲聊但保留其中提到的待办或决议。 第二步按以下结构输出纪要 一、会议基本信息 - 会议主题从内容推断 - 参会人数 - 会议时长 二、核心决议 每条决议包含决议内容、决策依据简要、时间戳 三、待办事项 每条待办包含事项、负责人、截止时间、来源时间戳 判断标准有明确行动指向且有人认领。提议和假设性表述不算待办。 四、风险与待确认事项 包含未定论的讨论、需要进一步确认的信息、潜在风险点 五、下次会议议题 从讨论中提取需要跟进的话题 第三步对于含义模糊、无法确定的内容不要猜测原文摘录放入待确认事项并标注时间戳。这套模板我用了三次输出质量都很稳定。你可以根据自己的会议类型调整板块比如项目复盘会可以加一个经验教训板块需求评审会可以加一个需求变更记录板块。4. 待办清单对接飞书待办接口纪要和待办生成出来之后如果还要手动一条条录入到飞书待办里那自动化就断在了最后一步。这一节讲怎么把 WorkBuddy 生成的待办清单直接推到飞书待办。4.1 飞书待办接口的基本调用逻辑飞书待办Task的开放接口核心是创建一个任务需要传这几个关键字段summary任务标题、due截止时间、members负责人、description任务描述。调用前需要先拿到tenant_access_token这个 token 是通过应用的app_id和app_secret换取的。整个流程分两步第一步获取 tokencurl -X POST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal \ -H Content-Type: application/json \ -d { app_id: your_app_id, app_secret: your_app_secret }返回里会有tenant_access_token有效期两小时够用了。第二步创建任务curl -X POST https://open.feishu.cn/open-apis/task/v2/tasks \ -H Authorization: Bearer your_tenant_access_token \ -H Content-Type: application/json \ -d { summary: 完成支付接口的联调测试, description: 来源00:47:30 的会议讨论, due: { timestamp: 1700000000, is_all_day: false }, members: [ { id: ou_xxx, type: user } ] }这里的members里的id是用户的 open_id需要提前把会议参与人的名字映射到 open_id。这个映射关系可以维护一张表或者通过飞书的通讯录接口按名字查询。4.2 让 WorkBuddy 直接输出可调用的 JSON与其让 WorkBuddy 输出人类可读的待办清单再写脚本去解析不如让它直接输出符合飞书接口格式的 JSON。我在指令最后加了一段待办事项板块除了人类可读的格式外请额外输出一份 JSON 数组每个元素包含 summary、description、due_timestamp、assignee_name 四个字段。due_timestamp 如果会上没有明确时间设为 null。这样 WorkBuddy 会同时给我两份输出一份给人看的纪要一份给程序用的 JSON。我拿 JSON 直接跑一个脚本批量创建任务就行。这里有个坑要注意会上说的时间往往是下周三这种相对时间需要转换成绝对时间戳。我在指令里加了一条会议日期为 2024 年 X 月 X 日。请将所有相对时间表述如下周三这周五月底前转换为绝对日期格式为 YYYY-MM-DD。如果不加这条WorkBuddy 输出的 due_timestamp 会是 null 或者错误的日期。加上之后它会把下周三正确换算成具体日期。4.3 负责人名字到 open_id 的映射这是整个对接环节里最麻烦的一步。会上说的是小李老王这种称呼而飞书接口要的是 open_id。我的处理方式是维护一张映射表会上称呼飞书姓名open_id小李李某某ou_aaa老王王某某ou_bbb张总张某某ou_ccc这张表我放在一个 JSON 文件里脚本读取 JSON 后用assignee_name去查表查到就填 open_id查不到就跳过并在日志里记一笔提醒我手动处理。提示如果你们团队人员流动频繁这张映射表建议从飞书通讯录接口动态拉取而不是硬编码。我目前团队比较稳定就先用静态表了每季度更新一次。4.4 批量创建的脚本把上面几步串起来就是一个批量创建待办的脚本。核心逻辑是读 JSON → 查映射表 → 调接口 → 记录结果。import json import requests TOKEN your_tenant_access_token MAPPING json.load(open(member_mapping.json)) def create_task(item): assignee MAPPING.get(item[assignee_name]) if not assignee: print(f未找到负责人映射{item[assignee_name]}) return False payload { summary: item[summary], description: item[description], members: [{id: assignee, type: user}] } if item.get(due_timestamp): payload[due] {timestamp: str(item[due_timestamp]), is_all_day: False} resp requests.post( https://open.feishu.cn/open-apis/task/v2/tasks, headers{Authorization: fBearer {TOKEN}, Content-Type: application/json}, jsonpayload ) return resp.status_code 200 tasks json.load(open(todos.json)) for t in tasks: ok create_task(t) print(f{成功 if ok else 失败}{t[summary]})跑完这个脚本待办就全部进飞书了负责人会收到通知。从录音到待办进系统全程不需要手动录入。5. 实测中踩到的坑和应对方式这一节讲我实操过程中遇到的问题。有些是 WorkBuddy 本身的特性导致的有些是流程设计上的疏忽。我把排查过程也写出来方便你遇到类似问题时参考。5.1 转写把专业术语识别错了我们会上讨论了不少技术术语转写出来有几个明显的错误。比如灰度发布被转成了灰度发不幂等被转成了密等。这种错误如果只是出现在纪要正文里影响不大但如果出现在待办事项里就会导致执行的人看不懂。我的应对方式是在指令里加一段术语校正表以下术语在转写中可能被错误识别请在处理时统一校正灰度发不 → 灰度发布密等 → 幂等熔断 → 熔断确认未被误识别这个校正表需要你根据自己团队的常用术语来维护。第一次用的时候可能发现不了问题跑几次之后把常见的错误积累下来后面就越来越准。5.2 说话人标签错乱导致待办指派错误有一次转写把两个人的话合并到了同一个说话人标签下导致一条本该是张三的待办被指派给了李四。这种错误比较隐蔽因为转写文本读起来是通顺的只有对照录音才能发现。我的应对方式是双重确认WorkBuddy 生成待办后我会快速扫一遍待办清单里的负责人对照我记忆中的会议情况做一次核对。如果发现可疑的指派就回到对应时间戳去听一下原录音确认。另外我在指令里加了一条如果某条待办的负责人无法从说话人标签明确判断标注为待确认不要根据上下文猜测。宁可标待确认让我手动补也不要猜错了导致待办派错人。5.3 长音频转写超时我第一次跑的时候直接把 200MB 的原始文件丢进去结果转写跑到一半超时了。后来我做了前面说的音频预处理把文件压到 70MB就顺利跑完了。如果你手上的录音更长比如三四个小时的建议分段处理。按每 30 分钟切一段分别转写最后再合并。分段的时候注意在静音处切不要在句子中间切否则会导致断句错误。ffmpeg -i meeting_norm.wav -f segment -segment_time 1800 -c copy part_%03d.wav这条命令会把音频按 30 分钟一段切开。切完之后逐段转写最后把转写文本按顺序拼接起来。5.4 待办去重两小时的会议同一个待办可能被提到好几次。比如接口联调这件事开头提了一次中间又提了一次结尾还确认了一次。如果不去重待办清单里会出现三条一样的任务。我在指令里加了去重规则如果同一事项在会议中被多次提及合并为一条待办取最后一次提到的时间节点作为截止时间来源时间戳取第一次提及的位置。这条规则加上之后待办清单干净了很多。不过要注意有些看起来相似的事项其实是不同的比如接口联调和接口文档更新是两件事不能合并。这个判断 WorkBuddy 做得还不错我抽查了几次没有发现误合并。5.5 输出格式的稳定性WorkBuddy 的输出格式偶尔会有波动。同样的指令有时候待办清单用的是无序列表有时候用的是有序列表有时候字段顺序会变。这对人类阅读影响不大但对程序解析有影响。我的应对方式是在指令里明确指定输出格式并且要求 JSON 部分用代码块包裹JSON 数组请用 json 代码块包裹确保格式严格符合 JSON 规范不要添加注释。这样脚本解析的时候我只需要提取代码块内容就行不用处理格式波动。6. 这套流程的适用边界和扩展方向讲完了实操最后说说这套流程适合什么场景、不适合什么场景以及还能往哪些方向扩展。6.1 什么会议适合用这套流程我实测下来这套流程最适合的是决策型会议——就是那种开会目的是做决定、分任务的会议比如项目周会、需求评审会、复盘会。这类会议有明确的决议和待办结构化输出的价值最大。不太适合的是创意发散型会议比如头脑风暴。这类会议的产出是一堆零散的想法没有明确的决议和待办硬套结构化框架反而会丢失信息。这种会议我建议还是用传统的记录方式或者只做转写不做结构化。另外一对一沟通也不太适合。两个人的对话信息密度低待办往往就一两条用这套流程有点杀鸡用牛刀。6.2 转写准确率的现实预期要说清楚一点没有任何转写工具的准确率是 100%。我这次实测下来转写的字面准确率大概在 95% 左右也就是说一万六千字里大概有八百字的错误。这些错误大部分是语气词和重复表述的识别问题对纪要影响不大但专业术语和数字的识别错误需要重点关注。我的建议是纪要生成后重点核对三类信息——人名、数字、专业术语。这三类信息出错的影响最大其他地方的错误可以容忍。6.3 可以扩展的方向这套流程跑通之后我还在尝试几个扩展方向。一个是把纪要自动同步到知识库。每次会议的纪要按日期归档形成一个可搜索的会议知识库。后面要查上次讨论这个方案是什么时候直接搜就行。另一个是待办完成情况的自动追踪。通过飞书待办接口定期拉取任务状态在下次会议前生成一份上次待办完成情况的报告会上直接过。这样会议的开场环节就不用花时间问上次那些事做得怎么样了。还有一个是多语言会议的处理。我们团队偶尔有英文会议WorkBuddy 的转写支持多语言但指令里的判断规则需要针对英文会议做调整比如英文里的action item和中文的待办判断标准不太一样。这个我还在摸索等跑顺了再单独写一篇。提示扩展的时候建议一步一步来先把核心链路跑稳定再往上加功能。我一开始想一次性把知识库同步和待办追踪都做了结果调试成本太高后来拆成三步走反而更快。这套流程我用了大概两个月处理了十几次会议目前已经成了我们团队开会的标准动作。最大的感受是会议纪要这件事难点从来不在记录而在结构化和行动化。把这两步交给合适的工具和指令去完成人只需要做最后的核对和判断效率提升是实实在在的。