广告关键词最容易被做成一个“大模型看表格”的 demo：上传报表，问它哪些词该否，哪些词该加。但真正跑过投放就会知道，单看 ACOS 很危险。ACOS 是结果，不是原因；低转化可能是相关性问题，也可能是样本没成熟，甚至只是最近 48 小时归因还没填完。
这类 Agent 的核心不应该是让 LLM 做最终裁决，而是让规则引擎和统计特征做判断，LLM 只负责解释结论、写运营备注和整理复盘语言。
五类数据源要先分工
- Search Term Report：负责真实 shopper query，是收词、否词和观察的主表。
- Targeting Report：负责当前 target 的表现，用来调 bid、保留或降级。
- Campaign Report：负责预算、placement 和节奏，不能单独决定某个 query 的命运。
- Advertised Product Report：负责 ASIN/SKU 承接基线，帮助判断商品页是不是拖后腿。
- 竞品 ASIN 反查词：只能做候选词发现，不直接当作投放真相。
判断顺序：相关性、样本成熟、价值密度
决策层按顺序走三关。第一关看相关性：词和商品、类目、属性是否冲突。第二关看样本：点击、订单和时间窗口是否成熟。第三关才看价值密度：CTR、CVR、CPC、Spend、Orders、Sales、RPC 和 ACOS 组合起来看。
不是 ACOS 低就加，不是 ACOS 高就砍；先确认它是不是该被比较。
用一条搜索词走完判断链
假设某个查询词与商品高度相关，近 30 天获得 18 次点击、2 个订单，ACOS 处在目标范围内。系统不会因为“有单且 ACOS 不高”就直接升词，而是继续检查原词是否已经存在、归一词是否与其他 query family 重叠、最近是否处于促销归因窗口，以及目标活动是否还有预算承接。只有这些条件一起成立，建议才进入 add_exact；否则先观察或进入人工复核。
单词复核顺序
先看商品相关性，再看点击与订单样本是否成熟；随后检查归因窗口、历史动作和词族重叠；最后才评估 ACOS、RPC 与建议 bid。任何一层证据不足，都不要直接输出执行动作。
从 raw query 到 action
- 保留 raw_query 和 canonical_query 两个字段，Exact 与 Negative Exact 看原词，Phrase/Broad 和聚类看归一词。
- 按服装类目抽取 gender、style、occasion、material、color、size、fit 等属性信号。
- 把同一意图的 child queries 聚合成 query_family，用于 phrase 扩展和 negative phrase 判断。
- 按不同粒度建立事实表，不把所有报表硬拼成一张万能大宽表。
- 生成 reason_codes、confidence、priority、recommended_bid 和 review_status。
{
"raw_query": "black cocktail dress women",
"query_family": "cocktail dress women black",
"action": "add_exact",
"recommended_bid": 0.79,
"confidence": 0.87,
"reason_codes": ["R01_high_relevance", "R02_sample_matured"],
"review_status": "pending"
}最终动作进入 review queue
MVP 的输出不应该直接改广告后台，而是生成 review sheet 和 bulksheet action file。高置信、低风险的动作可以批量确认；高花费、品牌词、竞品词、促销期和低样本判断则必须单独看。这样系统既能提高速度，也不会把误操作放大成真实花费。
这一篇和 R1–R6 那篇的关系是：R1–R6 更像一个已落地的调价规则骨架，而这里补上更完整的数据底座和决策分层。一个负责把规则跑起来，一个负责解释为什么规则应该这样分层。