AIPREF（Content-Usage 声明） AIPREF / Content-Usage Preference

AIPREF（Content-Usage Preference，AI 偏好声明）是 IETF 的一项草案，定义在 robots.txt 中用 Content-Usage 字段机器可读地声明内容可以被用于哪些 AI 用途——训练、AI 输出、搜索——逐项表态，比传统的“全允许/全禁止”细粒度得多。声明形如 Content-Usage: bots=y, train-ai=y, ai-output=y, search=y：站长可以允许被搜索收录、允许内容出现在 AI 生成的回答里，但拒绝被用于模型训练。它是 AI 时代“用协议表达偏好”这条路线上的最新一环。

为什么“全允许/全禁止”不够用

robots.txt 的原生语义只有“允许抓/禁止抓”两态，而 AI 时代站长面对的偏好是多元组合的：欢迎检索引用，但不欢迎进训练语料；愿意被摘录进 AI 答案，不愿意模型逐字学习自家文风；甚至同一站点内不同目录的偏好都不同。两态协议表达不了这类结构，站长被迫在“全开”与“全关”之间二选一——选全开，语料与引用一起放行，无法只留一半；选全关，连搜索可见度一起陪葬。AIPREF 的设计意图正是补上这层表达：把“被访问”拆成用途维度，逐项声明，机器可读。要理解它与既有协议的关系，先看robots.txt（AI 语境）。

Content-Usage 逐项声明怎么读

这个草案把“抓取之后能干什么”拆成几个正交的用途维度：是否允许作为爬虫通用访问（bots）、是否允许用于模型训练（train-ai）、是否允许内容进入 AI 的输出（ai-output）、是否允许用于搜索索引（search）。每个维度独立取值，组合出站长真实的偏好结构——“可搜索、可引用、不可训练”这类以前无法表达的中间态，现在有了标准写法。

它与具名 UA 分组是两套正交机制：分组管“谁可以来”，Content-Usage 管“来了之后内容能被用于什么”。两者叠加，才能拼出一张完整的授权地图。用排除法理解也直观：如果只写分组不写用途，等于对每位访客的权利只做了二分（可来/不可来）；加上用途声明，才把“可来，但只可以做事 A 不可以做事 B”讲清楚。

这张表里的“理由”没有对错，只有取舍——AIPREF 的价值恰恰是把取舍从“全有或全无”变成可以逐项勾选的偏好表。

三种典型立场，对应三种写法

落到部署，多数站点的立场可以归成三类。开放型：内容是营销资产，希望被一切渠道消费——全部维度放行，声明写出来主要是留痕与表达善意。分层型：要搜索与 AI 引用的露出，不要进训练语料——search 与 ai-output 放行、train-ai 禁止，这是内容生意与出版方最常见的组合，也是两态协议时代最表达不出来的那一种。受限型：内容有明确的授权与付费边界——仅对具体合作方放行，其余禁止，声明与商务合同互为印证。先想清楚自己属于哪一类，再动笔写声明；立场没想清楚就抄模板，是这类协议文件最常见的病。

还有两类站点要额外提醒。UGC 平台的责任更重：站方声明不能替用户内容做主，用户生成内容的授权状态要单列处理，不能一份 Content-Usage 覆盖全站。聚合与转载型站点则要先理顺上游授权——你自己声明“可用于训练”，并不改变内容原始权利方的立场，声明写得再标准也转授权不了你没有的权利。

草案的效力边界：表态不等于执行

对 AIPREF 的期待要放在正确的位置上，两件事必须先记住。其一，它是草案，不是标准，更不是法律——各厂商的遵守程度不一，可能采纳、部分采纳或干脆忽略；协议从来没有强制力，它的效力完全建立在“厂商自愿遵守”的默契上。其二，robots.txt 的语义铁律在 AIPREF 上同样适用：具名 UA 组只守自己组的规则、不继承 User-agent: * 组，因此声明必须逐组写——只在通配组里写一遍 Content-Usage，具名爬虫并不买账。这一铁律与具名爬虫的行为边界有关，背景见AI 爬虫（AI Crawlers / Bots）。

“声明了就会被读”这个假设本身也要打折，前车之鉴就在旁边：llms.txt 这个同样“为机器而写”的文件，据 Ahrefs 对 13.7 万域名的实测，约 28% 的站点已发布，但 97% 的文件整个月零请求——为机器准备的文件，机器未必来看。AIPREF 的处境同理：它嵌在 robots.txt 里、被读取的概率比独立文件高，但“被读”与“被遵守”之间还隔着厂商政策这一层。口径见数据卡llms.txt：28% 站点已发布，97% 全月零请求。Google 系另有一类既有的细粒度控制——控制型 token，例如屏蔽 Google-Extended 只退出 Gemini 训练语料、不影响搜索与 AI 摘要——可作为“厂商各自为政”现状的对照样本，见Google-Extended。

围绕它的常见误读也大多源自对效力边界的忽视。误读一：把它当强制标准。草案不是标准，标准也不是法——即便定稿，遵守仍取决于各家政策。把“我声明了”当成“你必须照办”，是对协议性质的根本误解。误读二：以为声明能溯及既往。协议只约束读到它之后的抓取，已被抓走、已进语料的内容不会因为补一份声明而回退；要处理存量，走的是另一条路——授权谈判与下架请求，不是 robots 文件。

误读三：把它与 llms.txt 当同类东西混着部署。两者都在根路径附近“对机器说话”，但功能完全不同：Content-Usage 表达授权偏好（可以/不可以用于什么），llms.txt 提供内容导览（这里有什么、在哪里）。一个管权利，一个管地图，互不替代，也不互相解释。误读四：写了声明就不管了。声明的价值一半在“有”，另一半在“可举证的连续性”——没有日期、没有版本、没有配套的日志快照，“我们一直如此声明”在争议场景里只是一句话。

务实部署：表态、留痕、执行三件事分开

本站当前的务实策略是 robots 分组与 AIPREF 声明并行，同时把三件事分开评估。表态：向厂商与生态声明本站的内容立场，成本近零；留痕：在授权谈判、版权争议或合规审查的场景里，书面声明是有日期、可举证的立场记录，法务价值不依赖执行；执行：厂商实际怎么抓、内容实际被用于什么——这不指望单靠声明达成，要靠日志实证，定期核对各爬虫的实际行为与声明的一致性，不一致时用协议外手段（网关规则、商务沟通、法律途径）补位。

部署本身的纪律有三条。逐组写：每条具名 UA 组都要带自己的 Content-Usage 行，不依赖通配组继承；保持一致：robots 的放行/禁止与用途声明不能互相打架（分组禁止抓取、声明却说全允许，这种矛盾只会让整份文件的可信度受损）；留版本：每次修改记录日期与原因，配合日志快照，留痕才有时间轴。这与 llms.txt 的“顺手棋”定位一脉相承——低成本可部署、预期值放在表态而非控制，参见llms.txt。

对本站用户的一句话结论：AIPREF 值得写，写的时候按纪律写；但它不是开关，真正的控制力仍然来自你对各环节入口的实际掌握——哪个爬虫能进来、进来的内容质量如何、以及你在授权与商务关系里的议价位置。