「我們是傳產啦，很多東西都還很原始，你進來看不要被嚇到喔！」
每次剛進廠初訪或評估專案，會議室的白板筆都還沒拿起來，對方的窗口或主管往往會先露出尷尬又不失禮貌的微笑，提前給我打上一劑「預防針」。
聽到這句話，在座的工程師心裡大概就已經涼了半截。
回顧上一章那張令人哭笑不得的現場梗圖——在各部門互築高牆、老舊機台接口封死的數據孤島之間，哪怕到處插滿「NO LANDING 禁止登島」的警告牌，好歹遠方還能看到幾座島的輪廓；只要有島，大家坐下來吵吵架、爭取一下預算，好歹還能談怎麼造橋攻克它。
但真實傳產現場最慘烈、也最讓人絕望的境地往往是：如果眼前在系統架構上連一座島都沒有，該怎麼辦？
很多沒在工廠蹲過的人常有一種誤解，以為傳產現場之所以在系統裡看不到數據，是因為老闆捨不得花錢買軟體。
別傻了，實際的情況是：很多傳產非常有錢！
幾千萬一套的 SAP、ERP 眼睛眨都不眨就買下去了，高層簡報上驕傲地宣稱系統早已全面上線。但只要你穿上安全鞋走進廠區，就會看到極其魔幻的一幕——生管與操作員的桌上，永遠放著一張手寫、被原子筆塗得亂七八糟、油漬斑斑的「生產規格表」。
系統歸系統，現場歸現場。現場人員的所有真實操作與調度，全都是盯著那張隨時塗改的手抄單在跑。也就是說，「連島都沒有」指的不是現場沒有作業行為，而是在公司的數位資料庫裡，這座島是完全憑空蒸發的幽靈！ 所有的島嶼與航道，全被物理性地封裝進了老師傅的皮囊與那張隨時可能揉掉的紙張上。
如果你是個不懂現場水深的工程師，天真地直接去連線 SAP 資料庫、拉裡面的表做分析與模型訓練，我可以保證——你最後算出來的結果絕對完蛋，甚至會死得很難看。
因為這類資訊之所以根深蒂固地停留在紙本，背後有著兩個大家心照不宣的深層原因：
避免被高頻率的無情勾稽： 紙本有其天然的物理屏障——調閱麻煩、翻找費力、難以跨表比對。一旦全搬上系統變成每秒跳動的即時數據，總部稽核或財務隨便點兩下就能跨表勾稽，第一線人員在現場為了維持生產平衡所必須保留的「彈性調配」與「不能說的餘裕」，立刻無所遁形。
這項核心 Know-How，註定要爛在老師傅的肚子裡一輩子： 檯面上常聽到的藉口是「怕被年輕人或系統取代、怕丟飯碗」。但如果你在現場蹲得夠久，會發現一個更平實、甚至有點無奈的答案——他自己其實也說不出個所以然。 面對反應爐的壓力擺動或是機台震動，他憑直覺轉了半圈閥門、聽了聽馬達聲，最後產出的規格「每次都是對的」；但你要他拆解出具體的因果關係、寫出標準作業手冊（SOP）？他講不出來。在產線現場，這種無法被結構化量化的黑盒子，就被神化為至高無上的兩個字——「經驗」。
管理學界有一句大家奉為圭臬的名言：「管理制度化、制度表單化、表單電腦化。」如果放到今天生成式 AI 滿天飛的風口上，後面大概還得再加個「表單 AI 代理人化」？！
但現實極度諷刺：你連底層資訊的真實物理邊界都還沒摸清，資料庫裡全是脫鉤的假象，就妄想一步登天玩 AI 代理人。
好，退一步講，就算現場願意配合，你會立刻撞上第二道殘酷的深淵：很多資料確實看得到，但它「只有即時的狀態」，根本沒有留存任何「歷史數據」！
當你想把歷史數據倒進模型學規律時，回頭一看，資料庫裡空空如也。
唯一值得慶幸的是，當初在安排出貨、開會討論生產排程時，現場偶爾還會「印一些紙本排程表出來」存檔。翻箱倒櫃找出那些泛黃的紙張，或許還能勉強拼湊出一點點可憐的歷史片段。
紙本雖然破爛，但好歹是個殘存的實體；最致命的，是那些在產線空氣中飄過、卻從未在任何介質上著陸過的「幽靈變動」。
在製造業的真實日常裡，營業部早上九點接到大客戶一通火急火燎的電話：「不管怎樣，明天一定要幫我插單 500 箱！」
生管一聽，立刻雞飛狗跳地翻開排程手抄單，塗塗改改把原本的批次往後挪；但到了下午兩點，產線發現某道工序換模根本跟不上，營業部又急忙打電話跟客戶協調取消。
這整段驚濤駭浪的「需求變動與排程干預」，自始至終完全沒有錄進任何資料庫裡！
它只存在於早上一通十幾秒的電話、以及生管手邊那張被立可帶塗掉又重寫的草稿紙上。當你半年後拉出 ERP 的最終出貨紀錄，看到的只是一片歲月靜好，完全不知道當天產線為了這筆消失的插單經歷了怎樣的兵荒馬亂。這種充滿斷點的環境，你拿什麼去訓練演算法？
比沒有數據更折磨工程師的，是現場老手嘴裡那句雲淡風輕的——「都可以啊」。
去現場做需求訪談，你拿著筆記本認真問：「師傅，如果這批料品質開始往下飄，你要怎麼調？」
師傅抽了口菸，手一揮：「都可以啊！有時候轉一下 A 旋鈕，有時候去敲一敲 B 管線也行。」
你轉頭跑去生管桌邊問：「那明天這三家客戶催貨，優先順序怎麼排？」
生管頭也不抬：「原則上先給大客戶 K 廠啦，但如果當天現場換模不順、或者 Q 廠催得要死，先給 Q 廠也完全沒差。」
工程師這時往往差點吐血。你氣急敗壞地翻開那本通過 ISO 認證的厚重標準作業程序（SOP），上面居然還真的白紙黑字寫著：「視現場工況，彈性微調 A 或 B 控制因子。」
如果今天你滿腦子都是傳統寫程式的邏輯，妄想用「如果怎樣就怎樣（If-Else）」的硬性規則把產線寫死，專案在第一天就徹底暴斃了。現場有一萬種「都可以」，你的規則引擎只要漏掉一種，機台當天下午就直接跳車給你看。
但這正是整個局勢最微妙、也最富戲劇性的轉折點：機器學習這門手藝，本來就不是發明來背 SOP 的，它最厲害的看家本領，恰恰就是去摸透人類老手那套「說不清、道不明的隱性暗號」！
面對這種灰色地帶，能不能做成，根本不取決於師傅講不講得出道理，而是取決於兩個極度骨感的現場條件：
結果到底算不算明確？——不管現場今天到底神經刀地動了 A 還是敲了 B，也不管排程先給了 K 還是給了 Q，只要老生管最後點頭說「這批貨能準時出港、客戶驗收沒退貨」，這件事就有了一個雷打不動的明確對錯！ 只要這條生死線是定死的，機器就有辦法倒回去抓規律。
當時的歷史操作有沒有留下蛛絲馬跡？——那張塗改手抄單上的鉛筆印、當初開會列印出來壓在抽屜裡的排程草稿，能不能把當時現場到底動了什麼、當時機台晃成了什麼德性給真實還原？
只要「最終結果有明確對錯」，且「當時的現場動作有跡可循」，哪怕老生管肚子裡的直覺再玄學，演算法都有機會像金屬探測器一樣，硬生生把黑盒子裡的規律給反推出來。
但反過來，如果連「這批貨到底算不算成功」都定義不出來，歷史手抄單又全是應付稽核瞎編的鬼話，那就算把全世界最強大的神經網路搬進機房，也只剩算命和瞎猜。
那麼，要怎麼把這張滿是塗改的手抄單與隱性規則，轉化為模型能消化的邏輯？
很多熱血工程師第一直覺會喊出：「那我們就肉身跳下去做，每天跟著生管排！」
說每天下去蹲？老實講，這未免太脫離現實了。
長官怎麼可能平白無故讓你把大把時間都耗在產線旁？專案才在需求訪談初期，你搞那麼大精力天天泡在機台邊，長官第一個跳出來質疑你的產出與時間配置。
這就必須精準扣回我們上一章談到的鐵律——「決策頻率的優先級，決定了題目的商業價值優先級」。
唯有當你在高階會議上證明了：這張手抄單支撐的是「每兩小時就要調度一次、動輒牽動上百萬交期」的高頻關鍵決策，高層神經被觸動了，你才有足夠的正當性爭取到資源去現場「深蹲」。
但即使你真的拿到了尚方寶劍，也不需要天長地久地耗在那裡。實務上，你只要讓現場知道：你是來「玩真的」！
試想一下，換作你是現場老生管，每天身邊跟著一個捧著長官尚方寶劍的小跟班，寸步不離、拿著筆記本對著手抄單每筆塗改問東問西，誰受得了？這種折磨，誰都想趕快解脫！長痛不如短痛，現場老鳥很快就會意識到：這群搞數轉的不是走馬看花開完會就拍拍屁股走人，這次是躲不掉了。
這時，你的溝通姿態至關重要。你必須明確傳達一個政治訊號：「長官對於現在這種完全不透明的營運黑盒子，忍受度已經到極限了！」
但請務必清醒：長官要的「透明」，是「營運趨勢、產能波動與預測因果的透明」；而第一線人員每天賴以生存的，是「應對機台異常、料況突發時的調度容錯與人為作業餘裕」。
水至清則無魚。如果把現場所有的彈性、耗損、緩衝全逼上檯面做到 100% 絕對透明，現場會立刻窒息，最後只會逼得所有人集體造假、魚死網破。
我們追求的從來不是透明無暇，而是「相對不透明」。
在深蹲梳理邏輯的過程中，你要讓老生管清楚明白：你不是總部派來抓小辮子的稽核走狗，你是在幫他把痛苦的例行排程自動化；而那些現場不可或缺的調度空間與安全緩衝，「我會直接寫進演算法的正規約束條件（Constraints）裡，幫你妥妥地 COVER 起來！」
大老闆拿到了產能可預測的宏觀透明，老生管保住了產線調度的生存空間。雙方在這種默契中逐步建立信任，直到某一天早晨，那位掌控著全廠排程生殺大權的老鳥，轉頭拍拍你的肩膀說：
「欸，我那天早上家裡臨時有點事要請假，你幫我弄一下排程好不好？」
當這句話從他嘴裡說出來的那一刻，這個專案、這套系統，才算在現實世界裡「真正能上線了」！
因為此時，你才真正接管了那個爛在肚子裡的經驗黑盒子，把不可見的人肉直覺，轉化成了系統能理解的邊界條件。
如果沒有走過這段接地氣的折衝與破局，單靠高層一紙行政命令硬推數位化，下場通常是極具諷刺意味的官僚災難：
制度的確訂立了，但久未更新：櫃子裡鎖著厚厚一本應付 ISO 認證的作業標準，幾年沒人翻過；
大家摸透了避坑技巧：基層同仁深諳生存之道，完全知道表單該怎麼填才能完美繞開監管警報，同時在底下的紙本保留自己的操作彈性；
系統看似數位化了，實質卻徹底脫鉤：資料庫裡堆滿了漂亮的虛假欄位，產線依然看著手寫單過日子。
大家在虛偽的太平日子裡相安無事，直到某一天，資深員工離職或退休了——那就是整座組織「業力引爆」的時刻！
當那位掌握排程暗黑眉角的老鳥收拾包袱走出廠門，原本靠他個人直覺維持住的生產平衡瞬間崩解。後續隨之而來的交期延誤、換模報廢、以及找不到根因的停機修機……這不僅僅是業務流程上的「失憶」，反映在公司的損益表上，更是幾千萬甚至上億元真金白銀的集體「失億」！
至此，關於「量化目標」這項大課題（從第七章生死的刻度、第八章指標的偽裝、第九章數據拼圖秀，到本章的經驗斷層），我們正式告一個段落。
回頭審視，很多人以為「量化」只是一道數學題或技術指標，但在殘酷的工業與商業現場，「無法量化」的本質，從來都是因為團隊根本「定義不出真正的問題」。
如果連問題的目的、商業的邊界、以及決策加速的真實顆粒度都錨定不出來，後續的演算法再精妙，也只是在虛榮指標與公關簡報上自我感動。而當我們好不容易把問題定義清楚、試圖落實量化時，眼前橫亙的往往不是算力不足，而是兩種極端的數據深淵：
面對「數據孤島（有島，但碎成滿地）」：不要妄想一步登天建資料湖；看現場做決策的頻率，挑出真正牽動營運的心跳線。在真正的大頭面前讓資訊斷點「自然蹦出來」，借高層對不透明度的零容忍，以行政權威強行打通調用邏輯。
面對「經驗黑洞（根本沒島，全在紙上）」：別天真地以為訪談幾次就能寫出規則；只要商業價值確立，工程師就必須帶著尚方寶劍肉身深蹲下去排。同時謹記「水至清則無魚」——把現場必備的調度緩衝寫進演算法的正規約束裡幫他 COVER，直到老鳥願意把代班權交給你的那一刻，系統才算真正落地。
目標能量化，轉型就一定會成功嗎？
答案依然很骨感：完全不見得。
量化目標只是讓你在泥淖中拿到了下場比賽的入場券。把坐標刻出來，充其量只是讓你知道自己究竟是邁向重生，還是走向往生；而真正決定生死存亡的，是接下來的「可行性評估（危險徵兆）」。
量化坐標已經定錨，接下來，我們將踩進專案最初的十四天生死線。但一進到現場，迎面砸過來的往往不是客觀的工程探討，而是窗口與長官興奮又焦慮的靈魂逼問：「你們這套到底有沒有 AI？底層用的是哪種演算法？」
如果手裡只有鐵鎚，你看什麼都會像釘子；如果專案只剩下為了交差而硬套高深模型，那這場轉型注定落得滿地雞毛。在急著寫程式或砸錢買算力之前，我們必須先啟動第一個危險徵兆雷達，戳破這個最昂貴的自嗨陷阱。
下一篇，我們正式進入第三大篇章【可行性評估：兩週內的危險徵兆雷達】—— 《第十一章｜危險徵兆 1：AI 根本 BI，當專案只剩下「為了 AI 而 AI」》。
iThome鐵人賽
看影片追技術