從現場客製到平台收入：FDE 如何把一次性專案變成產品飛輪

FDE 模式有一個天然矛盾：客戶問題越複雜，越需要高薪工程師深入現場；但人力越重，商業模式越像顧問公司，毛利與成長速度就越難接近軟體。真正的解法不是假裝不需要服務，而是讓每一次服務都產生產品資產。

從個案中找出可以重用的最小單位

客戶 A 要做設備預測維修，客戶 B 要做品質異常追蹤，表面上是兩個專案，底層可能共用設備主檔、事件時間線、權限、告警、人工覆核與稽核紀錄。如果 FDE 只交付兩套客製程式，公司就獲得兩筆收入；若把共通結構沉澱成平台能力，公司就得到第三項資產。

這個抽象化不能太早。還沒看過足夠真實場景，就急著做『通用平台』，通常只會產生一套什麼都能做、卻沒人願意用的產品。FDE 的價值是先在現場接受複雜度，再判斷哪些是客戶特例、哪些是產業共通。

飛輪有五個步驟

• 找到高價值、可衡量的業務問題。
• 在真實資料與工作流中快速建立原型。
• 用結果與例外驗證解法，不只收集滿意度。
• 將共通模型、連接器、評估與治理機制沉澱回平台。
• 用更短時間在下一個客戶重複部署，再取得新資料。

每轉一圈，產品覆蓋的真實情境增加，交付時間應該下降，客戶價值應該更快出現。如果人數與營收永遠等比例成長，飛輪尚未形成，只是專案公司披上 AI 外套。

管理層應該追蹤四個產品化指標

第一，重用率：新專案有多少能力直接使用既有元件。第二，部署週期：從問題確認到生產上線是否逐季縮短。第三，核心修改率：是否每個客戶都要求改動產品內核。第四，回饋轉產品率：現場需求有多少被抽象為正式 Roadmap。

服務毛利也要分層看。診斷與早期探索本來就可能較重；但連接器、權限、評估、監控和標準工作流應該越來越產品化。好的 FDE 組織，會把人留在判斷力最重要的位置，把重複工作交回軟體。

FDE 不是用人力替產品補洞，而是用現場學習決定產品下一步該長什麼樣子。

這個飛輪一旦成立，企業賣的不再只是模型存取，也不是一次性顧問服務，而是一套會隨部署經驗持續進化的營運平台。

這是「FDE × 企業 AI 落地」第 5 篇。整套策展只追一個問題：AI 如何從模型能力，變成企業每天可驗證的營運能力？