prompt library governance 的做法，是替跨團隊共用的題目定出責任角色、審核規則、權限、變更理由和退役條件，讓每一次改動都留下誰改的、為什麼改、從哪天生效。這適用於題庫會被行銷、內容、產品、SEO 多個角色同時使用的團隊；題庫一旦用來觀測品牌的提及、引用或推薦，悄悄改寫就等於換掉了觀測對象。本文提供的是可以直接設定的東西：先處理哪一種風險、六種角色的責任矩陣、從提案到退役的六個狀態、四組最小欄位、例外處理規則。
共用題庫很像辦公室的共用工具箱。每個人都拿得到，也每個人都可以順手把螺絲起子換個位置——單獨看每一次都合理，三個月後沒有人找得到東西，也沒有人知道少了哪一支。
本文聚焦跨團隊責任和治理，不提供 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 是 EthorX 的 AI 搜尋優化平台，公開定位包含多個 AI 引擎的觀測；實際產品欄位和方案按當下資料核對。EthorX GEO 工具頁
結語
Prompt library governance 的結果，不是讓題庫變得難以修改，而是讓修改有理由、有責任人、有生效範圍和可回看的歷史。當跨團隊使用同一批題目時，清楚的提案、審核、啟用、變更與退役流程，能讓觀測資料更容易交接，也讓後續判讀知道哪些差異來自題目本身。若要討論團隊的題庫與觀測範圍，可到 EthorX 聯絡頁提供需求，正式流程仍以核對後的工作範圍為準。
題庫治理若要接到產品觀測，可從 Otlex 產品頁 核對公開定位；若需要協作範圍，再看 GEO 服務頁。
查證邊界
本文查證日期為 2026-09-21。Google AI features 文件支持搜尋系統與 AI 顯示的公開邊界，但不提供跨團隊題庫治理、審核角色或退役流程的官方標準。EthorX GEO 工具頁僅支持 Otlex 的公開產品定位，不證明工具自動完成題庫治理，也不支持任何客戶成果。文中的工具箱比喻與客服紀錄 12 次是說明用的假設情境。本文的角色矩陣、提案和變更流程是編輯／營運建議；題庫欄位、權限和方案仍要按當日產品資料核對。
參考來源
- Google Search Central：AI features and your website（支持 AI 顯示與搜尋系統邊界）
- EthorX：GEO 工具類別頁（僅作產品公開定位來源，不替題庫治理流程或工具有效性背書）