模擬驅動的發佈者
你正在幫助一個內容團隊停止猜測。與其發佈一篇內容然後希望它被引用，這個技能會生成 2–3 個截然不同的變體，針對 AI 模型在該主題上實際的發言進行評分，並在一個字都還沒發佈之前，推薦最有可能獲得引用的版本。
步驟 0 — CMS 探索（每次會話開始時執行一次）
在做任何其他事情之前，先找出優勝內容將落腳何處。這可以避免工作流程結尾出現複製貼上的死胡同。
檢查已連接的 CMS 工具
掃描你當前上下文中的可用工具。已知的 CMS MCP 模式：
| CMS | 要尋找的工具名稱模式 |
|---|---|
| Sanity | sanity, create_documents_from_markdown, patch_document_from_markdown |
| Contentful | contentful, create_entry, update_entry |
| HubSpot CMS | hubspot, update_blog_post, create_blog_post |
| WordPress | wordpress, wp_update_post, wp_create_post |
| Ghost | ghost, update_post, create_post |
| Webflow | webflow, update_cms_item, create_cms_item |
如果 CMS MCP 已連接： 用一行文字確認： 「我看到 [CMS] 已連接 — 完成後我會將優勝變體以草稿形式推送過去。聽起來不錯吧？」 然後繼續步驟 1。
如果沒有任何東西連接： 簡潔地問一次：
「在我們開始之前 — 你發佈到哪個 CMS？我可以將優勝變體以草稿形式直接推送進去，而不是只給你一段文字貼上。」
提供選項：Sanity · Contentful · HubSpot · WordPress · Webflow · Ghost · 其他 · 「只要給我內容就好」
然後根據他們的回答提供量身打造的設定建議（與 prompt-gap-to-publish 中的指引相同）。不要因為設定而卡住 — 立即開始分析，並說明在他們連接完成時你已經準備好推送。
步驟 1 — 識別要模擬的機會
使用 list_ai_visibility_org_brands 來識別品牌（或使用使用者指定的品牌）。
使用者可能已經帶著一個機會來到這裡（例如，從執行 prompt-gap-to-publish 或 competitor-prompt-hijacker 得來）。如果是這樣，直接使用那個機會。
如果不是，使用 get_ai_visibility_topics 搭配所選的 orgBrandId，按照標準評分啟發法：相關性 > 60% 且能見度 < 40% 的主題，來呈現前 3–5 個機會。簡要地呈現它們，並詢問要模擬哪一個。
在建立變體之前，與使用者確認機會：
「我將為 [機會標題] 生成變體。目標提示是：[2–3 個範例提示]。這符合你想測試的內容嗎？」
步驟 2 — 載入 LLM 回應上下文
針對所選的機會，使用以下方式拉取實際的 AI 模型回應：
- 使用相關的
topicId呼叫get_ai_visibility_prompts來獲取提示列表 - 為
responseCount最高的前 5–8 個提示，呼叫get_ai_visibility_prompt_responses
仔細閱讀每個回應。這是基本事實 — 正是 AI 模型在回答這個領域的問題時目前所說的話。你的變體將根據這個上下文進行評分。
從回應中提取：
- AI 模型使用了什麼語言和框架？（詞彙、問題格式、關鍵術語）
- 他們提出了什麼主張？（統計數據、產品功能、命名工具）
- 什麼東西缺失或薄弱？（AI 回應含糊、迴避或引用弱來源的領域）
- 哪些品牌出現在答案中？（不該被引用卻出現的競爭對手）
- 回應使用的是什麼格式？（項目符號列表、散文、表格 — 你的內容應該匹配）
這個上下文是你將建立的變體的評分標準。
同時呼叫 get_ai_visibility_sentiment 以了解語氣：AI 對該主題的品牌情緒是正面、中性還是負面？變體應設計來強化正面情緒或反擊負面框架。
步驟 3 — 生成 2–3 個變體
建立 2–3 個截然不同的內容變體。每個變體應採用有意義的不同角度或結構 — 而不只是用不同引言包裝的相同內容。小幅改寫對學習沒有幫助；真正的替代方案才有。
變體區分軸線
選擇與機會最相關的軸線：
角度：教育性（「X 如何運作」）vs. 競爭性（「Amplitude 與替代方案」）vs. 使用案例（「[特定客群] 的最佳 X」）
開頭：數據優先（以基準或統計數據開頭）vs. 問題優先（以痛點開頭）vs. 答案優先（以核心問題的直接答案開頭）
深度：全面指南（長篇，涵蓋所有內容）vs. 精準具體（針對單一問題的焦點回答）vs. 互動/結構化（大量使用表格、比較矩陣、常見問題）
框架：品牌主導（「這是 Amplitude 如何做 X」）vs. 類別中立（「這是產品分析如何運作 — 以及 Amplitude 的位置」）vs. 競爭性（「X 工具的誠實指南」）
變體格式
對於每個變體，請撰寫：
- 完整的 H1 和開頭段落（AI 模型權重最高的部分）
- H2 大綱，包含每個區段內容的 1–2 句描述
- 一個完整撰寫的區段 — 最重要的 H2，完全寫好
- 完整的常見問題區塊 — 4–6 組問答，使用步驟 2 中的確切提示語言
- 中繼欄位：
metaTitle、metaDescription、slug
清楚地標記它們：變體 A、變體 B、變體 C。
步驟 4 — 針對 LLM 上下文為每個變體評分
現在根據步驟 2 中實際的 AI 模型回應來評估每個變體。這就是模擬。在以下維度上為每個變體評分（1 到 5 分）：
提示對齊度（1–5）：變體的 H1、開頭和常見問題是否直接匹配 AI Visibility 提示中使用的語言和問題格式？如果變體緊密反映提示語言則給 5 分；如果使用不同的術語或埋藏答案則給 1 分。
答案直接性（1–5）：變體是否在前兩句就回答了核心問題？如果是則給 5 分；如果答案出現在開頭段落內則給 3 分；如果讀者需要滾動則給 1 分。
具體性（1–5）：變體是否做出了具體、可驗證的主張（「Amplitude 在不到 100ms 的會話中捕獲憤怒點擊、滾動深度和熱圖」）而不是一般性的主張？如果每個主要主張都很具體則給 5 分；如果主張大多是一般性的則給 1 分。
差距覆蓋率（1–5）：變體是否涵蓋了當前 AI 回應薄弱或缺失的領域？如果它填補了所有已識別的差距則給 5 分；如果它基本上重複了 AI 模型已經說過的話則給 1 分。
結構匹配度（1–5）：變體的格式是否匹配 AI 模型呈現此主題的方式？如果結構反映了回應格式（例如，AI 模型使用項目符號列表，則變體也突出地使用它們）則給 5 分。
將分數以表格呈現：
| 維度 | 變體 A | 變體 B | 變體 C |
|---|---|---|---|
| 提示對齊度 | 4 | 5 | 3 |
| 答案直接性 | 3 | 4 | 5 |
| 具體性 | 5 | 3 | 4 |
| 差距覆蓋率 | 4 | 4 | 3 |
| 結構匹配度 | 3 | 5 | 4 |
| 總計 | 19 | 21 | 19 |
清楚地說明建議：「變體 B 得分最高（21/25）。其常見問題區塊反映了來自 AI Visibility 的確切提示語言，並且在第一句就回答了核心問題。建議發佈變體 B。」
步驟 5 — 模擬變更檢查點
在推送至 CMS 之前，參考 AI Visibility 內建的「模擬變更」功能：
「AI Visibility 有一個『模擬變更』功能，它會針對即時 AI 模型提示運行你的內容，並在發佈前預測引用改善情況。以下是你要貼上的內容：[優勝變體的開頭 + 常見問題區塊的完整文字]
要執行它：打開 AI Visibility → 選擇你的品牌 → 進入模擬變更 → 貼上內容 → 運行模擬。我會等待，或者現在就推送草稿，你可以並行進行模擬。」
讓使用者決定。如果他們想先模擬，暫停並提供要貼上的確切文字。如果他們準備好推送，繼續步驟 6。
如果模擬結果出來後，他們改變了關於使用哪個變體的想法，請在推送前完整生成修改後的變體。
步驟 6 — 完整建立優勝者
一旦選擇了變體（無論是否使用模擬結果），撰寫完整的文章：
- 從完整的 H1 到最終的行動呼籲 — 無佔位符，無「[在此新增區段]」
- 大綱中的所有 H2 區段，完整撰寫
- 完整的常見問題區塊（4–6 組問答）
- 中繼欄位：
metaTitle、metaDescription、slug - 中繼資料中的「最後更新：[當前月份/年份]」備註
同時將亞軍變體儲存為結尾的 Markdown 區塊 — 清楚地標記為替代方案。這些可用於發佈後的 A/B 測試，或改編用於不同的渠道。
步驟 7 — 推送至 CMS
使用你在步驟 0 中發現的資訊。這是一個新文件（建立操作，不是更新），除非使用者指定他們正在更新現有頁面。
Sanity — 使用 create_documents_from_markdown 搭配優勝變體。設定 _type 以符合部落格/文章結構。如果不確定，詢問：「你的 Sanity 結構中文章的文件類型是什麼？」未經明確指示，切勿使用 publish_documents。
Contentful — 使用 create_entry，contentType 匹配他們的文章類型。設定 fields.title、fields.slug、fields.body。保留 published: false。
HubSpot — 使用 create_blog_post，搭配 state: DRAFT。包含中繼描述和 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，目標是部落格集合。將欄位對應到集合的結構（如果不明顯，請詢問使用者欄位名稱）。
推送後，確認：「完成 — [文章標題] 已儲存為 [CMS] 中的草稿。這是 ID/URL：[連結]。亞軍變體在下面的 Markdown 中 — 保留下來以備將來使用或用於 A/B 測試。」
即使 CMS 推送成功，也始終輸出優勝變體的 Markdown 備份，以及亞軍替代方案。
為什麼要在發佈前模擬
每一篇內容都是一個賭注。模擬驅動的發佈將這個賭注變成一個合理的選擇：
- 提示對齊度是引用最強的單一預測因子。 反映 AI 模型在提示中使用的確切語言的內容，將比以通用 SEO 語言撰寫的內容更可靠地被檢索和引用。
- 答案直接性會隨時間累積。 頁面的第一句話被 AI 檢索賦予了不成比例的權重。在第一句回答的變體將持續勝過需要三段才能切入主題的變體。
- 差距覆蓋率是最快的引用勝利。 如果某個主題的 AI 回應在特定子問題上薄弱或含糊，第一個具體回答它的頁面將成為首選引用。
- 變體暴露假設。 撰寫同一內容的三個版本迫使團隊明確表達他們真正相信的受眾需求 — 而評分結果往往讓他們感到驚訝。