AI 搜尋 Prompt 版本與 Baseline 怎麼管？版本比較

管 AI 搜尋 prompt 版本的做法，是把一筆觀測拆成四種版本——題目文字、題庫收錄、執行條件、判讀規則——各自獨立編號，再把內容版本當成第五個關係欄位接上去。這適用於要做內容改版前後比較的觀測；四種版本裡只要有一種動過，那一輪就從「可比較」降級成「只能並列」。本文提供的是可以直接建欄位的東西：四種版本的分工表、baseline 的十三個欄位與三種完整度狀態、五類變更如何破壞可比性、四步重測流程、前後對照表，以及比較／並列／暫停三種報告處置。

程式碼會用 git 記版本，沒有人會直接覆蓋 main 再說「上次好像不是這樣」。題庫卻常常被這樣對待：有人順手把題目改得更精準，下一輪回答變了，然後整個團隊花一週討論內容改版的效果——而改變的其實是那句問題。

AI 搜尋 Prompt 版本、baseline 與重測時間點分層保存的概念圖 題庫版本與 baseline 需固定後才可比較後續重測。

AI 搜尋 Prompt 版本怎麼管：先拆四種版本

一筆 AI 搜尋觀測不只有一個 prompt 文字。至少分出四種版本，「前後比較」才不會把不同物件混在一起：

版本	它控制什麼	典型變更	影響
Prompt version	問題文字與輸出要求	改寫語氣、增加條件	可能直接改變回答
Set version	題庫收錄哪些題目	新增、退休、分層調整	改變分母與覆蓋範圍
Runtime version	引擎、模式、語言、地區與日期	換 AI Mode、改地區	改變取得條件
Rubric version	如何標記提及、引用、推薦或涵蓋	改判定門檻	改變摘要結果

內容版本是第五個關係欄位：頁面何時改了哪一段、哪個網址或什麼結構。它不屬於 prompt 版本，但前後測試要把兩者接到同一個 change record 上。這些欄位是可追溯的工作方法，不是平台統一格式。

Baseline：什麼資料才適合當基線

基線先定義比較問題

Baseline 不會因為「這是第一次看到的回答」就自動成立。先寫清楚要比較什麼，例如：「同一組決策題，在內容頁修訂前後，品牌提及、引用與回答涵蓋是否有變化？」這個問題決定了分母、判讀欄位和要保存的來源。

基線資料最少要有這些欄

baseline_id           基線編號
prompt_set_version    題庫版本
prompt_id             題目編號
prompt_version        題目版本
engine                引擎
surface_or_mode       引擎的哪一種模式
language_region       語言與地區
observed_at           觀測時間
answer_status         有效／空／錯誤／被阻擋
raw_answer_ref        回答原文位置
event_labels          提及、引用、推薦等判讀
content_version       當時的頁面版本
rubric_version        判讀規則版本

示例欄位只展示資料結構，不是實測結果。baseline_id 要連得回原始回答，content_version 指向修改前的頁面版本或摘要。

只留下「有提及」這個摘要、沒有原始回答的話，下一輪看到差異時，你分不出是回答變了還是上下文變了——而那正是你當初做這件事的目的。

基線要有完整性門檻

用三種狀態保存基線：

ready：題目、執行條件、回答和判讀規則完整，可進入前後比較。
partial：部分欄位可取得，可作背景參考，不宜當嚴格差異的唯一依據。
invalid：題目或執行條件缺失，無法確認和下一輪是否相同，暫停作比較基線。

這三個狀態描述的是資料可用性。基線 invalid 的意思是比較前要先修資料，和內容結果為零沒有關係。

變更分類：哪些差異會破壞可比性

題目變更

加上「台灣」、「B2B」、「預算」這類條件，就改變了問題的決策範圍，要建新的 prompt version。題目只調了一個形容詞時也要判斷：它有沒有改變受眾、任務或判讀要點？字數相近不是同一題的理由。

題庫變更

題庫加五題、退休三題或重新分配題型，set-level 分母就變了。可以比較交集題目；兩個 set 的總比例放進同一條趨勢線，前提是報告說明分母與交集規則。

執行條件變更

Google AI Overviews 和 AI Mode 可能使用不同模型與技術，回答及連結集合也可能不同；ChatGPT Search 的來源呈現又和其他引擎不一樣。換引擎、模式、語言、地區、登入狀態或觀測時間，都保存成 runtime 變更。目的若是看內容改版影響，這些條件要儘量釘死。

判讀規則變更

這一類最隱形。第一輪把「被列在清單」算推薦，第二輪改成需要條件與理由——回答一個字都沒變，推薦率也會掉。那是 rubric 差異，和回答品質無關。

新規則可以回頭重標舊回答，報告要保留原 rubric 版本，並說明數字有沒有經過回溯重判。

頁面與內容變更

內容頁新增一段產品描述、換 URL、改 canonical 或調整內鏈，都記在內容版本。多頁同時更新時，用一個 change set 串起來，後續重測才回答得了「哪一批改動對應哪一批觀測」。

重測方法：如何保留前後脈絡

第一步，凍結 baseline snapshot

內容改版前，把 prompt set、prompt 文字、runtime、回答原文、可見來源、判讀規則和內容版本存成一個 snapshot。

檔名可以含日期與版本，別讓日期代替版本——set-category-v3__content-20260921-r1 一眼看得出是哪一版題庫配哪一版內容，20260921 只告訴你那天有人跑過一次。

第二步，建立變更紀錄

變更紀錄要說清楚：改了哪個頁面、哪一段、為什麼改、何時完成、哪個內容版本可讀回。修改若源自推論或優先級建議，標成假設——寫成已證明的原因，之後整輪判讀都會沿著它偏。

第三步，用同一題目重跑

重測先用原有的 prompt version、set version 和 runtime。題目本身已經不符現況時，另開新版本並與原版分開呈現。

回答取得後用相同 rubric 標記，或者對舊回答也套用新 rubric 形成平行結果。兩種做法都可以，混用而不說明則不行。

第四步，保存差異而不只保存百分比

前後報告至少保留：

欄位	Baseline	Follow-up	比較說明
題庫版本			是否同一 set
可比較回答數			是否同一分母
品牌提及			只看有效回答
自有來源			來源 URL 另列
推薦判讀			rubric 需相同
覆蓋要點			要點規格需相同
內容版本			改動頁面與摘要

數字旁邊要能點回原始事件。回答文字不同時，至少保存新增、消失、來源替換和理由變化——只寫「上升」或「下降」，下一個人得從頭再跑一次才知道發生了什麼。

判讀報告：比較、並列與暫停

可以比較的情況

同一 prompt version、set version、runtime、rubric 和相同回答判定，只有內容版本或觀測日期不同時，通常可以前後並列。條件全部固定，AI 回答仍然可能變動，所以報告寫上觀測窗口——一個點不是趨勢。

只能並列的情況

題庫增加新情境、引擎模式改變或判讀規則不同時，結果可以並列、說明各自範圍，但別直接算差值。

並列不是失敗。它保住了新版本的設計價值，同時沒有虛構一個不存在的可比性。

應該暫停的情況

原始回答遺失、題目版本不明、來源 URL 被人工補猜、核心條件大幅更換，或資料取得狀態不完整——先標記資料不足，補齊後再決定要不要重跑。沒有證據就保留未知，用 0 填滿圖表只是讓缺口變得看不見。

把差異帶回內容假設

假設某個自有來源在 follow-up 出現了，但同一批題目還有其他 runtime 變更。合理的寫法是：「這一輪觀測到自有來源出現，內容改版與執行條件皆需列為可能影響因素。」下一輪固定 runtime，再觀察同一題目。

限制：Baseline 不是固定排名

Google Search Central 現行 AI features 文件提醒，AI Overviews 與 AI Mode 的模型和技術可能不同，回答及連結集合會變動；generative AI 指南也說即使頁面符合技術要求，Google 仍不保證一定抓取、索引或提供。Baseline 讓你的比較條件更清楚——平台輸出的變動，它固定不了。

Google 指南目前提供 Search Console 的 Generative AI performance report，讓網站團隊了解內容如何透過 Google 生成式 AI 功能被發現。那是 Google 搜尋端的官方報告入口，和每個 prompt 的回答事件是不同資料，也不會替其他引擎建立同一套 baseline。

OpenAI Developers 的 prompting guidance 把 prompt 視為 application code，建議每次發布前用 eval cases 測試。這支持把題目、測試案例和版本保留下來；eval 分數和 AI 搜尋的市場排名則是兩件事。AI 回答的來源也可能不完整、過時或錯誤，重要 URL 仍要打開原始頁核對。

常見問題

Prompt 只改一個字，也要新增版本嗎？

先看那個字有沒有改變受眾、任務、條件或回答要點。只是修正錯字、語意和判讀都沒動的話，在變更紀錄裡說明並沿用版本；從「比較」改成「推薦」或加了市場條件，就開新版本——那一個字改掉的是整題的意圖。

Baseline 一定要有很多次觀測嗎？

觀測次數影響的是你能描述多大的變動範圍。baseline 的最低要求是條件和原始證據完整——單次完整事件可以當單次基準，報告標清楚觀測日期，別把它寫成穩定趨勢。

題庫變大後，舊的比例還能直接比較嗎？

先看交集題目和共同分母。新增題目會改變整體分母，舊比例與新比例可以並列；直接相減的話，把排除和重算方法明寫出來。目標是前後內容測試的話，優先保存一組固定的核心題組。

判讀規則改了，要不要回頭重判舊資料？

可以重判，同時保留舊 rubric 的原始結果，新結果標成回溯判讀。兩組結果不加說明就混成一條趨勢線的話，讀者會把規則變動當成回答變動。

版本與 baseline 可以只放在檔名嗎？

檔名可以當索引，正式欄位仍要保存 prompt、題庫、runtime、rubric、內容版本與觀測時間。有這些欄位，查詢、報表和人工核對才會回到同一筆事件——只靠檔名的話，三種人會查出三種結果。

查證邊界

本文外部文件查閱日期為 2026-09-21，使用 Google Search Central 的 AI features、生成式 AI 搜尋指南，以及 OpenAI Developers 的 prompting guidance 與 OpenAI Search 說明。版本、baseline、變更分類與比較狀態是本文方法建議，不是 AI 平台公布的共同排名公式。文中的 git 比喻與 set-category-v3 是說明用的示例。本文沒有以未取得的帳號資料、客戶結果或單次畫面推出成效；實際比較仍需依可讀的原始回答和同一套條件判斷。

AI 搜尋 Prompt 版本怎麼管？建立可比較的 Baseline