一張線材報價，為什麼要在業務和工程之間來回三到五次？
客戶寄來圖紙，業務先轉給工程人員判讀 UL、VDE 等安規，再查料件、計算 BOM。工程算完後，業務還得把資料逐筆輸入 CRM 建立成本單。客戶若修改規格，這段路又要重跑一次。
這是電子線材與連接器製造商木子原本的報價日常。同仁每天花時間搬資料、等回覆，主要卡點其實是安規知識、料件成本與客戶資料分散在工程經驗、Excel 和 CRM 裡。
Data-DI 沒有先規劃一套包辦所有工作的 AI 系統。我們和木子選定「BOM 後段自動建立 CRM 成本單」這一段：資訊主管整理 CRM 的 API 文件，工程端整理安規知識與不同材質的計算規則，再由 AI Agent 讀取資料、比對規格、進行反向驗證並建立成本單。利潤比例與主管審核仍由人決定。
依木子專案前後紀錄，完成後的報價生成時間縮短至兩分鐘內，業務與工程的往返時間減少約 80%，手動輸入錯誤率也從 20% 降至趨近於零。這些是木子在特定流程下的成果，不代表每家企業都會得到相同數字。客戶真的用過這項功能後，才知道下一步還想解決什麼。合作範圍因此從報價助手，繼續發展成符合內部流程的專屬工作台，再增加可處理多項工作的助手。
我們當時沒有使用 FDE 這個名稱，但工作方式已經很接近：工程角色直接參與客戶的工作情境，先解一個具體問題，陪著系統進入日常工作，再根據使用紀錄與現場回饋持續修改。
這種從一項工作開始、使用後接著修改的工程方式，正是 FDE（Forward Deployed Engineer，前線部署工程師）和一次性交付的主要差別。
FDE 通常同時參與問題判斷、程式開發、系統部署與使用後修正。這組責任可以由一位工程師承擔，也可能由固定合作小組共同負責。工作不會停在需求轉交、展示或驗收；系統開始使用後出現的新問法、例外規則與資料缺口，也要有人接著處理。
有些公司的 PM、FAE 或軟體工程師，本來就會直接和客戶討論問題、修改正式系統並查看後續使用情況，他們的工作便可能和 FDE 高度重疊。若工作仍停在需求轉交與進度協調，換成 FDE 職稱也沒有改變原本的合作方式。
企業可以用四個問題判斷眼前的合作是否具備 FDE 特徵：
四件事若分散在不同角色手上，每次修改都得重新說明背景。這時企業需要先把責任接起來，是否另設職稱可以之後再決定。
近年國際 AI 業者動作頻頻，FDE 也從少數軟體公司的內部角色，開始被寫進正式企業服務。
把三家的做法放在一起看，工程人員都會直接碰到業務問題、企業資料、程式與正式使用結果。模型能力持續改變，企業反而會把不少時間花在兩件事上：「到底要拿 AI 做哪件事」以及「第一次使用後要怎麼改」。
即使大型 AI 業者正在把這類工程服務制度化，也不代表 FDE 已經普及，更不代表每家企業現在都該新增這個職缺。台灣企業眼前更該確認的是：原有合作方式能不能承接使用後才出現的需求。
傳統專案中的顧問訪談、系統整合、PM 管理與驗收仍然重要。它們讓預算、責任、資安與時程有清楚邊界。AI 專案多出的難題，是許多需求在第一次訪談時還不存在。
以木子的報價流程為例，開始處理後，才看得見圖紙格式的差異、安規判讀的例外、不同材質該走的計算方式，以及哪些決定必須留給主管。這些情況在系統碰到真實資料後才會出現，無法只靠第一次訪談問完。
我們將這段變化整理成「三次確認」：
三次確認讓每一輪討論都有真實資料可看，並不需要為此增加三輪會議。若工程角色只收到一張修改單，通常只看得到「要改什麼」；持續參與的 FDE 還能知道使用者為什麼要改，以及這次修改會不會影響前後流程。
資策會 MIC 在 2024 年 11 月調查 316 位台灣電子資訊製造業的企業主管與主要部門人員。在已實踐 AI 的受訪企業中，八成面臨資料相關挑戰。MIC 也指出，資料是否可用，往往要進入執行階段才看得出來；企業應先確認應用情境，再找出現有資料與需求之間的差距。[4]
FDE 是一組需要有人承擔的責任，不一定是一個現在就要開出的職缺。企業可依同時進行的 AI 工作數量、內部工程能力與資料限制，選擇三種做法：
若現在只有一項需要驗證的工作，先讓專案型角色從需求確認跟到正式使用，通常較容易看清楚所需人力。當多個部門都有系統要持續修改，而且外部交接已經比內部培養更費時，再評估全職 FDE 會比較有依據。
還有一個常被忽略的判斷：供應商是否只有展示與工作坊，還是會修改正式系統、陪同測試，並承接啟用後的問題。前者能協助企業理解工具，後者才接近本文所說的 FDE 合作。
木子的第一階段只處理報價流程中最卡的一段。這個選擇讓成效能用報價時間、部門往返與輸入錯誤來檢查，也讓工程與業務能針對同一件事回饋。
客戶使用後認為有幫助，才提出更多貼近內部流程的需求。第二階段因此發展成專屬工作台，後來再增加能處理多項工作的助手。這裡所說的「多項工作」，都是經過確認後逐項加入，不代表一個助手可以處理公司所有事情。
如果一開始就替木子畫出完整的萬用助手藍圖，我們很可能把時間花在尚未發生的假設。先讓報價進入日常工作，則能用每次真實使用回答下一步：哪項需求值得增加、需要哪些資料、誰要審核，以及原有系統怎麼接。
木子的經驗也形成 Data-DI 對 FDE 的判斷：每一次建置都要接得住上一次的使用經驗，顧問待在客戶身邊多久反而不是關鍵。企業除了增加功能，也會留下已整理的知識、串接方式、判斷規則與人工檢查點。
AltaBots.ai 是企業級 AI Agent 平台。Data-DI 以接近 FDE 的合作方式，依需求提供 AI 建置與顧問協助。平台負責承載 AI Agent、知識庫與工作流程；顧問與工程協作則把企業的工作規則、資料和既有系統接進來，並依正式使用情況繼續調整。
第一次談需求時，我們會先把 Bot 數量和模型名稱放在旁邊，問清楚哪項工作值得處理、誰每天在做、目前卡在哪個步驟，以及什麼結果可以用來判斷這次投入。
企業內部仍要有人提供資料與權限、說明例外、參與測試，並決定哪些商業判斷不能交給 AI。Data-DI 可協助把這些條件轉成可測試的系統，處理串接與修改，再一起查看使用後出現的問題。
如果想自行比較其他做法，可延伸閱讀自建 AI Agent 與 ChatGPT 的差異，以及選擇 AI Agent 顧問時的實務檢核點。
這類合作沒有適用所有企業的固定報價與時程。費用會受到工作範圍、資料整理程度、串接系統數量與權限要求影響；正式估價前，要先確認第一項工作、可用資料與驗收方式。若先做 AltaBots.ai PoC，可用三週作為一個驗證週期：第一週確認需求與測試資料，第二週建置並由企業測試，第三週整理回饋並決定是否繼續。正式專案仍須依串接與資料情況另行估算。
責任也要在開始前寫清楚。企業要提供資料與權限、指定能決定優先順序的負責人，並安排第一線使用者參與測試；Data-DI 負責把已確認的條件做成可測試的系統，處理串接與後續修改。若結果未達事先約定的指標，雙方要根據紀錄決定補資料、縮小範圍或停止，不把未完成的問題留給單一部門。
不需要先寫一份完整規格書。準備以下五項內容，就足以開始第一次討論：
Data-DI 的第一次討論，會先協助判斷問題適不適合由 AI Agent 處理、需要哪些資料、哪些判斷必須保留人工，以及應先從哪一段開始。若你已有一項反覆發生、牽涉多人或多個系統的工作，歡迎預約諮詢，一起確認適合現有角色承接、採專案方式合作，還是已經需要內部 FDE。
[1] OpenAI。（2026.05）。OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence。OpenAI。
https://openai.com/index/openai-launches-the-deployment-company/
[2] Microsoft。（2026.07）。Microsoft Frontier Company: AI engineering that amplifies and protects your intelligence。Microsoft Blog。
https://blogs.microsoft.com/blog/2026/07/02/microsoft-frontier-company-ai-engineering-that-amplifies-and-protects-your-intelligence/
[3] AWS。（2026.06）。Introducing Forward Deployed Engineering for Partners: Winning the Future of Enterprise AI。AWS Partner Network Blog。
https://aws.amazon.com/tw/blogs/apn/introducing-forward-deployed-engineering-for-partners-winning-the-future-of-enterprise-ai/
[4] 資策會產業情報研究所（MIC）。（2025.03）。八成電子製造業面臨資料挑戰，企業如何透過資料工程突破困境。MIC。
https://mic.iii.org.tw/research.aspx?id=710
