「還要多久？到底還要多久才會修好？客戶下午就要出單了，你這套系統我能不能先關掉？！」
話筒那頭傳來現場生管與廠長著急的詢問。
在專案摸底的十四天裡，走過前面的數據盤點、特徵工程與模型架構，許多團隊總以為只要離線指標漂亮，就能順理成章上線。但我常提醒同仁：一套系統能不能真正活在產線上，從來不是看它正常運作時有多聰明，而是看它暴斃時由誰來收拾殘局。
當伺服器當機、模型推論吐出 Error 500、現場突發非典型工況時，如果沒有清晰的退場與接管機制，再精巧的演算法，最終換來的也只會是現場一句無奈的評語：
「太複雜、很麻煩，現在流程不是這樣做的，這東西根本沒人要用。」
很多人談到系統上線，腦袋裡只有一條理想化的全自動輸送帶。但實務上最核心的工程拷問是：你這套系統的「適用邊界」到底畫在哪裡？在什麼非典型工況下，它必須主動舉手投降、交出控制權？
定義適用邊界，本質上就是在定義「錯誤處理程序（Error Handling Procedure）」——明確切分出哪些異常是演算法該扛的物理擾動，哪些狀況是系統必須立刻退出並交還人工接管的極限。
在石化與連續製造現場，最經典的爭議就是「停開車與規格切換」。
很多技術團隊為了衝高模型的準確率，恨不得把所有非穩態的資料全部當作離群值剔除。但現場必須分清兩種狀況：
如果是專案承諾要解的「動態過渡帶」（例如產線正常的升降載切換、原料轉規格）：這本來就是製程的一部分，模型必須透過工況狀態變數去學會擬合，不能偷拔數據裝作沒這回事；
但若是超出物理定義的「極端非典型工況」（例如全廠突發跳電、反應槽安全閥跳脫、原料嚴重斷供）：這已經脫離了歷史分佈的經驗海域（Out of Distribution）。
真正的錯誤處理程序，不是讓黑盒子在未知海域裡硬著頭皮瞎猜、胡亂下發危險的控制指令；
而是在識別出「超出適用條件」的那一秒，系統能否平滑降級為保守控制、凍結當前輸出（Hold）或切回預設安全基線（Fail-safe Default），並主動跳出告警交給操作員介入複判。
這種非穩態的退場判定，絕不能靠事後開檢討會互相推諉，必須在架構上白紙黑字寫好——是由系統發出具備時間戳記的狀態握手訊號（Handshake）主動退出，還是由中控室操作員手動確認交割。
所謂故障排除手續，起點不是出事後去翻系統日誌，而是打從一開始就界定清楚系統的物理射程。
更隱蔽的危險徵兆，來自於「系統內一切正常，但整體作業徹底崩潰」。
正如我們在第八章反覆強調過的：數位轉型是一道殘酷的相乘題——由數據與演算法相加的技術基礎，去乘上第一線的商業整合。 既然是相乘，只要商業整合與現場流程徹底脫鉤，那個乘數就是大寫的零，前面的技術再強也是白搭。而商業整合最大的盲區，就是只顧自己、不顧上下游的「跨單元斷裂」。
在專案後期，如果這套系統的檢討會議「始終只有單一部門在開」，這案子大概已經半截入土了。
化工領域講究跨單元整合，軟體領域稱之為業務閉環。
有些團隊高興地宣稱：透過演算法最佳化，前段反應槽的產能成功提升了 20%！但他們沒看到的是，後段的包裝線人手根本跟不上，儲槽直接滿溢爆倉；或者前段為了增產拼命衝量，下游出貨碼頭卻完全塞死。
經驗老到的現場師傅看到下游快滿了，會懂得手動收油門；但缺乏外部連鎖防護的演算法，卻只會盯著自己的局部最佳化無腦硬催。
這時的錯誤，根本不是演算法本身算錯，而是系統缺乏「外部異常的連鎖防護機制（Cascading Failure Protection）」。
更深層的病灶，往往在於跨部門的利益與 KPI 脫鉤：前段單元只在乎把自己的增產指標刷滿、拿專案績效，後段單元卻得在塞車的泥淖裡加班收爛攤子。
當下游儲槽已亮起高液位警報、後段包裝機台卡死跳車時，前段的 AI 系統有沒有接入這些外部訊號？它有沒有寫入自動踩煞車的降級節流迴路？
如果系統在外部工序瀕臨崩潰時依然盲目衝量，這種只顧局部的優化，帶給工廠的只會是一場連鎖災難。
現場本質上永遠是人在運作，再精密的演算法、再昂貴的伺服器，也沒人能保證它 100% 永遠不當機、網路永遠不斷線。
那麼，當系統突發狀況時，現場能不能「無痛切換回去」？甚至比以前更方便一點？
在第一線，使用者常提出一個看似土炮的需求：
「工程師，你這套系統排出來的結果，能不能讓我一鍵存成 Excel 或 Word 檔？」
這並不是排斥自動化的退步要求，相反地，這是一個實務上非常高明的運維緩衝設計（Fallback Mechanism）：
常態下的「人機微調空間」：系統自動運算、出表，並產出結構化的檔案，讓現場調度員能在數秒內手動覆核、微調少數幾筆特殊例外，而不是逼人面對不可更動的黑盒直下指令；
暴斃時的「安全基線底稿」：系統平時有沒有將推論結果即時落地為離線快照（Snapshot）？確保後台服務就算突然卡死或網路中斷，現場手頭依然能留有一張上一期的安全基準底稿，直接由人工接管、繼續手動派工。
這才是數位化的價值：不是把人逼進死胡同，而是在系統倒下的那一刻，現場依然能站在既有的運算基礎上把作業維持下去。
一套能活在現場的系統，在架構設計的第一天，就必須把「人機協作比率」想得清清楚楚。
系統的設計必須具備彈性，機器的角色可以很重，也可以很輕。在實務架構上，通常需要預留三種階梯式的切換模式：
全自動模式：工況常態穩健時，系統全自動推論並直接下發控制指令，機器角色最重。
建議模式：工況出現擾動或需要現場經驗時，系統退為輔助角色，只在介面提示建議數值，必須由操作員手動確認才執行。
物理旁路：系統異常或大幅超出邊界時，一鍵切斷演算法介入，控制面板平滑交回給現場人員全手動操作。
第一線人員抗拒的往往不是減輕負擔，而是抗拒「被演算法剝奪了處置權限，出事卻要由現場來扛責任」的不確定感。
當系統賦予現場隨時能介入、微調、甚至一鍵切回手動的彈性與安全感時，現場才敢放下防備，把重複繁瑣的工作逐步交託給演算法。
給系統留一條手動退場的生路，反而才是讓自動化真正被現場接受的起點。
好的系統架構，不是向主管承諾「我永遠不會出錯」，而是向現場證明「當我出錯時，作業絕不會跟著我一起停擺」。
確認停開車與規格切換時的適用邊界、算清上下游單元的承載極限、備妥讓現場能無痛接管的 Excel 降級方案，並在一開始就留好人機比的滑動彈性。
唯有把錯誤處理與故障排除手續想透，系統突發狀況時才不至於變成現場的災難。
十四天的摸底期，我們從目標 Y、特徵 X、演算法 f()、時滯物理量、量化指標障眼法，一路排查到了這道最後的退場防線。兩週的危險徵兆雷達全部掃描完畢，但這僅僅只是拿到了專案落地的入場門票。
走完了十四天的摸底期，我們排查了六大致命的危險徵兆。
然而，現場的未爆彈百百種，不可能靠幾條檢查清單就全部網羅。在面對各種專案型態與技術名詞時，身為站在第一線扛維運責任的工程與評估人員，我們到底該用什麼樣的核心心法，一眼看穿專案的虛實？
危險徵兆再多，有一件事情永遠跑不掉：你最終要交付的成果到底是什麼？
如果一切努力沒有回歸到「使用者至上」與「客戶至上」的實體作業線上，再精巧的排雷技術，也只是一場關起門來的自我陶醉。
下一篇，我們為專案摸底期做最後的收束與覆盤：
《第十七章｜危險徵兆總結——稽核的省思：以終為始，回歸使用者的真實世界》。
iThome鐵人賽
看影片追技術