夜雨聆风需求会刚结束，她打开手机，AI 纪要已经生成好了。内容都在，没有漏掉什么。但她盯着那份输出看了大概三秒，然后把手机翻过去扣在桌上。
不是因为内容不准。是因为那是一整段话——从「首先我们讨论了用户路径的问题」到「最后大家同意下周五之前给出方案」，七八个人的发言按时间顺序堆在一起，没有分层，没有重点，没有谁该做什么。
她需要的是：这次会议决定了什么、谁要在什么时间做什么、背景是什么。但她拿到的，是一份完整的「会议录音文字版」。她还是得自己重新整理一遍。
问题不是工具「听没听准」，是它把内容整理成了什么形状。
大多数人选 AI 纪要工具时，比的是输入侧的能力。
识别率高不高、支持几种语言、能不能实时转写、有没有说话人分离——这些问题本身没有错，但它们都在问同一件事：这个工具能不能把声音变成文字。
这是输入侧。
但纪要能不能被用起来，取决于输出侧——它把那些文字整理成了什么形状。
识别率 95% 和识别率 98% 的差距，在实际使用中几乎感知不到。但输出是一整段流水账，还是一份分层的结构化摘要，差距是：你拿到之后要不要再花二十分钟重新整理。
从我们观察到的主流工具来看，输出形状大致可以分成三种。
第一种是流水账型。按时间顺序堆叠发言，信息完整但没有提炼——适合存档，不适合行动。
第二种是清单型。自动提取待办事项，列成 to-do list。比流水账好用，但背景丢了。你看到「下周五前给出方案」，不知道这个方案是在什么前提下被提出来的、当时有没有争议、优先级是什么——执行的人拿到清单，还是需要回去问。
第三种是结构化摘要型。把会议内容分成几个层次：这次会议做了哪些决策、产生了哪些待办（含负责人和时间节点）、讨论背景是什么。三层各自独立，但互相关联。
这三种形状，对应的是三种完全不同的使用场景——或者说，三种对「纪要」这件事的不同理解。
谈小简选择的是第三种，但这个选择背后有一个具体的判断。
我们在设计输出结构的时候问过自己一个问题：纪要的第一读者是谁？
不是要存档的人。不是要回顾会议过程的人。是要推进事情的人——可能是会议里的某个参与者，可能是没参加会议但需要跟进的同事，可能是下一次会议的主持人。
这个人需要的不是「会议发生了什么」，而是「我现在该做什么、为什么要这么做、背景是什么」。
所以谈小简的输出结构是：决策在最前面，待办紧跟其后，讨论背景放在最后。
决策是结论，待办是行动，背景是上下文。三层的顺序不是随机的——它对应的是「推进事情的人」阅读一份纪要时的真实需求顺序：先知道结论，再知道自己要做什么，最后如果有疑问再去看背景。
全文转写是为存档设计的，不是为行动设计的。纯清单丢掉了让人能独立判断的上下文。我们选择三层结构，是因为我们认为纪要的核心价值是「让没在场的人也能推进事情」，而不是「让在场的人回忆会议过程」。
需要说明的是，这套结构更适合有结论要推进的工作会议。如果会议本身是发散讨论、没有明确决策，三层结构的价值会打折。
如果你每次拿到纪要都要再整理一遍，问题不在识别率，在输出形状——这是可以在选工具之前就确认的事。
结构对了，纪要才算完成了它该做的事。
选 AI 纪要工具之前，可以先问一个问题：它把会议整理成什么形状？
如果你需要的是「开完会直接能发出去、直接能跟进」的那种，可以试试谈小简——录完即出，决策、待办、背景，结构已经在里面了。
