材料筛选流程里真正要问的不是「Elements Claw 能不能用」，而是每一步的判断依据是什么。依据落在检索条件、字段比对、历史相似案例召回上的环节，通常可以移交；依据落在配方或工艺取舍、失效模式判断、批次放行责任上的环节，建议仍然由人拍板。下面按判断点盘点、移交划分、接入与确认、完整流程记录、不确定项标注五段展开。
可移交的是检索与比对型判断：材料是否命中给定条件、字段是否缺失、历史记录里有无同类案例。不可移交的是经验型判断：指标冲突时以哪项为主、边缘数据是否需要补充、某异常能否接受。做法是先登记判断点，再接调用，模型只产出候选结论；落库后由人把确认状态从 pending 改为 accepted 或 rejected，rejected 退回人工队列。模型输出只能作为候选，不能直接进入放行、归档这类有后果的记录。
把现有流程每一步的判断点挑出来
盘点时不要按「入库—评估—复议」这种步骤名走，那样看不出哪里能移交。要按判断来拆：这一步到底在判断什么、依据从哪来、判错会怎样。登记表建议至少包含四个字段：步骤、判断内容、依据来源、出错后果。
- 步骤：判断发生在流程的哪个位置，例如材料入库初筛、硬性条件比对、相似案例召回、边缘值复议。
- 判断内容：一句话说清在判断什么，例如「材料描述中是否出现指定关键词」「某项指标是否落在给定区间」「历史上是否存在同编号材料的处理记录」。
- 依据来源：判断时实际看的是什么，例如筛选条件清单、材料描述字段、历史记录表、实验报告结论、人工经验。
- 出错后果：判错之后会流向哪里，例如无关材料进入人工复核、合格材料被漏掉、异常材料进入放行记录。
登记时常见的问题是写得太笼统，比如「评估材料是否可用」。这种写法既看不出依据来源，也看不出谁负责，后面的移交划分就没法做。登记完会得到一张判断点清单，后续讨论只在清单上做，不再重新理解流程。
区分检索型判断与经验型判断
区分标准可以先看三条：判断依据能否写成明确条件（字段、区间、关键词、可检索范围）；判断是否需要跨批次经验或隐性知识；判断出错的后果是否落在放行动作和责任上。第一条满足、后两条不明显的，通常属于检索型；后两条明显的，属于经验型。
- 检索型示例：材料描述是否包含指定关键词；指标数值是否落在给定区间；编号或批次字段是否缺失；历史记录中是否出现过同类案例。
- 经验型示例：多项指标互相冲突时以哪项为主；边缘数据是否需要补充实验；供应商说明与历史表现不一致时采信哪一方；某类异常是否属于可接受范围。
经验型判断必须留在人这一侧，原因不在模型能力，而在依据来源。这类判断的依据往往不写在材料或文档里，而在人处理过的案例和后果记忆里。模型可以给出相似的说法，但被追问「为什么是这一项优先」时，它说不清依据，也无法承担放行责任。把经验型判断移交出去，等于把依据和责任一起交掉，出问题时既没有可追溯的判断链，也没有明确的决策人。
给可移交环节接上调用并保留确认动作
调用位置建议放在「筛选条件已经确定、结论记录尚未生成」之间，这样模型只处理候选判断，不参与条件本身的确定。下面是一段通用骨架，字段名和路径按实际服务替换。
POST /<你的接入地址>/screen
{
"task": "material_screening",
"criteria": ["<条件A>", "<条件B>"],
"items": [{"id": "<材料编号>", "text": "<材料描述或摘要>"}],
"output_schema": {
"decision": "hit | miss | uncertain",
"reason": "string",
"evidence_refs": ["<原文位置>"]
}
}返回结果落库时，human_confirm 默认写成 pending，不要默认 accepted。
INSERT INTO screen_result (
run_id, item_id, source_step, model_decision, model_reason,
uncertainty_flag, human_confirm, confirm_by, confirm_note, created_at
) VALUES (
:run_id, :item_id, '<流程步骤名>', :decision, :reason,
:uncertain_flag, 'pending', NULL, NULL, :ts
);确认动作放在落库之后、结果被下游引用之前。执行筛选的人逐条看 model_decision 与 model_reason，把 human_confirm 改成 accepted 或 rejected。确认不通过时不改模型返回的字段，只把该条记录退回人工处理队列，写明退回原因，由人重新判断。下游查询只读 human_confirm = 'accepted' 的记录，这样即使模型输出有问题，也不会绕过确认关口进入后续结论。
跑一次完整流程并记录每步的实际输入产出
选一批材料覆盖命中、未命中、边缘三类，走完整流程，用同一个 run_id 串起来，逐步记录：步骤名、输入、产出、确认结果、时间、操作人。输入要写清材料编号和参与判断的字段内容或文件位置；产出要同时保留模型原始返回和最终采纳的结论，不要只留改写后的版本。
- 入库初筛：输入材料编号与描述，产出是否进入范围，确认结果为 accepted 或 rejected。
- 条件比对：输入进入范围的材料与筛选条件，产出逐条的 decision 与 reason。
- 人工确认：输入模型返回，产出确认后的结论与退回记录。
- 结论归档：输入 accepted 记录，产出最终清单。
定位断层时按 run_id 排序逐条比对：上一步产出的编号或字段，是否完整出现在下一步的输入里；下一步用到的字段，是否在上一步有明确来源。出现下面任一情况，断层就在那一步：某步有输入没有产出；产出缺少下游需要的字段；产出被下游改写但没记录改写原因；确认结果为 rejected 的记录仍被下游引用。把断层的步骤名和缺失字段一起记下来，比笼统写「流程不通」更容易修。
记录它对不确定项的表达方式
模型对判断没把握时，表达方式通常有迹可循。需要留意的特征包括：decision 直接返回 uncertain；理由里出现「可能」「无法确定」「取决于」「需补充信息」「存在两种解释」「条件不足」这类说法；evidence_refs 为空，或引用的位置在原始材料里找不到对应内容；同一材料在不同条件下返回互相冲突的结论；理由只是复述了筛选条件，没有说明材料中哪一处支持这个结论。
出现上述任一特征时，这条输出在下游记录里必须标注为待确认，例如 need_review = true 或等价字段，并写清待确认的具体问题。不要因为结论文字看起来合理就把待确认标注省掉，也不要把它当确定结论引用到归档清单、放行记录这类有后果的位置。标注本身是给人看的入口，人看到标注后才知道该去核对哪一条依据。