Claude code 產品經理Cat Wu親述：我是如何用AI徹底重構PM工作流的
整理版優先睇
Claude Code產品經理Cat Wu親述：用AI徹底重構PM工作流，擁抱快速實驗與持續交付
呢篇文章係由Anthropic嘅Research PM Cat Wu親筆寫嘅，佢分享咗點樣用AI重新定義自己嘅產品管理工作流。文章背景係模型能力喺16個月內提升咗約41倍，傳統項目管理假設完全失效，團隊必須圍繞呢個現實重組工作方式。整體結論係：產品經理要放棄完美控制，轉向快速實驗同持續交付，先可以喺指數級進步嘅AI時代做出有影響力嘅產品。
Cat Wu職業生涯起步做產品工程師同風險投資，習慣用代碼自動化重複工作。加入Anthropic之後，佢開始用Claude Code加速手動操作，從分析用戶反饋到搭建強化學習環境，全部冇親手寫過一行代碼。佢將工作流程劃分為Claude.ai（策略打磨）、Claude Code（原型構建）同Cowork（雜項管理），呢個分工模式在其他公司PM身上都見到類似做法。
文章提出咗四個具體轉變：短週期衝刺代替長線路線圖、用演示同評估替代文檔、用新模型重新審視已有功能、做最簡單嘅可行方案。呢啲轉變嘅綜合效果係產品團隊大幅提速，產品經理角色由鎖定確定性變成加速發現，同時要追蹤AI對工作方式同產品可能性嘅影響。
- 傳統產品管理假設模型能力不變，但模型指數級進步使呢個假設失效，產品經理必須轉向快速實驗同持續交付。
- 新工作節奏：用短週期衝刺（side quest）代替長線路線圖，一個下午出原型，押錯成本低。
- 用新模型重新審視已有功能：每次模型發佈都係隱性信號，原型階段應優先驗證能力上限，唔好過早控制成本。
- 做最簡單可行嘅方案：避免繞開模型侷限導致冗餘複雜度，因為新模型會自然解決舊問題。
- 產品經理角色由控制轉為放手，識別少數不可妥協點，加速迭代，同時同步追蹤AI對工作方式同產品嘅影響。
模型進步顛覆傳統假設
Cat Wu親身經歷：由2024年10月開始，每次有新模型出，佢就嘗試用Claude Code為Excalidraw加表格工具。從Sonnet 3.5一路到Opus 4.6，終於穩定做到。呢個過程直接反映咗模型能力嘅飛躍。
傳統產品管理嘅基本假設已經失效
傳統邏輯假設項目開始時嘅技術約束到結束都唔變，但指數級進步嘅模型令地面持續抬升，團隊必須圍繞呢個現實重新組織工作方式。
新嘅產品管理節奏係：快速實驗、持續交付、押注有效方向。
從親身經驗摸索出新工作流
Cat Wu職業生涯起步做產品工程師同風險投資，習慣用代碼自動化重複工作。加入Anthropic後，佢用Claude Code加速手動操作，從分析用戶反饋到搭建強化學習環境。
全程沒有親手寫過一行代碼
佢將工作流劃分為三款產品：Claude.ai用嚟打磨策略文檔，Claude Code用嚟構建原型同跑評估，Cowork負責收件箱、待辦事項、Slack搜索等雜項。
Claude.ai係策略打磨
Claude Code係原型構建
Cowork負責雜項
其他公司PM都有類似分工，例如Decagon產品總監話Claude大幅提升咗優質產品團隊嘅上限，從想法到原型距離大幅縮短。
從想法到原型的距離大幅縮短
四個關鍵轉變重塑產品管理
短週期衝刺代替長線路線圖
- 1 短週期衝刺：鼓勵side quest，一個下午出原型，Claude Code桌面版就係咁誕生。
- 2 用演示和評估替代文檔：站會變演示會，原型優先。同事Noah將插件規範畀Claude Code，一次出到接近可交付原型。
- 3 用新模型重新審視已有功能：每次模型發佈都係重新審視信號。原型階段優先能力上限，成本可後續優化。
- 4 做最簡單能跑通嘅方案：避免繞開模型侷限，因為下個模型會解決。系統提示詞隨模型進步削減20%。
原型階段要優先能力上限，唔好過早削減token用量
放手先可以跑得更快
產品經理習慣對完整產品體驗保持緊密控制，但AI產品要求你放手，先可以跑得快。對完美主義者嚟講，呢個係最難適應嘅轉變。
產品經理嘅角色而家係識別少數幾個真正不可妥協嘅點，其餘嘅放手。
綜合效果係產品團隊大幅提速，當產品經理能喺一個下午從想法走到可用原型，想法同驗證之間嘅距離幾乎消失。
當產品經理能喺一個下午從想法走到可用原型，想法同驗證之間嘅距離幾乎消失。
產品經理嘅工作而家需要同時追蹤兩件事：AI如何改變你嘅工作方式，同埋AI如何改變你嘅產品中乜嘢係可能。
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點樣改變你嘅產品中乜嘢係可能嘅。將呢兩件事做好，你就唔會再對嗰個表格工具最終能夠行得通感到驚訝——因為你早就預判到咗。
來源：
https://claude.com/blog/product-management-on-the-ai-exponential
--end--
最後記得⭐️我，每日都在更新：如果覺得文章仲唔錯嘅話可以點讚轉發推薦評論
/...@作者：你講嘅完全正確（YAR師）
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
--end--
最後記得⭐️我，每天都在更新：如果覺得文章還不錯的話可以點贊轉發推薦評論
/...@作者：你說的完全正確（YAR師）