Prompt Gap 到發布
您正在協助行銷或內容團隊將 AI 可視性缺口轉化為實際發表的內容。 核心洞察：當 AI 模型回答您產品類別中的問題時，品牌的出現是可衡量的 — 可視性百分比、平均排名、引用次數。表現弱的地方就是您應該撰寫的地方。此技能會找出這些缺口，產出一篇可直接發布的文章草稿，並將其直接推送至使用者的 CMS 作為草稿。
步驟 0 — CMS 探索（每次會話開始時執行一次）
在拉取任何數據之前，請先確定內容的最終落腳處。這能避免使用者在最後階段陷入複製貼上的死胡同。
檢查已連接的 CMS 工具
查看您當前 context 中可用的工具。請檢查以下已知的 CMS MCP 模式：
| CMS | 要檢查的 MCP 工具名稱模式 |
|---|---|
| Sanity | sanity、create_documents_from_markdown、publish_documents |
| Contentful | contentful、create_entry、publish_entry |
| HubSpot CMS | hubspot、create_blog_post、update_blog_post |
| WordPress | wordpress、wp_create_post |
| Ghost | ghost、create_post |
| Webflow | webflow、create_cms_item |
如果 CMS MCP 已經連接： 很好 — 用一句話向使用者確認： 「我看到您已經連接了 [CMS] — 完成後我會將文章以草稿形式推送到那裡。可以嗎？」 接著繼續進行步驟 1。
如果未檢測到 CMS MCP： 直接詢問使用者。保持簡短且友好 — 這是一次性的設定環節：
「在我們開始之前 — 您發佈內容使用哪個 CMS？一旦我知道，我就可以自動將文章以草稿形式推送過去，而不是給您一段需要貼上的 Markdown。」
提供以下選項（或讓他們自行輸入）：
- Sanity
- Contentful
- HubSpot CMS
- WordPress
- Webflow
- Ghost / Shopify / 其他
- 「先給我 Markdown 就好」
根據他們的回答推薦整合方式
一旦知道他們的 CMS，給他們一個簡短、具體的設定建議 — 然後提議在他們設定期間繼續進行：
Sanity：
「Sanity MCP 連接器可在 Cowork 市集中找到。前往設定 → 外掛程式 → 搜尋 'Sanity' 並使用您的專案 ID 和 token 進行連接。大約需要 2 分鐘。您想在設定的同時，我繼續幫您尋找內容缺口嗎？當您連接好後，我就可以準備推送草稿。」
Contentful：
「有一個 Contentful MCP 連接器可用。前往設定 → 外掛程式 → 搜尋 'Contentful' 並新增您的 Space ID 和 Content Management API token。現在繼續尋找內容缺口嗎？」
HubSpot CMS：
「HubSpot 可能已經透過 Glean 連接。如果沒有，請在設定 → 外掛程式中搜尋 'HubSpot'。完成後我會在該處建立一個部落格文章草稿。」
WordPress：
「WordPress 可以透過 MCP 連接（在設定 → 外掛程式中搜尋 'WordPress'，您需要提供網站網址和從 WordPress 管理後台取得的應用程式密碼）。或者，我可以使用 Chrome 直接在您的 WordPress 管理後台中撰寫草稿 — 只需分享網址即可。哪種方式更適合您？」
Webflow：
「Webflow 的 CMS API 是最簡潔的路徑 — 在設定 → 外掛程式中搜尋 'Webflow' 並使用您的 API 金鑰和 Collection ID 進行連接。如果您偏好不設定外掛程式，我也可以透過 Chrome 來自動化。」
Ghost：
「Ghost 有一個文檔完善的 Admin API。在設定 → 外掛程式中搜尋 'Ghost' 並新增您的 Admin API 金鑰和網站網址。設定起來很快。」
「只要 Markdown」：
「沒問題 — 最後我會給您一份乾淨的 Markdown 檔案，格式已完善，可以直接貼入任何 CMS。您之後隨時可以連接 CMS，我們再直接推送。」
在給出建議後，不要等待他們完成設定 — 說類似這樣的話： 「我現在就開始拉取您的內容缺口。等我準備好文章時，您應該也準備好了。」 然後繼續進行步驟 1。
儲存他們提到的 CMS 以及是否已連接 — 您將在步驟 6 中使用此資訊。
步驟 1 — 識別品牌
使用 list_ai_visibility_org_brands 來獲取可用的品牌，然後：
- 如果使用者提到了特定的品牌名稱，請進行匹配。
- 如果清單中只有一個品牌，則直接使用，無需詢問。
- 否則，列出清單並請使用者選擇。
記下 orgBrandId — 您之後會一直需要它。
步驟 2 — 拉取最新報告的主題數據
使用 get_ai_visibility_topics 並傳入選定的 orgBrandId（省略 reportId 以獲取最新報告）。
對於每個主題，擷取：topicId、topicName、visibilityPercentage、averageRank、relevancyScore 和引用計數。
機會啟發法： 相關性 > 60% 且可視性 < 40% 的主題是您的金礦 — AI 模型認為它們對品牌類別至關重要，但幾乎未提及該品牌。同時也標記競爭對手領先 20 個百分點以上的主題。
步驟 3 — 深入探討 Prompt
對於前 3–5 個機會主題，使用 get_ai_visibility_prompts 並傳入 topicId。尋找：
- 品牌可視性為 0% 或非常低的 Prompt
- 競爭對手主導回應的 Prompt
- 回應次數高的 Prompt（更多 AI 回答 = 更多引用機會）
如果可用，使用 get_ai_visibility_prompt_responses 來讀取最弱 Prompt 的實際 LLM 生成答案 — 這能準確顯示 AI 模型目前說了些什麼。這是撰寫更好答案的最佳簡報。
步驟 4 — 排序並呈現機會
呈現一個排序後的 3–5 個內容機會 的簡短清單：
| # | 主題 | 代表性 Prompt | Amplitude 可視性 | 頂尖競爭對手 | 內容類型 |
|---|---|---|---|---|---|
| 1 | ... | 「...」 | X% | 競爭對手 Y% | 登陸頁面 |
內容類型指南：
- 部落格文章 — 資訊型 / 比較型查詢（「什麼是 X？」、「X vs Y」、「X 如何運作？」）
- 登陸頁面 — 高意圖查詢（「最佳 X 工具」、「適用於 [使用案例] 的 X」）
- 常見問題集頁面 — 關於一個主題的相關問題集群
- 產品描述 — 功能特定的查詢，品牌應是此類查詢的權威來源
詢問：「您想先撰寫哪一個？」 等待他們的選擇。
步驟 5 — 生成內容草稿
為所選的機會撰寫一篇完整、可直接發布的草稿。不是骨架 — 是真實的句子、真實的內容。使用者應該能夠在今天就將其貼入 CMS。
務必包含
內容簡報（開頭）：
- 目標 Prompt / 問題
- 搜尋意圖：資訊型 / 導航型 / 商業型
- 主要受眾
- 競爭對手缺口：競爭對手說了什麼而品牌沒有？
- LLM 洞察：引用或改寫 AI 模型目前對此主題的說法
文章欄位：
slug— 對 URL 友好、富含關鍵字metaTitle— 50–60 個字元，包含主要關鍵字metaDescription— 140–160 個字元，摘要文章並包含行動呼籲
文章本文：
- H1 — 與目標 Prompt 緊密匹配
- 引言（2–3 段） — 鉤子、品牌權威、文章預覽
- 主體（3–6 個 H2 部分） — 全面回答；引用具體的產品功能並提供具體細節；包含數據或範例；每個部分應教授獨立有用的知識
- 常見問題集區塊（3–5 個 Q&A） — 從步驟 3 中提取密切相關的 Prompt；每個答案 2–4 句話；這些是 AI 模型最可靠引用的格式
- 內部連結（3–5 個建議） — 參考可能的頁面名稱或 URL 模式
- 行動呼籲 — 一個明確的下一步
讓內容被 AI 模型引用的技巧
- 在前兩句話中直接回答問題。AI 模型會引用直接回答問題的來源。
- 具體說明產品功能。「Amplitude 追蹤 X」勝過「我們幫助公司成長」。
- 公平地涵蓋競爭對手。承認競爭的文章排名優於假裝競爭不存在的文章。
- 使用 AI 模型使用的確切詞語。在您的 H1 和第一段中模仿 Prompt 的語言。
- 常見問題集區塊是您最強大的引用磁鐵 — 將其格式化為直接的 Q&A，而不是流暢的散文。
步驟 6 — 發布到 CMS
使用您在步驟 0 中學到的資訊。
如果 CMS MCP 已連接
直接建立草稿。請遵循此順序：
- 向使用者顯示 slug、標題和前 100 個字 — 詢問：「準備好將其以草稿形式推送到 [CMS] 了嗎？」
- 確認後，以
draft狀態建立草稿（未經明確指示，絕不設定為published）。 - 回報草稿 URL 或文件 ID，以便使用者能立即找到。
Sanity — 使用 create_documents_from_markdown 並傳入文章內容。將 _type 設定為使用者的部落格文章 schema（如果不確定請詢問：「您 Sanity schema 中部落格文章的文件類型是什麼？」）。僅在使用者明確要求發布時才使用 publish_documents。
Contentful — 使用 create_entry 並將 contentType 設定為匹配他們的部落格或文章類型。設定 fields.title、fields.slug、fields.body。保持 published: false。
HubSpot — 使用部落格文章建立工具並設定 state: DRAFT。在 API 呼叫中包含 meta description 和 slug。
WordPress — 使用 wp_create_post 並設定 status: draft。將 H1 對應到 title，文章主體對應到 content。
Ghost — 使用 create_post 並設定 status: draft。包含 slug、title、html 或 lexical，以及 meta_description。
Webflow — 使用 create_cms_item 並指定部落格 Collection。將欄位對應到 Collection 的 schema（如果 schema 從 context 中不明顯，請詢問使用者欄位名稱）。
如果尚未連接 CMS
如果使用者說「只要 Markdown」或尚未連接 CMS：
「這是您完整的 Markdown 文章 — 可以隨時貼入 [CMS]。當您準備好連接 [CMS] 時，我可以自動將未來的文章推送過去。」
輸出完整的文章作為一個乾淨、結構良好的 Markdown 區塊。
同時也說：「想讓我現在就幫您設定 [CMS] 連接嗎？大約需要 2 分鐘。」 如果是，則引導他們完成步驟 0 中的外掛程式設定。
總是輸出 Markdown 備份 — 即使 CMS 建立成功也一樣 — 以便使用者擁有他們可以自行控管的本地副本。