上一篇我整理了一份自己現在會用的 AI Requirement Checklist。

一共 10 個問題：

01 User 想完成什麼 Task？
02 為什麼需要 AI？
03 AI 需要哪些 Context？
04 Context / Data 拿得到嗎？
05 Answer 還是 Action？
06 AI 可以自己決定多少？
07 不知道時怎麼辦？
08 做錯了怎麼 Recovery？
09 怎樣算成功？
10 拿掉 AI，Problem 還成立嗎？

但 Checklist 寫出來很容易。

真正拿一個 Requirement 進來跑，才知道這些問題到底有沒有用。

所以這篇我不想再增加新的 Framework。

直接拿一個我目前接觸的 AI 應用，實際跑一次。

為了避免涉及公司內部資訊，以下會把實際的系統、資料與流程抽象化。

Case｜企業內部 HR 資訊查詢

假設今天有這樣一個需求：

相關人員需要查詢某位員工過去的工作表現，希望透過 AI 更快速取得需要的資訊。

傳統流程可能是：

需求方
↓
提出查詢需求
↓
HR 理解需求
↓
確認查詢條件
↓
進 System 查詢
↓
篩選資料
↓
整理結果
↓
回覆需求方

資料其實一直都在。

真正花時間的是：

需求從「人話」變成「System Query」，中間需要經過很多人工理解與操作。

那如果要加入 AI，我會怎麼 Review？

Checklist 01｜User 到底想完成什麼 Task？

表面上的 Requirement 是：

「希望用 AI 查員工資料。」

但這其實還不是 User Task。

再往下一層，真正想完成的可能是：

在符合權限與規則的前提下，更快速取得特定員工、特定期間、特定條件的相關資訊。

這兩句差很多。

如果把 Requirement 定義成：

做一個 AI 查員工資料。

Product 很容易直接開始想：

Chatbox
Prompt
Answer

但如果定義成：

降低取得正確資訊需要經過的人工流程。

可以設計的 Solution 就不只 Chatbot。

所以 Checklist 第一題，其實是在避免我們太早進 Solution。

Checklist 02｜為什麼這裡需要 AI？

接著我會故意挑戰一次：

這真的需要 AI 嗎？

如果查詢永遠只是：

Employee ID
+
Year
+
Data Type
↓
Query

那一個好的 Search / Filter 可能就夠了。

AI 真正有價值的地方，是 User 不一定知道 System 的 Schema。

例如 User 可能說：

「我想看看這位員工過去幾年的表現，特別看最近有沒有什麼變化。」

AI 可以先把自然語言轉成 System 可以理解的條件：

Employee = XXX
Period = Past N Years
Data Type = Performance
Focus = Recent Records

所以這個 Case 裡，我目前比較認同的 AI Value 是：

User 不需要先學會 System 怎麼查，System 開始理解 User 想查什麼。

這跟「加一個 Chatbot」其實是兩件事。

Checklist 03｜AI 需要哪些 Context？

接著開始列 Context。

至少可能包含：

Who is asking？

Who is being queried？

Which period？

Which data type？

What filters？

What is the purpose / scenario？

這一步很重要。

因為一句：

「幫我看看他的表現。」

對人來說可能很自然，

對 System 來說其實非常模糊。

AI 可以理解 Language，

但不代表它天然就有足夠的 Business Context。

Checklist 04｜Context / Data 拿得到嗎？

列完 Context，下一步不能直接假設都有。

我要繼續問：

資料在哪裡？

哪個 System 才是 Source of Truth？

有 API 嗎？

資料是即時的嗎？

資料品質如何？

這個 User 有權限取得嗎？

這時候 Requirement 往往就開始從：

「做一個 AI」

變成真正的 System Problem。

因為 LLM 就算完全理解 User 的問題，

如果後面的：

Data
API
Permission

沒有準備好，

AI 還是做不了。

Checklist 05｜Answer 還是 Action？

這個 Case 目前比較偏：

Understand
↓
Retrieve
↓
Summarize
↓
Answer

而不是：

Create
Modify
Submit
Delete

這個分類看起來很簡單，

但它會直接影響後面的 Risk Design。

如果 AI 只是查詢資料，

做錯的風險是一種。

如果 AI 可以直接修改 HR Data，

那 Permission、Confirmation、Rollback 的要求會完全不同。

所以我現在會很早把：

Answer 還是 Action？

問清楚。

Checklist 06｜AI 可以自己決定多少？

假設 User 說：

「幫我看一下這個人的表現。」

AI 可以自己理解：

「這個人」是誰

前提是 Conversation Context 已經很清楚。

但它能不能自己決定：

「表現」＝哪一種資料？

「過去」＝幾年？

要不要包含某些敏感欄位？

就不一定。

尤其企業資料還有另一個 Boundary：

AI 知道答案，不代表 User 有權知道答案。

所以完整流程可能更像：

User Intent
↓
Interpret Query
↓
Permission Check
↓
Allowed Data Scope
↓
Retrieve

Permission 本身也是 Product Logic。

Checklist 07｜AI 不知道的時候怎麼辦？

這時候就可以直接拿模糊 Query 測：

「幫我看看他的表現。」

如果「表現」可能對應很多資料，

AI 有幾個選擇：

Infer
Clarify
Confirm

不是所有資訊都值得問。

如果 Context 已經非常清楚，可以 Infer。

但如果不同理解會導致完全不同的資料結果，

那我會傾向：

Clarify。

例如：

「你想查看的是哪一段期間的正式績效紀錄？」

這比 AI 默默選一個 Definition 安全很多。

Checklist 08｜做錯了怎麼辦？

這個 Case 很有趣。

因為它不像訂票、付款那種 Transaction，

所以最重要的不一定是 Rollback。

它可能錯在：

Wrong Employee

Wrong Period

Wrong Data Source

Wrong Query Interpretation

Unauthorized Data

Unsupported Conclusion

所以它需要的 Control 反而可能是：

Source
答案從哪裡來？

Scope
這次查詢用了哪些條件？

Permission
User 可以看到哪些資料？

Traceability
結果可以追溯嗎？

Uncertainty
AI 哪裡其實不確定？

這也是我真的拿 Checklist 套下去之後，

才更明顯看到的一件事：

不同 AI Feature 的 Failure Mode 完全不一樣。

所以「Recovery」不能只想到 Retry / Rollback。

要先問：

這個 Product 最可能怎麼錯？

Checklist 09｜怎樣算成功？

最簡單的 Metrics 當然可以看：

Usage

Query Volume

Active User

但如果回到原本的 Problem，

我會更想知道：

取得資訊花的時間有沒有下降？

人工轉手次數有沒有減少？

Query 是否取得正確資料？

有多少 Query 需要 HR 再介入？

User 最後有沒有完成原本的 Task？

甚至可以開始看：

Successful Query / Task 到底需要多少人工 Touch？

因為這個 Product 真正想 Optimize 的，

本來就不是：

大家跟 AI 聊更多。

而是：

原本需要很多人工轉手的資訊取得流程，能不能變短。

Checklist 10｜拿掉 AI，Problem 還成立嗎？

最後我會真的把 AI 拿掉一次。

原本的 Problem 是：

資料存在
↓
但 User 不知道怎麼取得
↓
需要 HR 理解 Requirement
↓
轉成查詢條件
↓
操作 System
↓
整理後回覆

所以就算沒有 AI，

Problem 還是成立。

這代表我們真正想解的不是：

「公司沒有 AI。」

而是：

資訊取得過程有太多 Translation 與 Manual Handoff。

AI 是其中一種可能的解法。

它有機會把：

Natural Language
↓
Intent
↓
Query Condition

這段自動化，

讓 System 更直接理解 User。

跑完一次，我會得到什麼？

如果只是收到：

「我們想做一個 AI HR Assistant。」

很容易直接開始討論：

Model
Prompt
Chat UI
RAG

但跑完這 10 題，

Requirement 會開始變成：

Problem
降低資訊取得的人工轉手

AI Value
理解 Natural Language，轉成 Query

Context
User / Employee / Period / Data Type

Data
Source of Truth

Boundary
Retrieve / Summarize 為主

Decision
不能自行擴張 Query Scope

Permission
依 User Role 限制 Data Scope

Uncertainty
關鍵條件不清楚時 Clarify

Failure
Wrong Scope / Wrong Source / Unauthorized Data

Outcome
更快取得正確且有權限取得的資訊

這時候，

我才會覺得 Requirement 開始有 Product 的樣子。

Checklist 真正的用途，不是把 10 題全部填滿

實際工作不太可能每次 Requirement 都做一份漂亮的十題問卷。

我更想把它當成：

Requirement Scan。

一個 AI Idea 進來，

快速掃過一次：

Problem 清楚嗎？

AI Value 清楚嗎？

Context 齊嗎？

Data Ready 嗎？

Boundary 清楚嗎？

Permission 清楚嗎？

Failure 想過嗎？

Outcome 定義了嗎？

哪一格特別模糊，

下一步就先 Investigate 那裡。

所以 Checklist 的價值不是：

幫 PM 得到十個答案。

而是：

更早發現哪幾個問題，我們其實還沒有答案。

Product Principle

好的 AI Requirement Checklist，不是證明這個 Feature 可以做，而是更早找出：在開始做之前，還有哪些事情我們其實沒有想清楚。

這也是我現在會想把 Checklist 放在 Prototype、PRD，甚至 Model Selection 之前的原因。