主题
智能会议模块 · 需求实现方案(FDS)
一份就够。讲清楚:有哪些原子业务 → 每个的用户操作 → 背后技术 → 二开归类(复用 deer-flow / 基于 deer-flow / 从头做)。 不写思考过程;名词第一次出现就用人话解释。旧的 00–14 是内部过程留痕,不必看。
二开归类三色:🟢 复用 deer-flow(基本不改,直接用) · 🟡 基于 deer-flow(在它的扩展点上做,不动其内核) · 🔴 从头做(deer-flow 没有或不胜任,acdm-backend 自建)
1. 模块全貌
组织者上传录音/纪要 ─▶ 系统按固定流水线处理一场会议:
收材料 ─▶ 转文字(可选) ─▶ 精修 ─▶ 抽取(带原文位置) ─▶ 出处校验
─▶ 存疑点派人确认 ─▶ 确认事实进【项目事实库】
项目事实库 ─▶ 待办 / 跨会看板 / 下次会议开场材料 / 周期复盘 (都只读这个库)一句话:把一场会议变成"可追溯、有人追到底"的结构化结果;所有下游都从一个统一的"项目事实库"读,不再每次重啃录音。
2. 原子业务总表(13 项)
| # | 原子业务 | 用户主要操作 | 二开归类 | 当前现状 |
|---|---|---|---|---|
| B1 | 会议建档与材料上传 | 建会议、传录音/纪要、选项目与参会人 | 🟢+🔴 | 已有上传,缺会议建档绑定 |
| B2 | 录音转文字(ASR) | 传录音,等转写 | 🔴(独立专项,可后置) | 没有,现靠人工传文字稿 |
| B3 | 口水稿精修 | 不操作(自动);可查看精修结果 | 🟡 | 没有 |
| B4 | 会议纪要生成 | 选模板、查看、人工修订 | 🟡 | 有 docx 生成,无人审改与回流 |
| B5 | 关键信息抽取 | 查看抽出的决策/风险/待办/事实 | 🟡 | 有但抽得差(见 §4) |
| B6 | 出处校验(防瞎编) | 点任一条看原文出处 | 🔴 | 没有,出处靠模型自报不可信 |
| B7 | 存疑点人工确认 | 收到确认任务、回答、可改 | 🟡+🔴 | 没有 |
| B8 | 项目事实库 | 不直接操作;是下游的唯一数据源 | 🔴 | 没有 |
| B9 | 待办管理 | 确认负责人/期限、改状态、跨会去重 | 🔴 | 没有(无待办表) |
| B10 | 跨会汇总/项目看板 | 看项目级决策/风险/进度 | 🟡+🔴 | 有但基本失效(见 §4) |
| B11 | 下次会议开场材料 | 开会前看"上次的事现在怎样" | 🟡+🔴 | 没有 |
| B12 | 周期复盘(周/月) | 看复盘报告、改进项完成率 | 🟡 | 没有(只有占位报告) |
| B13 | 业务规则可维护 | 业务人改"什么算风险""纪要模板"等并审批 | 🟢+🟡 | 没有 |
工作量分布:纯复用 1 项 / 基于 deer-flow 扩展 6 项 / 从头自建 6 项(其中事实库 B8 是地基)。详见每项与 §5。
3. 每个原子业务详述
B1 会议建档与材料上传
- 用户操作:在项目里"新建会议"(填主题/时间/参会人)→ 上传录音或纪要文件 → 提交。
- 技术:会议是一条记录,绑定项目;文件入库并转成可处理文本(Word/PDF/录音→统一格式)。
- 二开:🟢 文件上传+格式转换复用 deer-flow 现成能力;🔴 "会议记录+绑定项目/参会人/材料"这张表和接口 acdm-backend 自建(现在没有完整的会议建档)。
B2 录音转文字(ASR)
- 用户操作:上传录音,等待转写完成;转写带时间点和说话人。
- 技术:接一个语音转写服务(云服务或自托管),输出带时间戳、分说话人的文字稿。
- 二开:🔴 从头接,独立专项、可后置;在它做好前,用户先人工上传文字稿即可,不卡其他功能。选型(云/自托管)取决于公司对"录音能不能出公司网"的合规要求。
B3 口水稿精修
- 用户操作:无需操作(自动);可查看"精修后"的干净文本。
- 技术:用大模型把原始文字稿去口语、去重复、按话题分段、把"谁说的"归到人;长会议分块多次处理,防止中间内容被丢。
- 二开:🟡 写成一个"精修技能"(一份业务人可读的说明文件,引擎按它执行),挂在 deer-flow 的技能目录;引擎本身不改。
B4 会议纪要生成
- 用户操作:选公司模板 → 系统生成纪要(Word)→ 人工在线修订 → 确认。修订后下游自动重算。
- 技术:大模型按模板把精修文本凝练成纪要;生成 Word 用现有模板渲染(保留中文字体/格式);纪要被人改后,触发后面 B5 重新抽取。
- 二开:🟡 纪要生成做成技能 + 复用现有 Word 渲染;🔴 "人改了纪要→通知下游失效重算"这条联动 acdm-backend 自建。
B5 关键信息抽取
- 用户操作:查看系统从这场会抽出的:决策、风险、待办、里程碑、关键事实——每条带"出自原文哪句"。
- 技术:按类型分别抽(决策一组提示、风险一组……),不是用一个大提示词一次抽全部(那样会抽错、错位);每条必须给出对应的原文片段及其在原文中的位置。
- 二开:🟡 抽取做成技能(每种类型一个或一组),挂技能目录;引擎不改。当前实现是反面教材:一个大提示词一次抽全部、还开思考模式串行跑,导致单场要等好几分钟且抽得乱——重做时拆开。
B6 出处校验(防 AI 瞎编)
- 用户操作:点任意一条结论,跳到原文那句话核对。
- 技术:程序逐条检查"模型给的这句引文是不是真的在原文里"——不在,就丢弃或转 B7 人工确认。这步绝不能交给模型自己判断,必须是代码硬规矩。
- 二开:🔴 acdm-backend 自建一段校验逻辑(纯程序比对),放在"抽取之后、入库之前"这道关卡。这是"看得到真实出处、不瞎编"的根本保证,现在完全没有。
B7 存疑点人工确认
- 用户操作:负责人收到一条"请确认"任务(IM 通知),里面有上下文和候选答案;回答(或修改);系统据此把这条补全后继续。
- 技术:校验没过/模型没把握/两处说法冲突的条目,生成一条确认任务,指派给对应负责人;人回答后,处理流程从中断处接着跑,只重算受影响的条目,不整场重来。
- 二开:🟡 "中途暂停等人确认、人答后从断点继续"这套机制——公司已有功能(内部代号 ba_report)在生产环境跑通了,照它的做法做,引擎不改;🔴 "把确认任务异步派给指定负责人、IM 通知、收集回答再回灌"这一层 acdm-backend 自建(deer-flow 自带的只能在同一对话里当场问,不能异步派给别人)。
B8 项目事实库(地基)
- 用户操作:不直接操作。它是 B9–B12 的唯一数据来源。
- 技术:一个数据库(PostgreSQL),存这个项目"已确认的事实",字段含:项目、类型(决策/风险/待办…)、内容、原文出处位置、负责人、期限、状态、确认人、版本;支持按项目和条件精确查询,写完立刻能读,不丢数据,按项目隔离。
- 二开:🔴 acdm-backend 从头自建。特别说明:deer-flow 自带一个"记忆"功能看着像能用,但读了它真实代码确认——它只是把对话摘成一段文字,不能精确查询、写完不能马上读、还会丢、按项目隔离也没接通,不胜任,所以这块必须自建。这是整个模块的地基:做对了,慢和不可追溯的问题一起解决。
B9 待办管理
- 用户操作:看从会议派生的待办;确认负责人和截止时间(系统给的默认值要人确认才生效);改状态(待定→进行中→完成/取消);同一件事多次会议提到时自动并成一条;待办可推到团队在用的执行系统。
- 技术:从抽取出的"待办"条目派生;一张待办表 + 状态流转规则;跨会按(负责人+事情)归并去重;与外部任务系统(如飞书任务)对接。
- 二开:🔴 acdm-backend 自建(现在没有待办表/接口/状态机/归并)。归并和状态机有公司内现成范式可参考。
B10 跨会汇总 / 项目看板
- 用户操作:打开项目看:这个项目所有会议汇总的决策、风险、里程碑、待办;同一事项跨会怎么演变、哪个风险反复出现。
- 技术:从项目事实库读取并按类型聚合;同类事项的合并要用"实体消歧 + 语义相似"判断(谁是同一个人、同一件事),不是只看会议日期。
- 二开:🟡 聚合/叙述部分做成技能;🔴 真正的关联判断逻辑 acdm-backend 自建。当前实现失效:读了代码确认,现在的关联实际只按"开会日期接近"算(语义和实体比对被关掉了),所以跨会"智能"基本是错觉——重做时换成真的实体/语义比对,且只读事实库。
B11 下次会议开场材料
- 用户操作:下次开会前,自动看到一张"上次说要做的 N 件事:X 完成 / Y 没动 / Z 变了 / 哪些超期/反复卡住"。
- 技术:开会话时,从项目事实库取上次待办与其当前状态,拼成开场材料自动带出;偏差(超期/反复)标红。
- 二开:🟡 "会话开场自动带上下文"用 deer-flow 的中间件扩展点接入;🔴 取数和偏差判断读 acdm-backend 事实库。
B12 周期复盘(周/月)
- 用户操作:每周/月自动收到复盘:这阶段做成了什么、哪些跑偏、改进项完成率(低于一半报警);可导出/回写知识库。
- 技术:定时任务从事实库取数,大模型生成复盘报告;完成率=已确认待办里"完成"的占比。
- 二开:🟡 复盘做成技能 + 用现有定时流水线机制跑;取数读 🔴 事实库。
B13 业务规则可维护
- 用户操作:业务人在线编辑"什么算风险""纪要模板长啥样""精修规则"等说明 → 提交 → 自动跑测试 + 人审 → 通过才生效;改动有版本、可回退。
- 技术:这些业务规则就是 B3/B4/B5 用的那些"技能说明文件"(markdown),用 git 管版本;改动走评审与自动测试。
- 二开:🟢 技能机制复用 deer-flow;🟡 "业务人编辑界面 + 提交即跑测试 + 人审" 这层流程在现有知识库协编/CI 上接。三条不让步:正确性硬规矩(B6 校验、B8 入库)永远是代码不是技能;每个技能必须配自动测试,业务人改完能自动验有没有改坏;改动必须审过才上线。
4. 二开归类汇总(一眼看清做什么)
🟢 复用 deer-flow(直接用,基本不改)
- 文件上传与格式转换(B1)、技能机制(B3/B4/B5/B13 的承载)、确定性流水线引擎(跑这条会议处理流水线)、IM 通知通道(B7)、"暂停等人确认再继续"的机制范式(B7,照 ba_report 做法)。
🟡 基于 deer-flow(在扩展点上做,不碰其内核)
- 新建"会议处理流水线"(把 B1–B7 串成固定步骤,注册到引擎)、各原子业务的技能文件(精修/抽取/纪要/复盘)、会话开场注入(B11)。
🔴 从头自建(deer-flow 没有/不胜任,acdm-backend 代码)
- 项目事实库 B8(地基,最先做)、出处校验 B6、存疑点异步派人确认层 B7、待办池/状态机/跨会归并 B9、真关联判断 B10、会议建档绑定 B1、纪要改动联动 B4、跨会取数与偏差 B10/B11、ASR 接入 B2(独立可后置)。
5. 落地顺序(先跑通最小闭环,再扩)
- 先做地基:B8 项目事实库 + B6 出处校验(没这两个,后面全是空中楼阁)。
- 打通单场会议:B1 建档 → B3 精修 → B5 抽取 → B6 校验 → B8 入库。验收:随机抽 20 条,每条都能点回原文且确实是原文;不确定的 0 条进库;一场会几分钟内出结果(优于现在的好几分钟卡顿)。
- 加人确认:B7 存疑点派人确认回灌。
- 接下游:B9 待办 → B10 跨会看板 → B11 下次开场 → B12 复盘。
- 补外围:B4 纪要人审联动、B13 业务规则可维护、B2 ASR(独立专项,合规明确后做)。
6. 现状与一句诚实话
- 现有"智能会议"功能是"先能跑"的半成品被当成品上了线:单场分析要等好几分钟甚至卡死、抽错抽漏、看不到真实出处、跨会"智能"实际只按日期算——这些都是读了真实源码确认的,不是猜。
- 本方案是重做,不在半成品上打补丁;复用 deer-flow 该复用的、自建该自建的(尤其事实库 B8)。
- 目前代码还没动:方案已定、源码已查证;真正算数,要等第 5 节第 2 步"单场会议最小闭环"用真实会议跑通。