Claude code 產品經理Cat Wu親述：我是如何用AI徹底重構PM工作流的

Claude Code 產品經理Cat Wu剛寫了一篇博客，詳細剖析了AI如何重塑她的工作流，強烈推薦所有PM閱讀，除了PM，我覺得AI時代人人都是產品經理，尤其是你想做出有影響力的產品時這篇文章更值得閱讀。

以下是詳細內容：

2024年10月，Claude Sonnet 3.5（新版）發布之后，我養成了一個習慣：每次有新模型出來，就讓Claude Code（當時還是內部工具）給Excalidraw加一個表格工具。每次模型都能走得更遠一些，但始終失敗。

直到2025年6月Opus 4發布，Claude開始偶爾成功了。于是我們把這個演示錄成視頻，放進了Claude 4的發布活動。

再往后，Opus 4.6已經可以穩定地一次性完成Excalidraw的功能需求，我們開始在數千名專業開發者面前實時演示。

模型進步的速度，持續擴展著可能的邊界。

傳統產品管理的基本假設已經失效

傳統產品管理的邏輯，建立在一個默認前提上：項目開始時的技術約束，到項目結束時基本不變。產品經理前期收集足夠信息，做出自信的判斷，然后按計劃推進，一個周期往往長達數月。

指數級提升的模型打破了這個前提。你設計時繞開的約束，可能在項目進行到一半時就消失了。地面在你腳下持續抬升，團隊必須圍繞這個現實重新組織工作方式。新的產品管理節奏是：快速實驗、持續交付、押注有效的方向。

我是怎么走到這里的

我職業生涯起步于Scale AI和Dagster的產品工程師，后來做過風險投資，期間仍然堅持用代碼自動化工作中繁瑣的部分——比如掃描X平臺上的新公司公告，或者檢測開源項目的增長勢頭。

2024年8月，我加入Anthropic，擔任Research PM團隊的產品經理，負責連接研究團隊與真實用戶，推動更好的模型落地。那年秋天Claude Code在內部開放后，我開始用它加速工作中手動操作的部分：構建Streamlit應用分析大規模用戶反饋，跑評估幫助公司尋找新的可信基準。工具門檻低到我可以輕松越界探索，比如搭建強化學習環境來更好地理解模型訓練。

這些項目耗費了我數百小時與Claude Code的交互，底層是Sonnet 3.5（新版），全程沒有親手寫過一行代碼。

我如何劃分工作流

我最終在三款產品之間找到了自然的分工：Claude.ai、Claude Code和Cowork。

Claude.ai是我和Claude對話的地方，不需要它執行任何操作。我在這里打磨策略文檔的思路，處理棘手的情況，快速獲取答案。

Claude Code是我構建原型、跑評估、寫腳本的地方，很多腳本本身也在調用Claude API。有代碼產出的任務，我放在這里。

Cowork負責其他所有事情：清理收件箱、跟蹤待辦事項、制作PPT、搜索Slack里的決策歷史、預訂差旅。

我與其他公司產品經理的交流發現，他們也在摸索自己版本的這套分工。

Decagon產品總監Bihan Jiang分享道，Claude大幅提升了優質產品團隊的上限，從想法到原型的距離大幅縮短，以前需要幾周建設的東西，現在從Cowork拉取上下文、轉到Claude Code，幾小時內就能演示。能跑通真實用戶驗證的高質量想法數量顯著增加。

Datadog高級產品經理Kai Xin Tai在構建AI SRE智能體時提到，每次新模型發布都意味著可能性邊界的變化，產品經理的工作已經從前期鎖定確定性，轉變為加速發現。

模型能力的增長有多快

METR 2026年3月的研究數據顯示，Opus 4.6在約一半情況下能完成人類需要近12小時才能完成的軟件任務。而當我們最初構建Claude Code時，Sonnet 3.5（新版）是當時最強的模型，METR測量的結果是它能完成人類21分鐘左右的任務。

16個月，約41倍的提升。

我們做出的四個轉變

一、用短周期沖刺代替長線路線圖

我們鼓勵團隊每個人——工程師、產品經理、設計師——開展邊緣探索項目（side quest）。這是一種短期自主實驗：花一個下午做個原型，測試一個你以為做不到的能力，或者就是看看把模型推得比預期更猛會發生什么。

Claude Code桌面版、AskUserQuestion工具、待辦事項列表，都是這樣誕生的。

二、用演示和評估替代文檔

我們的團隊基本上用原型優先取代了文檔優先的思路。站會不是匯報進展，而是分享新想法的演示。內部用戶試用，有真實參與感的功能得到打磨并更廣泛分享。因為一個下午就能出原型，押錯的代價很低。

實際案例：同事Noah把插件規范發給Claude Code，返回的原型已經接近可交付狀態，直接錨定了團隊最終交付的產品形態。

一個簡單的技巧：寫完規范文檔之后，把它發給Claude Code，讓它來構建。哪怕是粗糙的原型，也會徹底改變對話的質量。

此外，評估也能讓抽象的產品功能變得具體。在多智能體協作功能的開發中，同事Conner手工構建了一套評估集，精準測量功能在哪些情況下有效、哪些情況下失效以及如何改進。能度量，才能改進。

三、用新模型重新審視已有功能

交付一個功能后，更好的模型出來了，這個功能可能會有質的提升。每次模型發布，都是重新審視已有功能的隱性信號。

捕捉這些時機最好的方式，就是自己成為日常活躍用戶，刻意嘗試你認為可能還做不到的事情。有時候它就成功了，這就是產品需要跟上的信號。

Claude Code with Chrome就是這樣發生的。我們觀察到用戶在Claude Code里構建Web應用，然后手動切換到Chrome中的Claude來測試，反復復制粘貼指令。這個模式足夠穩定，于是我們意識到這應該成為內置功能。

還有一個反直覺的原則：原型階段要優先能力上限，不要過早削減token用量。很多人會提前控制成本，結果交付了能力大打折扣的功能。你應該先驗證這個功能是否可行，成本的優化可以等到更便宜的模型跟上來之后再做。

四、做最簡單的能跑通的方案

Anthropic在所有團隊都有一條共同原則：做能解決問題的最簡單方案。

如果你的產品巧妙地繞開了某個模型局限，那這個繞法在下個模型出來后就會變成多余的復雜度。實現越簡單，新能力到來時就越容易替換。

我們最初在Claude Code里加入待辦事項列表功能時，模型無法穩定地在完成任務后勾掉對應條目。于是我們加了系統提醒，每隔幾條消息就推動智能體更新自己的待辦列表。這個方案跑通了，但本質上是個臨時補丁。下一個模型出來，這個行為直接就有了，提醒邏輯完全移除。我們反復見證這個模式：系統提示詞和工具描述曾經被大量工程化來補償模型局限，隨著每個新模型的發布，這些工程化內容都在被削減——Opus 4.6上削減了20%。

最后說幾句

很多產品經理習慣對完整的產品體驗保持緊密控制，但AI產品要求你放手，才能跑快。這對完美主義者來說是最難適應的轉變。但產品經理的角色現在是識別少數幾個真正不可妥協的點，其余的放手。

這些轉變的綜合效果是，產品團隊可以大幅提速。當產品經理能在一個下午從想法走到可用的原型，想法和驗證之間的距離幾乎消失了。

在Anthropic，做出轉變的不只是產品經理。數據科學、財務、市場、法務、設計團隊都是自發地拿起這些工具的。整個組織以相同的速度運轉，不再等待交接。

產品經理的工作，現在需要同時追蹤兩件事：AI如何改變你的工作方式，以及AI如何改變你的產品中什么是可能的。把這兩件事做好，你就不會再對那個表格工具最終能跑通感到驚訝——因為你早就預判到了。

source：

https://claude.com/blog/product-management-on-the-ai-exponential

來源 | AI寒武紀（ID：agihwj）

作者 | AI寒武紀 ; 編輯 | 呼呼大睡

內容僅代表作者獨立觀點，不代表早讀課立場