一個信任區間先被畫了出來：Cloudflare 的爬蟲評等，是一頁還在成形的介面

2026 年 10 月 19 日，APPI News 刊出張饒輝的分析長文，整理 Cloudflare 同月公布的 Verified Bot 信任評估。這項消息距今已有一段時日，值得回頭看的原因在於：它示範了一種治理介面的設計思路，把「這個爬蟲是誰」和「它守不守規矩」拆成兩個分開呈現的欄位，而這個拆分本身就是設計決定。

先從檔案層級看起。robots.txt 是網站發布給爬蟲的路徑偏好檔，用 User-Agent 區分對象，以 Allow、Disallow 表達哪些路徑可以或不希望被抓取。這份純文字檔案可能是網路上最老牌的「人機協議介面」：沒有強制力，只有宣告。Cloudflare 的信任評估，第一組觀察訊號就落在這裡，看爬蟲的實際流量是否長期符合網站發布的偏好，並著重反覆忽略規則的模式，而非把一次性違規直接當成定論。

第二組訊號落在 HTTP 429。這個狀態碼的意思是「請求太多，請降低頻率」。把它放進信任評估，等於把網站的回應也設計成觀察材料：爬蟲收到 429 之後有沒有調整流量，收了限流還照抓，這些互動紀錄累積起來，就成了評等的原料。Cloudflare 用一句話概括這個方向，「Verify, but continuously re-verify.」，身分需要驗證，行為也要持續重新確認。

身分欄與行為欄，被刻意分開排版

Cloudflare 既有的 Verified Bot 概念其實已經包含兩類條件：爬蟲要以可驗證方式表明身分（加密簽章、發布的 IP 清單搭配穩定 User-Agent、反向 DNS 等），同時要遵守 robots.txt、維持合理請求頻率。10 月公布的信任評估，是把第二類行為往時間軸延伸。

這個拆分值得放在介面設計的脈絡裡看。身分驗證回答的是靜態問題，回答一次就夠；行為觀察回答的是動態問題，答案會隨時間變動。如果把兩者塞進同一個勾選框，營運者看到的「已驗證」就會掩蓋掉「它昨天被限流了三次」這類資訊。Cloudflare 在公告中把「風險」定義為特定請求或某一時點行為可能造成的傷害，把「信任」定義為長時間反覆呈現的一致行為。這組定義的排版責任很清楚：信任是濃縮過去的摘要，不是對未來每次請求的承諾。

同樣把數字當成信任介面來排版的例子，我們先前在GPT-6 Astra 基準分數的編輯軌跡裡看過：一個可以被修改的幻覺率數字，如何在版面與時間差之間動搖信任。差別在於，Cloudflare 這次設計的是「區間」而非單一數字。公告表示評估會呈現一個可解釋的信任區間，說明行為一致程度與參考的觀察訊號，避免把結果視為永久定罪。用區間而非分數，是承認摘要必然有誤差的排版選擇。

這頁介面的適用界線

來源文章反覆提醒的界線，恰好也是設計觀察的重點。這項評等現階段還不等於所有網站都能直接使用的管理功能，Cloudflare 表示未來計畫在 Radar 公開評等，但完整計分公式與所有輸入資料並未公布。此外，這是產品方對自身方法的說明，並非第三方稽核結果。

對網站營運者來說，可以自己排好的欄位其實一直都在：哪些內容允許抓取、收到超量請求時回什麼狀態碼、決策由哪個系統執行、請求紀錄看得到哪些欄位。信任評等補上的是「對方長期表現」這一格，但這一格若看不到觀察涵蓋哪些流量、樣本是否足夠、回饋在什麼時間範圍內生效，單獨拿一個評等做放行決策，容易把「曾有良好紀錄」誤讀為「此刻一定安全」。

這種「公告如何被排成可依序執行的步驟」的問題，和WordPress 安全公告的處置介面是同一門功課：版本清單、評分數字、執行順序，每一格都對應一個讀者的動作。爬蟲治理也一樣，robots.txt 是宣告、429 是回饋、評等是摘要，三者各自有各自的讀法與時效。

回到一開始的問題：通過身分驗證的 AI 爬蟲，能放心放行嗎？Cloudflare 的答案藏在它的設計裡，它不給一個勾選框，而是給一個會隨行為移動的區間。這個選擇比任何單一評分都誠實：在一個身分可以驗證、行為卻持續變動的環境裡，最合適的介面形式，本來就該留下一點會更新的空間。