上一篇寫到，在 Requirement 最前面，AI 不一定要急著幫 User 寫一份漂亮的 BRD / URD。

它可以先幫我們把：

Problem
User
Scenario
Pain
Impact
Success

一個個問清楚。

但真的拿到一份 URD 之後，PM 的工作才剛開始。

因為 User 把需求寫完，不代表：

這個 Requirement 已經可以直接進 Development。

以我現在做企業內部產品的經驗來說，一份 URD 進來之後，我通常還是要：

看需求
↓
找不清楚的地方
↓
問 User
↓
查資料
↓
找 Engineer 確認
↓
開 Meeting
↓
會後再補資訊
↓
更新 Requirement

有時候 User 只寫了一句：

「希望 System 可以自動帶出 User 的相關資料。」

背後 PM 可能就要查半天：

到底需要哪些欄位？

資料在哪個 System？

有沒有 API？

API 有沒有這些 Field？

如果沒有，要不要申請？

申請要多久？

有沒有 Permission？

如果資料要給 AI 使用，
是不是還有額外的權限限制？

這些事情 AI 不一定知道答案。

但我最近覺得：

AI 不需要知道答案，光是更早幫 PM 發現「我還缺哪些答案」，就已經很有價值。

我以前 Review Requirement，比較像是在腦袋裡找洞

拿到一份 URD，我通常會邊看邊想：

這裡怪怪的。

這個是不是沒講？

這個我要問 Engineer。

等等，剛才那個 Rule 跟下面是不是衝突？

有經驗的 PM，確實會越來越知道哪些地方要注意。

但問題是：

這件事很吃注意力。

尤其 Requirement 一複雜，可能同時包含：

Business Rule
Data
API
Permission
Role
Flow
Exception
System Dependency

很容易開完 Meeting 才突然想到：

「啊，剛剛忘記問這個。」

然後再約下一次。

所以現在我會多做一步：

先讓 AI 幫我做第一輪 Requirement Review。

第一件事：不要叫 AI「幫我整理需求」

這是我覺得很容易踩的坑。

如果我把 URD 丟進去說：

「幫我整理這份需求。」

AI 通常會給我一份非常漂亮的 Summary：

Background
User
Requirement
Expected Benefit

但這些東西原本文件裡就有。

真正對 PM 有價值的不是：

它寫了什麼？

而是：

它還沒寫什麼？

所以我現在會更想把 Requirement 拆成：

Known
已經確認什麼？

Unknown
還不知道什麼？

Assumption
哪些事情目前只是我們的假設？

Next Action
下一步怎麼確認？

這四個欄位看起來很基本，

但我覺得非常實用。

例如 User 說：「希望自動帶出組織資料」

第一輪可以先拆：

這時候 AI 還沒有替我解決任何 Requirement。

但它已經把：

「我好像還有很多東西要查。」

變成：

「我接下來有七件事情要確認。」

對我來說，這就是提效。

第二件事：不知道答案時，不要叫 AI 猜，叫它幫我準備問題

例如我不知道公司到底有沒有某個 API。

如果 AI 沒有公司內部的 API Documentation，

我不會問：

「公司是不是有這個 API？」

因為它根本沒有 Source。

但我可以問：

「針對這個 Requirement，我應該跟 Engineer 確認哪些問題？」

AI 可以先幫我整理：

1. 現在是否已有相關 API？

2. API Response 包含哪些 Fields？

3. 資料多久更新一次？

4. 目前 System 是否已經有 Access？

5. 如果沒有，需要走什麼申請流程？

6. 預估 Lead Time 多久？

7. API Failure 時有沒有既有處理方式？

接著我拿這些問題，

去找真正知道答案的人。

這裡 AI 的角色不是：

Answer Provider

而比較像：

Question Preparer

我覺得這是 PM 使用 AI 很實際、也很容易被低估的一種方式。

第三件事：Meeting 前，先把能 Async 解決的問題拿掉

Requirement Review 很常發生一件事：

八個人進 Meeting，

第一個問題：

「這個 API 有嗎？」

Engineer：

「我回去確認一下。」

第二個問題：

「這個資料可以給 AI 用嗎？」

相關 Owner：

「這個我要問一下。」

第三個問題：

「User 到底需要哪三個欄位？」

User：

「我確認一下。」

最後一小時開完，

得到：

「好，那大家確認完我們再約下一次。」

這種 Meeting 我覺得最可惜。

如果 AI 第一輪已經幫我把 Open Questions 整理出來，

Meeting 前就可以先分：

可以 Async 回答
→ 會前先確認

需要查資料
→ 先找 Owner

需要大家做選擇
→ 留到 Meeting

所以 AI 不一定讓我們：

不要開 Meeting。

更實際的是：

不要把「回去查一下」留到 Meeting 裡。

第四件事：Meeting 結束，再讓 AI 做一次 Gap Check

我覺得這也是非常實用的一步。

因為 Requirement 最麻煩的通常不是第一次寫。

而是：

開完三次 Meeting 之後，到底現在的 Requirement 是哪一版？

假設我有：

Original URD
+
Meeting Notes
+
最新討論結論

我可以讓 AI 幫我比一次：

Confirmed
✓ User Role
✓ Required Fields

Changed
△ 原本即時更新
→ 改成每日更新

Open
? API Permission
? Error Handling

New Requirement
+ 管理者可以手動 Override

這時候 AI 幫我的不是 Summary。

而是：

Gap Check。

哪些已經關掉？

哪些改了？

哪些還 Open？

有沒有 Meeting 新冒出來、但原本 URD 沒寫的 Requirement？

這些才是我真正需要知道的。

我現在會把 Requirement Review 想成這個 Flow

URD
 ↓
AI First Review
 ↓
Known / Unknown / Assumption
 ↓
Open Questions
 ↓
找對的人確認
 ↓
Meeting
 ↓
AI Gap Check
 ↓
Requirement Ready

這套方法沒有很炫。

AI 也沒有自己去 Call API、查完所有 System、替 PM 做 Decision。

但它解決的是一個很真實的問題：

PM 很多時間，其實不是花在做 Decision，而是花在發現「還有什麼沒確認」。

我會直接這樣問 AI

如果明天拿到一份新的 URD，我可能會直接用：

請 Review 以下 Requirement。

不要自行補完缺少的資訊，
也不要把假設當成已確認的事實。

請整理：

1. Known
目前已經明確確認的資訊。

2. Unknown
還有哪些資訊需要確認？

3. Assumption
目前有哪些隱含假設尚未驗證？

4. Questions
下一步應該詢問哪些問題？

5. Owner
每個問題建議向 User、Engineer、
Business Owner、Data/System Owner
或其他哪個角色確認？

6. Next Action
建議查文件、Async 詢問、
Meeting 討論，還是需要進一步驗證？

最後列出：
「開始寫 PRD 前，最優先需要確認的 5 件事」。

我不會期待 AI 一次把 Requirement 做完。

但至少在第一次 Meeting 以前，

我已經可以多想一輪。

AI 提效，不一定要從「自動完成」開始

我們講 AI 提效，很容易想像：

AI 自動寫 URD
AI 自動寫 PRD
AI 自動查 API
AI 自動做 Prototype

但真的回到每天工作的場景，

我反而覺得很多提效來自一些很基本的事情：

少漏一個問題

少來回問一次

少開一次 Meeting

少發現一個太晚的 Dependency

少把 Assumption 當成 Requirement

每一件可能只省 10 分鐘、30 分鐘。

但一個 Requirement 從 User 提出到真的 Ready，

中間可能來回好幾輪。

這些小地方累積起來，

才是 PM 真正感受到的效率差異。

Day 18｜AI 不一定要知道答案，先幫 PM 找出「還缺哪些答案」

Day 17 我寫的是：

AI 可以在 User 提 Requirement 時，幫忙把問題問得更清楚。

到了 PM 接手之後，

我覺得下一步不是馬上：

「幫我生成 PRD。」

而是先問：

「如果我要真的開始做，現在還有哪些事情沒有確認？」

API 到底有沒有，

還是要查真正的 Documentation。

Permission 能不能拿，

還是要問真正的 Owner。

Business Rule 怎麼定，

最後還是需要人做 Decision。

但 AI 可以先幫 PM：

找洞、列問題、準備 Meeting、追 Open Item。

Product Principle

AI 不需要知道公司的所有答案；光是幫 PM 更早知道「還缺哪些答案」，就已經能省掉很多來回。

對我來說，

這可能也是 AI 改變 PM 工作很實際的一步：

不是直接取代基本功，而是讓基本功做得更完整、更快。