AI 原生媒體團隊嘅 90 日 rollout，係將 campaign 生命週期入面一個階段端到端重建，而唔係啟動五個階段。第 1–30 日整好個 constraint、令一份 brief 變得 machine-readable；第 31–60 日跑嗰個階段、由 model 產出第一 pass 並建立 review standard；第 61–90 日 measure，帶住證據決定擴唔擴展。
我見過團隊試圖靠買工具、搞 workshop 喺一季內變成 AI 原生，亦都見過團隊靠靜靜雞重建一條 workflow、俾個結果去論證下一條。第二組人更少，走得更遠。呢個就係嗰 90 日嘅形狀，按我會為一個有真實客戶負荷嘅真實團隊排序嘅方式寫出嚟。
點解係 90 日同一個階段
時間線唔係隨意嘅，範圍亦都唔怯。佢係產得出可信證據嘅最細單位。
90 日足夠令一個階段跑過幾個真實週期——幾份週報、幾場 campaign、幾份 brief——所以個結果唔係「順利嗰個禮拜嘅一次 demo」。佢又短到停留得到喺一個 project 而非一個轉型 project，呢個好重要，因為轉型 project 往往喺產出任何嘢之前就冇咗 budget。
一個階段係單位，因為巡遊問題會懲罰局部重建。整好一個階段但唔理佢啲鄰居，收益就由側面漏走。但將一個階段完整咁重建，證明到個方法、並俾咗你去下一個階段嘅內部理由，噉比五個半成品 pilot 更有價值。
第 1–30 日：揀 constraint，整 brief
第一個月係診斷同設計，唔係工具。
揀個 campaign 到最後仲喺度等嗰個階段——通常係 reporting、research 或者 brief。然後寫低嗰個階段嘅「好」係咩樣，並令個輸入 machine-readable。如果係 brief，噉意味住方向、audience、brand rules 同成功 metric，以人同 workflow 都用得到嘅形式。如果係 reporting，噉意味住數據源、關聯方式同 anomaly 閾值預先定義好。
第一個月嘅產出唔係一個運行中嘅系統。佢係一頁設計：階段、owner、machine-readable 嘅輸入、標準，以及你用嚟判斷成功嗰項 measure。如果你冇辦法將佢寫喺一頁上面，個階段太大——拆開佢。
第 31–60 日：跑佢，並建立標準
第二個月係 workflow 真正運行、同 review standard 以艱難方式建立起嚟嘅地方。
跑嗰個階段，俾 model 產出第一 pass：佢生成 report 敘述、research 綜合或 plan 選項，一個人對住個標準 review。預計頭兩個禮拜會好粗糙——份 brief 會比你以為嘅更含糊，而個 review 會捉到啲標準冇預料到嘅嘢。嗰個正係攞真實工作而非測試 campaign 嚟跑佢嘅意義。
第二個月嘅交付物係一份用得到嘅標準：咩自動檢查、咩人一定要睇、例外點處理。寫低佢，因為一份住喺一個人腦度嘅 review standard 唔係標準，係一個樽頸。呢個亦都係你了解到個階段實際需要幾多 review 能力嘅月份——幾乎總比第一版 plan 假設嘅更多。
第 61–90 日：measure，然後決定
第三個月係 measurement 同一個決定，亦都係冇耐性嘅團隊會跳過嘅部分。
喺兩樣嘢上比較個階段嘅前後：cycle time 同質素。份工作係咪真係早咗完成、錯誤或返工率有冇升？一個更快而更多錯誤嘅階段唔係勝利；嗰個係你仲未付出嘅風險。一個更快、質素持平或更好嘅階段，先係你擴展所需嘅證據。
然後誠實咁做三個判斷之一。如果啲數字好，攞下一個階段——但一次一個，用同樣嘅設計。如果啲數字參半，喺擴展之前整好個標準或者份 brief，因為個方法係可靠嘅、執行唔係。如果啲數字差而你講唔出點解，停低、寫低你學到咗咩；噉比擴大一條壞咗嘅 workflow 更平。
三個階段一眼睇
| 階段 | 目標 | 主要產出 | 成功訊號 |
|---|---|---|---|
| 第 1–30 日 | 診斷同設計 | 一頁設計：階段、owner、輸入、標準 | 你喺一頁上講得出個階段同佢嘅 measure |
| 第 31–60 日 | 運行同標準化 | 一份用得到、寫落嚟嘅 review standard | 個階段喺真實工作上跑得到，唔使英雄主義 |
| 第 61–90 日 | Measure 同決定 | 關於 cycle time 同質素嘅證據 | 一個站得住嘅「擴展、修正或停止」決定 |
訊號嗰一列係你要要求自己做到嘅部分。每個階段都有一條話你知應唔應該繼續嘅問題，而佢哋都唔係「佢感覺似進步咩」。
會殺死 rollout 嘅陷阱
將個海煲滾。 團隊一次重建三個階段，因為佢哋都好痛。巡遊問題會保證個 constraint 原地不動，而力氣攤得太薄，咩都證明唔到。一個階段。
工具先行。 個 rollout 由一張採購清單開始，而唔係一次 workflow 診斷。你最終得到一個 AI 輔助嘅團隊同一張更大嘅 software 賬單，亦都係AI 原生 vs AI 輔助嘅區分所描述嘅嗰種失敗。啲工具喺個設計嘅下游。
冇點名嘅 owner。 一個由「團隊」擁有嘅 rollout，邊個都唔擁有。一個人擁有個階段、個標準同啲證據，而嗰個人有權改變個階段點跑。
跳過個標準。 團隊自動化咗產出，卻將 review 保持喺非正式狀態。噉會一直管用，直到第一個錯誤到咗客戶，然後個 rollout 冇咗佢嘅 sponsor。喺擴量之前定義個標準。
邊個應該嚟跑佢
你需要一位 senior sponsor 同一個肯做 pilot 嘅團隊。Sponsor 保護呢 90 日唔俾其他工作徵用；pilot 團隊喺真實 campaign 上做重建。你唔需要喺開始前攞到全組織嘅對齊——等佢係一條花成年喺 slide 上面嘅常見路徑——你亦都唔需要工程團隊，除非某個真嘅 integration 開始回本。
Pilot 團隊應該有擁有份工作嘅 operator、一個認真對待得到數據嘅人、以及一個會喺產出唔夠好時誠實話你知嘅 reviewer。最後嗰個角色容易俾人忘記，而佢正係令個 rollout 保持誠實嗰個。
90 日時成功係咩樣
到季尾，成功係刻意適度、亦都異常紮實：一個階段喺真實工作上跑成 AI 原生，有一份寫落嚟嘅標準同一位點名嘅 owner；你展示得到佢慳咗嘅 cycle time 同守住嘅質素；而且你有一個站得住嘅理由去攞下一個階段。
噉唔係一場轉型。佢係轉型嘅一個跑得到嘅雛形，比一份 roadmap 更有價值，因為佢係證據而唔係意圖。Execution 指南係呢次 rollout 所處嘅完整地圖，面向 team lead 嘅 lane為第一個之後嘅階段排序。
FAQ
點解係 90 日而唔係 30 或 180？
30 日太短，令唔到一個階段跑過幾個真實週期，所以個結果係一次 demo 而唔係證據。180 日會將份工作變成一個冇咗勢頭同 budget 嘅 project。90 日係產出可信證明嘅最細單位。
我哋需要先揀最難嗰個階段咩？
唔使——揀個 constraint，亦都係個 campaign 最後仲喺度等嗰個階段。佢通常係 reporting、research 或 brief，而唔係咩光鮮嘅嘢。個 constraint 係 cycle time 所在，整好佢先係為其餘部分做出論證。
如果個 pilot 失敗咗呢？
一個失敗卻俾出誠實原因嘅 pilot，比一條你解釋唔清、已經擴大咗嘅 workflow 更平。寫低階段、brief 或標準錯咗喺邊，整好佢，喺同一個階段上再跑一次 90 日。個方法係可靠嘅；大部分失敗係執行，唔係概念。
邊個擁有呢次 rollout？
一位 senior sponsor 同一位階段 owner。Sponsor 保護時間；owner 擁有標準同證據。一個由「團隊」擁有嘅 rollout 邊個都唔擁有，一個月內就會俾其他工作徵用。
短版
一次 90 日 AI 原生 rollout，係一個階段被端到端重建：第 1–30 日診斷同設計份 brief，第 31–60 日運行同建立 review standard，第 61–90 日 measure 同決定。一個階段、一位 owner、擴展之前先有證據。陷阱係將個海煲滾、由工具開始、冇 owner、跳過標準。Execution 指南係更寬嘅地圖。
我跑過想做得太多嘅 rollout，亦都跑過做得太少嘅，而管用嘅永遠係嗰啲喺掂下一個之前先將一件事證明紮實嘅。
如果你嘅團隊喺度規劃一次 rollout，我好想聽下你揀咗邊個階段、點解——嗰個選擇通常預示到佢會唔會企得穩。
Cheers, Chandler
本文提供繁體中文（香港）版本。課程材料（影片、template同配套指南）以英語同日語提供。本網站提供13種語言版本。