發布部落格文章
此技能協助撰寫用於發布產品消息的部落格文章。一篇出色的發布文章需達成三個目標：告訴你的受眾你發布了什麼及其重要性、在搜尋引擎中針對你的受眾正在搜尋的關鍵詞排名、以及在人們詢問你的產品能解決的問題時，被 AI 答案引擎引用。
文章類型
根據發布層級和目標受眾選擇合適的文章類型。
公告文章
最佳適用於：Tier 1 和 Tier 2 發布。主要受眾：現有用戶與潛在客戶。
結構：發布了什麼 → 為何重要 → 如何運作 → 如何開始。字數控制在 1500 字以內。讀者應能在閱讀後 5 分鐘內理解變更內容並開始嘗試。
技術深度解析
最佳適用於：Tier 1 開發者/技術產品的發布。主要受眾：評估是否採納的工程師。
結構：問題 → 方法 → 架構/實作 → 基準測試 → 開始使用。篇幅可較長 (2000-3000 字)。包含程式碼範例、架構圖與效能數據。這是在 Hacker News 上會被分享的文章類型。
教學 / 「用 Y 打造 X」
最佳適用於：任何層級發布後的第一週內發布。主要受眾：剛聽說你並想親身體驗評估的開發者。
結構：我們要建構什麼 → 前置需求 → 逐步實作 → 成果。應能在 15-30 分鐘內完成。需包含完整可運作的程式碼，而非片段。
變更日誌條目
最佳適用於：Tier 3 發布或小型改進的彙整。主要受眾：現有用戶。
結構：每個改進以一個簡短段落說明。開頭直接說明什麼改變了，而非為何改變。連結至文件以獲取詳細資訊。建議每週或雙週彙整發布。
撰寫文章
從訊息簡報開始
若存在發布策略的訊息簡報，請使用它。主要價值主張成為文章的核心論點，次要價值主張則成為各章節。證據點則成為你貫穿全文的佐證。
若無簡報，請在寫作前先行定義：這篇文章寫給誰？他們現在能做些什麼？他們為何應該在乎？
以價值引領，而非過程
第一段必須回答「發布了什麼，以及為什麼這對我重要？」。切勿以你花了多少時間、有多少工程師參與或你的開發歷程開場。讀者不在乎你的過程——他們在乎的是自己的問題。
好的開頭： 「你現在可以透過單一 API 呼叫處理 14 種語言的音訊檔案。對於 10 分鐘內的檔案，延遲低於 200ms。」
不好的開頭： 「經過六個月的努力，我們的團隊非常興奮地宣布我們音訊處理平台的下一階段演進。」
展示，而非僅敘述
針對每個主張提供證據：
- 效能聲明 → 附有方法的基準測試數據
- 「易於使用」 → 5-10 行的可運作程式碼範例
- 「客戶喜愛它」 → 附有背景的具體引言
- 「比替代方案更好」 → 誠實的比較表格
包含可運作的範例
每篇技術產品的發布文章都應包含讀者可執行的程式碼。不是虛擬碼，也不是概念性片段——而是真正的、包含安裝指令、匯入語句和預期輸出結果的可運作程式碼。這是技術部落格文章中轉換率最高的單一元素。
以明確的下一步行動結尾
文章結尾必須只有一個行動呼籲（CTA）。「立即試用」、「閱讀文件」、「加入 Beta 版」。不是三個選項——只是一個。
SEO 優化
關鍵字定位
在動筆前選定主要關鍵字。它應符合你的目標受眾在遇到你的產品所能解決的問題時，會搜尋的詞彙。文章標題、H1 標題和第一段都應自然地包含此關鍵字。
對於發布文章，關鍵字通常是功能/產品名稱加上類別：「[產品] [類別]」（例如：「即時轉寫 API」或「開源功能開關」）。
頁面基本要素
- 標題標籤 (Title Tag)：包含主要關鍵字，字數少於 60 個字元。部落格文章標題應與 HTML 標題標籤密切匹配。
- Meta 描述：150-160 個字元，總結讀者將學到或能夠做到的事情。
- URL 縮寫 (URL Slug)：簡短、富含關鍵字，不包含日期（使其保持長青）。
- 標題 (H2/H3)：用於邏輯地組織文章結構。每個 H2 應是某人可能搜尋的問題或主題。
- 內部連結：連結到你的文件、相關部落格文章和著陸頁。從文件回連到這篇文章。
- 圖片替代文字 (Alt Text)：描述圖片內容，在自然的前提下包含相關關鍵字。
長尾關鍵詞排名內容
主要公告下方的章節——如何運作、技術細節、常見問題、比較——是長尾關鍵詞的目標。編寫它們以回答你受眾提出的具體問題。一個標題為「[功能] 如何處理 [邊緣案例]？」的章節，可以為該確切查詢進行排名。
AEO：答案引擎優化
AI 搜尋引擎（ChatGPT、Perplexity、Claude、Gemini 以及傳統搜尋中的 AI 驅動摘要）正成為人們發現和評估產品的主要方式。AEO 是一種結構化內容以利 AI 引擎在生成答案時引用的實務。
AEO 與 SEO 互補而非競爭。大多數 AEO 最佳實務也有助於 SEO。但有一些特定技術能使內容更易被 AI 引用。
為什麼 AEO 對發布文章很重要
當有人問 AI 助手「什麼是 [你的產品功能] 的最佳工具？」或「我該如何 [你的產品能完成的任務]？」時，你希望你的發布文章是 AI 從中提取資訊的來源之一。一次 AI 引用就能在發布日的流量消退後，持續長久地帶來發現機會。
讓內容可被 AI 引用
撰寫自成一體、可提取的段落。 AI 引擎引用段落而非整篇文章。你文章的每個章節都應能獨立理解，無需讀者先閱讀前文。一個明確陳述主張、用證據佐證、並提及你產品名稱的段落——這就是一個可被引用的單元。
以直接答案引領章節。 當一個章節處理一個問題（即使是隱含的）時，將答案放在第一句，然後再詳細說明。AI 引擎偏好能快速且具體回答的內容。
範例——與其這樣寫：
「選擇轉寫 API 時有許多因素需要考慮。延遲、準確度、語言支援和價格都扮演了重要角色。經過廣泛測試後，我們發現...」
不如這樣寫：
「[產品] 能以低於 200ms 的延遲轉寫 14 種語言的音訊，每分鐘僅需 $0.006。以下是基準測試的詳細分析...」
第二個版本可直接被引用。一個回答「最快的轉寫 API 是什麼？」的 AI 引擎可以直接抓取該句。
使用具體的量化主張。 AI 引擎偏好引用包含具體數據的內容：數字、基準測試、比較、百分比。「快速 API」不可引用，但「10 分鐘音訊檔案的 P99 延遲為 180ms」則可以。
包含結構化數據。 比較表格、功能矩陣和基準測試表格非常容易被引用，因為它們提供結構化、可提取的資訊。一個誠實比較你的產品與替代方案的表格，是最常被 AI 引用的內容格式之一。
使用真實問題編寫常見問題 (FAQ) 章節。 每個問題都匹配真實用戶會問 AI 助理的問題的常見問答章節，是引用的磁鐵。將問題寫成自然的 H3，然後在第一句直接回答。
針對 AI 引擎的 Schema 標記
Schema 標記為 AI 引擎提供機器可讀的內容上下文。在你的發布部落格文章中新增以下標記：
- Article / BlogPosting schema：告訴 AI 引擎這是一篇帶有特定作者和主題的日期文章。包含
headline、datePublished、dateModified、author和description。 - FAQPage schema：如果你的文章有 FAQ 章節，標記它以便 AI 引擎直接提取問答對。
- HowTo schema：如果你的文章包含教學或逐步指南，標記這些步驟。
- Product schema：如果文章發布的產品有定價，則包含帶有
name、description和offers的產品 schema。
你不需要全部使用——只需使用與你實際編寫的內容相匹配的即可。
內容時效性訊號
AI 引擎會權重建檔日期。未更新的頁面會隨著時間失去 AI 引用。對於發布文章：
- 在頁面上包含一個可見的「最後更新：[日期]」
- 每當你進行更改時，更新 Article schema 中的
dateModified - 每季重新檢視發布文章：更新基準測試、新增功能、更新程式碼範例
- 如果發布文章已過時，請更新它或將流量導向更新的文章——不要讓過時的內容繼續排名
實體與品牌訊號
AI 引擎會建立品牌和產品的內部模型。透過保持一致性來幫助它們：
- 一致地使用你的確切產品/功能名稱（不要在不同暱稱間交替使用）
- 明確陳述你的產品屬於哪個類別（例如「一個開源的功能開關平台」）
- 連結到關於你公司的權威來源（首頁、文件、GitHub、若適用的 Wikipedia）
- 確保你的產品在你的部落格、文件、著陸頁和社交媒體上描述一致
發布後檢查清單
發布後：
- 從各處建立連結：文件、著陸頁、變更日誌、相關部落格文章、README
- 在社群媒體上分享：使用 launch-tweet 技能來撰寫社群文案
- 提交到內容聚合平台：Hacker News、相關 subreddits、dev.to、Hashnode（針對技術文章）
- 發送電子郵件：包含在發布電子郵件或下期電子報中
- 監看問題：文章下方的留言、HN 討論串、Reddit——這些通常會揭示文章中的不足，你應透過更新來補救
- 發布週後更新：加入客戶故事、更新基準測試、修正讀者提出的任何問題
配套技能
- launch-strategy — 訊息簡報與發布規劃
- launch-tweet — 推廣文章的社群文案
- launch-email — 連結到這篇文章的電子郵件
- launch-video — 可嵌入文章中的示範影片和 GIF
- launch-distribution — 如何及在何處進行部落格以外的發布分發
- launch-landing-page — 部落格文章連結到的目標頁面
- launch-metrics — 為部落格文章連結設置 UTM，追蹤文章長期表現