ANGELA JIAN
LOADING
返回首頁
AI PM職涯轉型產品經理 2026.03.18

從傳統 PM 到 AI 產品經理:我的轉型路徑與實戰心得

Angela Jian
Angela Jian 簡琬庭
Sr. Product Manager / AI Product Builder
老實說,兩年前的我完全沒想過自己會走上 AI 產品經理這條路。

當時我還在做行動應用的 PM,每天的工作是畫 wireframe、寫 user story、跟工程師 sync 開發進度。日子過得很充實,但心裡有個隱隱的不安——我看到身邊越來越多產品開始加入 AI 功能,而我對這些東西一無所知。

那種感覺很像你在搭一班即將到站的列車,而下一班車已經進站了,你不確定該不該跳。

後來我跳了。這篇文章想跟你分享的,就是我從傳統 PM 轉型到 AI 產品經理的完整路徑,包含那些踩過的坑、學到的事,以及我認為最實際的轉型建議。


為什麼 AI 產品經理正在崛起

這兩年 AI 產品經理的職缺數量成長幅度,用「爆炸」來形容並不誇張。不管是大廠還是新創,只要產品裡有用到 LLM、推薦系統、或任何 ML 模型,都需要一個「懂 AI 能力邊界的人」來主導產品方向。

殘酷的現實是:市場不缺會寫 PRD 的 PM,缺的是能跟 AI 工程師對話、能判斷模型能不能解決用戶問題的 PM。(關於能力差異的深入分析,可以參考我之前寫的 傳統 PM 技能樹 vs. AI PM 能力矩陣

傳統 PM 的核心能力——用戶研究、需求拆解、專案管理——這些當然還是重要的基礎。但光有這些已經不夠了。當產品的核心引擎從「邏輯規則」變成「機率模型」,PM 的思維方式必須跟著改變。


AI 產品經理到底在做什麼

很多人問我:「AI 產品經理的日常跟傳統 PM 差在哪?」

最大的差異不在工具或流程,而在思考方式

傳統 PM vs AI PM 的核心差異

傳統 PM 做產品,邏輯是:用戶要什麼 → 定義規格 → 工程師照著做 → 產出確定的結果。

AI PM 做產品,邏輯變成:用戶要什麼 → 判斷 AI 能不能做到 → 定義「夠好」的標準 → 持續調整模型表現。 結果是機率性的,你要管理的不是「對不對」,而是「對的機率夠不夠高」。

日常工作長什麼樣

  • 定義 AI 功能的 Evaluation 標準:不是寫驗收條件就好,而是要定義 Precision、Recall 的目標值
  • 設計 Prompt 和 AI Workflow:很多 LLM 產品的核心體驗取決於 Prompt 設計
  • 管理 Data Pipeline 的優先級:AI 產品的品質取決於數據
  • 跟用戶溝通 AI 的限制:怎麼設定用戶預期、怎麼設計 fallback 體驗
  • 持續監控模型表現:上線不是結束,是開始。模型會隨數據分佈改變而衰退(Model Drift)

簡單來說,AI PM 的角色更像是一個翻譯官——把用戶需求翻譯成 AI 團隊聽得懂的語言,同時把 AI 的能力和限制翻譯成用戶和老闆聽得懂的語言。

維度 傳統 PM AI PM
思維方式確定性邏輯:輸入 → 固定產出機率性思維:管理「夠好」的標準
產出特性100% 可預測、可重現機率性產出,需持續監控
核心文件PRD、User Story、驗收條件Evaluation 指標、Prompt Spec、Data 需求
驗收標準功能是否符合規格Precision / Recall 是否達標
上線後維護 + 迭代持續監控 Model Drift + 數據品質

需要具備的能力

🧠
AI Literacy
判斷問題是否適合 AI、理解技術 trade-off 與模型限制
📊
數據思維
問對數據問題:來源、bias、量級、Label 品質
✍️
Prompt Engineering
System Prompt 設計、Few-shot 選擇、系統性 Evaluation
🎯
Confidence 校準
設定自動化閾值、管理團隊對 AI 產出的信任度

先講最重要的一句話:你不需要會訓練模型,但你必須懂 AI 的能力邊界。

1. AI Literacy(AI 素養)

你要懂的不是「模型怎麼訓練」,而是:

  • 這個問題適不適合用 AI 解:不是所有問題都該塞一個模型進去
  • 不同 AI 技術的 trade-off:LLM vs 傳統 ML、Fine-tuning vs Prompt Engineering
  • 模型的限制在哪:Hallucination、Latency、Token 成本、隱私風險

2. 數據思維

AI 產品的品質 = 數據的品質。這句話不是口號,是我用血淚換來的教訓。

我曾經花了三個月打造一個 AI 推薦功能,上線後效果很差。回頭檢查才發現,訓練數據裡有大量髒資料。

數據思維的意思不是你要會寫 SQL,而是你要有能力問出對的問題:這個數據從哪來?有沒有 bias?量夠不夠?Label 的品質誰在把關?

3. Prompt Engineering

如果你做的產品有用到 LLM,Prompt Engineering 幾乎是必備技能。你需要理解 System Prompt 的架構設計、Few-shot vs Zero-shot 的選擇、以及 Evaluation 的方法。

Prompt Engineering 某種程度上就是 AI 時代的「寫規格」——你用自然語言定義產品行為,這不正是 PM 最擅長的事嗎?

4. Confidence 校準能力

AI 的產出有不確定性,而你作為 PM,需要幫團隊校準對 AI 的 Confidence。Confidence Score 多少以上才放行自動化?這些判斷沒有標準答案,但 PM 必須做出決定。


我的轉型路徑

起點:行動應用 PM

轉型前我做了幾年的行動應用 PM,主要負責 B2C 產品的功能規劃與迭代。那時候對 AI 的理解大概停留在「好像很厲害但跟我沒關係」的程度。

轉捩點:被推著走

公司決定在產品裡加入 AI 推薦功能,老闆問:「誰要負責這塊?」沒人舉手,我就被指派了。

現在回想,這個「被迫上場」反而是最好的學習方式。因為你沒有退路,必須在最短時間內搞懂 AI 團隊在講什麼。

踩過的坑

坑一:把 AI 功能當傳統功能管理

一開始我還是用傳統的方式寫 spec:「用戶輸入 X,系統回傳 Y。」AI 工程師看了直接說:「PM,這個沒辦法保證每次都回傳一樣的結果。」

坑二:忽略數據品質

AI 產品的 discovery 階段,Data Audit 跟 User Research 一樣重要。

坑三:對模型能力過度樂觀

早期我常跟老闆說「AI 可以做到」,然後回頭發現模型根本做不到那個精確度。後來我學會:先做 POC(Proof of Concept),再許承諾。

我的轉型路徑
📱
行動應用 PM
B2C 功能迭代
被指派 AI 專案
被迫上場
🕳️
踩坑學習
數據、模型、預期管理
🚀
AI PM
擁抱不確定性

給想轉型的人的建議

1. 從現有工作中找 AI 切入點

你不需要換工作才能開始。問問自己:現在的產品有沒有哪個環節可以用 AI 優化?轉型不是一個瞬間的決定,而是一連串小實驗的累積。

2. 學對東西

我建議的學習優先級:

  1. Prompt Engineering(投報率最高,馬上可以用)
  1. AI 產品設計 Pattern(Human-in-the-loop、Progressive Disclosure)
  1. 基礎 ML 概念(Training、Inference、Evaluation 的基本邏輯)
  1. 數據基礎(SQL 是加分項,但更重要的是建立數據直覺)

3. 大量使用 AI 工具

不要只是用 ChatGPT 幫你寫信。試著用它做 User Research 分析、寫 PRD 初稿、產生測試案例。當你自己是 AI 的深度用戶,你才能真正理解 AI 產品的痛點和機會。(延伸閱讀:我每天在用的 5 個 AI 場景

4. 建立跨領域的語言能力

多跟 AI 工程師、Data Scientist 聊天。一開始聽不懂很正常,不要怕問笨問題。

5. 接受「不完美」的產品觀

不是追求 100% 正確,而是設計一個「就算 AI 出錯也不會造成災難」的產品體驗。 💡


寫在最後

回頭看這段轉型的路,我最慶幸的一件事是:我沒有等到「準備好」才開始。

如果你現在也站在那個不確定的路口,先從一個小實驗開始。找到你現在工作裡跟 AI 最近的那個接觸點,動手去做。

AI 產品經理這個角色還在被定義中,這代表你有機會用自己的方式去塑造它。

如果你也正在經歷類似的轉型,或是對 AI PM 的日常有任何好奇,歡迎留言跟我聊聊——我很想知道,你的轉型故事是什麼? 🚀