加载失败
讨论源自像 MetaBrainz（维护 MusicBrainz/ListenBrainz 等社区音乐元数据的志愿项目）因为被大规模爬虫反复抓取而改动其开放接口或要求 Authorization 的具体案例。评论同时引用了个人站点 tvnfo（小型爱好项目）关站、SQLite 社区的相似遭遇以及用户在 VPS 上被 openai/claude 多次访问的数百万请求作为证据，表明问题既是技术也是成本分配的问题。参与者围绕三条主线争论：建立 /.well‑known 或 llms.txt 之类的机器可读批量数据发现标准、采用 Cloudflare/Anubis/iocaine 等技术对策与其副作用，以及通过付费、版权重构或集中爬虫来内部化数据采集成本的政策方案。讨论普遍假定爬虫会伪装 User‑Agent、使用 headless Chromium 和住宅代理池来规避检测，因此传统基于 IP/ASN 的拦截越来越难以奏效。
评论中大量实例表明，志愿维护的开放数据服务（如 MetaBrainz/ListenBrainz 等社区音乐元数据项目）被无差别爬虫流量压垮，不得不把原本对外开放的接口改为需要 Authorization 或登录才可用，甚至关站。有人举出个人站点 tvnfo 因持续爬取消耗带宽而改为只对捐助者开放的具体案例，也有用户报告其 VPS 在数月内被 openai/claude 抓取数百万到千万次请求。维护者被迫采用封 IP、强制认证或移除调试/便捷端点，这直接损害了开放数据的可用性并伤及合法第三方使用者。多数评论把这种现象归结为大型训练方把获取数据的成本外部化到志愿项目与小站点上。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
许多评论建议建立机器可读的发现机制，让站点声明可供训练的批量数据位置（例如 gzipped tarball、torrent 或 /.well‑known/llms.txt），而不是让爬虫逐页遍历HTML。讨论提出的具体手段包括 sitemap.xml、在 429/Retry‑After 中加入提示、ETag/增量差分以及为常见 CMS 提供插件以暴露批量导出接口。支持者认为统一规范能节约双方成本、减少对小站点的冲击，但反对者和怀疑论者指出：没有动力的爬虫可能依然无视新标准，而且在规模化抓取时为每个站点做特殊处理在工程上代价高。因此标准能缓解部分问题但不能单凭技术规范解决激励与合规性问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
社区和厂商推出了多种防护：Cloudflare 的 AI Labyrinth 把可疑爬虫引导到“迷宫”或虚假页面，开源工具如 Anubis、iocaine 提供 proof‑of‑work、tarpit 或数据中毒以浪费爬虫资源。这些方法在短期能降低爬取压力，但会牺牲部分真实用户体验、迫使站点依赖第三方服务或增加带宽浪费的成本。同时爬虫也在进化：使用 headless Chromium、真实浏览器实例和住宅代理池来绕过 CAPTCHA、隐形链接和普通的 IP/ASN 封堵，使传统拦截手段失效。评论把问题描述为持续的攻防赛跑，指出没有单一万无一失的技术方案且每种防护都有副作用或误伤风险。
有评论主张把数据采集成本制度化：如用 micropayments/x402 给内容方分成，或采用类似 AWS S3 的 Requester‑Pays 模式把带宽费记到请求方。更宏观的建议包括设立“National Data Set”（国家清洗并授权的数据集）或让公共组织（如 Common Crawl/Internet Archive）承担集中、守规矩的爬取，AI 公司以赞助或许可费换取干净数据。这些方案被看作能把成本内部化并给内容生产者补偿，但评论同时指出政治、既得利益与大公司不配合会严重阻碍改革落地。整体讨论集中在如何建立可执行的付费或监管路径以替代现在的“免费搭车”。
评论普遍强调“AI 爬虫”往往只是以贪婪或笨拙策略递归抓取链接的程序，而非逐页用 AI 理解再决定是否抓取；这导致诸如遍历搜索面板组合的指数级抓取（facet explosion）。运营者常通过伪造 User‑Agent、使用住宅代理池（有时通过付费 SDK，如 Bright Data）和真实浏览器来规避检测，使基于 IP/ASN 或 UA 的封锁效果下降。用户侧也会无意产生类似负载：把链接丢给 Claude 或浏览器本地的 WebAssembly 模型去摘要，会像爬虫一样向站点发起请求。评论因此区分了恶意成本外部化、无知/粗糙实现造成的问题及合理研究用例三类不同动因。
部分人把当前争议比作早年对搜索引擎索引器的恐慌，预测最终会像搜索引擎一样被站点接受并通过流量/SEO 获益。反对者指出这里不同：搜索引擎会把用户流量回导到站点，给站长直接商业激励，而 LLM/训练管线通常不返还流量或引用来源，网站主缺少接纳的直接动机。因此有人建议由单一“守规矩”的共享爬虫（或由公共组织承担并由厂商资助）来减少对小站点的损害，但也有人认为这在现实政治和商业结构下难以实现。讨论聚焦于流量回馈、商业激励和能否形成跨方信任的权衡。
robots.txt: 网站根目录的文本规则文件，用于告诉爬虫哪些路径可抓取或应被拒绝；这是礼节式/协商式机制，无法强制执行或传达批量下载优先级信息。
.well‑known / llms.txt: 社区提议的一类机器可读路径（例如 /.well‑known/llms.txt），用于声明站点为 LLM/爬虫提供的批量数据、导出位置或抓取指引；目前不是普遍标准，但被多次建议作为协调手段。
sitemap.xml: 一种标准 XML 列表，列出网站可被爬取的 URL，搜索引擎用来发现页面；可帮助爬虫避免盲目逐页遍历，但并不携带授权或批量导出说明。
dataset dump / tarball / torrent: 站点为方便归档或供外部使用提供的整站或数据库批量导出（如 gzipped tarball 或 torrent），能显著降低逐页抓取带来的成本。
headless Chromium: 无界面的 Chromium 浏览器实例，用于自动化抓取以渲染 JavaScript 和模拟真实浏览器行为，能绕过许多基于简单请求特征的防护。
residential proxies（住宅代理池）: 通过真实家庭/移动 IP 提供的代理网络，爬虫用以伪装成普通用户的来源流量，常由第三方服务或捆绑 SDK 提供（评论提到 Bright Data）。
tarpit / poisoning / iocaine / AI Labyrinth: tarpit 指向可疑客户端返回大量无用或无限延伸的页面以浪费其资源；poisoning 指返回有害或无意义的数据。iocaine（社区项目）与 Cloudflare 的 AI Labyrinth 是此类思路的实作例子。
Anubis: 社区/开源的反爬工具，宣称使用 proof‑of‑work、挑战及启发式检测来识别并惩罚自动化抓取者，属于主动防御家族。
Requester‑Pays（S3 模型）: AWS S3 的一种计费模式：由下载方承担数据传输费用。评论有人建议将类似机制用于把爬取带宽成本记到请求方。
User‑Agent: HTTP 头字段，用于标识请求方的客户端类型；爬虫常伪造或重复 User‑Agent 来隐藏身份，因此基于该字段做判断有局限性。