不寫 PRD、不管 Jira、不做表面工夫：Anthropic 對產品經理的三個殘酷要求
不寫 PRD、不管 Jira、不做表面工夫：Anthropic 對產品經理的三個殘酷要求
我認為大多數產品經理正在練習一套即將失效的武功。
這話講得很重，但看看 Anthropic 最近開出的 PM 職缺，你會發現他們完全沒提到你以為最重要的那些東西——不要求你寫過多完美的 PRD，不在乎你管理了幾百張 Jira ticket，也沒興趣知道你跟利害關係人的會議開得多勤。
他們只要求三件事：
- 知道該開發什麼，以及不該開發什麼
- 親自動手建立原型與迭代
- 曾打造過真實的產品
乍看之下很基本，對吧？但仔細想想，這三條要求砍掉了多少傳統 PM 的「核心能力」。而更讓人不安的是——這不只是 Anthropic 的特殊偏好，這正在成為整個 AI 產業對 PM 的標準門檻。
背景：為什麼傳統 PM 的工具箱正在生鏽
在聊那三個要求之前，得先理解一個根本性的改變。
傳統軟體開發建立在一個基本假設上：軟體行為是確定性的（deterministic）。你定義規格、工程師實作、QA 驗證、上線。同樣的輸入永遠產生同樣的輸出。PRD 之所以有效，是因為你可以精確描述每一個邊界條件。
但 AI 產品是機率性的（probabilistic）。同樣的 prompt 可能產生不同的回答。模型在某些任務上表現驚人，卻在看似相似的任務上徹底失敗。你沒辦法寫一份 PRD 精確規格化「Claude 應該怎麼回答這個問題」——因為連 Anthropic 自己都無法完全預測模型的行為邊界。
這個根本差異讓傳統 PM 的整套工具鏈開始鬆動：
| 傳統 PM 實踐 | 為何在 AI 時代失效 | AI PM 的替代方案 |
|---|---|---|
| 撰寫詳細 PRD 規格 | AI 行為無法完全預先規格化 | 撰寫 Evals（評估框架）定義「什麼算好的」 |
| 以 OKR 衡量成功 | 需要準確度、幻覺率等 AI 特有指標 | 雙軌指標：傳統業務指標 + AI 品質指標 |
| 功能上線後轉維護 | 模型需要持續監控與重訓練 | 持續生命週期管理 |
| 需求 → 規格 → 開發 → 發布 | AI 能力邊界充滿不確定性 | 原型優先、資料驅動的迭代循環 |
Andrew Ng 在 No Priors podcast 上說得更直接：AI 輔助編碼壓縮了整個開發循環，現在的瓶頸不再是工程產能，而是產品決策。他觀察到團隊比例正在從傳統的「1 PM : 4 工程師」翻轉——工程產出加速了，但每一個產出仍然需要人類判斷、策略思考、使用者同理心和市場驗證。
換句話說：建造變便宜了，但決定「建造什麼」變得更昂貴了。
這就是 Anthropic 那三個要求背後的邏輯。
要求一：知道該開發什麼，以及不該開發什麼
"When it is cheap to build, the most expensive thing you can do is build the wrong thing."
這句話來自 Mind the Product 2026 策略指南，精準概括了第一個要求的核心。
當建造成本趨近於零——用 Claude Code 幾小時就能做出一個可用原型——「決定做什麼」的品質就成了最大的槓桿點。以前一個錯誤的產品決策可能浪費團隊三個月的開發時間，現在浪費的不是開發時間，而是更珍貴的東西：市場窗口、用戶信任、推理成本。
特別是推理成本這一點。AI 功能跟傳統軟體不同，每一次使用者互動都有真實的 API 呼叫成本。一個沒人真正需要的 AI 功能不只是佔版面，它每天都在燒錢。Mind the Product 把這類功能叫做「殭屍功能」——在 AI 時代，殭屍功能的代價比傳統軟體高出數倍。
好的 AI PM 如何做 Build/Kill 決策
我在研究中發現一個實用的框架叫 WIN Test，特別適合 AI 產品的機會評估：
- Worth solving：這個痛點真實、頻繁，且與金錢或風險直接相關？
- Information advantage：我們擁有可以隨時間改善的獨特資料？
- Non-obvious：這需要真正的產品洞察，還是任何人都能想到？
但光有框架不夠。更關鍵的是——你有沒有勇氣 kill 一個看起來很酷但不該做的東西。
Anthropic 的做法是預先設定 Kill Criteria（失敗條件），在任何功能投入開發前就約定好：
品質門檻：負面反饋率持續超過 X% → 停止
效能門檻：回應延遲持續超過 Y 秒 → 停止
經濟門檻：每用戶成本超過訂閱價值的 Z% → 停止
這不是悲觀主義，這是紀律。當你可以在兩天內建出任何東西時，知道「不做什麼」的能力，比「能做什麼」重要十倍。
AI 產品的 PMF 長得不一樣
傳統 PM 熟悉的 Product-Market Fit 指標在 AI 產品上需要擴展。Bessemer Venture Partners 的 AI PMF 框架提出了雙軌指標的概念：
| 指標層面 | 傳統指標 | AI 特有指標 |
|---|---|---|
| 用戶 | 互動率、留存率 | 信任度、理解度、採用深度 |
| 產品 | DAU/MAU、NPS | 準確度、幻覺率、回應品質 |
| 商業 | 營收、獲客成本 | 每次推理成本、成本/價值比 |
你看到了嗎？AI PM 要追蹤的不只是「有多少人用」，還要追蹤「用的人信不信任這個產品」。一個 AI 功能如果準確率只有 70%，就算 DAU 很高，使用者的信任正在被消耗——而信任一旦消耗殆盡，要重建比從頭來還難。
要求二：親自動手建立原型與迭代
這是三個要求中最讓傳統 PM 不舒服的一個。
Anthropic 的 JD 上白紙黑字寫著：
"Build prototypes yourself to validate ideas before committing resources" "Creatively build MVPs and prototypes to validate product-market fit with the lowest cost possible" "Prototype with AI tools like Claude Code"
不是「跟工程師合作建造原型」，是「你自己建造」。
Anthropic 內部的原型優先文化
Anthropic Product Lead Catherine Wu 公開分享了他們的產品開發流程，Sachin Rekhi 在 LinkedIn 上對此做了詳細分析：
graph LR
A[有想法] --> B[跳過規格書
直接用 Claude Code
建造原型]
B --> C[將原型發布給
全公司工程師]
C --> D[追蹤使用數據
收集反饋]
D --> E{高使用率 +
正面反饋？}
E -->|Yes| F[進入正式路線圖]
E -->|No| G[回到迭代
或放棄]
注意這個流程的前提：PM 必須有能力在數小時內自己建造一個可用的原型。不是畫 wireframe 請工程師實作，是自己動手做出一個真的能用的東西，然後丟進真實環境看反應。
這不是 Anthropic 在裝酷。這是因為當你的產品核心是 LLM，最有效的驗證方式就是讓人直接用。任何紙上談兵的規格書都無法捕捉 AI 產品的微妙體驗——回應的語氣對不對、延遲感受如何、哪些邊界情況會觸發幻覺。這些只有做出原型、親手測試才能知道。
不只是 Anthropic 在這樣做
看看其他數據：
Bolt.new 在不到五個月達到 $40M ARR。Lovable 三個月內衝到 $17M ARR。這些 AI 原型工具的爆炸性成長說明了一件事：整個產業正在擁抱「先做出來再說」的開發模式。
Aakash Gupta 整理的 AI PM 技術棧把 PM 需要的技術能力分成八層：
| 層次 | 能力 | 你需要懂到什麼程度 |
|---|---|---|
| L1 | Foundation Models | 理解模型的能力與限制 |
| L2 | Prompt Engineering | 能系統性地工程化輸入 |
| L3 | Context Engineering | 知道何時用 RAG、何時 Fine-tune |
| L4 | AI Prototyping | 用 v0/Cursor/Claude Code 快速建造 |
| L5 | Testing & Evals | 設計 AI 特有的評估框架 |
| L6 | AI Agents | 理解並建造 AI Agents |
| L7 | AI Feature Execution | 將 AI 融入產品核心流程 |
| L8 | AI Product Strategy | 驅動公司層級的 AI 策略 |
L4 那一層——AI Prototyping——已經不是「加分項」，而是「基本門檻」。
怎麼說呢，Evals 才是新貨幣
這裡要特別提一個正在發生的典範轉移：Evals 正在取代 OKR 成為 AI PM 的核心工具。
傳統 PM 定義成功靠 OKR。AI PM 定義成功靠 Evals——一套評估框架，明確定義「什麼算是好的回應」「哪些邊界情況必須處理」「品質底線在哪裡」。
"You don't define success through OKRs anymore. You define it through evals."
這意味著 PM 不只要能建造原型，還要能定義測試這個原型的標準。你做出了一個 AI 客服機器人的原型？很好。但你同時需要寫出 50 個測試案例，涵蓋正常對話、邊界情況、敏感議題、幻覺觸發場景，然後用這些 evals 來判斷原型到底夠不夠好。
要求三：曾打造過真實的產品
Anthropic 的 JD 有一句很有意思的話：
"Founder background is a plus."
不是「大公司 PM 經驗優先」，是「創辦人背景加分」。為什麼？
因為 AI 產品開發的不確定性程度，更像是從零到一的創業，而不是在成熟產品上做增量優化。你面對的不是「這個按鈕放哪裡比較好」的問題，而是「這個東西到底有沒有人需要」的問題。
有過獨立打造產品經驗的人——不管是創業、side project、還是開源專案——有三個無法從大公司 PM 經驗中學到的特質：
全棧思維：創辦人被迫處理產品的所有面向。從用戶研究到技術選型到定價到客服，你什麼都得碰。這種全面的理解在 AI 產品開發中極度重要，因為 AI 產品的每一層（模型選擇、prompt 設計、UX 設計、信任架構、成本控制）都緊密耦合。
與不確定性共處的能力：創業最核心的體驗就是「不知道自己在做的東西對不對」。這跟 AI 產品開發的日常驚人地相似——你永遠不確定模型會在什麼地方出包，你永遠在用不完美的資訊做決策。
殺手直覺的密度：用 Aakash Gupta 的話來說，獨立產品經驗提供的 at-bats（打擊機會）密度遠高於大公司。在大公司你可能一年做兩個重大產品決策；自己做產品，你每週都在做生死決策。這種密度堆疊出來的判斷力，面試官一問就知道有沒有。
"Build in Public. Create a portfolio of AI PM work. Companies want to see you can actually do the work, not just talk about it." — Aakash Gupta
這不只是 Anthropic 的要求：整個產業正在趨同
如果你覺得「那是 Anthropic 特別激進」，看看其他公司在做什麼：
| 維度 | Anthropic | OpenAI | Google DeepMind | Meta AI |
|---|---|---|---|---|
| 核心定位 | AI 安全與企業信任 | 消費者 + 企業 AI | 前沿研究產品化 | 大規模 AI 整合 |
| 技術要求 | 至少 1 年工程經驗 | 10+ 年 PM 經驗（高階） | 研究與產品橋接 | 大規模 ML 產品經驗 |
| 特殊要求 | 用 Claude Code 做原型 | 高合規環境經驗 | 將前沿研究轉為產品 | Product Sense with AI 面試 |
| 薪資範圍 | $468K-$651K | $759K-$1.1M+ | $300K-$600K+ | $250K-$500K+ |
Meta 特別值得一提。他們在 2025 年新增了一個面試環節叫「Product Sense with AI」——要求候選人在面試中即時使用 AI 解決產品問題。重點不是你的 prompt 技巧有多花俏，而是你能不能在 AI 給出不完美資訊時，依然做出清晰的產品決策。
這跟 Anthropic 的要求本質上是同一件事：我們要的不是會使用 AI 工具的人，而是理解 AI 本質並能在不確定性中做決策的人。
市場供需的殘酷數字
根據 Product School 和多個求職平台的數據：
- AI PM 職位佔所有 PM 職位的 20%（2025 年），較 2023 年的不到 2% 大幅成長
- 全球約 14,000+ AI PM 開放職位
- AI PM 薪資較傳統 PM 高 20-40%
但真正的問題在供給端：35% 的新 PM 職位要求 AI 相關經驗，但只有約 10% 的 PM 候選人擁有真實的 AI 產品經驗。
這個缺口就是機會——但也是警訊。如果你現在還沒開始轉型，這個窗口不會永遠開著。
轉型路線圖：從傳統 PM 到 AI PM
說了這麼多，具體該怎麼做？根據我的研究，我整理出一個分階段的轉型路線：
第一階段：AI 素養（2-3 個月）
這個階段的目標不是成為技術專家，而是建立直覺。
- 每天使用 ChatGPT 和 Claude 處理真實工作任務（不是隨便問問題，是真的用它來寫報告、分析數據、設計方案）
- 完成 Andrew Ng 的 AI for Everyone 課程
- 開始理解什麼任務 AI 做得好、什麼做得差，培養對模型能力邊界的感覺
常見陷阱：很多 PM 在這個階段停留太久，把「使用 AI 工具」當成「具備 AI PM 能力」。使用 ChatGPT 寫 PRD 不等於你理解 AI 產品。你得往下一層走。
第二階段：技術動手（3-6 個月）
這是最關鍵的轉折點。
- 學會 Prompt Engineering——不是知道「思維鏈」這個名詞，而是能設計一套系統性的 prompt 策略
- 掌握至少一個 AI 原型工具（v0、Lovable、Cursor 或 Claude Code）
- 理解 RAG 和 Fine-tuning 的差異以及各自的適用場景
- 嘗試為一個簡單的 AI 功能設計 Evals
常見陷阱：這個階段最大的風險是「只學不做」。你不需要成為工程師，但你必須親手建造過至少一個可運行的 AI 原型。看十篇教學不如自己做一次。
第三階段：建造產品（6-12 個月）
這是讓你從「有 AI 知識的 PM」變成「有 AI 產品經驗的 PM」的階段。
- 建造一個有真實使用者的 AI 產品（即使只有 10 個用戶）
- Build in Public——在社群分享你的建造過程、踩過的坑、學到的教訓
- 為你的產品設計完整的 Eval 框架，用數據說明品質
- 記錄你的 Build/Kill 決策過程和理由
常見陷阱：不要追求完美。一個有 50 個用戶、你能清楚說明每個決策理由的粗糙產品，比一個「計劃中的完美產品」有價值一百倍。
第四階段：定位求職
- 瞄準 AI 應用層公司，而非純研究機構
- 準備一個 AI PM portfolio：你的產品、你的 Evals、你的決策框架
- 展示你能用原型工具在面試中即時建造東西
graph TD
A[第一階段
AI 素養
2-3 個月] --> B[第二階段
技術動手
3-6 個月]
B --> C[第三階段
建造產品
6-12 個月]
C --> D[第四階段
定位求職]
A -.- A1[每日使用 AI 工具<br/>建立能力邊界直覺]
B -.- B1[學 Prompt Engineering<br/>掌握原型工具<br/>設計 Evals]
C -.- C1[建造真實產品<br/>Build in Public<br/>累積決策經驗]
D -.- D1[AI PM Portfolio<br/>展示實戰成果]</div>
時間不站在你這邊
根據 Gartner 的預測，到 2027 年 AI agents 將主導下一波數位轉型浪潮。TechCanvass 的產業分析指出，超過半數的產品管理角色將直接涉及 AI 產品。不具備 AI 能力的 PM 將被邊緣化——不是失業，但會被推到越來越不重要的位置。
| 時間 | 正在發生的事 |
|---|---|
| 2025（已發生） | AI PM 佔所有 PM 職位 20%；Meta 新增 AI 面試環節 |
| 2026（現在） | 「Full-Stack Builder」成為理想 PM 模型；Evals 取代 OKR |
| 2027（預測） | 50%+ PM 角色直接負責 AI 產品；PM/工程師邊界進一步模糊 |
| 2028+ | Agent 管理成為 PM 核心職責；不具備 AI 能力的 PM 被邊緣化 |
回到 Anthropic 那三個要求：
知道該開發什麼 / 不該開發什麼 —— 因為建造成本趨近於零，決策品質就是最大槓桿。
親自動手建立原型 —— 因為 AI 產品只有做出來才能驗證，任何紙上規格都是猜測。
打造過真實產品 —— 因為只有經歷過真實挫折的人，才有能力在不確定性中做出正確判斷。
這三項要求正在從 Anthropic 的特色需求，演變為整個 AI 產業的標準期待。
問題不是「要不要轉型」，而是「你打算什麼時候開始」。
延伸閱讀
- Anthropic Is Hiring PMs at $460K/Year — Here's What They Want — Aakash Gupta
- The Way Anthropic Builds Products is Wild — Aakash Gupta
- Anthropic's Prototype-First Approach — Sachin Rekhi
- Andrew Ng: Product Management Is the Bottleneck — Business Insider
- The 2026 AI Product Strategy Guide — Mind the Product
- Moving To Higher Ground: PM In The AI Era — Reforge
- A Guide to AI Prototyping for PMs — Lenny's Newsletter
- AI PM Tech Stack Changed Completely — Aakash Gupta
- AI PMF Framework — Bessemer Venture Partners
- Unpacking Meta's New PM Interview: Product Sense with AI — Maven
本文最初發布於 HackMD @BASHCAT。
留言
張貼留言