讓 Codex 找出你的客戶已經在問的 30 個真實問題

使用 Codex 將客戶語言、批准的匯出資料和搜尋結果筆記轉化為 30 個真實問題，這些問題可以成為有用的 SEO 和 GEO 頁面。

在找到關鍵字之前先找到問題

關鍵字是有用的標籤。問題揭示了訪客正在嘗試完成的工作。當你給 Codex 真實的客戶語言時，它可以將工作分組成人們真正需要的頁面，而不是產出同一短語的五十個變體。

完成的定義： 你有 30 個有來源標記的客戶問題，每個都標記為可能的頁面、支援段落、現有頁面改善或不適合。

預留 45 到 60 分鐘。 帶上你的流量任務、事實包，以及任何你可以安全使用的真實客戶語言。十個好的、有來源標記的問題，勝過三十個根本沒人問過的漂亮短語。

帶三種語言

使用你擁有的任何東西。第一次執行不需要付費軟體。

1. 客戶語言： 支援工單、銷售通話、評論、電子郵件、站內搜尋或你的團隊反覆聽到的問題。移除個人資料。
2. 搜尋證據： 批准的 Search Console 匯出、關鍵字工具匯出、你手動記錄的 Google 建議，或競爭對手/SERP 筆記。
3. 你的事實包： 它告訴 Codex 你可以誠實回答哪些問題。

建立一個名為 question-inputs.md 的簡單檔案，包含三個標題，並將素材貼在下面。為每個來源加上標籤。一個沒有來源的問題仍然可以是一個構想，但它不是證據。

讓輸入檔案安全且可讀

在將任何東西貼入 Codex 之前，移除姓名、電子郵件地址、訂單號碼、電話號碼和私人案例細節。保留揭示決策的措辭。一個安全的輸入檔案可能看起來像這樣：

## 銷售通話筆記
- 「我有一袋收據。在自我評稅前尋求幫助是否太晚了？」
- 「你們是否與通過多個平台開立發票的設計師合作？」

## 支援和電子郵件主題
- 「我預約探索通話後會發生什麼？」
- 「我是否需要居住在布里斯托？」

## 搜尋證據
- 查詢：bookkeeping checklist self assessment | 頁面：NONE | 來源：GSC 匯出，
  完整的 28 天期間
- 查詢：freelance designer bookkeeping | 頁面：/bookkeeping-for-designers |
  來源：GSC 匯出，完整的 28 天期間

這個輸入刻意地參差不齊。一個真實的地圖結合了確切的語言、廣泛的搜尋標籤和業務問題。工作是將它分類，而不是讓它聽起來像一份關鍵字研究報告。

品質檢查： 每一行都帶有來源標籤。如果你只有內部記憶，寫 owner observation 並附上日期。這仍然比假裝它是搜尋需求更誠實。

使用這個 Codex 標準

你是我的客戶問題地圖繪製師。

閱讀：
- 流量任務：[路徑]
- 事實包：[路徑]
- 客戶/搜尋輸入：[路徑]

建立 customer-question-map.csv，包含確切的欄位：
question, source, customer_job, intent, page_fit, proof_available, priority, notes

規則：
- 僅在提供的證據支持時才產出 30 個不同的問題。
- 盡可能保留客戶的語言。
- 將 page_fit 設為 NEW PAGE、EXISTING PAGE、SECTION、NOT A FIT 或 NEEDS FACT。
- 不要發明搜尋量、排名、客戶引述或產品主張。
- 將近似重複的問題標記出來，而不是將它們呈現為獨立的構想。
- 優先考慮符合流量任務且有可用證明的問題。

在 CSV 之後，寫一個五行摘要：三個最強的客戶工作、
最大的證據缺口，以及最有可能成為第一個流量頁面的那個問題。
不要撰寫內容或編輯我的網站。

逐列閱讀 CSV

以記帳範例而言，第一批有用的列可能看起來像這樣：

CSV 不是發布計畫。它是一塊分類板。一個 SECTION 列可能比一篇新文章更有價值，因為它修復了買家已經需要的頁面上的問題。

在計算到 30 之前，強迫 Codex 分組重複項

三十個問題不代表三十個頁面。在第一張地圖之後立即要求進行一次重複項處理：

閱讀 customer-question-map.csv。將具有相同客戶決策的列分組，
即使措辭不同。對於每一組，選擇一個規範問題，列出來源列，
並建議 NEW PAGE、EXISTING PAGE、SECTION、NOT A FIT 或 NEEDS FACT。
不要新增問題、推斷數量或撰寫內容。

例如，「我需要哪些記錄？」、「我該保存哪些收據？」和「我如何在自我評稅前準備我的帳本？」可能屬於一個決策指南下的幾個支援段落。發布三篇幾乎相同的文章不是覆蓋。這是重複。

知道一個真實問題長什麼樣子

如果 Codex 給你 30 個漂亮的關鍵字短語，但無法顯示來源或客戶工作，要求它重新開始。你的第一張問題地圖應該感覺略微雜亂且具體。這是它來自真實客戶語言的跡象。

在信任地圖之前先審查前十列

按 priority 排序 CSV，並在以下情況拒絕某一列：它與你的流量任務是不同的客戶工作、事實包無法支持有用的答案、它與現有頁面重複、或它僅僅是關鍵字變體。用 not now 的註記保留被拒絕的列；不要刪除它們。後續的證據可能使它們有用。

偏好真實的客戶問題勝過泛泛的清單。偏好連結到你其中一個頁面的 Search Console 查詢，勝過一個推測性的流量數字。偏好你可以用證據支持的頁面，勝過一個聽起來只是商業化的短語。

用簡單的決策表評分最強候選人

取前十列或前十組，只評分四件事。使用 0、1 或 2；不要假裝這是精確的預測。

總分不會替你決定。它讓與 Codex 的對話變得具體。一個分數較低的問題如果急迫且你能誠實回答，仍然可能勝出。分數主要阻止一個有吸引力但沒有支持的主題壓過一個有用的客戶問題。

使用這個提示詞建立短名單：

閱讀已分組的客戶問題地圖、流量任務和事實包。使用 0、1 或 2
對前十組的證據、任務適合度、證明和頁面槓桿進行評分。
用一句話解釋每個分數。推薦一個第一頁候選人、兩個次要候選人，
以及一個要暫存到擁有者事實存在為止的問題。不要建立內容或編輯網站。

修復三張常見的壞地圖

每一列都寫 NEW PAGE。 要求 Codex 找出買家會希望在同一頁面上獲得答案的問題。在答案很短或屬於一個較大決策的一部分時，要求 SECTION 推薦。

問題聽起來像 SEO 文案。 回到 question-inputs.md，要求模型在每個改寫問題旁引用最接近的原始措辭。刪除它無法追溯到來源的列。

地圖有好的問題但沒有證明。 將它們標記為 NEEDS FACT，然後將確切缺失的事實新增到 owner-questions.md。一個有希望的問題不是撰寫你無法支持的答案的許可。

將最終檔案保存在一起：

question-map/
  question-inputs.md
  customer-question-map.csv
  grouped-question-map.md
  question-shortlist.md

當另一個人可以將勝出的問題追溯到真實語言，並理解為什麼它屬於一個頁面而不是一個無盡的構想清單時，地圖就完成了。

將暫存的問題轉化為未來可審查的決策

不要因為一個問題今天無法成為頁面就刪除它。在短名單中，加入一行重新激活規則：Revisit when [specific fact, repeated customer wording, completed period, or new page exists].（當 [特定事實、重複的客戶措辭、完整的期間或新頁面存在] 時重新審視。）例如，「設計師可以在英國以外使用這項服務嗎？」這個問題會一直暫存，直到擁有者批准一份服務區域聲明。它不應該每次你向 Codex 要求構想時都重新出現為一個頁面標題。

在下次審查時，使用這個提示詞：

閱讀 question-shortlist.md、當前的流量任務和新證據：[路徑]。
僅審查暫存的問題。對於每個問題，說明它的重新激活規則是否已滿足、
哪個事實包資料列支持一個答案，以及它是新頁面、現有頁面段落，
還是仍然 NOT NOW。不要建立內容或因為一個問題聽起來可搜尋就推廣它。

這給現有網站一個紀律化的待辦清單，並給新網站一個從證據中成長的方式，而不是從一份泛泛的 100 關鍵字表格。

課程地圖

下一課：挑選最有可能為你帶來首次新自然流量的那一個頁面。它將三十個可能性變成一個頁面決策。

完成檢查清單

• [ ] 每個問題都有來源，或清楚標記為未驗證的構想。
• [ ] 相似的問題已分組而不是重複。
• [ ] 每一列都有客戶工作和頁面適合度決策。
• [ ] 我可以說出第一流量頁面的最強候選人。
• [ ] 我已移除個人資料並為每個有用的問題保留來源標籤。
• [ ] 在將近似重複視為頁面機會之前已先分組。
• [ ] 我建立了一份包含一個第一頁面候選人的短名單，而不是一份 30 頁行事曆。

作者：Elena Shaw，Auspia 提示庫策略師，繪製超過 3,000 個買家提示詞。Elena 專注於將真實客戶語言轉化為有用的搜尋和 AI 回答覆蓋。

![問題地圖工作包流程圖]()

對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。