[FDE閱讀-1] 讀《前線部署工程師》，這個職位賣的不是人力
讀《前線部署工程師》：
這個職位賣的不是人力
這本書叫《前線部署工程師（FDE）：人工智能時代的客戶價值交付秘籍》，作者范冰，早年那本《成長駭客》就是他寫的。這裡先講一件實際的事，這本書目前只有簡體版，還沒有繁中譯本，想讀得從簡中管道找。
適合誰讀，我想先說清楚。如果你手上正在做企業 AI 專案，或者負責導入工具卻總覺得卡在某個環節的主管，這本書會有共鳴。它不教你怎麼調模型，它講的是另一個問題，為什麼東西做得出來、卻用不起來。如果你的工作跟企業採購、系統整合、顧問服務沾得上邊，讀起來會更有感。反過來說，想找技術實作手冊的人，或者想看 AI 產業趨勢與投資機會的人，這本書不會給你那些東西。
我拿它來讀，原本是想弄懂一個現象，AI 喊了這麼久，為什麼多數企業買了工具、開了帳號，最後還是停在示範階段。范冰給的答案很直接，缺的是人。
他在書裡解釋這個角色時，用的方法是先講它不是什麼。這不是修辭技巧，是因為這個職位太新，正面定義反而說不清。你很難跟人解釋一個從沒存在過的角色，但你很容易說清楚它跟售前、跟外包、跟顧問哪裡不一樣。
書的第八章有一則 180 天的完整復盤，我覺得要理解這個職位到底在做什麼，最好的方式是從它遇到的第一個抉擇開始看。作者自己先做了一個提醒，這則案例的數據做過模糊處理，但比例關係和決策邏輯是真實的。我把它當成一份流程範本讀，不去糾結單一數字。
桌上擺著三個客戶
有一家做企業 AI 知識庫的創業團隊，手上同時握著三條客戶線索。第一條是預算充足的頭部券商，第二條是預算中等、痛點清楚的區域連鎖零售集團，第三條是影響力很強、但數據高度敏感的三甲醫院。
按照銷售的本能，該選券商。預算最大、招牌最亮，拿下它就是一張漂亮的成績單。
團隊卻把它否掉了。
理由攤開來看很簡單。券商那邊第一次見面就提出「全公司覆蓋」的目標，聽起來氣勢宏大，但追問下去，專案沒有明確的業務負責人，權責主體是一片模糊。這種單子接下來，你會發現自己不是在解決問題，而是在應付一個沒有主人的期待。醫院那條線的痛點是真的，但數據不出域這條合規紅線卡在那裡，交付週期完全無法預判，你答應了時間，等於給自己埋一顆定時炸彈。
最後他們選了零售集團。這家企業的財務長親自牽頭，痛點具體到不能再具體：三千多家門市的營運督導報告堆積如山，區域經理根本看不完、也統籌不了。數據基礎很亂，但條件具備，可以進場。
這個選擇在書裡被總結成一句紀律：專案排期與選擇，優先依戰略價值與學習價值判定，而不是以合約金額為導向。
我把這段讀了三遍。它不是什麼高深的策略，它就是一種克制。而這本書最打動我的地方，正是它從頭到尾都在講各種不同性質的克制。
被放棄的券商，作者還補了一段注腳。這類客戶不必直接拒絕，可以先賣一份為期兩到三週的付費診斷，交出場景優先級報告和數據準備度清單。
願意付這筆錢的，說明轉型意願是真的，後續就能順理成章談下去；連診斷都不肯投入的，只是想當年度報告裡的一個亮點，那本來就不該啟動。
團隊當時沒走這條路，直接拒絕守住了產能，卻也把一個潛力巨大的標杆客戶讓給了願意做診斷的對手。作者稱這是整個 180 天裡「唯一一個正確但可惜的決策」。
我喜歡這種寫法。它不把成功案例寫成無懈可擊的範本，它告訴你：做對了，還是可能付出代價。
進場以後，頭兩週不寫一行程式
合約簽了，團隊進場。按照一般專案的節奏，接下來該做需求訪談、畫流程圖、開始寫程式。他們派駐現場的是三個人，兩個工程師加一個行業顧問。
他們沒有馬上動手。頭兩週，一行程式都沒寫，團隊跟著區域經理跑門市。
這叫影子工作法，做法很樸素，就當那個人的影子，看他一天到底怎麼過。他在微信群裡怎麼督辦門市資料、怎麼用 Excel 把一週的報表拼出來、晚上又在催哪幾家。你不用問他需要什麼，你跟著他走一遍就知道。因為人講出來的困擾，通常是他消化過、整理過的版本，跟他實際做事的方式有落差。
跟在區域經理旁邊走了幾天，團隊發現一件奇怪的事。公司花了錢做官方系統報表，他參考得並不多；他自己做了一張表，讓店長每天手動填，他在上面看。
這裡有意思的地方在於，他不是不信任數據，官方報表的問題很具體，更新有滯後、偶爾還會出錯漏，對一線每天要做決策的人來說，慢半天就等於沒用。他自己那張手填的表不好看，但每天早上就在那裡，數字對得上他昨天看到的事。你跟他講「這個系統的數據更準」，他不會反駁你，他會禮貌點頭，然後繼續用他那張表。
如果你在這時候才恍然大悟，那你已經浪費掉前面幾個月做的所有產品文件。影子工作法的價值就在這裡，它讓你在寫第一行程式之前，就發現真正的使用現場長什麼樣。你甚至會發現，你原本要解決的問題，跟客戶真正卡住的問題不是同一個。
於是原本規劃的「完整智能數據平台」被調整掉了。三個模組、六個看板，最後只留一個最笨的功能，每天早上八點，區域經理手機收到一條異常簡報，三分鐘讀完，內容就是三千家門市前一天的銷售波動、庫存異動、投訴量變化。這個切口小到有點不好意思，設定的交付週期是六週。
這份簡報跟 BI 報表的差別不在技術，在它送達的節點，它出現在他一早打開手機、正準備開始今天決策的那一刻。書裡的復盤寫得很清楚，第 90 天之後，這份日報的自然打開率穩定在 85% 以上。要注意的是，作者在案例開頭就交代過，這則案例的具體數據做過模糊處理，但比例關係和決策邏輯是真實的。
我第一次讀到這裡，想到的是一個詞，最小可行。不是做一個能上市的產品，是做一個能在他今天的業務裡真的用上一次的東西。
書裡有句話很白。客戶嘴上說的需求，寫成規格書就是誤差；真正解決你生意的方案，往往藏在你看不上的笨辦法裡。
模型出錯的那四十八小時
系統上線第一週，出了一件事。
AI 把兩家門市的促銷流量高峰誤判成異常波動。區域經理在工作群裡直接反饋了這個情況。這種事在任何 AI 專案裡都會發生，而且一定會發生在客戶剛建立一點信心的時候。
團隊的反應值得記下來。他們沒有做過多辯解，四十八小時之內，把促銷日曆接進了模型判斷邏輯，讓系統知道這幾天本來就會爆量。同時做了一件更關鍵的事，在群裡公開向反饋的經理道謝。
我讀到這裡停了一下。這兩件事裡，技術只佔一件，道謝那件事才是關鍵。多數團隊在系統出錯時會急著證明「不是我搞錯」，因為承認誤判好像在削弱自己的專業。可是客戶要的從來不是你的正確，他要的是這個東西明天能不能用。
同一段時間，還有一個更難的關卡。
客戶那邊有一位區域總監，資歷很深，在組織裡屬於話語權很強的那種非正式核心角色。他初期對這個專案持觀望態度，不反對，也不投入，偶爾在會上丟一兩句質疑。這種人比明確反對的人更難處理，因為他從不給你把柄。
團隊邀請他參與評估規則的修訂，把他三條實戰經驗固化進系統邏輯裡。兩週之後，他變成這套系統最積極的內部推廣者，因為規則裡有他的東西，系統出的錯他比誰都急著修。
作者在書裡把這件事講得很務實，這類中間派是靠參與轉化的。你讓他動手，他才會在乎。
這個案例還有一個我覺得很妙的收尾。到第 120 天，零售集團的資訊長在季度經營會議上，主動拿出這套系統來演示。從一個被觀望的專案，變成客戶自己在高層會議上要講的東西，這比任何使用率數字都更能說明它活了。
簽約那天，他們去寫手冊
第 121 天到 180 天，專案進入收尾。照理說這是最輕鬆的階段，合約要驗收了，錢要收了，團隊該準備慶功。
他們卻在那段時間忙著做一件跟這個客戶無關的事：把這次的經驗沉澱成資產。
具體是幾份東西。一份零售行業的資料接入組件，把三千多家門市的資料欄位、清洗規則、常見缺漏整理成可套用的東西；一份異常信號評估框架，把零售業的促銷、節慶、天氣變數整理成判斷模板；還有一份門市場景的盡調清單，記錄一個陌生門市該看哪幾個細節。這些東西的讀者是下一個客戶。
結果很直接。他們拿著這個零售案例去談第二個客戶，某快消品牌的通路管理部門，兩邊的業務場景高度同源。第二個專案的交付週期比第一個縮短了四成。
我特別喜歡這個安排，因為它戳破了一種很常見的自我安慰。我們總覺得做專案很累、每個專案都在重來一次，然後把這歸因於「客戶都不一樣」。范冰的意思是，客戶確實不一樣，但你做的事有很多是同一套，只是你每次都把它當成一次性的勞務在做，做完就散掉了，沒有留下任何能給下一個客戶用的東西。
到這裡，180 天走完了。我把它重新看了一遍，發現這四段時間其實是四種不同的克制。
第一段，忍住不搶最大的單，你要的是一個能站得住的戰場。
第二段，忍住不馬上寫程式，你要的是搞清楚問題。
第三段，忍住不辯解，你要的是讓東西真的能用。
第四段，忍住不慶功，你要的是下一單的起點。
四種忍住，說到底都是同一件事。這份工作真正難的地方，不在你會什麼，而在你忍得住什麼。
它不是售前，也不是駐場外包
講完這 180 天，我們可以回頭回答那個問題了：FDE 到底不是什麼。
第一條，它不是售前工程師。
這兩者很容易被搞混，因為都要懂技術、都要面對客戶、都要在成單之前出現。差別在目的。售前的目的是贏單，他要讓客戶相信「這個方案能解決你的問題」；FDE 的目的是驗證，他要在客戶的真實環境裡證明「這個方案確實解決了你的問題」。
一個是說服你相信，一個是證明給你看。前者靠的是一場精彩的簡報，後者靠的是一個跑起來的系統。
這一條之所以重要，是因為它決定了一家公司怎麼用這個人。如果把 FDE 當售前用，他的績效就是成單率，他的壓力就是月底的數字，那他自然會挑最好講的場景、最漂亮的說法。他不會告訴你這個客戶的資料品質根本不夠，因為那會拖慢簽約。而這恰恰是 AI 專案最後失敗的最常見起點。
第二條，它不是駐場外包。這條是四條裡最容易被誤解的一條，也是台灣產業環境裡最痛的一條。
駐場外包的商業邏輯是按人天計費，一個工程師進場，一天多少錢，做了幾個月算幾個月。這個模式本身沒有錯，它清楚、透明、好估算，很多系統整合商靠它活了幾十年。
但它有一個結構性的問題，工程師待得越久，客戶就越依賴這個人；人一走，專案就停。知識沉澱在個人身上，不在系統裡。
范冰把兩者的差別列成三行對照，我覺得這三行值得直接擺出來。
合約上，一邊是按人頭計費，一邊是按階段驗收，後者驗收的是價值有沒有落地，不是工時有沒有填滿。開發上，一邊是從零開始寫程式，一邊是依託產品底座做配置與整合，因為重複造輪子的錢最後還是客戶付。驗收後，一邊是人走、專案停，一邊是人撤走、能力留在系統和客戶團隊裡。
我們的行業生態裡，按人天計費的駐場模式幾乎是默認選項。這不是誰的錯，這是市場長期以來的採購習慣，客戶習慣用「多少人、多少天」來理解一件事的價格。但你只要問一個問題就能看出差別：這個專案結束的那一天，你的客戶手上多了什麼？是一個能自己運轉的系統，還是一份需要你繼續維護的報價單。
它不是顧問，也不是開發工程師
第三條，它不是顧問。
顧問賣的是判斷，交付物是一份報告、一張路線圖、一套架構建議。這份建議通常寫得很好，讀起來也很有道理，但它不會動。報告交完，客戶內部還是那些人、那套流程、那個卡住的環節，唯一的變化是他們知道了應該怎麼做。
FDE 交的是能跑的東西。他也做判斷，但他的判斷要通過系統在真實業務裡跑一遍才算數。分野很清楚，顧問只按專案要求交付建議，不對執行環節負責；FDE 要對系統最後能不能運轉負責，目標是客戶團隊能獨立使用它。
有個案子把這件事推到極致。Anthropic 的工程師嵌進金融科技公司 FIS 的團隊，一起搭反洗錢智能體，把原本要花好幾小時的調查壓到幾分鐘。但這個合作寫明的目標，是轉移知識，讓 FIS 以後能自己搭建智能體。
這就引出一個很反直覺的判斷標準。傳統顧問的生意，建立在客戶持續需要你之上；FDE 做得好不好的標準恰好相反，只有客戶哪天不再依賴你，才算真的做成功了。
第四條，它不是傳統開發工程師。
這條聽起來最不合理，FDE 明明也要寫程式。差別在工作的方向。開發工程師是把一項能力服務給很多個客戶，寫一次程式、上線給所有人用；FDE 是把一個客戶的需求，調動很多種能力去滿足。前者追求通用，後者追求貼合。
這種貼合有多貴，看一天的時間分配最清楚。另一本講同一個職位的書，作者高承實把一個 FDE 的普通工作日切成六段來看，得到的比例是七成時間在聽和看，三成時間在動手。早上七點半他站在客戶的倉庫裡，中午跟客服一起吃便當聽抱怨，下午在資訊室翻舊系統的欄位定義。真正寫程式的時間，落在其他人下班之後。
范冰在書裡引了一位一線 FDE 的話，我很喜歡。他說，模型通常是整個流程裡最乾淨的部分，真正難的是找到那個沒寫進文件的工作流。
一個傳統開發工程師只面對乾淨的那部分，一個 FDE 要面對全部。
賣的不是人力，是一次被驗證過的價值
把四個「不是」疊在一起看，其實它們指向同一個答案。
不是售前，因為它不靠說服；不是駐場外包，因為它賣的不是工時；不是顧問，因為它交的不是報告；不是傳統開發，因為它不是把一項能力發給所有人。
那它是什麼？它是把一個抽象的 AI 能力，放進一個具體客戶的真實業務裡，跑一遍，直到有人願意為這個結果付錢。
我讀完這一段，想到一件自己行業裡的事。這個角色在歐美開始被制度化，有了名字、有了分工、有了薪資行情。我接觸到的案子裡，多數還是把它拆成「顧問訪談」加「工程師開發」兩段來發包，兩段都做完了，中間那個讓東西真正跑起來的責任，反而沒有人認領。
范冰把驗證的最小單位取了個名字，叫 MVD，最小可行部署。它是對照 MVP 提出來的。
這個對照是整本書我覺得最有意思的地方。MVP 問的是「這個產品，市場要不要」，裁判是市場；MVD 問的是「這個方案，這個客戶有沒有價值」，裁判是這一個客戶的業務結果。差一個字母，問的問題完全不同。
而且他很直白地戳破一件事，就算你的方案已經被十個客戶驗證過，第十一個客戶照樣可能失敗，因為他的資料、流程、人，全都不一樣。
這句話對做專案的人來說，可能有點刺。我們太習慣把「成功案例」當成保險，以為有了前例就可以複製。但現場不是這樣運作的。原因其實不複雜，每個客戶的資料基礎不一樣，組織慣性不一樣，痛點的形式也不一樣。價值沒辦法從別的案子裡繼承，只能在眼前這個客戶身上重新驗證一次。
這本書我只講到這裡，但我想接著說下去。接下來還有四篇，會一路走過這幾站，這個人需要什麼樣的能力、他在組織裡同時扮演哪些角色、這個行業幾乎不打廣告是靠什麼讓客戶一個帶一個、錢到底怎麼收，最後一站回到現場，看看真實的專案會遇到哪些不體面的事。
如果你只對其中一站有興趣，跳著讀也可以。但我建議至少讀完最後一篇，因為前面四篇講的都是這件事應該長成什麼樣，最後那一篇講的是它實際會長成什麼樣。
這個職位賣的不是人力，是一次被驗證過的價值。
深入閱讀范冰新書 FDE 系列 · 之一
深入閱讀范冰新書FDE系列:
讀《前線部署工程師》，這個職位賣的不是人力
一個值百萬美元年薪的職位，考的是你能不能忍住不寫程式
一個幾乎不打廣告的行業，靠什麼讓客戶一個帶一個
免費的驗證最貴，一場「明年再評估」的會議，問題出在哪
八十萬買了一套寄信設備，AI落地真正卡住的地方
歡迎訂閱我的文章，第一時間可以收到喔!
常見問題
FDE（前線部署工程師）跟售前工程師有什麼不同？
售前工程師的目標是用簡報說服客戶相信方案可行，以成單為績效指標；FDE則要在客戶真實環境中把系統跑起來，證明方案真的解決了問題。兩者差別在於一個靠說服，一個靠實際驗證結果。
為什麼FDE不等於傳統的駐場外包？
駐場外包是按人天計費，工程師離開後專案往往停擺，知識留在個人身上。FDE則是按階段驗收價值，目標是讓能力與系統留在客戶團隊裡，人離開後專案仍能運轉。
什麼是MVD（最小可行部署）？
MVD是對照MVP提出的概念，MVP問的是市場要不要這個產品，MVD問的是這個特定客戶能否從方案中獲得實際業務價值。即使方案已被多個客戶驗證過，每個新客戶仍需重新驗證一次。
這本書適合哪些人閱讀？
適合正在推動企業AI專案、負責系統整合或顧問服務的主管閱讀，書中聚焦在為何工具做得出來卻用不起來的問題。若是想找技術實作手冊或產業趨勢分析的讀者，這本書並不適合。