產品經理寫需求、設計師畫介面、工程師把規格變成產品，是科技團隊行之有年的接力賽。但生成式AI正在改寫交棒方式。
現在，產品經理可以做出可點擊的功能流程，設計師可以用真實資料測試互動，工程師也能在動手建置前並排比較多個原型。但更高的流動性與互補性，代表傳統的「部門」定義鬆動了嗎？
Anthropic的Claude Code負責人Boris Cherny認為，真正鬆動的是「先寫文件，再交給下一個職能實作」的工作流程。當更多人能直接產出可操作成果，團隊的瓶頸也從「誰能把東西做出來」，移向「什麼值得做、如何做到可上線，以及誰來收拾與維護」。
Cherny近期在一篇X貼文中提出5種「工作原型」，正好提供一套觀察框架，它的價值不在於預測哪些職稱會消失，而是把焦點從部門名稱轉回產品需要完成的工作。
AI先改變的，不是職稱，而是交接物
有類似觀察的產業人士，不只有Cherny。
例如Figma產品長Yuhki Yamashita觀察，AI讓更多人具備「做產品」的能力後，速度可能製造虛假的進展感。
因此團隊真正的優勢不再只是「更快上線」，而是知道「什麼值得上線」。Figma因此會把多個可互動原型並排比較，先驗證不同方向，再決定投入哪一個。
另一篇Figma官方案例則提到，會計軟體公司FloQast的使用者體驗主管，以模擬後端與接近真實的資料製作程式碼原型，因而提早發現「畫面看起來合理，實際流程卻行不通」的問題。
這類原型沒有完全取代產品需求文件（PRD），但讓原本寫在文件裡的假設，可以更早被操作、比較與推翻。
Anthropic內部也出現類似變化。該公司公開的Claude Code使用案例顯示，產品設計團隊會把Figma設計稿交給代理寫程式、執行測試並反覆修正；設計師則在設計階段就處理錯誤狀態、邏輯流程與系統狀態。
換句話說，工程、產品與設計的邊界沒有消失，而是更多討論能以「可運作的東西」為共同語言。
5種工作原型，分別推進產品哪一段？
Cherny提出的5種原型，並不對應特定部門：
- 原型者（Prototyper）：大量提出並測試新點子，多數實驗不會上線，任務是快速縮小探索範圍。
- 建造者（Builder）：把概念轉成正式產品或基礎設施，補上測試、權限、效能與部署等條件。
- 清理者（Sweeper）：簡化介面與程式碼、移除不再需要的功能，控制產品與系統複雜度。
- 成長者（Grower）：持續調整既有產品，改善產品市場契合度（product-market fit，簡稱PMF）、留存與使用情境。
- 維護者（Maintainer）：確保成熟系統的安全、可靠性、速度與成本效率，讓產品能在規模擴大後穩定運作。
一名工程師可以同時是建造者與維護者，一名設計師也可能兼具原型者與清理者；Cherny認為，多數人會橫跨2至3種原型。
這套分類的前瞻性在於，補上傳統職稱沒有回答的問題：這個人最擅長把產品從哪個狀態，推進到哪個狀態？
當「做出來」變容易，清理與維護反而更稀缺
大家都在說AI讓寫程式、畫設計變快了，但很少人討論「速度」背後的代價。
Anthropic的研究發現，工程師利用AI產出的東西變多了，但如果團隊只是一味的把這些產出塞進產品裡，結局通常是災難性的：過度的技術債、難以維護的架構，以及沒人在意的無用功能。
Boris Cherny的觀點給了我們一個極佳的框架：「清理者」與「維護者」的地位將會超越「建造者」。
因為執行（Coding）可以大量委派給AI，但方向判斷與架構整頓，永遠是人類專業知識的最後堡壘。
如果你是產品團隊的領導者，請檢查一下：你的團隊KPI是否正在懲罰那些願意花時間「刪除冗餘功能」的人？如果有的話，你們可能正處於加速累積負債的風險中。
對管理者而言，重點不是改職稱，而是找出缺口
企業不必急著取消工程、產品與設計部門。這些職稱仍承載專業標準、決策責任、資安權限與職涯制度，不能只靠「人人都能做」取代。
更實際的做法，是在招募、組隊與檢討流程時多問3個問題：團隊是否只獎勵新增功能？誰有權停止錯誤方向？誰明確負責清理與維護？
AI降低的是產出第一個版本的門檻，不是打造好產品的全部難度。未來團隊的差異，未必在於誰擁有最模糊的跨職能職稱，而在於能否讓探索、落地、整頓、成長與維護都有人承接。
資料來源：Boris Cherny、Anthropic1,2,3、Figma1,2
＊本文出自《數位時代》，原文標題：工程師與PM的價值被AI重寫？Claude Code負責人點名：未來團隊最缺的不是「建造者」，而是這2種人
延伸閱讀：
Micro LED是什麼？為何能成光電產業的CPO新機會？
AI課程學習地圖！Claude、Google、微軟⋯免費線上課一次收，完成還能拿證書
責任編輯：陳芊吟
核稿編輯：倪旻勤
