本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。

昨天談到，主管需要協助團隊釐清對 AI 的期待落差，處理速度、品質與責任上的分歧。有些問題可以透過補充資訊與討論形成共識，也有些需要實際做過，才能知道新的工作方式是否有效。

例如，PM 認為用 AI 準備需求資料能節省時間，工程團隊卻擔心，文件看似完整，後續仍需要花很多時間追問與查證。雙方都有各自的判斷依據，接下來可以選一小段工作試行，看看結果如何。

今天從《產品領導人之道》第 26 章〈從內部進行改變〉與第 27 章〈培養敏捷思維〉出發，探討主管如何支持一次可評估的 AI 協作實驗，讓團隊根據實際結果調整工作方式。

從一項具體的工作困擾開始

作者在第 26 章建議，新的工作方式可以從小處開始，在廣泛採用前先確認成效。主管則提供專業知識、教練支持與預算等資源，協助團隊達到改善目標。

把這個原則放進 AI 協作情境，第一步是選定希望改善的工作。

假設一個團隊的需求釐清會議，經常花很多時間補充背景。設計師想知道使用情境，工程師需要了解既有系統限制，PM 則在會後繼續找資料、補說明。團隊希望試試看，在會前由 AI 根據已確認的資料，整理需求背景、限制與待確認問題，再由 PM 查證，交給大家閱讀與討論。

這次試行的範圍很明確：調整會前資料準備方式，保留原本的需求決策與品質要求。選幾件性質相近的需求來觀察，就有機會了解這項改變帶來哪些影響。

DORA 的生成式 AI 導入指南也建議，從小規模開始，事先規劃如何衡量影響，再依結果持續調整。對主管來說，除了讓大家取得工具，也需要保留學習、查證與回顧的時間，並邀請受到影響的角色一起參與。

試行之前，先說清楚希望改善什麼

「用了 AI 應該會更快」還不足以判斷結果。團隊需要進一步說明，期待哪一段工作改善，以及哪些條件必須維持。

以前面的情境為例，可以先寫下這樣的預期：

在需求背景完整度維持的情況下，AI 協助整理會前資料，能減少準備與後續補件的整體投入，也讓團隊更早發現待確認問題。

這裡的「整體投入」，包含 PM 整理與查證資料、設計與工程閱讀，以及會後補件所花的時間。如果 PM 省下半小時，工程卻多花一小時釐清錯誤，團隊就需要重新評估這個做法。

觀察項目可以保持簡單，先聚焦在三個面向：

也要先約定完成條件。例如，資料需要標明來源，未確認的內容要清楚列出，關鍵限制不能省略。否則，一份快速產生但尚未查證的文件，和一份已可供團隊討論的資料，很難直接比較。

用相近的工作比較，保留判讀空間

比較的基準可以是團隊目前的做法。若大家已經使用 AI，也能比較既有流程與新的協作方式，例如加入來源標示、固定查證步驟後，是否減少後續返工。

試行時，盡量選擇複雜度與資料完整度相近的需求，沿用相同的完成條件。同時記下影響結果的差異，例如某一件需求涉及陌生領域，或剛好需要等待其他部門提供資訊。初次設定與熟悉工具的投入可以另外記錄，但評估是否值得推廣時，仍需要把這些成本算進去。

METR 在 2026 年公布的研究設計反思提供了一個提醒：當開發者會挑選適合 AI 的任務、調整成果內容，或同時使用多個 AI agent 工作，單純比較完成時間就更難解讀。

這份研究討論的是開發者工作，不能直接推論 PM 的成效。但它提醒我們，比較之前，需要確認雙方完成了哪些工作、品質要求是否相近，以及時間是怎麼計算的。

團隊的小型試行也會遇到類似限制。幾件需求的結果可以幫助選擇下一步，卻不足以推論所有工作都會得到相同成效。若資料太少或差異太大，就保留結論，繼續觀察。

圖說：AI 協作實驗卡----以需求釐清會議前的資料準備為例，先寫清楚問題、改變範圍、比較基準與觀察項目，再約定檢視時間及決策條件。此圖為本文延伸整理，並非原書既有模型。

讓回顧結果影響下一步

作者在第 27 章指出，回顧會議可以幫助團隊停下來反思，思考接下來應該做哪些改變。即使團隊沒有使用 Sprint，也能安排定期回顧。

對這次 AI 協作試行而言，可以在開始前就約定檢視時間，由 PM、設計與工程一起回顧實際資料和工作感受：哪些環節變順了？哪些工作轉移到其他人身上？品質問題集中在哪裡？

也需要事先談好，什麼結果會支持不同的決定：

這些條件需要依團隊的工作具體化。例如，什麼程度的時間節省值得投入、哪些資訊錯誤不能接受，都應該在試行前討論，避免看到結果後才改變標準。

主管的回應也會影響這場回顧。如果一開始就要求導入 AI 必須成功，團隊可能只挑選看起來有成效的部分回報。主管需要讓成員知道，指出問題、提出停止建議，也是對這次試行有幫助的資訊。

停止某一種做法後，仍可以保留學到的東西。例如，AI 整理待確認問題很有幫助，但自動補寫系統限制容易產生錯誤，下一輪就能縮小用途，調整分工。

有了成效，再把適用條件一起分享

回到第 26 章，作者建議由實際採用新方式的團隊分享成果，尋找有興趣的支持者，再逐步推廣。

在 AI 協作情境中，值得分享的內容包括：原本遇到什麼問題、改了哪些步驟、投入多少查證與學習時間，以及哪些工作目前仍不適用。下一個團隊才能判斷，這套做法需要如何調整。

一次小型試行，也需要產品領導人協助選定問題、提供資源、理解結果，並做出後續投入的決定。當團隊能把改善預期與實際結果放在一起討論，對 AI 的期待就能逐步轉成可持續調整的工作方式。

最後一天，我們將回顧這個系列在人員、產品與流程上的探索，選出接下來值得持續實踐的改變。