先請瀏覽器 Agent 交一張來源表。每列對應一個可查證的主張，寫明原始頁面、證據所在的位置和判定。審閱者才能從報告中的一句話回到可核對的段落。這個公開範例裡，兩份權威資料對 HTTP 418 採用不同說法。查看文件日期和用途後，就能說明差異。
先把問題限定在可查證的範圍
我們只查兩個問題：現行狀態碼登錄表怎麼列出 418，以及茶壺用語出自何處。2026 年 11 月 6 日，我們在 Tabbit 開啟登錄表和兩份 RFC，由作者逐列審閱判定。這是有人引導的瀏覽器查證。交給 Agent 自行執行時，也能用相同範圍，要求它交回尚無結論的列，再開始寫報告。
把日期、待答問題和第一手來源的條件寫在第一行。「查現行登錄名稱和歷史用語」比「解釋 HTTP 418」容易複核。後者可能把歷史文件、現行狀態和伺服器行為混在一起。先用深度研究案例規劃問題，再參考首次任務檢查表限定網站與動作。先開少量第一手頁面，碰到缺口再擴大。
從主張回到原文
| 待查證主張 | 第一手來源和位置 | 判定 |
|---|---|---|
| C1 現行登錄表把 418 標為未使用。 | IANA 的 418 列，連到 RFC 9110 §15.5.19。 | 支持，限於 IANA 登錄。 |
| C2 早期 RFC 2324 有茶壺用語。 | 1998 年 4 月的 RFC 2324 §2.3.2。 | 支持，屬於資訊類 RFC 的歷史用語。 |
| C3 現行規範把 418 命名為「我是茶壺」。 | 2022 年 6 月的 RFC 9110 §15.5.19。 | 反駁。標題是未使用，內文解釋保留理由。 |
| C4 提供的 RFC 可證明另一項伺服器行為。 | 特意加入無效的 RFC Editor 網址作對照。 | 未查證。Tabbit 讀到 HTTP 404。 |
來源表 CSV包含四列的原始網址、實際到達網址及結果。IANA 登錄表連到 RFC 9110，這兩項證據有直接的引用關係。RFC 2324 回答歷史用語的問題。某個伺服器是否回傳 418，需要查該實作的證據。
複核時從報告中的一句話出發，開啟引用網址，記下重新導向後的位置，再找到指定小節。擷取短句或轉述時保留原文條件。若原文只涵蓋部分實作，報告便應保留這個範圍。若一句話同時講現行狀態與歷史來源，就拆成兩列。用瀏覽器 CLI 教學擷取文字，再參考 MCP 與 CLI 的比較了解如何把觀察結果交給 Agent。
留下查證失敗和未解決的差異
| 判定 | 處理方式 |
|---|---|
| 支持 | 在原文範圍內引用。 |
| 反駁 | 先修正主張，再寫入報告。 |
| 部分支持 | 拆分主張，只保留有證據的部分。 |
| 未查證 | 保留失敗紀錄，等待補充資料。 |
可用四種判定：支持、反駁、部分支持、未查證。404 只說明這次請求的結果。碰到登入頁，可記錄畫面上的標題，並標註內文未讀。若找不到另一個適合的來源，就暫時從結論移出這項主張。操作已登入頁面前，先查瀏覽器權限涵蓋的動作。
如果兩份資料似乎互相矛盾，先查定義、日期和範圍。這個例子裡，登錄狀態和歷史用語是在回答不同的問題。若仍有差異，兩個值都保留並寫清還缺什麼證據。會變動的主張記下查核日，重用時回到第一手資料。
給 Agent 一個可驗收的要求：「先交來源表。每項主張要有網址、章節或列號、對應原文、查核日期和判定。失敗也留在表內。只用已支持的主張寫結論，並標註推論。」抽查幾項成功的列，再逐一複核未解決項目。可參考瀏覽器自動化及網頁研究工作流程，再用 Tabbit重做此範例。
原始資料：IANA HTTP 狀態碼登錄表、RFC 9110 §15.5.19、RFC 2324 §2.3.2。
常見問題
研究來源表要包含哪些欄位？
替每項主張編號，保留原始網址、實際到達網址、原文位置、簡短引文或轉述、查核日期和判定理由。
網址打得開，引用就正確嗎？
網頁可能談的是同一主題，但適用的日期、對象或結論不同。打開後仍要查核它能否支持報告裡的句子。
遇到無法開啟的來源怎麼辦？
保留嘗試的網址、已知的到達網址、查核日期、實際回應和對應主張。有適當的補充來源前，標記為未查證。
來源說法不一致怎麼辦？
比對日期、範圍、權威性和定義，兩個來源都保留，再寫明差異是否能解釋。
每個來源都需要逐字引用嗎？
簡短引文或準確轉述，加上可以回到原文的章節位置，就能協助複核。把來源內容和你的判定分開。