Content Signals 与 AIPREF 的区别
两者都试图在“能不能来”（robots 具名组）之外表达“来了能怎么用”，但路线完全不同。Content Signals 是 Cloudflare 2026-07 落地的单方实验：在 robots.txt 里加 use= 字段（如 use=reference），分 immediate、reference（默认）、full 三档，表达“可以怎么用”，与具名组的“能不能来”正交。AIPREF 是 IETF 正式工作组的标准路线（2025-01 charter）：attach 草案（-05 版，作者含 Google 的 Gary Illyes，将更新 RFC 9309）定义 HTTP 头与 robots.txt 两种附着方式，vocab 草案（-08 版）定义词表——但截至 2026-10 两份都还是 Internet-Draft，未成 RFC。
对照表
| 维度 | Content Signals | AIPREF |
|---|---|---|
| 推动方 | Cloudflare 单方 | IETF aipref 工作组 |
| 附着点 | robots.txt use= 字段 | HTTP 头或 robots.txt 规则（attach 草案） |
| 表达能力 | immediate/reference/full 三档 | 词表仅 train-ai/ai-use/search 三类 |
| 现势（2026-10） | 已在 Cloudflare 侧落地 | 草案 -05/-08 版，成 RFC 时间表未公布 |
| 标准地位 | 非 IETF 标准 | Internet-Draft（将更新 RFC 9309） |
| 互操作性 | 与 AIPREF 并行且互不兼容 | 同左 |
常见混淆
一是把两者当成同一标准的两个名字——它们是竞争路线，写法不通用。二是高估 AIPREF 的可用性：词表只有三个类别，想表达的偏好落不进去就只能不表达，自造标签在 Structured Fields 语法里是非法值，等于什么都没说；原定 2026-08 送 IESG 的工作组里程碑已过期未达成。三是把任何偏好声明当执行机制：具名组之外的声明都依赖爬虫方自愿尊重，且执行层在协议之外——user-triggered 类爬虫连 robots.txt 本身都不承诺遵守，偏好表达管不到它们。
选用建议
今天的排序很清楚：有效控制仍靠 robots.txt 具名组逐条写（这是唯一立即生效的层）；Content Signals 可叠加——但别与具名组配置混为一谈，且要记住它是单方实验、下游支持面有限；AIPREF 跟踪不部署——两份草案的分工是 vocab 管“词”、attach 管“贴在哪”，词表没定稿，附着机制的实现就悬空，等成 RFC 再动。现势细节见AIPREF Content-Usage 档案、AIPREF 术语卡与爬虫访问控制实战档案；与既有协议的关系另见对照卡robots.txt 与 AIPREF 的区别。