先定清楚要筛的元素组合——Elements Claw 才能给出可验证的候选

输入写成一段自然语言描述时，返回的候选往往看起来都合理，但你没法说清某个候选为什么被选中，也说不清换一组约束后结果还会不会一样。要解决的是可复现和可归因：先把要筛的元素组合拆成有名有姓的枚举项，再给每条约束标上单位和取值范围，最后用小批量输入确认约束真的被用上了。Elements Claw 在筛选环节能给出多少可验证的候选，很大程度上取决于喂进去的输入是否结构化到可以逐条改动、逐条对比。

适用场景：候选看着都合理、但无法复现也无法归因的筛选任务。操作动作：元素组合写成枚举项，约束写成带单位、带区间的字段，先用小批量（几条到几十条，按自己的场景定）跑通。验证方式：固定其余输入只改一个约束，比较两次输出的差异是否与该约束的方向一致。风险边界：模板只约定输入结构和记录方式，不承诺工具内部如何解释字段；字段名与单位含义仍需在自己的环境里逐条确认。

把元素组合写成枚举式输入而不是一段描述

一句话描述的问题不在长短，而在于每次转述都会变形：今天写“高比例的主元素”，明天写“主元素占大头”，工具无法判断这是同一个意思，你也没法拿两次结果做对比。建议把输入拆成三块分列书写——元素集合、约束、结构类型——每块用枚举项而不是形容词。下面是一个通用骨架，所有尖括号内容都是占位符，需要替换成自己的字段名和取值，不涉及任何具体接口。

task: <筛选任务短名>

elements:                 # 元素集合，一项一行
  - name: <元素名>
    role: main | aux | optional

constraints:              # 约束，一条一行
  - field: <约束字段名>
    unit: <单位>
    min: <下限>
    max: <上限>
    required: true | false

structure:                # 结构类型分列，不用自然语言描述
  - type: <结构类型标识>
    weight: <数值>

batch:
  size: <整数>
  seed: <整数>

output:
  format: candidates | candidates_with_reason

替换时有三点要守住：role 用固定枚举值，不要写“主要”“次要一点”这类程度词；structure 里的 type 必须来自一份事先约定的标识清单，新类型先加清单再进输入；batch.size 先给小值，跑通再放大。这份骨架可以放在一个单独文件里执行，方便和上一次输入逐行 diff。

给每个约束标上量纲和取值范围

同一件事用不同单位表达，是结果漂移最常见的原因：百分比和小数混写、微米和毫米混写，工具按哪套解释取决于输入本身，不取决于你的本意。建议每条约束都补齐字段名、单位、上下限、是否必需四项，缺一项就别进输入。

composition_ratio｜质量百分比 % 或质量分数，二选一并写死｜0–100 或 0–1｜必需
phase_fraction｜体积分数或质量分数，选一种并标注｜0–1｜必需
particle_size｜微米或毫米，只写一种｜0 到环境中确认过的合理上限｜视场景
count｜个｜大于等于 1，并给一个上界｜必需
structure_type｜枚举标识｜取值来自约定清单｜可选

一条填写示例（其余约束照此格式补齐）：

- field: composition_ratio
  unit: mass_percent      # 本文件统一用质量百分比，不混用小数
  min: 5
  max: 15
  required: true

把单位约定写在文件头注释里，同一批筛选任务的全部输入共用一套单位。需要改单位时，改文件头加注释说明，不要在一份输入里两种写法并存。

用小批量输入验证输出是否随约束变化

约束写进文件不等于被读到。最省事的确认方式是小批量对照：固定其余输入，只动一个约束，看输出有没有往该动的方向变。步骤可以按下面走。

用完整约束跑一次，作为基线，记录候选数量和候选标识清单。
复制基线输入，只改一个约束的值（例如把 max 从 15 调到 12），其他字段逐字不动。
再跑一次，对两次输出做集合比较：交集有哪些、只在基线出现的有哪些、只在新输入出现的有哪些、有没有候选落在新约束区间之外。
如果收窄区间后输出完全没变，通常说明该字段名没被识别、单位被当成另一种解释，或者这条约束本身对当前候选集不起作用——先用其他字段复核，再判断是输入问题还是约束冗余。
如果输出变化方向相反（收窄反而变多），优先检查小数和百分比是否被反解，再检查 required、min、max 有没有写错位置。

对比结果建议直接用表格记录，字段如下，一行一次对照：run_id、baseline_run、changed_field、old_value、new_value、candidate_count、added、removed、violated、note。note 一栏写清“方向是否符合预期”，以后回溯时比数字本身更有用。

把验证通过的输入固化成可复用文件

验证通过的输入不要只留在对话框或临时脚本里。建议按“输入与运行记录分开”的方式组织目录：

filters/
  <组合名>/
    input.v1.yaml          # 已验证通过的输入
    constraints.v1.csv     # 约束表，版本号与 input 一致
    README.md              # 字段含义、单位约定、取值清单
runs/
  <组合名>/<YYYYMMDD-HHmm>/
    input.snapshot.yaml
    constraints.snapshot.csv
    candidates.jsonl
    compare.csv
    meta.json

命名规则：组合名-版本号-执行时间。input 和 constraints 的版本号必须一致，改动任何一个字段都要升版本并新增文件，不要原地覆盖，否则对照记录会失去参照。README.md 里写清每个字段的含义和单位，别人接手或自己三个月后回看时不用猜。

每次执行都要保存元信息，至少包含：执行时间、输入文件路径与内容哈希、约束版本号、执行脚本或命令的标识、本次结果文件清单、执行人。这些信息放在 meta.json 里，和结果文件同目录。缺少元信息的运行记录，下一次只能靠记忆复现，小批量对照也就白做了。先固化一条验证通过的输入，再在此基础上增量调整约束版本，比每次重写一份描述稳定得多。