寫到第 23 天，回頭看前面的文章，我已經一路寫了：

Intent
Journey
Search
Agent
Human-in-the-loop
Evals
Token
Requirement
PRD
Prototype

東西越來越多。

但如果有人現在問我：

所以 AI 到底改變了 Product 的哪裡？

我反而覺得，需要停下來重新整理一次。

我原本以為這個系列會一直在講「AI Product」。

寫到現在才發現，前面 22 篇其實一直在回答六個問題：

Understand
↓
Decide
↓
Act
↓
Control
↓
Measure
↓
Build

這不是一套我已經驗證完成的 AI Product Framework。

比較像是我寫到目前，幫自己整理出來的一張地圖。

01｜UNDERSTAND：System 能不能先理解 User？

這其實是整個系列最早開始的地方。

傳統 Software 很多時候是：

System 定義結構
↓
UI 把結構呈現出來
↓
User 學會怎麼操作

例如我要訂機票：

出發地
目的地
日期
人數
艙等

我要申請公司服務：

選分類
填表單
選原因
填欄位
送出

User 必須先理解：

System 要我怎麼輸入。

但 AI 出現之後，開始有另一種可能：

「下週幫我找台北去東京，
三天兩夜，早去晚回。」

System 自己從裡面理解：

Intent
Context
Slot
Constraint

這也是我 Day 1 到 Day 9 一直在繞的核心。

Search、Recommendation、分類、表單、Generative UI，看起來是不同題目，

背後其實都在問：

到底還有多少 System Structure，需要 User 自己理解？

我目前最喜歡的一句話，還是系列一開始寫的：

以前我們努力讓 User 理解 System；現在，System 應該開始理解 User。

02｜DECIDE：理解 User 之後，AI 可以自己決定多少？

但 System 能理解 User，下一個問題馬上就來了：

理解了，然後呢？

假設 User 說：

幫我訂明天下午去台北的車票。

AI 發現有兩班：

14:00
15:00

它應該：

自己猜？
根據歷史紀錄選？
問 User？
先選再讓 User Confirm？

這就是我前面寫 Human-in-the-loop，以及：

Ignore
Infer
Clarify
Confirm

真正想處理的事情。

我後來發現：

AI Product 很多設計，其實不是在設計「AI 能不能回答」。

而是在設計：

這個 Decision 到底應該由誰做？

我目前會看的幾件事包括：

Uncertainty
Risk
Reversibility
Authorization

錯了沒什麼影響，而且可以復原，

AI 可以多做一點。

但如果是：

付款
送出正式申請
刪除資料
涉及敏感資訊

那 User Control 就要回來。

所以 AI Product Design 不只是讓 AI 更聰明。

還要設計：

AI 聰明到什麼程度時，可以替 User 往下走。

03｜ACT：AI 是在回答問題，還是在完成事情？

這也是我寫 Agent 後，開始覺得很不一樣的地方。

Chatbot 時代很容易停在：

User 問
↓
AI 回答

但 User 真正想要的，通常不是一個答案。

例如：

我要請假。

User 真正要的不是：

「以下是公司的請假規定。」

而是：

確認假別
↓
確認日期
↓
檢查資格
↓
填入資料
↓
送出申請
↓
得到結果

所以我後來越來越在意：

AI 最後有沒有把 User 的 Task 往前推？

這也是 Journey Delegation、Agent、Tool Calling 最後都會碰到的問題。

如果 AI 只能說：

「你可以去某個頁面操作。」

它可能只是另一種 Search。

但如果 AI 要真的 Action，

後面馬上就會碰到：

Data
API
Tool
Permission
Business Rule

所以 Agent 也不是：

接一個 LLM 就完成了。

04｜CONTROL：如果 AI 做錯了，User 怎麼把事情拿回來？

AI 開始 Action 之後，我覺得 Product Design 最容易被低估的是這一層。

Demo 很常長這樣：

User
↓
AI
↓
Action
↓
Success

但 Production 更可能是：

User
↓
AI
↓
Action
↓
？

API Timeout
Permission Denied
Wrong Data
Partial Success
Unexpected Result

所以我在 Day 14 寫 Agent Failure 時，最大的感受是：

Agent 的能力不只看它能做多少，也要看做錯之後能不能收拾。

產品至少要想：

Retry
Rollback
Stop
Escalate

還有一個更重要的問題：

User 知不知道現在發生什麼事？

AI Product 如果什麼都藏在後面自動執行，

User 可能反而失去掌控感。

所以 Control 不是 AI 做得不夠好才需要。

而是：

只要 AI 開始替 User 做事，Control 就應該一起被設計。

05｜MEASURE：AI 回答很多，不代表 Product 做得好

接著是我寫到 Evals、Token、Metrics 時，自己觀念改變滿多的一塊。

傳統 Feature 上線，我們很習慣看：

PV
UV
CTR
Usage
Retention

但 AI Product 有一個很奇怪的地方：

互動很多，不一定是好事。

例如 User 一個問題：

問一次
↓
Regenerate
↓
換句話問
↓
再問一次
↓
最後放棄

從 Usage 看：

Engagement 很高。

但從 User 角度：

根本沒有解決。

所以我現在會多問一句：

User 的 Task 最後有沒有完成？

甚至進一步看：

Task Completion

Correction / Retry

Turns per Successful Task

Escalation

Latency

Token Consumption

這也是為什麼我後來覺得：

AI Product 的單位不一定應該是「一次 Interaction」，而可能是「一次完成的 Task」。

這個想法對我來說滿重要的。

因為它把：

Quality
Experience
Cost

重新拉回同一件事情：

到底花多少資源，幫 User 把事情做好？

06｜BUILD：最後，做 Product 的方法本身也開始改變

這是最近 Day 17 到 Day 22，我開始轉進來寫的部分。

一開始我以為 AI 改的是 Product。

後來才發現：

AI 也開始改我們做 Product 的方式。

例如 Requirement 進來後，

以前可能是：

User Requirement
↓
Meeting
↓
PRD
↓
Wireframe
↓
Development

現在我自己的工作方式開始出現：

Requirement
↓
AI 找 Unknown / Assumption
↓
跟 User 補 Context
↓
AI First Draft
↓
快速 Prototype
↓
直接操作驗證
↓
再補 Product Detail

這裡我自己也還在摸索。

但至少目前有一個感受很明顯：

Documentation 正在變便宜。

整理 Meeting Note
寫 First Draft
產生 Flow
做 Prototype

都比以前快很多。

但另外一些事情沒有一起消失：

Context
Business Rule
Dependency
Trade-off
Product Judgment

甚至因為 Prototype、Code 都做得更快，

這些事情反而更容易成為新的 Bottleneck。

所以前幾篇我才會一路寫到：

做得出來 ≠ 設計得對 ≠ 可以上 Production。

以及：

AI Coding Optimize 的是 Build Time；真正的 Product Velocity，要看 End-to-End Lead Time。

把前 22 篇放回來，我現在看到的是這張圖

如果現在要我把這 22 天濃縮成一張圖，

大概會是：

USER
 │
 ▼
UNDERSTAND
System 知道 User 想做什麼嗎？
 │
 ▼
DECIDE
哪些可以自己判斷？
哪些需要問 User？
 │
 ▼
ACT
AI 能不能真的完成 Task？
 │
 ▼
CONTROL
User 什麼時候需要拿回控制權？
失敗怎麼 Recovery？
 │
 ▼
MEASURE
Task 最後有沒有完成？
Quality / Cost 值不值得？
 │
 ▼
BUILD
我們怎麼更快把正確的 Product 做出來？

有趣的是，

這六層裡真正跟「LLM 有多強」直接相關的，其實只有一部分。

其他很多還是很傳統的 Product 問題：

User 到底要什麼？

誰應該做 Decision？

System Boundary 在哪裡？

失敗怎麼辦？

怎樣算成功？

Team 怎麼交付？

只是 AI 把這些問題重新洗了一遍。

我現在反而不太想問：「這是不是 AI Feature？」

寫這 23 天以前，

我看到一個 Product 很容易先分：

傳統 Feature

AI Feature

但現在我覺得這個分類沒有我原本想像中那麼重要。

我更常問的是：

System 理解多少？

System 決定多少？

System 執行多少？

User 控制多少？

因為 AI Native 不一定代表：

畫面中間有一個 Chatbox。

也不一定代表：

Product 裡面放了一個 Copilot。

它比較像是一條光譜：

User 操作全部
───────────────
System 開始理解
───────────────
System 開始建議
───────────────
System 開始執行
───────────────
System 自主完成

真正的 Product Design，

是決定自己的 Product 應該站在哪裡。

不是越右邊越好。

Day 23｜我現在對 AI Native Product 的暫時答案

所以這篇我不想下結論說：

AI Product 就應該照這六步做。

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

比較準確的說法是：

寫到第 23 天，

這是我目前用來整理問題的一張地圖：

UNDERSTAND
理解 User

DECIDE
分配 Decision

ACT
完成 Task

CONTROL
保留控制

MEASURE
驗證 Outcome

BUILD
縮短 Learning Loop

它可能還會變。

甚至寫到明年，我可能會重新拆掉重組。

但至少它幫我回答了一開始那個問題：

AI 到底改變 Product 哪裡？

我目前的答案是：

它不只是多了一個新的 Interface，而是開始重新分配 User 和 System 之間的工作。

以前很多事情：

User 理解
User 選擇
User 操作
User 串流程

現在開始有一部分可以變成：

System 理解
System 推理
System 執行
System 協助完成

而 PM 要重新設計的，

就是中間那條界線。

Product Principle

AI Native Product 不是讓 System 做得越多越好，而是重新決定：什麼應該由 System 理解、判斷與執行，什麼仍然應該留在 User 手上。