广告周会最常见的场景：打开投放报告，一行一行看，凭经验说「这个降一点、那个先观察」。同样的数据，不同的人给出不同的结论；同一个人，两周后也未必记得上次为什么这么调。调价这件事长期停留在手感层面，既没法复盘，也没法交接。
所以我把自己的调价逻辑写成了明文标准，再把标准做成可执行的规则引擎：每周一读三份后台报告和一本台账，输出周诊断报告和四张待确认清单。系统负责把证据、规则与建议动作排好，人仍然负责确认并在后台执行。
一切从毛利率出发
规则引擎只有一个锚点：目标 ACOS = 款毛利率 × 阶段系数。新品期、成长期、稳定期的系数不同，但都从「这个款还剩多少利润空间」推导，而不是从「别人 ACOS 多少」出发。点击量门槛也不是拍出来的，由参考转化率反推——换一个类目，只需要改 reference_cvr 一个参数，整套门槛跟着变。
这里刻意把业务参数和判断逻辑分开：毛利率、阶段系数与参考转化率可以按款和阶段调整，R1–R6 的优先级与保护规则保持稳定。配置变化可以单独审阅，不需要为了改一个阈值重写整段脚本。
六条规则，覆盖四类动作
- R1 止血：累计点击达到门槛仍零出单，主位置竞价降 20%；上周已触发过 R1 的，直接建议暂停或否定。
- R2 降温：窗口内点击足够且 ACOS 超过目标 1.5 倍，降 18%。
- R3 加码：窗口内出单达标且 ACOS 不超目标，提 12% 或追加预算。
- R4 保曝光：折算 7 天曝光低于 500，提 10%，防止词被饿死。
- R5 升词：搜索词出单达标且 ACOS 在目标 1.2 倍内，升精准投放并在源活动否定；升之前先撞台账查重。
- R6 拉黑：搜索词点击达到门槛仍零出单，精准否定并写入台账黑名单。
六条规则不是六个彼此独立的 if。一个投放对象可能同时满足低曝光、ACOS 偏高和零订单条件，如果没有冲突处理，系统会在同一周给出相反动作。真正决定规则引擎是否可用的，是规则之上的保护层。
人工复核问题
这条建议用了哪段时间窗口？触发了哪条规则？是否与更高优先级规则冲突？上周是否已经执行过同类动作？建议幅度是否超过单次保护线？如果暂不执行，需要留下什么原因？
先处理规则冲突，再生成动作
- 一周一个动作：每个投放对象只保留一个建议，优先级 R1 > R2 > R3 > R4，避免同一对象又降又提。
- 限制单次调幅：竞价变化不超过 20%，规则再激进也不允许一步到位。
- 保留人工确认：引擎只生成执行清单，不登录广告后台，也不自动写入竞价或否定词。
- 换算可复核：按底价与位置溢价换算有效竞价，清单同时保留计算后的竞价和溢价百分比。
规则引擎的意义不是比人聪明，而是把「上次为什么这么调」变成一件可以查的事。
三份报告如何汇成一轮诊断
投放报告负责对象级点击、花费与订单，搜索词报告负责真实查询词和升词、否定判断，展示位置报告补充位置表现；台账则保存款的毛利参数、活动阶段和历史动作。报告提供本周证据，台账提供连续记忆，两者缺一不可。
- 从后台下载三份报告：投放报告（近 60 天）、搜索词报告（近 60 天）、展示位置报告（近 30 天），混放进 reports 目录即可，报告类型按列自动识别。
- 跑一次 diagnose，输入报告和当前台账。
- 得到周诊断报告、四张执行清单（调价 / 否定 / 升词 / 新开，每张带「已执行」勾选列）和更新版台账。
- 人工检查异常项与高影响动作，再到后台执行；完成后勾选「已执行」，把结果带入下一周。
python scripts/ad_architect.py diagnose \
--reports-dir ./reports \
--ledger ./台账.xlsx \
--output-dir ./output台账是记忆，init 是迁移
台账记录每个款的毛利参数、每个活动的阶段和历史动作，是规则引擎的长期记忆：R5 升词前要撞台账查重，R6 的黑名单也落在台账里，避免同一个词反复升、反复否。存量的老活动则由 init 模式接管——读一份投放报告，生成台账初始版和一张《改名对照表》，把历史命名逐步迁移到标准架构，而不是推倒重来。
报告回答这一周发生了什么，台账回答上一次已经做过什么。
当前边界与下一步
这套引擎和关键词清洗流水线采用同一种 Agent Skill 交付方式，带内置样例用于先检查输入、规则冲突和输出结构。两个 Skill 也有明确交接：清洗流水线产出的分级词库进入新开活动候选清单，广告引擎再结合毛利、阶段和历史动作给出建议。
目前完成的是打包与样例评测，不把它写成已经验证收益的自动投放系统。下一阶段会按周记录真实诊断、人工改动和执行后表现，再决定哪些阈值可以沉淀，哪些判断必须继续留给人。