AI 搜尋的重複觀測，做法是每一輪固定同一組題目、同一套執行條件與同一份判讀規則，只讓你真正想驗證的那一項改變，並把回答原文與畫面上看得到的來源一起存下來。這套做法適用於題庫固定的 AI 搜尋觀測；題目版本、引擎模式或觀測期間只要動過，那一輪就要另記版本，再說明能不能跟前一輪並排比較。本文給的是可以照著跑的流程：一筆觀測要存哪些欄位、執行前檢查什麼、失敗狀態怎麼分類、前後兩輪怎麼比較，以及哪些結論超出單輪證據。
為什麼值得花這個力氣，用一個情境最快說明。假設你在 9 月 1 日問 ChatGPT「台灣有哪些 GEO 服務」，回答裡出現了你的品牌；9 月 15 日再問一次，品牌不見了。中間可能是你改了網站，可能是引擎換了模型，也可能只是同一句話在不同時間得到不同結果。手上只有兩張截圖時，這三種解釋一樣站得住腳；把上面那些欄位補齊，才有辦法把解釋收斂到一個。
單獨一次回答可以當作一筆事件證據；要討論「變化」，前提是前後條件清楚、失敗狀態分開記、原始資料還調得出來。以下按觀測前、執行中、執行後與重跑報告四段走，並說明哪些情況該重跑、哪些該並列、哪些該先暫停。
每輪觀測要保存題目、執行條件、回答、來源與比較所需的回查資料。
AI 搜尋重複觀測流程：先固定觀測單位
一筆觀測可以想成一張看診紀錄：什麼時候看的、誰看的、當下量到什麼數值、醫師怎麼判讀。少了其中一欄，下次回診就很難說清楚哪裡變好、哪裡變差。AI 搜尋的一筆觀測同樣至少要有五個元素：問題、引擎或搜尋模式、執行條件、回答、畫面上看得到的來源。
任何一筆事件都可以先用這組欄位描述：
observation_id 這筆觀測的編號
prompt_id / prompt_version 題目編號與題庫版本
engine / surface_or_mode 引擎，以及它的哪一種模式
language / region / device 語言、地區、裝置
observed_at 實際執行時間（含時區）
answer_status 這次有沒有拿到可讀的回答
raw_answer_ref 回答原文存在哪裡
visible_source_refs 畫面上出現的來源
event_labels 提及、引用、推薦等判讀結果
content_version 當時網站內容的版本
review_status 人工覆核狀態這組欄位只是保存結構的示意，裡面沒有實測資料。其中 answer_status（回答狀態）要能分出成功、空回答、執行錯誤、被阻擋與未取得五種。「未取得」的意思是這一次沒有拿到資料，和「品牌沒被提到」是兩件事——就像問卷沒送到受訪者手上，不能記成他投了反對票。
觀測前：題庫與條件檢查
第一步，凍結題庫版本
考卷印好就封存，考完才討論分數；中途改了題目，分數就失去比較基礎。題庫也一樣：執行前先確認題目清單、題型、判讀要點與題庫版本，題目裡若帶了市場、語言、受眾或產品條件，也要留成欄位。
舉例來說，「GEO 工具推薦」和「台灣有哪些 GEO 工具」看起來很近，實際上是兩個題目：前者容易得到國際品牌清單，後者才會逼出在地供應商。這兩題若在某一輪被誰順手合併成一題，下一輪的數字就對不起來，而且通常要到報告做完才發現。題目怎麼選可以參考 AI 監測 prompt 選擇 FAQ；這一段的重點只有一個，執行當中不要改題。
第二步，確認平台與模式
「我們有在 Google 上觀測」這句話的資訊量，大概等於「我們去那家餐廳吃飯」——午餐菜單和晚餐菜單不同，端上桌的東西當然也不同。Google AI Overviews 與 AI Mode 可能使用不同模型與技術，回答和連結集合也可能不同；ChatGPT Search 的 citation 呈現又有自己的介面。
報告要寫出當次實際使用的引擎與模式，例如「Google AI Overviews、桌機、繁體中文、台灣」。標籤寫成「Google AI」或「ChatGPT」這種寬度，之後看到差異也無從歸因。
第三步，記錄語言、地區與裝置
同一句問題用繁中問、用英文問，在台灣問、在新加坡問，用手機問、用桌機問，出現的來源可能完全不同。裝置未必每一次都是主要變因，但只要頁面或功能會依環境改變，之後就會需要知道當時的條件。
登入狀態、個人化設定與搜尋歷史如果拿得到，也要照權限政策保存，或至少標成未讀取。一輪用登入帳號跑、下一輪改用無痕視窗跑，兩邊的差異可能跟你改的內容完全無關。
第四步，建立觀測前清單
執行前可以用以下清單：
| 檢查項目 | 確認內容 | 狀態 |
|---|---|---|
| 題庫 | prompt_id、版本、題數、意圖 | |
| 平台 | engine、surface、搜尋或回答模式 | |
| 條件 | 語言、地區、裝置、登入狀態 | |
| 時間 | 開始、結束、時區 | |
| 保存 | 原始回答、截圖或檔案位置 | |
| 判讀 | mention、citation、recommendation、coverage 規則 |
空白代表還沒確認、需要補查。這張表是執行前的檢查表，不是結果評分表；六列都填完再開始跑，事後省下的爭論通常比事前花的十分鐘多。
執行中：保存回答與失敗狀態
先保存原始回答，再做摘要
會議紀錄方便傳閱，錄音檔才是爭議時的依據。回答也是這個關係：取得後先存下可回看的原文或受控檔案位置，再去填品牌提及、引用、推薦和涵蓋這些欄位。
若平台提供 Sources 或 citation 入口，就把畫面上看得到的來源名稱與 URL 記下來。只看得到網域時（例如卡片只顯示 example.com），先存網域就好，不要自己補成 example.com/pricing——補進去的那一段，下一輪沒有人分得出是觀測到的還是推測的。
失敗狀態不要轉成結果 0
電訪打不通，不能記成「受訪者不推薦」。AI 觀測的失敗狀態也一樣，可以先分成五類：
| 狀態 | 意義 | 是否進入有效回答分母 |
|---|---|---|
| valid | 取得可讀回答，可按規則判讀 | 是 |
| empty | 回傳空內容或沒有可讀回答 | 否 |
| error | 執行或服務錯誤 | 否 |
| blocked | 權限、政策或環境阻擋 | 否 |
| partial | 只取得截斷內容，需人工查看 | 依規則保留或暫停 |
舉例來說，某一輪 20 題裡有 2 題因服務錯誤沒跑完，品牌提及率的分母要寫 18 還是 20，必須在指標規格裡先講明。把那 2 筆錯誤當成 0 分、再用 20 當分母，等於在數字裡摻了兩次沒有發生的觀測。已發布的 AI Visibility 量測方法提供事件層的分母拆法。
保留執行時間和來源讀回時間
回答產生的時間，和你打開來源頁去讀的時間，通常不是同一刻。今天存下回答、明天才點開來源，中間那一頁可能已經改版，你讀到的內容未必是當時回答看見的內容。
兩個時間都留下來，才分得開「回答當下呈現的來源」與「現在讀到的頁面」。這一條在做內容改版驗證時特別重要，因為改版本身就會讓來源頁與前一輪不同。
每一輪使用相同的命名規則
檔案或資料列可以用 set-v3__prompt-014__engine-x__20260921T1030+0800 這種識別，效果像出貨單流水號：看一眼就知道是哪一批題庫、哪一題、哪個引擎、什麼時間跑的。它不是安全控制，也不是平台標準，作用只是讓題目、回答與來源串得起來。
題目版本或引擎模式換了，識別碼裡就要換版本，報告再說明新舊兩輪能不能直接比。
執行後：來源核對與事件判讀
先核對 citation 的來源關係
論文後面列了一本書，不保證書裡真的寫了正文那句話。AI 回答附的 URL 也是這樣：先記錄它在回答中怎麼出現（是整段的依據，還是只掛在某一句旁邊），再打開原始頁，核對頁面能不能支撐相鄰的句子。
OpenAI Help Center 說明 ChatGPT Search 的回答可能包含 citations，同時提醒結果或 citations 可能不完整、過時或錯誤，所以來源核對要保留原始頁與日期。Google Search Central 的 AI features 文件則說明 AI Overviews 與 AI Mode 會顯示支援回答的連結，頁面仍須符合一般 Search 的索引與 snippet 技術要求。兩份文件都支持「把 supporting link 保留下來」這個做法；至於各家 AI 引擎怎麼判分，官方文件沒有給出共同標準。
再做 mention、recommendation 和 coverage 判讀
這三種判讀的差別，在於回答替你說了多少話：
- mention（提及）：回答裡出現品牌名字就先記一筆，相當於有人在對話中提到你的公司。
- recommendation（推薦）：問題本身有選擇意圖，而回答把品牌和條件、用途或理由連起來，例如「如果你要同時看多個引擎，可以考慮 X」。相當於有人真的說「你這種情況去找他們」。
- coverage（要點涵蓋）：回答需要處理好幾個要點時，逐點標記完整、部分、缺少或尚未判定。
一筆回答同時附了來源，也還是停在提及。來源說明的是「這句話從哪裡來」，推薦說明的是「回答替誰背書」，兩件事各自需要證據。
保留人工覆核理由
邊界案例留一句理由就夠，例如「品牌只在問題重述中出現」、「來源卡顯示網域，URL 尚未讀回」、「題目沒有選擇意圖」、「回答截斷，後文無法判斷」。
這一句話的價值會在三個月後出現：那時要修字典或改判讀規則，可以直接回到原始事件，不必重看幾百張畫面猜當初為什麼那樣標。
重跑與報告：如何比較前後資料
同一內容測試先固定五件事
想知道頁面改版後回答有沒有變，就把 prompt 版本、題庫 set、引擎模式、語言地區與判讀規則五件事固定住，只讓內容版本這一項刻意改變。這是實驗的基本盤：一次只動一個變因。
現實中還是會有你控制不了的變動——引擎更新、其他網站改版、當週剛好有相關新聞。把觀測日期與已知的平台變化列進報告，讀的人才知道結論的邊界在哪裡。Prompt 的版本管理細節可以先看 AI 監測 prompt 選擇 FAQ。
比較回答差異，不只比較比例
前後報告可以並列：
| 證據層 | 前一輪 | 後一輪 | 需要核對的問題 |
|---|---|---|---|
| 回答狀態 | 是否同樣有效 | ||
| 品牌提及 | 出現句子是否改變 | ||
| 自有來源 | URL 是否同一頁 | ||
| 推薦條件 | 理由是否存在 | ||
| 回答要點 | 哪個要點由缺少變部分或完整 | ||
| 內容版本 | 哪些頁面在期間內修改 |
假設前一輪有效回答 18 筆、後一輪 16 筆，直接比較兩個提及率，等於拿 30 人到齊那天的班平均去比 28 人的班平均。比例適合放在摘要，解釋變化要回到原始事件；報告至少要同時呈現兩輪的有效數與失敗狀態。
設定觀測窗口
一次重跑只能回答兩個時間點之間的差異，就像量體重：每天量會看到水分波動，每月量才看得出趨勢，兩種尺度回答的是不同問題。
要看方向，就先決定重跑頻率與窗口，例如「內容改版後第 7 天與第 28 天各跑一輪」，或連續四週使用同一份題庫。頻率沒有通用答案，要依內容更新速度、引擎可取得性與資料保存成本評估。
把結果寫成範圍清楚的句子
「在 2026-09-21 的固定題庫、指定引擎與可讀回答中，觀測到某來源出現」是可以被核對的句子。「AI 已經更喜歡這個品牌」則超出一輪觀測能承擔的範圍。來源、回答或條件有缺，就寫成尚未判定，把空白留成空白。
限制：紀錄能追溯，平台輸出仍會變
Google 官方提醒 AI Overviews 與 AI Mode 的回答和連結集合可能變動，頁面就算符合技術與政策要求，仍可能遇到抓取、索引或提供上的差異。重複觀測能提高資料的可追溯性，至於平台輸出本身的變動，紀錄消不掉。OpenAI 也提醒 Search citations 可能不完整、過時或錯誤，來源頁仍要另外核對。
Google 現行指南提供 Search Console 的 Generative AI performance report，用來了解內容如何透過 Google 生成式 AI 功能被發現。這是 Google 搜尋端的報告入口，和逐題保存的跨引擎回答事件屬於不同資料層：前者看的是你的網站被誰帶進來，後者看的是某一題在某個引擎當下答了什麼。
Otlex 是 EthorX（伊索斯科技有限公司）開發的 AI 搜尋優化平台，觀測 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 等七個 AI 引擎回答中的提及、引用與推薦。這段描述說明的是觀測範圍；各引擎提供的介面不盡相同，重跑之後會出現什麼結果，也要回到當次資料才能說。
相關概念與產品連結
如果你要先定義要觀測哪些指標，參考已發布的 AI 可見度量測方法；若你主要處理來源 URL，參考已發布的 Citation Tracking。想把觀測結果帶回內容測試，可以先讀 ChatGPT 品牌監測。
若你需要把題庫、回答、來源與內容缺口放在同一個平台範圍內，可以從 Otlex 了解產品能力，或從 EthorX GEO 服務了解服務範圍，再依資料治理與專案條件評估。
常見問題
每次都問同一句 prompt，就算重複觀測嗎？
還不夠。同一句話在無痕視窗與登入帳號、在台灣與在美國、在桌機與在手機，都可能得到不同來源。至少要同時保存引擎或模式、語言、地區、裝置、時間、回答原文、來源與判讀規則，前後差異才不會被執行環境吃掉。
觀測失敗要不要刪掉？
留著。把失敗狀態與原因記下來，再按指標規則決定它進不進有效回答的分母。刪掉失敗列的報表看起來很乾淨，代價是下個月有效數從 20 掉到 16 時，沒有人說得出原因。
一次回答中途截斷，能不能只看前半段？
可以先保存已取得的部分，但要標成 partial 或待核對，並寫清楚判讀範圍。舉例來說，題目問「有哪三種做法」，回答講到第二種就斷了，此時若當成完整回答計算，第三個要點會被算成缺少，而它其實只是沒載完。
來源 URL 打不開，citation 要填沒有嗎？
分成兩欄來記。「回答中是否呈現來源」與「目前是否讀得回這個 URL」是兩個問題：來源卡當時確實出現過、今天回頁面拿到 404，那就是前者成立、後者失敗待核對。壓成同一個 no，之後會分不出是回答沒給來源，還是那一頁後來被移掉。
多久重跑一次才有意義？
沒有通用頻率。內容一季才改一次，卻每天跑一輪，多半只是在記錄引擎自己的波動；反過來一年只跑一次，改版效果早就跟其他變因混在一起。先依內容改版節奏、引擎可取得性、題庫規模與保存成本決定，並在計畫裡固定觀測窗口，重點是每一輪的條件與資料狀態都能回看。
查證邊界
本文外部文件查閱日期為 2026-09-21，使用 Google Search Central 的 AI features、生成式 AI 搜尋指南，以及 OpenAI ChatGPT Search 說明。流程、欄位、失敗狀態和重跑規則是本文方法建議，不是平台公布的共同排名或品質標準。文中的題數、有效數與日期都是說明用的假設情境，不是實測結果。實際工作仍需依可讀的原始回答和資料保存政策執行，證據不足時保留資料範圍與判讀限制。