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。在 HTMLhead里加入一个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 的既有框架如果能做到“字段 用途 授权对象”的组合控制那它就有机会成为商业数据流通里一个非常重要的技术基础设施。