新品上市清單
上市的失敗更多來自被遺忘的細節而非壞產品：沒帶埋點上線的頁面、鏈到草稿 URL 的推廣、晚一個月才補的 metadata。清單是解藥，而自動化是自己會跑的清單。
每次上市都是同樣的二十步、同樣的依賴順序，而每次趕工的上市都會隨機跳過其中三步。這份 playbook 把步驟固定成三個階段——之前的就緒、之中的排序、之後的度量——讓第二十次上市和清單一樣完整，沒有任何一次依賴誰的記性。它是 Agent 作為常設程序所跑內容的手動版。
階段一：誰都沒見到之前就緒
上市前是徹底性最便宜的階段。頁面完整：文案回應上市定位、圖片排好、規格結構清楚、價格與庫存載入。度量接好：商品事件用一筆測試訂單驗證觸發、推廣 UTM 分配好。搜索層備好：metadata 寫好、結構化數據有效、來自相關分類與內容頁的內鏈與頁面同步上線。
頁面完整並對照上市 brief 審過——文案、圖片、規格、價格
埋點用真實測試交易驗證，不從模板想當然
metadata、結構化數據與暫存內鏈一起發佈就緒
上市電郵起草、分羣、排期完畢；客服已知曉產品
階段二：按依賴順序上市
上市日就是排序：頁面先上線並驗證（真人加載、加購、查看事件），然後內鏈與 sitemap ping，然後向高偏好分羣發公告，然後更廣的渠道。「頁面上線」與「第一封發送」之間的間隔是安全餘量——間隔裏發現的問題花幾分鐘；發送之後發現的問題花掉整場推廣。
階段三：第一週決定第二週
早期數據回答三個不同的問題，哪個失敗對應的動作不同：流量（有人來嗎——投放問題）、轉化（來的人買嗎——頁面問題）、放大（買的人評價和復購嗎——產品信號）。分開讀、第一週每天讀，把修復路由到擁有它的層，而不是憑感覺把整場上市重迭代一遍。
運作方式
走完就緒清單
頁面、埋點、搜索層與推廣各就各位——逐項驗證，不想當然。
排好上市日
任何發送之前先上線並驗證；高偏好分羣先於廣泛渠道。
每天讀三信號
流量、轉化與放大分開追蹤，修復路由到對的層。
你會得到甚麼
第一天就完整的上市，而不是補丁打一個月
因埋點先於流量而可信的第一週數據
幾天內被診斷到所屬層的問題
不再依賴記性的可複用序列
由這些 Agent 負責
可配合使用
常見問題
清單該提前多久啟動？
產品資料和圖片齊了之後，數字側的就緒是幾天不是幾週。長杆通常是素材質量——它一到位，下游一切可以並行。
新品該向全列表發嗎？
很少該。高偏好分羣先行：轉化更好、早期評價、頁面在大範圍曝光前的實測。頁面被驗證後廣發跟上——排序勝過羣發。
第一週表現不佳怎麼辦？
改任何東西之前先診斷三個信號哪個失敗了。流量弱轉化強是投放的事；反過來是頁面的事。甚麼都一起迭代，會毀掉這場上市剛付費買來的資訊。
哪些 Agent 跑這個？
全隊上，從一份 brief：Builder 管頁面，Analyst 管埋點與第一週解讀，Visibility 管搜索層，Retention 管排序發送。依賴順序由共享工作流強制——這正是清單自己會跑的原因。