晚上十一点半，我打开 paulkuo.tw 的首页，看了一眼流量分析区块。

访客：0。

不对。今天有人看我的文章，翻译工具也有人在用。昨天的数据已有数百人来访，不可能今天直接归零。我打开 Cloudflare Dashboard 看——Page views 193，Visits 130。

零和 130 不是误差，是两个完全不同的世界。究竟是「没人来」，还是「一百多人来过了」。哪一个是对的，或者都错？

Cloudflare 的两个世界

如果你的网站放在 Cloudflare 上（全球超过 4,100 万个网站都是），你可能不知道 Cloudflare 其实有两套完全不同的分析系统。

第一套：Zone Analytics（HTTP Traffic）。 这是 CDN 层的数据。每一笔经过 Cloudflare 网络的 HTTP request 都会被记录。它能告诉你总请求数、带宽、国家分布、unique visitors（用 IP 去重）。精确，什么都算，包括 Google 的爬虫、ChatGPT 的 crawler、各种监控 bot。

第二套：Web Analytics（RUM beacon）。 这是浏览器层的数据。Cloudflare 在你的网页里注入一段 JS beacon，只有真人用浏览器载入页面时才会触发。Bot 不会跑 JavaScript，所以它天然过滤掉了非真人流量。

我在设计流量分析架构时，经过一次迭代，后来选了 Web Analytics 的 GraphQL API 作为主要数据源。理由联起来很合理，它只算真人，更精准。一开始使用 Zone Analytics 这条路，但含有 bot，数字偏高。才刚设定好网站，一天就上千 Visit。

逻辑没问题。但我犯了一个错误：我验证了「这支 API 能给我什么资料字段」，没有验证 Web Analytics（RUM beacon）「给我的数字是不是准的」。

Adaptive sampling：让 130 变成 0

追查之后，我找到了根因。Cloudflare 的 Web Analytics GraphQL API 用的是一种叫做 Adaptive Bit Rate（ABR）的取样技术。

原理不复杂：Cloudflare 每秒处理超过七亿笔事件。如果每一笔查询都要扫过全部原始资料，系统要支付更多成本。所以它把资料存成多种解析度——100%、10%、1%。查询的时候，系统根据数据量和复杂度，自动选一个解析度回传结果。

对高流量网站，这完全没问题。你的日访客如果有十万，10% 取样也是一万笔，统计上准确度很高。

但对低流量网站呢？我的 paulkuo.tw 一天大约 130 个真人访客。API 取样完之后，回传的 visits 都是 100 的整数倍——0、100、200。130 被四舍五入成了 0。

我去翻了过去 30 天的 API 数据，发现有几天 visits = 0，而且所有数值都是 100 的倍数。这不是「今天坏了」，这是从上线第一天就是这样的逻辑。只是我今天第一次拿 API 数据跟 Dashboard 比对。

后来查了 Cloudflare 的文件，他们承认，现在还没办法让使用者验证查询结果到底准不准。也就是说，你拿到一个数字，但没有人能告诉你这个数字的误差范围是多少。

还有一个更大的数字

当我理清了 Web Analytics 的取样问题，转头去看 Zone Analytics——Unique Visitors 的数字是 1,100。

Web Analytics Dashboard 说 130。Zone Analytics 说 1,100。API 说 0。

三个数字，同一天，同一个网站。

1,100 和 130 的差距——那接近一千个「多出来的访客」就是 bot。我的网站从一开始的设计就是 AI 友善，有 llms.txt、JSON-LD、MCP 支持，都是为 AI 系统设计的。所以 GPTBot、ClaudeBot、Bingbot 这些爬虫很勤劳地来抓内容。Zone Analytics 忠实记录了每一个 IP，不管它是人还是机器。

根据 Imperva 的 2025 年报告，自动化流量在 2024 年首次超过了人类活动，占全球网络流量的 51%。其中恶意 bot 占 37%。Cloudflare 的 2025 年度回顾也显示，AI bot 对 HTML 页面的请求占了 4.2%，Googlebot 一家就占了 4.5%。

所以，我的网站 88% 的 unique IP 是 bot、12% 是真人。听起来很夸张，但在统计上完全合理。今年一月起，很明显有感觉到 “Make something Agent Want”，已经是技术圈内的共识。因此，这就让我重新检视网站只看真人 Visit 的执念。

我走错的三条路

在找到目前的方案前，我犯了三个错。

第一个错：规划时没做技术侦察。 选 Web Analytics RUM 做主要数据源之前，我没有查 adaptive sampling 的行为限制，没有拿 API 回传值跟 Dashboard 交叉比对。如果当时花五分钟做这件事，整个问题会在规划阶段被发现。

第二个错：发现问题后仓促修复。 我直觉地判断「Zone-level API 的取样粒度应该比较好」，仍有「人类中心」的执念，写了修正版推到 GitHub。推完之后才在 Cloudflare 社群发现有人回报 zone-level API 也有同样的 visits=0 问题。于是 revert。一来一回浪费了时间，还污染了 git history。

第三个错：把「不含 bot」跟「精确」画等号。 Web Analytics 确实只算真人，但「不含 bot」不代表「数字正确」。取样精度和 bot 过滤是两件完全独立的事。我把它们混在一起看了。

我与 AI Agent 的工程原则是先侦察再动手，但 AI 会疏漏（奇怪，已经写在 skill 了呢），我也会。但人在发现问题的时候，特别容易急着去修，跳过该做的功课。

看见完整的观众轮廓

一开始我把 bot 流量当作噪音，想要排除它。但 paulkuo.tw 有 AI-Ready 的架构设计——llms.txt 让 AI 系统读懂网站结构、JSON-LD 提供结构化知识、MCP 协议让 AI agent 可以直接操作。所以，让 AI bot 来读内容，不是噪音，也是影响力的一部分。

所以正确的问题变成不是「怎么排除 bot」，而是「怎么看见完整的『阅读观众』」。

我需要两个独立的指标：

  • 真人访客：多少人类读者看了我的文章和工具——这是旧世界衡量社群影响力的核心指标
  • AI/Bot 访客：多少 AI 系统在读取我的内容——这是 AI-Ready 策略的成效指标

最终的架构也不复杂。真人访客用自建的 visit beacon——页面载入时发一个 POST 到我的 Cloudflare Worker，Worker 用 IP + User-Agent 的匿名 hash 做每日去重。全站访客继续用 Zone Analytics 的精确 IP 去重。两个相减就是 AI/Bot 的量。 paulkuo.tw 流量分析架构图：自建 beacon（真人）+ Zone Analytics（全量）→ 差值计算 AI/Bot

三个数字都是自己算出来的，不靠 Cloudflare 的估算。做法跟 Google Analytics、Plausible、Umami 这类网站流量分析工具的原理一样。在网页里埋一段追踪码，自己数人头，每一个都算到。只是我不需要额外装第三方工具，直接跑在网站既有的服务器上就行。

你的数据可能会误导你

2025 年，自动化流量首次超过人类活动，占全球网络流量的 51%。AI crawler 的爬取量在同一年增长了超过 15 倍。你的网站不只被人类读，也被机器读。

如果你的网站用的是 Cloudflare Web Analytics 的 free plan，而且日访客在几百以下，仪表板上的 visits 数字，很可能跟我一样，是取样后的估算值，不是精确值。

这不代表 Cloudflare 不好用。它的 CDN、DNS、安全防护在业界顶尖。Web Analytics 的 Dashboard UI 数字是准的。但如果你要用 API 把数据拉到自己的仪表板，在低流量场景下，你需要自己验证一次。拿 API 回传的数字跟 Dashboard 比对，五分钟就能知道答案。

当数据落差过大时，网站经营者可能需要回到更直接的方法，自己建立精确的访问计数机制。这不是因为 Cloudflare 不值得信任，而是因为取样在流量规模还小的时候，先天就容易失准。随着受众规模扩大，取样的精度自然会逐步提升；但也正是在流量仍在成长的阶段，精确数字最不可或缺，因为那正是判断方向与调整策略的关键时刻。

网站经营不能只靠感觉，数据就像健康检查报告。若连最基本的触及人数都无法准确掌握，就如同对自己的体重、体脂与生理指标一无所知，所谓的改善与成长，也就很难建立在清楚而有根据的判断之上。