AI 搶走了寫 code 的飯碗，卻開出一個它自己幹不了的職缺？
AI 讓人人兩三天做出 demo，軟體團隊還需要 PM、FDE（前線部署工程師）、RD 分工嗎？談 vibe coding 做的 demo 為何在 PoC 轉正式產品、外包驗收上線時卡關。
AI 都能寫 code 了，還需要分這麼多角色嗎
你可能也遇過：滿懷期待拿到一個 AI 兩三天做出來的 demo，看起來什麼都好，真要交付上線卻沒完沒了。問題不在那個 demo，在它背後少了幾種 AI 幫不了你的判斷。
如果 PM、FDE（前線部署工程師）、RD 現在都能靠 AI 寫 code、查資料、做 demo、整理文件，那還需要分這麼多角色嗎？這是我這陣子一直在想的問題，尤其每次把一個專案接進來、又看著它在「看起來差不多了」之後卡很久，我就更想把它弄清楚。
這問題很合理。過去很多分工，是被技能邊界切開的。PM 比較少寫程式，RD 比較少直接面對客戶，中間靠顧問或解決方案的角色把需求翻譯清楚。每個人手上有一把別人沒有的工具，分工是因為工具不能共享。AI 一進來，工具就共享了：PM 兩三天生出一個會動的 demo，RD 用 AI 補測試、查 log、寫文件，連設計、業務都能自己拉一個原型。如果分工只是分技能，那它確實該散。
我一開始也這麼想。但與其急著回答「要不要分工」，不如先看清楚一件更基本的事：AI 到底改變了 PM 和 RD 的工作型態。因為 FDE 為什麼會冒出來，答案就藏在這個變化裡。
AI 怎麼改變了 PM 的工作
過去 PM 寫規格又慢又痛，而這個痛，逼著他在動工前把需求想清楚——哪些是客戶嘴上說的、哪些是他真正在做的。而且他對技術可行性的判斷是二手的，得靠 RD 回他「這個兩週、那個做不了」來校準，節奏被 RD 的產能綁住。
AI 把這兩件事都鬆開了。PM 現在自己就能在兩三天生出一個會動的 demo，不用排 RD 的隊，也不用等規格寫完才知道方向通不通。這一兩年大家把這種做法叫 vibe coding：用嘴巴指揮 AI，很快就有個能跑的東西。這是真的進步。但代價藏得很深：寫規格不再痛，那道「為了寫清楚而被迫想清楚」的防線就消失了。而且他驗的多半是理想環境下的 happy path——用自己的乾淨資料、自己挑的情境。於是「我做出一個能跑的東西」很容易被當成「這件事值得做、而且做得起來」。
那句「功能差不多了，剩下修 bug 就好」，就是這麼來的。它不是 PM 偷懶，是 AI 讓「做出一個看起來會動的東西」變得太便宜，便宜到容易蓋過「這東西到底該做到什麼程度」這個更難的問題。
AI 怎麼改變了 RD 的工作
RD 那邊，被抹平的是「寫程式很慢」。慢的時候，RD 一行一行把模糊釘死，順手就把資料怎麼來、哪些例外要處理摸過一遍；而且需求進到他手上，通常已經被 PM 過濾、收斂過一輪。他的判斷集中在架構、效能、技術債、長期能不能維護。
AI 讓他打字的產能暴增，但有兩件事沒跟著變快。一是「想清楚邊界、扛住真實負載、出事能查」——這些的成本從來不在寫第一版 code，AI 幫不上多少忙。二是他跟客戶之間那層 PM 的過濾網變薄了，客戶會直接拿著自己用 AI 拼的原型來說「這不是能跑嗎，你們弄一下就好」。RD 被推得更靠近現場，工作慣性卻還是「為長期穩定而設計」，而且沒有人授權他用「拋棄式、只服務這一家、跑得起來就算」的方式做事——那違反他所有的工程直覺。於是他被夾在中間：上游用兩三天的速度往下丟「都能跑了」的東西，下游的產品化還是要三個月。
中間空出了一塊，沒人想站
把這兩件事擺在一起看，中間會露出一塊以前不太被看見的地方。
先講清楚：「這個需求是不是真的、在真實現場跑不跑得起來」這塊，不是 AI 才製造出來的——它一直都在，以前的專案一樣常常卡在這裡。差別在於，以前它被「慢」蓋住了。做什麼都慢的年代，PM 寫規格要好幾週、RD 實作又要好幾週；正因為慢，過程中會被迫把一些現場狀況順手碰過一遍——寫規格時被逼著想清楚、實作時被逼著面對細節。沒有人專門負責驗證現場，只是「慢」這個副作用，順便擋掉了一部分。
而且因為每一步都慢，問題爆出來的時間也被往後拖，常常拖到後期才出事。出事的時候，大家把它算成「專案延期」「需求又變了」「客戶不配合」，很少有人把它歸到同一個根上：從頭到尾，沒有人專責去確認這件事在現場到底行不行。問題一直在，只是被別的名目吸收掉了。
AI 把「慢」拿掉了。demo 兩三天就好、規格十分鐘就生出來，前面快得不得了；但「到現場驗證到底行不行」這件事的成本，一點都沒少。前面變快、這裡沒變快，那塊一直沒人站的地方，就第一次明晃晃卡在中間，藏不住了。
而這塊地，兩邊都不想站。PM 自己做的 demo 太乾淨，證明不了現場；RD 的工程直覺，又不允許他做一個明知要丟掉、不可維護的版本。它需要的是一種同時違反 PM 和 RD 慣性的工作：有人實際進到客戶的環境，拿真實的資料、權限、限制，把那個漂亮的原型逼到現場真的能動，而且心裡很清楚這一版是用過即丟的，目的只是換到一份「值不值得繼續投」的技術證據。
為什麼需要 FDE？PM 和 RD 都補不了的那塊
最直覺的反應是：那叫 PM 或 RD 多扛一點不就好了？
問題不在他們願不願意，也不在技能（AI 都給了）。問題在這三種判斷追求的成功，根本是互相打架的。對 PM 來說，成功是把方向選對、把該做到的程度抓準，所以他得相信自己的判斷、敢押方向；對 RD 來說，成功是把東西做得穩定、好維護，能長久運行，所以他會抗拒為了趕時間而妥協；但對負責現場驗證的人來說剛好相反——成功是用最快的速度確認一條路走不走得通，而且做完之後敢把那一版丟掉。
把這三種標準壓在同一顆腦袋裡，它們會互相污染。你要 PM 一邊論證價值、一邊放下樂觀，去最不友善的現場把東西弄到能跑，這是兩塊相反的肌肉；你要 RD 一邊追求穩定可維護、一邊故意做一個用過即丟的髒版本，他要嘛把它過度工程化拖慢驗證，要嘛被現場急單帶著欠下一堆技術債。
所以這塊地需要一個成功定義跟另外兩個都不同的人，專門站在這裡。這就是 FDE。簡單說，FDE（Forward Deployed Engineer，前線部署工程師）就是直接進到客戶真實環境、用真實資料和限制把原型逼到現場能動，再為「這條路值不值得繼續投」交出技術證據的人；他的成功不是把產品做完，而是用最快的速度證明一條路通或不通。就像前面說的，這塊工作一直都在，只是以前被「慢」蓋著、被當成「專案延期」或「需求變更」；現在 AI 讓它藏不住了，總得有人正面回答：這塊，到底誰負責。
PM、FDE、RD 各自在乎什麼
把「為什麼要分」講清楚之後，每個位子在乎的事就清楚了。
PM 在乎的是這件事值不值得做、該做到什麼程度。哪些是這一個客戶的特例，哪些值得收斂成平台、賣給下一個客戶。少了這個判斷，團隊很容易把每個客戶的特例都當成功能往上疊，半年後產品變成一堆專案痕跡。
FDE 在乎的是這件事在真實現場跑不跑得起來。他不信 demo，堅持有人到現場用真東西驗一遍，把「好像可以、又好像怪怪的」逼成可驗證的證據。這種判斷沒辦法外包給 AI，因為 AI 只會給你一片綠燈，不會主動說「這裡其實沒驗過」。FDE 沒被當成一個角色看待時，代價很具體：該驗的事一直被往後挪，跨兩端的功能斷在沒人負責的接縫上，每個人都覺得自己做完了，合起來卻沒人對「整套在現場能不能跑」負責。
RD 在乎的是這件事能不能長期、穩定地交付給更多客戶。這也是為什麼，一個被蓋章「差不多了」的 PoC，RD 寧可把地基整個重做，也不肯直接拿來改——他要對的不是「demo 今天動不動」，是「半年後、換十個客戶、被 AI 改過上百次，還站不站得住」。
AI 時代，還需要 PM、FDE、RD 分工嗎？
需要，而且比以前更需要。
技能那一半確實塌了，「你會什麼」越來越分不出人。但判斷那一半沒塌，反而因為東西做得太快、太像、太容易看起來「差不多了」，而更難被看見、也更容易出事。AI 能替你把每一條路都鋪好，但走哪一條、走到哪裡、這條路十年後會不會塌，得有人簽名——而 AI 不簽名，它不為任何後果負責。
與其說 AI 時代還要不要那三個職稱，不如說它逼我們把 PM、FDE、RD 看成三種觀點：同一件事，要從「值不值得做、做到哪」看一遍，從「在真實現場跑不跑得起來」看一遍，再從「能不能長期穩定地運行下去」看一遍。技能被抹平之後，真正的能力不是「會做」，而是面對一個東西時，知道該調哪幾種觀點來檢視它、把判斷建立在對的依據上。
大多數卡住的專案，不是三種觀點全缺，而是剛好缺了其中一種。有的團隊很會評估該做什麼，也養得起把東西做穩的人，卻沒有人真的進過現場，於是做出一個技術上漂亮、客戶卻用不起來的東西。有的團隊很能跑現場、demo 一個比一個亮，卻沒人替長期把關，東西越改越爛、半年後沒人敢動。也有的團隊技術很硬、現場也熟，卻一直在做不值得做的需求，把力氣花在沒人要的功能上。缺哪一種，案子就從那一種的方向裂開，而且裂的時候你往往還以為問題出在別處。很多外包或委外專案就是這樣卡住的：demo 看得到的功能都對，真要上線、要驗收、要長期維護，才發現中間那塊判斷一直沒人接。
這也是我們接案時在做的事。專案進來，我們會先看它此刻最缺的是哪種觀點——是還沒有人把「值不值得做」想清楚，是少了一個願意進你現場、用你真實資料把東西驗到底的人，還是缺一個從第一天就盯著「半年後、換更多客戶、被 AI 改過無數次還站不站得住」的人。我們不是派一個「什麼都會的人配一套 AI」就交差，而是把你這個案子當下最缺的那種觀點補上，並且真的為它負責。技能可以靠 AI 補齊，缺的那種判斷不行。
而這三種觀點裡，RD 那一種最違反直覺。明明已經有一個會動、還被蓋章「差不多了」的 PoC，直接拿來轉成產品不就好了，為什麼 RD 偏要把地基整個刨掉、重新來過？至於 RD 為什麼通常不直接拿 PoC 來改、而選擇重做，我會在下一篇〈為何 RD 不喜歡直接拿 PoC 來改〉從實際案例出發細談。
參考資料
我對 FDE 的理解，有一部分來自這些來源：