a-cdm × deer-flow 源码分析

主题

FDS-20 · B11 下次会议开场材料 ​

开下一次会(或开会前),系统自动把"上次说要做的那几件事,现在到底怎样了"摆到桌面上当开场。不接飞书,全部站内。本章给到取数口径与偏差判定规则。

1. 业务说明 ​

  • 是什么:下一次会议开场时,系统自动生成一段对照——"上次说要做的 N 件事:X 件做完、Y 件没动、Z 件改了说法、哪几件已经超期、哪几件每次会都被提但一直没推动",作为这场会的开场材料。
  • 给谁/解决什么:给组织者和参会人。现在的痛点是"开会先花十几分钟回忆上次定了啥、谁该做、做没做",回忆还经常对不上、漏项;有了它,开场即对账,会议直接从"差距"切入。
  • 跟谁的关系:它不重新分析录音,只读项目事实库(FDS-17)里 kind=action 的待办事实和它们的当前状态(待办状态由 B9 维护,落在同一张 project_facts 表的 payload.status / status 上)。"摆到桌面"靠会话开场注入位——开会话时自动把这段材料带进上下文的挂载点(deer-flow 中间件扩展位,见 FDS-03)。
  • 不做会怎样:每场会靠人脑回忆上次待办,漏项、记错、超期没人发现、同一件事反复提却没人意识到它"卡了三次会",PDCA 的 C(检查)环节始终缺位。

2. 用户操作与界面 ​

  • 组织者新建/进入下一场会议的处理会话时,无需任何操作,开场材料自动出现在会话开头(一段结构化对照 + 可点开看出处)。
  • 也可在会议工作台手动点"生成上次进度对照"提前预览(开会前准备用)。
  • 每条待办可点开 → 跳到它在上次纪要里的原文位置(trace,见 FDS-17),核对"当初到底是怎么说的"。
  • 用户不直接操作取数与判定逻辑;看到的是结论,改不了口径(口径是代码,见 §5)。

3. 数据与接口(字段级) ​

输入(只读,全部来自 FDS-17 project_facts,不重啃录音):

  • 取数范围:project_id = 本场会议所属项目;kind=action;status ∈ {proposed, confirmed, superseded}(已 dropped 的不进开场,除非本场被重新提起)。
  • 每条用到的字段:id、text、payload.owner(负责人)、payload.due(应完成时间)、payload.status(待办流转状态,由 B9 维护:未开始/进行中/已完成/受阻 等)、status(事实级:proposed/confirmed/superseded/dropped)、meeting_id(出自哪场会)、supersedes_id(演进链:它取代了哪条旧待办)、extract_version、content_hash、created_at/updated_at、source_ref(回原文)。
  • "上一次会议"的界定:本项目里时间上紧邻本场之前的那场会议(meeting_id 对应的会议时间);开场对账对象 = 该会及之前仍处于"未闭环"的待办全集(不是只看上一场新增的,跨会未完成的一并带出——避免"上上场漏的永远不再被提")。

接口(均为 acdm-backend 现有事实库接口,见 FDS-17,本章不新增库):

  • GET /facts/query:project_id + kind=action + status 过滤 + 时间范围,精确、强一致(刚被 B9 改完的状态立刻读得到,不存在缓存延迟导致开场材料是旧的)。
  • GET /facts/{id}/trace:每条待办回原文定位(开场材料里"点开看出处")。
  • 本章自建的 GET /facts/opening-brief(acdm-backend 新增,仅做编排,不新增表):入参 project_id + meeting_id(本场);内部调用上面两个查询 + 跑偏差判定;返回分组结果(见下)+ 每条 source_ref。

输出契约(opening-brief 返回结构,注入位据此组装上下文):

{
  prev_meeting: { meeting_id, title, date },
  summary: { total, done, untouched, changed, overdue, recurring },
  groups: {
    done:      [ {fact_id, text, owner, closed_at} ],
    untouched: [ {fact_id, text, owner, due, days_idle} ],
    changed:   [ {fact_id, text, owner, change: "范围漂移|负责人变|期限改", supersedes_id} ],
    overdue:   [ {fact_id, text, owner, due, days_overdue} ],
    recurring: [ {fact_id, text, owner, hit_meetings:[id...], hit_count} ]
  }
}

一条待办可同时落在多组(如"既超期又反复卡");summary 计数按"事项去重"(同一待办演进链算一件),不重复累加。

4. 技术实现(分步) ​

  1. 触发与挂载:组织者开本场会议处理会话时,会话开场注入位(deer-flow 中间件扩展位)在会话第一轮之前调用 GET /facts/opening-brief,把返回内容作为开场上下文带进去——业务无感、不需手点。手动预览走同一接口。
  2. 取数:opening-brief 先定位"上一场会议"(本项目时间上紧邻本场之前者),再 GET /facts/query 取该会及之前仍未闭环的 kind=action 全集(强一致读,拿到的就是 B9 维护的最新状态)。
  3. 偏差判定(代码,确定性,口径见下表):对每条待办按规则归到 完成 / 没动 / 变了 / 超期 / 反复卡 五组(可多重)。
  4. 演进链折叠:沿 supersedes_id 把同一事项的多条修订折成一件,取最新一条参与判定;判定"变了"时对照被它取代的旧条说明改了什么(范围/负责人/期限)。
  5. 组织措辞(技能):把分组结果交给开场叙述技能,生成人话开场——先一句总览("上次 8 件,3 完成、2 没动、1 改了说法、2 超期、1 已卡 3 次会"),再分组列条、点名负责人、给出处链接。技能只负责措辞与排序,不改判定结果、不新增结论。
  6. 回原文:每条带 source_ref,前端/会话里点开经 trace 跳上次纪要原文位置,供现场核对。
  7. 空场兜底:项目首场会(无上一场)或上次无待办 → 开场材料明说"本项目暂无上次待办对照,从本场开始建立",不报错、不杜撰。

偏差判定口径(全部代码,不交模型自判):

组判定规则(基于事实库字段)
完成payload.status = 已完成(由 B9 在产品内确认置位);记 closed_at
没动payload.status 仍为未开始 且 自创建/上次会以来 updated_at 无推进(days_idle = 距今天数)
变了沿 supersedes_id 与旧条对比:text 关键内容变化(范围漂移)/ payload.owner 变 / payload.due 变;标出变化类型
超期payload.due < 今天 且 payload.status ≠ 已完成;days_overdue = 超期天数
反复卡同一事项(演进链)关联 meeting_id ≥ 2 场 且 至今未闭环;hit_count = 被提及的会议数

"反复卡"依赖跨会同一事项的归并关系(project_fact_links / supersedes_id,B9/B19 维护);本章只读这层关系做计数,不自建归并。

5. 技能 or 代码 ​

  • 代码(acdm-backend):注入位接入、取数、演进链折叠、偏差判定全部口径(完成/没动/变了/超期/反复卡的边界)。这些是确定性事实计算,必须代码——口径若交模型自判,会出现"这次说没动、下次说在推进"的飘忽,开场对账失去信任基础。
  • 技能:只有"开场怎么说"——总览句式、分组顺序、点名与措辞、语气(对账而非问责)。业务人可读可改、版本化(见 FDS-04)。

边界:技能拿到的是已判定好的分组数据,只做语言组织;不允许技能改判定、合并/拆分组、或添油加醋出新结论。判定与措辞物理分离。

6. 二开归类 ​

  • 🟡 基于 deer-flow:开场叙述做成技能挂技能目录;"自动把材料带进会话"复用 deer-flow 的会话开场注入位(中间件扩展位,FDS-03 §1),不动内核——只用它的入参注入口子。
  • 🔴 从头自建(acdm-backend):opening-brief 编排接口、取数口径(界定上一场、跨会未闭环全集)、偏差判定五组规则、演进链折叠。deer-flow 自带"记忆"做不了这件事(不能按字段精确查、写完不能马上读、无项目隔离、更没有超期/反复卡这类业务判定),已在 FDS-17 确认不胜任,故自建。
  • 不重造:事实库表/查询/trace/可逆全复用 FDS-17,本章零新增表;待办状态机复用 B9,不在此重做。

7. 与人机协同模型关系 ​

对应模型里的项目工作台 → 任务卡片(开场对账卡):开场材料是一张项目级"上次承诺 vs 现在"的对账卡,人在产品内即可看到、点开核对、当场决定本场要处理哪些差距(继续追、改期、关闭)。它把 PDCA 的 C(检查)固化进每场会开场——AI 管"怎么把对照说清楚"(技能),正确性与口径由代码兜底(任务卡可审阅、可回溯出处)。

8. 验收(可证伪) ​

  • 可用:开下一场会的处理会话,无需任何操作,开场即出现上次待办对照;每条可 trace 回上次纪要原文位置且内容一致。
  • 可用:总览计数 = 各组按事项去重后之和;同一事项多次修订只算一件(不因 superseded 链重复计数)。
  • 好用:构造一条 due 已过且未完成的待办 → 必落"超期"且 days_overdue 正确;构造同一事项被 3 场会提及且未闭环 → 必落"反复卡"且 hit_count=3。
  • 好用:B9 刚把某待办改"已完成",立刻开场 → 该条进"完成"组而非旧状态(强一致,无缓存滞后)。
  • 兜底:项目首场会无上一场 → 开场明说"暂无上次对照",不报错、不杜撰待办。

9. 现状 ​

没有。当前既无项目事实库也无待办状态沉淀,更无"开场自动对账"——开会全靠人回忆上次说了什么、谁该做、做没做,漏项与超期无人系统性发现,"反复卡同一件事"从不会被自动指出。本章在 FDS-17 事实库 + B9 待办状态之上,补"开场即对照"这一步,把 PDCA 的检查环节落地。

10. 风险与取舍 ​

  • 风险:"没动"判定误伤——人做了但没在产品内更新状态,被开场点名"没动"。取舍:口径以产品内状态为准并在开场措辞里写明"以下据系统记录,如已推进请当场更新",把更新责任显性化;不靠模型猜"可能在做"。
  • 风险:"变了"依赖演进链,若 B9/B19 归并没接好,改了说法的待办识别不到。取舍:本章只读归并关系不自建;归并未就位时"变了"组可能为空(不杜撰),随 B19 完善而准确——降级不报错。
  • 风险:跨会未闭环全集越积越长,开场材料过载。取舍:开场只详列"超期 + 反复卡 + 上一场新增未闭环",更早的久未推进项折叠为一行汇总("另有 N 项历史未闭环,可展开"),不一次倒完。
  • 风险:开场措辞偏问责,影响会议氛围。取舍:技能定调"对账而非追责",只陈述事实与差距、点负责人不带评价;措辞改动走技能评审(FDS-04 三红线)。

开场对账完成。它与 B9(待办状态来源)、B12(周期复盘,同样只读事实库)同源同口径,确保"开场说的"和"复盘算的"永远是一笔账。

公司内部参考 · 由 claude-wiki-gen 基于源码自动生成的二次分析

a-cdm（公司内部）· deer-flow © ByteDance