駐點交付 vs 遠端交付:企業 AI 專案什麼時候該讓工程師直接進場現場?

去年冬天,我們同時在跑兩個 RAG 知識系統的案子。一個是新竹的精密製造廠,一個是台北的 SaaS 公司。同樣的技術棧、同樣的團隊、同樣的預算級距。差別只有一件事:製造廠我們派了兩個工程師駐點六週,SaaS 那邊全程遠端。

三個月後,製造廠的系統上線,現場工程師每天真的在查;SaaS 那個,我們遠端交得漂漂亮亮,結果對接的窗口離職,系統躺在那裡沒人動。

聽起來很反直覺對吧。照理說軟體公司比較懂技術,遠端應該更順。但決定 AI 專案該不該讓工程師進場的,從來不是客戶的技術成熟度,而是這個專案本身的「現場密度」有多高。

先給一個能直接用的判斷句

駐點 vs 遠端 AI 交付的分界,不在專案大小,而在三個訊號的強度:邊角案例密度、資料敏感度、內部知識黏著度。三者只要有兩個偏高,就該駐點;三者都低,遠端就夠。

這三個訊號,是我們踩過十幾個案子之後歸納出來的。逐一拆開講。

訊號一:邊角案例密度

邊角案例(edge case)密度,指的是「規則之外的例外」在這家公司日常裡佔多少比重。

SaaS 公司的客服工單,九成長得像同一個模子,例外好整理、好標註,遠端拉一份資料就能訓練。但製造廠不一樣。同一個「異常停機」,老師傅的判斷會分岔成十幾種情境:是刀具磨耗、料件批次問題,還是隔壁產線的震動干擾?這些分岔寫不進 SOP,只活在人的腦子裡。

邊角案例密度高的時候,遠端交付最大的問題是你「問不到對的問題」。工程師在螢幕另一端,只會拿到客戶「以為重要」的那些案例,而真正讓系統翻車的,永遠是沒人想到要告訴你的那一類。人在現場,才會在茶水間聽到「喔那個啊,我們都馬手動改」。

訊號二:資料敏感度

第二個訊號最好判斷,卻最常被低估。

資料能不能出場,決定了工程師能在哪裡工作。病歷、核保資料、晶圓良率、未公開財報——這類資料多半綁死在內網,連截圖出來都違規。遠端交付在這種環境下會退化成一種很痛苦的節奏:客戶端的人幫你跑查詢、貼結果、你再遠端猜哪裡出錯,一個迭代要來回三天。

我們在一家醫療機構做知識系統時就是這樣。前兩週遠端,每個問題的驗證週期是 48 小時起跳。後來工程師帶著筆電進院區,坐在他們的隔離網段裡,同一批問題一個下午清完。資料敏感度高不一定代表技術難,但它幾乎必然拉長遠端的回饋迴圈——而 AI 專案的死因,大多是回饋迴圈太長,還沒調準客戶就失去耐心了。

訊號三:內部知識黏著度

第三個訊號最隱形,卻最能決定「上線後有沒有人用」。

內部知識黏著度,指的是這套系統要好用,需要吸收多少「沒有文件、只在人身上」的知識。有些流程攤在 Confluence 上寫得清清楚楚,黏著度低;有些關鍵決策的「為什麼」只存在資深員工的直覺裡,黏著度就高。

黏著度高的案子,遠端交付會交出一個技術上正確、實務上沒人認的系統。因為採用(adoption)本質上是信任問題:現場的人願不願意把判斷交給這套系統,取決於他們有沒有參與過它的養成。工程師駐點的真正價值,常常不是寫程式,而是坐在使用者旁邊,把他嘴上唸的「這個不對」一條條餵回模型,同時讓他親眼看到系統一天比一天準。這個過程,遠端做不到。

把三個訊號放進同一張表

規則很簡單:右欄命中兩格以上,把工程師送進去;三格全在左欄,遠端交付不但夠,還更划算——硬派人進場只是浪費雙方的時間。

一個常被忽略的中間帶

實務上,大多數案子不是非黑即白,而是「前重後輕」。

我們現在的預設打法是:高訊號的案子,前四到六週駐點,把邊角案例挖乾淨、把資料驗證的迴圈壓到當天、把種子使用者的信任建立起來;等系統跨過「有人每天在用」這條線,再切回遠端做長期維運與迭代。駐點不是一種永久駐紮,而是把最貴、最靠現場的那段風險,用人力密集地啃掉。

會這樣做,是因為我們信一件事:Demo 很美不算數,上線且有人天天在用才算數。而讓 AI 從 Demo 走到被採用的那段路,到底該用駐點還是遠端走完,先看這三個訊號,再決定要不要買機票。