上一篇寫到，AI 已經可以很快幫 PM 生成一份 PRD Draft。

但真的做 Product 時，我越來越覺得：

不是所有 Requirement，都適合用文字確認。

有些東西寫成 PRD 很清楚：

運費類型提供三種選項：

1. 免運
2. 滿額免運
3. 固定運費

看起來沒有任何問題。

User 也可能說：

「對，就是這樣。」

但真的開始做之後，問題才會慢慢跑出來：

這三種是 Radio 還是 Dropdown？

選「滿額免運」後，
金額在哪裡設定？

可以同時設定不同地區嗎？

不同商品可以套不同規則嗎？

規則很多時怎麼管理？

已經生效的 Rule 要怎麼修改？

這時候我會發現：

一句 Requirement 描述的是「功能」，但沒有真的描述 User 要怎麼使用它。

我最近更常做的，是先把它「做出來」

例如今天我要做一個購物網站的促銷設定。

Business 說需要：

免運
滿額免運
固定運費
滿額贈

以前我可能先把所有 Rule 寫進 PRD。

現在我反而會先快速做一版後台：

運費設定

運費類型
○ 免運
○ 固定運費
○ 滿額免運

滿額門檻
[ 1,000 ] 元

適用商品
[ 全部商品 ▼ ]

適用地區
[ 台灣本島 ▼ ]

生效時間
[ 09/01 ] ～ [ 09/30 ]

然後直接拿給 User：

「如果今天要建立一個滿 1,000 元免運的活動，你會怎麼設？」

這時候得到的 Feedback，

通常會比：

「這三種運費設定可以嗎？」

具體很多。

因為 User 看到東西之後，才比較容易知道自己缺什麼

User 可能馬上說：

「等等，我們不是所有商品一起設定。」

或者：

「地區不是這樣選，我們是按照配送方式。」

甚至：

「活動上線之後不能直接改，要先關掉舊 Rule。」

這些 Requirement，

一開始未必有人會主動講。

不是因為 User 不懂自己的 Business。

而是因為：

抽象描述很難讓人想到所有操作細節。

當一個具體介面出現，

User 才開始把自己的真實工作方式投射進去。

這其實不是 AI 才出現的方法

Prototype 本來就是 Product Design 很重要的方法。

Nielsen Norman Group 很早就提倡 Paper Prototyping：在真正寫 Code 前，用非常低成本的 Prototype 測試設計，提早發現 Usability Problem。:chatgpt-content-reference{index="1"}

Google Design Sprint 對 Prototype 的定義，我也很喜歡：

Prototype 不需要真的把整個 Product Build 完。

只需要做到：

足以讓我們驗證某個 Hypothesis。

甚至不需要完整 Backend，只需要把想測試的 Flow 做到「足夠真實」。:chatgpt-content-reference{index="2"}

所以 Prototype 本來就不是：

PRD 寫完之後，把畫面畫漂亮。

它其實是一種：

Learning Tool。

AI 真正改變的是：這個 Learning Loop 變便宜了

以前 PM 當然也可以畫 Wireframe。

但如果我要測：

前台 User Flow
+
後台 Config
+
不同設定狀態
+
幾種 Rule 組合

還是需要時間。

所以通常會先：

「把 Requirement 討論得差不多，再請 Designer 開始做。」

但 AI Prototype / Vibe Coding 把這個成本往下降之後，

順序可以開始改變：

Requirement
↓
先做一個 Rough Prototype
↓
User 操作
↓
發現 Detail
↓
修改 Prototype
↓
更新 Requirement

Prototype 不再只是 Requirement 的 Output。

它也可以反過來成為：

Requirement Discovery 的工具。

例如申請 System，前台跟後台最好一起看

這是我自己做企業 System 時很有感的一件事。

如果 Requirement 只寫：

「管理者可以設定申請類型。」

看起來很簡單。

但我把前台跟後台一起做出來，

問題會變得非常具體。

後台

申請類型：差旅申請

適用對象：
[ 全體員工 ▼ ]

需要附件：
[ 是 ]

審核層級：
[ 直屬主管 ▼ ]

前台

User 看到：

差旅申請

日期
[          ]

地點
[          ]

附件
[ Upload ]

[ Submit ]

這時候 Business 才更容易開始問：

不同 Role 看到的欄位一樣嗎？

某些申請是不是不用附件？

不同金額是不是不同 Approval Flow？

後台 Rule 改了，已經送出的申請怎麼辦？

這些才是真正會進到 PRD 的 Product Detail。

所以我現在不會只問「Prototype 好不好看」

如果 Prototype 是拿來找 Requirement，

Review 時我會刻意分三層。

第一層：Task

先給 User 一個真實任務：

「請設定一個滿 1,000 元免運的活動。」

然後讓他自己操作。

不要一開始就解釋：

「這裡是運費、這裡按下去會……」

Interaction Design Foundation 在 Early-design Testing 的建議也很接近這個做法：給 User 真實 Task、觀察第一步怎麼操作，並讓 User Think Aloud，而不是一直引導。:chatgpt-content-reference{index="3"}

我真正想看的不是：

「你喜歡這個畫面嗎？」

而是：

你知不知道怎麼完成這件事？

第二層：Rule

操作過程再觀察：

哪些選項不符合真實 Business？

哪些 Rule 沒想到？

不同 Role 是否不同？

哪些設定其實會互相影響？

這一層是在補：

Business Detail。

第三層：System

最後再回來確認：

資料拿得到嗎？

API 有嗎？

Permission 合理嗎？

Rule 可以被 System 支援嗎？

有沒有 Security / Dependency？

這一層才是：

Feasibility。

所以我會把 Prototype Review 想成：

Task
User 會不會用？
     ↓
Rule
Business 真的是這樣運作嗎？
     ↓
System
我們真的做得到嗎？

這比一句：

「大家看看 Prototype 有沒有問題。」

有效很多。

還有一個基本功：Prototype 前先寫下「這次到底要驗證什麼」

Prototype 做得越快，

反而越容易犯一個錯：

因為很容易做，所以什麼都做。

但 Prototype 不應該只是 Demo。

Interaction Design Foundation 在談 Prototyping 的常見陷阱時，也特別強調：Prototype 應該先有明確問題——到底要測哪個 Assumption、回答哪個問題，而不是為了 Prototype 而 Prototype。:chatgpt-content-reference{index="4"}

所以開始之前，我會先寫：

這次要驗證：

□ User 是否理解三種運費設定？

□ 滿額免運的 Config 是否符合操作習慣？

□ User 是否需要按照商品 / 地區設定？

這次不驗證：

□ UI 視覺

□ 真實 API

□ Performance

這個小動作很重要。

因為它會提醒所有人：

我們現在不是在 Review 成品，而是在回答問題。

Prototype 越像真的，越要提醒大家它「不是真的」

這也是 AI Prototype 特別需要注意的地方。

現在 AI 做出來的畫面太完整了。

Button 可以按。

表格會動。

甚至還有假資料。

User 很容易產生：

「這不是已經做好了嗎？」

但實際上：

Data 可能是 Mock

Rule 可能是 Assumption

Button 可能只是 Simulation

Backend 根本不存在

所以我反而會刻意標記：

Mock Data

Simulated Action

Assumption

Not Connected to API

高擬真 Prototype 的確更接近真實體驗，但也有一個已知風險：User 可能把它當成接近 Finished Product，甚至把注意力放到表面細節。:chatgpt-content-reference{index="5"}

AI 讓 Prototype 更快變得很像真的，

這個風險反而更值得 PM 注意。

Day 20｜AI 讓 Prototype 從「畫需求」變成「找需求」

Day 19 我寫：

AI 可以快速生成 PRD Draft，但真正的 Product Detail，還是得靠近 Business 一層一層摳出來。

Day 20 我想再補一個方法：

不一定所有 Detail 都要靠 Meeting 一句一句問。

有時候直接做一個：

Rough Prototype
↓
給 User 一個真實 Task
↓
看他怎麼操作
↓
問他哪裡不符合真實工作
↓
把發現寫回 Requirement

會更有效率。

所以 AI Prototype 最大的價值，

對我來說已經不只是：

「以前畫 Prototype 要一天，現在一小時就好了。」

而是因為 Prototype 變便宜，

我們可以更早把抽象 Requirement，

變成一個可以：

操作、被挑戰、被否定、被修改的東西。

Product Principle

不要只用 Prototype 展示 Solution；用 Prototype 把藏在一句 Requirement 後面的 Product Detail 摳出來。

PRD 告訴我們：

「提供三種運費設定。」

Prototype 則可以讓 User 真正試一次：

「那你現在設定一個滿 1,000 元免運給我看。」

而 User 卡住、反問、修改的那些地方，

很多時候，

才是真正的 Requirement。