这件事为什么值得站长关注

过去，如果你不想让自己网站的内容被拿去训练大模型，通常的做法是在 robots.txt 里把各家的训练爬虫一个个列出来再 Disallow。问题很明显：爬虫名字各家不同、不断新增，规则越写越长，而且「禁止抓取」和「禁止训练」被混成了一件事——有的站长其实愿意被 AI 搜索收录，只是不想被用于训练。

2026 年 10 月 30 日，OpenAI 发文宣布：将支持 robots.txt 中一个跨厂商的通用信号，网站可以用它一次性向多家参与的 AI 公司表达「是否允许用于基础生成式 AI 训练」的偏好。该信号来自 IETF AI Preferences（aipref）工作组的讨论，具体写法在同日发布的 Internet-Draft《Machine-Readable Training Preference Signal》中给出。

需要先说清楚两点现状，免得误会：

  • OpenAI 表示会在未来几个月内实现该信号，届时再公布实现细节；现有的 GPTBot 等爬虫控制继续有效，不会被替代。
  • 这份草案目前是个人提交的 Internet-Draft，并非 IETF 正式标准；遵守它是各厂商的自愿行为。

也就是说，现在就可以把它写进 robots.txt，成本几乎为零，但不要把它当成强制性的技术屏障。

核心概念：策略令牌（policy token）

草案的思路很巧妙：不发明新语法，而是复用 robots.txt 已有的 User-Agent 分组，只不过这里的「User-Agent」不是某个真实爬虫，而是一个代表「用途」的令牌：

__usage_ai-training

几个要点：

  1. 以两个下划线开头。这是为了避免被一些「模糊匹配」的老解析器误认成某个真实爬虫。
  2. Disallow = 不希望用于 AI 训练，Allow = 允许用于 AI 训练。路径匹配、最长匹配优先等规则与普通 robots.txt 完全相同。
  3. User-Agent: * 不算数。草案明确规定，通配分组不能被解释为匹配这个令牌。换句话说，你写了 User-Agent: * + Disallow: /，并不等于表达了「禁止训练」。
  4. 文件里没有这个令牌，就等于没有表达偏好。
  5. 这里的「AI 训练」指用内容去修改生成式 AI 模型的参数；只做非生成式任务的模型训练不在此列。

最关键的一条：它不是抓取指令。训练偏好和「能不能抓」是两个相互独立的维度。草案明确说，爬虫仍按自己的名字去查自己的规则；想限制抓取流量，依旧要写针对具体爬虫的分组。

准备工作

  • 能修改网站根目录 robots.txt 的权限（静态站、Nginx、CDN 或 CMS 后台均可）。
  • 一台能执行 curl 的机器，用于自检。
  • 想清楚你的策略：全站禁止训练？只开放部分目录？是否仍希望出现在 AI 搜索结果里？

第一步：选一个适合你的配置模板

模板 A：全站不希望被用于训练，但正常让搜索引擎抓取

# 传统抓取规则：照旧
User-Agent: *
Allow: /

# 训练偏好：全站不希望用于生成式 AI 训练
User-Agent: __usage_ai-training
Disallow: /

Sitemap: https://example.com/sitemap.xml

模板 B：默认禁止训练，但开放新闻稿、文档等目录

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/
Allow: /docs/public/

由于最长匹配优先，/press-kit/ 下的内容会被视为「允许训练」，其余路径为「不允许」。这正是草案示例的用法。

模板 C：允许训练，只保护付费或用户内容

User-Agent: __usage_ai-training
Allow: /
Disallow: /members/
Disallow: /user-content/

第二步：和现有的爬虫规则配合

如果你之前已经写过针对具体厂商的规则，不需要删除。以 OpenAI 为例，其官方文档把几个爬虫的用途分开：OAI-SearchBot 用于在 ChatGPT 搜索中展示网站，GPTBot 用于收集可能被用于训练生成式模型的内容，各项设置相互独立。一个常见的组合是「愿意出现在 AI 搜索里，但不愿被训练」：

# 允许 AI 搜索抓取
User-Agent: OAI-SearchBot
Allow: /

# 厂商专属：禁止训练爬虫
User-Agent: GPTBot
Disallow: /

# 跨厂商通用：表达不希望被训练
User-Agent: __usage_ai-training
Disallow: /

为什么两种都写？因为通用信号还在推广期，并非所有厂商都已实现；厂商专属规则则是它们早已承诺遵守的。草案也允许厂商声明「专属令牌比通用令牌更具体、优先级更高」，所以两者冲突时，专属规则可能胜出——请确保它们表达的意思一致。

草案还允许在一个分组里连续写多个 User-Agent 行，把同一组规则绑定到多个令牌，例如：

User-Agent: GPTBot
User-Agent: __usage_ai-training
Disallow: /

这样写更短，但可读性略差，团队协作时建议分开写并加注释。

第三步：部署

  • 纯静态站点：直接把文件放到站点根目录，确保能通过 https://你的域名/robots.txt 访问。
  • Hugo：可以在 layouts/robots.txt 写模板，并在配置中开启 enableRobotsTXT: true，构建后会输出到站点根目录。
  • Nginx 直接返回（适合不想改程序的情况）：
location = /robots.txt {
    default_type text/plain;
    alias /etc/nginx/robots.txt;
}

修改后重新加载 Nginx：nginx -t && nginx -s reload。

第四步：自检

  1. 确认文件可访问、类型正确：
curl -sI https://example.com/robots.txt | grep -iE "^(HTTP|content-type)"
curl -s https://example.com/robots.txt
  1. 检查令牌拼写（前面是两个下划线，中间是连字符）：
curl -s https://example.com/robots.txt | grep -n "__usage_ai-training"
  1. 用 Python 标准库做一次「路径是否被禁止」的粗略模拟。注意 urllib.robotparser 并不认识「通配符不匹配策略令牌」这条特殊规则，所以它只适合验证你写的 Allow/Disallow 路径逻辑是否符合预期：
from urllib.robotparser import RobotFileParser

rp = RobotFileParser("https://example.com/robots.txt")
rp.read()
for path in ["/", "/press-kit/logo.png", "/blog/post-1"]:
    ok = rp.can_fetch("__usage_ai-training", "https://example.com" + path)
    print(path, "允许训练" if ok else "不希望训练")

如果你的文件里没有 __usage_ai-training 分组，这段代码会回落到 User-Agent: * 的结果——而按草案，这种情况应理解为「未表达偏好」。这恰好说明了为什么必须显式写出该令牌。

常见坑

  • 只写 User-Agent: * 就以为禁止了训练：按草案，通配分组不代表训练偏好。
  • 令牌拼错：少一个下划线、写成下划线 ai_training，都不会被识别。
  • 把它当防火墙：这是偏好声明，不是访问控制。真正不想被抓取的内容，应该用登录、鉴权或在服务器层面拦截。
  • 以为改了就立刻生效于历史数据：IETF 相关文档指出，爬虫依据抓取当时的 robots.txt 判断偏好，修改不会追溯到已经获取的内容。
  • robots.txt 过大：RFC 9309 对文件大小有限制，不要为每个路径单独写一行，尽量用目录前缀。
  • 专属规则与通用规则矛盾：例如 GPTBot 允许、通用令牌禁止，不同厂商的解释可能不同，务必保持一致。

小结

__usage_ai-training 让站长第一次可以用一套规则、按路径地向多家 AI 公司表达训练偏好，同时把「能不能抓」和「能不能训练」拆开。它目前仍是草案，OpenAI 也尚在实现中，但写进 robots.txt 几乎没有成本。建议的做法是：保留现有厂商专属规则，再加上一段通用令牌分组，并定期关注 IETF aipref 工作组和各厂商的实现公告。

参考来源