会议心智

会议为什么总是「开完就结束」

大多数团队的会议流程是断裂的:纪要生成了,上次提出的问题没人验证;待办派出去了,执行进度无人追踪;一个问题在五场会议里反复讨论,累计消耗 47 人时,最终只完成 4 个待办。会议被当成孤立事件,而不是问题解决链条上的节点。

会议心智要修的就是这个断点。它把会议生命周期拆成三个始终可问的核心问题:这次会解决了什么?(会后提取)、上次的问题解决了吗?(会前验证)、我是不是要开什么新的会?(主动建议并直接创建)。

核心机制:问题闭环的自维持循环

差异化在于闭环。问题未解决时,技能用 --auto-record-type cloud --auto-asr 自动创建跟进会议,新会议自动录制转写,再被技能处理,循环直到闭环,无需每次手动操作。

平台分工上,腾讯会议(tmeet)是数据主角,负责会议全生命周期、录制转写、智能纪要;飞书(lark-cli)是执行层,负责任务派单、催办消息和日历。

内容获取的三场景路由

不是所有会议都有录制,技能按优先级自动路由:

• 场景 A:线上有录制 → 转写 + 智能纪要,信息最完整
• 场景 B:线下有纪要文档 → 读取飞书日历关联的文档
• 场景 C:无任何记录 → 引导口述要点,AI 结构化兜底

能力覆盖

• 会前:一句话建会、冲突检测、会前简报、历史出席分析、资料推送
• 会中:确保每场会议开启转写与云录制、AI 答疑、智能考勤、焦点偏移检测
• 会后:五维度提取(核心问题/决定/待办/遗留问题/闭环判断)、待办自动派单到飞书、DDL 催办、一键导出 Word
• 洞察:会议成本量化(时长 × 人数 = 人时)、跨会议决策溯源、无效会议建议取消
• 模板:8 种结构类型起步,反复打磨后固化为团队定制模板,含党政机关公文体分支

适用边界

• 录制文件仅回溯近 3 个月,更早历史需用户手动提供会议号
• 参会人报表需主持人或报表权限,否则报 9042 错误,退化为仅展示应到名单
• 至少腾讯会议已登录才能运行;tmeet CLI 无实时推送能力,实时转写依赖客户端原生功能
• 模板不记录会议密码等敏感信息;多语言纪要走 AI 翻译层,准确性不做官方保证