Shelf Protocol 这个项目名字一出来，我第一反应是：商业数据终于也要有属于自己的 robots.txt 了。robots.txt 是网站管理员用来告诉搜索引擎爬虫哪些路径可以抓、哪些路径不能抓的文本协议；而 Shelf Protocol 从命名上看，就是想给电商、品牌、商品、橱窗类的商业内容做一套类似规则。它想解决的，是数字商业里越来越尖锐的一个问题：你的商品信息、价格、库存、评论、品牌描述，能不能被别人采集？采集之后能不能用来训练模型？能不能放进聚合平台二次展示？现行技术里没有统一答案。
如果你在品牌方、电商平台、供应链数据团队或者做数据采集服务，这个方向值得认真看。它的价值不在于“又多了一个协议文件”，而在于它把商业数据的使用边界从“人工判断”变成“机器可读”。下面我从为什么需要它、协议可能长什么样、落地要考虑什么问题、开发者怎么接入，以及和 robots.txt 的成熟经验有哪些差异来拆一遍。
1. 为什么商业内容需要一份“robots.txt”
1.1 robots.txt 解决的是传统网页抓取问题
robots.txt 已经存在很多年。它的工作方式很简单：网站在根目录放一个文本文件，里面用User-agent区分爬虫，用Allow和Disallow声明路径范围，爬虫访问前先读取这个文件，再决定要不要抓取对应页面。
这个机制解决了一个基础问题：在没有规则的情况下，爬虫只能靠“礼貌”和“自律”判断边界。有了 robots.txt 之后，网站管理员至少能把想法告诉所有遵守协议的爬虫。搜索引擎、目录站、研究爬虫大多会遵守，这是一种非常朴素但有效的数据治理方式。
但 robots.txt 的语义很窄。它只回答一个问题：某个路径能不能被抓取。它不回答：抓取之后能不能用来做推荐、能不能放进知识库、能不能用来训练大模型、能不能二次转售。也就是说，它管的是“访问的入口”，管不了“数据的使用方式”。
1.2 商业数据的规则缺失带来哪些混乱
商业内容和普通网页不同。一个商品页面，里面同时包含 SKU、价格、库存、品牌介绍、材质、规格、用户评价、优惠信息等结构化数据。这些数据对很多业务方都有价值：比价网站需要价格，AI 购物助手需要商品图谱，品牌方需要监控渠道价格，供应链需要库存信息。
问题在于，这些数据出现在同一个页面里，但使用场景完全不同。数据提供者可能希望搜索引擎抓取商品页帮助导流，却不希望第三方把价格抓去比价；也可能希望公开库存给供应链伙伴，却不希望消费者爬到库存后产生误导。这些细微的语义，robots.txt 表达不出来。
结果就是两个极端。要么所有爬虫一视同仁，能抓的全抓，不能抓的靠技术反制；要么干脆用登录、验证码、签名把数据全部锁住，连正常合作方也拿不到。前一种让品牌方觉得数据被滥用，后一种又让正规数据流通成本变得很高。
1.3 Shelf Protocol 想填什么空
从项目标题的定位来看，Shelf Protocol 想做的，是把“商业内容的访问和使用规则”标准化成一种类 robots.txt 的东西。
这里的关键词不是“禁止抓取”，而是“声明规则”。一个品牌方可以在自己的商品域名下发布规则，声明哪些数据允许读取、哪些数据禁止训练、哪些数据需要授权后才能二次分发。数据需求方在采集之前先读取规则，按规则执行。这样就不需要每次都签线下合同、也不需要靠技术猫鼠游戏来解决。
它更像一个“数据使用许可层”。传统 robots.txt 只解决“能不能进”，Shelf Protocol 想解决的是“进来之后能做什么”。这个定位如果成立，商业数据流通的边界就会清晰很多。
2. 从协议角度拆解，Shelf Protocol 可能长什么样
公开资料里目前没有特别完整的协议规范，所以我这里更多是基于命名逻辑和商业数据场景做推断。你如果准备接入或评测一个早期协议项目，可以从这几个维度去看它的设计。
2.1 规则的主体可能不是 URL，而是商品对象
robots.txt 的规则粒度是路径，比如/products/或者 `/products/shoes/。对电商场景来说，这个粒度太粗了。一个商品页可能同时包含价格、图片、评论、推荐组合；一个品牌频道可能包含几十个字段。如果只按路径声明，很难精确表达“商品描述可以抓，价格不能抓”。
所以我估计 Shelf Protocol 的第一个设计重点会落在“对象”上。它可能要声明的不只是/products/{sku}是否允许访问，而是某个商品对象下，哪些字段是公开的、哪些字段是受限的、哪些字段完全禁止。
字段级别的规则比路径级别复杂，但更符合商业数据流通的真实需求。比如：
- 商品标题、主图：允许收录，用于搜索展示。
- 价格：允许读取，但禁止存储超过 24 小时。
- 库存：仅对授权合作方开放。
- 用户评论：可读，但禁止用于训练推荐模型。
- 品牌描述：可读，但禁止二次转售。
这种粒度才配叫“robots.txt for Commerce”。如果它还是只能区分整个路径，那和现有 robots.txt 的区别就不大。
2.2 规则表达：需要区分读取、存储、训练和分发
真实商业场景里，“允许抓取”不代表“允许所有用途”。我见过很多数据需求方只关心能不能抓，抓回来之后放在哪里、怎么用，很少有人问。这正是数据提供方最大的顾虑。
如果协议要解决这个问题，规则语言里至少要有几种独立的行为标签，比如：
read：允许读取并解析，用于临时展示或检索。store：允许持久化保存。train：允许用于模型训练，包括推荐模型、价格预测模型、大模型微调。redistribute：允许在另一个平台上发布、转售或聚合展示。attribution：是否必须标注来源。
这几个标签可以自由组合。例如一个品牌方可以声明：
- 允许
read和store，但禁止train和redistribute。 - 允许
read，但要求attribution。
只有把“使用方式”也纳入规则，商业数据的授权才算真正闭环。否则即使协议写出来了，爬虫方读了也只是“礼貌参考”，没有实质约束力。
2.3 发现机制：爬虫怎么知道规则在哪
robots.txt 之所以普及，是因为发现路径非常固定：标准协议规定，爬虫访问网站根目录时会首先检查/robots.txt。不需要额外注册，不需要调用 API，也不需要知道站点管理员的联系方式。
Shelf Protocol 如果要推广，必须有类似的低摩擦发现机制。可能的方向有几种：
- 在网站根目录放一个固定文件，比如
/shelf.txt或/shelf-protocol.json。 - 在 HTML
<head>里加入一个<link>标签，指向规则文件。 - 在 HTTP Response Header 中增加一个字段，比如
Shelf-Rules: /shelf/rules.json。 - 在现有的商品页 JSON-LD 结构化数据里扩展
UsagePolicy字段。
不管用哪种方式，关键判断标准都一样：爬虫能否在“不需要人工问答”的前提下，稳定地找到规则文件、解析规则、应用到采集行为上。
2.4 与现有 robots.txt 的关系：兼容还是替代
这里还有一个现实问题：Shelf Protocol 和 robots.txt 是并行使用，还是替代关系？
我的判断是，初期一定是并行使用。robots.txt 仍然负责基础的抓取边界，Shelf Protocol 负责更细粒度的使用规则。数据获取方读取规则时，先看 robots.txt 判断路径是否可抓，再看 Shelf Protocol 判断抓下来之后能做什么。这样兼容成本最低，老爬虫也不会因为不识别新协议而完全失效。
如果协议想完全替代 robots.txt，那它必须连路径发现逻辑也一起实现，而且要让所有浏览器、搜索引擎、开源爬虫都默认支持，这个难度非常高。早期项目大概率不会这么做。
3. 落地时最需要想清楚的五个问题
协议设计是一回事，真正落地是另一回事。我见过很多好想法死在“标准没人遵守”上。Shelf Protocol 如果只是写一个规范文件，不可能改变商业数据生态。它必须回答下面这几个很实际的问题。
3.1 谁有权利定义规则
第一个问题是授权主体。品牌方可以定义品牌目录的规则，电商平台可以定义平台商品页的规则，但这两者经常冲突。
比如一个品牌入驻某电商平台，品牌方希望价格可以被比价网站读取，因为这样能扩大曝光；但平台方可能不希望第三方直接抓取站内价格，因为比价流量会绕过平台交易。这时规则以谁为准？
可能的解决方案是做层级化规则。平台层的规则兜底，品牌层可以指定更严格或更宽松的策略，商家可以在店铺空间内配置字段级规则。真实采集时按“最严格优先”还是“最具体优先”，协议必须写清楚。这个决策直接决定规则系统的可用性，也会是早期最容易吵起来的地方。
3.2 规则怎么与现有爬虫协议兼容
很多爬虫目前已经有自己的 robots.txt 处理逻辑，甚至不会检查第三方规则文件。要让它们支持 Shelf Protocol，要么在现有 robots.txt 里扩展语法，要么提供一个很轻的“入口”让爬虫可以顺带发现。
比如在 robots.txt 中增加一行：
Shelf: /shelf-protocol.json这不是官方标准，但思路很直观：老爬虫可以忽略这行，新爬虫看到后继续去读 JSON 规则。这种兼容方式成本最低。如果新协议非要另外设一个独立文件，且要求所有爬虫默认检查，推广阻力会大很多。
3.3 规则怎么验证和执行
robots.txt 从一开始就不是强制的。搜索引擎和主要爬虫遵守，更多是出于行业自律和避免法律风险，而不是因为技术上无法绕过。Shelf Protocol 大概率也会面临同样的处境。
所以必须提前区分两个概念：协议执行的“技术约束”和“商业约束”。
- 技术约束：规则文件存在，爬虫读取，并按规则做出决定。
- 商业约束：不遵守规则的数据方，可能在 API 授权、商业合作、法律条款上承担后果。
如果协议能做一套可视化验证工具，让数据提供方看到“哪些爬虫读取了规则、是否触发了限制”，它的实际价值会大幅提升。验证能力比语法规范更重要。
3.4 授权链路和身份认证怎么处理
商业数据里有些规则不能完全公开。例如“允许供应链伙伴读取库存”“允许特定比价平台读取价格”。如果规则文件放在公网，任何匿名的爬虫都能读到规则，但规则无法判断“你是谁”。
所以协议可能还需要配合授权标识。常见做法是在规则文件中声明哪些对象需要 token、API Key 或者数字签名；爬虫读取受限字段时，要附带凭证，数据提供方再根据凭证校验权限。
这个设计会带来一个额外问题：规则文件本身公开，但资源不能公开，那“允许读取”的判定就变成“能否带上有效凭证”。这与 robots.txt 的完全匿名模式不太一样，也意味着协议需要同时定义请求头、签名方式、错误返回等接口规范。
3.5 与 AI 训练、数据聚合、Agent 采购的边界
现在商业数据的最大消费场景之一，已经从“网页搜索”变成了“AI 训练”和“Agent 自动采购”。一个 AI 购物助手可能为了回答“哪家最便宜”，同时抓取几十个品牌站点。如果这些站点没有声明“数据是否可以用于训练”，AI 训练方只能靠合规团队逐个人工判断，极不现实。
Shelf Protocol 如果能清楚区分read和train的边界，对 AI 场景的价值会非常大。例如：
read：允许助手在实时请求中读取并展示。store：允许存入短期缓存。train：禁止把商品信息加入模型训练集。
这比单纯的“禁止爬取”更符合 AI 时代的商业现实。很多品牌并不反感 AI 助手推荐自己的商品，只是不希望被无差别地拿去训练竞品模型或低价分析。声明好使用场景，比一刀切禁止更有用。
4. 从开发者视角看，怎么评估和接入一个早期协议
如果你看到 Shelf Protocol 后，想试试它能不能用于自己的网站或采集流程，我建议先按下面这个思路走一遍。它同样适用于其他早期数据治理协议。
4.1 先判断它是标准还是客户端
早期项目经常有一个容易混淆的点：它到底是一个“协议标准”，还是一个“软件工具”。
- 协议标准：定义了规则格式、发现机制、字段语义，各方各自实现。
- 软件工具：提供解析器、规则编辑器、爬虫过滤中间件等开箱即用的程序。
这两者的接入方式完全不一样。如果是协议标准，你要评估它是否被社区接受、有没有多语言 SDK；如果是工具，你要看部署难度、依赖环境、是否支持你的业务规模。项目标题里的“Protocol”一般指标准，但很多项目会同时附送参考实现，所以最好去仓库里确认 docs 和 examples 目录。
4.2 数据提供方的接入流程
如果你是品牌方或平台方，想在自己的商品域上声明规则，通用流程可以这样理解：
第一步，确认规则文件放在哪个位置。按当前大多数网站的习惯，我会优先考虑放在网站根目录，或者通过 HTTP Response Header 声明，这样爬虫更容易发现。
第二步，定义规则。先想清楚你的商业目标：你想让搜索引擎收录，还是只允许合作 API 调用？哪些字段可以公开？训练和转售是否允许？把这些答案结构化。
第三步，生成规则文件并进行校验。校验内容包括文件是否能被正常访问、JSON 格式是否正确、路径是否和实际 URL 匹配、是否有前后冲突的规则。
第四步，持续审计。通过日志或专有后台，观察哪些爬虫读取了规则，有没有高频访问，有没有触发警告。
下面是一个模拟的规则文件示例，不是 Shelf Protocol 的官方格式，只是为了帮助理解：
{ "shelf": "0.1", "domain": "example-shop.com", "subject": "product", "rules": [ { "scope": "/products/*", "fields": { "title": "allow", "image": "allow", "price": "allow", "inventory": "deny", "review": "allow" }, "usage": { "read": true, "store": true, "train": false, "redistribute": false, "attribution": true } } ] }这个示例里最值得注意的字段是usage。它把“能不能抓”和“抓了能不能用”分开，这正是商业场景和普通网站最大的区别。
4.3 数据消费方的接入流程
如果你的业务需要采集商品数据，评估一个商业规则协议时，至少要检查这些点：
- 是否在采集前读取规则文件。
- 是否区分
allow和deny字段。 - 是否记录规则的最后一读时间，方便后续审计。
- 是否对受限数据做删除或脱敏。
- 是否在二次分发时保留来源标识。
一个比较稳妥的做法是：在爬虫调度器里加一个“规则检查中间件”。每次请求商品 URL 之前，先检查缓存中的规则文件，确认目标字段允许访问；如果规则发生变化，优先按更严格的方向处理。这样即使规则更新滞后，也不会立刻造成违规。
4.4 小样本验证比直接全量更重要
我建议接入任何早期协议时，都先用小样本跑通完整流程，不要一上来就全量接入。
小样本流程大概包括：
- 选 10 到 50 个商品 URL。
- 模拟读取规则文件。
- 按规则抓取字段。
- 检查结果是否符合声明。
- 再手动修改规则文件，观察新爬虫请求是否立刻读取新规则。
这样跑一遍，能提前发现很多问题：规则路径写错、字段名不匹配、缓存失效慢、某个规则被更高优先级覆盖。等小样本稳定后，再逐步扩大范围。
5. 对照 robots.txt 的成熟经验，商业版需要补哪些短板
robots.txt 出来这么多年，有大量经验可以直接复用，但也有不少局限。这些局限在商业数据场景里会被放大。
5.1 robots.txt 的局限一：不控制使用
robots.txt 只声明可访问性，不声明使用场景。这个局限在商业数据里非常致命。
一个数据方完全遵守 robots.txt，允许搜索爬虫抓取商品页，但它可能把抓下来的数据存在自己的数据库里，训练成本模型，然后做出一个比价产品，跟原商家抢流量。这从 robots.txt 层面看没有任何问题，因为 robots.txt 没说不允许使用。这也是为什么很多品牌方越来越不愿意把价格数据完全开放。
商业协议必须把“使用”作为规则的一等公民。只声明“可访问”等于没声明，因为使用才是真正的风险点。
5.2 robots.txt 的局限二：动态内容难以覆盖
很多商品页面的关键信息不是静态 HTML，而是通过 AJAX 或接口动态加载的。比如价格、库存、优惠券，都是前端异步请求获得的。robots.txt 只能禁止某个路径，很难细到“某个 JSON 返回里的某个字段是否可用”。
Shelf Protocol 如果要做字段级规则，就需要考虑数据接口的集成。常见做法是给接口也挂一套规则，比如：
GET /api/v2/products/{sku} -> 读取规则后再决定返回哪些字段也就是说，规则不只存在于“页面层”，还要能作用到 API 层。这种设计比 robots.txt 复杂，但也更贴合现代电商系统的数据流。
5.3 robots.txt 的局限三：没有版本和时间维度
robots.txt 是静态文本，通常很少更新，也没有历史版本。商品数据却变化很快。价格今天能抓，明天改了促销策略可能就不希望被抓；库存数据可能只在特定时间段对特定伙伴开放。
商业规则协议应该要有版本号、生效时间和过期时间。这样爬虫读到规则时，能判断自己手中的缓存是否已经过期，是否需要重新获取。否则一个数据方更新了规则，爬虫还按旧规则跑，又会造成误解。
模拟规则增加时间维度，可能是这样：
{ "version": "2025-06-01", "valid_from": "2025-06-01T00:00:00Z", "valid_until": "2025-12-31T23:59:59Z" }有了版本和时间，第三方在审计时就能说清楚“我按哪个版本的规则采集了哪些数据”。这对商业合规非常重要。
5.4 从“不让抓”到“可按规则使用”的转变
当前行业里的主要矛盾，在我看来不是“爬虫抓多了”，而是“规则表达不了授权”。很多品牌方并不是想彻底禁止所有爬虫，而是想区分不同对象、不同用途。
一个成熟的商业规则协议，应该让数据提供方配置出这样的策略：
- 搜索引擎：可以读，可以存，可以展示摘要。
- 比价平台：可以读价格，不能读库存，不能用于模型训练。
- 授权经销商：可以读库存，可以读商品描述，但必须带来源标识。
- 普通消费者：可以读所有公开字段，但只允许浏览器内使用。
这种细粒度授权，已经超过 robots.txt 的能力范围，需要进行对象管理和用途管理。如果 Shelf Protocol 能往这个方向走，它就不只是一个“克制爬虫的工具”，而是一套真正的商业数据基础设施。
6. 我的一些判断和实际操作建议
6.1 这个方向短期更适合内容平台和品牌方
从项目标题看，Shelf Protocol 还处在“Show HN”阶段，也就是原型展示和社区讨论阶段。它最可能的早期使用者，不是普通独立站站长，而是三类角色：
第一类是品牌方。他们有明确的商品数据控制需求，也有技术能力去配置规则。第二类是电商 SaaS 平台，它们可以把协议集成到模板中，让大量商家一键生成规则。第三类是数据需求方，比如 AI 购物助手、价格分析服务，它们需要一套可审计的数据合规方案。
如果你只是个人博客或静态站点，那么现有 robots.txt 仍然够用，暂时不需要引入新的协议。但如果你想做商品数据公开，又怕被滥用，倒是可以关注这个方向，用一个小电商站去测。
6.2 最大的难点不在语法，而在生态位
我可以负责任地说，写一个规则文件、定义几个 JSON 字段，对任何有经验的开发者都不难。难的是让足够多的数据提供方和数据消费方同时接受这个协议。
这背后有一个冷启动问题：只有数据提供方配置规则，而没有爬虫读取，等于白配；只有爬虫支持读取，而没有站点配置，也等于白做。要打破僵局，需要有一个中间角色强制或引导双方使用。
谁最有可能做成这件事？一种力量是搜索引擎和大型 AI 训练方。如果它们宣布，未来采集商品数据时会优先读取某个协议，数据方就会主动配置。另一种力量是电商平台或支付公司，它们可以直接在商家后台提供默认规则模板。还有一种力量是法律合规要求，让“是否声明数据用途”变成一种准入标准。
对一个“Show HN”项目来说，早期不需要一步到位，先提供一个足够优雅的参考实现，再争取几个头部数据方验证，是比较现实的发展路径。
6.3 值得关注的验证指标
如果你真的要去试一个类似 Shelf Protocol 的早期项目，我建议不要只看它支持多少语法，而是重点看下面几个指标：
- 规则发现成功率：爬虫能否在正常请求流程中稳定找到规则文件。
- 规则解析成功率：遇到格式错误、编码异常、字段缺失时，能否安全降级。
- 规则变更生效时间：修改规则文件后，爬虫平均多久能读到新版本。
- 误伤率：有没有因为规则歧义，导致原本允许的数据也被禁止。
- 生态支持度：是否已经有开源爬虫框架、SDK、CMS 插件加入支持。
这些指标比“支持多少种字段”更能反映协议的真实可用性。
6.4 如果想参与，从小处做起
最后给一个比较务实的参与路径。
先不要急着在大规模生产环境接入，也不要被“行业标准”这四个字冲昏头。你可以先做这三件事：
- 读一遍项目仓库里的 protocol 文档，搞清楚它到底定义了哪些字段。
- 在你的域名下加一个最小规则文件，内容只覆盖一个商品列表页。
- 写一个简单的脚本，模拟爬虫读取规则，并判断是否遵守
deny字段。
跑完这三步，你就知道这个协议是纸上谈兵，还是真的能解决商业数据流通问题。也不要怕阶段太早，任何协议最开始都是一个小生态。真正有用的是，它能不能让数据提供方和数据消费方之间的对话变得更简单、更透明、更可追溯。
我个人更建议你关注它在“字段级使用权限”上的设计。如果只做路径级声明，它很难跳出 robots.txt 的既有框架；如果能做到“字段 + 用途 + 授权对象”的组合控制，那它就有机会成为商业数据流通里一个非常重要的技术基础设施。
