AI 專案不是死在技術不行，是死在範圍蔓延

很多管理者第一次看到 AI 把一條流程真的跑通，心裡第一個反應不是「先把這條守住」，而是「那順便把第二條也接上，第三條也一起做」。這個反應很自然，因為大家都想放大成果、快點看到規模效益。但現實通常相反：第一條流程剛穩定，就急著往外擴，往往不是加速，而是把原本可控的成果重新拖回混亂。很多 AI 專案最後不是卡在模型不夠強，也不是工程團隊不夠會做，而是死在管理端沒有守住範圍。

範圍蔓延通常很早就有徵兆。第一個信號，是團隊開始頻繁出現一句話：「順便也讓 AI 做這個。」只要「順便」變多，代表專案已經從解決一個明確問題，滑向收集一堆未排序需求。第二個信號，是同一個人開始同時盯超過三條流程。這種安排表面上像資源整合，實際上常常讓 review、排錯、驗收全部擠在同一個人身上，最後每條都看不深。第三個信號，是當你問團隊「現在到底有幾條流程在跑」，沒有人能在一分鐘內回答清楚。只要流程數量、狀態、owner 都說不明白，專案基本上已經不是在擴張，而是在失控。

為什麼範圍蔓延比技術失敗更危險？因為技術失敗通常是局部問題。模型效果差，可以重調 prompt；串接失敗，可以補監控；流程不穩，可以回頭修 SOP。這些問題雖然煩，但至少邊界清楚，知道該修哪裡。範圍蔓延不一樣，它會把人力、注意力、預算和決策焦點一起打散。原本應該把一條流程打磨到穩定的人，被拉去救另一條半成品；原本應該被驗證的 KPI，被新的需求不斷往後推；原本可以複製的成功案例，最後變成五條都不完整、誰都不敢正式擴張的尷尬狀態。技術壞了可以修，節奏亂了通常更難收回。

所以管理 AI 專案，真正要守的不是「多快上更多功能」，而是「一條做完再加一條」的紀律。這裡至少有三個門檻不能省。第一，KPI 要先達標。不是 demo 能跑，也不是偶爾成功，而是明確指標連續穩定達標，像是處理時間、成功率、人工節省比例都過線。第二，SOP 要先寫好。沒有文件化的操作、例外處理和交接方式，代表這條流程還是靠人撐，不算真正完成。第三，review owner 要確認自己有空。沒有人能在 already overload 的情況下，再多接一條流程還維持品質；如果 owner 沒空，就不是開新線的時機。

管理者最容易犯的錯，不是低估 AI 技術，而是高估組織同時消化多條變更的能力。你以為自己在擴張，實際上可能只是在製造更多待修清單。把一條流程做實、做穩、做成可複製，價值遠高於同時掛著五條半成品。AI 專案要跑得久，不靠衝動加需求，而靠紀律守範圍。先把一條做完，再談下一條，這不是保守，是效率。