發布
軟體發布是一個同步化的發布事件，而不是單一的社群媒體貼文。高速發布透過精心編排發布前的名單動能、平台原生社群（Hacker News 的「Show HN」和 Product Hunt）以及創辦人的即時互動，將所有力量集中在 24 小時內爆發，以克服初始的演算法慣性。
1. 發布前與名單排序
在公開發布前建立動能，以確保發布當天的參與度：
- T-14 天（名單登陸頁面）：高轉換率的英雄文案、30 秒產品示範影片、電子郵件收集並提供推薦獎勵（例如：在 X/LinkedIn 上分享即可在名單中向前移動）。
- T-7 天（Beta 測試者動員）：邀請早期社群成員和重度使用者加入私人頻道，測試入門流程、尋找邊緣案例錯誤，並準備發布當天的真實回饋。
- T-2 天（素材最終確定）：凍結產品部署；壓力測試資料庫連線限制和 CDN 快取，以應對 10 倍的流量高峰；驗證自動化的交易電子郵件。
- T-0（發布時刻）：同步推送電子郵件名單、Product Hunt、Hacker News、X/LinkedIn 創辦人討論串以及相關的 subreddit。
2. Hacker News 「Show HN」 操作手冊
Hacker News 要求技術內涵、知識誠實，以及零行銷吹捧：
A. 標題慣例
- 格式：
Show HN：[產品名稱] – [簡潔、事實性的功能描述] - 良好範例：
Show HN：Skillary – 277 個代理技能，支援 SQLite FTS5 搜尋 - 致命反模式：
Show HN：革命性的下一代 AI 代理框架，改變一切（立即被踩或檢舉）。
B. 提交文字/創作者開場白
包含一個頂層文字區塊，涵蓋四個必要元素：
- 為什麼建立這個：導致建立這個工具或產品的特定開發者痛點或技術限制。
- 運作方式：架構、使用的語言、關鍵演算法和取捨（例如：「我們選擇 SQLite FTS5 而非向量資料庫，以實現在地化、零遙測的搜尋」）。
- 取捨與限制：清楚地說明該工具目前還「不」能做什麼。工程透明度能化解懷疑者。
- 尋求回饋：詢問特定的架構或 UX 問題：「好奇你們在 CI 工作流程中如何處理分支保護？」
C. 演算法衛生與規則
- 絕對不要徵求按讚：發送連結給朋友請求按讚，或在 Slack 中大量分享連結，會觸發 HN 的投票圈偵測器，導致貼文永久被懲罰。
- 參與留言：在 15 分鐘內回覆每個技術問題。將批評視為有效的工程資料。
3. Product Hunt 發布策略
A. 中繼資料規範
- 名稱：產品名稱。
- 標語：嚴格控制在 60 個字元以內。以利益為導向，零行銷術語（避免「AI 驅動」、「革命性」、「無縫」等詞彙）。
- 視覺素材：
- 縮圖：乾淨的 240x240px GIF 或標誌。
- 圖庫：1 個 30 秒的動畫示範 GIF/影片 + 4-5 張帶有清晰說明的截圖（1270x760px）。
- 定價標籤：準確標示為免費 / Freemium / 付費。
B. 當日行程（太平洋時間）
- 00:01 AM PT：產品在 PH 上線。
- 00:05 AM PT：創作者發布第一則留言：起源故事、主要功能、提供給社群的折扣/免費層級代碼。
- 07:00 AM PT：向發布前名單發送電子郵件，宣布發布消息。
- 09:00 AM PT：在 X 和 LinkedIn 上發布創辦人發布討論串，附上簡短的示範片段。
4. 發布日作戰室檢查清單
- 在專用螢幕上打開錯誤追蹤（Sentry）和伺服器 CPU/記憶體儀表板。
- 在生產環境中測試歡迎電子郵件、交易註冊 token 和付款 webhook。
- 即時聊天或專屬支援頻道設定完成，目標回應時間小於 5 分鐘。
關鍵規則
- 絕對不要在 Hacker News 或 Product Hunt 上人為徵求按讚；使用者的有機好奇心和真實社群參與是唯一可持續的成長動力。
- 確保產品具有未驗證的互動式試用區、互動式示範影片或開源儲存庫連結；將產品放在銷售電話之後會摧毀發布轉換率。
- 在發布當天立即修復阻礙入門的關鍵錯誤；在不打斷現有使用會話的情況下推送熱修復。
驗證檢查清單
- 名單電子郵件通知已撰寫、測試並排程。
- 「Show HN」標題和技術說明文案已撰寫，並清楚說明限制。
- Product Hunt 圖庫圖片、示範 GIF 和創作者留言已準備就緒。
- 基礎設施容量已驗證，可承受 10 倍流量激增而不崩潰。
- 已驗證登陸頁面、註冊和啟動流程的分析追蹤事件。
反模式
- 絕對不要在星期五或週末發布，如果目標是商業軟體買家；請選擇星期二到星期四發布。
- 絕對不要在公開留言區為批評者辯護；感謝他們的批評，並解釋技術原因。
- 絕對不要在未於行動裝置上測試完整的註冊和入門流程的情況下發布。