這兩年做產品，我越來越常在需求討論裡聽到一句話：

「這個是不是可以加 AI？」

FAQ 很多。

→ 做 Chatbot？

表單很複雜。

→ AI 幫忙填？

Search 不夠好。

→ 改成自然語言？

客服很忙。

→ 做 Agent？

報表很多。

→ AI 自動分析？

每一個聽起來都合理。

而且前九天一路寫下來，我也一直在談 AI 可以怎麼改變 Journey、Search、分類、UI，甚至直接替 User 完成一些 Task。

但寫到第十天，我反而想踩一下煞車：

這個 Product Problem，真的需要 AI 嗎？

因為 AI 時代很容易把產品開發的順序反過來。

以前是：

User Problem
    ↓
Solution
    ↓
Technology

現在很容易變成：

AI Capability
    ↓
可以拿來做什麼？
    ↓
找一個 Problem 塞進去

不要因為 AI 做得到，就開始替它找問題。

如果今天有人跟我說「這裡可以加 AI」，我現在會先過 6 個 Gate。

① Friction｜User 現在到底痛在哪？

第一步甚至先不要講 AI。

先把現在的 Journey 畫出來。

例如：

找 Policy
 ↓
打開文件
 ↓
搜尋 Keyword
 ↓
讀很多內容
 ↓
找到答案

真正的 Friction 可能是 Finding Cost 太高。

另一個流程可能是：

找服務
 ↓
理解分類
 ↓
選子分類
 ↓
找到 Form
 ↓
填寫

真正的問題則可能是 User 必須先理解 System Structure。

如果連現在到底哪裡痛都說不清楚，我不會急著討論 AI Solution。

② AI Advantage｜為什麼一定要用 AI？

找到 Problem，下一題不是：

AI 可以怎麼做？

而是：

傳統方法為什麼解不好？

如果 User 找不到功能，把入口移到首頁可能就夠了。

如果只有 10 個固定選項，一個 Dropdown 可能比 Chatbot 更快。

AI 真正有優勢的，通常是傳統 Rule-based UI 很難處理的問題：

Unstructured Input
自然語言、文件、圖片

High Variability
需求組合很多

Complex Knowledge
大量文件與跨資料來源

Multi-step Task
需要理解、判斷、呼叫多個 Tool

Ambiguous Intent
User 很難用標準 Keyword 表達

如果一個 Button 就能解決，就讓它繼續是一個 Button。

③ Data Readiness｜AI 有可靠的 Source 可以工作嗎？

這是我覺得很多 AI Proposal 最容易漏掉的一題。

例如：

「我們做一個 AI Assistant 回答公司 Policy。」

聽起來很好。

但下一題應該立刻是：

它要根據什麼回答？

真的盤點後，可能才發現：

Policy A → Portal
Policy B → PDF
Policy C → SharePoint
Policy D → Excel
Policy E → 只有承辦人知道

甚至同一件事，有三份不同版本的文件。

這時候最大的問題可能根本不是：

LLM 夠不夠聰明？

而是：

Source of Truth 到底在哪裡？

我現在會把 Data Readiness 拆成四層：

Exist
有資料嗎？
 ↓
Reliable
可信嗎？
 ↓
Accessible
AI 拿得到嗎？
 ↓
Usable
格式與定義能用嗎？

Agent 也是一樣。

如果想讓 AI：

「幫我查訂單並處理退款。」

背後至少需要：

Order Data
Refund Policy
Permission
Order API
Refund API

沒有 Data、沒有 API、沒有 Permission，再厲害的 Model 也做不了。

所以有時候 AI Project 的第一步根本不是 Build AI。

而是：

Build the Foundation.

④ Interaction Delta｜AI 到底少掉了什麼？

接著我會直接把 Before / After 放在一起。

例如原本：

找到報表
↓
點「下載」

AI 版本：

打開 Assistant
↓
「幫我下載 9 月報表」
↓
「確認是 9 月嗎？」
↓
「對」
↓
下載

Technically 很 AI。

但 Product Experience 反而變差。

所以我會問：

AI 到底有沒有幫 User：

• 少 Click？
• 少 Ask？
• 少 Decision？
• 少 Search？
• 少理解 System 的成本？
• 少等待時間？

如果 AI 沒有拿掉 Friction，只是換了一種 Interaction，就不一定值得做。

⑤ Risk｜省下來的成本，值得增加的不確定性嗎？

AI 和傳統軟體有一個很大的差別：

它帶進來更多 Uncertainty。

同樣是少三個步驟：

推薦錯一間餐廳

跟：

匯錯一筆款項

完全不是同一件事。

所以不能只算：

AI 幫 User 省多少時間？

還要一起看：

Value of Automation
        vs.
Cost of Error

越容易發現、容易 Undo 的 Task，可以讓 AI 多做一點。

涉及金錢、權限、個資或不可逆操作，就需要更多 Guardrail、Confirmation，甚至不適合自動化。

⑥ Adoption｜User 為什麼會改用？

最後一題很容易被忽略。

即使前五題都成立，也不代表 User 真的會用。

上一篇寫 Capability Discovery 時，我提到：

System 做得到，不代表 User 知道做得到。

但還可以再往下一步：

User 知道做得到，也不代表他願意改用。

因為 Adoption 還受到：

• Existing Habit
• Trust
• Discoverability
• Response Time
• Learning Cost

影響。

所以 Success Criteria 不能只是：

AI Feature 上線了。

而應該回答：

User 為什麼會從 Existing Flow，切換到 AI Flow？

Day 10｜我現在會用這 6 個 Gate Review AI Feature

最後整理成一套我自己會用的 Checklist：

1. Friction
User 現在痛在哪？
      ↓
2. AI Advantage
為什麼傳統方法解不好？
      ↓
3. Data Readiness
有可靠、可取得的 Source 嗎？
      ↓
4. Interaction Delta
AI 實際少掉了什麼？
      ↓
5. Risk
做錯的 Cost 能接受嗎？
      ↓
6. Adoption
User 為什麼會改用？

其中任何一層答不出來，我都會先停一下。

尤其：

「因為現在 AI 可以做到。」

這不是 Product Reason。

Product Principle

不要問「這裡能不能加 AI」，先問「AI 到底拿掉了 User 哪一個 Friction？」

而且就算找到了適合 AI 的 Problem，也別忘了往下一層問：

我們真的有足夠的 Data、Source、API 和 Permission，讓 AI 把這件事情做好嗎？

如果答案是沒有，Roadmap 的第一步可能不是 AI Feature。

而是先把 Foundation 建起來。

AI Native Product 的價值，不是產品裡出現多少 AI。

而是：

在真正適合 AI、而且 System Ready 的地方，用它拿掉以前很難解的 Friction。