02 · 跨库审核工作台

审核工作台V1.1 迭代设计

本库共 7 条待审 · 本页 4 条 · 服务端上限 50 条/页截断点名

混合检索的融合策略对比

PENDING_REVIEW科研语料库confidence 0.72

RAPTOR 树形索引要点

PENDING_REVIEW科研语料库confidence —

GraphRAG 社区摘要机制

CONTRADICTED方法学笔记confidence 0.41

存量条目（评审早于本列上线）

PENDING_REVIEW科研语料库从未检查过

队列不按前端 filter 状态生成：前端自己挑"待审核"等于把取值域抄第二份（FR-10）。

驳回不带理由 = 创建者只知道"被拒了"，不知道为什么，这一条在现网是真实痛点。

action	操作者	detail（按实际发生的量计数）
本次会话尚无操作。被门拒掉的操作一条都不写。

同一栏"评审记录"有三种值，界面必须长得不一样。现网曾把 null 和 [] 压成同一个空列表，于是 19 条活条目里 17 条被显示成「评审跑过，但没给建议」——库里没有这个结论，是接口替它编的（发现 138）。

qualityCheckedAt = null → 「从未成功检查过」，且发布按钮旁给"先跑质检"

qualitySuggestions = [] 且已检查 → 「跑过，没给出改进建议」

有值 → 逐条列出，措辞是「评审写下 N 条」而不是「质量问题 N 条」（发现 122：最长 78 行而该条目 0.88 分）

R7 队列由服务端出，带 total 与上限，界面不得把本页条数当总体。
R8 confidence=null 显示「—」，不显示 0.00、不参与阈值比较；三档发布判据（≥0.8 自动发布 / 0.5–0.8 待审 / <0.5 低置信）在评审未给分时一律落待审，不当 0 分。
R9 keyFacts 三态同 R8：null = 这一列从未产出（V13 前存量或正文被改写后作废），[] = 产出过而模型没给可核对事实。不许显示成"该条目没有关键事实"。
R10 来源清单是实际并入的文档（merged_doc_ids 透传），不是请求参数原样落库（发现 63）；点来源必须过读门。
R11 发布/驳回/回滚都是不可逆或影响对外答案的写操作 → 必须写审计，detail 写实际发生的量。
R12 驳回理由必填且非空白（服务端校验，不只前端 disabled）。
R13 CONTRADICTED 条目在队列里置顶且不隐藏——矛盾是最高优先级的待办，不是异常数据。