前面幾篇，我陸續寫過：

AI 問 Requirement

AI 找 Unknown

AI 整理 PRD

AI 做 Prototype

分開看，每一件事情都不新奇。

現在打開任何一個 AI Tool，

都可以叫它：

幫我整理需求

幫我寫 PRD

幫我產 User Flow

幫我做 Prototype

所以這篇我不太想再寫：

PM 可以怎麼用 AI。

我更想直接記錄一件事：

現在真的收到 Requirement 之後，我自己是怎麼一路用 AI 做到可以跟 User 討論的？

這個流程跟我幾年前做 Product 時，

已經有點不一樣了。

以前 Requirement 進來，我很容易先「整理」

以前 User 丟來一段 Requirement，

我的第一個動作通常是：

聽 Requirement
↓
整理
↓
畫 Flow
↓
寫 PRD
↓
跟 User Review

問題是：

如果最前面的理解就錯了，

後面寫得越完整，

有時候只是：

更完整地把錯的理解寫出來。

最近我開始刻意改掉這個習慣。

Requirement 一進來，

我第一個叫 AI 做的事情，

通常不是：

幫我寫 PRD。

而是：

幫我找現在還不能寫 PRD 的地方。

Step 1｜先把 Requirement 拆成 Known / Unknown / Assumption

我現在很常先丟這種 Prompt：

以下是一段 User Requirement。

請不要急著提出 Solution，
先幫我拆成：

1. 已確認的 Known
2. 還缺資訊的 Unknown
3. 目前只是推測的 Assumption
4. 如果要開始設計 Product，
   最優先需要問 User 的 5 個問題

不要自行補公司規則或 System 能力。

我喜歡這一步，

因為它會逼我不要太快進 Solution。

Requirement 常常看起來有兩頁，

但真正可以確定的可能只有幾句。

其他很多是：

我們猜 User 是這個意思

我們假設 API 有

我們預設這個 Role 可以看

我們以為流程本來就是這樣

AI 在這裡最有價值的，

不是幫我得到答案。

而是：

把那些還不是答案的東西標出來。

Step 2｜補完 Context，再叫 AI Challenge 一次

跟 User 補完第一輪資訊之後，

我不會立刻進 PRD。

我會再跑一次：

這是目前確認後的 Requirement。

請從 Product / User Flow / Data /
Permission / Error Handling 五個角度 Review：

1. 還有哪些矛盾？
2. 哪些 Edge Case 還沒定義？
3. 哪些條件會讓 Flow 分岔？
4. 哪些事情需要 Engineer 確認？
5. 哪些事情必須由 Product / User 決策？

不要把 Unknown 當成已確認事實。

這一步很像以前開 Design Review 前，

自己先找洞。

差別只是 AI 可以很快幫我掃一次。

真正的答案還是要：

問 User

找 Owner

查 Documentation

問 Engineer

但 Meeting 前先知道：

今天真正要問的是哪幾題。

討論通常會有效率很多。

Step 3｜不要急著寫完整 PRD，先做可以操作的東西

這是我最近工作方式改變最大的一塊。

我接過一個企業內部系統需求，

User 本身不熟技術，

需求又有不少：

Config

Rule

Front-end Flow

Back-end Setting

如果只靠文字討論，

Meeting 很容易一直繞：

你說的是這個嗎？

不是，我剛剛的意思不是這個。

那如果是另一種情況呢？

後來我乾脆先把需求做到一個可以操作的 Prototype。

大概花：

約 1 小時
做 Front-end Flow

+

約 1 小時
補 Back-end / Config Flow

不是 Production Code。

也不是把全部 Requirement 做完。

只是讓原本抽象的討論，

變成一個大家可以一起操作的東西。

Prototype 對我最大的價值，不是「展示」

以前我想到 Prototype，

比較像：

Requirement 都差不多確認了，做一個 Prototype 給大家看。

但現在我比較常反過來：

Requirement 還沒有完全確認，所以先做 Prototype。

讓 User 直接操作：

你會從哪裡開始？

這裡你預期看到什麼？

按這個之後應該發生什麼？

這個設定到底誰來改？

如果沒有資料怎麼辦？

原本用文字很難發現的 Gap，

常常在 User 按兩下之後就出現了。

所以 Prototype 從：

Communication Output

慢慢變成：

Requirement Discovery Tool

Step 4｜我會刻意記錄「Prototype 改變了哪個 Decision」

這是我最近多加的一步。

因為如果做完 Prototype，

只是得到：

大家覺得畫面比較清楚。

那價值還是有限。

我更想知道：

原本以為 A
↓
操作後發現其實是 B

原本認為這一步一定需要
↓
實際走一次發現可以拿掉

原本以為 User 會從入口 X 開始
↓
User 第一個找的是 Y

原本認為一個設定就夠
↓
實際發現有兩種不同 Role

這些才是 Prototype 真正產生的 Product Value：

它改變了 Decision。

Step 5｜最後才讓 AI 幫我補 PRD

到這裡，

我才比較願意叫 AI：

幫我整理成 PRD Draft。

我會給它：

Confirmed Requirement

Prototype Flow

User Feedback

Open Questions

Business Rules

Edge Cases

Technical Constraints

然後要求：

請整理成 PRD Draft，
但把：

Assumption
Open Question
Pending Technical Confirmation

分開標示，
不要自動補成 Requirement。

這時候 AI 寫文件真的很快。

但我覺得順序差很多。

以前很容易變成：

模糊 Requirement
↓
AI
↓
漂亮 PRD

我現在比較想要的是：

模糊 Requirement
↓
AI 找 Unknown
↓
補 Context
↓
Prototype
↓
User 操作
↓
Product Decision
↓
PRD

我現在真的會用的 5 個 Prompt

如果要把這篇變成一組可以直接帶走的 Prompt，

我大概會留這五個。

1｜Requirement Scanner

不要提出 Solution。

把以下 Requirement 拆成：
Known / Unknown / Assumption / Open Questions。

特別找出會影響 Product Decision 的缺口。

2｜Requirement Challenger

從 User Flow、Data、Permission、
Business Rule、Failure 五個角度，
找出這份 Requirement 還沒想清楚的地方。

3｜Prototype Brief

根據目前確認的 Requirement，
產生一個最低成本、可以驗證核心假設的 Prototype Brief。

不要追求完整，
列出：
Must Show / Can Fake / Need Validate。

4｜Edge Case Reviewer

假設 Happy Path 已經成立。

請列出最可能讓這個 Flow 失敗的 Edge Cases，
並分成：
User Input / Data / Permission / System / External Dependency。

5｜PRD Gap Checker

Review 這份 PRD。

不要改寫文案，
只找出：
Missing Decision
Undefined Rule
Unverified Assumption
Missing Failure Handling
Pending Technical Question。

Day 27｜AI 真正改變我的，不只是寫東西變快

如果只看工具，

最大的改變當然很明顯：

PRD 快了

Flow 快了

Prototype 快了

但實際做了一段時間後，

我反而覺得更重要的變化是：

Product Discussion 可以更早碰到真正的問題。

以前：

寫很多
↓
畫很多
↓
開發後
↓
才發現理解錯

現在我希望：

先找 Unknown
↓
快速做出東西
↓
早點讓 User 操作
↓
早點發現理解錯

AI 幫我降低的，

不只是 Documentation Cost。

而是：

把一個模糊 Requirement 變成可以被驗證的東西，需要付出的成本。

Product Principle

我現在最想用 AI Optimize 的，不是「寫 PRD 的時間」，而是從 Requirement 出現，到 Team 發現真正 Product Decision 的時間。

如果一個兩小時的 Prototype，

可以讓我們少兩週之後才發現：

原來我們理解的根本不是同一件事。

那對我來說，

這才是 AI 真正開始改變 PM 工作的方法。