過去的產品開發是一條清楚的接力線：「產品經理寫需求、設計師畫介面、工程師把規格變成產品。」但生成式AI正在改寫這條線的協作方式。今天，產品經理可以做出可點擊的功能流程、設計師能用接近真實的資料測試互動、工程師也能在正式開發前就比較好幾個原型。
近期一則廣受討論的觀察，來自Anthropic旗下Claude Code的負責人Boris Cherny。他點出一個關鍵：真正被AI改變的不是職稱本身，而是「先寫文件、再交給下一個職能實作」的工作流程。當更多人能直接產出可操作的成果，團隊的瓶頸也從「誰能把東西做出來」，轉向「什麼值得做、如何做到能安全上線，以及誰來收拾與長期維護」。
這個轉變，正好呼應我們在協助企業數位轉型時的長期體會。以下我們借用這套框架，談談它對台灣中小企業與系統落地的實際意義。
## AI先改變的，不是職稱，而是「交接物」
Figma產品長Yuhki Yamashita也有類似觀察：當AI讓更多人具備「做產品」的能力，速度反而可能製造出虛假的進展感。因此團隊真正的優勢，不再只是「更快上線」，而是知道「什麼值得上線」。
這一點我們感受很深。在許多專案裡，畫面看起來合理、Demo跑得漂亮，真正接上企業既有流程與資料後，卻發現關鍵環節根本走不通。能用接近真實的資料及早驗證流程，遠比多做幾個好看的原型更有價值。
## 五種工作原型，分別把產品推進到哪一段？
Cherny提出的五種工作原型並不對應特定部門，而是描述一個人最擅長把產品從哪個狀態推進到哪個狀態
- 原型者（Prototyper）：大量提出並測試新點子，多數實驗不會上線，任務是快速縮小探索範圍。
- 建造者（Builder）：把概念轉成正式產品或基礎設施，補上測試、權限、效能與部署等條件。
- 清理者（Sweeper）：簡化介面與程式碼、移除不再需要的功能，控制產品與系統的複雜度。
- 成長者（Grower）：持續調整既有產品，改善產品市場契合度（PMF）、留存與使用情境。
- 維護者（Maintainer）：確保成熟系統的安全、可靠、速度與成本效率，讓產品在規模擴大後依然穩定運作。
實務上，一個人往往橫跨兩到三種原型：一名工程師可以同時是建造者與維護者，一名設計師也可能兼具原型者與清理者。這套分類真正的價值，是補上傳統職稱沒有回答的問題——「這個人最擅長把產品從哪個狀態，推進到哪個狀態？」
## 當「做出來」變容易，整頓與維運反而更稀缺
Anthropic的研究也提醒：工程師靠AI產出的東西變多了，但如果團隊只是一味把這些產出塞進產品，結局往往是災難性的——過度的技術債、難以維護的架構，以及一堆沒人在意的無用功能。
這正是我們最想強調的一點。撰寫程式（Coding）這件事，越來越可以大量委派給AI；但方向判斷、架構整頓與長期治理，始終是人類專業的最後堡壘。換句話說，在AI時代，「清理者」與「維護者」的價值，只會超越、而非低於「建造者」。
給正在導入AI與新系統的企業主一個提醒：請檢查你的團隊KPI，是否正在懲罰那些願意花時間刪除冗餘功能、整理架構的人？如果是，你們可能正在加速累積看不見的負債。
## 對管理者而言，重點不是改職稱，而是找出缺口
企業不必急著取消工程、產品或設計部門。這些職稱仍然承載著專業標準、決策責任、資安權限與職涯制度。更務實的做法，是在招募、組隊與專案檢討時多問三個問題
- 團隊是否只獎勵「新增功能」？
- 誰有權喊停錯誤的方向？
- 誰明確負責清理與長期維護？
AI降低的是產出第一個版本的門檻，而不是打造一個好產品的全部難度。這也是我們一直以來的定位：作為企業的系統整合與數位轉型夥伴，我們在意的不只是「把系統做出來」，更包括依循ISO 27001等治理標準，把安全、可維護與可長期運作一併交付。因為真正決定一套系統能走多遠的，往往不是它上線那一天，而是它上線之後的每一天。