假設行銷、內容和產品三個團隊都能編輯同一份題庫。有人為了讓品牌出現，把問題改得更像品牌題；有人又把市場和語言換掉，最後的趨勢圖看似連續，實際上每輪問的不是同一件事。共用題庫像實驗室的量杯，大家可以輪流使用，但刻度不能每週由不同人重畫。
題庫本身怎麼設計，見 AI 搜尋題庫設計；這篇處理題庫交給多個團隊使用之後的審核與交接。
題目版本與基準的變更規則另見 Prompt 版本與 Baseline。
也像辦公室的共用工具箱。每個人都拿得到，也每個人都可以順手把螺絲起子換個位置，單獨看每一次都合理，三個月後沒有人找得到東西，也沒有人知道少了哪一支。這篇只講跨團隊的責任和治理，prompt 怎麼寫是另一篇的事；先把題庫當成一項共享研究資產，再決定工具裡要有哪些欄位和流程。
題庫提案、審核與交接應留下可回查的責任與變更紀錄。
題庫治理先處理哪一種風險
共享題庫最容易出的問題，通常和文句好不好無關，而是大家對題目的用途理解不同。行銷角色想測品牌認知，內容角色想測服務選擇，產品角色想測功能比較。三個人看同一筆回答，會給出三種判讀，然後在會議上爭論一個其實沒有定義過的指標。
治理要先回答三件事：
- 這題要觀察哪一種使用者問題？
- 哪些條件必須保持固定，哪些部分可以因市場或語言而分支？
- 誰能提案、審核、啟用、修改和退役？
Google 的 AI features 官方說明指出，AI Mode 和 AI Overviews 仍依一般搜尋系統處理內容，也可能使用不同查詢展開與來源。所以你的題目和條件要自己保存，搜尋系統那邊沒有一份對應的設定。Google AI features 官方說明
prompt library governance 的角色和責任
先建立責任矩陣，再選工具欄位。以下角色可以由同一個人兼任，但兼任要寫出來，避免出現「每個人都能改，所以沒有人負責」的情況。
| 角色 | 主要責任 | 可以決定的事 | 需要留下的紀錄 |
|---|---|---|---|
| 題庫責任角色 | 維持題庫目的與範圍 | 啟用、停用與分組原則 | 題庫政策、責任人與審核週期 |
| 提案者 | 提出題目與使用理由 | 說明意圖、受眾和預期用途 | 提案內容、來源和影響範圍 |
| 事實審核者 | 核對品牌、產品或服務語境 | 判斷題目是否含未核准主張 | 核對來源、日期與意見 |
| 執行者 | 按核准條件執行觀測 | 回報執行狀態與材料 | 題目識別、日期、引擎和結果 |
| 使用者 | 讀取結果並建立工作 | 將現象轉成內容或研究任務 | 判讀、連結與下一步 |
| 系統管理者 | 管理權限、備份和資料取回 | 新增或撤銷帳號 | 權限變更與操作紀錄 |
責任角色不必是職位最高的人，重點是他有權處理題庫邊界和爭議。題目涉及產品事實、法規、價格或競品比較時，指定能核對那個內容的角色。讓提案者自己當唯一審核者，等於沒有審核。
題目寫法和平台規則是兩層
題目要中性、可理解、可重複，這是你的治理設計。搜尋引擎怎麼處理查詢、顯示回答、選取來源，要回到各平台的官方文件，兩層各管各的。
責任角色和 approver 可以分開
題庫會影響報告或內容優先順序時，至少讓另一個角色確認題目用途和品牌事實。單人審核比較快，代價是共享資料的責任集中在一個人身上，那個人離職或休長假的那一週，題庫就會停在原地。
一題從提案到退役要經過什麼
題庫流程可以用六個狀態表示：
1. 提案
提案者提交題目原文、使用者意圖、市場、語言、預期觀察和原因。題目源自客戶問題、網站搜尋紀錄或內部研究時，記下來源類型。「業務說客戶常問」和「客服紀錄有 12 次」是兩種來源，前者要標成未核對的轉述。
2. 初審
責任角色檢查題目是否重複、範圍是否清楚、是否包含需要事實核對的主張。初審可以退回補充，也可以標記需要產品或法務角色加入。
3. 事實核對
涉及品牌名稱、產品能力、服務範圍或公開政策時，核對現行來源和日期。沒有可核對來源時保留待確認狀態。題目提早進固定觀測集合，之後就會有一批數字建立在一個沒人查過的說法上。
4. 啟用
通過審核後給題目識別和啟用日期，並將市場、語言、意圖與適用引擎寫入欄位。只是測試的話，別放進正式趨勢集合。測試題目混進趨勢線，之後很難分辨哪幾段資料該被排除。
5. 變更
變更時保留舊文字、修改後文字、原因、提案者、審核者和生效日期。變更理由要讓沒參加這次會議的人看得懂：市場語境改變、品牌事實更新、題目原本太寬。只寫「優化」的話，半年後你自己也還原不出當初改了什麼。
6. 退役
題目不再適用、重複、含過時事實或無人負責時，可以退役。退役和刪除不同。保留題目歷史與最後一次執行資料，摘要裡寫明從哪一天起不再納入新觀測。刪掉的話，那段歷史趨勢就變成一條斷頭的線。
題目可依適用狀態啟用、暫停或退役保存；退役是停用，歷史留著。
哪些欄位讓題目可交接
題庫最小欄位可以分為四組：
| 欄位組 | 建議欄位 | 交接時回答的問題 |
|---|---|---|
| 身分 | 題目識別、原文、語言、意圖、狀態 | 這題是什麼，現在能不能用 |
| 責任 | 責任角色、提案者、審核者、代理人 | 有問題要找誰 |
| 變更 | 版本、修改理由、生效日期、前一版本 | 為什麼和以前不同 |
| 執行 | 引擎、範圍、最近執行、結果連結 | 最近一次在哪裡看 |
欄位越多不會越好。先確保每個欄位真的會被使用，並在題目頁面旁邊寫定義。「啟用」指的是可以被排程執行，還是已經完成一次有效觀測？「版本」是題目文字版本，還是整組條件版本？這兩個詞沒有定義的話，兩個團隊會各自用各自的意思填同一欄。
共享集合與個人草稿要分開
個人草稿讓探索變快，它不該自動流進共享集合。建兩個空間或狀態，並寫出從草稿到正式題庫的最低條件。沒有這道門檻，正式報告裡遲早會出現一題沒有人審過的問題。
題目內容和結果資料要分開
題目本身是治理資產，回答和引用是執行結果。別用最新一次回答覆蓋題目紀錄，也別從回答摘要反推題目意圖。兩者用識別連起來，各自保留。回答會變，題目的意圖不該跟著變。
跨團隊審核的例外處理
例外流程要把緊急需求的風險寫清楚，也要維持治理紀錄。遇到下列情況，可以暫時建立受限題目：
- 公開政策或產品資訊剛更新，需要先檢查題目是否仍適用。
- 客戶或內部團隊提出高優先問題，但事實核對還在進行。
- 市場或語言新增，既有題目不能直接套用。
- 引擎或觀測條件變更，需要先確認資料可讀性。
受限題目要有到期日期、指定 reviewer、使用範圍和標記。沒有到期日的「暫時」通常會變成永久。到期時由責任角色決定轉正式、修改還是退役。
治理也要保留「拒絕加入」的理由。這能讓後續提案者知道是題目重複、範圍太寬、來源不足，還是超出專案邊界。拒絕記錄的是決定，跟某個人的寫法好不好無關，它讓下一個提案者少繞一圈。
如果要把題庫接到觀測工作，可以先讀 GEO baseline workflow理解 Day 0 需要哪些題目識別；若要檢查 dashboard 如何呈現版本和範圍，參考 AI 搜尋監測 dashboard。採購題庫功能前，也可以用 AI 搜尋監測工具採購清單核對權限、匯出和保存條件。
常見問題
prompt library governance 和單純版本管理有什麼差別？
版本管理回答的是「改了什麼」；治理還要回答誰能提案、誰核對、誰啟用、何時退役、哪些題目進正式集合、爭議怎麼處理。版本欄位是治理的一部分，有了它，還是可能發生「每個人都能改，所以沒有人負責」。
題庫責任角色一定要由 SEO 角色擔任嗎？
由最能承接題庫目的、範圍和交接的人擔任就好，職稱不是條件。涉及產品或品牌事實時，讓相應角色參與核對。SEO 可以是使用者、審核者，也可以兼任責任角色，看組織分工，跟這件事聽起來像誰的工作無關。
題目改一個字也要重新審核嗎？
先看那一個字會不會改變意圖、範圍或品牌語境。「推薦」改成「適合」看起來很小，判讀規則卻可能整個換掉。會改變條件的改寫留下前後版本和理由，再由責任角色決定要不要事實審核；純文字調整也保留變更紀錄。
可以把緊急題目直接加入正式題庫嗎？
建立受限狀態，配上到期日、reviewer、適用範圍和標記。正式集合的定義保持一致。時間壓力可以省掉一次會議，省不掉責任紀錄，否則下個月你會有一批來路不明的題目。
Otlex 可以代替跨團隊題庫治理嗎？
工具能保存題目和觀測結果。責任角色、審核、權限、事實核對與退役這五件事，要由組織決定。工具提供的是欄位，決定誰能填那些欄位的是你。Otlex 是我們的 AI 搜尋優化平台，觀測多個 AI 引擎的回答；實際的題庫欄位和方案按當下的產品頁核對。
結語
Prompt library governance 的目的是讓修改有理由、有責任人、有生效範圍和可回看的歷史，而不是讓題庫變得難改。跨團隊使用同一批題目時，清楚的提案、審核、啟用、變更與退役流程，能讓觀測資料更容易交接，也讓後續判讀知道哪些差異來自題目本身。
題庫治理要接到產品觀測的話，Otlex 是我們為此開發的平台；需要有人一起定規則和判讀，GEO 服務有範圍說明。