ERC-7517 数据挖掘偏好：给 NFT 元数据写一份 AI 使用声明

作品被爬虫批量抓走训练模型，是数字创作者这几年最焦虑的问题之一。网站世界早就有 robots.txt 这种“机器可读的意愿声明”，ERC-7517 想把同类机制搬上链：在 NFT 或内容元数据里加一个叫 dataMiningPreference 的结构化字段，让模型训练方在采集阶段就能程序化地读到创作者的许可偏好。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Draft。

三档取值与六类用途

每个用途属性的取值只有三种：allowed 表示可自由使用；notAllowed 表示严格禁止；constrained 表示允许但有条件，具体条件不写在这个字段里，而要回到元数据引用的许可文本里查——这种设计是为了避免链上枚举与许可合同两处各说各话。用途维度则铺开了一组属性：dataMining 管一般性数据挖掘，aiInference 管能否把作品作为模型输入做推理，aiTraining 与 aiGenerativeTraining 区分非生成式与生成式训练，aiTrainingWithAuthorship 和 aiGenerativeTrainingWithAuthorship 则是在允许训练的前提下要求披露作者署名。一份示例声明可以同时写“数据挖掘允许、推理允许、带署名训练允许、生成式训练禁止”，颗粒度远比一句“版权归作者所有”要细。

与 C2PA 和 ERC-7053 的衔接

提案在依赖上挂着 ERC-721 与 ERC-7053，理由是要把声明同时绑定到链上代币和“内容哈希索引”两层；正文还专门对齐了 C2PA——这个在图片文件内部记录来源与编辑历史的行业标准，同样规定过“是否可用于 AI 训练”的声明方式。两者一个活在文件里、一个活在合约档案里，对齐的意义是让采集方无论先碰到文件还是先碰到链上记录，读到的偏好应当一致；一旦两处不一致，本身就是值得警惕的信号。

声明的效力边界

采集方与平台怎么落地

对训练数据管道来说，这份标准的价值在于把“许可”从一段人读的文本变成一次布尔判断：采集程序抓到一个内容哈希或代币编号，先查元数据里的 dataMiningPreference，按属性分流——明确禁止的跳过、要求署名的登记署名义务、标记 constrained 的转人工审许可。没有统一字段之前，这一切都靠平台各自的爬虫规则，口径互不相通。创作者侧的配套动作同样具体：铸造时把偏好写进元数据只是起点，还要确保许可文本在可访问的地址上长期有效，否则链上指针指向 404，声明就退化成一句空话。平台侧则需要处理声明冲突——同一作品在不同版本元数据里前后不一致时，采集方应默认取更保守的那一档。这些都不写在提案正文里，却是它能否走出文档的现实环节。

与邻近标准的边界

ERC-7517 只管“偏好声明”，不管技术执行：不阻止抓取、不颁发许可、也不做水印。它上游站着 ERC-7053——用内容哈希把作品文件与链上记录对起来的那套索引标准；平行位置上是 C2PA 的文件内元数据；下游则连着各国正在讨论的训练数据合规规则。把它理解成一层“机器可读的意愿层”，恰好介于法律文本与技术防护之间：比许可协议更容易被程序消费，比内容指纹更容易被创作者自主填写。三层各自缺一，采集治理都会漏。

必须把话说明白：dataMiningPreference 是一份链上可读的意愿表达，不是技术锁，也不是法律裁决。数据是否真的没被拿去训练，取决于采集方是否自愿遵守；主张侵权或违约，最终仍要走现实世界的许可与法律程序。对买家，它可以作为评估创作者授权姿态的透明线索；对采集方，它降低了逐份翻许可文本的成本。把“有声明”误读成“有保障”，是把披露当保护的老毛病。另需注意提案仍在 Draft 阶段，字段名与枚举都可能随评审调整，落地实现要以核验时仓库正文为准。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。