---

name: product-launch-checklist language: zh-TW description: "為任何產品釋出生成完整的釋出前、釋出當天和釋出後檢查清單。當準備產品釋出、功能上線或重大更新時使用。產出分配到角色、按級別劃分的檢查清單，覆蓋工程就緒、市場與傳播、客服支援和釋出後監控。"

product-launch-checklist 的繁體中文翻譯，英文版本為規範版本。

產品釋出檢查清單

絕不在沒有逐項檢查的情況下發布。生成一份完整、分配到角色的檢查清單，覆蓋釋出前就緒、釋出當天執行和釋出後監控。

提議的操作

清單獲批後可以執行：把各項交給 action-runner，它會先預覽（試執行、標註風險），只透過已連線的操作類 MCP（GitHub / Linear / Slack）執行你批准的內容，並把做過的事記回大腦。典型做法：在指定的倉庫或專案中為每個檢查項開一個任務（🟡），以及把釋出摘要發到 Slack（🔴，需單獨批准）。這個技能只提議；由 action-runner 把關並執行，絕不悄悄進行。

所需輸入

如未提供，請向使用者詢問：

• 釋出名稱和計劃釋出日期
• 釋出級別（1 = 重大產品釋出，2 = 重要功能上線，3 = 漸進式更新）
• 團隊成員及角色（技術負責人、產品經理、市場、客服等）
• 功能描述（釋出的是什麼）
• 回滾能力（能否用功能開關控制，或快速回退？）

從大腦讀取 / 寫入大腦

如果存在 professional-brain（brain/），先用它再提問：

• 先讀： 要釋出的 entities/ 功能，以及相關的 decisions/（範圍、日期、負責人）。
• 之後寫： 把釋出決策和負責人記入 decisions/。這個技能也可以把清單交給 action-runner 去建任務，它會把實際做過的事記回大腦，形成閉環。

如何使用這個技能

提供：

• 釋出名稱和日期
• 釋出級別（1 = 重大，2 = 功能，3 = 漸進）
• 團隊成員及角色

這個技能生成分級的檢查清單。第 3 級釋出只用"基本項"部分。第 2 級增加"市場與傳播"。第 1 級使用全部部分。

---

輸出格式

釋出檢查清單：[功能 / 產品名稱]，目標日期：[日期]

釋出級別： [1 / 2 / 3] 釋出負責人： [產品經理姓名] 技術負責人： [姓名] 釋出決策截止： [日期和時間，通常為釋出前 24 小時]

---

🔧 釋出前：工程與產品（提前 2 周）

• 功能開關已建立並在預發環境測試
• 所有驗收標準已經產品經理確認
• 程式碼已評審併合入主幹
• 測試已簽字確認（迴歸 + 新功能）
• 效能測試已完成（負載、延遲）
• 安全評審已完成（如涉及資料或認證變更）
• 回滾流程已記錄並測試
• 監控和告警已配置
• 錯誤日誌已就位，嚴重級別正確
• 資料庫遷移已在預發環境用生產級資料量測試

📢 釋出前：市場與傳播（提前 1 周）

• 部落格文章已撰寫、審閱並排期
• 應用內公告或提示已配置
• 郵件活動已起草並檢查
• 社交媒體內容已起草並排期
• 落地頁或功能頁已在預發環境上線
• 媒體聯絡已發出（僅第 1 級）
• Product Hunt 或社群帖子已準備（僅第 1 級）

🎓 釋出前：銷售與客服（提前 1 周）

• 銷售賦能一頁紙已完成
• 常見問題文件已共享給銷售和客服團隊
• 幫助中心文章已撰寫併發布
• 客服團隊演示或培訓已完成
• 客戶成功團隊已就重點客戶做好準備
• 價格已更新（如適用）
• 合同或服務條款已更新（如適用）

📊 釋出前：資料分析（提前 1 周）

• 埋點事件在預發環境正確觸發
• 釋出指標看板已配置
• 基線指標已記錄
• 成功標準已記錄並共享給團隊
• A/B 測試已配置（如適用）

---

✅ 釋出決策：提前 24 小時

標準	狀態	負責人
所有嚴重缺陷已解決	🟢 / 🔴	技術負責人
測試簽字確認完成	🟢 / 🔴	測試
回滾已測試	🟢 / 🔴	技術負責人
幫助中心文章已上線	🟢 / 🔴	客服
監控已啟用	🟢 / 🔴	技術負責人
產品經理簽字確認	🟢 / 🔴	產品經理

釋出決策： [釋出 / 不釋出] 決策負責人： [產品經理與技術負責人共同]

---

🚀 釋出當天

• 為 [X%] 的使用者開啟功能開關（從低開始：5% 到 10%）
• 在團隊 Slack 或頻道確認已釋出
• 指標看板已開啟並持續監控
• 在釋出後 15 分鐘、1 小時、4 小時檢查錯誤率
• 部落格文章釋出 / 郵件發出
• 社交媒體內容上線
• 客服團隊在前 4 小時待命
• 產品經理全天可聯絡
• 釋出後 2 小時檢查透過則開關擴大到 50%
• 釋出後 4 小時檢查透過則開關擴大到 100%

---

📈 釋出後（第 7 天、第 30 天）

• 第 7 天指標回顧：採用率、錯誤、客服工單
• 第 7 天客戶反饋已彙總
• 覆盤已排期
• 經驗已記錄
• 第 30 天對照目標回顧成功指標
• 從程式碼庫移除功能開關（清理）
• 根據反饋把後續功能加入待辦列表

---

延伸材料

這個技能附帶支援檔案，可用時請使用：

• references/launch-tiering.md：釋出分級：讓儀式感與風險相匹配。在產出時應用它；它包含上面方法摘要壓縮掉的校準和判斷。
• templates/launch-plan.md：可填寫的成果模板，品質關卡寫在裡面。當使用者想自己完成文件而不是生成時提供。

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

維度	0	5	10
級別校準	沒寫級別，或清單深度明顯不匹配（改個文案卻用全套第 1 級流程，或新的收入線只有一份簡單清單）	寫了級別但沒有理由；部分內容的增刪與級別不一致	寫明級別及理由（定價、法務、影響範圍，而不是工程工作量），各部分與級別匹配，級別上的分歧有記錄地解決
負責人與時間	檢查項和關口由"團隊"或沒人負責；沒有日期	大多數項目有負責人，但關鍵關口（釋出決策、擴量、覆盤）缺少具名個人或具體時間	每個檢查項、關口和決策都有一個具名個人和日期時間，包括設在釋出前約 24 小時的釋出決策時間
回滾與分階段上線	沒有回滾計劃，或第一天開關就全量	回滾有記錄但沒有測試；有分階段，但擴量步驟沒有透過標準	回滾經過測試，回退時間已知（"X 分鐘，於 [日期] 測試"），開關按 5% 到 10% → 50% → 100% 分階段，每次擴量都以具名的檢查為關口
釋出決策的誠實度	沒有關口，或關口只是走過場：預設全綠，被阻塞的工作也打了勾	有關口和標準，但被阻塞的項目被淡化、狀態過於樂觀，或"不釋出"沒有修訂計劃	狀態誠實（紅色寫明阻礙和負責人），即使意味著推遲也按表決策，"不釋出"會產生帶日期的重新決策，並在釋出時就約好覆盤

品質檢查

• 生成清單前確認了釋出級別（範圍決定深度）
• 釋出決策有具名負責人和具體決策時間
• 回滾流程已記錄並測試（而不只是計劃）
• 功能開關分階段擴大（5% → 50% → 100%），而不是一次全量
• 釋出時就約好了釋出後覆盤

反模式

• 不要對漸進式更新使用第 1 級清單：生成清單前先恰當地給釋出分級
• 沒有確認的週末工程值守，不要在週五釋出
• 不要把釋出決策負責人寫成"團隊"：必須是具名個人
• 第 1、2 級釋出不要跳過回滾計劃：上線前就知道回退時間
• 不要在沒有約好釋出後覆盤的情況下結束髮布：必須在釋出時就約好，而不是之後

指南

• 釋出決策必須有具名負責人："團隊"不是負責人
• 除非有周末工程值守，否則絕不在週五釋出
• 建議所有釋出都從不到 10% 的流量開始，即使是簡單功能
• 記錄回滾時間："我們可以在 X 分鐘內回退"應該在釋出前就知道

示例觸發語

• “準備產品發表。”
• “給我一份上線當天的檢查清單。”
• “規劃功能上線。”
• “大版本上線前還缺什麼？”