我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

前面幾篇，我花了一些篇幅介紹這個 SMT 案例。

一開始進到客戶現場時，我們先從製造端開始看，希望了解搬運、領料、上料或製程裡，還有哪些地方值得自動化。實際走過產線之後，可以看到智慧料架、搬運設備、條碼防呆和 MES 都已經存在，多數重要節點也有相對成熟的自動化機制。

因此，後續訪談開始往工廠外延伸，去了解客戶從收到詢價、整理資料到完成報價的流程。這時才發現，公司要求業務在客戶詢價後一個工作日內完成報價，而這個要求和他們的商業模式直接相關。接著，我們又陸續遇到客戶 Excel 格式不一致、業務只能使用一般筆電、模型需要持續更新，以及 AI 分類結果不可能每一筆都完全正確等限制。

最後交付的，是一套單機版的報價輔助工具。外部客戶繼續用原本的 Excel 詢價，業務只需要做少量設定，再由軟體解析資料、模型分類料號，最後集中確認模型比較沒有把握的結果。

如果把這幾次現場觀察和決策放在一起，可以整理出四個在企業 AI 專案裡經常需要面對的判斷。

1. 先理解企業靠什麼競爭，再決定自動化哪裡

這個案子第一次進工廠時，原本想找的是製造現場的自動化機會。產線裡當然還是存在一些可以繼續改善的人工環節，也很難有哪一間工廠真正做到百分之百自動化。不過在看過智慧料架、搬運、上料防呆和 MES 之後，可以確認製造端剩下的改善空間相對有限，未必是當下最值得優先投入的地方。

後續找業務了解接單的完整流程，才發現這家公司非常在意報價速度。他們服務不少大型電子廠，其中包含少量、多樣、需要快速打樣的需求。相較於用價格競爭，他們更依賴快速回應、短交期、彈性配合和在地服務，因此內部才會要求業務在一個工作日內完成報價。

這個背景會直接改變對「報價流程」的理解。如果只看到業務每天花很多時間整理 Excel，很容易把它視為單純的行政效率問題；但當報價速度和公司的競爭方式連在一起之後，縮短這段時間同時也在支持客戶體驗與接單能力。

所以在找自動化題目之前，公司的主要客戶是誰、客戶為什麼選擇它、企業靠什麼方式競爭，以及哪些流程會直接影響這些優勢，通常都需要先被理解。否則很容易找到一個技術上可以做的題目，卻沒有真的碰到對企業最重要的流程。

2. 不要把系統的複雜度，轉嫁成使用者的配合成本

找到報價流程之後，接下來的問題是客戶提供的 Excel 格式幾乎都不一樣。如果只從開發難度來看，最簡單的方法是提供一份標準範本，要求所有客戶以後按照相同格式詢價。欄位固定、位置固定、格式一致，後面的程式會簡單很多，維護成本也比較低。

實際上，這些外部客戶本身也是大型企業，內部早就有既定流程和文件格式。站在供應商的角度，為了讓自己的系統比較好開發，就要求客戶修改原本的詢價方式，會增加客戶的配合成本。這又剛好和這家公司原本強調的快速、彈性、好配合產生衝突。

同樣的取捨也出現在模型部署上。業務使用的是公司既有筆電，沒有 GPU，也不是為了 AI 特別採購的設備，而且工作上還會帶著筆電移動。如果為了使用更大的模型，要求公司重新買設備、架 Server，或要求業務每次使用都先連到特定環境，技術方案本身可能更完整，但新的使用成本也會一起出現。

這兩件事共同點是對系統端複雜度做取捨。有些方案看起來讓工程端變簡單，其實只是把原本需要程式處理的 複雜度轉移到客戶或第一線使用者身上。

因此，評估一個方案時，除了開發成本之外，也需要把 Adoption Cost 一起算進去。系統比較容易做，不代表企業整體付出的成本就比較低。

3. 技術選型，要從現場限制往回推

這個案例裡，模型真正需要完成的任務，是把客戶提供的零件描述對應到公司既有的料號。這是一個邊界相對明確的 Classification 問題，不需要生成長篇內容，也不需要和使用者進行多輪對話。

此外，模型需要跑在業務原本的筆電上，沒有 GPU，最好可以直接使用 CPU；處理一批報價資料不能等太久；客戶的料號和 BOM 未來還會改變，所以模型也需要能夠持續更新；而且模型效果不能只看一次測試結果，還要能處理後續進來的新資料。

在這些限制條件之下，我們最後選擇一個比較小的 Transformer 分類模型，利用客戶既有的報價資料 Fine-tune，再和 Excel 處理流程一起包成單機版工具。

如果單看模型能力，大型語言模型肯定比較強。但畢竟我們是要交付一整套會進入日常工作的方案。任務需要什麼能力、部署環境有多少資源、模型效果是否足夠、未來更新的成本是否可接受，這些條件都會一起影響技術選型。最後要最佳化的是整套方案在真實環境裡能不能順利運作，而不是單一模型的能力上限。

4. 100% 自動化，不一定是最適合的設計

這套系統的使用流程中，有幾個手動和自動化的取捨。

第一個是在 Excel 進入系統時。因為每個客戶的版面不一樣，我們沒有要求程式自己判斷所有可能的資料位置，而是讓業務先指出真正要處理的資料從哪裡開始，再交給軟體進行後續解析。

第二個是在模型完成料號分類之後。模型會輸出 Confidence Score，因此可以讓經過驗證、信心值比較高的結果直接往下處理，再讓業務集中確認中低信心值的資料。

這兩個地方都保留了一點人工，但也因此縮小了系統需要自行處理的不確定性。對人來說很容易完成，但對系統來說需要處理大量例外的事情，保留少量人工通常可以換來更低的開發與維護成本；而那些大量、重複、耗時間，且已經能由系統穩定處理的工作，才適合盡量自動化。

如果要求所有 Excel 都完全自動辨識、所有分類結果都不需要人工確認，理論上當然還可以繼續增加功能，但系統需要處理的例外會更多，測試範圍也會變大。為了最後那一小部分人工工作，投入的開發與維護成本不一定划算。而且模型本來就有可能出錯，如果人必須重新檢查所有結果，額外的檢查又吃掉了原本透過 AI 節省的時間。

當時在梳理這段流程時，我們曾經估算，如果可以把報價中大量重複性的工作自動化，節省的工作量可能接近一位業務人員。不過報價本來就只是業務工作的一部分，業務仍然需要開發市場、拜訪客戶、理解需求和維持關係，所以真正希望減少的是那些重複、接近行政作業的時間。

從這個角度來看，自動化率本身未必適合作為最主要的 KPI。整體流程花多少時間、需要多少人力、系統要付出多少維護成本，以及使用者是否願意採用，這些條件通常更能決定方案最後有沒有價值。

回頭看這個案例

以上四點，大致就是我整理出的 FDE 原則，雖然沒有什麼太華麗的做法，但都是真實的現場案例！

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！