「到底有幾案還在用？你們去查查！」
某次集團的高層月會上，長官摘下眼鏡，語氣裡沒有激昂的斥責，只有一片疲憊又冰冷的慍怒。
這句話丟出來，台下頓時一片死寂。大家心裡都有數：過去幾年結案的那些智慧化專案，現在到底還有幾套真正活在產線上？
長官一聲令下，總部隨即啟動了全集團的專案大普查。身為稽核與技術排查的一員，看完上百個案子的真實下場後，我發現了一件極度諷刺、但身在其中的人也絲毫不意外的事：那些被審查退件、或是結案後私底下被現場徹底唾棄的案子，其原因居然大同小異！
抽絲剝繭後，死因大概可以歸結為兩大類：
第一類，就是前面幾章所提的那些技術危險徵兆。 我不否認有些案子是早期純推廣、試驗性質遺留下來的產物，以現代眼光回頭看，妥妥的破綻百出。以後照鏡來看，大家只會嘆氣說當初幹嘛做；如果繼續追問細節，就會發現前面談到的那些技術徵兆一個不漏地全部跑出來。
第二類，則是現場通常說不上來、但在日常體感中卻極其明顯的：數據使用場景到底有沒有被改變？
什麼意思呢？如果你走進現場問操作員，他往往講不出什麼高大上的數位轉型術語，甚至抓抓頭跟你說不上來具體改了哪裡。但只要你多觀察幾天，就會發現大家的體感完全變了：交接班時少掉了幾次爭吵、以前老是要去翻抽屜找抄紙的動作消失了、甚至每天盯著螢幕的眼神都不一樣了。
現場察覺到了改變，卻不知道該怎麼用漂亮的話去形容——答案很簡單，因為底層的數據使用場景，已經實打實地重塑了一線人員的作業方式。
我只能說，沒有比較就沒有傷害。如果你看過真正的好案子——那種現場同仁真心覺得好用、天天開著螢幕依賴它、甚至遇到別廠同仁來參訪時會帶著驕傲向你炫耀「我們這套幫了大忙」的案子；回頭對比那些書面審查報告極度完整、指標漂亮無瑕，現場卻根本沒人碰的案子，你會發現書面資料可以調整，但現場的感受是騙不了人的。有些案子書面資料完整得像教科書，走進中控室一問現場操作員，對方卻只是一臉茫然地回你：「蛤？我們有這套東西喔？」
無論當初立案時有多少理由，但如果拉回到「業務流程」、拉回到「真正要被系統執行的現場」，這些東西就是絕對不可以漏！因為專案最終永遠跑不掉同一個靈魂拷問：你最終要交付的成果到底是什麼？
一切終究必須回歸到最純粹的原點——客戶至上、使用者至上。
如果你在大型企業裡擔任過內部稽核或專案審查的角色，你一定會對這份差事多麼「吃力不討好」深有體會。
審查報告時，沒抓出問題長官覺得你沒做事；認真退件現場又覺得你找碴。承辦團隊總有一堆理由：「專案剛起步還有不確定性」、「先拿到經費廠商進來再說」……
看透了這種無效拉鋸，稽核心中往往會磨出一套極度質樸的權宜之道：在正常情況下，只要你的報告裡具備了「這些關鍵細節」，我就不會特別多說什麼。
這些細節既然作為你專案最「終」結案時理應具備的交付成果，沒有就得列入改善建議；那麼，如果你能有一顆後悔藥「重生」回到專案第一天，正常來說，你就該在最一開「始」的那份規格書裡，把這些東西通通寫得清清楚楚、雷打不動。
期初，大家總希望把餅畫得鉅細靡遺，簡報上的藍圖講得活靈活現，這個最終解方聽起來簡直躍然紙上。然而，到了結案時刻，東西真不真，全看細節裡的顆粒度：
A案陳述：「本案降低轉品別次數提升效益數百萬元。」
B案陳述：「本案利用演算法建議品質預測，操作人員可透過平台與推播及時獲得資訊進行操作，在系統上線 1 年後，某單位成本指標下降多少，故換算效益為某數值（見附件）。」
很多人一眼看過去，會覺得 B 案比 A 案優秀太多了：有演算法名稱、有操作平台、有即時推播、有點名效益指標，甚至還煞有介事地附上了計算附件。
但我必須戳破這個幻象：B 案實際上也是一個假案子，它只是「聽起來很真」而已！
B 案最致命的破綻有兩個：
第一，它「缺乏具體的數據使用場景」。演算法給出「建議」，在工廠現場是最沒有用的東西。演算法推播建議閥門開度 45%，操作員根本不敢照做，因為如果產品報廢了，是他要寫檢討報告，演算法又不用負責。現場作業員手裡抓著板手、戴著防油手套，誰有空掏出手機看推播？至於附件裡那張看似漂亮的年化成本下降曲線，往往只是剛好碰上了市場原料降價的週期紅利，或是現場同仁靠肉身加班硬扛出來的成果；整套系統在後台推播了上萬次，現場真正採納執行的次數屈指可數，這就是典型把環境運氣攬為演算法功勞的虛偽因果。
第二，它「根本沒有點出跟過去人工相比到底差在哪裡」！
大部分報告在寫動機時，最喜歡用些空泛的套話蒙混過關：「人工判斷容易有疏忽」、「人員經驗參差不齊」……這些話說了等於沒說。真正的痛點與專案動機，必須能翻出歷史的錯誤紀錄：
「在某年某月的某個大夜班，因為現場交接班時對溫度回升的認知不同，憑直覺調慢了冷卻水閥門，導致下游整條反應直接交聯結塊；整整兩百噸原料報廢，客戶退運、產線停機清理三天，工廠被迫認列了幾百萬的重新出貨與報廢損失！」
前者是為賦新詞強說愁的公關話術；後者才是現場痛徹心扉、花真金白銀買來的血淚教訓。
對於「痛點」與「專案動機」這件事，很抱歉，在審查稽核的世界裡，我沒有絕對的標準答案。它不是一張能打勾計分的是非題考卷。但案子看多了，你從文字的顆粒度與現場同仁講話時的眼神，大概就能一眼看出這是真痛還是假裝在痛。
這也是為什麼我把這件事情放在最後的原因——前面 11 到 16 章談的六大徵兆，更像是一套客觀的底線雷達；如果提案團隊把那些該交代的地雷都排查了、甚至有了一些實戰上的延伸，這案子大概就不會太差，身為審查者或公司高層，我們才終於「願意冒點風險陪你做做看」。
既然 B 案這種「只給建議、不管場景」的作法無法帶來真正的轉型，那到底什麼樣的系統，才算真正長進使用者的真實世界？
轉型從來不是追求一步登天的科幻電影。
前幾年風口浪尖上的「無人商店」，就是脫離真實世界的極端案例。技術狂熱者總妄想在店內布滿幾百顆天眼攝影機與重力感測貨架，企圖打造一個完全沒有人類的烏托邦；結果硬體折舊驚人、辨識異常處置成本居高不下，最後紛紛黯然退場。
反觀真實世界裡真正存活下來、而且越來越普及的轉型是什麼？「一人小店」。
它不強求極端的完全無人，而是在現實中找到了一個極佳的灰階平衡點——僅僅把「外場點餐與結帳數位化」。
走進現在街頭巷尾的一人小拉麵店或咖啡館，門口擺著一台數位點餐機，或者桌面上貼著一張點餐 QR Code。顧客自己掃碼、自己選配客製化口味、自己完成電子支付；訂單數據直接穿透進廚房的螢幕，唯一的店員只需要專注在備料、煮麵、出餐。
這種模式不見得適合每家店，但它的確越來越普及。為什麼？因為它不是給店員「建議」說客人可能喜歡吃什麼，而是實打實地把「外場點餐、收銀、找零」的繁瑣人工作業徹底取代掉了。這套數位化沒有讓現場變得更手忙腳亂，反而是把原本需要兩個人的店，濃縮成一人就能穩健運轉。
現場作業員也是人。當然，連續製程與工業現場牽涉工安與設備風險，不可能像拉麵小店一樣瞬間撤掉所有人手讓 AI 全自動代操；就像產線不用 AI 妄想直接盲控整座高壓反應爐，但可以把原本每小時要人工查表對照的參數計算、或特定低風險閥門的繁瑣微調給徹底接管。
這兩者的底層邏輯是完全相通的：一套好的系統，絕對不能只停留在丟出一個不痛不癢的「建議」，然後把採納與否的責任全甩給操作員。 它必須精準接管某個繁瑣的計算斷點或特定控制閉環，讓現場同仁的工作流真正被解放、形成穩固的行為閉環。
那麼，如果一套系統真的在現場扎下了根、被操作員天天持續使用，它的「數據使用場景」到底會長成什麼模樣？
實務上，真正有在運轉的系統，必然會從這三個角度徹底展現出來：
AI 推論紀錄透明可溯 ：每一次模型運算給出閥值或決策時，底層吃進什麼特徵、輸出什麼邏輯，全都有跡可循，決策完全透明可溯，絕不讓推論死無對證。
推論過程高度可重複 ：同一批歷史數據餵進去，能隨時重現當時的決策脈絡，如果現場要覆盤，絕不會因為伺服器重啟就成了死無對證的黑盒子。
決策可解釋性具備實質意義 ：當異常發生、現場需要檢討覆盤時，操作員與工程師能看懂當時模型為什麼這樣判斷，同時保留現場人員重新標註、修正與介入決策的空間。
但這裡藏著一個極其殘酷的專案潛規則：這些東西可能一開始就沒被規劃!甚至如果這些數據場景的規格在專案開案時就大喇喇列出來，沒經驗的窗口或審查主管大概率會想把這部分砍掉！
在很多長官眼裡，這些東西看起來就像可有可無的「裝飾品」；他們只想快點看到預測結果，恨不得把這些日誌記錄、重現機制與覆盤介面通通砍光，好把專案報價壓低。
遇到這種情況，資深工程師的底氣通常是這樣的：
基本上，這些底層機制我在架構初期就全都順手設好了。 拿掉這些東西，專案不會因此比較便宜；你就當作附加送你的，反正合約上不必大肆張揚，底層管線先布好再說。
為什麼要這樣做？因為這不是做慈善，而是為日後的維運自保。等到系統真的上線跑了一陣子，現場每天都在用、開始產生依賴後，往往會迎來一個極度熟悉的場景。現場課長打電話來：
「喂，工程師啊，你們這套系統我們天天在看，蠻順手的。但我最近在想，能不能幫我新加一個功能？我想調出三個月前的歷史推薦紀錄，跟當時的配方對照覆盤一下，看看能不能加進去？」
這時候，你根本不需要重新開規格、不用跟主管報加班、更不用跟對方扯皮加錢，而是能靠在椅背上，對著話筒帥氣地說出：
「課長，這個功能我們當初在系統底層早就全部架設好了！當初介面沒特別強調，您現在方便直接看一下螢幕右上角的這個按鈕嗎？點開它，歷史推論跟覆盤數據全都在那裡。您看一下，這樣有沒有符合您的需求？」
電話那頭傳來一聲驚喜的「太神了吧！」，這才是一個資深技術人員在真實世界裡最優雅的落地姿態。能做到這一步，不是因為我們會通靈算命，而是你在最初以終為始推演架構時，早就知道一套「真正在跑的系統」遲早會撞上這些維運場景。
走到這裡，我們必須停下腳步，好好重新審視這四個字：以終為始（Begin with the end in mind）。
史蒂芬·柯維提出這個習慣時，談的是人生願景；但在資訊專案與數位轉型的泥淖裡，「以終為始」簡簡單單四個字，背後代表的卻是極其嚴苛的具體實踐——它完全取決於你對上線後的那個畫面，究竟能想到多細、對後續維運有多誠實！
你越是能站在使用者的角度，就越要把最殘酷的後續維運給考慮進去：
你的最終上線畫面，能不能把該數據優化的東西全都展現出來？ 每一筆數值是否方便後續的模型確效（Model Validation）與指標覆核？每一次推論是否禁得起內部稽核與責任追溯？如果介面上只有一個孤零零的預測數字，那不叫系統，那叫黑箱猜謎。
你的決策流程跟過去人工相比，到底少了什麼步驟、具體解決了什麼痛點？ 是幫現場拿掉了繁瑣的人工作業閉環，還是只是在螢幕右下角多塞了一個沒人敢採納的擾民推播？
如果一開始沒把結案那天的真實畫面刻進骨子裡，你初期開出的規格就只是一紙空文。連終點長什麼樣都看不清的人，從起跑的第一天起，就註定只是在陪跑演戲。
在可行性評估的戰場上，我們給自己的鐵律向來很死：十四天內，用排除法拍板專案的生死。
在跨入下一階段之前，我們把這十四天排查的六大危險徵兆收攏為一張清單，作為任何團隊自我檢核的防禦雷達：
如果這六道關卡有任一項亮起紅燈，且在現有資源下無法補齊，最專業的決策絕不是硬著頭皮把雜訊倒進黑盒子交差，而是乾脆俐落地舉手喊停——幫公司把一場註定往生的災難掐死在搖籃裡，也是一種巨大的價值。
「以終為始，回歸使用者的真實世界。」
這句話的潛台詞是：系統做出來，不是為了在技術年會上炫耀參賽，更不是為了在結案報告裡寫出看似完美的 B 案話術；它是為了在第一線悶熱的中控室裡，實實在在地替同仁省下力氣、扛住風險。
走過全集團這場專案大普查，看著幾十套被現場遺棄的智慧化廢墟，這正是企業在付出過幾十億轉型學費裡最痛的一筆領悟：把表面光鮮的 B 案奉為圭臬，結果驗收簽字之日，就是系統停用之時。
至此，十四天的摸底雷達正式告一段落。我們排除了讓專案死於非命的常見漏洞，確認這套解法在現場「能做得出來、能用得下去、暴斃時有人接管」。身為工程師與專案負責人，我們才終於拿到了通往下一關的門票。
但請隨時保持清醒：
無論一套方案在技術上多麼成功、流程上對使用者多麼體貼，它最終都無法掩蓋其在財報上的平庸。
在技術與流程的防線守住之後，擺在眼前的，是企業經營最赤裸的生存考驗。
當景氣反轉、大環境緊縮，企業高層拿起紅筆準備大砍預算時，決定專案生死的楚河漢界，往往被粗暴地冠上同一個詞——「回收年限」。
你的系統，到底是在寒冬中不可或缺的「必需品」，還是承平時期嚐嚐鮮、一遇風吹草動就喜獲好人卡的「必割品」？
避開了可行性的深坑，我們正式拿起算盤，跨入第四大核心支柱——【效益評估篇】：
《第十八章｜「回收年限」的審判：「必需」與「必割」的分水嶺》
iThome鐵人賽
看影片追技術