OpenAI 将遵循 robots.txt 里共用的 AI 训练偏好信号：新增 __usage_ai-training 令牌，但还要等几个月

OpenAI 于 2026 年 10 月 30 日公告，将遵循 robots.txt 中一个由多家提供商共用的「AI 训练偏好」信号。信号定义来自 IETF 个人草案 draft-kelley-aipref-training-preference-signal-00（作者 Kevin Kelley，署名 Anthropic，2026-10-30，拟议标准轨），做法是在 User-Agent 行写用途令牌 __usage_ai-training，用普通 Disallow / Allow 表达反对或赞成。草案不引入新语法，旧解析器会忽略该组、抓取行为不变；OpenAI 表示将在未来几个月内实现，目前尚未生效。

这次发布的是什么

OpenAI 于 2026 年 10 月 30 日发布公告，表示将遵循 robots.txt 中一个由多家 AI 提供商共用的「训练偏好信号」。此前，网站运营者要先辨认各家 AI 爬虫的标识，再为每一家分别维护一套规则；共用信号把这件事合并成一次表达。

信号的定义不在 OpenAI 手里，而在 IETF 的一份个人草案里：draft-kelley-aipref-training-preference-signal-00，作者 Kevin Kelley，署名机构为 Anthropic，草案日期 2026 年 10 月 30 日，拟议标准轨，2027 年 5 月 3 日到期。它没有引入新的指令名与新语法，只在 robots.txt 的 User-Agent 行里新增一个用途令牌：__usage_ai-training。

OpenAI 公告里的措辞是「计划在未来几个月内实现该信号，届时再公布实现细节」。所以这是一条承诺遵循的公告，不是已经生效的开关 —— 这一点决定了现在写进去能不能起作用。

可用性与限制

• 生效时间：尚未实现。官方只给了「未来几个月内」这一窗口，没有日期。
• 标准地位：草案是个人投稿，在 IETF 标准流程中没有正式地位，配套的词汇与附件草案仍在修订。
• 不是抓取指令：草案原文写明该令牌「is not a directive for crawling behavior」，它表达偏好，不约束抓取。
• 不替代现有控制：OpenAI 表示现有爬虫控制继续适用并被尊重，两套规则并存。
• 通配组不算数：User-Agent: * 不得被视为匹配该令牌，必须显式写出，否则等于没表达偏好。

主要功能

• 用一个 User-Agent 组表达「内容是否可用于基础生成式 AI 训练」。
• 支持按路径分别表达：同一组里 Disallow 表示反对，Allow 表示赞成。
• 沿用 robots.txt 既有语法、最长匹配优先级与组结构，不新增指令。
• 旧解析器会把该组当作不认识的 user-agent 忽略，线上抓取行为不变。
• 一次面向所有参与该信号的提供商表达，不必为每家重写一遍规则。
• 与抓取规则正交：想限制抓取，仍需另写针对爬虫 product token 的组。

技术原理

草案的做法是复用 RFC 9309 的 product token 规则：令牌由字母、下划线与短横线组成，消费方按 product token 精确匹配、仅忽略大小写。两个下划线前缀是为了降低与真实爬虫名意外撞车的可能。一个组可以用多行 User-Agent 挂多个令牌，也可以与普通爬虫名混写。草案 Figure 1 的示例是：

User-Agent: __usage_ai-training

Disallow: /

Allow: /press-kit/

含义是「除 /press-kit/ 之外，所有路径都表达反对用于 AI 训练；/press-kit/ 表达赞成」。判定方式是查表而不是解读内容：命中 Disallow 即表达反对，命中 Allow 即表达赞成，文件里没有这一组就是没有表达任何偏好。

草案还划了几条边界：通配组不得被视为匹配令牌；文件里的厂商私有令牌在本文档语境下不算偏好表达；私下协议可以覆盖这里表达的偏好；具体表达优先于一般表达。兼容性是设计目标之一 —— 部署中的旧解析器会把策略令牌组当成陌生 user-agent 直接跳过，因此现有行为不变，这也是为什么它能先落地再谈标准。

OpenAI 的公告本身没有给语法示例，只链接到草案，实际写法要以草案正文为准。

实际体验

公告与草案能对上，而「写进去会怎样」现在就可以自己测。用本机 Python 3.13.14 自带的 urllib.robotparser 解析上面那段示例，结果是：Googlebot 访问 /blog/post 允许、访问 /private/ 下路径不允许；把 __usage_ai-training 当作 agent 去问 /press-kit/ 得到允许、问 /blog/post 得到不允许。这个库把令牌当成一个普通的 user-agent 名来匹配，恰好符合草案「旧解析器忽略令牌组」的预期。

同一个库在只有通配组的文件上会露出口径差异：文件里只写 User-agent: * 加 Disallow: /，再拿 __usage_ai-training 去问，返回的是不允许。而草案明确要求通配组不得被当作匹配该令牌，此时正确语义应是「未表达偏好」。这说明在消费方真正实现草案之前，同一份 robots.txt 在不同解析器里可能得出不同结论，别指望通配组顺手兜住一切。

另一个可核验的观察是：这类内容没有安装包也没有接口，改的是自己站点的 /robots.txt 文件本身，抓一次就能看到自己写了什么、旧解析器读到了什么。

项目地址与获取方式

• OpenAI 公告：https://openai.com/index/helping-websites-express-ai-training-preferences
• 草案状态页：https://datatracker.ietf.org/doc/draft-kelley-aipref-training-preference-signal/
• 草案正文纯文本：https://www.ietf.org/archive/id/draft-kelley-aipref-training-preference-signal-00.txt

不需要下载任何软件，也没有可申请的接口。要看原始语法请直接读 ietf.org 上的草案正文，别用二手改写版本 —— 令牌名少一个下划线就会失效。

适合谁用

• 运营内容站、需要表达「内容是否可用于训练」的站长。
• 关注 AI 爬虫与内容授权口径的媒体与出版方。
• 要给客户解释 robots.txt 各段含义的建站与 SEO 从业者。
• 不必用：不运营站点、也不处理内容授权的人，读了只是知识储备。

常见问题

现在写进 robots.txt 就会生效吗？

不会。OpenAI 说的是未来几个月内实现，公告当天没有任何消费方按这个信号行动。现在写的好处是把意图先落在文件里，等实现上线后不必再改；如果你的目的是立刻阻止抓取，仍要用现有的爬虫屏蔽规则，两者不是一回事。

写 User-Agent: * 能覆盖这个令牌吗？

不能。草案要求消费方不得把通配组视为匹配该令牌，必须显式写 User-Agent: __usage_ai-training 才算表达了偏好。反过来，通配组也不该被当成「顺手把训练也拒了」——上面那个解析库的表现说明，不同实现对这一点并不一致。

这和屏蔽 OpenAI 爬虫有什么区别？

屏蔽爬虫是「别来抓」，属于技术性限制，由各家爬虫标识决定；训练偏好信号是「抓了也别拿去训练」，属于用途声明，不阻止抓取。草案自己也写明，要限制抓取仍应另写针对爬虫 product token 的组。想两头都管，就得两套都写。

草案通过了吗？

没有。它是个人投稿的 Active Internet-Draft，在 IETF 标准流程中没有正式地位，讨论在 aipref 工作组邮件列表进行，2027 年 5 月 3 日到期。正式标准还要走一段路，写法也可能随工作组共识变化，这也是「先写、等实现」比「现在改架构」更合适的原因。

还要逐家给每家 AI 公司写规则吗？

共用信号要解决的正是这件事：一次表达、多家识别。但前提是那些提供商也参与并实现该信号。OpenAI 的公告只说与工作组其他成员同日发布了这一信号，没有点名其他厂商，所以现阶段能确认明确表示将遵循的只有 OpenAI 一家。

相关工具与内容

• Cloudflare 与 OpenAI 公布 AI 发现试点早期结果：用网络侧信号帮 ChatGPT 找到更多网页
• OpenAI 公布欧盟文本溯源方案：水印从研究者切入，逐步扩展到更多场景
• OpenAI 更新 Model Spec：改成五条核心价值，删掉大部分文风规定
• OpenAI 前沿模型训练不再接入实时互联网：离线环境与高算力红队
• AI 搜索
• 其他 AI 工具