Claude code 產(chǎn)品經(jīng)理Cat Wu親述：我是如何用AI徹底重構(gòu)PM工作流的

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

以下是詳細內(nèi)容：

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

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

再往后，Opus 4.6已經(jīng)可以穩(wěn)定地一次性完成Excalidraw的功能需求，我們開始在數(shù)千名專業(yè)開發(fā)者面前實時演示。

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

傳統(tǒng)產(chǎn)品管理的基本假設已經(jīng)失效

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

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

我是怎么走到這里的

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

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

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

我如何劃分工作流

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

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

Claude Code是我構(gòu)建原型、跑評估、寫腳本的地方，很多腳本本身也在調(diào)用Claude API。有代碼產(chǎn)出的任務，我放在這里。

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

我與其他公司產(chǎn)品經(jīng)理的交流發(fā)現(xiàn)，他們也在摸索自己版本的這套分工。

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

Datadog高級產(chǎn)品經(jīng)理Kai Xin Tai在構(gòu)建AI SRE智能體時提到，每次新模型發(fā)布都意味著可能性邊界的變化，產(chǎn)品經(jīng)理的工作已經(jīng)從前期鎖定確定性，轉(zhuǎn)變?yōu)榧铀侔l(fā)現(xiàn)。

模型能力的增長有多快

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

16個月，約41倍的提升。

我們做出的四個轉(zhuǎn)變

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

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

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

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

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

實際案例：同事Noah把插件規(guī)范發(fā)給Claude Code，返回的原型已經(jīng)接近可交付狀態(tài)，直接錨定了團隊最終交付的產(chǎn)品形態(tài)。

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

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

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

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

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

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

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

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

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

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

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

最后說幾句

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

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

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

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

source：

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

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

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

內(nèi)容僅代表作者獨立觀點，不代表早讀課立場