我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
在本次 iThome 鐵人賽中，選擇「FDE 是 AI Agent 時代的最強武器嗎？」作為系列主題，一方面希望整理參與過的企業案例，另一方面試著理解 FDE 這種工作模式，究竟能對企業帶來哪些價值。
從 2021 年開始經營公司以來，客戶的產業雖然不同，但都經常提出「這個能不能用 AI 處理？」之類的需求。但隨著需求訪談與系統開發逐漸深入，實際需要解決的問題，可能和客戶最初的想法存在很大的差異。
例如原本希望開發 AI 智能客服，後來發現企業缺少完整的商機管理流程；原本希望改善工廠自動化，進入現場後卻發現報價流程可能更值得優先投入；在 ERP 導入過程中，也經常遇到企業原本仰賴人工判斷與部門默契的工作，必須隨著系統導入逐漸明確化。
也因此我開始思考，企業需要的資訊服務商，除了能夠完成軟體開發，還需要具備哪些能力，以及這些能力應該如何在專案中發揮作用。
回顧前面幾個案例系列，我認為可以整理出三個經常遇到的問題。
首先，客戶一開始提出的需求，未必是最值得優先投入的工作。在 AI 客服專案中，我們原本希望處理客戶詢問與回覆的問題，但當開始研究商機如何轉換成訂單時，才發現企業內部缺乏完整的 CRM，大量商機資料仍然需要透過 Google Sheets 複製貼上。如果直接按照原本的需求完成 AI 客服，雖然可以改善部分工作，卻未必能夠解決整個商機到訂單流程中的主要問題。
第二個問題，是企業現場存在許多沒有被明確定義的 Decision。在 ERP 導入專案中，我們遇過請購是否需要審核、料號應該合併還是拆分，以及備註欄應該如何承接跨部門資訊等問題。這些工作在過去可能依靠員工經驗處理，但當企業希望透過系統執行，就需要進一步確認規則、責任與例外情況。部分問題甚至需要由具有管理權限的人做出決定，才能繼續進行系統設計。
第三個問題，則是系統開發完成，和企業真正能夠使用這套系統之間，仍然存在不少工作。例如 ERP 導入時，即使會議中已經確認流程，仍然需要讓使用者實際操作，才能知道新系統是否符合現場習慣。在按需製造專案中，也需要同時考慮 API 接單、訂單成立條件、資料一致性，以及工廠第一線是否能夠配合新的工作方式。
這些問題分別涉及需求、技術、流程及組織管理，也很難由單一職位獨立完成。因此，我開始重新整理 FDE 在專案中需要具備的能力，以及它和過去既有角色的關係。
最近我讀到一篇 36 氪的文章，討論 FDE 和售前、產品經理、軟體工程師及專案經理的差異。作者將 FDE 拆成六種能力，再分析不同職位轉型時可能遇到的問題。
我認為這個分析方式很有參考價值，但如果結合自己前面 28 篇的實際案例，我會傾向將 FDE 的能力重新整理成五個面向：程式開發、技術選型、需求理解、溝通協調，以及落地導入。
程式開發：將需求轉換成可以使用的系統
程式開發是 FDE 很重要的基礎能力，尤其隨著 AI Coding 普及，需求確認與實際開發之間的距離，有機會進一步縮短。
過去一項功能可能需要先由顧問整理需求，再經過產品經理、設計師與工程師協作，才能完成可以讓使用者測試的版本。現在透過 AI Coding，即使原本不具備完整程式背景的人，也有機會快速製作原型，直接向使用者確認需求。當開發者本身就熟悉工作流程時，甚至可以省下大量需求交接與等待時間。
不過，完成原型和建立正式使用的系統，仍然需要處理測試、權限、異常、部署及後續維護等問題。因此，FDE 除了能夠開發功能，也需要理解程式在正式環境中的品質要求，或是與具備相關能力的工程師合作。
技術選型：選擇適合企業條件的解決方式
前面 AI 報價系列曾經討論，當 LLM 已經具備相當多能力時，是否每個問題都需要採用 LLM。
實際上，技術選型需要考慮任務性質、模型效果、運算環境、成本，以及未來如何維運。有些問題可能更適合使用小型模型、傳統機器學習，或是明確的程式規則。
同樣地，當企業希望整合 ERP、CRM 或其他既有系統時，也需要評估 API、資料同步、權限、安全性與架構的限制。
因此，我會將技術選型視為獨立於程式開發的一項能力。開發速度即使已經大幅提高，如果一開始選擇的架構不符合企業的實際環境，後續仍然可能需要付出很高的整合與維護成本。
這部分和傳統解決方案架構師（Solution Architect，SA）的工作有不少重疊，也需要具備一定的系統設計經驗。
需求理解：確認企業真正需要改善的問題
從前面的 CRM、ERP 及按需製造案例來看，需求理解可能是我在企業現場投入最多時間的工作之一。
客戶提出的需求，通常是從自己當下看到的問題開始。例如希望導入 AI 客服、改善報價效率，或是串接外部平台的 API。
但在確認系統功能之前，還需要理解企業實際的工作流程、商業模式、資料來源，以及不同部門如何協作。
尤其當企業原本沒有明確定義流程，或是同一件工作在不同部門存在不同做法時，需求訪談也需要協助企業釐清哪些規則應該保留、哪些需要調整，以及哪些 Decision 尚未完成。
我認為這項能力和產品經理、商業分析師及企業顧問相當接近。FDE 需要將這些需求理解的結果，持續連結到後續的系統開發與驗證。
溝通協調：協助不同角色制定流程與規則
企業軟體經常涉及多個部門，而各部門的工作目標與管理指標可能不同。
例如 ERP 系統如果調整了請購與採購流程，可能同時影響使用部門、採購、財務及主管的審核責任。即使大家都認為應該改善流程，也不代表能夠立即對新的工作分工取得共識。
在這種情況下，FDE 需要協助整理各方的需求、限制與取捨，讓具有決策權的人能夠做出選擇。
這和專案經理的協調工作有不少重疊，但我認為有一個需要特別注意的地方：FDE 可以協助企業釐清 Decision，卻不一定有權限直接決定企業內部的工作分配。
尤其當外部 FDE 參與客戶內部的 AI Coding 專案時，如果開始承擔進度追蹤、人員管理及跨部門協調等責任，就需要另外確認管理權限與服務範圍，避免技術顧問逐漸承擔無法有效控制的管理工作。
因此，溝通協調除了需要理解不同角色的需求，也需要清楚知道哪些責任應由客戶自己承擔。
落地導入：確認系統真正進入企業工作流程
最後是落地導入，我認為這包含系統部署、使用者測試、教育訓練、異常處理，以及正式上線後的持續改善。
以 ERP 導入為例，即使流程已經在會議裡確認，仍然需要讓使用者實際操作，才能發現系統設計和現場工作習慣之間的差異。如果導入的是 AI 系統，還需要持續確認模型效果、錯誤情況，以及使用者是否願意根據系統結果採取行動。
這也意味著，系統正式上線之後，仍然需要透過實際使用情況來驗證當初的假設，並判斷是否需要進一步調整。
落地導入和傳統導入顧問、測試工程師及維運人員的工作存在許多重疊，但 FDE 模式希望讓前期需求、技術決策與後續使用結果之間，可以建立比較緊密的回饋關係。
如果將前面五種能力放回傳統軟體開發團隊，可以發現它們原本就分散在不同的專業角色中。
Pre-sales 經常負責理解客戶需求、提出解決方案，以及協助客戶確認產品是否符合需求。SA 主要負責技術選型、系統架構與整合設計。產品經理或商業分析師負責整理需求與功能優先順序，專案經理則協調時程、資源及交付風險。軟體工程師負責開發與技術品質，而導入顧問與維運人員則協助系統正式上線及持續運作。這些角色的實際分工會因公司與專案規模而有所不同，也有不少企業原本就採用跨職能團隊，讓不同專業人員共同參與需求與交付。
FDE 的一個關鍵特點，是它重新安排了這些工作之間的協作方式，讓需求理解、技術選型、開發、溝通與落地導入，可以更密切地相互影響。以前面 AI 客服專案為例，如果需求確認完成後，就直接交由工程師開發客服功能，後續可能要等到系統驗收時，才發現整個商機管理流程仍然有其他問題需要處理。
但如果負責需求探索的人，可以持續參與系統設計、快速製作原型，並且讓使用者及早驗證，就有機會在投入大量開發資源之前，調整原本的方向。這和前面討論的 Lead Time 也有關係。當一個專案需要經過多個角色反覆交接時，除了實際執行工作所花費的時間，也需要考慮等待、溝通與重新理解需求的成本。FDE 有機會透過更緊密的協作，減少這些額外成本。
不過，我不認為每位 FDE 都必須獨立具備所有專業能力，也不認為企業採用 FDE 後，就不再需要 SA、PM 或軟體工程師。尤其在大型或複雜的專案中，仍然需要不同專業角色共同參與。FDE 可以是一位同時具備多種能力的工程師，也可以是由不同專業人員組成、共同對實際交付負責的團隊。
對我而言，重要的是需求、架構、開發與實際使用之間，能否保持足夠緊密的聯繫，並且在新的資訊出現時，持續修正原本的判斷。
如果放在幾年前，要求同一個人或小型團隊同時處理需求、程式開發與落地導入，可能需要投入相當高的人力與培訓成本。AI Coding 很明確地在改變其中大部分工作的成本結構。
當程式開發速度提高，熟悉業務流程的人有機會自行建立工具，工程師也可以更快完成原型，減少等待其他角色交付成果的時間。而當軟體提供 API、MCP 或其他可以讓 Agent 操作既有功能的方式，部分原本需要客製開發的需求，也可能直接由使用者自行完成。這些變化對外部資訊服務商具有相當大的影響。
在前一篇討論企業內部 AI Coding 能力時，我認為如果客戶已經有熟悉流程、能夠自行開發工具的員工，外部 FDE 未必需要直接參與每一項功能開發。
比較適合的方式，可能是協助企業建立軟體工程管理機制，例如版本管理、測試與正式環境、資料庫 Migration、自動化測試，以及系統部署與權限管理。當企業需要處理較複雜的資料庫架構、多角色權限、大量資料處理，或是 AI 模型、RAG 等技術問題時，外部 FDE 也可以提供架構與技術選型方面的專業能力。至於客戶內部開發人員的工作管理與進度追蹤，則需要由企業自己建立相應的管理機制，或另外明確委託外部服務商承擔。
因此，隨著 AI Coding 逐漸普及，我認為 FDE 需要提供的能力與服務範圍，也可能持續調整。
前一篇研究 Palantir 時，另一個讓我收穫良多之處，是它如何將 FDE 視為產品開發的一部分。
Palantir 在官方架構文件中，使用 Human Backpropagation 形容這套工作方式。FDE 深入企業現場，接觸實際營運問題，再將現場發現的需求與限制，持續回饋給核心產品工程團隊。Palantir 本身也有 Foundry、AIP 與 Apollo 等共通平台，讓不同企業可以建立符合自己需求的應用，同時重複使用資料管理、權限、部署與 AI 等基礎能力。所以 FDE 的價值除了改善當前專案的交付，更能協助服務商逐漸累積未來能夠重複使用的能力。
如果回到我個人的公司，雖然沒有必要立即建立一套像 Palantir 一樣龐大的平台，但仍然可以從過去的企業專案中，整理出具有共通性的經驗。例如 ERP 導入時遇到的請購審核、料號管理及流程確認問題，可以逐漸整理成需求訪談與驗收的方法。印刷報價專案中涉及的價格級距、成本計算與外發詢價，也可以幫助未來更早確認類似企業的業務規則。
在技術方面，資料整合、API、權限管理、測試與部署等工作，也有機會整理成可以重複使用的架構與模組。當然，這些能力是否值得進一步產品化，仍然需要考慮不同客戶的需求是否足夠相似，以及後續維護所需要的成本。但至少可以開始觀察，每次專案完成之後，有哪些方法、工具與經驗，能夠讓下一次相似專案更快完成。
不同企業有不同的組織規模、技術能力及營運需求。有些企業適合讓內部人員透過 AI Coding 自行開發工具，有些需要完整的軟體開發團隊，也有些可以透過購買既有產品，直接滿足大部分需求。
FDE 是否適合，仍然需要回到企業實際希望解決的問題，以及這種工作方式能否提高交付效率、減少導入風險。
不過，我認為 FDE 提供了一種有價值的協作方式。透過需求理解、技術選型、程式開發、溝通協調與落地導入之間更緊密的合作，有機會減少不同階段的資訊落差，也讓新的現場資訊能夠更快反映到系統設計與開發決策中。
至於客戶是否願意為 FDE 付更多錢？企業投資 AI 與軟體，最終還是希望增加營收、降低成本、提高效率、減少風險，或是為未來建立新的能力。服務商採用什麼工作模式，可能影響客戶對交付品質與成功機率的判斷，但客戶願意投入多少預算，仍然需要回到預期的投資效益。
另一方面，對資訊服務商而言，FDE 也可能是一種改善經營模式的方法。如果能夠透過更緊密的協作縮短交付時間，再將不同客戶現場累積的經驗轉換成可以重複使用的方法、架構與產品，就有機會在下一次專案中，降低相似工作的開發成本。
對目前提供 AI / 數位轉型服務的我來說，接下來仍然需要透過實際專案，持續觀察 FDE 模式能否在維持交付品質的前提下，降低需求探索與開發成本，並且讓每次專案累積的能力在未來繼續產生價值。
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術