2026 年 10 月更新：本文写于 2026 年 7 月，记录的是当时 RongAds 走 Ads API 自动调价的方案。三个月后我把这条路整体放弃了：API 接入、调度器、自动执行器、回执对账和它们依赖的数据库全部删除，RongAds 回到只读 Bulk 文件、不保存任何数据的免费网站（ads.rongcraft.com），调价由你核对后自己上传。七道闸门的内容保留原样，原因和现在的做法见文末”后来怎么样了”。
做 Amazon 广告优化工具时，最容易让人兴奋的是调价公式：输入点击、订单、销售额和目标 ACOS，输出一个新的 bid。真正准备让程序 24 小时运行后，我才意识到，算出建议只占很小一部分，阻止错误建议直接花钱才是主体工程。
如果一个系统每天自动运行，它迟早会遇到这些情况：数据还没回填、文件过期、同一个词被重复调整、某个 Portfolio 没配预算、API 超时但 Amazon 端可能已经生效、回执缺失、全账户指标突然恶化。任何一个问题处理成“继续试试看”，都会把小误差放大成真实广告费。
因此我给 RongAds 设计的不是“定时执行一个公式”，而是一个逐层收窄权限的安全闭环。
截至 2026 年 7 月 14 日的真实状态：RongAds 的安全控制面、dry-run 计划、日限额、预算护栏、灰度观察、异常暂停、审计日志和 Ads API 执行适配骨架已经存在；线上 UI/API 正常运行，EU OAuth 已完成，凭据以
0600权限保存在服务器。但生产环境没有任何 Portfolio 开启自动化，零曝光探索全部关闭，也没有 scheduler/autopilot 服务或广告写入。真实广告仍不会被程序自动修改。
专题导航：本文属于 Amazon 广告优化与 RongAds 实战 系列；可从专题页按“基础 → 数据 → 决策 → 工具”查看完整阅读路径。
先分清三件事：建议、计划和执行
很多“自动调价”介绍会把三层混成一件事：
| 层级 | RongAds 做什么 | 是否会改 Amazon 广告 |
|---|---|---|
| 建议 | 根据数据计算 suggested bid，并解释为什么加、减或保持 | 不会 |
| 计划 | 应用安全规则后生成本轮允许执行的差异清单 | 不会 |
| 执行 | 把已放行的指令交给 Bulk 或 Ads API，并核对回执 | 只有最后一步可能会 |
这个拆分很重要。系统可以高频地观察和生成建议，但不代表应该高频地修改竞价。我的目标是让服务器每天跑一轮检查，而不是让每个关键词每天必然变化。
RongAds 的基础建议仍来自分层贝叶斯 CVR：
建议出价 = 贝叶斯 CVR × 每单收入 × 目标 ACOS
但这个结果只是候选值。它还要依次经过控制策略、自动化闸门、预算与频率限制，最后才有资格进入执行器。
安全闸一：每个 Portfolio 默认都是 off
自动化不是全账户总开关，而是逐 Portfolio 管理：
off：默认状态，不参与自动化；dry_run：每天生成计划和日志，但不修改广告；live：通过全部闸门后，才允许把指令交给真实执行通道。
未配置就等于 off。系统本身只能把 Portfolio 降级为 off，不能替人把它升级到 dry_run 或 live。也就是说，即使代码、调度器和凭据都已经存在，没有人工明确授权，机器仍然没有花钱权限。
安全闸二：dry-run 至少观察 7 天
RongAds 不允许从 off 直接切到 live。必须先连续处于 dry_run 至少 7 天，观察机器每天打算做什么。
这 7 天主要检查：
- 建议是否集中在少数异常词，而不是全账户同向变化；
- 加价和降价是否与业务直觉一致；
- 数据窗口、目标 ACOS 和每单收入是否填对；
- 预算警示是否稳定；
- 同一关键词是否出现反复加减的震荡。
中途切回 off 后，观察期重新计算。这个限制写在模式切换的底层校验里，不是一个可以在界面上随手跳过的提示。
安全闸三：数据不可信就不生成计划
自动执行最危险的输入不是“坏数据”，而是“看起来正常的旧数据”。RongAds 对自动化数据源做了几层限制：
- 最新数据超过 14 天，不生成自动计划；
- API 模式只消费 API 数据帧，Bulk 过渡模式只消费 Bulk 帧，避免两套口径互相劫持；
- API 拉取失败时，不拿刚上传的 Bulk 文件偷偷替代；
- 数据分页超过上限、字段无法解析或报表不完整时，停止而不是静默截断；
- Ads API 与同期 Bulk 的关键口径偏差超过 2% 时，不能让 API 数据进入出价公式。
这里采用的是 fail closed：无法证明输入正确，就当作不具备执行条件。程序少跑一轮的损失，通常远小于用错一轮数据的损失。
安全闸四：每个 bid 同时受四类数值边界约束
即使输入正确，模型也不能直接决定变化幅度。
| 限制 | 当前默认值 | 解决的问题 |
|---|---|---|
| 出价硬范围 | €0.02–€1.50 | 阻止异常值和灾难性溢价 |
| 单次步幅 | 加价最多 +10%，降价最多 −10% | 防止一次跳得过远 |
| 单日次数 | 同一对象最多 1 次 | 防止调度器重跑造成复利变化 |
| 单日累计幅度 | 相对当日首次调整前不超过 ±15% | 防止多次小步绕过单次限制 |
此外，加价比降价更严格。这里需要补一条实施状态更正：
- 点击少于 10 次，不允许因为先验看起来不错就加价；
- 设计契约要求加价后进入对象冷却，避免归因尚未回填时继续复利加价；
- 5 天只是机械冷却示例，不会替代 Seller 7 天、Vendor 14 天的归因成熟；
- 降价止血可以日频检查，但不能仅因昨天 0 单而动作；
- 当日人工导出和自动执行共用同一个次数预算，避免人上午刚改过、机器下午又改一次。
2026 年 7 月 15 日实施状态更正（生产 v2.19.0）：当前已实现按对象的事件溯源调价状态、加价 5 天冷却和降价可日频，并在 autopilot 计划中拒绝冷却期内的普通重复加价。手动 Bulk 流程只能从“文件已导出”近似起算，无法证明用户已经上传到 Amazon；API live 路径则只在成功回执后记录
bid_adjusted。生产仍没有 scheduler/autopilot 服务、未注入 live 执行器且没有广告写入；方向反转冷却与组合熔断仍未实现。上面的规则是完整安全契约，当前代码只覆盖其中一部分。完整的四时钟设计见：Amazon 广告多久调一次价？把运行频率、归因窗口和冷却期分开。
这正是“24 小时运行”和“每天调一次价”的区别：程序可以一直活着，但每个词是否动作仍由信息量和冷却期决定。
安全闸五：预算没配好，只允许省钱方向
RongAds 会估算一批加价在“点击量暂时不变”假设下的每日新增花费上界，再与 Portfolio 日预算比较：
- 新增花费达到日预算的 10%，进入警示；
- 达到 25%，视为高风险；
- 没有配置有效日预算，自动加价不应放行；
- 降价是省钱方向，可以保留用于止血。
预算护栏不是在预测未来点击量，而是在回答一个更保守的问题：即使流量结构不变，这批加价最少会把成本推高到什么程度？
零曝光词探索是例外，因为它的目标就是让点击从 0 变成非 0，现有花费模型无法估算新增点击。对此 RongAds 默认关闭探索，并额外限制每轮候选数量、试探价上限，同时要求 Amazon Campaign 自身的日预算作为最终止损闸。
安全闸六：异常只能让系统降级，不能让它自愈后重开
RongAds 有全局 kill switch，也能在 Portfolio 指标异常时自动暂停：
- ACOS 高于目标的 1.5 倍；
- 花费相对上一可比周期上涨 1.5 倍；
- 指标达到最小花费门槛后才触发，避免小样本误报。
系统检测到异常后，可以把 Portfolio 切回 off，也可以拉下全局 kill switch；但它不能自己恢复运行。排查完成后，必须由人写明原因并重新开启。
这是刻意的不对称权限：机器可以主动踩刹车，不能因为下一轮指标看起来恢复了就自行松开刹车。
安全闸七：没有明确成功回执，就不记作已执行
API 执行的难点不是发送请求，而是处理“状态未知”。例如关键词批次已经成功，商品定向批次随后超时；或者 Amazon 实际接受了请求，但网络中断导致客户端没收到回执。
RongAds 的执行边界遵循三条规则：
- 每条指令都按“实体类型 + ID”复合键对账，避免关键词与商品定向撞号；
- 只有明确成功的回执才写入“已应用”审计事件并占用当日次数预算；
- 失败、未回执、畸形回执和通道异常全部单独记录，要求人工核对，绝不静默假装成功。
所有模式切换、kill switch、计划、人工导出和真实生效事件都进入 append-only 操作日志。一个 bid 为什么变成现在这样，应该能够沿时间线回答：谁动的、什么时候、旧值、新值、原因和通道是什么。
一轮安全自动化实际怎样运行
把上面的规则合在一起，一轮自动驾驶更像下面这样：
读取 kill switch
→ 识别已获人工授权的 Portfolio
→ 获取同源且未过期的数据
→ 生成候选建议
→ 应用加价冷却与单日限额
→ 应用预算护栏与异常检测
→ dry-run：只保存计划
→ live：执行后逐条核对回执
→ 写入不可追加修改的事件日志
任何一层无法确认，流程就在那一层停止。这种设计看起来保守，但对会直接影响广告费的系统，宁可少做一次，也不允许不知道自己做了什么，才是合理默认值。
后来怎么样了：为什么我把自动化删了
这篇文章发表三个月后，2026 年 10 月，我把上面写的东西整体删掉了：Ads API 接入、OAuth 凭据、调度器、自动执行器、回执对账、事件日志，以及它们依赖的数据库，一共六万多行代码。RongAds 现在是一个免费网站：上传 Amazon 后台导出的 Bulk 文件，网站算出每个关键词的建议，你勾选接受的那些，下载改好的 Bulk 自己上传回后台。它不连接任何 API，不保存任何数据。
原因有三条，按重要程度排：
- 自动执行的前提和“不保存用户数据”互斥。要让程序每天替人改价，就得持续拉数、记住每个词上次改了什么、保管授权凭据。我想把工具免费开放给别的卖家用，又不想替任何人保管广告账户的授权和数据。两者只能选一个。
- 七道闸门防的全是执行通道的风险，不是决策的风险。回头看，这套工程九成的篇幅在回答“怎么安全地改”，而真正难、真正值钱的问题是“该不该改、改多少”。把执行权收回给人之后，这九成工程量连同它的风险一起消失了，留下的全是决策本身。
- 每天自动跑和每周手动跑，效果没有差别。归因要两三天才回填，决策本来就按周；一周一次下载、核对、上传，半小时以内。为了省这半小时去维护一套 24 小时运行的系统，不划算。
现在的 RongAds 怎么保证安全
比七道闸门简单得多：没有执行权限，就没有执行风险。工具只产出一个 Bulk 文件，上传与否、上传哪些行，由你决定。文中仍然成立的规则都还在：单次步幅 ±10%，加价后 5 天冷却（靠你下次拖回来的“本期记录”文件实现），零曝光探索不越过先验价值上限，活动预算顶格时不加价。不再需要的是 kill switch、回执对账和不可追加修改的事件日志，因为没有机器在替你花钱。
决策这一半也重写了：不再是“贝叶斯 CVR × 每单收入 × 目标 ACOS”算一个新 bid 就完事，而是给每个词算一个概率 P，即真实转化率高于保本转化率的把握。P 高加价、P 低降价、中间保持；每条建议附全部数字和一句理由。效果评估靠“决策记分卡”：下一期把上期加价、降价、收割的词分组对账，没动的词当对照。这些写在网站的“怎么用”页里。
这篇文章保留原样，是因为它记录了一个真实的弯路：把精力花在防御执行通道上，比承认“不该自动执行”要容易得多。
而安全调价的输入也必须先能解释。关于广告费、FBA 优惠、退款佣金、仓储费和成本口径怎样逐项闭合，可以继续看：Amazon 利润和领星为什么对不上？一张桥接表拆清差额。
如果要先判断一个产品的单位经济能否承受广告，可以继续看：低客单价产品能不能跑 Amazon 广告？先算清 4 条止损线。
当安全闸需要判断一个零订单搜索词是否还值得继续花费时，可以继续看：Amazon 搜索词花到多少该停？别再套用固定点击阈值。
