Elements Claw 负责把候选结构批量产出来，但“能不能合成”这一步不该继续留在输出端回答。通常的做法是：结构生成和条件筛选归输出端，可合成性判断和实验设计归实验端，两边靠固定字段交接；每条候选要写清判断依据来自哪一侧，缺了就按缺项走流程，而不是先排实验再补信息。

把 Elements Claw 当候选生成器用，而不是当合成性裁判：结构生成、条件筛选由输出端承担，可合成性判断与实验设计由实验端拍板。交接时随附结构描述、约束条件、输出依据、待确认项四类字段，缺字段的候选不进排期。判断不了的候选只走挂起、补信息、退回三条路径，每条都指定负责人和补齐期限，避免长期悬置。

列一份职责划分表，逐项标注由谁承担

分工模糊的典型症状是：输出端给了“看起来可行”的排序建议，实验端照单排期，最后卡在试剂或设备上。把下面这张表放进交接文档或工单模板，每项写清承担方和判断依据来自哪一侧，比口头约定省事。

表里最容易出问题的是“可合成性判断”这一行。输出端可以给可行性排序建议，但这类建议只能当排序参考，不能当合成结论；只有判断依据标注为来自实验端的候选，才允许进入实验设计环节。

把可合成性相关判断逐项落到实验端

下面这些判断项本质上都要实验现场的信息才能成立，通常不要由输出端下结论，每项都要说明还缺什么才能判断：

• 原料与前驱体可得性：需要补充库存量、纯度、杂质谱，以及前驱体是否需要自行制备。
• 反应条件窗口：需要补充温度、压力或气氛、溶剂、时间、投料比的可接受范围，以及越界后的现象描述。
• 热力学与动力学可行性：需要补充类似结构的实验记录、参考路线，以及是否需要额外活化条件。
• 副反应与杂质容忍度：需要补充可接受的杂质上限，以及现有表征手段能分辨到什么程度。
• 安全与放大：需要补充放热情况、毒性、通风与压力容器条件，判断能否从毫克级往更大规模推。
• 表征与验证手段：需要确认现有仪器（按场景替换为 XRD、NMR、IR 等）能否识别目标产物，样品量下限是多少。
• 设备与排期：需要补充设备占用、人员工时、耗材到位时间。

这些判断项的共同点是：缺一项具体信息，结论就可能翻转。所以交接时别把“可行/不可行”当字段值，而是把“还缺什么”当字段值传递，让实验端一眼看出要补哪一步。

约定候选交接时随附哪些字段

字段约定的目标是让实验端拿到候选就能判断要不要接，而不是先来回问一轮。下面是一份通用骨架，字段名可按团队现有工单模板替换，结构不建议删减：

{
  "id": "claw-0001",
  "structure": {
    "name": "",
    "formula_or_smiles": "",
    "key_skeleton": "骨架、官能团、连接关系",
    "uncertainty": "不确定的位置，留空表示结构明确"
  },
  "constraints": {
    "temperature_range": "",
    "pressure_or_atmosphere": "",
    "solvent": [],
    "reagents_on_hand": [],
    "forbidden": []
  },
  "basis": {
    "source": "规则 / 相似结构 / 参考路线",
    "assumptions": [],
    "not_checked": []
  },
  "pending": [
    { "item": "前驱体纯度", "owner": "experiment", "needed_info": "" }
  ],
  "status": "generated"
}

四类字段缺失时的处理方式可以固定下来：

• 结构描述缺失（关键位置不明确、连接关系写不清）：直接退回输出端，不进入实验评估。
• 约束条件缺失：候选标为待补，实验端只做上限判断，不据此设计路线。
• 输出依据缺失：候选降级为参考项，不进排期，只保留在候选库里。
• 待确认项缺失：视为存在未声明的风险，默认挂起，不默认放行。

遇到无法判断的候选怎么处理

灰色地带要有一个固定动作，否则候选会一直躺在“待评估”里，谁也说不清是没人看还是看不了。建议只保留三条路径，并且给每条写清触发条件。

挂起

触发条件：关键信息暂时拿不到，但可以预期补齐，比如库存待查、设备占用待确认。动作是状态改为挂起，指定一名负责人和补齐期限；期限到了仍拿不到信息，自动转到退回，而不是无限延期。

补信息

触发条件：判断只缺一两个具体数据，比如纯度、温区、表征下限。动作是生成一条最小信息请求，只问必要项，不把整份候选重写一遍；补齐后回到评估队列，由实验端给结论。

退回

触发条件：结构本身不明确、与约束条件直接冲突，或者安全与设备明确不支持。动作是退回输出端，并在退回理由里写清是哪一条约束不满足，避免带着“可能可行”的模糊描述在原队列里反复流转。

状态字段建议只保留 generated、blocked、needs-info、rejected、accepted 这几种，每次状态变更记录谁改的、依据是哪条信息。这样做的验证方式很直接：翻任意一条候选的历史，能看出它为什么停在当前状态、下一步归谁处理。