駐點工程師留下的東西，為什麼每次都蒸發了

問題是什麼

如今把AI賣進大企業的公司，都會把人送進客戶內部。前向部署工程師在客戶那裡坐上幾週到幾個月，替遺留系統接上轉接層，挖出從沒寫進任何文件的業務規則，把髒亂的生產資料整理成產品吃得下的形狀。做完之後系統跑起來了，而這一路造出來的東西，絕大部分留在了那家客戶的圍牆裡面。

出不來不是因為偷懶。有保密協議，有資料落地規定，更關鍵的是這些產物本身就浸透了客戶的資料表結構與業務邏輯，連一張截圖都帶不走。於是沉澱在乙方這邊的，只剩下人的記憶，加上導入結束幾週後有空才寫的幾頁內部wiki。wiki一定會腐爛。

結果體現在毛利曲線上：第三個客戶的導入時間和第一個差不多。營收漲，成本同比例跟上，成長速度的上限就變成了徵人的速度。這有多貴，看薪酬帶就知道。Christian & Timbers整理的市場資料顯示，中階FDE的總薪酬中位數為38.5萬美元，Staff級為61萬美元，前沿實驗室的Principal級超過120萬美元。就是這批人，在第三家客戶那裡重做著第一家做過的對映。

為什麼是現在

先爆的是需求。同一份資料顯示，Indeed上的FDE職缺從2025年4月的643個漲到2026年4月的5,330個，增幅729%；截至2026年年中，39家AI公司共開著224個職缺。Salesforce公開承諾要招1,000名FDE。Perspective AI分析約1,000則英文職缺的報告給出的年增幅超過1,000%，並發現超過70%的職缺明確要求需求挖掘能力，以及把模糊的商業問題翻譯成方案的能力。已經有41%的AI工程師把三成以上的工作時間花在面對客戶上。

大廠也把資本押在同一個形狀上。AWS在6月30日宣布向FDE專屬組織投入10億美元，在此之前OpenAI與Anthropic分別設立了40億與15億美元規模的合資實體。值得拿來用的細節是亞馬遜為什麼選擇內部建制而不是拆出獨立公司：為了把IP留在自己手裡。連最大的玩家都要用組織結構去堵導入資產的外流，沒有這種體量的公司就需要一個替它做這件事的工具。

技術前提也齊了。軟體跑在客戶環境裡、只把摘要送出去，也就是資料留在裡面、只把形狀取出來，這種設計在隱私工程裡早已不算稀奇。幾年前會死在法務審查上的方案，現在落進了可談判的區間。台灣的系統整合案子多半由客戶掌握成果物權利，能把送出去了什麼攤開給客戶看，本身就是進場的條件。

flowchart LR
  A[客戶環境<br/>整合·對映·提示詞] --> B[觀測層<br/>記錄做了什麼、怎麼做的]
  B --> C[去識別化擷取<br/>剝掉取值，保留結構]
  C --> D[乙方導入記憶<br/>可檢索的模式庫]
  D --> E[下一次導入<br/>從骨架而不是白紙開始]

怎麼構建

先把產物收窄到一種。資料對映規格是最好的第一個標的：把客戶的資料表結構翻譯成產品期待的形狀，這張表每次導入都要重做，同一產業裡結構相似得驚人，把欄位名與取值剝掉之後，留下的就是可複用的骨架。

工具跑在客戶環境裡，地端部署或客戶VPC都行，但原始資料絕不外流。往外走的只有三樣：資料表結構的形狀、轉換規則的形狀，以及失敗嘗試的類別。最後一樣其實最值錢，因為試過哪種對映、為什麼壞掉，從來不會寫進任何wiki。

乙方這邊會累積一份可檢索的導入記憶。下一個進場的工程師依產業、來源系統、欄位結構一搜，先拿到前面三次導入的對映骨架，以及當時踩過的雷。第一天從草稿開始，而不是從白紙開始。

設計的另一半在合約裡。主約裡通常有衍生資產歸屬條款，但從來沒被執行過，因為沒人看得見到底送出去了什麼。這個工具把匯出項目的稽核紀錄原樣開給客戶看，這就是賣點：客戶第一次能看清乙方帶走了什麼，乙方第一次能名正言順地帶走該帶的東西。計費按FDE席次訂閱，或者按導入次數。

成功條件

第一，去識別化方案必須過得了客戶法務。過不了，工具連裝都裝不上，後面的討論全部作廢。所以客戶可直接查看的稽核紀錄不是功能，是前提。

第二，第二個客戶開始必須真的更快。不更快，這就只是又一個文件工具，而FDE手上的文件工具已經夠多了。第一個值得設的目標是：到第三次導入時，第一條整合跑通所需的時間砍掉一半。

剩下的是選產業。模式要能重複，領域就得夠窄。保險理賠、醫院醫事、物流結算都是候選，但哪一個的資料表結構最標準化，得跟著兩次真實導入走一遍才知道，光靠推理是推不出來的。