巡遊問題係一種失敗模式：你將 AI 加到一個從來冇重建過嘅 workflow 上面，得到一段更快嘅起步同後面一模一樣嘅樽頸。個巡遊仍然以嗰架快花車身後最慢嗰件事嘅速度抵達。你喺前端感受到速度，喺終點一啲都感受唔到。
我俾佢改呢個名，係因為佢係 AI 採納入面最平嘅錯誤，亦都最難睇見。你跑一個 pilot，有人喺幾分鐘內示範一個兩百個 variant 嘅 creative generator，全場拍手，六個禮拜後個 campaign 又遲咗。個 generator 冇任何問題。底下條路線從來冇被掂過。
我喺廣告業做咗 19 年，最近幾年將同一份工作用 AI 重新砌一次。以我經驗睇，卡住嘅團隊幾乎從來唔係卡喺 model 質素上面。佢哋卡喺一個將 AI 當成一個「環節」、而唔係「默認」嘅 workflow 上面，於是機器一交返個結果，收益就由側面漏咗出去。等我指俾你睇漏喺邊。
巡遊問題係咩樣
想像一場真實嘅巡遊。領頭花車靚又快。後面係步操樂隊、十幾架更慢嘅花車，仲有一隊按自己節奏行嘅清潔隊。如果你將領頭嗰架花車換成一架火箭車，個巡遊唔會早啲抵達。火箭只係衝前咗，喺樂隊追上之前拉出一段更大嘅空隙。
一個 media workflow 就係嗰場巡遊。Research 餵俾 planning，planning 餵俾 activation，activation 餵俾 reporting，reporting 餵俾下一輪 research。加速一個階段，你唔會縮短個巡遊——你只係拉闊咗嗰個階段同佢鄰居之間嘅空隙。唯一縮短得到個巡遊嘅，係搬動「最慢」嗰個階段，而最慢嗰個階段幾乎從來唔係被示範嗰個。
點解快花車會整出個空隙
呢件事有個樸素嘅理由，唔係技術問題。係 constraint 問題。
每個 workflow 都有一個決定節奏嘅階段，而佢通常最唔起眼：一次簽批、一次數據拉取、一次客戶 review、一份從來冇被決定嘅 brief。將 AI 加喺 constraint 嘅上游，產生嘅係在製品，唔係產出。你生成嘅原材料超出咗下一階段吸收得到嘅量，多出嚟嘅材料排隊、老化、俾人返工。
呢個就係點解 AI pilot 成日報「某一步快咗」同「cycle time 持平」。嗰一步係快咗。個 constraint 冇郁。而因為真正嘅成本住喺 constraint 度，個業務結果差唔多冇變——呢個時候懷疑者開始講「早就話咗你」，budget 靜靜咁消失。
Pilot 之後仍然生存嘅四個樽頸
由我觀察過嘅 pilot 睇，樽頸幾乎總係落喺四個地方之一。佢哋都唔係 model。
- 未被決定嘅 brief。 Model 忠實咁產出咗兩百個版本嘅一個冇人答過嘅問題。樽頸喺生成嘅上游，喺嗰個本應由 brief 編碼嘅決定度。
- 審批隊列。 一個人類 reviewer 可以仔細讀十幾個 variant，或者粗粗咁讀一百個。如果個 workflow 而家產出上百個，而 review 能力冇變，你移動嘅係嗰堆嘢，唔係份工作。
- 數據交接。 份 report 幾秒鐘生成，然後等三日，等人去核對嚟自兩個互相唔一致嘅系統嘅數字。生成從來唔係慢嗰部分。
- 整合接縫。 產出住喺一個工具度，下一階段住喺另一個工具度，於是有人喺佢哋之間複製貼上。嗰次複製貼上而家變咗條生產線。
留意呢個模式：四個入面有三個係關於「邊個喺等、咩喺等」，而唔係關於智能。你用 prompt 繞唔過一條審批隊列。
我不斷返去嗰個故事
我最清楚嘅例子，係一個團隊砌咗一個 AI copy generator，幾分鐘產出上百個 headline variant。佢確實令人印象深刻，個個都好開心。然後個 campaign 表現依然唔好。
樽頸從來唔係 headline。而係冇人決定個 campaign 喺度打邊一個 message。個 generator 盡職咁產出咗「未決 brief」嘅上百個版本，而團隊花喺爭論 message 上嗰兩個禮拜，同佢哋冇工具嗰陣花嘅一模一樣。AI 移走咗平嗰個階段，留低咗貴嗰個。
等團隊花一個禮拜將份 brief 變得 machine-readable——一個揀定嘅 message、brand rules、audience、metric——同一個 generator 就變得有用了，因為呢個時候有個方向可以對住佢生成。個工具一啲都冇變。變嘅係條路線。
「重新設計條路線」到底係咩意思
重新設計條路線唔係一場宏大嘅轉型 project。佢係四個具體動作，而你可以一個一個階段咁做。
- 喺生成之前先決定份 brief。 將方向明確咁寫落嚟，令第一 pass 有真實嘅嘢可以放大。
- 移動 review，而唔只係產出。 如果 model 產得多啲，review 能力就要改變形狀——抽樣、結構化檢查、一個清楚嘅標準——否則量就變成風險。
- 將 context 擺喺 workflow 掂得到嘅地方。 Brand rules、audience 同歷史應該隨住個 task 一齊移動，而唔係住喺一個 senior 員工嘅腦度。
- 堵住複製貼上嘅縫。 任何一個人喺兩個工具之間手動搬運產出嘅地方，都係一個偽裝成「某人嘅工作」嘅樽頸。
做呢四件事，個巡遊就郁。跳過佢哋，你只係買咗架快啲嘅花車。
點樣診斷你自己嗰場巡遊
喺建議任何 AI 投入之前，我用一個刻意直白嘅測試。
問：邊個階段最後完成？ 唔係邊個階段起步最慢——而係個 campaign 到最後仲喺度等邊個階段。嗰個階段就係你嘅 constraint，亦都係如果你想 cycle time 郁、AI 一定要先去嘅地方。
再問第二條問題：當 AI 完成，人會攞份產出做咩？ 如果誠實嘅答案係「全部讀完、揀、重排格式、再往下貼」，噉你就搵到下一個樽頸。第一 pass 快，如果第二 pass 同以前一樣，噉價值好細。
你可以由一個階段開始
好消息係：巡遊問題支持一個細而樸素嘅開始，而唔係一個大開始。
揀嗰個 constraint——通常係 reporting、research 或者 brief——只重建嗰一個階段，俾機器產出第一 pass、人似 review 一位 junior 咁 review。Measure 嗰個階段喺前後各自嘅 cycle time。如果佢郁咗，你就攞到「呢個方法得」嘅證據，亦都有咗去掂下一個階段嘅理由。如果佢冇郁，你就以自己嘅營運為代價、便宜咁學到咗嘢。
呢個就係Strategy 指南為成條 lane 所做嘅排序論證，亦都係template存在嘅原因：一份 machine-readable 嘅 brief 同一個 review standard，係將「一個快階段」變成「一場快啲嘅巡遊」嘅兩件產物。一個階段做紮實，比五個階段做一半更教你到嘢。
FAQ
巡遊問題淨係一個變革管理問題咩？
部分係，但主要唔係。變革管理關乎採納——人係咪用個工具。巡遊問題關乎設計——個 workflow 吸唔吸收得到個工具嘅產出。一個俾完美採納嘅工具，外掛到一條唔變嘅路線，仍然會產出同一個樽頸。
噉係咪話將 AI 疊喺舊 workflow 上面從來冇用？
佢喺邊角處幫得到手，噉都有佢嘅價值。但收益俾身後嗰個 constraint 封頂。如果目標係實質咁快啲縮短為 campaign cycle，條路線就要變；如果淨係某一步驟快少少，外掛就夠。
我點樣快速搵到我嘅 constraint？
問個 campaign 到最後仲喺度等邊個階段，而唔係邊個階段起步最慢。有隊列嗰個階段就係 constraint。佢通常係一次審批、一次數據核對、或者一份未決嘅 brief，而唔係任何技術性嘅嘢。
我需要一次過重建每個階段咩？
唔使——恰恰相反。端到端重建一個階段，measure cycle time，然後先至繼續。將一個階段做紮實，俾你去下一個階段嘅證據；將五個階段做一半，俾你五個新樽頸。
短版
巡遊問題就係「快速嘅起步」同「唔變嘅樽頸」之間嘅空隙。將 AI 疊喺舊 workflow 上面，加速嘅係架花車而唔係個巡遊，因為 constraint 坐落喺佢身後，而且好少喺示範發生嘅地方。修復唔係更好嘅 model。而係決定份 brief、移動 review、將 context 擺喺 workflow 掂得到嘅地方、堵住複製貼上嘅縫——一個階段一個階段咁嚟。
我仲喺公開咁學呢個領域，而我在兩個方向上都錯過：曾經喺工具上過度投入、喺路線度投入不足，而條路線從來都係貴嗰部分。所以我會繼續問嗰條直白嘅問題——邊個階段最後完成？
如果你見過一架快花車冇令到你嘅巡遊郁，我好想聽下個樽頸最後落喺邊。
Cheers, Chandler
本文提供繁體中文（香港）版本。課程材料（影片、template同配套指南）以英語同日語提供。本網站提供13種語言版本。