Cloudflare新反爬功能不是默认魔法：先打开这一项设置

开启 Cloudflare Adaptive Intelligence 的最短路径是：选择目标站点，进入 Security Settings，筛选 Bot traffic，打开 Bot Management，然后在 Configurations 中编辑 Auto-updates to the Machine Learning Model，将其开启并保存。这个开关控制评分模型是否自动接收更新，不是新建 WAF 规则，也不是替换 Bot Score 字段。

这项能力面向已获得 Bot Management 权益的 Enterprise zone。开关启用后，无需选择或迁移模型版本，现有基于 cf.bot_management.score 的规则仍可沿用；不过，模型更新可能改变部分请求的评分，因此规则表达式不变并不保证命中量和处置量完全不变。

启用前确认权益、编辑权限和现有基线

先确认目标 zone 确实拥有 Enterprise Bot Management，而不只是 Bot Fight Mode 或 Super Bot Fight Mode。Cloudflare 的 Enterprise Bot Management 套餐页 将其列为由客户团队添加到 Enterprise 套餐的能力，并说明该产品提供细粒度 Bot Score、Bot Analytics、自定义规则字段和多种处置方式。

如果控制台显示“Add Bot Management”，或目标 zone 下没有 Bot Management 配置，应先让账户管理员或 Cloudflare 客户团队核对 entitlement。实际执行变更的账号还应能编辑该 zone 的安全设置；若编辑图标不可用，先解决权限问题，不要把缺少权限误判为功能尚未发布。

变更前保存一份可比较的运行基线。观察窗口应覆盖站点的正常业务周期和主要流量高峰，至少记录：

• Bot Score 的整体分布，以及低分请求集中在哪些主机名和路径。
• 所有引用 cf.bot_management.score 的自定义规则、阈值、附加条件和动作。
• Managed Challenge、Block、Skip 与仅记录动作的当前数量。
• 登录、注册、结算、搜索、API 和合作方回调的正常成功率与失败量。
• Verified Bot、静态资源和已知自动化客户端是否已有准确的排除条件。

这些记录不是产品要求的配置项，而是后续判断误伤的运维依据。没有基线时，模型变化、业务流量波动和原有规则缺陷会混在一起，很难确定动作量为何升降。

四步打开机器学习模型自动更新

Cloudflare 的 Bot Management 设置步骤 给出了明确入口，也说明该产品会为请求生成 1–99 的 Bot Score，并允许客户通过 WAF 自定义规则使用该分数。启用自动更新可压缩为四步：

1. 登录 Cloudflare dashboard，选择正确的账户和 zone，进入 Security Settings。
2. 在设置页按 Bot traffic 筛选，定位 Bot Management。
3. 在 Configurations 下找到 Auto-updates to the Machine Learning Model，点击编辑图标。
4. 将开关设为开启并保存，再重新进入配置项，确认保存后的状态仍为开启。

如果 Bot Management 尚未开启，应先打开产品本身并检查基础流量处置设置，再启用模型自动更新。“Block AI Bots”是针对 AI 爬虫的独立策略，不是 Adaptive Intelligence 的启用开关。

也不必为这次启用额外创建一条覆盖全站的拦截规则。自动更新负责改变产生 Bot Score 的模型；现有自定义规则仍负责组合分数、URI、请求方法、Verified Bot 等条件，并决定记录、质询、跳过或拦截。

持续重训、Bot Score 和规则各管一层

Cloudflare 的 Adaptive Intelligence 产品说明 确认，当前上线的首个组件是持续重训的机器学习模型；新权重会自动部署，并在成为主要防线前以影子模式对照实时流量。Enterprise 客户开启 Auto Update Machine Learning 后，无需迁移版本，原先依赖 Bot Score 的规则可以继续工作。

三层能力的边界因此很清楚：持续重训让检测模型跟随新的流量特征和绕过方式演进；Bot Score 向规则提供请求的自动化判断结果；自定义规则再结合站点自身的路径、客户端和风险要求决定动作。模型不会自动改写管理员的表达式，也不会替站点选择处置策略。

“规则继续工作”只表示字段和表达式不需要迁移，不表示模型输出被冻结。假设一条规则对登录路径中的低分请求执行 Managed Challenge，模型更新后若更多异常请求进入该分数范围，规则的命中量会增加，但规则本身并未被修改。

还要区分已经上线与仍在规划中的组件。持续重训是当前可通过开关接入的部分；自动生成并轮换临时检测规则、进一步从受保护流量中学习等能力，在产品说明中仍属于后续逐步上线的方向。打开自动更新不能被解释为所有规划功能已经同时生效。

上线后先验证评分和动作，不要同时改阈值

保存开关后，先确认配置状态，再用与基线相近的业务周期观察结果。不要同时修改所有 Bot Score 阈值，否则即使命中量变化，也无法区分原因来自新模型还是规则调整。

• 评分分布：比较启用前后的低分、中间分段和高分请求占比，并按主机名、URI、国家或 ASN 下钻，避免只看全站平均值。
• 规则动作：确认变化来自哪条自定义规则，并分别检查 Managed Challenge、Block、Skip 和仅记录动作。
• 质询表现：观察质询完成情况和重复质询现象。单独一个通过率变化只能作为调查线索，不能直接证明模型判断正确或错误。
• 业务信号：核对登录失败、支付中断、API 认证错误和合作方回调失败，确认它们是否与被处置请求在时间和路径上重合。
• 已知自动化：复查 Verified Bot、监控探针和合作伙伴客户端，确认精确例外仍然匹配实际请求。

如果评分和业务指标稳定，保留原规则即可，不必为“适配新模型”机械调整阈值。若动作量明显变化，先缩小到具体路径、客户端和触发规则，再考虑补充排除条件、收窄匹配范围，或暂时将高影响路径的 Block 改为 Managed Challenge 或仅记录。

看不到开关或疑似误伤时的排查顺序

看不到 Auto-updates 配置时，依次确认账户与 zone 是否选对、该 zone 是否拥有 Enterprise Bot Management、Bot Management 是否已启用，以及当前账号能否编辑安全设置。如果页面仍显示购买入口或缺少整个 Bot Management 区域，应核对产品授权，而不是寻找同名 WAF 规则。

若已开启但分析页面没有预期数据，先检查查询的 zone、时间范围、主机名和路径是否正确，并确认待分析请求确实经过该 zone。不要在证据不足时直接把“没有数据”解释成全部请求都是真人流量。

出现疑似误伤时，先找出执行动作的具体规则和对应请求样本，再核对路径、请求方法、Verified Bot 状态、静态资源标记及客户端特征。精确例外应围绕可稳定识别的业务条件设计；直接关闭全部机器人防护会掩盖过宽规则或缺失例外，无法说明问题真正来自模型还是处置层。

若业务影响正在扩大，可先降低受影响路径的动作强度并保留日志，再逐项修改条件。一次只改变一个关键变量，才能验证调整是否有效，同时保留自动更新带来的持续检测能力。