AI讓寫程式更快卻成災難？Anthropic警告：狂塞功能恐變技術債，未來這2種人最稀缺

landrover1211

摘要：AI讓跨部門交接從文件提前到可操作原型。Claude Code負責人Boris Cherny的 5 種工作原型，提供產品團隊重新分工的觀察框架。
1.生成式AI正改變產品開發流程，產品、設計與工程之間的界線變得更模糊，團隊開始以可操作原型取代部分文件溝通。
2.Anthropic提出5種工作原型，包括原型者、建造者、清理者、成長者與維護者，重點不在職稱，而是每個人如何推動產品不同階段。
3.隨著AI降低開發門檻，真正稀缺的能力將轉向方向判斷、產品整頓與長期維護，而非單純把功能做出來。


產品經理寫需求、設計師畫介面、工程師把規格變成產品，是科技團隊行之有年的接力賽。但生成式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降低的是產出第一個版本的門檻，不是打造好產品的全部難度。未來團隊的差異，未必在於誰擁有最模糊的跨職能職稱，而在於能否讓探索、落地、整頓、成長與維護都有人承接。