视频会议这个赛道这两年最大的变量就是AI。我前后参与过三款视频会议产品的智能化模块设计从最早的语音转文字这种单点功能到后来尝试把AI能力铺到会前、会中、会后整条链路上踩过的坑比想象中多得多。很多团队一上来就想做AI会议助手结果做出来的东西要么是鸡肋的会议纪要要么是没人用的实时字幕最后沦为PPT上的一个卖点。问题不在于AI能力不够强而在于产品设计时没有想清楚会议这个场景里用户到底在哪些环节真正需要AI以及AI介入之后会不会反而增加认知负担。这篇内容我想聊的是AI视频会议产品设计这件事本身不是讲某个具体模型怎么调而是从产品视角拆解围绕会议全链路智能化能力应该怎么落地、怎么取舍、怎么避免做成为了AI而AI。适合正在做会议类产品、协同办公工具或者任何想把AI能力嵌入实时交互场景的产品经理和开发者参考。我会结合自己实际做过的功能模块把每个环节的设计逻辑、技术选型考量、以及上线后遇到的真实问题都摊开讲。1. 先搞清楚会议全链路到底分几段AI该在哪一段发力很多人做AI会议功能脑子里只有会中这一段觉得实时字幕、实时翻译就是全部。但真正用过几十场会议之后你会发现用户的痛点分布是极不均匀的而且会前和会后的需求往往比会中更刚性。1.1 会前被严重低估的智能化入口会前这一段传统产品设计里基本就是发个邀请、定个时间、附个议程看起来没什么可做的。但实际调研下来会前是AI最能体现价值、又最不容易被用户抗拒的环节因为它不涉及实时性压力容错率高。我做过的一个功能是智能议程生成。用户输入一个会议主题和参会人列表系统根据历史会议记录、相关文档、以及参会人的角色自动生成一份结构化议程草案。这个功能的技术实现并不复杂核心是把会议主题做语义扩展然后从知识库里检索相关材料再用大模型做摘要和结构化输出。但设计上的关键在于不要让AI直接生成最终议程而是生成一个可编辑的草案。我们第一版做成了一键生成完整议程结果用户反馈说改起来比自己写还累。后来改成生成3到5个议题框架每个议题下面给2到3个讨论要点提示用户只需要增删改接受度立刻上来了。另一个会前功能是参会人准备度提示。系统会分析每个参会人是否阅读了会前材料、是否在相关文档里有评论、是否在之前的会议里对相关议题有过表态。这个功能的价值在于它帮会议组织者判断这场会能不能开出效果。如果关键决策人根本没看材料那这场会大概率是浪费时间。这个功能的技术难点不在AI而在于数据打通——你需要把文档系统、会议系统、IM系统的数据关联起来这涉及到权限和隐私的边界设计。注意会前智能化的一个核心原则是辅助准备不替代决策。任何让用户觉得AI在替我做决定的设计都会引发抵触。草案、提示、建议这些词比自动生成智能决策要安全得多。1.2 会中实时性是双刃剑别什么都往实时上堆会中这一段是AI能力最集中、也最容易翻车的地方。实时字幕、实时翻译、实时摘要、发言识别、情绪分析听起来都很美好但每加一个功能都是在跟延迟、算力、以及用户的注意力抢资源。我踩过最大的一个坑是实时摘要。当时觉得这个功能很酷会议进行中侧边栏实时滚动显示当前讨论要点。上线后发现几乎没人看。原因很简单开会的时候人的注意力要么在听别人说话要么在看共享屏幕根本没有余力去读侧边栏的文字。而且实时摘要的质量不稳定有时候摘出来的东西和实际讨论重点偏差很大反而干扰判断。后来我们把这个功能改成了**关键节点标记**。不做实时摘要而是让AI识别会议中的决策时刻和待办时刻在这两个时刻发生时在侧边栏打一个轻量的标记比如检测到决策Q3预算方案已确认或检测到待办张三负责整理需求文档。用户不需要实时看会后回顾的时候这些标记就是天然的章节锚点。这个改动之后功能使用率提升了三倍多。实时字幕倒是刚需但设计上也有讲究。我们最初做的是全量实时字幕每句话都显示结果屏幕被文字占满而且识别错误率在多人交叉说话时飙升。后来改成**发言人分段字幕**结合声纹识别做说话人分离每个人说的话单独成段并且只保留最近30秒的内容更早的自动折叠。这样既保证了可读性又不会让屏幕变成文字墙。会中AI功能用户真实需求强度技术实现难度我的建议实时字幕高中必做但要做说话人分离和滚动折叠实时翻译中跨语言场景高高按场景开关不要默认开启实时摘要低中不建议做改成关键节点标记发言识别中中用于字幕分段和会后统计不直接展示情绪分析低高谨慎容易引发隐私争议1.3 会后AI价值密度最高的地方会后是AI能力真正能形成闭环的地方也是用户最愿意为之付费的环节。会议纪要、待办提取、决策记录、会议效果分析这些功能直接对应开完会之后要干什么。我们做的智能纪要经历了三个版本。第一版是全文转写摘要就是把语音转成文字再用大模型压缩成一段话。用户反馈是太笼统找不到具体谁说了什么。第二版改成按议题分段每段摘要关键发言引用结构清晰了很多但用户还是觉得看完纪要还得回去听录音确认。第三版才找到相对正确的形态纪要待办决策三件套。纪要按照议题结构组织每个议题下面自动提取待办事项谁、做什么、什么时候之前以及决策结论达成了什么共识、否决了什么方案。待办可以直接一键同步到任务系统决策记录可以关联到相关文档。这个版本上线后用户留存明显提升。核心原因是它不只是记录了什么而是接下来要做什么。会议的价值不在于开了多久而在于开完之后有没有产生行动。2. 技术选型不是所有AI能力都要自己训模型做AI会议产品技术选型上最大的误区是什么都想自研。我见过不少团队为了做实时字幕非要从头训一个语音识别模型结果做了半年效果还不如直接调用成熟的API。产品设计的核心是快速验证价值而不是炫技。2.1 语音识别自研还是调用算一笔账语音识别是会议AI的基础能力所有上层功能都依赖它。自研ASR模型的成本包括数据采集和标注、模型训练和调优、推理服务部署、以及持续的迭代维护。一个中等规模的团队做一套能用的中文会议ASR至少需要3到5个人月的前期投入而且效果还不一定比得上成熟方案。调用成熟API的成本则清晰得多按量付费前期几乎零投入效果有保障。但问题在于会议场景有一些特殊需求比如专业术语识别、多人交叉说话分离、口音适应通用API在这些方面可能不够好。我的建议是混合方案基础转写用成熟API然后在应用层做后处理。具体来说维护一个领域词典把公司内部的产品名、项目代号、专业术语加进去在API返回结果之后做一次替换和纠错。说话人分离如果API自带就用自带的如果不带可以用声纹聚类做二次处理。这样既控制了成本又保证了场景适配。2.2 大模型会议纪要的生成策略会议纪要的生成本质是一个长文本理解结构化输出的任务。这里的关键不是模型选哪个而是怎么组织输入。直接把整场会议的转写文本丢给大模型效果通常很差因为文本太长、信息密度低、而且有很多无关内容。我们的做法是分层处理。第一层把转写文本按时间窗口切分成若干片段每个片段做一次轻量摘要提取出这段在讨论什么。第二层把片段摘要按议题聚类相同议题的片段合并。第三层对每个议题的合并内容做一次深度摘要生成结构化的议题纪要。第四层从议题纪要里提取待办和决策。这个分层策略的好处是每一层的输入长度都可控模型的理解质量更稳定。而且中间结果可以缓存如果用户只需要待办就不需要跑完整的四层。提示会议纪要的prompt设计里一定要明确不要编造。大模型在长文本摘要时很容易脑补一些没发生的内容尤其是当讨论比较零散的时候。我们在prompt里加了如果某个信息在原文中没有明确出现不要写入纪要这样的约束虽然会损失一些流畅度但准确性提升明显。2.3 实时处理边缘计算还是云端会中的实时功能比如字幕和翻译对延迟非常敏感。云端处理的延迟通常在几百毫秒到一秒之间对于字幕来说勉强可接受但对于实时翻译就有点吃力。边缘计算可以把延迟降到几十毫秒但需要在客户端部署模型对设备性能有要求。我们最终采用的是分级策略字幕走云端因为用户对字幕延迟的容忍度相对高实时翻译走边缘因为翻译延迟超过500毫秒就会明显影响理解。边缘部署的模型用的是量化后的小模型效果比云端大模型差一些但延迟优势明显。这个取舍的核心逻辑是实时场景下延迟比精度更重要。用户宁可看到一句稍微不那么准确的翻译也不愿意等两秒才看到一句完美的翻译。3. 产品设计中最容易翻车的三个决策点技术选型只是基础真正决定AI会议产品成败的是产品设计层面的决策。我总结下来有三个决策点最容易翻车而且每一个都跟AI能力本身无关而是跟用户心理和使用场景有关。3.1 默认开启还是默认关闭这是一个看似简单、实则影响巨大的决策。AI功能默认开启用户感知强但容易引发被监控的抵触默认关闭用户需要手动开启使用率会大幅下降。我们的经验是分功能区别对待。字幕默认开启因为它是辅助理解的功能用户感知是帮我听清楚没有隐私压力。翻译默认关闭因为它是场景化功能只在跨语言会议时需要默认开启反而干扰。纪要默认开启但要在会议开始时明确提示本次会议将生成智能纪要给用户知情权。情绪分析、发言时长统计这类功能默认关闭并且只在主持人视角可见。这个策略背后的逻辑是用户对AI的接受度取决于AI是在帮自己还是在分析自己。帮自己听清楚、帮自己记笔记接受度高分析自己的情绪、统计自己的发言接受度低。3.2 AI出错的时候怎么办AI一定会出错字幕会识别错纪要会摘错待办会提错。产品设计的关键不是如何让AI不出错而是出错的时候用户怎么纠正。字幕的纠错相对简单用户看到错字点一下就能编辑编辑后的结果可以反馈给系统做优化。纪要的纠错就复杂得多因为用户看到的是一段摘要不知道原文是什么。我们的做法是纪要的每一句话都可以点击展开查看对应的原文片段。这样用户既能快速浏览纪要又能在有疑问的时候追溯到原始内容。待办的纠错则是提供一个编辑按钮用户可以直接修改待办的内容、负责人、截止时间。这里有一个设计原则AI的输出必须是可追溯、可编辑、可反馈的。可追溯是指用户能看到AI结论的来源可编辑是指用户能直接修改AI的输出可反馈是指用户的修改能被系统学习用于优化后续的输出。三者缺一不可少了任何一个用户都会觉得这个AI不靠谱还不如我自己来。3.3 会议数据的边界在哪里这是最敏感、也最容易被忽视的问题。AI会议产品需要处理大量的会议数据包括语音、文字、参会人信息、讨论内容。这些数据的存储、使用、销毁都需要有明确的边界。我们的做法是分级授权透明可控。分级授权是指不同角色的用户能看到的数据范围不同。普通参会人只能看到自己参与的会议的纪要主持人能看到自己主持的所有会议的完整数据管理员能看到统计层面的数据但不能看到具体内容。透明可控是指用户能随时查看自己的数据被如何使用能随时删除自己的会议记录能选择是否让AI使用自己的历史数据做优化。注意会议数据里经常包含商业机密、人事讨论、战略规划等敏感内容。产品设计时一定要假设所有会议内容都是敏感的默认采取最严格的保护策略而不是先收集再说。一旦出现数据泄露对产品的打击是毁灭性的。4. 从功能堆砌到场景闭环一个真实的迭代案例讲一个我们实际做过的迭代案例把上面的设计原则串起来。这个案例是关于跨语言会议场景的前后迭代了四个版本每个版本都踩了不同的坑。4.1 第一版实时翻译字幕看起来很美好第一版我们做的是实时翻译字幕就是把发言人的话实时转写成文字然后翻译成目标语言显示在屏幕上。技术上跑通了延迟控制在800毫秒左右翻译质量也还行。但上线后使用率极低。调研发现问题出在阅读负担上。跨语言会议里参会人本来就在努力听和理解屏幕上再滚动一堆翻译文字注意力被严重分散。而且翻译字幕和语音不同步经常出现听到的是上一句看到的是这一句的错位感。用户反馈说还不如直接听听不懂的地方再问。4.2 第二版按需翻译把控制权交给用户第二版我们改成了按需翻译。默认不显示翻译用户如果听不懂某句话可以点击那句话弹出翻译结果。这个改动把持续阅读变成了按需查询认知负担大幅降低。使用率有所提升但还是不够理想因为用户在会议中点击这个动作本身就有成本。4.3 第三版会前术语准备会中关键词提示第三版我们换了个思路与其在会中做翻译不如在会前做准备。系统会分析会议议程和相关文档提取出可能出现的专业术语和关键概念提前生成一份双语术语表发给参会人预习。会中则只对检测到的高频术语做实时提示比如发言人提到一个专业词侧边栏显示这个词的翻译和解释。这个版本的效果明显好于前两版。核心原因是它把AI的能力用在了降低理解门槛上而不是替代理解过程上。跨语言会议的难点不在于逐句翻译而在于专业术语和背景知识的理解。会前准备解决了背景知识会中提示解决了术语障碍剩下的靠参会人自己就能搞定。4.4 第四版会后双语纪要待办同步第四版我们把重点放到了会后。生成双语纪要每个议题的讨论要点同时提供两种语言版本。待办事项也做双语并且可以直接同步到不同语言的任务系统。这个版本让跨语言会议的会后行动变得顺畅不再需要人工翻译和转达。四个版本迭代下来最大的体会是AI在会议场景里的价值不是替代人而是补足人的短板。人听不清AI做字幕人记不住AI做纪要人不懂术语AI做提示。但AI不应该替代人的判断、人的决策、人的沟通。一旦越界用户就会抵触。5. 落地过程中那些文档里不会写的经验最后这部分我想分享一些在实际落地过程中积累的、常规产品文档里不会写的经验。这些经验不一定适用于所有团队但至少能帮你少走一些弯路。5.1 先做减法再做加法AI会议产品最容易犯的错误是功能堆砌。因为AI能力看起来很万能什么都能做于是产品经理就容易什么都想做。但会议场景的用户注意力极其有限每多一个功能就多一份干扰。我的建议是先做减法。列出所有能想到的AI功能然后问三个问题这个功能解决的是不是高频痛点这个功能会不会干扰会议本身这个功能如果去掉用户会不会有明显感知三个问题里有两个是否定答案的就先不做。我们最初列了二十多个功能点最后第一版只做了四个实时字幕、智能纪要、待办提取、会议搜索。这四个功能覆盖了会中记录和会后行动两个核心场景其他的都往后排。5.2 冷启动阶段人工兜底比AI优化更重要AI功能上线初期效果一定是不完美的。这个时候与其花大量精力优化模型不如先做人工兜底。比如智能纪要初期可以安排运营人员对AI生成的纪要做人工校对确保输出质量。待办提取不准确的地方人工修正。这样虽然成本高但能保证用户体验为后续的模型优化争取时间。我们当时的做法是前100场会议全部人工校对同时收集错误样本。这些样本后来成了模型优化的重要数据来源。如果一开始就放任AI输出低质量结果用户可能用一次就再也不用了连收集反馈的机会都没有。5.3 会议场景的AI要安静一点这是一个很微妙但很重要的设计原则。会议是一个高度专注的场景任何打断、弹窗、声音提示都会造成干扰。AI功能的设计要尽量安静用视觉上的轻量提示代替弹窗用会后汇总代替会中打扰。比如待办提取我们最初的设计是检测到待办时弹窗提示结果被用户骂惨了。后来改成在侧边栏打一个轻量标记不打断当前操作体验就好很多。再比如纪要生成不要在会议结束后立刻弹出而是等用户回到工作台的时候在通知中心里显示您的会议纪要已生成。5.4 不要试图用AI解决所有问题有些问题不是AI能解决的或者说用AI解决的成本远高于其他方案。比如会议太多这个问题AI能帮你更好地记录会议但不能帮你减少会议。比如会议效率低这个问题AI能帮你提取待办但不能帮你确保待办被执行。产品设计时要清楚AI的能力边界不要给用户过高的预期。我们在产品介绍里从来不说AI帮你开好每一场会而是说AI帮你记住每一场会。这个定位更准确也更容易兑现。5.5 数据闭环是长期竞争力的来源AI会议产品的长期竞争力不在于模型有多强而在于数据闭环有多完整。用户每一次对AI输出的修改、每一次对纪要的编辑、每一次对待办的调整都是宝贵的反馈数据。这些数据能用来优化模型让产品越用越准。但数据闭环的前提是用户愿意反馈。我们的做法是把编辑本身设计成反馈入口用户修改纪要的时候不需要额外操作系统自动记录修改前后的差异。同时提供一个这个结果有帮助吗的轻量反馈按钮不强制但给愿意反馈的用户一个通道。6. 关于AI会议产品未来形态的一点个人判断做了这几年的AI会议产品我有一个越来越强烈的感受会议这个场景最终可能不需要一个AI会议助手而是需要会议本身变得不需要AI。什么意思呢就是当会议的信息流转足够顺畅、当会前准备足够充分、当会后行动足够明确的时候AI在会中的介入需求会自然减少。但这不意味着AI会议产品没有未来。恰恰相反AI的价值会从会中辅助转移到会前准备和会后闭环上。会前AI帮你把该准备的准备好把该对齐的对齐好让会议本身变得更短、更聚焦。会后AI帮你把该记录的记录好把该执行的执行好让会议的价值真正落地。会中那一段AI的角色会越来越像一个安静的记录者而不是一个活跃的参与者。它不打断、不干扰、不抢戏只是默默地把该记的记下来该标的标出来。等会议结束你发现所有需要的东西都已经整理好了这就是最好的AI会议体验。我在实际使用中发现那些真正好用的AI会议功能往往不是最智能的而是最懂场景的。一个恰到好处的提示比一个炫酷的实时分析更有价值。一个准确的待办提取比一段华丽的会议摘要更让人愿意付费。产品设计的功夫不在AI能力本身而在对会议这个场景的理解深度上。