AI 轉型的關鍵一步是需求轉譯：91APP 顧問如何聽懂客戶說不出口的真實需求
「我們想要辦公室更自動化」是品牌最常說的一句話，卻是幾乎無法動工的規格。FDE（前線部署工程師）的核心價值在需求轉譯：把客戶說不清楚的痛點，拆解成技術團隊接得住的規格。91APP的CDMP與個人化行銷導入現場，長期在做同一件事。
客戶說「我們想要微軟 Offiec更自動化」，這句話對嗎？沒有錯。但它幾乎不能拿來動工。
過去一年，「前線部署工程師」（Forward Deployed Engineer，簡稱FDE）這個職稱在AI產業裡從冷門詞變成搶手貨。根據人力資源網站Indeed提供給媒體的求職資料，FDE相關職缺貼文的活動量，以2025年1月為基準，一年後的年增率達729%，成長速度遠遠超過多數科技職缺。獵頭公司Christian & Timbers的調查也顯示，原本在2026年初只有5%到10%的企業計畫聘用FDE，到了第二季末，這個比例已經衝上70%，這份調查的樣本來自該獵頭公司自己接觸的客戶群，並非全市場普查，但方向值得留意。
這些數字很吸睛，但也很容易被誤讀。多數報導把焦點放在「這個職位多稀缺、薪水多高」，卻沒有回答一個更關鍵的問題：這群人到底整天在做什麼，才讓企業願意搶著要？
答案不只是寫程式的能力。真正稀缺的，是把客戶模糊的話翻譯成技術團隊能執行的規格的能力，業界把這個工作的前段稱為「需求轉譯」（Scoping）。完整的Scoping還包含範圍邊界、排除事項、資源限制與驗收條件，本文聚焦在最容易被低估、也最常出錯的那一段：把一句模糊的話翻譯清楚。
我們在91APP的CDMP、個人化行銷導入現場，不少新專案的啟動會議上都聽過類似的一句話：品牌希望「Office 更自動化」、希望「AI幫忙做決策」、希望「會員經營更精準」。這些話沒有一句是錯的，但也沒有一句能直接變成一行程式碼或一張後台設定畫面。我們最近跟幾個品牌的行銷主管聊到這個現象，發現大家都有一種說不出的心虛：知道現況有問題，卻說不清楚問題出在哪一層。這正是需求轉譯要解決的事，也是這篇文章想拆解清楚的核心工作。
這是「FDE系列」文章的第二篇。系列的主題文已經談過91APP為什麼認為自己一直在做零售版的FDE，之後還會有幾篇分別深挖「速度不是重點」「換皮顧問的爭議」「技術落地的最後一哩路」和「怎麼分辨真假FDE」。這篇專注在第一關，也是最容易被低估的一關：需求轉譯。
一句話拆成三層：客戶說的、客戶真正卡住的、技術能接的規格
「Offcie 更自動化」這句話之所以難處理，是因為它同時包含三個不同層次的資訊，而這三層被壓縮成同一句話說出來。我們把它拆開來看：
- 字面陳述：「我們想要更自動化」，這一層所有人都聽得懂，但沒人能拿去動工。
- 隱含痛點：某個流程每天要花人力手動處理、而且容易出錯，這一層要靠追問才會浮現。
- 可執行規格：具體要用哪些資料、觸發哪個條件、輸出到哪個通路、多久驗收一次，這一層技術團隊才能真正開始動手。
這是本文為了說明轉譯過程而畫的三層拆解，並不是什麼複雜的模型，重點只有一個：客戶只負責講出第一層，而且往往連自己都不確定第二層是什麼。如果顧問或工程師照單全收第一層就開始寫規格，做出來的東西大概率是一個「技術上能跑，但沒解決任何人痛點」的系統。
哈佛商業評論早年考證過一句在商業圈流傳極廣、卻查無實據出自福特本人的話：如果他問顧客要什麼，顧客會說要一匹更快的馬。這句話雖然真偽存疑，但它精準點出一個真實現象：顧客描述需求時，用的是自己既有經驗裡最熟悉的詞彙，而不是解決方案本身該長什麼樣子。品牌講「Office更自動化」，心裡想的可能是「不要再有人半夜手動核對Excel」，但這句話本身完全沒說出「核對哪張表、跟哪個系統對帳、多久對一次」。把第一層直接當成規格去執行，等於把「要一匹更快的馬」直接理解成去育馬場找更快的馬，而不是去想顧客真正要的是更快抵達目的地。
Palantir 怎麼把「翻譯」做成一門生意：FDE的起源與工作方法
FDE這個職稱不是這兩年才冒出來的新發明。根據數位時代BusinessNext的報導，2011年Palantir把原本分開的解決方案工程師與整合工程師合併為單一職能，稱為前線部署工程師，直接坐進客戶的辦公室裡，貼身觀察現場人員怎麼操作、卡在哪裡。當年很多人覺得這套模式太貴，沒辦法像純軟體產品那樣規模化，算是一種昂貴的顧問服務。
這種「貼身觀察、反覆追問」的做法，其實一般成熟的需求訪談也會做；真正把FDE跟傳統顧問拉開差距的，是FDE同時要對後續的建置、整合與部署結果負責，不是交完一份規格書就退場。LeadDev引述顧問Piotr Kraus的說法，FDE真正倚重的能力，是敢對客戶提出的方案提出質疑，並且用數據與證據支撐替代方案，技術深度反而其次。FDE的工作起點，是先追問「客戶說的話，有多少比例經得起檢驗」，然後才動工；照單全收，只是把翻譯的責任丟回給客戶自己。
「陪客戶一路做到成功」這種邏輯，半導體業其實早就有類似的服務模式。聯發科早年鎖定白牌手機市場推出turnkey整合方案，靠的正是一群深入客戶產線現場的現場應用工程師（FAE），從零組件選型、設計導入一路陪到量產爬坡。FAE跟FDE的核心邏輯相通：不是交付一份規格書就結束，而是留在現場，跟客戶一起把技術真正用進日常工作流程裡。
91APP的顧問、CS與導入團隊，長期在做同一件事，只是換了產業。我們在跟品牌開會員經營健檢會議時，通常不會一開始就問「你想要什麼功能」，而是先問「你現在的會員分級標準是什麼」「私域溝通現在是手動發送還是有自動化工具」「大檔期間的決策是靠經驗還是靠數據」。這些問題聽起來瑣碎，但每一題都在把「我們想要精準行銷」這種抽象陳述，往下拆解成「現在卡在哪個環節、資料完整度到哪裡、要解決的第一個具體場景是什麼」。這正是需求轉譯的第一步：先搞清楚現況，才有資格談要往哪裡去。
為什麼「客戶說什麼就做什麼」會讓多數AI專案打水漂
需求轉譯聽起來像是流程上的細節，但它決定的其實是整個AI導入專案的存活率。
麻省理工學院NANDA研究計畫在2025年7月發表的初步研究報告《The GenAI Divide: State of AI in Business 2025》，以300個公開揭露的AI導入案例、52家企業的結構化訪談與153位企業主管的問卷調查為基礎，得出一個驚人的結論：儘管企業在生成式AI投入了300億到400億美元，仍有95%的組織拿不到任何實質回報，只有5%的整合式先導計畫真正創造出顯著的商業價值。報告特別點出，這個落差的根源不是模型品質不夠好，也不是法規限制，而是多數企業在把AI工具嵌進實際工作流程時，缺乏足夠的「學習」與轉譯過程，讓通用工具停留在個人使用的層次，始終無法真正嵌入組織的營運節奏。
同一份報告還有一個容易被忽略、但對品牌選擇合作對象很有參考價值的數字：向專業廠商採購並建立合作關係的AI專案，部署成功的比例約達67%，完全靠企業內部自建的專案，成功比例約為33%，前者大約是後者的兩倍。報告作者也誠實提醒，這是受訪企業的自陳結果，不必然證明是合作模式本身造成成功，也可能反映不同企業原本的風險偏好與技術能力差異。即使有這層保留，這個方向仍然呼應本文的主張：花時間蹲進客戶的業務現場、把每個模糊詞彙都問到能落地為止，比憑一己想像去猜客戶要什麼更容易成功。
這也呼應我們在CDMP相關文章裡反覆談到的一個判斷：當每個品牌都用得到AI工具，最後拉開差距的關鍵，回到誰能定義問題、誰做取捨、誰下判斷，模型大小或介面好不好看反而其次。需求轉譯，就是「定義問題」這件事的具體工作方法。很多品牌買過看起來很厲害的AI Agent demo，廠商展示環境裡的順暢操作，跟真實業務環境裡資料破碎、系統老舊、跨部門權責不清的複雜狀況，是完全不同的兩回事。差距往往就出在，導入前有沒有人願意花時間把「更自動化」這種話，翻譯成「哪個部門的哪個流程、用哪些資料、多久要看到什麼改變」的具體規格。也難怪我們在另一篇文章分析生成式AI在電商行銷的落地困境時，同樣觀察到多數品牌卡在資料品質與流程整合這一步，而不是模型能力不夠。
91APP在 CDMP 導入現場怎麼做需求轉譯
把這套邏輯放回91APP服務品牌的日常，需求轉譯是貫穿整個導入過程的持續動作，不會只發生在專案啟動那一次訪談裡。
- 盤點現況，而不是蒐集願望清單。我們會先確認品牌目前的會員數、各通路觸及率、有沒有在做分級、註冊會員的首購轉換率大概落在哪個區間。這些問題的目的不是評分，而是找出品牌口中「更自動化」這句話，實際對應的是哪一段現有流程。
- 找到「每天在跑這個流程的人」，而不是只問決策者。品牌高層說出來的痛點，往往是被層層彙報過濾後的版本；真正卡關的細節，通常藏在第一線操作人員的抱怨裡。這也是為什麼91APP的CS與導入顧問，習慣直接坐下來看客戶怎麼操作後台、怎麼手動整理報表，而不是只憑一次會議的簡報內容就動工。
- 把每個模糊詞彙換成可以驗收的規格。舉個常見的場景：品牌講「我們想要精準行銷」，實際攤開來看，是第一線行銷專員每個月要手動去後台撈生日名單、再手動排LINE訊息與簡訊發送折扣券，耗時又追蹤不到誰真的因為這張券回來消費。需求轉譯要做的，是把這句話換成「用CDMP自動篩選當月生日、且30天內未消費的會員，透過LINE自動發送指定折扣券，並追蹤7天內的轉換率」這種可以直接動工、也可以驗收的規格。最小限度的產出物，通常是一份寫清楚「現況流程、使用資料、觸發條件、驗收指標、負責人」的簡短規格，而不是一份長篇願景報告。
- 把導入過程中發現的坑記錄下來，往回反饋。一個品牌在資料串接上踩過的雷、在腳本設計上發現的邊界案例，如果只停留在那個專案裡沒有沉澱，下一個品牌還是會重複踩同樣的坑。這也是為什麼我們認為客戶成功團隊的角色，早就不只是回答問題，而是持續把現場學到的東西，轉化成能重複使用的分析框架與判斷邏輯。
需求轉譯也不是每次都划算。如果資料根本不存在、流程還在頻繁變動、真正能拍板的人不在場，或是本來就有現成的標準設定可以解決，硬要投入一輪完整的轉譯過程，反而是浪費時間。判斷值不值得做，本身也是需求轉譯的一部分。
品牌在找AI導入夥伴前，可以自己先做的準備
需求轉譯的責任不會只落在顧問或FDE一方。品牌在找合作夥伴之前，也可以先做幾件事，讓後續的轉譯過程更有效率：
- 先盤點「現在到底怎麼做」，不要急著描述「想要什麼」：畫一張簡單的流程圖，標出哪些環節要手動下載Excel、哪些系統之間目前沒有串接，這比列一張功能願望清單更有價值。
- 找出每天實際執行這個流程的人，邀請他一起參加評估會議：不要只讓行銷經理或協理代為轉述，主管的描述經過整理，往往會漏掉最關鍵的操作細節與例外狀況。
- 把每個抽象詞彙自己先追問一次：講「更自動化」或「精準行銷」的時候，試著換成一個具體場景，例如「針對30天內未消費的會員，在LINE推播特定新品」，能先幫顧問省下一半的探問時間。
- 問清楚合作對象提供的是一次性交付，還是願意陪著長期修正：需求轉譯不是簽約前的一次性動作，導入後的實際使用情況通常會推翻部分原始假設，需要有人願意持續調整。
- 確認導入過程中發現的問題，會不會被真的紀錄與反饋：一個好的合作關係，應該讓每一次踩坑都變成之後少走的彎路，而不是每個專案各自從零開始。
真正被低估的能力，不是寫程式，是聽懂話
FDE職缺一年成長超過七倍，聽起來像是一場技術人才的軍備競賽，但寫程式的能力只是門檻。決定專案能不能落地的關鍵，是能不能把一句含糊的話，拆解成別人聽得懂、也做得到的規格，然後留在現場，把新發現的問題聽進去。
品牌不需要先學會講出完美的需求，才有資格談AI轉型。真正該問的問題，是找的合作夥伴，願不願意花時間把「Office更自動化」這句話，一層一層拆到能動工的地方，並且在做完之後，繼續留在現場，把新發現的問題聽進去。這件事91APP的導入顧問團隊已經做了很多年，只是過去沒有一個時髦的職稱去描述它。現在它有名字了，但工作的方法沒有變。
常見問題
Q1：什麼是「需求轉譯」（Scoping）？跟一般的需求訪談有什麼不同？
A1：需求轉譯是把客戶用日常語言描述的模糊痛點，拆解成技術團隊能直接執行的具體規格，包含要用哪些資料、觸發條件、驗收標準。跟一般需求訪談的差異在於，轉譯強調追問與挑戰客戶的原始說法，而不是照單全收記錄下來就結束。
Q2：為什麼客戶自己說的需求常常不準確？
A2：客戶描述需求時，用的是自己既有經驗裡最熟悉的詞彙，而不是解決方案本身該長什麼樣子。加上真正卡關的操作細節，往往藏在第一線執行人員手上，而不是在做決策的主管口中，兩者之間的落差就是需求轉譯要補上的部分。
Q3：91APP的顧問或CS團隊具體怎麼做需求轉譯？
A3：先盤點品牌現有的會員數、通路觸及率、分級標準等現況資料，接著直接觀察第一線操作人員怎麼處理流程，再把模糊詞彙換成可驗收的具體規格，最後把導入過程中發現的問題記錄下來，反饋成可重複使用的判斷邏輯。
Q4：預算有限的中小品牌，也需要做這麼細的需求轉譯嗎？
A4：需要，而且更需要。中小品牌可調動的資源有限，一旦把預算花在轉譯不完整的規格上，試錯的代價相對更高。品牌可以先從盤點現有流程、找出一個具體場景開始，不必一次涵蓋所有通路。
Q5：需求轉譯做得好，多久能看到成效？
A5：初版規格通常可以在專案啟動階段的數週內完成，但這只是需求轉譯的起點，不是終點。導入後的實際使用情況經常會推翻部分原始假設，後續執行的準確度會持續影響整體成效，實際時程則取決於品牌選定的第一個場景複雜度。
Q6：需求轉譯跟找一般顧問做診斷有什麼不同？常見的誤解是什麼？
A6：關鍵差異在於是否持續蹲點與反饋，而不是交付一份診斷報告就結束。常見的誤解是以為需求轉譯只發生在專案啟動前，事實上導入後實際使用情況經常會推翻部分原始假設，轉譯需要貫穿整個過程。