Anthropic 的 Head of Product 聊 Claude Code：產品週期壓到一天，PM 該長什麼樣子？
TL;DR
- Anthropic 的產品週期從六個月壓到一週甚至一天，PM 的工作從「對齊 roadmap」改成「拆掉所有擋住 ship 的障礙」
- 幾乎所有新功能都以 Research Preview 形式出貨，降低承諾門檻，讓工程師一週內就能把想法推到用戶手上
- 工程師、PM、設計師的角色在融合，Claude Code 團隊偏好招「有 product taste 的工程師」，而不是純 PM
- 最稀缺的技能是 product taste 和「正確劑量的 AGI-pilled」，重點在於壓出當前模型的最大能力
- Mission 大於產品：Cat 說如果 Claude Code 失敗但 Anthropic 成功，她會非常開心。這句話解釋了 OpenClaude 事件為什麼會那樣處理
- 新模型出來時，團隊做的多半是「刪功能」而不是「加功能」，把過去幫模型補短板的 workaround 一個個拿掉
這集在二〇二六年四月播出的 Lenny's Podcast 是 Lenny Rachitsky 主持的產品管理節目，從 2022 年開播到現在累積三百多集，基本上是產品圈的聖經級 podcast，專訪世界級產品主管談實戰。這集來賓 Cat Wu 是 Anthropic 的 Head of Product，同時負責 Claude Code 和 Cowork 兩條產品線。她 Princeton CS 出身，早年在 Scale AI 和 Dagster 當產品工程師，之後短暫做過創投，2024 年 8 月加入 Anthropic，先在 Research PM 團隊，現在帶著被很多人形容「這一代最改變工作方式的產品」。Claude Code 是 Anthropic 的終端機 coding agent，Cowork 則是它的 non-code 版本，處理像做投影片、整理信箱、客戶 brief 這些不產出程式碼的工作。Anthropic 過去一段時間的 ARR 成長速度已經到「一個月進帳以十億美元計」的規模，這集內容基本上就是他們怎麼在這個節奏下還能保持這麼快的 shipping。
六個月 → 一個月 → 一週 → 一天
Cat 在這集講的第一個震撼彈，是 Anthropic 把產品功能的週期從六個月一路壓到一天。這不是誇飾。
過去 PM 大部分時間花在跨部門對齊、多季 roadmap 協調、確認 dependency 都就位。寫 code 很貴，所以把事情計畫好再做是理性的。AI 出現之後這套邏輯整個翻盤。寫 code 變得超便宜，模型能力每幾個月就跳一個台階，原本六個月的功能現在一個禮拜就能做出來。PM 的工作重點也跟著變，焦點從「對齊 roadmap」移到「拆掉每一個擋住 shipping 的障礙」。
Cat 講了一句我覺得很精準的話：做 AI native 產品的 PM，腦中該裝的是另一個問題：怎麼把從想法到用戶手上的時間縮到最短。多季 roadmap 對齊那一套已經不太重要了。
之前寫過的Anthropic 狂飆、OpenAI 失焦裡面 All-In 四人幫有聊過 Anthropic 這波產品連發的聲勢，Cat 的訪談算是把內部邏輯攤開來給你看。
Research Preview 是他們降低承諾門檻的方法
你可能會問：產品週期壓到一天，品質怎麼辦？
Cat 的答案是 Research Preview。Anthropic 幾乎所有新功能都會以 Research Preview 的形式推出，上面貼清楚標籤告訴用戶「這是早期產品、我們在測試、可能不會長期支援」。這件事的妙處在於它降低了團隊的承諾門檻。不用擔心「上線就是公司門面」，就不會花兩個月做 polish，可以一週出貨。
他們還有一套跨部門的 evergreen launch room。工程師內部 dogfood 過的功能一放進去，負責 docs 的 Sarah、PMM 的 Alex、DevRel 的團隊第二天就能把對外公告做出來。這個流程把跨部門協調的摩擦降到最低，PM 的工作就是把這套流程建起來，然後讓它自己跑。
代價是什麼？產品一致性。Cat 很坦白講，Anthropic 現在常常有功能互相重疊，因為他們同時在測兩個內部都很愛的 form factor，想讓外部用戶告訴他們哪個比較好。新用戶進來會搞不清楚「哪條路才是最佳解」，這是刻意的 trade-off。他們用 onboarding 產品（像 /power-up 指令）來彌補，但一致性本身是被犧牲的。
Claude Code 如果失敗但 Anthropic 成功，我會非常開心
這集最讓我印象深刻的一句話。
Cat 把 Mission 跟 Focus 拆開來講。Focus 是 Anthropic 選擇不做什麼（例如不做 social feed、不做內容分發），Mission 則是團隊願意為了 Anthropic 整體目標犧牲自己團隊的 KR。Claude Code 如果失敗但 Anthropic 成功，她會很開心。這句話拿出來放在 Twitter 上會被吐槽是在演戲，但放在 Anthropic 的脈絡下其實滿有道理。
這個文化解釋了很多事情。為什麼 OpenClaude 事件（第三方產品不能再用 Claude 訂閱跑）會那樣處理？因為他們判斷「讓 Anthropic 有更多訂閱用戶」比「第三方生態」更重要，團隊就會很乾脆地做這個決定。為什麼他們不去搞一個 ChatGPT 風格的 social feed？因為那不符合 Mission，直接砍掉不用討論。
很多大公司內部每個 product line 都在搶預算搶資源，Anthropic 這種 Mission 凌駕個別產品線的文化，在公司規模達到這個級別的情況下我很少看到。這可能才是他們 shipping 這麼快的底層原因。Mythos（他們內部的下一代模型）帶來的加速其實沒想像中多，真正的原因是文化本身讓決策成本低到不可思議。
Product Taste 變成最稀缺的技能
Cat 講到一個產業正在發生的融合：工程師、PM、設計師的邊界在消失。工程師在做 PM 的工作（收 Twitter 回饋、定義 feature、一路 ship 出去），PM 在寫 code，設計師也在寫前端。
Claude Code 團隊的策略很明確：他們不特別招很多 PM，他們招「有 product taste 的工程師」。這個選擇背後的邏輯是：code 變便宜之後，「決定寫什麼」的價值就變高了。你拿到一萬個 GitHub issue，每個都想要不同的功能，你需要的是能判斷「哪幾個 issue 值得做、該怎麼做才優雅」的品味，單純會寫 code 這件事已經是 commodity。
這點跟之前Steven Sinofsky 聊 Apple 文化那篇裡 Bill Gates 那句「I wish we had your taste」是同一條線的思考。產業從追求功能堆疊的時代，走到追求品味的時代。
有人會擔心背景差會吃虧。Cat 的答案是 taste 可以從任何背景培養出來，只是工程背景在「接下來幾個月」特別有用，因為你對實作難度有感，比較會做優先級判斷。她也很坦白，技能組合每幾個月就會因為模型能力躍進而改變，沒有人能預測得更遠，重點是保持 first principles thinking 的能力。
「正確劑量的 AGI-pilled」
這是整集我覺得最有價值的觀念。
Cat 說，為「超強 AGI 模型」造產品其實很簡單，你只要給一個 text box 讓使用者講他要什麼就行了，模型會自己補齊所有工具、問釐清問題、決定該做什麼。真正難的是「為當前模型做產品」。當前模型有哪些做得好、哪些做不好？你要怎麼設計 UX 讓使用者自然走到 golden path 上？怎麼用產品設計補齊模型的弱點？
怎麼練這個能力？她給了三個具體做法：
- 跟模型對話，問它為什麼做這個決定。Claude 有時候會做奇怪的事情（例如改完前端只跑測試不開 UI 驗證），直接問它為什麼，它會告訴你是系統提示詞哪邊誤導了它，或是它把驗證 delegate 給 sub-agent 而 sub-agent 沒做到。這些答案會直接指向你要修的地方。
- 找一小群最會給 feedback 的人做 vibe check。不是所有人的回饋都一樣 qualified，找五個真的會描述模型表現的人，比一百個隨意回饋有用得多。
- 寫 evals。不用寫一百個，十個好的 eval 就夠用。這是 PM 和工程師都低估的工具。
之前寫過的前 OpenAI 工程師的 Coding Agent 使用心法也提過類似的事，context engineering 本質上就是在搞懂當前模型的極限，然後設計 workflow 把它推到最大。
新模型來的時候，他們做的是「刪功能」
這是我第二意外的觀察。
很多人以為新模型出來團隊會馬上加一堆新功能，其實不是。Cat 講了個 to-do list 的故事：Claude Code 早期版本碰到大型 refactor，會說要改二十個 call site，結果改完五個就停了。團隊加了 to-do list tool，強迫模型把所有要改的地方列出來再一個個處理。Opus 4 之後模型自己就會這樣做了，to-do list 從「必要的拐杖」變成「可有可無的 UI 元素」。
每次發新模型，他們做的第一件事是重讀整份系統提示詞，問每一段：「這個提醒還需要嗎？」不需要就刪掉。新模型真正 unlock 的是以前做不到的「全新功能」，例如他們一直想做但直到 Opus 4.5 和 Sonnet 4.6 才做得起來的 multi-agent code review。
這給一般開發者的啟示是：造產品的時候就要造「目前還不太 work」的功能。做到九成的 prototype 丟著，下一個模型出來把它 swap 進去看差距縮小了多少，比等到「模型完全成熟再開始做」快很多。
Claude Code 跟 Cowork 怎麼分？
順便整理一下 Cat 自己講的分工：
| 工具 | 最適合的場景 |
|---|---|
| Claude Code CLI | 單次 coding 任務，想用到最新功能 |
| Desktop | 前端開發、有 preview pane 可即時預覽，對非技術人員友善 |
| Web / Mobile | 在外面散步時丟任務、不想抓著筆電到處跑 |
| Cowork | 輸出不是 code 的工作，像投影片、inbox zero、客戶 brief |
她自己用 Cowork 的方式值得參考：先把 Slack、Google Calendar、Gmail、Google Drive 全部接上，讓它有 context 可抓。最近一個例子是她要準備 Code with Claude 大會的演講，把 PMM 的草稿、過去的 demo、Slack 裡的 launch 訊息全丟給 Cowork，它跑了一小時吐出一份二十頁的 deck，視覺上看起來像 Anthropic 設計師做的（因為她把 design system 餵給它了）。
這種用法的重點在於把 AI 變成一個「會拿公司內部 context 的腦力放大器」。光是把各種資料源接上這一步，就會拉開你跟其他使用者的差距。
給所有人的一句話建議
整集最後 Cat 給聽眾的建議，我覺得很實在：
找你每天在手動重複做的事情，把它自動化到百分之百。
她特別強調九成五不算自動化。如果一個流程只有九成五可靠，你還是得每次檢查，省不了多少時間。最後那一小段很痛苦、很耗時，但那才是真正的門檻。做到百分之百你才會真正信任它、依賴它、把腦力空出來做更有創造力的事。
另一個陷阱她也點得很準：很多人（包括 Twitter 上曬自己 setup 的那些人）把時間花在「一直在客製化工作流」這件事本身，skill 加一堆、MCP 接一堆，但真正的工作沒往前推。設定環境的快樂是真的，但那不是產出。她的原話是「簡單的 setup 反而更有用」。
這點我自己很有共鳴。我 Gmail 的自動分類也卡在九成五，偶爾會把重要信丟進 spam 資料夾，每次發生都很痛，但懶得花時間調到百分之百。聽完這集我決定要花一個週末把它逼到百分之百，看能不能真正把這個 workflow 交出去。
整集聽下來最核心的一句話，其實是 Cat 在最後講的：AI 給每個人更多 leverage，但 leverage 只有在你真的用它做事情的時候才會發生。做 prototype 放著不用，跟沒做一樣。每天要做的事情裡，挑一個你真的討厭做、又會持續做的，把它丟給 Claude，然後花時間把它調到可以安心不看。這個動作重複十次，你這一年就不一樣了。
這類從 podcast 裡挖出來的產業觀察，我每天都會整理一篇放在 wilsonhuang.xyz，有興趣的話訂閱一下就不會錯過。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件