如何管理 AI 專案? AI PM 從確定性工程到應用研究

最近看了幾篇討論 AI 產品經理和 AI 專案管理的內容,最有感的是這句話:「傳統軟體開發是確定性的,但 AI 開發本質上是應用研究」,這根本性的差異改變了一切。

為什麼傳統路線圖 (Product Roadmap) 會失敗?

傳統 PM 會說「我們 9/21 要發布這個 AI 功能」,但問題是:你怎麼為還沒被發現的東西制定 Roadmap?這就像在地圖還沒畫出來的時候就規劃路線一樣荒謬。

AI 開發更像科學研究:

  • 進度不是線性的(可能好幾週沒進展,然後突然有突破)
  • 成功不是保證的(有時數學本身就不支持你的產品目標)
  • 關鍵指標是學習速度,而非開發速度

舉個例子:你想做一個「減少模型幻覺」的功能。在傳統開發中,這可能是個明確的工單。但在 AI 開發中,這是個開放性研究問題,你甚至不知道是否能完全解決。

從功能思維轉向實驗思維

與其說「我們要建立自然語言轉 SQL 功能」,不如問:

  • 我們能否通過表格內的 row data 找到相關表格?
  • 資料提取在 OCR 之前還是之後效果更好?
  • 判斷器在摘要上效果更好嗎?

每個實驗都要有明確的成功指標和預估改進幅度。例如:「目前召回率 73%,這方法預計能提升 5-8%」。

重點是把大問題拆解成可測試的小假設。這讓你能快速驗證方向是否正確,而不是花三個月做出一個沒人要的功能。

評估系統(Evals) 是 AI PM 的核心職責

這點特別有趣: 很多人把 Evals 當成回歸測試,但其實完全不同。單元測試確保系統不會崩潰,但 LLM 的非確定性讓一切變得複雜,相同輸入可能產生不同輸出。

AI PM 要親自參與標註和錯誤分析。是的,沒人喜歡做標註,但如果你不深入資料,你無法確保產品成功。這不是可選的,是核心職責。

會主動查看用戶對話記錄,找出 AI 卡住的地方,然後帶到團隊說「看,用戶在這裡遇到問題了」,這種深入一線的做法才能真正改善產品。

失敗漏斗:找出系統瓶頸

「失敗漏斗」概念很實用,以自然語言轉 SQL 為例,不要只看最終結果對不對,而是拆解每個步驟:

  1. 能生成語法正確的 SQL 嗎?(85% 成功)
  2. SQL 能無錯誤執行嗎?(92% 成功)
  3. 返回的結果相關嗎?(78% 成功)
  4. 結果符合用戶意圖嗎?(65% 成功)
  5. 真的解決了用戶問題嗎?(41% 成功)

每個階段的失敗率都能指引你該優先改進什麼。早期階段的改進影響最大,如果第一步只有 50% 成功率,後面再怎麼優化也沒用。

實際執行

很多團隊還是習慣傳統的 Sprint 和看板。要轉型,可以從兩個方向切入:

  1. 新功能開發:列出所有需要驗證的假設,設計實驗逐一測試
  2. 既有功能優化:為現有最重要的 AI 功能建立失敗漏斗

當主管看到「60% 評估通過」變成「12% 在第一步失敗、7% 在第二步失敗」這種具體分析,立刻就知道該優先做什麼了。

溝通方式

傳統方式:「我們改進了模型,現在比較好了」

比較好的方式:「假設用微調能提升準確率,我們實驗後 F1 分數從 0.72 提升到 0.83(提升 15%),但推理時間增加了 20ms」

差別在於:

  • 明確說明假設和介入措施
  • 提供可量化的結果
  • 誠實面對權衡(準確率 vs 速度)

關鍵轉變:從交付思維到學習思維

傳統 standup:「這週我完成了 X 功能」

AI standup:「這週我們測試了 5 個假設,都失敗了,但排除了 3 個主要方向,找到了新的可能路徑」

這就是 AI 開發的進展樣貌。重點不是「何時能改善準確率」,而是「什麼阻礙我們進行更多實驗」。

有個生動的比喻:這就像健身時只盯著體重看。體重是最終指標(lagging indicator),但你真正該關注的是運動次數、卡路里攝取這些你能直接控制的領先指標(leading indicator)

AI PM 的日常工作

根據討論,一個優秀的 AI PM 每天可能在做:

  • 早上查看昨晚實驗結果,分析失敗案例
  • 和工程師討論新的假設和實驗設計
  • 親自標註 30-100 個案例,理解錯誤模式 (編按: 請參考我最近寫的錯誤分析文章)
  • 設計新的評估指標,確保測量正確的東西
  • 和用戶訪談,理解真實需求(不只是表面需求)

未來展望:AI 驅動的 PM

有趣的是,AI PM 自己也在被 AI 改變。現在的 PM 可以用 ChatGPT 來:

  • 分析大量非結構化的用戶反饋
  • 快速產生實驗假設
  • 協助設計評估框架
  • 加速資料分析和洞察提取

但諷刺的是,調查顯示超過一半的 PM 還沒真正用過 Cursor、v0 這些 AI 工具。這個採用差距本身就值得深思。

總結來說,AI PM 需要全新的技能組合:深度技術理解、願意做髒活(標註!)、實驗設計思維、系統性分析能力、以及最重要的: 擁抱不確定性的勇氣。

如果你還在用傳統方法管理 AI 專案,是時候「燒掉你的 Product Roadmap」,擁抱探索者心態了。因為在 AI 時代,唯一確定的就是不確定性本身。

參考資料

本文基於以下原始內容,用 AI 摘要生成後人工潤飾。

  1. Stop Managing AI Projects Like Traditional Software 附上我用 AI 整理後的文章
  2. WTH is an AI Product Manager? 附上我用 AI 整理後的文章
  3. Effective Communication in AI Engineering: Moving Beyond Vague Updates
  4. SWE vs AI Engineering Standups

發佈留言

發表迴響