上一篇我寫到，我現在會直接用 AI 生成 HTML Prototype。
例如一個購物網站要做運費設定。
PRD 可能只寫：
提供三種運費設定：
1. 免運
2. 滿額免運
3. 固定運費
但我可以直接讓 AI 做出：
運費類型
○ 免運
○ 滿額免運
○ 固定運費
滿額門檻
[ 1,000 ] 元
適用商品
[ 全部商品 ▼ ]
適用地區
[ 台灣本島 ▼ ]
[ 儲存 ]
甚至真的可以點。
User 一操作，很多原本藏在一句 Requirement 後面的細節就跑出來了。
做到這裡，很自然會出現下一個問題：
如果 PM 自己就能做 Prototype，Designer 還要做什麼？
再往前一步：
現在 AI Coding Tool 甚至可以產生 Frontend、串 API、建立 Database。
那是不是連 Engineer 的工作也開始重疊？
我覺得答案不是「角色都不需要了」。
真正發生的是：
AI 正在讓 PM、Designer、Engineer 原本很清楚的交付邊界，開始變模糊。
傳統 Product Team 很容易長成這樣：
PM
Requirement / PRD
↓
Designer
Wireframe / UI / Prototype
↓
Engineer
Code / Production
PM 用文字描述。
Designer 把文字變成 Interface。
Engineer 再把 Interface 變成真的 Product。
這個流程不是沒有道理。
因為每一個階段都需要不同的專業與工具。
但 AI 出現之後，中間開始重疊：
PM
PRD + Prototype
↘
Designer
UX + Prototype + Design
↘
Engineer
Prototype + Code + Production
以前 PM 說：
「這裡需要一個 Dropdown。」
現在 PM 可以直接做一個 Dropdown 給大家看。
以前 Designer 做完 Prototype，Engineer 才開始實作。
現在 Designer 也可能用 AI 把 Interaction 做到接近真的。
甚至 Business User 自己都可能 Vibe Coding 一個 Tool。
每個人都開始往旁邊多走一步。
例如我用 AI 做一個申請 System。
我完全可以做出：
申請人
申請類型
日期
附件
[ Submit ]
而且看起來很合理。
但 Designer 可能會問：
User 最常用哪一種申請？
有沒有必要一次看到所有欄位？
Error 發生時 User 知道怎麼修嗎？
Mobile 上這個 Flow 還合理嗎？
這些問題不是：
畫面能不能生成。
而是：
Interaction 應該怎麼設計。
AI 讓 PM 更容易把想法變成介面，
不代表 PM 因此自動獲得完整的 UX 專業。
這個差距可能更容易被低估。
假設我用 AI 做了一個：
員工查詢 System
輸入姓名，可以查到：
Department
Title
Manager
Email
Demo 完全正常。
但 Engineer 真正要處理的可能是：
資料從哪裡來？
Source of Truth 是哪一個 System？
API 掛掉怎麼辦？
同名 User 怎麼處理？
哪些 Role 可以看哪些欄位？
Sensitive Data 能不能顯示？
需要 Audit Log 嗎？
Concurrency 怎麼辦？
Error 怎麼 Recover？
Production 怎麼 Monitor？
Prototype 很容易讓我們看到：
Happy Path。
Production 要負責的卻是：
當真實世界不照 Happy Path 走時，System 還能不能安全地活著。
以前大家看到 Prototype，
可能開始問：
「還要多久可以上線？」
現在我反而會先列一張：
UI ✓
Basic Flow ✓
Real Data ?
API ?
Business Rule ?
Permission ?
Error Handling ?
Security ?
Performance ?
Monitoring ?
Maintenance ?
這張表很重要。
因為 AI Prototype 最大的風險之一，
就是：
它太容易讓一個還有很多 Unknown 的東西，看起來像已經完成 80%。
但 UI 做到 80%，
不代表 Product 做到 80%。
如果 PM 已經可以自己做 Prototype，
我覺得 Designer 的價值反而會更集中在：
User Mental Model
Information Architecture
Interaction Pattern
Usability
Accessibility
Design System
Cross-product Consistency
PM 可以說：
「我想像大概是這樣。」
Designer 可以 Challenge：
「但 User 真的會這樣理解嗎？」
這兩件事情不是同一件事。
尤其當 AI 讓「畫一個看起來合理的 UI」越來越便宜，
合理不合理的判斷反而更重要。
Engineer 的角色也不只是：
「把 PM 的需求寫成 Code。」
如果只是生成一段 Code，
AI 的確已經很強。
但企業 Product 真正困難的通常是：
Architecture
Data
API
Permission
Security
Scalability
Reliability
Observability
Maintainability
例如 PM 說：
「這裡幫我顯示員工資料。」
AI 幾秒就可以做出 UI。
但 Engineer 需要問：
「這份資料到底應該從哪個 System 拿？」
這個 Decision 可能比寫 Component 本身重要很多。
以前：
PM 寫完
↓
交給 Designer
Designer 畫完
↓
交給 Engineer
Engineer 做完
↓
交給 QA
每個角色很容易在自己的階段工作。
但 AI 讓前期 Build Cost 下降之後，
我更期待的是：
Problem
↓
PM + Designer + Engineer
↓
快速 Prototype
↓
一起發現問題
↓
一起調整
↓
Production
也就是：
Handoff 變少，Collaboration 變早。
這可能才是 AI 對 Product Team 更大的影響。
這也是我自己現在很在意的 Boundary。
我很支持 PM：
自己做 Prototype
自己查 Data
自己跑 SQL
自己用 AI Coding
自己測 API
因為越能 Build，
越容易把想法講清楚，
也越能理解 Engineer 面對的 Constraint。
但：
Capability Expansion ≠ Role Replacement。
我會做 Prototype，
不代表所有 Interaction Decision 都應該由我決定。
我可以生成 Code，
也不代表 Production Architecture 不需要 Engineer Review。
AI 最有意思的地方，
不是讓每個人變成「另一個職位」。
而是讓每個角色：
可以多跨一步，減少中間資訊損失。
我覺得這是一個很有意思的反差。
以前 PM 不會 Coding，
反而很清楚：
「這部分我要問 Engineer。」
現在 AI 什麼都能生一點，
最大的風險反而是：
我做得出來，所以我以為我懂了。
但一個可以 Demo 的 Product，
跟一個可以：
被真實 User 使用
承載真實 Data
符合 Permission
面對 Exception
長期維護
安全運行
的 Product，
中間還有很長的距離。
所以 AI 時代，
我覺得很重要的一個能力反而是：
知道 Prototype 哪些地方是真的，哪些地方只是看起來是真的。
Day 19，我寫 AI 可以快速生成 PRD Draft。
Day 20，我開始直接用 Prototype 找 Requirement。
走到 Day 21，
PM 的確已經可以做很多以前不屬於 PM Toolset 的事情。
但我不會因此得到：
「Designer / Engineer 不需要了。」
這個結論。
我反而覺得 Product Team 正在從：
PM 寫
↓
Designer 畫
↓
Engineer 做
慢慢變成：
大家都能 Build 一點
↓
更早看到同一個東西
↓
更早 Challenge
↓
更快發現 Gap
↓
各自把專業帶進來
AI 降低的是：
把想法變成東西的成本。
但它沒有消除：
UX Judgment、Technical Judgment，以及 Product Judgment。
AI 讓每個角色都可以多 Build 一步，但「做得出來」不等於「設計得對」，更不等於「可以上 Production」。
我覺得 AI 時代好的 Product Team，
可能不是每個人的 Boundary 都守得非常清楚。
而是：
每個人都可以跨出去一點，但也知道什麼時候，需要另一個專業的人進來。
iThome鐵人賽
看影片追技術