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

昨天談到，AI 加快個別工作的產出之後，團隊仍可能卡在審查、決策與交接。要改善這些瓶頸，需要先看見工作在哪裡等待，以及等待的原因。

不過，有些問題還沒有出現在工作看板上，只有成員自己知道。他可能已經察覺工作成果有疑慮，卻還在猶豫要不要提出。

試想一個情境：一位 PM 用 AI 整理顧客訪談，團隊根據摘要開始討論功能。後來，他發現其中一項「顧客需求」在原始訪談裡找不到明確依據，但還無法確認是摘要失真，還是自己漏看了什麼。

問題可能出在 AI 的摘要，也可能是 PM 提供的資料不完整，或在解讀時把推論當成了顧客的需求。剛察覺疑慮的時候，通常還無法確定是哪個環節出了問題，但團隊已經需要知道，原本採用的資訊可能需要重新確認。

他會立刻告訴團隊，還是先自己查一查，等有完整答案再說？

這個選擇，除了取決於他的判斷，也和他預期主管會如何回應有關。

有疑慮的時候，能不能先說出來？

提出問題有時需要承擔人際上的風險。PM 可能擔心被認為沒有做好檢查、能力不足，或在團隊已經往前推進時，又拖慢了進度。如果最後證明只是自己誤會，會不會顯得小題大作？

使用 AI 本身，也可能讓人有所顧慮。Anthropic 在 2025 年發表的一項訪談研究中，一般職業樣本有 1,000 位受訪者，其中 69％提及在工作中使用 AI 可能伴隨的負面評價。這項研究受樣本招募與自陳資料限制，不能直接推論所有團隊的狀況，但提醒了我們：人們是否願意談自己的 AI 使用方式，也受到周遭態度的影響。

《產品領導人之道》第 20 章〈直接與開放式的溝通〉指出，主管需要確保組織能夠進行開放、坦率的溝通，而這必須建立在心理安全感與信任之上。主管也要透過日常行為展現這些價值，包括多聽少說、重視透明與誠實，以及保持開放心態。

Google 的團隊效能研究也將心理安全感列為重要因素，具體表現在成員是否能安心承認錯誤、提出問題與表達不同意見。

把這些觀點放到 AI 協作裡，團隊需要容得下「我還不能確定」這樣的說法。成員可以交代目前看見了什麼、已經查過哪些部分，以及需要什麼協助。若每次都得先確認錯誤、找出原因、準備好解法才能開口，其他人可能早已根據有疑慮的資訊繼續工作。

主管的第一個回應，影響接下來能聽到多少資訊

回到前面的情境。當 PM 提出疑慮，主管如果立刻問：「為什麼沒有先檢查清楚？」成員接下來可能把注意力放在解釋自己做過哪些事、為什麼當時沒有發現。原本需要共同釐清的問題，反而被擱在一旁。

主管可以先這樣回應：

「謝謝你先提出來。我們一起確認哪一段有疑慮，以及哪些決定已經用到這份內容。」

接著，讓 PM 說明他如何察覺異常。目前已經確認了什麼？還有哪些部分無法判斷？原始訪談與 AI 摘要之間，具體差異在哪裡？

取得這些資訊之後，才有辦法決定如何處理。如果摘要還沒被採用，可以先標示待查證；如果已經影響功能排序或開發工作，就需要通知相關人員，確認哪些決定應該暫緩或重新檢視。主管也可以協助找到熟悉原始資料的人，約定誰來核對、何時回報。

肯定及早提出疑慮，與要求完成後續修正，可以同時做到。

人與 AI 都可能出錯，因此團隊需要能夠發現與修正錯誤的工作方式。對於 AI 產出的內容，採用的人仍需要依工作風險做好查證；發現問題後，也要有人負責更正與溝通。「AI 就是這樣回答的」無法交代當初為什麼採用這個結果，以及現在該如何處理。

PM 需要協助釐清影響、修正內容，主管則要提供足夠的時間與支援。如果團隊原本已約定檢查步驟，也需要了解當時是否執行、方法是否有效，以及有沒有其他條件影響了判斷。

先把經過弄清楚，才能決定接下來需要的是補強能力、調整流程，還是處理沒有履行約定的行為。

主管也要示範如何承認錯誤與不確定

要求成員坦誠面對錯誤時，主管自己的做法同樣會被看見。

《產品領導人之道》第 5 章〈成為一個優秀的主管〉談到，主管可以展現自己的疑慮與脆弱，並在取得新資訊後調整原本的觀點。作者也提醒，團隊成員會密切注意主管的行為，觀察他是否做到自己要求別人的事。

例如，主管用 AI 準備市場分析時，可以說明哪些資訊已經核對、哪些推論仍需要討論。如果先前引用的資料有誤，也可以主動更正，交代哪些判斷因此需要調整。

主管也可能誤解顧客需求、太早下結論，或在時程安排上低估必要的查證工作。如果這些判斷影響了團隊，就需要說清楚自己當時如何思考、現在看見了什麼，以及接下來會怎麼調整。

這些日常做法，讓成員知道主管也需要查證、也可能判斷錯誤。相反地，如果主管總是把自己的看法當作確定答案，卻嚴格追問部屬為何沒有查清楚，成員就很難相信，提出疑慮會得到公平的對待。

主管也可以問團隊：「最近有沒有什麼問題，是擔心我的反應，所以沒有及早告訴我的？」收到回饋之後，還需要讓大家看見實際的調整。書中同樣提醒，僅僅鼓勵員工提供意見並不足夠，主管必須針對回饋採取行動。

把這次發現，變成下一次能用的經驗

問題修正後，團隊還可以一起回看當時的工作經過：提供給 AI 的資料是否完整？摘要如何被解讀與採用？哪些假設沒有被說明？原本的檢查方式，為什麼沒有發現差異？

這些問題能幫助大家了解，資訊如何經過工具與人的判斷，最後影響了產品決定。

Google SRE 的事故檢討實務提供了值得參考的做法。它強調了解事件發生的條件，避免以指責或羞辱個人的方式檢討，同時要求改善項目具備明確負責人、優先順序與可驗證的完成條件。公開責備可能使成員隱藏關鍵資訊；缺乏後續行動，則讓同樣的問題有機會再次發生。

將這個原則應用到前面的假設案例，團隊可以約定：訪談摘要中會影響產品決策的需求判斷，需要附上可回查的原始片段，並區分受訪者實際表達的內容與分析者的推論。

這樣的改善比「下次請更小心」更具體，也讓下一位接手工作的人知道如何檢查。未來再遇到類似疑慮，團隊便有共同的方法可以使用。

《產品領導人之道》第 27 章〈培養敏捷思維〉提出，可以透過團隊在壓力下的反應，觀察敏捷思維是否真正落實：成員是否仍會主動分享洞察、思考替代方案，並共同應對變化。作者也建議透過回顧，持續調整工作方式。

當工作成果出現問題，正好可以看見這些日常習慣是否存在。成員提出疑慮後，有沒有人願意一起查證？修正需要的時間，有沒有被納入安排？承諾的改善，最後有沒有完成？

讓提出問題成為有用的行動

主管自己也可能判斷錯誤，更難以事先掌握人與 AI 協作中所有可能出現的問題。願意聽完疑慮、承認自己的疏漏、協助查證並追蹤改善，會讓成員知道，問題被提出之後，團隊能夠一起處理。這些反覆發生的經驗，才會逐漸形成坦誠面對錯誤的文化。

回想最近一次成員承認錯誤或提出求助時，主管的回應，讓他更願意繼續說明，還是更想趕快結束對話？這個問題，或許就是檢視團隊溝通文化的一個起點。

下一篇將接著討論，當主管、團隊與其他部門對 AI 帶來的速度、品質與責任有不同期待時，如何處理這些落差。