最近打開很多 AI Product，都會看到一個很熟悉的畫面：

乾乾淨淨的首頁，中間只有一個 Chatbox。

How can I help you today?

沒有複雜的 Menu，也不用先理解產品架構。

但如果今天是我第一次使用，我反而常常會想：

所以……你到底可以幫我做什麼？

我可以問問題？

可以查我的資料？

可以幫我修改資料？

可以直接執行任務？

還是只能聊天？

AI 讓產品入口變得前所未有地簡單，卻也帶來另一個 Product Problem：

當所有功能都藏進一個 Chatbox，User 要怎麼知道它們存在？

傳統產品很複雜，但至少「看得到能做什麼」

以前我們很常嫌 App 的 Menu 太多。

假設打開一個企業系統：

假勤
薪資
差旅
福利
個人資料
我的申請

看起來確實不性感。

但它至少有一個優點：

Capability 是 Visible 的。

User 看一眼就知道：

原來這裡可以查薪資。

原來可以申請休假。

原來可以改個人資料。

UI 本身其實就是一種說明書。

但如果今天把它全部收進 AI Assistant，只剩：

┌─────────────────────────┐
│                         │
│   有什麼可以幫你的？      │
│                         │
│   [ 輸入你的問題…… ]     │
│                         │
└─────────────────────────┘

畫面乾淨很多。

問題是，User 開始不知道：

我可以做到哪裡？

Blank Chatbox 看起來沒有 Learning Cost。

但仔細想，只是把：

「學 Menu 在哪裡」

換成：

「猜 AI 到底能做什麼」。

「Ask me anything」其實是一個很大的要求

很多 AI Product 喜歡寫：

Ask me anything.

聽起來非常自由。

但對第一次使用的 User 來說，「什麼都可以問」有時候反而等於：

我不知道要問什麼。

因為 User 還得自己猜：

AI 看得到哪些資料？
        ↓
它有哪些 Capability？
        ↓
只能回答，還是可以 Action？
        ↓
我要怎麼說，它才聽得懂？

所以 AI 把 System Structure 藏起來，不代表 Learning Cost 消失了。

只是換了一種形式。

這讓我想到以前在小米做電商 PM 的一個 Case

有趣的是，這不是 AI 時代才有的問題。

以前我在小米做電商 PM 時，網站的 Search 主要拿來搜尋：

「手機」

「平板」

「耳機」

「行動電源」

有一次營運提出：

「要不要把 FAQ 也接進 Search？」

這樣 User 搜：

「怎麼退換貨？」

「保固多久？」

「哪裡有線下門市？」

也可以直接找到答案。

從 System 角度看非常合理。

Search 多接一個 Data Source，就可以做更多事情。

但我當時把這個需求否掉了。

原因不是做不到，而是：

我不覺得 User 知道這個 Search 可以拿來問 FAQ。

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

User 對「電商搜尋框」本來就有 Mental Model：

這裡是找商品的地方。

所以就算 Backend 真的接上 FAQ，功能已經存在，User 也不會突然知道：

「原來我可以在這裡問退貨。」

這件事情放到今天的 AI Chatbox，問題幾乎一模一樣。

以前是：

Search 可以搜 FAQ
≠
User 知道可以搜 FAQ

現在則是：

AI 可以執行 Workflow
≠
User 知道 AI 可以執行 Workflow

我覺得這是一個很重要的產品觀念：

沒有被發現的 Capability，對 User 來說幾乎就等於不存在。

而且 AI 能力越多，這個問題反而越嚴重。

因為一個 AI Assistant 可能同時可以：

• Search
• Answer
• Summarize
• Generate
• Modify
• Call Tool
• Execute Workflow

Capability 越多，Capability Discovery 就越重要。

Suggested Prompt 不是在教 User 寫 Prompt

這也是為什麼很多 AI Product 會在 Chatbox 周圍放 Suggested Prompts。

例如：

[ 我今年還有幾天假？ ]

[ 幫我申請下週五休假 ]

[ 育嬰留停需要準備什麼？ ]

[ 我要修改薪資帳戶 ]

以前我可能會把這些東西單純理解成 Onboarding。

但現在我覺得它還有一個更重要的功能：

Capability Discovery。

這四句其實分別在告訴 User：

我可以查資料
我可以解釋規則
我可以處理申請
我可以執行 Action

所以 PM 在設計 Suggested Prompts 時，不應該只是問：

「首頁放哪四句比較好看？」

而應該問：

「我最希望 User 先發現哪些 Capability？」

如果當年的 FAQ Search 今天重新做一次

現在回頭看，我不是覺得 FAQ 永遠不能放進 Search。

真正的問題是：

不能 Backend 接好了，就期待 User 自己發現。

例如 Placeholder 可以直接寫：

搜尋商品，或詢問退換貨、保固與門市問題

下面再放：

[ 如何退貨？ ]
[ 查詢門市 ]
[ 保固政策 ]

System Capability 完全沒變。

但 User 的 Mental Model 改變了：

原來這裡不只能找商品。

所以 Capability Discovery 本身，就是 Product Design 的一部分。

如果今天設計 AI 首頁，我會用 Guided + Open

我不會把傳統 20 個 Menu 全搬回來。

但我也不會只留一個 Blank Chatbox。

我會考慮三層入口。

第一層：High-frequency Task

[ 查剩餘假期 ] [ 申請休假 ]

先讓 User 知道：

大家最常拿它做什麼。

第二層：Contextual Task

入口可以根據 User 當下的 Context 改變。

例如新進員工：

[ 設定薪資帳戶 ]
[ 查看新人福利 ]

到了績效季：

[ 查看績效流程 ]
[ 準備績效資料 ]

Capability Discovery 不一定是固定的，也可以跟著情境改變。

第三層：Open Input

最後永遠保留：

或直接告訴我你想做什麼。

因為 AI 最大的價值，仍然是不需要被 Menu 限制。

所以我比較喜歡的 AI Entry 是：

Guided + Open

先告訴 User：

你可以從這裡開始。

但不要限制：

你只能做這些事情。

Day 9｜從 Feature Entry 到 Capability Discovery

其實這仍然是 PM 很熟悉的問題。

以前做產品，我們會問：

Feature Entry 放哪？

Homepage 要不要曝光？

User 看不看得到？

CTR 和 Adoption 怎麼樣？

一個 Feature 做完，從來不代表 User 就會使用。

AI 時代這件事情沒有消失，只是問題變成：

以前：
Feature 要怎麼被看見？

現在：
Capability 要怎麼被發現？

所以如果 Day 9 只留下一個 Product Principle，我會寫：

Capability 做得到，不代表 User 知道做得到；產品仍然需要設計「如何被發現」。

AI Product 不需要讓 User 先學會整套 System Structure。

但也不應該期待 User 面對一個空白 Chatbox，就憑空知道所有能力。

先給他一個容易開始的地方，再把自由留給他。