每次广告复盘都会落到同样三类表上：亚马逊后台的搜索词报告、卖家精灵反查自身 ASIN 的词表、反查竞对 ASIN 的词表。加起来几千行，过去的做法是在 Excel 里手筛——按流量排序、肉眼扫、凭感觉删。筛完之后没人能说清楚：同样一行词，上周为什么留，这周为什么删。
真正要解决的也不是把几千行压成几百行，而是保留判断过程：这个词来自哪张表、命中了哪条规则、为什么进入当前等级，以及哪些地方因为样本不足必须退回人工复核。只有这些信息一起留下来，清洗结果才不只是一份一次性的 Excel。
手筛的问题不是慢，是不可复现
手筛真正的代价有三个：同一张表筛两遍结果不一样；判断标准全在筛的人脑子里，没法交接给别人，也没法交给 Agent；每次都从零开始，上个月踩过的坑这个月原样再踩。速度反而是最不重要的问题。
清洗的价值不在删掉了多少词，而在每一次删除都有一条可以指出来的规则。
三类输入，一条流水线
流水线接受三个目录作为输入，但不会先把三类数据粗暴合并。后台搜索词提供真实点击、花费、订单与 ACOS；自身反查表补充当前覆盖；竞对反查表提供待筛选候选词。三条支路先各自完成字段映射和质量检查，再在规范词组层面建立关系。
data/
├── backend_search_terms/ # 亚马逊后台真实搜索词表
├── own_reverse/ # 自身 ASIN 的卖家精灵反查词表
└── competitor_reverse/ # 竞对 ASIN 的卖家精灵反查词表
运行前检查清单
确认产品代码；分别放入后台搜索词、自身反查词、竞对反查词；检查关键列是否存在；确认目标款是否有后台样本；若需参考同类规则库，先说明参考范围与降级标记。
一行词如何走到建议动作
- 读取原始文件并按字段别名映射统一列名；缺少关键列时停止当前支路，不用空值伪造结果。
- 规范大小写、空格、变体和词根，把可以比较的表达折叠到同一规范词组。
- 用后台表现、核心词根、排除模式与自身覆盖交叉判断，记录命中的规则和来源。
- 对竞对候选词计算等级与建议动作；证据不足的词进入降级或复核队列，不冒充确定结论。
- 生成 Excel 交付包、分类与映射 CSV、关键词规则库 JSON，并把读取、判断和异常写入 run.log。
规则负责确定性，人工负责不确定性
当前实现没有把模糊词条直接交给模型拍板。无效字符、明确排除词、核心词根、后台高花费无订单等确定判断由配置化规则处理；后台样本不足、同类参考不充分或相关性证据冲突时，结果会显式降级并保留风险提示。
新品没有后台搜索词时，流水线也不会静默套用旧规则。只有先确认可参考的同类规则库，才会以参考模式继续，并在结果中标记没有使用目标款后台数据。这个边界牺牲了一点自动化程度，却避免把“有输出”误写成“有依据”。
能自动判断的交给规则；证据不够的，就把不确定性原样交还给人。
打包成平台中立的 Agent Skill
整条流水线最终打包成一个 Agent Skill：说明文档定义三目录输入约定、产品代码、执行顺序和交付标准，Python 包负责实际清洗，配置文件保存字段映射、筛选规则与输出结构。Agent 不需要重新理解业务，只需要按契约检查输入、执行脚本并核对产物与 run.log。
Lab 里的 keyword-cleaner 工具就是这条流水线的在线演示：同样的清洗逻辑，换成了浏览器里可以看的流程动画和预生成结果。
固化之后的变化
- 结果可复现：相同输入与相同配置会得到一致结果，复盘时可以从产物回到命中规则。
- 标准可交接：筛选逻辑从人的经验变成仓库里的配置与执行契约，Agent 和同事使用同一套边界。
- 异常可见：缺列、样本不足、参考规则和降级原因不会被藏进一张看似完整的表里。
- 资产可维护：换品类时可以明确区分通用流程、字段映射和需要重新确认的类目规则。
这条流水线先解决“什么词值得进入候选池”。下一步才是把分级后的词交给广告规则引擎，结合毛利、阶段和历史动作决定如何测试；清洗与投放各守一段边界，避免一套规则同时承担两个问题。