上一篇，我把前 22 天寫過的東西重新整理成六個問題：

UNDERSTAND
↓
DECIDE
↓
ACT
↓
CONTROL
↓
MEASURE
↓
BUILD

整理完之後，我開始想：

如果明天工作上真的收到一個新的 AI Requirement，這張圖到底要怎麼用？

所以這一篇，我想把前面的思考再往實務推一步。

假設明天 User 跑來說：

「我們想在這個 System 裡面加 AI。」

以前的我可能很快開始想：

• AI 可以放在哪裡？
• 要不要做 Chatbot？
• User 可以問哪些問題？
• UI 怎麼設計？

但現在，我反而會先把 Solution 放旁邊。

先問下面這 10 個問題。

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

第一題甚至不是：

AI 要做什麼？

而是：

User 原本想完成什麼？

例如 User 說：

「我希望 AI 可以幫我查公司規定。」

這句話背後可能其實有很多不同 Problem：

不知道去哪裡找
↓
找到了，但文件太長
↓
看不懂規定
↓
看得懂，但不知道自己的情況適用哪一條

這四種 Problem，需要的 Solution 完全不同。

可能是：

• Better Search
• FAQ
• Summary
• RAG
• Personalized Answer
• Agent

甚至可能根本不需要 AI。

所以第一步，我會逼自己先把這句話寫清楚：

When ___, User wants to ___, but currently ___.

如果連 User 真正想完成什麼都還說不清楚，我暫時不會急著討論 Model。

02｜為什麼這裡需要 AI？

這是我現在很喜歡問的一題。

因為 AI 太容易直接變成 Solution。

看到大量文字：

做 AI Summary。

搜尋很難：

做 AI Search。

流程很長：

做 AI Agent。

客服問題很多：

做 AI Chatbot。

但我現在會先問：

Rule-based 能不能解？

Search 能不能解？

Filter 能不能解？

Workflow Automation 能不能解？

傳統 UI 能不能解？

如果傳統 Solution 已經：

• 便宜
• 穩定
• 可預測
• 好維護

那 AI 不一定比較好。

所以問題不是：

這裡能不能放 AI？

而是：

AI 到底解決了哪個傳統 Product 很難解的問題？

03｜AI 要理解哪些 Context？

假設我們確認這裡真的需要 AI。

下一題就是：

AI 需要知道什麼，才能把事情做好？

例如 User 說：

「幫我看看我還剩多少假可以休。」

表面上只有一句話。

背後可能需要：

User Identity
+
Employment Type
+
Leave Balance
+
Leave Policy
+
Current Date
+
Previous Application
+
Special Rule

所以我現在會開始把 Context 拆成：

User Intent
+
User Context
+
Business Context
+
System Context

因為 LLM 再聰明，缺少 Context 還是只能猜。

很多時候真正的問題不是：

Model 不夠聰明。

而是：

System 根本沒有把它需要知道的 Context 給它。

04｜這些 Context / Data，System 真的拿得到嗎？

第三題很容易停在 Product 想像。

第四題開始回到現實。

假設 AI 需要：

User Profile
Order History
Policy
Real-time Data

那我要繼續往下問：

• 資料在哪裡？
• 有 API 嗎？
• 是即時資料嗎？
• 誰才是 Source of Truth？
• Data Quality 怎麼樣？
• AI 有 Permission 拿到嗎？

這也是我最近越來越有感的一件事：

很多 Enterprise AI Problem，最後不一定是 Model Problem。

真正卡住的可能是：

Data
API
Permission
Integration

AI 可以理解 User 想要什麼，

不代表 System 有能力把需要的東西交給它。

05｜AI 是要 Answer，還是要 Action？

這題會直接改變整個 Product 的複雜度。

例如：

「我還有幾天特休？」

可能只是：

Question
↓
Retrieve Data
↓
Answer

但如果 User 說：

「幫我請下週五特休。」

就變成：

Understand Intent
↓
Check Balance
↓
Check Policy
↓
Create Application
↓
Submit
↓
Return Result

兩句話看起來很像，

背後其實是完全不同的 Product。

因為只要從 Answer → Action，

就開始需要考慮：

Tool
API
Permission
State
Error Handling
Audit Log

所以我現在會很早確認：

我們是在讓 AI 回答問題，還是在讓 AI 操作 System？

06｜哪些事情 AI 可以自己決定？

到了這裡，才真正進入上一篇提到的 DECIDE。

假設是訂餐：

推薦餐廳
→ AI 可以

根據歷史偏好排序
→ AI 可以

幫 User 選一個品項
→ 看情況

套用優惠券
→ 看 Rule

付款
→ User Confirm

我目前會特別看四件事：

Uncertainty
Risk
Reversibility
Authorization

錯了沒什麼影響，而且很容易復原，

AI 可以多做一點。

但如果錯了會產生明確成本、涉及權限，甚至無法復原，

User Control 就應該更早回來。

所以：

AI 做得到，不等於 AI 應該自己決定。

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

這題很容易在 Demo 裡被忽略。

Demo 通常都是：

User 說清楚
↓
AI 理解正確
↓
資料完整
↓
Success

但 Production 一定會遇到：

「幫我訂明天的。」

訂什麼？

「跟上次一樣。」

哪一次？

「幫我找便宜一點的。」

多少算便宜？

這時候 Product 要決定：

Ignore
Infer
Clarify
Confirm

不是永遠都：

「請提供更多資訊。」

也不是永遠讓 AI 自己猜。

真正要設計的是：

哪個 Unknown 重要到值得打斷 User，再問一次？

08｜如果做錯了，可以怎麼 Recovery？

只要 AI 開始碰到真實資料或執行 Action，

我現在就會開始問：

如果它做錯呢？

例如：

選錯資料
↓
呼叫 API
↓
部分成功
↓
第二個 API Failed

接下來怎麼辦？

可能需要：

Retry

Rollback

Stop

Escalate

Human Takeover

但不同 Product 的 Failure Mode 也不一樣。

交易型 Agent 可能最在意：

能不能 Rollback？

資訊查詢型 AI 可能更在意：

查錯 Source 怎麼辦？

涉及企業資料時可能更在意：

回傳了 User 沒有權限看的資訊怎麼辦？

所以 Recovery 不是最後才補的 Error Message。

而是 Product Design 的一部分。

09｜怎樣才算這個 AI Feature 做對了？

這一題我以前很容易留到上線前再想。

現在反而想提前問。

因為如果 Requirement 只寫：

Launch AI Assistant。

上線後很容易只剩：

多少人點？

多少人問？

多少 Conversation？

但真正應該回到：

User 原本的 Task 有沒有變好？

例如：

查規定
→ 找到正確答案的時間有沒有下降？

客服
→ Issue Resolution 有沒有提高？

申請
→ Completion Rate 有沒有提升？

Agent
→ Successful Task 有多少？

甚至還可以繼續問：

需要 Retry 幾次？

需要多少人工介入？

花多少 Token？

Latency 可以接受嗎？

如果一開始連 Success Criteria 都說不清楚，

可能代表我們連：

為什麼要做這個 Feature？

都還沒有完全想清楚。

10｜如果把 AI 拿掉，這個 Problem 還成立嗎？

最後一題，是我會拿來逼自己冷靜的一題。

先把：

LLM
Chatbot
Agent
Copilot

全部拿掉。

重新問一次：

我們真正想解的是什麼 Problem？

如果拿掉 AI 之後，整個 Requirement 突然不知道在做什麼，

那我們可能只是想：

做一個 AI Feature。

而不是在解一個 Product Problem。

但如果拿掉 AI 之後，我還是可以很清楚地說：

User 是誰

他卡在哪裡

現在為什麼很麻煩

我們希望改變什麼 Outcome

那 AI 才比較像是一個真正被選擇的 Solution。

而不是 Requirement 的起點。

把 10 題放在一起

最後整理成這張 Checklist：

01｜User 想完成什麼 Task？

02｜為什麼需要 AI？

03｜AI 需要哪些 Context？

04｜Context / Data 拿得到嗎？

05｜Answer 還是 Action？

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

07｜不知道時怎麼辦？

08｜做錯了怎麼 Recovery？

09｜怎樣算成功？

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

如果對應上一篇整理的六層：

UNDERSTAND
01 / 02 / 03 / 04

DECIDE
06 / 07

ACT
05

CONTROL
08

MEASURE
09

BUILD
04 / 10

實際工作時，我當然不會每次都照著 1 到 10，

跟 User 開一場兩小時的 Meeting。

我比較想把它當成一份：

AI Requirement Review Checklist

一個新的 AI Idea 進來，

快速掃過一次。

哪一題答不出來，

那裡可能就是下一步真正需要 Investigate 的地方。

AI Requirement 最危險的地方，可能是太快進入 Solution

現在做 AI Demo 真的太容易了。

一句：

「我們做一個 AI 幫 User 自動填。」

可能半天就能看到 Prototype。

這當然是好事。

但也因為太快，

很容易直接跳過：

Problem
Context
Data
Boundary
Risk
Outcome

直接進入：

Prompt
Model
UI
Demo

最後做出一個：

看起來很 AI，但不知道到底改善了什麼的 Feature。

所以寫完前面 23 篇後，

如果現在再收到一句：

「我們想加 AI。」

我的第一個反應反而不會是：

可以怎麼做？

而會先問：

等一下，User 到底想完成什麼？

Day 24｜這不是標準答案，是我現在的 AI Requirement Checklist

這 10 題不是我做了幾十個 AI Product 後，

驗證出來的 Industry Standard。

我自己的 AI Product 經驗也還在累積。

它比較像是：

寫到第 24 天，加上目前實際做 Product 時，我最怕自己漏問的 10 件事。

之後一定還會改。

但至少目前，

它提醒我不要因為：

AI 可以做

就直接跳成：

我們應該做

下一篇，我也準備直接拿一個自己目前接觸的 AI Requirement，

把這 10 題真的跑一次。

看看 Checklist 寫在文章裡是一回事，

碰到真實的 Data、Permission、Context 和 System Boundary 時，

又會長成什麼樣子。

Product Principle

AI Feature 的起點不應該是「AI 可以做什麼」，而是「User 到底想完成什麼」；後面的 Context、Decision、Action、Control，才決定 AI 應該做到哪裡。