1.1 人工纪要的三个槽点：慢、漏、没人愿意干

老板跟我说“能不能搞个自动的”那天，我正在翻上周三场例会的纪要。准确地说，是在翻三份半成品：一份只写了标题和参会人，一份记到一半跑去改 Bug，还有一份是会后第二天凭记忆补的，关键决议写成了“大家商量了一下”。

这就是我们公司纪要的现状。一个二十来人的团队，每周三次例会加无数项目会，会议室永远在抢，纪要永远没人写。我是全栈开发兼半个 IT，这种“不紧急但每个人都被它折磨”的活，最后都会落到我头上。所以在动手写任何代码之前，我先把人工纪要到底有多痛，一条一条列了出来——做内部工具最怕凭着感觉下手，需求没拆清楚，做出来的东西同事只会更嫌弃。

三个槽点：慢、漏、没人愿意干

我把过去一个月收集到的反馈整理成一张对照表，槽点、表现、后果和量化影响一目了然：

先说慢。一场一小时的会，两个人对着录音回放整理，最快也要一个多小时——因为录音不能快进着听，快进了就听不清谁说了什么。更多时候整理纪要的时间比开会本身还长，而这段时间本来可以用来写代码。慢的根本原因不是人懒，而是音频这个介质对人极其不友好：它是线性的、不可检索的，想确认一句“下周前完成接口联调”到底是谁说的、上下文是什么，只能把整段重听一遍。我统计过自己一次，找一句话平均要回放三分钟，一场会下来光定位信息就用掉四十分钟。

再说漏。多人会议里说话人是穿插的，记笔记的人注意力一断，某段讨论就只剩半句。最典型的一次是产品评审，三个候选方案讨论了二十分钟，纪要里只留下“采用方案二”，为什么选方案二、谁提的条件，全没有。后面新人入职翻纪要，看不懂，又拉着老人开了一次会复盘——一次纪要没记好，衍生出又一场会。

漏还有一种更隐蔽的形式：漏掉的是“反对意见”。会上有人对某个方案表达了保留，纪要图的省事往往只写最终结论，反对意见和折中过程被抹掉。三个月后项目遇到问题，大家翻纪要发现结论里毫无线索，才想起当时其实有人提醒过风险。从那以后我定了个规矩，纪要里必须保留“少数派意见”一栏，但靠人工坚持了半个月就放弃了——会议节奏一快，谁还记得那些没有形成结论的话。这件事后来直接促成了我们保留逐字稿的决定：机器记不下结论，但能把所有过程都留下来，结论让算法去提炼，过程不丢就行。

最要命的是没人愿意干。纪要这件事天然吃力不讨好：写好了没人夸，写漏了第一个被问责。我们试过轮值，四个轮值人三个拖延，最后一个永远是我。管理上这叫公共地悲剧，大家都需要纪要，但没有人愿意当那个写纪要的人。还有一个隐蔽成本：写纪要的人为了不在会上漏掉内容，会下意识少发言、少争论——这件事在我们团队最内向的几个工程师身上特别明显，等纪要轮到他们，整场讨论都变安静了。也就是说，人工纪要不只浪费整理的时间，还在悄悄压低会议本身的质量。

一周会议统计：数据比感觉更扎心

为了说服老板投入开发资源，我统计了我们公司某一周的真实会议情况：

这一周合计 8 小时会议，只有两场出了合格纪要，还有一场只有录音躺在某人硬盘里。老板看完表格说，怪不得上周两个待办没人跟。我说不是大家不负责任，是流程本身就反人类：会议是同步的高密度信息，纪要却要求人在信息最疲惫的时候做整理归档。

我们试过的土办法，和它们怎么失效的

在做自动化之前，我们其实已经折腾过三轮“管理手段”，每一轮都坚持不过三周：

轮值那轮最有戏剧性。值日表贴在墙上第一周，大家还很积极；第二周开始有人“忘了”；第三周某个周三的评审会，纪要栏写的是“详见群聊天记录”。老板一拍桌子：既然管理手段治不好这病，就上技术手段。

回过头看，这三轮失败指向同一个事实：纪要的难点不在“写”这个动作，而在于它要在会议结束后、大家注意力已经切换到下一件事的时候，额外消耗一小时高密度的脑力。任何依赖意志力的方案都会失效，因为意志力本身就是最稀缺的资源。真正有效的办法只有两个：要么把纪要变成会上当场完成的小动作，要么把它彻底自动化。前者需要改变所有人开会的方式，后者只需要改变我一个人——作为全栈开发，我选了后者。

纪要是管理动作，不是文书工作

想明白这一点，后面的选型就顺了。很多人把纪要当作文书工作——找个文笔好的人把会议写通顺。但我们的真实需求根本不是通顺，而是可执行：

• 决议是否被记录并传达？
• 待办是否落实到人、有截止日？
• 责任人事后能否快速回溯讨论依据？

换句话说，纪要的价值在于把一次同步的口头交流，转成一份可追溯、可跟踪的异步依据。这本质上是信息从“声音”到“结构化数据”的搬运。既然是搬运，就天然适合自动化：录音已经在那里了，转写、提取待办、归档、分发，每一步都是可重复的机械劳动。用人力做机械劳动，是对工程师最大的浪费。

基于这个认识，我给“合格纪要”定了一个硬标准，后来它成了整个工具的验收基线：

这份标准里没有一条要求文笔。反过来说，一份辞藻优美但缺了责任人和截止日的纪要，在工程团队眼里就是废纸。这也是我们后来拒绝“找个实习生专职写纪要”这种提案的原因——问题的瓶颈从来不是人力不足，而是流程中的信息损耗无法靠堆人来弥补。

我们团队后来把这套思路沉淀成了文字处理的通用方法论，具体可以参考我另一本DeepSeek 工具链实战，里面介绍了怎么用大模型把非结构化文本变成结构化字段。纪要归档与知识管理则可以看笔记知识库实战，我们的纪要最终也接进了团队的笔记库。

自动化的预期收益

动手之前我又算了一笔账，把每个环节的人工耗时和自动化后的预期做了对比：

结论很清楚：哪怕只做到半自动化，每场会也能省下一个多小时；如果全流程跑通，人只需要最后扫一眼校对。这是后来整个项目的立项依据。

除了时间，自动化还带来三个容易忽略的收益。第一是时效性：纪要可以在散会前自动生成并发到群里，趁大家记忆还热的时候核对，漏记的部分当场就被纠正了，而不必等到第二天。第二是完备性：机器不会因为走神漏掉一段，逐字稿就在那里，任何争议都可以回查原文，这比任何人的记忆都可靠。第三是边际成本趋零：多录一场会不会增加任何人的负担，于是我们敢于把十五分钟的站会也录下来——在人工时代，这种短会根本不值得花一小时去整理，很多有价值的信息就这么散掉了。

当然，自动化的前提是这些底层能力可以直接调用而不用自己造轮子。我们用的语音识别、对象存储、云函数这些，在腾讯云五件套实战里也有系统介绍，这里就不展开了。

需求梳理至此，结论就一句话：我们要做的不是一个“把语音变成文字”的演示 Demo，而是一条把会议录音自动变成可执行纪要的流水线。痛点是慢、漏、没人愿意干；目标是决议可查、待办到人、过程可回溯；手段是语音识别加结构化处理加自动分发。下一节我会把开源模型自建和云端 ASR 两条路摊开来对比，看看在二十人小团队的资源约束下，哪条路能走通。

延伸阅读

• DeepSeek 工具链实战：纪要的结构化提取如何交给大模型
• 笔记知识库实战：纪要归档与团队知识管理
• 腾讯云五件套实战：本项目用到的云服务底座