PM 的美麗與哀愁：AI 時代，產品經理會被取代還是被迫升級？
很多人只知道我是講師、顧問跟作家，以前在幾家媒體做過記者和編輯，卻不曉得我還曾經當過產品經理（PM）。所以，我對產品經理這個職務，一直有一種難以言喻的情感。
倒不是因為產品經理的薪水比較多，也不是因為名片上印著 Product Manager 看起來很厲害，好像管很多；而是因為產品經理做的事情，本質上非常迷人——你要在使用者的語言、商業的語言與工程的語言之間來回翻譯，然後在資訊不完整、時程很殘酷、每個人都覺得自己是對的情況下，做出一個可以被驗證、交付以及被市場檢驗的決定。
這份工作不只有光芒，也有委屈。美麗與哀愁，從來都是一體兩面。
但這兩三年，AI 近乎改寫了所有白領工作的底層結構——工程師、行銷企劃、設計師、客服、數據分析，當然也包含產品經理。更尷尬的是：產品經理過去引以為傲的能力，像是寫規格書、做分析、跨部門溝通協調以及推動專案進行等等，如今看起來好像都能被 AI 幫你做一點，甚至在不知不覺中幫你做很多。
於是，問題來了：產品經理的地位到底是正在式微，還是益發重要，並且被賦予更多任務？
曾經有當 PM 的朋友跟我抱怨，主管要求他不只要做規劃案，還要把軟體真的開發出來！嗯，這件事表面看起來像是主管亂來，但更深層其實是在反映一個新現實：當做出東西的門檻下降時，組織會重新定義誰該負責把它做出來。
而這正是今天這篇文章想談的核心：在 AI 時代，產品經理到底該何去何從？
現狀與挑戰：PM 的工作沒有變少，而是變得更像一場綜合格鬥
▲ PM 的核心價值：在使用者、商業與技術之間找到平衡點。
如果要問我的意見，我對 PM 的未來是抱持審慎樂觀的看法。理由很簡單，因為 AI 會取代的是產出，而不是判斷；會自動化的是流程，而不是責任。
但這句話如果只停在口號階段，就等於沒說。所以，我認為真正的挑戰是：PM 的工作內容，正在發生以下三個結構性變化。
▲ AI 時代 PM 面臨的三大結構性變化：產出爆炸、速度提升、職責漂移。
1) 產出爆炸：產製文件變容易了，但要兼顧決策品質更難了
過去，一份 PRD、Roadmap、競品分析或使用者訪談摘要，需要 PM 花掉大量時間整理、寫作與校稿。現在呢？AI 可以幫你在幾分鐘內把初稿生出來。
問題是：文件產製的速度變快，不代表整體的品質或開發出來的產品更好。簡單來說，你會得到一堆看起來很完整、其實很空洞的東西。這種現象，最近甚至被稱為「workslop」：AI 生成了貌似完成、但品質不足的內容，最後變成同事要花時間去清理的負擔。《Business Insider》也報導過「workslop」在白領工作中的擴散，甚至有人要花很多時間修補 AI 產出帶來的混亂。
PM 的痛點是什麼？你不只要產製與規劃產品內容，還要辨識內容的真偽與承擔決策的責任。當大家都能用 AI 產出漂亮的簡報或看似完整的產品規格書時，PM 的價值不再是我寫得比較多、可以跟工程師溝通，而是我更理解市場與客戶，判斷得比較準。
2) 速度提升：開發變快了，但瓶頸移到組織摩擦上
McKinsey 的研究指出：在一些任務上，生成式 AI 可以讓軟體開發者把工作完成得接近兩倍快。GitHub 也整理過研究與實務觀察，提到像 Copilot 這類工具在特定情境下可帶來顯著效率提升，例如「55% 更快完成任務」等指標。MIT 的田野實驗也提供較保守、但更接近現場的證據：在不同組織情境下，Copilot 對產出（例如每週完成的 PR 數）帶來約 7%～22% 的提升區間。
你看，透過 AI 工具的輔助，確實讓寫程式更快了——但這不代表交付產品等比例變快。
Atlassian 所發佈的「State of Developer Experience Report 2025」報告，就點出一個很殘酷的矛盾：幾乎所有開發者都感受到 AI 帶來的省時，其中 68% 說自己每週省下超過 10 小時；但同時，組織低效率（包括等待、溝通、找資料、協作卡關等）也能把這些時間吃掉。
對 PM 而言，這句話翻譯成白話就是：工程變快，反而讓決策、對齊與取捨更快被放大成主要瓶頸。而這些，偏偏是 PM 最容易被責怪、但最難被量化的工作。
3) 職責漂移：當 AI 降低了做出原型的門檻，PM 就被推向更靠近產出的一側
我知道，最近很多 PM 的壓力都很大！因為 AI 讓做出東西變得容易，公司主管難免就會開始問：
那你為什麼不自己先做一個版本？
《Business Insider》在 2025 年底報導：LinkedIn 乾脆把原本知名的 Associate Product Manager（APM）計畫砍掉，改推 Associate Product Builder（APB）計畫，也就是培養所謂的 full-stack builders——更能同時做產品、做設計，也能動手做出東西的人。同一時期，《Business Insider》也報導 Meta 內部讓 PM 用 AI 輔助進行 vibe coding 來快速做原型、直接拿去給高層看。
由此可知，這不是單一主管的任性，而是一種更廣泛的趨勢：PM 正在從協調者的角色，被推向建造者。
PM 對未來可以審慎樂觀，但前提是你必須升級成新物種
▲ PM 正在分裂成兩種人：停在舊世界的協調者，與能把 AI 變成槓桿的建造者。
話說回來，我之所以審慎樂觀，是因為 PM 的核心價值，從來不是我會寫技術文件或我會主持會議。
我的印象裡，PM 的核心價值來自做好以下這三件事：
- 定義問題：到底在解決什麼問題、為什麼值得花時間解決
- 做取捨：資源有限時，先做什麼、後做什麼
- 把不確定性變小：用實驗與迭代，讓團隊往正確方向走
AI 可以幫你把資料整理得更快，把訪談摘要寫得更漂亮，把 A/B 測試假設列得更完整——但 AI 很難替你承擔一件事：「如果做錯了，誰負責？」
而且，愈是 AI 時代，愈會出現一個反直覺現象：當產出成本趨近於零，判斷成本會變得更高。因為你會面對一大堆看起來都合理的方案，而你必須選一個去賭。
所以，PM 這個職務不會消失，但很可能會分裂成兩種人：
- 一種是還停在舊世界的 PM：會寫、會講、會開會，但交付速度追不上 AI 時代的節奏。
- 另一種是能把 AI 變成槓桿的 PM：不只會規劃，還能用 AI 把原型做出來、把數據跑出來、把市場驗證做起來。
而這，就是我說的新物種。
職能轉變：從交棒到先開始跑一段，再把棒子交出去
▲ 從「寫規格交棒」到「先跑一段再交棒」：PM 角色正在轉變。
如果你無法理解，我可以把它講得更直白一點：
(a) 過去：PM 把規格寫好，交給工程師
這個時代的 PM，很像建築師：畫圖、規劃、對齊、確保大家照圖施工。你不一定要自己拿鐵鎚，但你要確保最後房子能住。
(b) 現在：PM 可能得先做出一個能跑的雛形，甚至做掉一部分開發
這個時代的 PM，更像設計師和施工的工頭：你要能用最低成本，先把關鍵假設跑一遍，做出可測試的東西，讓使用者或內部能快速回饋。
請注意：這不等於 PM 從此變身為工程師。更精確的說法是：PM 必須具備把想法變成可驗證原型的能力。你做的可能不是最漂亮、最完整或最可擴充的系統，但你做的是能快速讓真相浮現的東西。
話說回來，這也是為什麼有些 PM 會被主管要求把軟體做出來：如果主管腦袋正常，他真正希望的是你不要只交一份充滿想像的草稿，而是交一份可以驗證的東西。
但這裡有一條危險的界線：
- 健康的趨勢：PM 具備原型能力，縮短迭代週期，讓工程師把力氣用在真正被驗證過的方向。
- 不健康的漂移：公司用「AI 很方便」當藉口，讓 PM 承接工程責任，卻不給資源、不改流程、不調整 KPI，最後導致 PM 整個人被快速耗盡。
所以，判斷關鍵往往不是你該不該做，而是你做的是不是正確層級的東西？
如果主管叫 PM 去開發，到底合不合理？
▲ 判斷主管要求是否合理的三個關鍵問題。
我會用三個問題，幫你判斷這是不是正確的發展？
問題 1：公司要你做的是原型，還是產品？
- 原型：用來驗證需求、流程、價值主張。可以粗糙，但要快。
- 產品：要可維運、可擴充、監控和資安審核。當然，這不是 PM 一個人能扛的責任。
如果主管講不清楚，PM 就要主動把話講清楚：
「我可以在兩週內做出可測試原型，但若要上線營運，必須由工程師負責架構、資安、監控與維運。」
問題 2：你做完以後，誰來負責技術債？
AI 很會幫你把東西拼出來，但也很容易把技術債埋進去。如果公司要你交付的是會長期運作的系統，那一定要釐清責任。
問題 3：KPI 有沒有跟著調整或轉換？
如果你同時要做 PM 的工作，又要做工程師的工作，但主管在打考績的時候，卻還是用類似需求交付數、規格完整度或跨部門協調等 KPI 來評估你，那你會死得很難看。
所以，我會建議 PM 把這件事以一個專案模式去談：
- 明確範圍：MVP 到什麼程度
- 明確角色：工程要接手哪些部分
- 明確節奏：兩週原型、四週驗證、再決定是否產品化
評判一位 PM 是否成熟，重點不在於你多會規劃產品規格，而是在於你能否把任務、方向定義清楚？
建議與指南：給正在做 PM、或想投入 PM 的你——我會這樣升級
▲ AI 時代 PM 必須鍛鍊的三層能力：精準判斷、原型實作、人機協作。
我會把 AI 時代的 PM 能力，分成三層肌肉。你不需要（也真的很難）一夜變成全能，但你要知道自己該練哪一塊？
第一層：AI 讓你變快，但你必須先變得更精準
核心能力：問題定義、優先順序、指標設計與取捨邏輯。
AI 可以幫你列出一堆 OKR、指標、Roadmap，但你要能回答：
- 這個指標真的能代表價值嗎？
- 這個功能如果不做，會死嗎？
- 這個決策背後的假設是什麼？如何驗證？
我的建議是：把 AI 當成辯論對手，每天逼自己練三個問題：
- 這個需求背後的 job-to-be-done 是什麼？
- 最小可驗證版本是什麼？
- 失敗的最早訊號會是什麼？
第二層：你要會做可驗證原型，讓你從會議裡走出來
核心能力：快速原型、流程設計與基本技術素養（不需要寫得妙筆生花，而是懂得夠用）。
你不一定要成為資深工程師，但你至少要能做到其中一種：
- 用 no-code / low-code 做一個能跑的 Demo
- 用 AI 輔助寫出簡單前端頁面 + 串 API
- 用現成服務（Auth、DB 或分析工具）拼出 MVP
為什麼？因為這會改變你在組織中的位置：你不再只是提出需求的人，你會變成能把假設落地的人。
當然，這也呼應了現在的國際職場趨勢：組織愈來愈偏好能跨域的 builder 型人才，甚至直接重塑培訓制度。
第三層：你要會設計人機協作的回饋迴路，這會是下一個護城河
誠然，AI 工具愈來愈像一個代理人（agent）。而代理人最缺的不是能力，是回饋。St. Louis Fed 的研究指出：在 2024 年 11 月調查中，使用生成式 AI 的人平均省下約 5.4% 工時，以每週 40 小時計算約 2.2 小時；但整體平均下來（包含非使用者），節省約 1.4% 工時。這個數字告訴我們：AI 的效益不會自動爆炸，它需要被妥善設計才能放大。
也因此，未來 PM 很重要的能力會是：
- 你怎麼讓 AI 在產品裡學到正確的東西？
- 你怎麼定義成功與失敗？
- 你怎麼設計使用者回饋、標註、評估與迭代流程？
換句話說：PM 會從寫需求，進化成訓練系統的人。
我看到的趨勢，不是 PM 消失，而是重新分工
▲ 正在發生的三大國際趨勢：AI 技能成基本盤、瓶頸在協作、企業推動 PM 成為 builder。
最後，請注意這三個正在發生的趨勢：
趨勢 1：AI 技能成為職場基本盤，好奇心與學習力變得更關鍵
世界經濟論壇（WEF）的《Future of Jobs Report 2025》指出，AI 與大數據等技能是未來數年成長最快的技能之一，並且「好奇心與終身學習」的重要性也持續上升。這對 PM 意味著：你不需要一開始就什麼都會，但你不能停止學，也不能只站在岸上評論浪潮。
趨勢 2：工程效率提高，但真正的瓶頸在協作與流程
Atlassian 的「State of Developer Experience Report 2025」報告指出，大量時間仍消耗在 IDE 之外的摩擦與低效率上。所以 PM 的價值會更聚焦在：對齊、取捨、流程設計、讓團隊少走冤枉路。你不是被弱化，你其實是被推到更核心的地方——只是那個地方更難、也更需要成熟。
趨勢 3：企業正在把 PM 往 builder 的方向推
LinkedIn 重塑人才培訓、Meta 讓 PM vibe coding，這些案例都在說明：PM 不一定要寫到很深，但必須能把價值用更低成本、更快速度做出可驗證版本。
美麗與哀愁仍在，但你可以選擇把哀愁鍛造成更漂亮的自己
▲ 美麗與哀愁仍在，但你可以選擇把自己升級成新物種。
如果你問我：AI 時代的 PM 會不會更辛苦？
我會說，肯定會。
因為你要懂得更多，你要動手做更多，你要更早交付、更快迭代與更精準取捨，而且你還要處理 AI 帶來的看似完成、其實需要人類收拾的混亂。
但如果你問我：AI 時代的 PM 還值不值得做？
我也得說，更值得。
因為在產出愈來愈廉價的世界裡，好的判斷會變得愈來愈昂貴；在每個人都能做出漂亮文件的時代，能把問題定義清楚、能把真相快速挖出來、能把團隊帶往正確方向的人，反而更稀缺。
所以，我的審慎樂觀不是安慰，而是一種要求：你可以懷念那個只要寫好規格就能交棒的年代；但你更應該把自己升級成——既能定義方向，也能做出雛形，還能設計迭代回饋迴路的 PM。
親愛的，那不是被迫多做事。
那是你在新時代，重新拿回自己尊嚴與價值的方式。
延伸閱讀
- 講師的數位資產管理術：用 AI 把授課經驗變成可複利的系統
- 知識工作者的獲利覺醒：從現金流思維到微型組織時代的生存法則
- Podcast 筆記術：6 個步驟，用 Podwise + Anytype 搭建內容飛輪
☕️ 請 Vista 喝杯咖啡
