# 策展 · X (Twitter) 🔥🔥🔥🔥 > 作者：宝玉 (@dotey) · 平台：X (Twitter) · 日期：2026-04-24 > 原始來源：https://x.com/dotey/status/2047537778959778209 ## 中文摘要 # Cat Wu 面試了幾百個 PM 候選人，幾乎沒人答對一個問題：AI 產品經理到底應該幹什麼？ Cat Wu 是 Anthropic Claude Code 和 Cowork 的產品負責人，和 Boris Cherny 搭檔，帶著團隊把產品功能的交付週期從半年壓到了一天。在 Lenny's Podcast 最新一期中，Cat 聊了 Anthropic 內部的速度文化、PM 角色的劇變、原始程式碼洩露的善後，以及那個讓開源社群炸鍋的 OpenClaw 封堵決定。 原始影片：https://www.youtube.com/watch?v=PplmzlgE0kg ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519751-iaHGpGHcrXQAAkAZXjpg.jpg) ## 要點速覽 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519704-diaHGpGK3SXAAADxIjpg.jpg) - 大多數 PM 候選人仍然在用 6-12 個月路線圖的思維找工作，Anthropic 的節奏是一週甚至一天發布一個功能 - Claude Code 團隊幾乎所有 PM 都有工程背景或直接寫程式碼，設計師也曾是前端工程師 - Anthropic 用 research preview 機制降低發布承諾，讓工程師可以 End to End (端到端) 完成從想法到發布的全流程 - Cat 花 30% 的時間故意把 Cowork 推到極限，和模型對話搞清楚它為什麼犯錯 - Claude Code 原始程式碼洩露經過兩層人工審查仍然漏過，Cat 定性為流程失敗 - 封堵 OpenClaw 使用訂閱配額的決定，Cat 從容量管理角度解釋，但迴避了「先複製功能再封堵」的爭議 - Anthropic 成功的核心：統一使命讓團隊願意犧牲自己的 KR 去服務公司整體目標 ## 1. 與 Boris Cherny 搭檔：80% 心靈感應，20% 各幹各的 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519724-diaHGpGOHMXQAAhY4jpg.jpg) Lenny 開場就問 Cat 和 Boris 是怎麼分工的。Boris 是 Claude Code 的創造者和技術負責人，在 Podcast 界已經是明星級人物，Lenny 說他的那期節目是 Podcast 史上最受歡迎的一集。 Cat 說自己和 Boris 的關係用「80% mind-meld」來形容。Boris 擅長的是方向感，他會說三個月後、六個月後產品應該長什麼樣，那個最 AGI pilled 的版本是什麼。Cat 的角色則是把這個願景翻譯成執行路徑：從現在到那個願景之間，每一步怎麼走？同時她花更多時間在跨職能協調上，確保市場、銷售、財務、容量等團隊都認同計畫，不會在功能準備好之後才發現有障礙。 剩下的 20%，是各自特別在意的事情。Cat 會主導自己更關心的事，Boris 也一樣，誰更在意誰就推。這種模糊分工在外面看起來不太正統，但 Cat 覺得正是因為模糊，才能快。 > 編者註： Boris Cherny 是 Anthropic Claude Code 技術負責人，也是 O'Reilly 出版的《Programming TypeScript》一書的作者。他在 2024 年 9 月加入 Anthropic 後構建了 Claude Code 的第一個終端原型。AGI pilled 源自網際網路俚語 red pilled（出自電影《駭客任務》），指對 AGI 即將到來持極其樂觀甚至狂熱的態度。在 AI 行業內部，這個詞既有正面含義（敢於為更強的模型設計產品），也有警告意味（可能脫離當下模型的實際能力）。 ## 2. 面試幾百個 PM 後的發現：大多數人還活在舊世界 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519707-iaHGpGRRgX0AAn0c9jpg.jpg) Lenny 提到一個有趣的現象：想去 Anthropic 當 PM 的人多到他快收到三十億美元 ARR 的「介紹費」了。Cat 面試了幾百人，她覺得大多數人對 AI PM 角色的理解方向不對。 問題出在哪？Cat 認為 AI 出現之前，技術變化很慢，你可以做 6-12 個月的規劃。程式碼寫起來很貴，所以 PM 的核心工作是協調各團隊的路線圖，確保大家的功能互相解鎖。這套打法在舊世界是對的。 但現在，模型能力在快速提升，AI 大幅加速了工程效率，很多產品功能的交付時間從 6 個月變成了 1 個月，有時候 1 週，甚至 1 天。在這個節奏下，PM 不應該把精力花在多季度路線圖的跨團隊對齊上，而應該想：怎麼找到最快的方式把東西推出去？怎麼讓工程師有個想法、週末就能送到使用者手裡？ > 最好的 AI 產品 PM，能縮短從「有這個想法」到「產品到了使用者手裡」的時間，並且能定義出產品必須在哪些任務上開箱即用。 （“The PMs who do the best on AI native products are the ones who can figure out: How can I shorten the time from having this idea to actually getting the product in the hands of users.”） ## 3. 怎麼做到一天出一個功能 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519749-diaHGpGULXwAAZI3yjpg.jpg) Lenny 追問具體怎麼做到這麼快。Cat 講了三件事。 第一件是設定清晰目標。 因為大型語言模型能力太通用，使用者是誰、解決什麼問題、核心場景是什麼，全都模糊。好的 PM 能把這些定死：我們的核心使用者是企業裡的專業開發者，這個功能要解決權限提示太多導致的疲勞感，目標是讓企業開發者安全地做到零權限提示。這個目標一旦清楚，就排除掉了大量不相關的方案。 第二件是 research preview 機制。 Claude Code 幾乎所有功能都先以研究預覽的形式發布。明確告訴使用者：這是早期產品、只是一個想法、我們在收集回饋、這個功能可能不會永遠支援。這降低了發布門檻，一兩週就能把東西推出去。 第三件是搭建跨職能的快速反應流水線。 Cat 的團隊有一個叫「evergreen launch room」的機制。工程師覺得功能準備好了、內部也試用過了，就把它發到這個頻道裡。負責文件的 Sarah、負責產品市場行銷的 Alex、開發者關係的同事會直接跳進來，第二天就能完成對外宣傳。這套流程跑順了之後，任何工程師想發布功能都沒有摩擦。 Cat 說得很明確：搭建這套發布流水線，就是 PM 該幹的事。 > 編者註： Anthropic 的發布節奏有多快？有人做過一個日曆，發現 Anthropic 在 2026 年前幾個月幾乎每天都有一個重要功能或產品發布。 ## 4. PRD 沒死，但活法不同了 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519799-iaHGpGYM3XEAAYWXCjpg.jpg) Lenny 問 PRD 還寫不寫。Cat 說他們做了兩件替代的事。 第一是每週做嚴格的 metrics readout，整個團隊一起看資料，確保每個人都深度理解業務的各個面、關鍵目標、趨勢和驅動因素。 第二是維護一份 team principles，包括誰是核心使用者、為什麼是他們、願意做什麼取捨。這份原則的目的是讓團隊每個人都能自己做決策，不需要等 PM 或其他利益相關方來拍板。 PRD 並沒有完全消失。對於特別模糊的功能，Cat 還是會寫一頁紙，列出目標、理想場景、當前失敗模式。需要大量基礎設施投入的長期專案也仍然有 PRD。但大部分功能不需要。 ## 5. 不是 Mythos 讓他們變快的 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519748-iaHGpGbVsXwAA6UPZjpg.jpg) Lenny 注意到 Anthropic 還沒正式發布的 Mythos 模型引發了外界的關注，問他們內部是不是在用這個模型來加速開發。 Cat 的回答很直接：他們已經快了好幾個季度了，Mythos 不是核心原因。 Mythos 很強大，他們確實在內部使用模型，這多少加速了開發，但不足以解釋速度提升的主要部分。更大的原因是流程和團隊的期望設定：每個人都覺得自己有權力也有責任把想法在一週內變成現實。 > 編者註： Mythos（內部代號 Capybara）是 Anthropic 的最新前沿模型，2026 年 4 月 7 日以研究預覽形式限量發布，主要用於 Project Glasswing 網路安全專案。最初在 3 月 26 日因 CMS 配置錯誤提前曝光，Fortune 等媒體拿到的草稿描述它是一款比 Opus 更大、更強的模型。Anthropic 稱該模型在程式碼、推理和網路安全方面能力大幅超越此前所有模型，已發現數千個零日漏洞。 ## 6. 原始程式碼洩露：定性為流程失敗 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519717-iaHGpGegzWUAAXLbajpg.jpg) 2026 年 3 月底，Claude Code 的完整原始程式碼透過 npm 包洩露。Lenny 問 Cat 發生了什麼。 Cat 說他們第一時間就去查了。原因是人為錯誤，有人在用 Claude 寫一個關於包發布流程更新的 PR，這個 PR 經過了兩層人工審查，但還是漏了。他們已經加固了流程，確保不會再發生。 Lenny 追問了一個尖銳的問題：這個人還在 Anthropic 嗎？Cat 的回答很乾脆：還在。這是流程失敗，最重要的是學習教訓、加強防護。 > 編者註： 洩露的根本原因是 Claude Code 使用 Bun 執行階段建構，Bun 預設生成 source map 檔案，而 .npmignore 中缺少 *.map 條目，導致一個 59.8 MB 的 source map 檔案被發布到公共 npm 註冊表，暴露了約 2,000 個檔案、512,000 行 TypeScript 原始程式碼、44 個未公開的功能標誌，以及一個名為 KAIROS 的自主後台 Agent（從洩露的程式碼中發現的未發布功能，能讓 Claude 在後台持續執行，甚至在使用者空閒時做「記憶整理」）。這已經是 13 個月內的第二次程式碼洩露，而且發生在 Mythos 模型資訊因 CMS 錯配洩露後僅 5 天。對於一家以「安全優先」為品牌定位的公司來說，一週內兩次洩露引發了外界對其營運安全的質疑。 ## 7. 封堵 OpenClaw：容量管理還是生態圍牆？ ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519714-iaHGpGhq1WkAADW85jpg.jpg) Lenny 問到了另一個爭議話題：Anthropic 禁止訂閱使用者透過第三方工具（特別是 OpenClaw）使用 Claude。開源社群反應很大。 Cat 的解釋是：Claude 的需求量很大，他們一直在努力擴展基礎設施，同時也在優化 harness 的 token 效率。訂閱計畫不是為第三方產品的使用模式設計的，這類產品給系統帶來了不成比例的壓力。他們花了很多時間想最平滑的過渡方案，最終決定給每個使用者隨訂閱附贈一些額度，但核心決策是優先保障自有產品和 API。 > 我們確實需要做出一個艱難的決策，優先保障我們的第一方產品和 API。 （“We did have to make the hard decision that we needed to prioritize our first-party products and our API.”） > 編者註： Cat 的回答只覆蓋了這個爭議的一個面。完整的時間線是這樣的：OpenClaw（原名 Clawdbot，2026 年 1 月因 Anthropic 擔心商標混淆改名）是奧地利開發者 Peter Steinberger 建立的開源 AI Agent 框架，在 2026 年初迅速走紅，GitHub 累計 24.7 萬顆星，是開源史上增長最快的專案之一。2 月 14 日，Steinberger 宣布加入 OpenAI，OpenClaw 移交開源基金會。2 月 20 日，Anthropic 更新條款明確禁止訂閱 OAuth token 用於第三方工具。3 月底 Anthropic 自己的 Cowork 上線了 Claude Dispatch 等功能，和 OpenClaw 最受歡迎的能力高度重合。4 月 4 日正式封堵生效，給使用者的通知不到 24 小時。Steinberger 批評 Anthropic「先複製熱門功能到自己的封閉 harness 裡，再把開源鎖在門外」。Boris Cherny 則在 X 上表示團隊「是開源的大粉絲」，他本人還給 OpenClaw 提交過改善提示快取效率的 PR。這些舉動和實際政策之間的溫度差，使用者感受得到。一個 $200/月的 Max 訂閱使用者如果透過 OpenClaw 跑全天自主 Agent，可能消耗相當於 $1,000-$5,000 的 API 成本，從經濟角度看 Anthropic 的決定有合理性。但這個決定的時間節點和 Cowork 功能擴展的巧合，仍然是社群爭議的核心。 ## 8. PM 團隊的全貌 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519777-diaHGpGk3W8AEA50Fjpg.jpg) Cat 說 Anthropic 大約有 30-40 名 PM，分布在幾個團隊： - 研究 PM 團隊：負責收集客戶對模型的回饋並推動模型發布 - Claude 開發者平台團隊：維護 API 和 Managed Agents 等服務 - Claude Code 團隊：做核心產品 - 企業團隊：負責安全控制、成本管控、RBAC（基於角色的存取控制）等讓大企業安心使用的功能 - 增長團隊：負責整個產品套件的增長 ## 9. 角色融合：工程師、PM、設計師的界限在消失 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519725-ediaHGpGnKXIAA892jpg.jpg) Lenny 問了那個所有 PM 都在焦慮的問題：PM 未來還需要嗎？ Cat 的觀察是所有角色都在融合。PM 在寫程式碼，工程師在做產品決策，設計師在做 PM 的活也在提交程式碼。她說有兩條路可以走：要麼大量招有產品品味的工程師，要麼維持工程師數量不變、多招 PM 來引導。Anthropic 選的是前者——大量招有產品品味的工程師。 她說團隊裡很多工程師完全能獨立完成從「在 Twitter 上看到使用者回饋」到「週末發布功能」的全流程，幾乎不需要 PM 參與。這是最高效的模式。 > 當程式碼變得越來越便宜，真正變得更有價值的是決定寫什麼。 （“As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.”） Cat 自己就是工程師出身。她之前在 Scale AI 做產品工程師，在 Dagster Labs 做工程經理，然後去了 Index Ventures 做風投。團隊裡幾乎所有 PM 要麼曾經是工程師，或者在 Claude Code 上直接寫程式碼。設計師也都做過前端工程師。 那工程背景為什麼在當下特別有用？Cat 解釋說，如果你有工程背景，你能判斷一件事應該有多難。如果很簡單，別討論了，花一小時做掉；如果很難，你提前知道成本，就能更準確地排優先級。 不過她還是認為，不管什麼背景，最核心的能力是 product taste（產品品味）。 > Product taste 仍然是一種非常稀缺的技能，任何能強有力地展示這種能力的人，我們基本都會錄用。 （“Product taste is still a very rare skill to have, and we'll pretty much hire anyone who we feel has demonstrated this strongly.”） ## 10. 「恰好正確程度的 AGI 信仰」 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519753-iaHGpGrHhWoAE8dTwjpg.jpg) 談到 PM 需要什麼新技能，Cat 給出了全場最有洞察力的回答。 最難的技能是定義產品一個月後應該長什麼樣。這裡面的模糊性很大：模型的能力在那個時間範圍內會變成什麼樣？使用者行為又會如何改變？ > 做到恰好正確程度的 AGI 信仰非常難。 （“It is very hard to be the right amount of AGI pilled.”） Cat 說，每個人都能看到那個終極未來：**模型極其聰明，什麼都能做，你只需要一個輸入框告訴它你想要什麼，它自己就能接入任何工具完成任務。**這就是 AGI 的產品形態。 但問題是，為那個終極版本做產品太容易了。難的是搞清楚當前模型的能力邊界在哪，怎麼在這個邊界內榨出最大價值。 太 AGI pilled 會讓你忽略眼前使用者的痛點，太保守又會在下一次模型升級時措手不及。 最好的 PM 能看到一種訊號：使用者如何突破現有產品的極限。他們能從這些訊號裡判斷方向，穩步推進，同時在模型能力超出或低於預期時靈活調整路線。 Cat 自己的做法是把 30% 的時間花在故意把 Cowork 推到極限，和模型對話，搞清楚它為什麼在某些任務上犯錯。 ## 11. 模型暫時還不懂的東西 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519770-iaHGpGuYmWwAARi8Zjpg.jpg) Lenny 問：在模型變得超級聰明之前，人腦在哪些地方還有用？ Cat 的回答指向常識和情商。任何一次產品發布都有一千個細碎環節，模型還不能很好地判斷誰是關鍵的利益相關方、他們之間的關係、他們的偏好、應該用什麼溝通場合讓他們保持在狀態裡。這種隱性的人際判斷仍然是人的領地。她相信模型會越來越擅長這些，但目前缺口還在。 ## 12. P0 到 P0000：混亂中怎麼保持理智 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519759-iaHGpGxowW4AE6KIvjpg.jpg) Lenny 問如何在這種節奏下保持理智。Cat 笑著說他們的團隊都是享受混亂的人。面對每一個挑戰都帶著笑容，因為如果你對任何事情太緊張，就會燃盡。 她給了一個很有畫面感的描述：週日晚上出了一個 P0（最高優先級事故），週一又來一個 P0，週一下午來了個 P0000，「你會想，天啊，我居然還為週日那個 P0 擔心過。」 她的應對方式很實際：承認你能做的事有限，睡好覺才能第二天做好決策，暴力排優先級，允許產品不夠完美。有些發布確實不夠打磨，但只要不影響核心場景，就接受它，等回饋，下個版本修。 ## 13. 速度的代價：功能重疊，使用者困惑 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519750-diaHGpG0vXMAEKi6Qjpg.jpg) Lenny 問為了速度犧牲了什麼。Cat 說最大的代價是產品一致性。 傳統做法是仔細規劃產品套件裡每個產品的關係、每個產品的場景、它們怎麼整合。現在 Anthropic 有時候會同時推出功能重疊的東西，因為內部有兩種方案都不錯，他們想讓外部使用者來告訴他們哪個更好。 代價是新使用者可能不知道完成某件事的最佳路徑是什麼。她承認需要做更多教育工作來幫使用者理解核心功能和最佳實踐。 ## 14. Anthropic 為什麼能贏：使命和聚焦 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519711-ediaHGpG31zWIAApgjpg.jpg) Cat 說了兩個因素。 第一是統一使命。 Anthropic 招的是最在意「把安全 AGI 帶給全人類」的人，這個使命在產品決策中被頻繁引用。因為使命高於任何單個產品線，跨組織決策可以非常快，執行可以高度統一。 Cat 特別強調了使命的具體含義：它意味著團隊願意做出犧牲自身目標和 KR 的決策，來服務 Anthropic 整體的目標和 KR，而且人們很樂意做這種取捨。 > 使命意味著團隊願意做出傷害自己目標和 KR 的犧牲，來服務 Anthropic 的整體目標和 KR。 （“Mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropic's goals and Anthropic's KRs.”） ## 15. Claude Code、Desktop、Cowork：什麼時候用哪個 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519773-iaHGpG7BdWUAAVNE7jpg.jpg) 這部分 Cat 給了一個清晰的分類。 - CLI（命令列版）：最強大的，功能通常最先在這裡上線。適合隨手啟動一個程式開發任務，需要最新最全功能的時候用。 - Desktop 版：適合做前端開發。Cat 經常打開預覽窗格，一邊和 Claude 聊天一邊即時看自己在建構的 Web 應用。 - Web 和行動裝置端：適合不在電腦前的時候。走在路上有個想法，掏出手機就能啟動任務。 - Cowork：處理非程式碼輸出——回完 Slack 訊息、做一個客戶會議的 slide deck、寫一份功能目標文件。 Cat 特別提到，要讓 Cowork 發揮最大作用，第一步是連接所有相關資料源：Google Calendar、Slack、Gmail、Google Drive。只有 Cowork 能存取到足夠的上下文，它才能給出高品質的輸出。 ## 16. 自定義應用：每個人的個人 SaaS ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519720-diaHGpGlBWAAEuio4jpg.jpg) Cat 講了一個例子。Claude Code 銷售團隊裡有個人，發現自己反覆做同樣類型的演示文稿。他用 Claude Code 做了一個 web 應用，內建了效果好的 deck 範本，可以從 Salesforce 和 Gong 拉取客戶資料，自動生成針對特定客戶的定製 deck，比如會標註這個客戶是用 Bedrock 還是 Claude Code for Enterprise，對應不同的功能集。 ## 17. Token 花費在漲，但仍低於薪資 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519668-diaHGpHCA8XoAA9lrjpg.jpg) Lenny 提到一個熱門話題：token 花費超過員工薪資。Cat 確認了趨勢但沒給具體數字。她說每次模型升級或產品大幅改進後，人們會把更多任務交給 AI，花更多時間在 Claude Code 和 Cowork 裡，單個工程師或知識工作者的 token 成本確實在增長。但目前仍然遠低於工程師薪資，只是佔比在持續上升。 ## 18. Claude 的性格是護城河 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519701-iaHGpHFigX0AAn2dhjpg.jpg) Cat 說 Claude 的一個核心差異化是性格。使用者經常提到 Claude 讓人覺得「輕鬆有趣但又極其能幹」。 她特別提到兩個性格特點： - 低 ego：你告訴 Claude 它做錯了，它會說「哎呀，謝謝你告訴我，我來修」，而不是辯解。 - 積極正面：當你面對一個看起來無從下手的任務，Claude 會說「沒關係，我覺得我們可以這樣開始，要我先幫你動手嗎？」 Cat 把這比作同事關係。回想你合作過的所有人，總有一些人讓你覺得他們的能量特別好。Claude 的目標就是做那種同事。 ## 19. 產品願景：從單任務到 Agent 矩陣 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519713-iaHGpHIuWXIAAOgcnjpg.jpg) Cat 用「building blocks」來描述長期路線。核心建構單元是單個任務的成功率：你給一個清晰的 prompt，它能不能持續產出可接受的輸出？ 隨著模型變強，單任務成功率上升，使用者自然開始做多任務並行。2025 年底 multi-coding 成了大趨勢，現在更加普遍。 Cat 的推演是：一個任務成功了，然後六個任務同時做。再往後，也許同時跑 50 個 Claude，或者上百個。這條路線從單兵作戰走向 Agent 矩陣。 ## 20. 閃電輪：攀岩、Waymo、和一萬塊巨石的退休生活 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519722-iaHGpHL07XYAAE2j0jpg.jpg) Cat 推薦了兩本書： - 《How Asia Works》：講的是什麼樣的政策和政府能造就持久成功的經濟體。 - 《The Technology Trap》：講的是過去幾次技術革命（工業革命、電腦革命）對工人的影響。 兩本都和她正在經歷的 AI 變革直接相關。 最喜歡的產品是 Waymo，每天坐兩次通勤。最喜歡的影視是 F1 紀錄片《Drive to Survive》和攀岩紀錄片《Free Solo》。Cat 說她喜歡看人極度專注於一個純粹的工程目標，這個偏好多少解釋了她為什麼會在 Anthropic。 如果有一天不用工作了？她說可能會搬到法國楓丹白露，那裡有一萬塊巨石，每天攀岩。還想把閱讀量從現在的每週 0.5 本提到一兩本。 ## Q&A 速覽 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519709-iaHGpHO9TXsAE19nEjpg.jpg) - Anthropic 的 PM 團隊有多大？ 大約 30-40 人，分研究、開發者平台、Claude Code、企業和增長五個團隊。 - PM 還需要寫 PRD 嗎？ 大部分功能不需要。每週 metrics readout 和 team principles 替代了常規 PRD。特別模糊或需要大量基礎設施投入的專案仍然有一頁紙的 PRD。 - Anthropic 用 Mythos 模型加速內部開發了嗎？ 有幫助但不是核心原因。速度更多來自流程和團隊文化。 - Claude Code 原始程式碼洩露後相關人員被開除了嗎？ 沒有。Cat 定性為流程失敗，已加固防護措施。 - 什麼時候用 Claude Code 什麼時候用 Cowork？ 需要程式碼輸出用 Claude Code，需要非程式碼輸出（文件、deck、郵件處理）用 Cowork。 ## 編輯手記：三個值得關注的矛盾 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777008519746-diaHGpHSMTWgAAzX3jpg.jpg) 這期訪談整體是一次相當友好的對話，Lenny 沒有在敏感話題上深追，Cat 也把控得很好。但幾個有意思的矛盾值得關注。 第一個是速度文化和安全承諾之間的縫隙。 Cat 用了大量篇幅講「一天出一個功能」「降低發布承諾」「讓工程師自主發布」的速度文化，但 Anthropic 同時是那家把「安全」寫在公司名片上的 AI 實驗室。一週內兩次資訊外洩（Mythos CMS 錯配 + Claude Code 原始碼 source map），Cat 的解釋都是「人為失誤，已加防護」。這兩次失誤的性質已經超出了單個 PR 的範圍。對速度文化本身是否加劇了這類風險，她沒有任何反思。 第二個是開放生態和圍牆花園之間的取捨。 Cat 對 OpenClaw 的解釋在經濟邏輯上成立，一個 $200/月的訂閱使用者透過 Agent 框架可能消耗價值數千美元的算力。但時間線上的巧合很難忽略：Anthropic 在自己的 Cowork 產品推出了類似功能之後，才封堵了第三方工具的訂閱通道。OpenClaw 創辦人 Peter Steinberger 的批評「先複製熱門功能到封閉的 harness 裡，再把開源鎖在門外」，Cat 在訪談中沒有正面回應。Boris Cherny 一邊說「我們是開源的大粉絲」一邊給 OpenClaw 提交過改善效能的 PR，這些舉動和實際政策之間的溫度差，也許比政策本身更值得玩味。 第三個矛盾藏在 Cat 關於 PM 角色的論述裡。 她用「角色融合」來描述 PM 的未來，但她自己給出的最高效模式是工程師 End to End (端到端) 完成從使用者回饋到發布的全流程，「幾乎不需要 PM 參與」。如果這是真的，那 PM 的價值到底在哪？Cat 的答案是 product taste，但這個概念在整場對話中始終停留在抽象層面，沒有給出任何可操作的定義或評估標準。當一個篩選標準無法被明確描述時，它很容易變成一個不可證偽的門檻。而她關於 AGI pilled 的論述暗含一個更深的悖論：如果模型足夠強，一個文字框就夠了，那她所做的產品工作本質上是過渡性的。一個產品負責人承認自己的工作有保質期，這種坦率不常見。 接下來值得觀察的訊號：Anthropic 承諾的安全防護措施是否真正起效，OpenClaw 封堵後開發者生態的走向，以及這套「永久 beta」的 research preview 模式能持續多久，使用者的忍耐度有沒有上限。 原始影片：https://www.youtube.com/watch?v=PplmzlgE0kg ## 標籤 產業趨勢, 教學資源, OpenClaw, Anthropic, Claude