AI PM INSIDER
LOADING
返回首頁
AI PM產品思維 2026.05.13

傳統 PM 管功能,AI PM 管不確定性

Angela Jian
Angela
Sr. Product Manager / AI Product Builder

AI Product Management · Mindset Shift

規格、迭代、成功指標的三個重寫

很多想轉 AI PM 的朋友會問:「我已經當 PM 五年了,是不是只要補幾門機器學習課就好?」

技術部分要補沒錯,但更重要的是另一件事。底層思維要重寫的部分,比技術本身多得多。

過去十年的 PM 工作建立在「確定性思維」上。寫好 PRD、訂好規格、工程實作、QA 測試、上線,每一步都可預測。AI 產品從根本上是「機率性產品」,同樣的輸入跑出三種輸出,準確率今天 92% 明天可能 87%,上線使用者用兩週就離開。

下面三個重寫,是我在 AI 客服機器人專案裡,一步一步學到的轉變。

今天想聊的,是 PM 思維底層的三個重寫:

① PRD 在 AI 世代該怎麼升級,才 hold 得住模型的不確定性?

② AI 產品的迭代節奏,跟傳統產品差在哪?

③ 成功指標從準確率換成什麼,才代表使用者真的買單?

一份失敗的 PRD

場景:AI 客服機器人專案啟動會議。會議室裡 PM 攤開一份十二頁的 PRD,工程師翻到第三頁就停下來。

我曾經帶著一份很傳統的 PRD 走進這個會議。第一頁寫的是:

「使用者輸入問題 → 系統檢查 FAQ → 回傳對應答案 → 使用者滿意。」

工程師看著我說:「那如果系統不知道答案?或者使用者問的是兩個 FAQ 的組合?或者語氣很模糊?」

我意識到我寫了一份完美的「確定性 PRD」。所有路徑都有預設答案,沒有一條路徑處理「模型不確定的時候」。

那份 PRD 後來被我整份重寫。下面三節是我換了什麼框架在想。

重寫一:從定義行為到定義邊界

傳統規格寫法是:使用者輸入 X,系統回傳 Y。寫得清楚,工程師看完知道怎麼做,QA 看完知道怎麼測。

AI 客服機器人的規格不可能這樣寫。使用者問「我下個月該繳多少稅?」,模型可能:

可能輸出該怎麼處理
給出金額並附計算過程直接顯示
給出金額但沒附過程補上「請使用者確認來源」
給錯金額必須被偵測並擋下
答非所問(給了健保費)提示使用者重新提問
直接拒答自動轉真人客服

AI PM 寫的不再是「系統必須回 X」,而是要回答四件事:

  • 哪些回答可接受、哪些不行
  • 不可接受的回答出現時,系統怎麼接住
  • 使用者怎麼分辨回答的來源
  • 錯誤的修正機制怎麼回流到模型訓練

我的第二版 PRD 為這個 AI 客服機器人寫了三層回應策略:高信心直接答、中信心附「請覆核」標籤、低信心自動轉真人。光是這一改,上線後使用者誤信錯誤答案的比例就降到原本的三分之一。

你的 PRD 要從「行為規格」進化成「行為邊界+失敗策略」。

重寫二:從上線優化到資料驅動

傳統迭代週期是這樣的:上線 → 看 GA → 看 funnel → 找轉換瓶頸 → 改 UI / 改文案 → A/B test → 再上線。PM 看的是「事件數據」。

AI 客服機器人上線後的迭代週期完全不同:

  1. 看 user log
  2. 標註上週的壞案例
  3. 找壞案例的共同模式
  4. 改 prompt / 加 RAG 例子 / 視情況微調
  5. 跑離線評估
  6. 上 A/B test
  7. 再上線

中間多了「資料」這一層。AI PM 要學會問的問題不再只是「轉換率多少」,而是:

  • 這個月的失敗類型跟上個月一樣嗎?
  • 失敗的案例有沒有共同模式(某類使用者、某類問題、某種語氣)?
  • 我要花預算收集哪一類資料?
  • 收回來的資料品質如何?需不需要重新標註?

在 AI 客服機器人專案裡,我每週固定花兩小時抽看 100 筆對話。這份「壞案例資料集」最後成為團隊最珍貴的資產,比任何模型版本都更值得守護。

AI PM 的核心資產不是規格文件,是一份持續累積的壞案例資料集。

重寫三:從功能完成度到信任度

傳統 PM 的勝利條件是:功能做完、bug 修完、上線、達到 DAU 目標。

AI 客服機器人上線首週的數據看起來很漂亮:

指標第一週數字
摘要準確率(人工抽檢)92%
回應時間1.2 秒
使用人數8,500

但兩個月後使用率掉到剩 1,200。技術指標沒變,使用者就是不再用。

我去訪談發現一件事:使用者怕。AI 的答案讀起來很流暢,但他們不知道哪裡可以信、哪裡不能信。每次看完還是要自己重看一次原文。那為什麼要用 AI?

後來我加了三個小設計:每個答案連回原 FAQ、不確定的句子用淺灰標示、一鍵「這個答案有問題」回饋按鈕。三週後留存率從 14% 回到 38%。

技術指標完全沒變,使用者體驗變了。

信任度才是 AI 產品的北極星指標,不是準確率。準確率是工程師的 KPI,信任度才是產品的 KPI。

反過來看:不確定性管理也有要留意的地方

到這裡你大概看到一個模式:規格寫邊界、迭代靠資料、指標看信任度。三個重寫能讓 AI 產品穩定運轉。

但我觀察到一些把不確定性管理做到極致的 PM,最後變成了「風險管理者」,每個功能都先想十種失敗策略、每個 prompt 都評估三層信心度,結果什麼都不敢 ship。

不確定性需要管理,但不能讓管理本身變成 paralysis。

該認真做的可以快速通過的
涉及金錢、法律、健康的高風險回應一般資訊查詢的低風險回應
使用者第一次接觸 AI 的入口體驗進階使用者的細節操作
模型可能造成的長期信任傷害短期可以靠 UI 修補的小錯

不確定性管理是 AI PM 的肌肉,不是 AI PM 的牢籠。 練到能快速判斷哪些情境值得花時間設計、哪些可以快速通過,才是這條路真正的成熟。

漂亮的 AI PM 不是那個「永遠零錯誤」的人,是那個能讓團隊在不確定性中繼續前進的人。

寫在最後

如果只記得一句:傳統 PM 在管理「功能」,AI PM 在管理「不確定性」。

不確定性管不好,再強的模型上線也是災難。管得好,就算用最便宜的 API,也能做出讓使用者離不開的產品。

這也是為什麼好的 AI PM,反而是那些習慣處理混亂、習慣與人類共事、習慣在資訊不全時做決策的人。那不就是每個資深 PM 的日常嗎?

你最近寫的 PRD 裡,有沒有一段是專門處理「模型不確定時」的策略?如果沒有,那會是你下一份 PRD 最值得補上的一節。

如果這篇對你有幫助,歡迎追蹤這份 Newsletter。每兩週一篇 AI PM 實戰筆記,主題涵蓋產品策略、跨職能合作、與 AI 導入的真實節奏。

#AIPM #ProductManagement #產品思維 #AI產品策略 #ProductStrategy #職涯成長 #人機協作