AIPREF Content-Usage 档案

AIPREF 是 IETF 为“机器可读地声明内容 AI 用途偏好”立项的标准工作，概念定位见AIPREF（Content-Usage 声明）术语卡。本档案记录它的现势：截至 2026-10，它仍是 Internet-Draft 而非 RFC，但已不是散案——有正式工作组、有署名作者、有逼近定稿的草案文本。对站长而言，现在的正确姿势是跟踪，不是部署。

AIPREF 现在走到哪一步了

aipref 工作组于 2025-01 正式 charter。两份核心草案的现状如下。其一，draft-ietf-aipref-attach 已到 -05 版（2026-08-18 更新，2027-02-20 过期），状态仍是 “I-D Exists”，它将更新 RFC 9309——也就是把偏好表达写进 robots.txt 标准本体；作者为 Gary Illyes（Google）与 Martin Thomson（Mozilla）。其二，draft-ietf-aipref-vocab 已到 -08 版（2026-09-13），作者为 Paul Keller（Open Future）与 Martin Thomson，但多个关键章节仍标注“缺乏 WG 共识”。工作组里程碑原定 2026-08 送 IESG——已过期未达成，截至 2026-10 两份草案都还是 Internet-Draft，新时间表未公布。

时间线放在一起看更直观：

两份草案的分工值得说清：vocab 管“词”（能表达哪些偏好），attach 管“贴在哪”（HTTP 头还是 robots.txt 规则行）。词表没定稿，附着机制的实现就悬空——这就是为什么“仍未成 RFC”对站长是实质状态而不是文牍细节。

词表只有三个类别

vocab 草案现行词表只有三个词，没有笼统的 gen-ai 标签——“能不能被 AI 生成内容引用”这类模糊表态在词表里没有对应物。

推一个组合示例：想表达“欢迎搜索收录与引用、拒绝进训练语料”，写法是 train-ai=n, search=y——逐词表态，而不是找一个“半开半关”的总开关。逐词表态的纪律也在这里：词表之外没有可用的词，想表达的偏好若落不进三个类别，现阶段就只能不表达，等 vocab 定稿——自造标签在 Structured Fields 语法里是非法值，等于什么都没说。

语法：Structured Fields 字典，最严者胜

取值只有 y 与 n，缺失意味着 unknown（不是默认允许）；整体是一条 Structured Fields 字典（RFC 9651），形如 train-ai=y, search=n。“缺失即未知”是和现有爬虫行为的关键差异：今天没写 robots.txt 的站点实际处于“无限制”状态，而 aipref 语义下没声明的用途是“未知”——引擎端如何对待 unknown，正是草案里尚未收敛、缺 WG 共识的部分之一。

最容易出错的是合并语义：多个来源（HTTP 头与 robots.txt 规则、上级路径与子路径）叠加时取最严者——任一来源出现 n 即整体禁止。这与 robots.txt 的 Allow/Disallow 冲突处理方向恰好相反（后者打平时取宽松），把旧直觉迁移过来会出错。

两种附着机制

机制一是 HTTP 响应头 Content-Usage，对整页或整站逐页声明。机制二写进 robots.txt——attach 草案给它加了新规则行，官方示例格式如下：

Content-Usage: /ai-ok/ train-ai=y

路径匹配沿用 robots.txt 的最长前缀规则；不可抓取的路径不暗示任何偏好；robots.txt 现有的 24 小时缓存语义照旧适用，且偏好变更不追溯——发出 n 不能撤回已被抓取的内容。它与具名组是两套正交机制：具名组管“谁可以来”，Content-Usage 管“来了之后内容能被用于什么”，两者的写法基础见robots.txt（AI 语境）与robots.txt AI 配置矩阵。

两种附着机制各有适用面，草案并存而非二选一。HTTP 头逐页精确、随响应即时生效，适合对单页有不同偏好的站点；robots.txt 规则一行管一段路径，维护成本最低，但受 24 小时缓存约束，变更不会即时传导。两者同时声明时按最严者胜合并——这决定了“头与规则打架”不会成为漏洞，但会成为误配置的来源。

厂商支持名单：目前是零

措辞纪律先立好：标准仍在制定、尚无厂商承诺。截至 2026-10，没有任何 AI 厂商发布过正式支持 aipref 的声明——现在部署 Content-Usage 头或 robots.txt 规则，没有证据表明哪家引擎会读它。竞争路线有两支：Cloudflare 的 Content Signals（2026-07 已落地为 robots.txt 的 use= 字段，现势见爬虫访问控制实战档案）与 draft-car-ai-txt-wellknown（ai.txt 提案）。三条路线并存、语法互不兼容，站长现阶段无需选边——因为哪一条都还没有厂商支持面。采用前景只有一个参考点：aipref 2025-04 会议记录中的内部评估——大玩家参与可迅速带来“40% web 采用”。这个数字是讨论口径而非预测承诺，但它解释了为什么 Google（Illyes 任 attach 作者）的站位被业界紧盯。

对站长的操作清单

1. 把 AIPREF 归为“跟踪项”而非“部署项”：订阅 attach 与 vocab 两个草案的 datatracker 页面，等 RFC 落地与厂商声明。
2. 试验环境可以先发 Content-Usage 头打通工具链，但不要在生产环境依赖其效果。
3. 若提前部署，记住最严者胜：检查子路径的 n 会不会覆盖主域的 y。
4. 现阶段表达“可搜索不可训练”，仍用具名组 robots 配置，协议基础见 robots.txt（AI 语境）术语卡。
5. 评估 use= 与 ai.txt 等竞争方案时，注意它们与 aipref 的语法互不兼容，不要混写。
6. 记住偏好变更不追溯——别指望发一个 n 就撤回已被抓走的内容。

限制与待核实

• vocab 草案多个关键章节仍标“缺乏 WG 共识”，词表与合并语义在定稿前都可能变。
• 厂商支持为零的判断基于 2026-10 检索（未检索到任何正式声明）；口头表态未逐一核实。
• “40% web 采用”出自 2025-04 会议记录的内部讨论口径，非工作组承诺。
• 送 IESG 的新时间表未公布，原 2026-08 里程碑已过期。