最近在 Hacker News 上看到一个项目标题本身就很值得琢磨Shelf Protocol —— Robots.txt for Commerce。把电商数据和 robots.txt 放在一起类比是一种很有冲击力的提法。先说我的判断如果这个定位真能立住它解决的不是“让爬虫别来抓页面”这种表层问题而是商业数据在开放互联网上如何被授权使用的问题。做电商站点的开发者多少都有过这种经历站点内容放在公网上谁都能打开可数据一旦被抓走被比价、被倒卖、被拿去训练模型你又很难追责。传统 robots.txt 能拦住“守规矩的爬虫”但拦不住“不守规矩的爬虫”更表达不了“页面可以看但价格不能拿去比价”这种商业意图。这篇文章会从 robots.txt 的边界讲起拆解 Shelf Protocol 到底想解决什么问题然后给出实际电商场景下的规则文件编写方式、接入验证流程以及安全合规方面的落地建议。即使这个协议最终形态会有变化“商业数据授权声明”这套思路也值得每一个做电商或数据开放平台的开发者关注。1. 这篇文章真正要解决的问题先看一个最常见的矛盾电商数据需要公开才能被搜索、被比较、被用户发现但数据一旦公开就会被批量抓取用于你无法控制的场景。比如你做的是跨境电商独立站商品详情页、SKU 价格、库存数量都在公网上。比价引擎会来抓价格优惠券插件会来抓促销信息内容农场会来抓产品描述AI 公司会来抓图文数据做训练集。这些行为不一定违法但绝大多数不是站点运营者的本意。你缺的并不是一把“锁”而是一份能表达“什么数据允许什么角色用来干什么”的机器可读协议。Shelf Protocol 的定位正是想补上这一块。用“Robots.txt for Commerce”来理解它会得到几个关键信息它是一个公开的、机器可读的规则声明。它不解决技术对抗只解决规则表达。它的约束力来自“遵守协议的客户端”和“愿意主张权益的服务端”而不是技术强制。所以这篇文章适合三类读者。第一类电商平台、独立站、品牌官网的技术负责人你需要决定站点数据对外部爬虫和 AI Agent 的开放策略。第二类数据服务商、价格监控工具、AI 数据供应商的开发者你需要判断抓来的数据能不能用、能用到什么程度。第三类正在业余关注机器可读协议、爬虫治理、数据合规的开发者这个项目是一个很好的观察样本。2. Robots.txt 的边界为什么传统协议管不住商业数据2.1 robots.txt 到底做了什么robots.txt 是 1994 年前后出现的网站爬虫访问规则本质是一个文本文件。爬虫在抓取某个站点前先请求这个文件按文件的声明决定哪些路径可以访问。一个最简单的 robots.txt 长这样User-agent: * Disallow: /checkout/ Allow: /product/它表达的意思是所有未指定的抓取客户端不能抓/checkout/开头的内容但可以抓/product/开头的内容。这套机制的优点非常明显零成本、去中心化、业内共识。任何一个正规爬虫都会先读取它。但它也有一个致命短板它只描述“页面路径能不能抓”不描述“抓到的数据能不能用于某个业务目的”。2.2 robots.txt 管不住的三类场景第一类页面可抓但数据不适合被商用。商品详情页完全可以被搜索引擎抓取用于自然搜索展示但如果同一页面的价格被批量抓走后用在比价平台上就可能破坏品牌定价体系。robots.txt 表达不了这种区别。第二类不同抓取方应该有不同的权限。同一个接口搜索引擎可以访问比价引擎不应该访问AI 训练爬虫更不应该批量下载。robots.txt 虽然可以用多个 User-agent 块做区分但只能区分客户端名称无法区分用途也无法表达“允许读取但禁止用于模型训练”这类规则。第三类数据已经离开页面了。你开放了一个商品查询 API返回 JSON 数据爬虫直接调用接口就能拿到结构化结果。robots.txt 通常只声明到路径层面技术语义上“你能访问这个 URL”和“你只能用返回数据的一部分字段”是两码事。2.3 从页面控制到数据控制的本质变化传统爬虫治理关注的是“是否允许访问某个 URL”商业数据治理关注的是“是否允许使用某类数据”。前者是访问控制后者是使用许可。Shelf Protocol 想做的正是把后者变成一种可发布的规则文件。所以你可以理解为robots.txt 是 Web 时代的“机器人门禁”Shelf Protocol 是电商数据时代的“商业使用说明书”。它不负责验证你是谁只负责把规则说清楚。谁遵守、谁不遵守后续由合同、技术检测和法律手段去解决。3. Shelf Protocol 的核心设计思路3.1 定位给商业数据加一份“使用许可”从项目标题和定位来看Shelf Protocol 想表达的是在商业数据被外部程序读取之前站点可以发布一份声明说明哪些数据允许读取、读取后允许用于什么目的。我把它拆成三个问题就比较好理解谁在请求数据是搜索引擎、比价引擎、AI 训练爬虫还是普通用户请求了哪些数据商品标题、描述、价格、库存、评价、优惠信息打算用来做什么搜索展示、比价、数据分析、模型训练、二次分发如果一份协议能把这三个问题写成机器可读的规则那么“电商版的 robots.txt”这一类比就成立了。3.2 与 robots.txt 的差异对比可以用一张表对比传统 robots.txt 和 Shelf Protocol 的设计差异。注意这里的差异基于对“Robots.txt for Commerce”定位的合理推导而非某个已发布版本。对比维度robots.txtShelf Protocol 的定位核心对象URL 路径商业数据字段与使用场景表达粒度抓取权限使用许可区分依据客户端名称数据类别、使用者身份、用途典型动作Allow / DisallowAllow / Deny 某种商业用途适用场景通知搜索引擎与爬虫约束比价、AI 训练、数据采集方约束力来源行业约定行业约定 法律合同 技术检测3.3 协议形态的合理推测由于项目仍处于早期阶段我不能替作者确定正式语法。但从“Robots.txt for Commerce”的定位出发可以合理推测它会提供以下能力一个公开 URL例如/shelf.txt用户可以通过 HTTPS 直接访问。文本格式接近 robots.txt 的规则名: 值风格容易手写也容易被解析器读取。也可能会提供 JSON 或 YAML 派生格式方便接入配置管理和自动化工具。规则文件需要支持版本号或生效时间避免长期模糊。这些判断并不是对官方规范的复述而是从问题出发的合理设计方向。你在落地时可以按这个思路做自己的规则声明不一定要等协议标准化。4. 实战为电商站点编写 Shelf 规则文件真实项目里规则文件的语法一定以官方发布为准。下面给出的是演示性设计核心目的是展示“如何用 robots.txt 的思维方式表达商业规则”。4.1 规则文件放哪里可以放在站点根目录用/shelf.txt路径对外提供。这样任何客户端都能通过标准 URL 获取规则。站点根目录还常放robots.txt和sitemap.xml把规则文件放在同一层便于维护。# 文件路径站点根目录 /shelf.txt # 版本标识方便客户端判断规则是否过期 Shelf-Version: 1.0 Shelf-Updated: 2025-01-01 Contact:># 文件路径/shelf.txt # 面向普通爬虫和搜索引擎 User-agent: * Product-title: allow Product-description: allow Product-image: allow # 面向比价引擎 User-agent: price-comparison Product-price: deny Stock-inventory: deny Promotion-info: deny # 面向AI训练爬虫 User-agent: ai-training Product-description: allow Product-price: deny Review-content: deny这段规则的意义在于同一个站点不同请求方看到的“许可”完全不同。比价引擎可以正常浏览页面但不允许批量抓取价格和库存AI 训练爬虫只能读取商品描述做常识理解不能拿评价数据训练模型。4.3 一个面向 AI Agent 的规则示例如果你是做品牌内容分发的希望 AI 搜索引擎能准确引用你的产品规格但又不希望你的内容被用来生成同品类竞品文案可以这样写# 文件路径/shelf.txt # 允许 AI 搜索助手读取结构化商品信息 User-agent: ai-search-agent Product-spec: allow Product-title: allow Product-description: allow # 禁止用商品数据训练生成式模型 User-agent: ai-training All-data: deny # 禁止将商品数据用于转售和二次打包 User-agent:>{ version: 1.0, updated: 2025-01-01, owner: data-ownerexample.com, policies: [ { role: search-engine, product_title: allow, product_description: allow, product_price: allow, stock_inventory: deny }, { role: price-comparison, product_title: allow, product_description: allow, product_price: deny, stock_inventory: deny }, { role: ai-training, product_title: allow, product_description: allow, product_price: deny, review_content: deny } ] }JSON 格式的可读性不如纯文本但更容易被程序消费。建议两个格式都提供/shelf.txt给人看/shelf.json给程序读。4.5 规则解析要点编写规则时有几个容易混淆的点。第一规则名大小写。robots.txt 中指令不区分大小写但这里建议统一小写减少解析器的兼容成本。第二角色分类。不要把User-agent写成具体某个爬虫的产品名而应该写“行为角色”。否则新爬虫出现时规则没覆盖到又会回到默认放行状态。第三默认策略。对未识别的客户端建议默认 deny 敏感字段而不是默认 allow。也就是“无声明即拒绝”与 robots.txt 的“无声明即放行”正好相反。这样更符合商业数据保护的需要。5. 接入与验证从规则文件到访问控制规则文件发布之后还需要做两件事让站点正常对外输出规则让客户端能读取并校验规则。下面给出一套最小可用的接入方案。5.1 Web 服务器公开规则文件以 Nginx 为例在站点配置中增加两个 location 规则。实际上文件已经放在站点根目录也可以但显式配置能控制响应头。# 文件路径/etc/nginx/conf.d/shelf.conf server { listen 443 ssl; server_name example.com; location /shelf.txt { default_type text/plain; alias /var/www/example/shelf.txt; add_header Cache-Control public, max-age3600; } location /shelf.json { default_type application/json; alias /var/www/example/shelf.json; add_header Cache-Control public, max-age3600; } }配置完成后需要重载 Nginxnginx -t nginx -s reload5.2 Python 脚本读取和解析规则客户端想要遵守规则就得先解析规则。下面是一个最小解析器示例把/shelf.txt的文本规则解析成 Python 字典。# 文件路径check_shelf.py import requests def parse_shelf(text): 解析类 robots.txt 格式的 shelf 规则。 rules {} current_agent None for line in text.splitlines(): line line.strip() if not line or line.startswith(#): continue if : not in line: continue key, value line.split(:, 1) key key.strip().lower() value value.strip() if key user-agent: current_agent value.lower() rules.setdefault(current_agent, {}) elif current_agent: rules[current_agent][key] value else: # 文件头部的全局声明 rules[key] value return rules if __name__ __main__: url https://example.com/shelf.txt resp requests.get(url, timeout10) resp.raise_for_status() rules parse_shelf(resp.text) print(rules)运行方式很简单python3 check_shelf.py输出示例{ shelf-version: 1.0, shelf-updated: 2025-01-01, contact: data-ownerexample.com, *: {product-title: allow, product-description: allow}, price-comparison: {product-price: deny, stock-inventory: deny} }5.3 用命令行验证规则是否生效发布完规则文件后你可以用 curl 验证站点是否能正常对外提供规则。curl -i https://example.com/shelf.txt预期响应应该包含200 OKContent-Type 为text/plain下面跟着规则文本。如果返回 404优先检查 Nginx alias 路径和文件权限。这个示例说明了一个重要原则协议本身不强制客户端访问受控接口。它更像一份“声明书”能不能真正落地取决于你的服务端是否有配套的监控和反滥用策略。你可以在网关层根据来源 IP、User-Agent、请求频率判断对方是否遵守了规则并做限流或封禁。6. 场景拆解哪些角色应该关注这份协议6.1 电商平台平台型电商是最直接的受益方。平台掌握商品、价格、库存、评价、店铺经营数据需要约束第三方数据采集。通过声明“价格与库存默认 deny”平台可以先从规则层面阻止比价插件和爬虫的批量行为再结合技术手段识别绕过声明的客户端。实际项目中这类规则应该与数据开放 API 的授权体系结合。Shelf 声明解决“态度问题”API 鉴权解决“能力问题”两者配合才完整。6.2 品牌商家和独立站站长对中小商家来说成本最低的做法是在站点根目录发布一份shelf.txt声明允许搜索收录、禁止价格采集、禁止 AI 训练。这份文件本身没有强制力但它明确表达了你的立场。当争议发生时这份公开声明可以作为判断对方“是否有恶意”的证据之一。商家还可以把shelf.txt的链接写进网站服务条款让规则声明与法律文本形成呼应。6.3 数据服务商和比价引擎这个角色的处境比较微妙。如果比价引擎主动访问并解析shelf.txt那么它至少可以区分哪些站点的价格允许读取哪些不允许。这样能显著降低被投诉和发起争议的风险。反过来如果数据服务商无视规则文件直接抓取那么规则的“协议性”就会被削弱。因此遵守规则不仅是道德问题也是商业可持续问题。公开数据不等于免费商用数据这会是未来行业逐步形成的共识。6.4 AI 搜索助手与训练方生成式 AI 时代网站内容被拿去训练模型的争议越来越多。Shelf Protocol 如果普及可以为内容所有者提供一个正式声明渠道允许 AI 搜索助手引用商品描述生成答案但禁止用商品图片和文案训练同品类竞品模型。对于 AI 公司而言规则文件也能帮助它们降低法律不确定性。抓取前先检查全局shelf.txt比事后收到律师函要划算得多。6.5 跨境与平台型外贸站外贸独立站通常依赖 Google 搜索和社交媒体引流不能简单屏蔽所有爬虫。用 Shelf 规则区分“搜索引擎可以抓”和“比价爬虫不能抓价格”正好符合这类站点的需要。你可以把规则文件做成站点初始化模板的一部分建站时自动生成上线后随商品策略调整。7. 常见问题与排查思路在实现和接入规则文件时最容易遇到的问题集中在路径、格式、解析和默认策略这几类。问题现象可能原因排查方式解决方案访问 /shelf.txt 返回 404规则文件未放到站点根目录或 Nginx 配置 alias 路径不对检查文件实际路径确认 alias 路径是否存在修正文件存放路径或 alias 配置浏览器打开正常爬虫不读取规则文件没有对外公开或响应头设置了受限权限用 curl 查看响应码和响应头确认文件可匿名访问不建议加鉴权客户端解析不到规则字段规则名大小写不一致或行尾有空格打印原始响应文本逐行检查统一规则名小写去除多余空格规则被缓存后长期不更新响应头没有设置合理的 Cache-Control查看返回的缓存响应头设置 max-age 并配合版本号更新未识别的客户端默认放行解析器把未知角色当成通配角色检查解析逻辑对未知 key 的处理建议默认 deny 敏感字段配置告警协议声明与实际访问控制不一致网关没有联动规则仅发布文件查看访问日志中爬虫请求频率在网关层根据规则对高风险来源限流每个问题出现时第一排查方向永远是规则文件本身能不能被公开访问、能不能被正确解析。规则文件不可达后续一切策略都没有基础。8. 安全合规与工程最佳实践8.1 协议不等于安全边界需要反复强调一点Shelf Protocol 是规则声明不是防火墙。不要因为发布了“deny price”就把价格接口裸奔。敏感商业数据的真实保护仍要依赖服务端鉴权、接口限流、风险识别和日志审计。如果你的数据本身就不想被外部读取最稳妥的方式仍然是不要把这些数据暴露在公开接口中或者用接口密钥保护。规则文件只能让守规矩的人更守规矩不能让攻击者失效。8.2 规则文件与授权体系联动在正式项目中建议设计一个规则管理模块让shelf.txt与内部权限系统保持一致。比如某品牌与某个数据服务商签了合作协议允许对方读取价格和库存那么内部接口鉴权时应给该服务商开通对应权限并且在shelf.json中增加一条allow记录。这种联动避免了“协议说一套、后台做一套”的混乱。规则文件可以视为对外承诺系统权限是对内落实两者必须对得上。8.3 最小权限原则编写规则字段时只开放必要的数据。比如商品招商页面需要露出价格就只允许product_price字段在特定页面读取不允许通过 API 批量导出。库存数量通常比价格更敏感建议默认 deny除非确实需要公开。最小权限原则具体落地时可以按数据敏感度分级低敏感商品标题、公开描述、白底图片。中敏感促销信息、评价内容。高敏感实时价格、真实库存、采购成本、用户信息。低敏感字段可以开放给搜索引擎高敏感字段一律默认 deny并且不体现在公开规则中。8.4 日志、监控与灰度发布规则文件是文本改起来容易但影响面大。建议把shelf.txt纳入版本管理每次变更都记录 diff。同时监控规则文件请求量如果请求量突然下降可能是站点可访问性出问题也可能是客户端开始用其他方式绕过规则。灰度发布也很有价值。可以先在一台测试机上发布新规则验证解析和访问正常后再同步到生产环境。如果规则文件与网关限流联动变更前要在预发环境跑一遍回归。8.5 向客户端提供清晰的联系渠道规则文件中明确写一个Contact字段作用是给善意客户端一个通道如果对方对某条规则有疑问或者想申请价格类数据的读取权限可以联系你。这个细节能显著降低误解概率。实际项目中还可以在规则文件下方补充一段人类可读的说明把协议的“机器语义”翻译成大白话。让运营同学也能看懂方便跨部门协作。9. 总结与后续学习方向Shelf Protocol 最有价值的点是把“商业数据该如何被使用”这个模糊问题变成了一份可发布、可解析、可传播的机器可读规则。它借用了 robots.txt 的轻量思路但把控制点从 URL 提升到了数据字段和业务用途这思路更贴近 AI 时代的数据治理需求。如果项目仍在早期建议你以观察者的身份跟踪它的语法设计和生态反馈。机器人可能不会因为你发布了 shelf 规则就停止抓取但越是缺少统一规则数据使用边界就越难界定。哪怕短期没有标准化先在自有的电商站点发布一份类似shelf.txt的声明也能让数据治理从“模糊默认”走向“明确表达”。下一步可以这样做把自己的站点按文中的最小示例设计一份规则文件发布到测试环境用 Python 脚本验证解析是否正常然后把规则文件链接加进网站服务条款最后结合访问日志观察外部客户端的请求变化。过程中如果遇到问题优先检查规则文件可访问性、默认策略和网关联动三个环节。技术协议不会一夜之间改变生态但“让数据用途可见、可表达、可遵守”这件事值得每个做数据开放的人提前准备。