FDS-16 · B7 存疑点人工确认

模型拿不准的地方不让它瞎猜:挑出来,生成一条站内确认任务派给对应负责人,流水线在这一步先停下来存档;人在产品里答完,流水线从停的地方接着跑、只重算被这条答复影响到的内容,确认结果(含确认人)进事实库。

1. 业务说明

抽取(B5)产出一批结论,出处校验(B6,见 FDS-15)做完程序硬规矩后,会剩三类模型靠自己定不下来的条目:

• 出处校验没过:抽出来的话在原文里找不到对应位置,或位置对不上(B6 判为存疑)。
• 抽取置信低:模型自己都标了"没把握"(置信低于阈值,见 FDS-12/14)。
• 同一事实跨处冲突:同一件事在会里前后说法不一致(如"周五交付"和"下周一交付"都出现),或与已入库的旧事实矛盾。

这三类条目不能让模型猜一个填进事实库——猜错了,下游待办、看板、复盘全跟着错,且看不出错在哪。B7 的职责:把每个这样的疑点,变成一条结构化的站内确认任务(说清楚疑点是什么、给出候选答案、能点回原文那一句、指派给对应负责人),会议处理流水线在这一步暂停;负责人在站内(项目工作台的待办面板)看到并回答;答复写回后流水线从暂停处继续、只重算受影响的条目,不整场重来;确认后的结果(带"谁确认的")写入事实库。

为什么这样设计:正确性的底线是"不确定的不猜";但"不猜"不等于"卡死"——靠已经在生产跑通的 ba_report 做法(流程中途暂停存档、人答后从断点接着跑),把人的判断异步接进自动流水线,既不瞎编,也不让整条流水线干等或重来。

不做会怎样:要么模型瞎猜污染事实库(现在的老问题:又不准又不可追溯),要么一遇到拿不准就整场失败让人从头再来(贵且体验差)。

2. 用户操作与界面

负责人全程在站内,不接飞书/企微/邮件(全局约束〇):

1. 流水线跑到 B7,某条结论存疑 → 系统生成一条确认任务,站内消息提醒对应负责人(谁负责由指派规则定,见 §4),会议处理状态显示为"等待人工确认"。
2. 负责人在项目工作台 → 待办面板看到这条任务卡:一句话疑点说明、几个候选答案按钮(含"都不对,我来填""此条作废")、一个**「看原文」**链接(点开跳到精修稿对应那句、高亮)。
3. 负责人选一个候选或自己填写 → 提交。可附一句理由。
4. 提交后任务卡转"已确认",会议处理状态自动从"等待人工确认"恢复为"处理中";稍后该会结果页/看板上这条结论生效,可点开看出处与"由 XXX 于 X 时确认"。
5. 一场会有多个疑点 → 一批任务,全部答完(或显式作废)流水线才继续。负责人可在面板里一次处理多条。

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

确认任务表 awaiting_clarification(一条 = 一个待人确认的疑点):

字段	类型	说明
id	uuid PK	确认任务唯一 id
project_id	uuid, 索引	所属项目(隔离边界,所有查询强制带,沿用现有权限校验)
meeting_id	uuid, 索引	来源会议
run_id	text, 索引	该会流水线运行 id(回灌时定位是哪次暂停,对应 ba_report 的运行态)
issue_id	text	疑点 id(= 被存疑的抽取条目 id;答复后据此精确定位重算谁)
issue_type	enum	source_unverified(出处没过)/ low_confidence(低置信)/ conflict(跨处冲突)
context	jsonb	疑点说明 + 上下文:{summary, kind, conflicting_values?, neighbor_text}(给人看清楚到底在拿不准什么)
candidates	jsonb	候选答案数组:[{label, value}] + 固定项("自填""作废")
source_ref	jsonb	原文定位:{file_id, char_start, char_end, speaker, ts}(「看原文」据此跳转高亮,与事实库 source_ref 同形)
assignee	uuid	指派给的负责人(由 §4 规则解析,落具体人,不落"角色"以免无人认领)
status	enum	open / answered / cancelled / expired
answer	jsonb null	负责人答复:{chosen_value, free_text?, reason?}(answered 时必填)
answered_by	uuid null	实际回答人(= 确认人;回灌事实库时写入 confirmed_by)
answered_at	ts null	回答时间
due	ts null	期望答复截止(到点未答→提醒升级,见 §4;不自动猜答)
created_at	ts	创建时间(= 流水线暂停时刻)

辅助:clarification_events(留痕:建任务 / 提醒 / 回答 / 升级 / 作废,各带时间与操作人,供审计与"为什么这条是这个值"回溯)。 索引:(project_id, status)、(assignee, status)(负责人面板按"待我确认"拉)、(run_id)(回灌按运行态定位)。

接口(acdm-backend 提供;流水线与前端经此交互,模型不直接碰确认逻辑):

• POST /clarifications/batch:流水线在 B7 暂停时调用,把本场所有存疑条目批量建任务;入参带 project_id、meeting_id、run_id、每条 issue 与 source_ref;返回任务 id 列表(同时触发站内通知 + 解析 assignee)。
• GET /clarifications?assignee=&status=open:待办面板拉"待我确认"列表(强制带 project_id)。
• GET /clarifications/{id}:取单条详情(含候选、原文定位)给任务卡。
• POST /clarifications/{id}/answer:负责人提交答复;写 answer/answered_by/answered_at、status=answered;当且仅当本场全部任务 answered/cancelled 时,发"从断点续跑"信号给流水线。
• POST /clarifications/{id}/cancel:负责人显式作废该条(对应"此条作废":该抽取条目不入事实库,记 dropped)。
• GET /clarifications/{id}/trace:取原文定位(给「看原文」跳转高亮,复用事实库 trace 同款定位逻辑)。

与事实库(FDS-17)的衔接:答复回灌、流水线重算后,受影响条目经事实库 POST /facts/commit 写入,status=confirmed、confirmed_by=answered_by;显式作废的条目记 status=dropped;不重新生成的旧条目不动。

4. 技术实现(分步)

1. 暂停并存档(照 ba_report 做法):会议处理流水线在 B6 之后、写事实库之前注册一个暂停点。B6 产出存疑条目后,流水线按 ba_report 已上线写法逐步存档当前运行态并在此步前停住——"中断/续跑"在这里的意思就是:把流程当前进度完整存档、人答完之后从这个断点接着往下跑,不是丢弃重来。引擎机制本身不改(🟢 复用,见 §6)。
2. 建确认任务:流水线暂停的同时调 POST /clarifications/batch,把每条存疑条目落 awaiting_clarification:
   • 疑点说明与上下文(context)由 B5/B6 的产出直接组装(出处没过给原文未命中说明;低置信给模型不确定点;冲突给两个矛盾取值并列)。
   • 候选(candidates):出处没过→候选含"原文这句的实际表述"与"删除此条";低置信→模型给的 top 几个解读;冲突→并列各冲突值;固定追加"自填""作废"。候选只是减负,绝不替人决定。
   • source_ref 沿用 B5 抽取时记的原文位置(FDS-12/14 已带),保证「看原文」能精确跳转。
3. 解析负责人(指派):assignee 解析顺序——① 该条目本身带的负责人(如待办类抽到了 owner);② 否则按疑点 kind 走项目配置的确认负责人映射(如风险类→项目经理、决策类→组织者);③ 兜底→会议组织者。落具体人,不落角色(避免"大家都以为别人会答")。
4. 站内通知:建任务后经 deer-flow 站内通知能力(🟢 复用)给 assignee 推一条站内提醒;不接任何外部 IM(全局约束〇)。到 due 未答 → 升级提醒(再提醒 + 抄送组织者),仍不自动替人猜答。
5. 收集答复:负责人在待办面板提交,走 POST /clarifications/{id}/answer,记 answer/answered_by/answered_at。
6. 答复回灌 + 续跑:本场全部任务 answered/cancelled 后,acdm-backend 把答复写进该 run_id 暂停态对应槽位(对应 ba_report"把人的答复写进去再续跑"),然后给引擎发从断点续跑信号。流水线从暂停点继续。
7. 只重算受影响条目:续跑后,仅对被答复影响的 issue_id 条目重做后续(用确认值替换/修正该条),其余已通过 B6 的条目原样带下去不重算;作废条目剔除。最终经事实库接口写入:确认的 status=confirmed+confirmed_by,作废的记 dropped。这正是 ba_report"只跑后面没跑的步、不整场重来"在本场景的落地。
8. 隔离与可逆:所有确认任务接口强制 project_id(沿用现有权限校验);所有动作进 clarification_events 留痕(谁、何时、改了什么),可审计、可回溯"这条为何是这个值"。

5. 技能 or 代码

• 全部代码(acdm-backend + 引擎现成的中断/续跑机制)。确认任务的建立、指派、状态机、答复收集、回灌、隔离、留痕,都是确定性 + 强一致的事,不允许做成技能让模型参与——模型只负责更早的精修/抽取(B3/B5),拿不准的恰恰是要交人的,绝不能再让模型在这步替人拍板。
• 引擎的"暂停存档 / 断点续跑"按 ba_report 已上线做法直接复用,引擎不改。

边界:这一步没有模型决策。模型的产出到 B6 为止;B7 纯粹是"把人接进来"的工程机制 + 站内异步派人。

6. 二开归类

🟢 复用 + 🔴 自建。

• 🟢 复用:"流程中途暂停 → 等人确认 → 从断点继续、只跑没跑的步"这套机制,照公司已上线的 ba_report 做法用(流水线编译时带逐步存档 + 在 B7 步前暂停;答复写入后从断点续跑)。这是已在生产跑通的现成做法,引擎内核不改(扩展位见 FDS-03 §1/§2)。会议流水线本身在流水线注册位按此写法编译(🟡,见 FDS-03)。站内通知也复用引擎现成能力。
• 🔴 自建(acdm-backend):站内异步派人整层——awaiting_clarification 确认任务表、按负责人指派的解析规则、站内通知触发与到期升级、把答复收集并回灌进暂停态再触发续跑的桥接、与事实库的衔接(确认结果入库带 confirmed_by)。

为什么自建这层:引擎自带的"提问/确认"只能在同一对话里当场问操作者本人,不能异步派给指定的、可能不在场的另一个负责人,也没有任务表/指派/到期升级/回灌桥接——这部分 deer-flow 没有,必须在 acdm-backend 写。

7. 与人机协同模型关系

正是模型里**"AI 与人共写"**的关键落点:任务流(会议流水线)跑到拿不准处,主动停下来生成一张任务卡(确认任务)交人,人在项目工作台答完,任务流凭这个答复继续。事实库里这条因此带 confirmed_by——人和 AI 共同对它负责、可追溯到具体人。和 B9 待办"默认待确认"一致:不确定的东西默认归人拍板,不让 AI 替人做主。

8. 验收(可证伪)

• 可用:制造一条出处对不上 / 一条低置信 / 一组前后冲突的条目,B7 各生成一条 awaiting_clarification,流水线状态变"等待人工确认"并停住不写库;对应负责人收到站内提醒(无任何外部 IM 调用)。
• 可用:任务卡点「看原文」能跳到精修稿对应那句并高亮(source_ref 准确)。
• 可用:负责人答完最后一条 → 流水线自动从断点续跑;只重算被答复影响的条目,其余已过 B6 的条目内容逐字不变(对比续跑前后);确认条目入事实库 status=confirmed 且 confirmed_by = 实际回答人。
• 可用:显式"作废"的条目不进事实库(记 dropped);全程动作在 clarification_events 可查到操作人与时间。
• 好用:一场多疑点时,负责人在待办面板一处批量处理;到 due 未答有升级提醒且系统不擅自猜答。

9. 现状

没有。引擎自带的确认只能在同一对话里、对当前操作者本人当场提问,无法异步派给指定的别人,也没有确认任务表、按负责人指派、站内通知、到期升级、答复回灌的桥接。现状下遇到拿不准只能模型猜(污染结果)或整场失败(从头重来)。本章从零建"站内异步派人确认"这一层,把已上线的 ba_report 暂停/续跑做法接进会议流水线。

10. 风险与取舍

• 风险:疑点过多 → 负责人被一堆确认任务淹没。取舍:B6 阈值与候选要"精而准";同会同类疑点在面板合并展示批量处理;只有真定不下来的才转 B7,常规走自动。
• 风险:负责人长期不答 → 流水线一直挂着。取舍:到 due 升级提醒 + 抄送组织者;绝不自动猜答(自动猜答会重新打破"不瞎编"底线)——挂着是预期行为,靠站内催办闭环,不靠模型兜底。
• 风险:回灌后"全量重算"会很贵且引入新错。取舍:严格只重算受影响 issue_id 条目,其余已过 B6 的条目原样带下去——这正是 ba_report"只跑没跑的步"做法,不是另起炉灶。
• 风险:指派落到"角色"导致无人认领。取舍:assignee 一律解析成具体人并兜底到组织者;指派规则可在项目配置维护(谁负责哪类疑点)。
• 风险:候选答案诱导负责人随手选错。取舍:候选只作减负、永远保留"自填/作废",答复可附理由并全程留痕,事后可审计与纠正(配合事实库可逆)。

拿不准的交人、人答完接着跑、确认的进库带确认人——会议流水线到此完整。下一章 FDS-17 即这条线的终点与地基:项目事实库。