过去几年中，网站拥有者面对 AI 爬虫只有一个粗糙的工具：把所有 Bot 挡掉、或者全部放行。这个非黑即白的控制方式在 2026 年 7 月 终于出现了实质性改变。
Cloudflare 于今年 7 月 1 日为所有客户（包含免费版）开放了三组独立的 AI 流量开关：Search（搜寻引擎爬虫）、Agent（即时 AI 代理）、Training（模型训练爬虫）。到了 9 月 15 日，预设值将正式翻转——任何显示广告的页面，会自动阻挡 Training 和 Agent 类型的 Bot。
在旧世界中，网站拥有者只能靠 robots.txt 表达意愿，但多数 AI 爬虫根本不会遵守。Googlebot 同时为搜寻索引和 Gemini 训练抓取内容；Anthropic 的 ClaudeBot 每爬取超过 11,000 页 才产生一次推荐流量（Cloudflare Radar 2026 年中数据）；OpenAI 的比例也不乐观，约 857:1。
对比之下，传统 Googlebot 每爬取 5 页就能带来 1 次点击。这就意味著：你为 AI 训练公司免费运行了大量伺服器资源，但几乎没有换回任何实际访客。而这些无效流量正在直接消耗你的 CDN 频宽与计费额度。
Cloudflare 的三类分流首次让网站拥有者能对「有价值的搜寻引擎」和「只索取不回馈的训练爬虫」分别下达指令，而不是被迫在「全开」或「全关」之间做选择。
这项政策最引发讨论的部分不在于阻挡 Training Bot，而在于 Googlebot 被归类为「多用途爬虫」——因为 Google 使用同一套爬虫基础设施同时执行搜寻索引和 Gemini 模型训练。因此，如果你选择阻挡 Training 流量，Googlebot 在广告页面上也会被一并阻挡。
Hacker News 上的讨论非常激烈。许多开发者认为这正是 Google 应该面对的后果：「当 OpenAI 已经把 GPTBot、OAI-SearchBot、ChatGPT-User 拆成三个独立身份的时候，Google 还在用同一个爬虫同时做搜寻和训练，问题显而易见。」
Cloudflare 也提供了退让选项——在安全性设定中可以对「Training+Search」混合型爬虫设定白名单。但这个选择本身就反映了更深的产业矛盾：网站拥有者为了留住 Google 搜寻流量，可能被迫继续免费供应训练资料。
「我该怎么设定这三组开关？」的答案取决于你的收入模式和流量来源：
IETF 近来推动了 robots.txt 的「Content Signal」延伸协议（search=yes,ai-train=no,use=reference），但这类宣告式语法只对自愿遵守的公司有效。Cloudflare 的控制面板设定才是真正在边缘层强制执行的防火墙规则。
实务上，最有效的做法是两套并行：robots.txt 表达你的偏好意图，让合规的爬虫自动遵守；Cloudflare 控制面板则是底线防护，挡掉所有不听话的流量。这也正好对应 WAF 运维的核心逻辑——宣告式政策加上强制性执行层。
无论你的网站属于哪一类型，Cloudflare 这次改版都指向同一个结论：Bot 流量管理已经不是「要不要做」的问题，而是「怎么做才不会害自己」。
第一，你必须知道自己被谁爬了什么。 如果你的日志分析工具还只分得出人类和 Bot，那你根本看不出 ClaudeBot 一天吃了你多少 GigaByte、哪些 Agent 在合法存取、哪些是在滥用。看不见就管不了，这是一切自动化防御的前提。
第二，你需要边缘层的快速决策能力。 等爬虫请求到达后端伺服器再判断已经太晚——资料流量费用是按请求次数和频宽计费的，不是按「这个 Bot 有没有价值」来算。你的防御必须在 CDN/WAF 边缘就完成分类与阻挡。
第三，设定之后不能就不管。 爬虫的行为会变（Googlebot 可能哪天就拆成两个独立 UA）、新的 Bot 会出现、你的网站用途也可能改变。好的 Bot 管理策略需要定期审视和调整，而不是「设定一次就结束」。