FDE 能不能規模化？答案不在擴編，而在雙向知識蒸餾

先看結論：企業買的不是模型，而是完成工作的能力

FDE 最常被質疑的問題，是重交付是否注定隨營收線性增加人力。報告提出『雙向蒸餾』作為答案：第一層把客戶員工腦中的經驗、規則與例外，轉成 Agent 可用的知識、工作流程與標準作業程序；第二層再把標竿專案的介面、測試、失敗案例與產業模式，寫回廠商的平台。真正規模化的 FDE，不是把更多工程師派到更多現場，而是讓每次現場學習都降低下一次部署成本。

這個題目值得獨立拆解，因為企業 AI 已經走到第二個階段。第一階段比的是模型能不能回答，第二階段比的是系統能不能在資料不完整、權限複雜、流程跨部門的環境裡，穩定交付可衡量結果。FDE 能不能規模化？答案不在擴編，而在雙向知識蒸餾不是技術名詞的排列組合，而是一個組織、工程與財務必須同時成立的問題。

運作機制：把人的經驗翻成 Agent 可執行的規則

資產沉澱可以沿著四層演進：先做高頻技能模組與 ERP、CRM、知識庫等連接器；再形成產業範本；客戶數增加後，把共通的業務物件、關係、權限與例外整理成產業本體模型；最後由平台統一管理版本、測試、監控與發布。這條路徑不要求第一天就建一座龐大知識城堡，而是讓已驗證需求逐步上升到共用層。

FDE 的價值是把客戶現場變成產品研發的一部分。前線團隊先找出高價值工作流程，再把資料介面、規則、權限、測試資料集與例外處理做成系統；專案結束後，還要把可共用部分沉澱成技能模組、連接器、產業範本與平台能力。少了最後一步，FDE 就容易退化成高價外包。

實務上應先畫出原有流程的輸入、判斷、工具、輸出與例外，再決定哪些環節交給 Agent、哪些需要人工核准。這個順序很重要：若先拿模型找題目，團隊容易做出技術可行但商業低頻的功能；若先找出高成本、高等待或高錯誤的流程，再設計資料與執行環境，投資報酬率才有機會被驗證。

財務視角：從專案收入走向能力複製

財務上應觀察三條曲線：同類客戶上線天數是否下降、每位 FDE 支撐的年約收入是否上升、軟體與用量收入占比是否提高。服務收入本身不是壞事，它可以替產品買到市場知識；但若服務毛利、交付週期與人均產出多年不變，就表示知識沒有轉成可複用資產。理想狀態是客戶收入成長快過交付人力，新增毛利逐步由平台而非工時貢獻。

財務長應把成本拆成五層：場景診斷、資料與系統串接、模型推論、執行框架、上線後的人工作業。初期毛利偏低不必然代表模式失敗，因為第一批客戶可能同時支付產品學習成本；但下一批同類客戶若沒有明顯縮短交付週期，代表知識沒有資產化。最重要的曲線，是每一元新增收入需要多少新增工程人力與模型成本。

收入品質也要分開看。一次性顧問費能證明客戶願意付錢，訂閱與用量收入則更能反映系統已進入日常流程；成果分成若能建立清楚基線，可能提高上限，但也會帶來歸因與合約爭議。健康的商業組合通常是以前期服務完成導入，再讓軟體、技能模組與執行量成為後續擴張主體。

執行方法：從一個高價值流程開始

每個專案結束時，除了驗收客戶功能，還要辦一次產品化審查：哪些介面可成為標準連接器、哪些失敗案例要進共用測試集、哪些規則屬產業共通、哪些只能留在客戶層。資產需要擁有者、版本與採用統計，否則只是資料夾裡的簡報。FDE 的績效也應包含『被其他專案重用的資產』，避免組織只獎勵準時救火。

導入時應先定義成功與失敗。成功不只包含平均任務時間下降，也包括錯誤率、人工覆核、法遵事件與使用者採用；失敗則要能被分成模型、資料、權限、工具、流程或組織責任。分類清楚後，每次錯誤才會變成測試資料與產品改進，而不是群組裡又多一張『AI 怎麼又壞了』的截圖。

反方論證：重交付也可能只是昂貴的人力生意

知識抽象也有過度風險。兩家企業看似使用同一 ERP，實際權限、會計政策與組織責任可能完全不同；太早做成標準範本，會把第一個客戶的做法誤當產業真理。平台化應以多個案例驗證，並允許客戶層覆寫與版本差異。所謂本體模型不是把現實硬塞進一張圖，而是建立可演進的共同語言。

FDE 是否可規模化，要看收入與人力的相對速度，而不是工程師人數。健康模式下，同類客戶第二次部署會更快、所需人天更少、可複用資產占比更高；若每個新客戶仍要從頭訪談、串接與改寫，營收再漂亮，也只是把專案公司穿上 AI 外套。

此外，報告整理的數據包含企業調查、公司案例、產品公告與研究判斷，可信度與時間點並不完全相同。本文保留原始頁碼，並把已發生事實、廠商所述規畫與延伸分析分開呈現。對快速變動的 Agent 市場而言，最危險的不是判斷暫時錯，而是把尚未驗證的規畫寫成已經實現的財務成果。

台灣企業可以怎麼用：先做流程資產負債表

台灣軟體商與顧問公司最有機會的資產，往往是長年累積的產業規則與介面經驗。過去這些經驗跟著資深顧問走，現在可以透過本體模型、技能模組、測試集與連接器變成公司資產。建議先選一個熟悉產業，盤點過去十個專案的重複工作，從重複最高、風險最低的部分開始產品化。

接下來可固定追蹤：1、同類客戶上線時間；2、每位 FDE 支撐的年約收入；3、資產跨專案重用次數；4、客製層逐步上移到平台層的比例。這些指標同時涵蓋技術、流程與財務，能避免團隊只挑對自己有利的數字。對台灣企業而言，最務實的起點通常不是成立一支龐大 AI 部門，而是選一條跨資料、跨系統、又能直接衡量成本或營收的流程，讓小型 FDE 團隊與業務負責人共同完成第一個生產閉環。

最後要記住，真正的護城河不是 Prompt 數量，而是企業願不願意把規則、失敗案例與決策邊界持續沉澱。模型會升級、單價會下降、工具名稱也會換季；留在公司裡的本體模型、測試資料集、連接器、技能模組、權限設計與營運紀錄，才是能在下一輪技術變化中繼續複利的資產。