AI 搜尋 Prompt Set 怎麼設計？題庫規劃與覆蓋方法

AI 搜尋 Prompt Set 的設計方式，是先寫一句話的任務定義，再依認知、問題、比較、決策、品牌核對五種題型鋪出覆蓋，每一題都帶著意圖、受眾、市場、語言、地區與判讀要點一起入庫。這適用於要重複執行、前後比較的觀測題庫；題目一旦標成 ready 就別再偷改句子，要改就發新版本，否則下一輪的差異可能只是問題換了。本文提供的是可以直接開工的東西：題型矩陣、寫題的四個原則、人工去重表、從空白表到第一版的五個步驟，以及這套題庫測得到與測不到什麼。

先看一個常見的失敗。假設你列了 40 題，長相大致是「有哪些 AI 搜尋優化工具推薦？」「AI 搜尋工具哪個好用？」「推薦的 AI 搜尋平台有哪些？」跑完，品牌提及率 62%，數字看起來還行。實際上你只測到一件事：在「求推薦」這個問法下品牌會不會出現。使用者真正卡住的問題——「20 人團隊該自建還是買」「來源 URL 怎麼保存才查得回去」——題庫裡一題都沒有。

題庫的品質來自不同情境的覆蓋、可重跑性與解釋變化的能力，跟題目數量關係不大。40 題全是同一種問法，覆蓋還是 1 種。

相似題目經審核後分流成比較題與決策題的概念圖 相似題目經審核後分流成比較題與決策題，示意題庫欄位與管理情境。

AI 搜尋 Prompt Set 怎麼設計：先定義觀測任務

出差前會先寫清楚「這趟要談成什麼」，題庫也一樣：在寫第一題之前，先把任務寫成一句話。例如「觀測台灣 B2B 團隊找 AI 搜尋優化平台時，品牌是否被提及、來源是否可追溯，以及回答是否處理導入條件。」

這句話會限制後面的題型與欄位。任務若只寫成「看品牌有沒有出現」，題庫多半會整批倒向品牌直問，最後看得到認知，看不到類別、比較和限制情境——就是上面那 40 題的來源。

可以把任務拆成五個設計決定：

設計決定	要先回答的問題	產出欄位
觀測對象	要看品牌、產品、服務還是內容主題	`entity_scope`
受眾情境	誰在什麼情況下提問	`audience`、`market`
意圖	使用者要認識、解決、比較還是選擇	`intent`
證據事件	要標記提及、引用、推薦或回答要點	`event_fields`
比較條件	哪些欄位必須固定	`language`、`region`、`date`、`engine`

這些欄位是題庫管理方法，不是任何 AI 引擎公開承認的分類。它們的價值在於讓每一題都有可追查的設計理由：三個月後有人問「這題為什麼算比較題」，欄位裡就有答案。

題型矩陣：哪些意圖要放進題庫

五種題型大致對應一個客戶從「你們是誰」問到「那我該選誰」的過程。題庫少掉其中一段，就會有一段路看不見。

認知題：確認實體和類別

認知題問「X 是什麼」、「X 提供什麼」或「哪些公司在做某項服務」，用來檢查品牌名稱、產品類別、公司關係和基礎描述。這類題的回答先看 mention 與實體內容；品牌被介紹了一段，還是停在提及，別直接記成推薦。

問題題：確認方法和限制

問題題從使用者手上的任務開始，例如「如何觀測 AI 回答中的品牌引用？」或「怎麼保存可重查的來源 URL？」這類題目適合檢查回答有沒有給出步驟、前置條件和限制，也能連回你的內容頁解不解得了這個問題。

寫這類題時最常見的走樣，是把服務名稱塞回題目裡，變成「如何用某某平台觀測品牌引用？」——原本的資訊需求就不見了，回答也只會沿著那個品牌講。

比較題：固定共同比較面向

比較題要求兩個以上的方案在相同條件下對照，所以題目本身要寫出比較面向：資料來源、保存方式、適用團隊、限制。

「A 和 B 哪個好」這種問法的麻煩在於，回答會自己挑標準——這一輪比價格，下一輪比功能數量，兩輪看起來都變了，其實只是評分尺變了。

決策題：把條件寫進選擇情境

決策題要交代使用者的條件：團隊規模、地區、語言、預算區間、既有工具、需要的整合方式、導入時間。條件越具體，越判讀得出回答是不是真的提出了合適選項。

決策題要觀測的是條件式推薦（「如果你是這種情況，可以考慮 X」），而不是回答把哪個品牌排在第一個。

品牌核對題：確認回答是否描述正確

品牌核對題問「某品牌的產品類別、適用情境和限制是什麼」，用來檢查 AI 有沒有把公司、產品與服務關係混在一起，例如把一個平台講成顧問服務。

它擅長找出實體描述缺口，但代替不了類別題或決策題——題目裡已經給了品牌名字，回答會提到它是理所當然的。

可以先用矩陣檢查第一版覆蓋：

題型	主要意圖	最少要固定的條件	主要判讀
認知	認識實體或類別	語言、地區、名稱	mention、描述正確性
問題	找方法或答案	任務、輸出需求	answer coverage
比較	對照方案	比較面向、候選集合	mention、citation、取捨
決策	選擇適合方案	受眾條件、限制	recommendation、理由
品牌核對	校正實體描述	品牌別名、產品關係	entity accuracy

這張矩陣決定不了題目數量，它只保證題庫不是同一種問題的集合。每一格要放幾題，仍要看市場、產品類別與你實際跑得動的觀測量。

題目寫法：讓問題接近真實決策

用具體任務取代廣泛形容

比較這兩個問法：

「最好的 AI 工具是什麼？」——沒有受眾，也沒有標準。
「台灣 20 人 B2B 團隊，想每週比較固定 AI 搜尋問題的品牌提及與來源 URL，應該如何評估工具？」——市場、團隊規模、頻率、觀測事件、任務都在裡面。

後者未必是唯一正確的問法，但它容易設定回答要點，也容易解釋某個品牌為什麼被列為候選。

一題只保留一個主要決策

問卷設計有個老問題叫「雙管問題」：一題同時問兩件事，受訪者答了，你也不知道他在回答哪一個。prompt 也會這樣。

一題可以有背景、條件和輸出格式，但主要決策最好只有一個。同時要求定義、比較、報價、技術整合和導入計畫的題目，回答會大幅變動，而你分不出是哪個子任務造成的。複合需求就拆成一組有關聯的題目，用 scenario_id 串起來，而不是塞成一個超長 prompt。

先寫判讀要點，再寫句子

改考卷之前要先有評分標準，寫題目之前要先有判讀要點。每題至少先寫三個，例如：

回答是否正確區分 AI 搜尋觀測和一般排名。
回答是否說出固定題庫、引擎與時間條件。
回答是否交代引用 URL 的保存與核對限制。

這些要點是題目的驗收規格，給判讀的人看的。把規格直接寫進 prompt，題目就失去自然問題的樣子，也可能引導模型照著模板重述一遍。

保留自然語氣，但固定不可變條件

自然問題可以有不同句型，該固定的是會影響比較的條件：繁中、台灣、桌機或手機、觀測模式、登入狀態、題庫版本、執行期間。這就是實驗的控制變因。

每次執行都容許改寫整題的話，後續看到的差異可能只是問題換了，跟你改的內容無關。

去重與覆蓋：怎麼避免同一題換字重複

比較主題，不只比字串

問卷裡「你多常使用？」和「使用頻率為何？」是同一題。prompt 也一樣：兩題字面不同，但要求的動作、條件與判讀要點都相同時，它們仍是同一個觀測單位。

可以用下表先做人工去重：

檢查面向	問題一	問題二	是否保留兩題
主要動詞	比較	選擇	可能保留，需看條件
受眾	台灣 B2B 團隊	台灣 B2B 團隊	相同
條件	固定題庫、來源 URL	固定題庫、來源 URL	相同
輸出要求	列比較面向	給適用理由	可能不同
判讀要點	取捨與來源	推薦條件與理由	視任務分工

這是寫題時要留下的人工檢查，不是自動語意檢測。兩題的差異若只在「推薦」和「適合」兩個詞，把其中一題換成真正的缺口——來源查核，或導入限制。

以情境覆蓋，而不是用同義詞湊數

一組題庫可以按受眾、任務階段、內容主題和風險條件分層，每層都要有它存在的觀測理由：認知題看實體，問題題看方法，比較題看共同比較面向，決策題看條件式理由。

把「推薦」「建議」「適合」輪流替換出來的題目，答案通常高度相似，只是讓人工判讀的量變成三倍。

把品牌直問和非品牌題分開

使用者不一定知道你的品牌名字。他知道的是需求，所以他會問「怎麼追蹤 AI 回答有沒有提到我們」，而不是「某某平台好用嗎」。非品牌的類別題更接近這種發現情境，也才看得出品牌會不會自然出現在候選或來源裡。

兩種題目都要，但報表要保留題型。品牌直問的提及率天生就高，和類別題混成一個總數，那個數字誰也解釋不了。

實作步驟：從空白表到第一版題庫

第一步，建立題庫欄位

至少使用以下欄位：

prompt_id                題目編號
prompt_version           題目版本
scenario_id              同一情境下的關聯題目
prompt_text              題目原文
intent                   認知／問題／比較／決策／品牌核對
audience                 受眾條件
market                   市場
language                 語言
region                   地區
engine_scope             這題要跑哪些引擎
required_points          判讀要點
event_fields             要標記哪些事件
owner                    誰負責這題
status                   draft／review／ready／retired

題目進入 ready 之前，先確認句子、條件、判讀要點和去重結果都過了。這些是題庫的品質欄位，跟 AI 引擎回傳什麼無關。

第二步，先做小型代表集

問卷正式發放前會先做預試，題庫也該有這一步。先為每一種意圖建立少量代表題，跑一次，看看有沒有缺必要條件、有沒有題目根本判讀不了、有沒有來源畫面或回答長度上的麻煩。修訂題型之後，再擴充同一分層。

小型代表集的用途是找設計缺口。這一輪跑出來的比例不要拿去當品牌可見度報告，樣本還沒有代表性。

第三步，做可判讀性檢查

每題交給另一個人，只請他回答三件事：看得懂使用者要什麼嗎？知道要看哪些回答證據嗎？能把這題和題庫中的其他題分開嗎？

三題有一題答不出來，就先修題目或要點。這一步花的時間大概十分鐘，省下的是跑完幾百筆之後才發現題目判讀不了。

第四步，保存執行條件

同一組題目在不同引擎可能落在不同的回答介面。每次執行都保存引擎、模式、語言、地區、觀測時間、登入狀態與來源取得方式。

OpenAI 官方 prompting guide 另建議把 prompt 當作 application code 管理，並在發布前用 eval cases 測試。本文把這個原則套在題庫設計上：題目也該有輸入和驗收規格，改動要能回溯。

第五步，固定一版再交給觀測

題目從 ready 到實際觀測之間，句子就別再動了。需要修改時產生新版本，並把變更理由寫下來。版本化與基線的細節屬於重複觀測的比較方法；本文先把題目設計成後續可以版本化的單位。

限制：Prompt Set 能測到什麼

Prompt Set 是一份觀測設計，它能說明的是「這組題目、這些引擎、這些條件、這個日期下的回答事件」。要推到所有市場使用者看到的內容，或把一次題庫結果改寫成固定排名，都超出這份資料的範圍。題庫變大也消不掉設計偏差——40 題同一種問法，擴成 400 題還是同一種問法。

Google Search Central 的生成式 AI 指南指出，SEO 基礎仍然是 Google 生成式 AI 搜尋的基礎，並說明 Search Console 有 Generative AI performance report 可用來了解內容如何透過相關功能被發現。這些是 Google 搜尋端的官方測量入口；跨引擎的 prompt、回答、引用與推薦，仍要按各自的觀測條件保存。Google 也提醒頁面符合要求仍可能遇到抓取、索引或提供上的差異。

OpenAI 目前的 prompting guidance 建議每次發布前使用 eval cases 測試 prompt，並把 prompt 當成應用程式碼管理。這支持保存題目版本和測試案例的做法；至於一套題庫能不能預測所有模型回答，或官方有沒有給出 AI 搜尋 Prompt Set 的共同標準，文件沒有這樣說。

Otlex 是 EthorX（伊索斯科技有限公司）開發的 AI 搜尋優化平台，觀測 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 等七個 AI 引擎回答中的提及、引用與推薦，可以把題目、回答和內容缺口串在一起。題庫怎麼代表你的市場、哪些題目要進入比較，仍要依專案目標設計。

常見問題

Prompt Set 和關鍵字清單一樣嗎？

Prompt Set 多了幾層東西。關鍵字清單整理的是查詢詞，題庫還要寫出使用者情境、條件、回答任務和判讀要點。同一個關鍵字「AI 搜尋工具」底下，可能同時躺著認知題、比較題和決策題，三題要觀測的事件完全不同。

每一個引擎都要用完全相同的題目嗎？

目標若是比較同一問題在不同引擎的回答，就把核心文字保持一致，再分別記錄引擎介面和拿得到的來源欄位。某個產品只支援不同輸入格式時，把變更記下來，那一輪就別當成完全相同的實驗條件。

題庫一定要包含品牌名稱嗎？

兩種都要，但分層報告。品牌直問檢查的是實體描述，非品牌的類別、問題和決策題看的是使用者沒指定品牌時會拿到什麼。用品牌直問的結果代表整體類別可見度，數字會偏高很多。

Prompt Set 要放幾題才算足夠？

沒有一個本文能證實的通用數字。題數取決於市場、語言、受眾、意圖層和你跑得動的觀測量。比較實際的順序是：先確認每一層都有可判讀的代表題，再擴充與重跑；先追一個漂亮題數，通常只是把同一種題目複製很多份。

可以讓模型自己產生所有題目嗎？

可以拿它當發想工具，產出的題目仍要人工檢查意圖、條件、去重與證據欄位。OpenAI 官方 prompting guidance 建議使用 eval cases 測試 prompt；無論題目由誰草擬，版本和測試結果都要留下，才知道這一版題庫代表的是什麼。

查證邊界

本文外部文件查閱日期為 2026-09-21，使用 Google Search Central 的 AI features、生成式 AI 搜尋指南，以及 OpenAI Developers 的 prompting guidance。題型矩陣、去重規則、欄位和可判讀性檢查是本文的方法建議，不是任何 AI 引擎公布的共同標準。文中的 40 題、62%、20 人團隊都是說明用的假設情境，不是實測數字。本文沒有使用未授權的客戶題庫或個人案例；實際題庫仍需依市場與資料治理範圍重新設計。

AI 搜尋 Prompt Set 怎麼設計？從問題覆蓋到可判讀題庫