AI Product Management · Cross-functional
從服務生到共創者的三個轉折
很多轉型 AI 的 PM 都有過一個瞬間：開完會回到位子上，發現工程師對自己的提案沒什麼反應，ticket 永遠卡在 backlog 最底，跨部門問到「目前進度」時，工程師會說「OO PM 的需求還沒釐清」。
不是技術問題，是合作關係出了問題。
在 AI 專案裡，PM 從「合作者」掉到「需求方」的速度，比想像中快得多。真正讓這個身份轉變發生的，往往不是 PM 的能力，是 PM 開口的第一句話。
下面三個轉折，是我在多次 AI 客服機器人專案裡學到的固定節奏。走過這三個轉折，跟 ML 團隊的距離會徹底不一樣。
今天想聊的，是讓 PM 變共創者的三個對話轉折：
① 為什麼 ML 工程師最受不了「能不能更聰明」這句話？
② 準確率攻防卡住三週，怎麼換個對話框架打開？
③ 「再撈一些資料」這四個字，工程師耳裡聽到什麼？
一場 weekly sync 的對照
為了讓後面的三個轉折有畫面，整篇都會回到這個 AI 客服機器人專案。
場景：AI 客服機器人 weekly sync。會議室白板畫滿上週的失敗案例截圖，工程師站在白板前敲 keyboard。
我曾經走進這個會議，開口的第一句話是：
「能不能讓 AI 自動回答得更聰明一點？」
工程師沒回應，繼續敲 keyboard。我以為他在忙，又補一句：「就是那種，使用者比較好接受的感覺。」
他關掉螢幕，看著我說：「『聰明』指的是什麼？哪些案例不夠聰明？你要我改 prompt、換模型、加 RAG、還是 fine-tune？」
那一刻我意識到，我用了一整句模糊的需求，等對方猜出 5 個可能的工作方向，再自己決定要做哪一個。
從工程師的角度看，這不是合作，是接訂單。
幾週之後我換了一個說法，整個合作節奏徹底反轉。下面三個轉折，是我前後一年多累積下來的領悟。
轉折一：從問「更聰明」到談「失敗類型」
「能不能讓 AI 自動回答得更聰明？」這句話最大的問題不是它模糊，是它把工程師的工作描述成一個有旋鈕可以轉的黑盒子。
ML 模型不是有個叫做「聰明度」的滑桿。它是由 prompt、context window、retrieval 策略、fine-tune 資料、推論參數、後處理規則一連串具體的決策堆出來的。需求說得模糊，工程師就只能猜你想要什麼。
在 AI 客服機器人的脈絡裡，「不夠聰明」可能是這幾類完全不同的問題：
| 表面現象 | 真正的失敗類型 | 對應的修法 |
|---|---|---|
| 答得太硬 | Prompt 沒教 AI 識別客戶情緒 | 改 system prompt |
| 答非所問 | RAG 沒抓到正確的 FAQ 段落 | 重做 chunking、調 embedding |
| 漏掉一半問題 | 客戶問複合問題，模型沒拆 | 加入 query decomposition |
| 訂單編號講錯就放棄 | 過於嚴格的 input validation | 加 fuzzy matching |
四種「不夠聰明」對應四種解法，工時、風險、技術路徑全都不同。只說「更聰明」這三個字，等於要工程師自己做完所有診斷工作。
轉折之後
那次會議後，每週我固定花兩小時翻當週 user log，抽 100 筆失敗對話，自己標出失敗類別。隔週走進 weekly sync，開場白變成：
「我看了上週 200 筆對話，整理出四類失敗。情緒沒識別佔 28%、複合問題只答一半佔 35%、訂單編號講錯一個字就放棄佔 18%、其他 19%。我們要先打哪一類？」
那是工程師第一次看著我說：「終於有 PM 把作業做完才來找我。」
從那天之後，他在我所有的 ticket 上都多花一點時間。
轉折二：從爭準確率到設計 UX 分層
第二個轉折出現在這個專案上線前的 go / no-go 會議。
PM 那邊堅持「上線需要 95% 準確率」。工程師回應「目前 88%、再多 3% 要 6 週、剩 4% 要 6 個月」。雙方僵住了三週。
這個爭執最大的盲點是：95% 跟 98% 對使用者的體驗差異可能很小，但對工程成本可能差 10 倍。抓著數字不放，工程師就要花 3 個月去爭那 3%，而那 3% 並沒有對應到任何使用者的真實痛點。
更深的問題是，準確率本身是個沒有 context 的數字。它沒回答：哪一類錯誤可以接受？哪一類絕對不行？惡意輸入算不算？冷門問題該不該扣分？
轉折之後
我把那次卡住的會議重新開了一場。這次不講準確率，講 UX 分層：
「假設我們允許 AI 在不確定的時候選擇不回答，回答出來的部分要做到 95% 應該不難？至於不回答的那部分，UI 就轉真人。這樣使用者體驗不會崩，整體滿意度搞不好還更高。」
工程師眼睛一亮：「這樣的話我兩週就能做到。」
兩週後上線。最終實際數字：AI 回答了 64% 的 case，其中 96% 正確；不回答的 36% 自動轉真人。整體客戶滿意度比原本全人工的還高出 14 個百分點。
如果當時繼續堅持 95% 全自動，這個產品永遠上不了線。
準確率是工程師的指標，信任體驗才是 PM 該扛的指標。
轉折三：從丟資料需求到自己標 case
第三個轉折最隱形，但影響最大。
AI 客服機器人上線後三個月，模型品質開始下滑。工程師建議「加更多訓練資料做 fine-tune」。當時 PM 那邊在會議上說：「好啊，工程師你們再從 log 撈一些出來。」
工程師沒回應。三週後，模型品質繼續下滑。再隔一週，下滑得更慘。
問題出在「再撈一些」這四個字。在 ML 工程師耳裡，這句話的潛台詞是：
- 誰來標？工程師沒時間做這個
- 誰來清洗低品質樣本？
- 誰來確認 label 一致？
- 誰來抽驗品質？
- 預算誰出？
說「再撈一些」的 PM，等於把這串隱形工作整包丟給工程師，自己以為只是「轉達需求」。
業界一筆高品質標註資料的成本，依複雜度大約落在這個區間：
| 任務類型 | 每筆成本（美元） |
|---|---|
| 簡單分類 | 0.5 至 2 |
| 中等任務（如標註句子情緒） | 3 至 10 |
| 複雜任務（如標註法律意圖） | 15 至 50 |
| 醫療、法律專業領域 | 50 至 500 |
當 PM 說「再加 5,000 筆資料」，那是 $2,500 到 $2,500,000 之間的差距。而 PM 通常還沒編這個預算。
轉折之後
四個月後我換了做法。跟客服主管談好流程：每週篩出 100 筆對話，由我親自標 30 筆高優先順序的，標完用一個 google sheet 給工程師。每月做一次 review，討論哪一類失敗最值得追加標註。
工程師再也沒問過「能不能加更多資料」。因為他知道我會主動給。
走進會議的姿態整個變了。從接到「再撈一些」訊息的工程師，變成期待週三 google sheet 更新的工程師。
反過來看：做到極致也有要留意的地方
到這裡你大概看到一個模式：把模糊需求拆成具體案例、把準確率攻防換成 UX 設計、把資料當成自己的工作。三個動作能讓你從「服務生」翻成「共創者」。
但這條路有一個值得提醒自己的地方。
我觀察到一些把這三件事做到極致的 AI PM，最後變成了「資料勞工」。每週花一整天標 case，每兩週做一次 user log 大盤點，每月開三場資料審查會。他們跟 ML 團隊的關係很好，工程師很喜歡他們，但做久了會發現自己離產品策略愈來愈遠，離商業判斷愈來愈遠。
當你的時間 80% 都在做資料品質的事，你就不再是 PM，是 dataset curator。
怎麼平衡
| 該手作的 | 可以授權的 |
|---|---|
| 第一個月的壞案例分類體系 | 之後的例行標註 |
| 高戰略影響的失敗類型 review | 低風險案例的全部處理 |
| 跟工程師的 weekly 失敗模式對齊 | 例行 user log 整理 |
| 季度的資料策略方向 | 日常的資料管線維運 |
手作是為了贏得對話權，不是為了長期當執行者。 一旦對話權建立，就要把例行工作授權出去，重新把時間花回產品策略。
漂亮的 AI PM 不是那個「跟 ML 團隊感情最好」的人。是那個讓 ML 團隊覺得「跟他合作我能做出最好的產品」的人。
那是兩件不一樣的事。
寫在最後
從「服務生」到「共創者」，這三個轉折說穿了不是技巧，是承擔。
你願意把資料當成自己的工作。
你願意把模糊需求拆成具體案例。
你願意把準確率攻防換成 UX 設計。
每一個「願意」背後都是 PM 把手弄髒的選擇。願意做的 PM 太少，做了的人都會發現自己的 ticket 從 backlog 最底浮到最上面。
你最近一次跟 ML 工程師的 sync，你的開場白是什麼？如果重來一次，你想怎麼說？
留言告訴我，我會逐則回覆。
如果這篇對你有幫助，歡迎追蹤這份 Newsletter。每兩週一篇 AI PM 實戰筆記，主題涵蓋產品策略、跨職能合作、與 AI 導入的真實節奏。
#AIPM #ProductManagement #人機協作 #跨職能合作 #ProductStrategy #AI產品策略 #職涯成長