4.2 信息提取：待办、决议与发言人归集

清理完的文本通顺多了，但它终究只是一份逐字稿。同事真正关心的是三件事：会上定了什么、谁要干什么、每个人说了多少。这一节就是把清理后的文本再过一遍，提取出结构化的待办、决议和发言人归集，为 4.3 的一页纸纪要备好料。

提取有两条路：规则和大模型。我的经验是分类型用——格式强（截止日期、人名）的用规则兜底，语义强（决议、风险）的交给大模型，两者对着干不如分开用各自的长处。

这个分工也是被逼出来的。最早图省事全部走规则，结果待办漏了一大片——有人答应做事但句式根本不套模板（这个事儿我盯着），规则死活抓不到。后来全部走模型，待办倒是抓全了，人名日期又经常飘。最后才定型成现在这样：模型负责理解语义，规则负责卡位兜底，两边互相填坑。

提取的时机也有讲究。转写结果一落库就触发提取，这是最自然的节奏，但实测发现清理还没跑完就提取，准确率会掉一截——碎片句子里待办的主语经常被语气词挡着，模型分不清是谁的活。所以提取统一排在清理流水线后面，作为它的下游步骤；实时转写场景（3.2 那种开会时出字幕的）则不做自动提取，散会统一来，免得开会中途给同事发半成品纪要。

混在一起干还有一个反例：有阵子图省事把提取和清理跑在同一个任务里，清理脚本一改 bug，提取跟着全量重跑，一天的调用成本翻了几倍。拆开成上下游两个独立任务之后，谁出问题重跑谁，互不连累。

提取目标表

先定清楚提取什么、验收标准是什么。没有验收标准的提取，上线一周就会退化成没人信的玩具：

会议元信息那行看似鸡肋，其实省过事：有次会议两个项目评审撞在一起开了，全靠上传时带的会议类型参数才把两份纪要分清。详情里我们也会顺手记一句会议主题，检索纪要时比看日期直观得多。

表里最容易被忽略的是最后一列。提取准确率这东西，不挂验收标准就没人查，不查就会慢慢烂掉。我每周还会抽五条提取结果人工核一遍，记到质量台账里，连续三周某类提取命中率走低，就说明提示词或词表该调了。

待办提取格式

待办是所有提取项里价值最高的，格式我们对齐了三版才固定下来，最终长这样：

带来源时间戳这一列是点睛之笔。校对的时候有争议，点一下就能跳回原始录音的对应位置，谁也不用凭记忆吵架。相对时间（周五前、下周三）先保留原文，归档时再由校对的人确认成具体日期。

待办的粒度也有讲究。一句话可能含两件事（你先把接口联了，顺便把文档也补了），拆成两条还是留一条？我们的做法是按负责人拆——两个动作同一个负责人就合成一条，不同负责人必须拆开，不然待办就漏了。这条规则是看了一周漏派三条任务之后才加上去的。

发言人归集表

发言人归集靠的是转写结果里的说话人标签加时间戳，纯统计不花模型调用的钱：

这张表一开始只是好奇，后来发现真有用：有两次例会某个人发言量突然从 30% 掉到 3%，一问是那段时间被排开会排岔了，排会的人自己都没意识到。顺带一提，说话人标签不是每次都准，参会人变动大的时候需要人工标一次映射表，之后就能复用。

发言量数据还能反向验证归并质量。有阵子某人的发言量异常高，查发现是归并算法把他和邻座的话并到一起了，回去调了清理规则。统计表不只是给人看的管理视角，也是整套流水线的健康监测计。

待办之间还有个去重的问题。同一个人在会上三次提到同一件事（先说下周做，中间又补充了一下，结尾再强调一遍），提取出来就是三条待办。我们的规则是按负责人加任务关键词做一轮聚合，把三次说法并成一条，来源时间戳取第一次提及。不做这一步，待办列表会越提越长，最后谁也不想看。

去重的力度也踩过分寸：聚合太狠会把两件名字像、但完全不同的事情并成一条，比如跟进登录页改版和跟进登录接口联调。所以聚合规则只在同一负责人内生效，且要求任务关键词重复超过半数。宁可多留一条重复，也不把两件事糊成一件。

提取准确率怎么量

提取质量必须量化，不然改提示词全凭手感。我们的指标分三类，每两周复盘一次：

命中率低就说明漏了（提示词约束太紧），误报率高就说明抓多了（把讨论当待办），两个指标对着看才调得准。这个漏斗和第四篇 4.4 的校对反馈是同一份数据来源，人工校对的改动天然就是质检样本。

有一次误报率突然飙到 25%，排查了一上午发现是新来的同事开会爱说我下次请你们吃饭，模型把这句当成了待办。这种文化性地名（口头承诺但不构成任务）也进了提示词的排除项。质检指标的意义就在这——它总能比你先嗅到味道。

大模型的提示词设计

语义类的提取交给大模型，提示词我按角色、约束、输出三段式写，核心是输出必须是固定结构的 JSON，后面好解析：

角色：你是一个会议纪要助手，只做客观提取，不做总结发挥。
约束：
1. 只从文本里提取，看不懂的字段写 null，禁止脑补。
2. 每条提取必须能定位到原文片段。
3. 截止日保留原文表述，不换算成具体日期。
输出（示意）：
{
  "todos":   [{"task": "", "owner": "", "deadline": "", "at": ""}],
  "decisions":[{"summary": "", "project": "", "at": ""}],
  "risks":   [{"risk": "", "raised_by": "", "at": ""}]
}

提示词里最关键的一句是看不懂写 null、禁止脑补。模型最大的毛病是爱帮你补全——文本里没写截止日，它顺手给你编一个下周，这种待办发出去是要出事的。模型工具的具体调用和参数，照着DeepSeek 工具链里的实践来配就行。长远看，把提取、补充分发串成一条自动流程，往智能体方向演进，可以参考AI 智能体开发实战的思路。

提示词本身也迭代过好几版。v1 没有约束输出格式，返回的自由文本没法解析；v2 加了 JSON 结构但没写时间戳字段，提取结果追不到原话；v3 才补上禁止脑补和必填来源，稳定下来。每次迭代都是被校对环节的反馈推着走的，哪类错校对改得最多，提示词就治哪类。

提取失败的兜底

兜底机制不能少，我遇到过三种典型失败：模型返回的 JSON 缺字段或多字段，解析直接报错；人名识别错（张三被识别成张珊）；把讨论里否掉的方案当成决议提了出来。对应的办法：JSON 解析失败就降级走规则，用正则先把明显的待办句（包含负责、跟进、之前这类词）捞出来，保证纪要不至于空白；人名和决议都走 4.4 的人工校对，校对界面里每条提取都附原文片段，错了一目了然。

还有两类失败不在模型，在环境。一是网络超时，提取任务卡了十分钟没人发现，后来提取失败自动告警，降级规则的结果会在纪要上额外标一行：本次部分提取为降级结果，请重点校对。把丑话说在前头，比让校对的人误以为一切正常强得多。二是转写后处理还没跑完就提取，碎片句子里待办主语被语气词挡着，提取结果一塌糊涂——所以提取统一排在清理流水线之后，顺序写死在编排里。

最难防的一类失败是提取结果全对、但会议本身信息量太少：一场全是闲聊的站会，最后提取出零条待办零条决议。这种情况不报错也不告警，但纪要发出去空空荡荡。后来我们加了一条规则：待办和决议都为零时，纪要不自动发布，转成待确认状态提醒主持人，是不是会开得水了点。工具要学会说这场会可能没实质内容，而不是硬凑内容交差。

兜底的原则就一条：宁可少提取，绝不提取错的东西发出去。

延伸阅读

• DeepSeek 工具链：提取模型的调用与参数配置实践
• AI 智能体开发实战：提取流程智能体化的扩展方向
• 笔记知识库实战：提取结果如何进入知识库沉淀