最近看到好幾篇文章都在談 AI 時代 PM 角色的變化，而且不是泛泛而談。Anthropic 的 Claude Code 產品負責人 Cat Wu、設計負責人 Jenny Wen、成長負責人 Amol Avasarala，還有 LangChain 創辦人 Harrison Chase，幾個人從不同角度講的其實是同一件事: 傳統產品管理的 playbook 建立在一個前提上——你的技術底層是大致穩定的。這個前提已經不成立了。

以下整理幾個小編覺得最有料的觀點。

1. 地板在你腳下往上升

Cat Wu 用了一個很精準的比喻: 你是在一塊正在往上升的地面上蓋東西（building on ground that’s rising underneath you）。

她拿自己的經驗舉例: 2024 年 10 月開始，她每次新模型發布都會用 Claude Code 測試同一個任務——幫 Excalidraw 加一個表格工具。Sonnet 3.5 失敗，Opus 4 偶爾成功（好到可以拿去做預錄 demo），到 Opus 4.6 已經穩定到敢在幾千個開發者面前現場演示。

METR 的研究數據更驚人: Opus 4.6 有一半的時間能完成人類需要近 12 小時的軟體任務，而 16 個月前的 Sonnet 3.5 只能做人類 21 分鐘的任務——41 倍的跳躍。

當底層能力以這種速度提升，你在專案開始時設計的限制條件，可能在專案中途就消失了。傳統 PM 那套「先充分調研、寫好 PRD、鎖定路線圖、按月執行」的做法，前提就不存在了。

2. PM 的新工作流: 三個工具、一個下午

Cat Wu 分享了她現在的工作分配:

  • Claude.ai: 當思考夥伴，丟策略想法、處理棘手問題
  • Claude Code: 做原型、寫 eval、跑腳本，產出是程式碼
  • Cowork: 處理其他一切——收信、追待辦、做簡報、搜 Slack 歷史紀錄

這套組合最大的改變是: 從想法到可用原型的距離，從幾週壓縮到一個下午。Decagon 的產品總監 Bihan Jiang 也說了類似的話——以前把東西放到客戶面前測試要好幾週，現在從 Cowork 拉 context 開始，幾個小時就能用 Claude Code 做出可以 demo 的東西。

這不只是效率提升，是遊戲規則的改變。當建造成本趨近於零，過去因為「實作成本太高所以不值得做」的想法，現在都值得試一試。VentureBeat 有篇文章的觀察很到位: 他們公司的 PM 直接自己建了一個功能，不是寫需求、不是開 ticket，是自己建好、測好、部署上線，一天搞定。

3. 角色邊界正在融化

這可能是所有變化裡最深層的一個。Cat Wu 說她們團隊裡，設計師在 ship 程式碼、工程師在做產品決策、PM 在建原型和跑 eval。

Jenny Wen 從設計師的角度印證了同樣的事。她給出一組很具體的數字: 幾年前設計師 60-70% 時間花在做視覺稿和原型，現在這部分壓縮到 30-40%，多出來的時間用在跟工程師直接協作，甚至自己寫程式。

為什麼？因為改變是從工程端發起的。當工程師可以同時跑七個 Claude agent，每個人都能隨手把想法做成可運行的版本。設計師如果還在花兩週做精美的 mockup，那份 mockup 出來的時候，功能可能已經上線了。

Jenny 說了一句讓人停下來想的話:「連工程師自己都跟不上自己了。」

編按: LinkedIn 最近把它的 Associate PM 計畫改名為「Product Builder」計畫，訓練內容橫跨產品、設計、工程三個領域。這不是漸進式調整，是對角色本身的重新想像。

4. 工程變快 3 倍之後，PM 反而成了瓶頸

這是 Amol Avasarala 在 Lenny’s Podcast 上講的，小編覺得是整篇最反直覺的洞見。

主流敘事說: 工程師用了 AI 工具產能翻倍，公司需要的 PM 數量會減少。Amol 說剛好相反——Anthropic 正在大規模招 PM。

邏輯很簡單: 一個典型團隊過去是 5 個工程師配 1 個 PM。工程師用了 Claude Code 之後產能翻 2-3 倍，等於變成 15-20 個工程師配 1 個 PM。工程的產出爆炸了，但 PM 的產能沒有同比成長，結果 PM 變成整個團隊最擠的角色。

Anthropic 的做法分兩層: 一是大量招 PM，二是推「兩週規則」——小於兩週工程量的專案由工程師自己當 mini-PM 處理（包括跟法務、資安的溝通），PM 只在大專案才正式介入。

這裡面隱藏的訊息是: 能自己兼半個 PM 的工程師，價值直接乘以 10 倍。反過來，能寫程式碼的 PM，議價能力也是過去好幾倍。

5. 設計流程已死

Jenny Wen 去年 9 月在柏林的設計研討會上宣布「設計流程已死」，台下反應完全撕裂——一半人瘋狂點頭，一半人直接反駁。

她指的是經典的雙鑽石模型: 先發散、再收斂、再發散、再收斂。這套設計師曾經奉為聖經的流程，在 AI 速度面前已經跑不動了。而且三、四個月後她自己回頭看，覺得連那場演講都已經過時了。

被吃掉的很明確: 大量的 mockup、長期願景文件、精美的故事簡報。願景的有效期從過去的 2-5 年，縮短到現在的 3-6 個月。

但沒被吃掉的東西也很有意思。Figma 在兩件事上仍然不可取代: 一是同時探索 8-10 個方向並排比較（程式碼環境天生是線性的），二是極細微的視覺和互動調整。

最讓人吃驚的是 Jenny 對「品味與判斷」的看法。很多設計師把品味當成最後的堡壘，但 Jenny 的回應是:「AI 的品味和判斷會愈來愈好，我們可能太執著於這一點了。」不過她也指出了一個更根本的問題: 做軟體最難的部分從來都不是建造它本身，而是你和另一個人對方向意見不合。AI 可以給建議，但沒辦法解決你和同事之間的爭執。

6. 做簡單的事

Cat Wu 的團隊有四個核心原則，小編覺得每一個都蠻值得咀嚼的:

🔹 用短衝刺取代長路線圖: 鼓勵團隊每個人（不只 PM）去做「side quest」——在正式路線圖之外，花一個下午自己試一個想法。Claude Code 桌面版、AskUserQuestion 工具、todo list 功能，都是這樣冒出來的。

🔹 demo 和 eval 優先於文件: 不開傳統站會，改成分享 demo。因為一個下午就能做出原型，押錯注的代價很低。Cat Wu 的建議: 寫完 spec 之後，丟給 Claude Code 看它能不能直接做出來，「即使是粗糙的原型也能改變整個對話」。

🔹 每次新模型都重新檢視既有功能: 你上線一個功能，然後更好的模型出來了，你的功能可能瞬間變得好得多。最好的方式是每天使用自己的產品，故意叫它做你覺得太難的事。

🔹 做簡單的事 (do the simple thing): 如果你巧妙地繞過了模型的限制，那個繞法在下一個模型出來時就會變成不必要的複雜度。實作越簡單，新能力到來時越容易替換。Cat Wu 舉例: Claude Code 的 todo list 一開始要靠系統提示詞不斷提醒模型更新清單，這是個 hack。下一個模型出來後，這行為自然就有了，hack 直接刪掉。她們的 system prompt 隨著每個新模型都在瘦身，Opus 4.6 砍了 20%。

7. AI 開始自動跑產品實驗了

Anthropic 內部有個叫 CASH 的專案（Claude Accelerates Sustainable Hypergrowth，Amol 自己說這縮寫有點土），用 Claude 自動跑完整的成長實驗迴圈: 從歷史數據找機會 → 建構功能 → 測試品質紅線 → 上線分析結果。

目前的水準大概相當於兩到三年年資的初級 PM——還不到資深水準，但已經可以對文案修改、小型 UI 微調這類低風險實驗直接按下啟動。Amol 說 Opus 4.5 之前跑不起來，Opus 4.6 上線後「終於開始印錢」。

但有一個步驟 Claude 完全做不到: 跨部門對齊。Amol 的原話是:「就算有了 AGI，要讓六個人在同一間房間裡達成一致還是不可能。」

8. 不會設計也能做出好產品

Neethan Wu 的故事是這波變化的一個具體縮影。三個月前他完全不會 UI 設計，在 TikTok 和 Amazon 當工程師，設計完全空白。三個月後，他每週都在交付可上線的設計成品。

他組了一套三層系統:

  • Skills 層: 把資深設計師的判斷標準編碼成 AI agent 的指令。例如 Paul Bakaus 做的 Impeccable，專門抓 AI 生成介面最常犯的錯——濫用字型、低對比灰字、巢狀卡片
  • Canvas 層: 設計畫布，但不綁定特定 AI。例如 Paper 用 HTML/CSS 直接建構，設計出來就是程式碼
  • Inspiration 層: 訓練眼光。Variant 可以輸入想法生成無限設計詮釋，Style Dropper 能吸取任何設計的視覺 DNA

這套框架的厲害之處在於它跟設計本身無關，而是跟「怎麼用 AI 探索一個新領域」有關: 找到最好的 Skills（借用專家判斷力）、選一個 Canvas（工作介面）、持續用 Inspiration 訓練品味。PM 要跨界學設計、設計師要學寫程式、工程師要懂產品思維——門檻都在急速降低。

9. Builder 或 Reviewer? LangChain 創辦人的 EPD 重組論

Harrison Chase（LangChain 創辦人）寫了一篇蠻火的長文（73 萬次閱讀、4000+ 收藏），從 EPD（Engineering, Product, Design）三個角色同時受衝擊的角度來分析。他的核心觀點跟上面 Anthropic 幾位講的方向一致，但框架更清晰。

他說傳統 EPD 流程是線性的: 有人（通常是 PM）有想法 → 寫 PRD → 設計師做 mockup → 工程師寫程式碼。這套流程之所以存在，是因為「建造」本身很花時間和精力，所以需要分工和溝通機制。但 coding agent 把建造成本壓到趨近於零之後，這整條鏈就斷了。

傳統 EPD 流程
傳統 EPD 流程: 想法 → PRD → 設計稿 → 程式碼，一條線走到底

取而代之的是: 任何人都能直接做出原型，然後交給 EPD 審查。問題是——原型太容易生了，審查反而成了新的瓶頸。

新 EPD 流程
新流程: 原型先行，EPD 三方同時審查，瓶頸從建造轉移到 review

這跟 Amol 講的「PM 成為瓶頸」完全吻合，只是 Harrison 把範圍擴大到整個 EPD 都面臨審查能量不足的問題。

Harrison 提出了一個蠻清楚的二分法: 未來 EPD 角色基本上分成兩種人:

🔹 Builder: 有產品直覺、會用 coding agent、有基本設計品味。在護欄（測試套件、元件庫）的保護下，能獨自把小功能從想法做到上線，大功能至少做出可用的原型。

🔹 Reviewer: 某個領域的頂尖系統思考者——工程架構、產品策略、或設計體驗。負責審查 Builder 產出的東西，確保品質。門檻很高，而且要快，因為要審的東西比以前多得多。

Builder vs Reviewer
Builder 與 Reviewer 的光譜: 工程、產品、設計三種角色都落在這兩極之間

如果你是工程師，要嘛把系統設計練到極致當 Reviewer，要嘛補上產品和設計能力當 Builder。PM 和設計師也是同理——要嘛有極強的領域心智模型專門審查，要嘛跳進 coding agent 的世界自己動手建。

他還有一個觀點小編覺得蠻尖銳的: 好的產品思維比以前更有價值，壞的產品思維比以前更浪費資源。為什麼？因為一個爛想法現在可以在一個下午變成原型，然後帶著「都已經做好了，合進去吧！」的慣性要求審查——這不只浪費審查者的時間，還有把爛功能塞進產品的風險。

最後一個有趣的點: Harrison 說 PRD 沒有真的死，死掉的是「PRD → mockup → code」這條流水線。需求描述仍然不可或缺——審查者需要知道原型裡哪些行為是有意為之、哪些只是意外。他甚至丟了一個挑釁的問題: 未來的 PRD 會不會就是一組結構化的 prompt？

10. 不同的聲音

上面主要是 Anthropic 的視角，但業界的討論比這更複雜，至少有三種不同立場。

「不是所有 PM 都在同一條船上」派。 Michele PM 區分了兩種 PM: 流程型（靠寫文件、跑儀式、保持專案運轉來建立身份）和決策型（靠取捨、判斷、conviction 來建立身份）。AI 拿走的是工作裡「舒適」的部分，前者感到被威脅，後者反而被解放——行政負擔掉了，留下的是他們本來就在乎的工作。Art Kreimer 講得更不客氣:「很多『成功的』PM 其實是靠錯誤的理由成功的——如果你的優勢是整合、寫文件、協調，那個優勢正在被侵蝕。」他認為 PM 角色正在收斂成一件事: 在不確定性下快速做出高品質決策，而且對的次數要夠多。LinkedIn 把 Associate PM 計畫改名為「Product Builder」，訓練內容橫跨產品、設計、工程，入場券從「會跑流程」變成「能展現品味和判斷力」。Andrew Ng 也直接點名——工程速度在爆炸，但產品決策速度沒跟上，有些團隊甚至討論「1 個 PM 配 0.5 個工程師」的極端比例。

「砍 PM 的公司會後悔」派。 Meta 砍了 3,600 人、Tidal 砍掉整個 PM 團隊、Microsoft 砍了 15,000 個職位。Product Party 預測這些公司 12-18 個月內會學到昂貴的一課。AI 可以自動化文件、加速開發，但它不懂排序——不知道 Feature A 必須在 Feature B 之前 ship 因為 A 驗證了讓 B 值得做的市場假設。它也不懂 momentum，不懂組織政治，不懂什麼時候該放棄一個數字上合理但戰略上錯誤的方向。PM 的價值從來不是開站會和寫 spec，而是同時看見工程能做什麼、客戶真正需要什麼、商業上需要什麼存活，然後在三者之間做取捨。Balsamiq 訪問的產品專家也說:「AI 可以在幾秒內做出原型，但它不能告訴你這個功能到底解決了真正的用戶痛點，還是只是增加了複雜度。那個判斷是純粹的人類產品思維。」

「這套敘事本身有盲點」派。 Anthropic 的產品核心就是 AI 模型，模型每進步一代產品價值可能翻 10 倍——在這種曲線上短衝刺當然合理。但如果你做的是銀行系統、醫療軟體、或任何需要法規合規的產品，「一個下午做好原型」不只不現實，可能還違法。多數公司的產品價值曲線是線性的，傳統 PM 的 playbook 沒有那麼過時。Jenny Wen 在柏林宣布「設計流程已死」時台下一半人反駁——雙鑽石模型存在是有原因的，AI 讓你建造得更快，但建造錯誤的東西也更快了。而「PM 要會寫程式」可能也是階段性風潮，十年前是「PM 要會 SQL」，五年前是「PM 要懂 Python」，重點從來不是工具本身，是能不能問出對的問題。bencoding.com 有一個很好的比喻: 如果組織不能對取捨做出乾脆的決定，AI 會把產品變成吃角子老虎機——大量產出，結果不可預測。速度不等於方向。

小編覺得真相取決於你的產品離 AI 指數曲線有多近。越近的公司變化越劇烈，越遠的公司傳統 PM 技能保鮮期還沒那麼短。但不管在哪個位置，有一件事各方都同意: 把「協調」和「寫文件」當核心價值的時代，確實在結束。

什麼在升值、什麼在貶值

把上面正反觀點放在一起看，小編覺得有一條清楚的主線: 工作的價值分布正在重新排列，只是速度因公司而異。

正在貶值的:

  • 微優化和長期路線圖（願景的保鮮期可能只剩 3-6 個月）
  • 精美的設計稿和 PRD（demo 和原型取而代之）
  • 執行型的協調工作（AI 正在吃掉「人肉中間件」層）
  • 靠流程和文件建立的專業身份

正在升值的:

  • 判斷力: 決定「做什麼」和「為什麼做」，在不確定性下快速做出高品質決策
  • 跨部門對齊: 就算有了 AGI，讓六個人在同一間房間達成共識還是不可能
  • 建造能力: 能自己從想法做到原型，但前提是問對問題
  • 韌性: 願意每三個月丟掉舊做法，接受自己會的東西可能很快過期

Amol 在訪談最後說:「進來的第一件事，是接受你過去 50-70% 的工作方式必須整個丟掉。」這句話不一定適用於所有產業，但方向沒有錯。Jenny Wen 被問到座右銘，想了想，說: It is what it is。在一切都在變的世界裡，也許這種輕盈感才是讓你繼續走下去最需要的東西。

參考資料: