Claude產(chǎn)品負(fù)責(zé)人：AI時代的產(chǎn)品經(jīng)理工作流

本篇取自 Anthropic 旗下 Claude Code 產(chǎn)品負(fù)責(zé)人 Cat Wu 的分享：當(dāng)模型能力以指數(shù)級速度提升，產(chǎn)品管理團隊該如何重構(gòu)自己的工作流、節(jié)奏與判斷方式。

2024 年 10 月，Claude Sonnet 3.5（new）發(fā)布后，我給自己養(yǎng)成了一個習(xí)慣：每次有新模型上線，我都會讓 Claude Code——當(dāng)時它還只是一個內(nèi)部工具——去給 Excalidraw 加一個表格工具。

幾乎每一代模型都比上一代更進一步，但還是會失敗。

直到 2025 年 6 月，Opus 4 發(fā)布后，Claude 開始偶爾能做成了。成功率已經(jīng)高到一個程度：我們甚至把這件事做成了 Claude 4 發(fā)布時的預(yù)錄制演示，用來展示最新模型已經(jīng)具備了怎樣的能力。

而不到一年后，Opus 4.6 已經(jīng)能相當(dāng)穩(wěn)定地“一次成型”完成 Excalidraw 的功能需求。穩(wěn)定到什么程度？穩(wěn)定到我們愿意在數(shù)千名專業(yè)開發(fā)者面前現(xiàn)場演示。

這就是今天產(chǎn)品團隊面對的現(xiàn)實：模型能力的進步速度，正在持續(xù)拓展“什么是可能的”的邊界。傳統(tǒng)產(chǎn)品管理方法有一個很深的前提——項目啟動時技術(shù)上能做什么，到了項目結(jié)束時，大致還是那些事。于是，PM 會在前期盡可能收集信息、做判斷、定計劃，然后在接下來幾個月里沿著這條路徑執(zhí)行。

但指數(shù)級進化的模型，打破了這個假設(shè)。

你原本圍繞著設(shè)計的一些約束，可能會在項目進行到一半時突然消失。你不是在一塊穩(wěn)定地面上建產(chǎn)品，而是在一塊不斷抬升的地面上建。團隊也必須圍繞這個現(xiàn)實重新組織自己。新的產(chǎn)品管理節(jié)奏，不再是“研究—規(guī)劃—執(zhí)行”的線性流程，而是快速實驗、持續(xù)發(fā)布，再對有效的方向加倍投入。

這也是我在 Anthropic 做產(chǎn)品經(jīng)理后，最常被問到的問題之一：產(chǎn)品經(jīng)理這個角色，到底變成什么樣了？

下面是我的一些體會。

一、我是怎么走到 Claude Code 產(chǎn)品管理這條路上的

我的職業(yè)起點是產(chǎn)品工程師，曾在 Scale AI、Dagster 這樣的創(chuàng)業(yè)公司工作。后來我做過風(fēng)險投資，在那段經(jīng)歷里，我也仍然會寫代碼，把一些繁瑣的工作自動化掉，比如掃描 X 上新公司的發(fā)布信息，或者判斷哪些開源項目正在快速起勢。

2024 年 8 月，我加入 Anthropic，成為 Research PM 團隊的一名產(chǎn)品經(jīng)理。這個團隊的職責(zé)，是連接研究團隊與真實世界的客戶，幫助公司交付更好的模型。

當(dāng)年秋天，Claude Code 在公司內(nèi)部開放后，我開始用它處理工作里那些原本很手動的部分。比如，我會用它搭建 Streamlit 應(yīng)用來分析大規(guī)模用戶反饋，也會跑各種 eval，幫助團隊找到新的、值得信任的 benchmark。更重要的是，構(gòu)建門檻被大幅降低后，我也可以探索很多原本超出自己角色邊界的事情，比如搭建 RL 環(huán)境，去更直觀地理解訓(xùn)練過程。

這些項目加起來，花了數(shù)百小時。我全程都在提示由 Sonnet 3.5（new）驅(qū)動的 Claude Code，但我自己沒有手寫過一行代碼。

二、一套新的產(chǎn)品管理工作流，正在形成

像 Claude Code 和 Cowork 這樣的工具，正在逐漸抹平產(chǎn)品開發(fā)流程中原本很清晰的崗位邊界。

當(dāng)然，Claude Code 并不是我整個工作流里唯一的工具。到現(xiàn)在為止，我大致形成了一種比較自然的“三段分工”：

Claude.ai，是我把 Claude 當(dāng)作思考搭子使用的地方。在這里，我更像是在和它討論，而不是讓它執(zhí)行。我會和它聊戰(zhàn)略文檔、棘手問題的處理方式，也會拿它做快速問答。

Claude Code，是我寫原型、做 eval、搭腳本的地方，很多項目也會直接調(diào)用 Claude API。只要輸出是代碼，我通常就會切到 Claude Code。

Cowork，則承擔(dān)了剩下的大多數(shù)知識工作：清郵箱、管理待辦、做 slide、搜索 Slack 理解決策歷史、預(yù)訂出差行程，基本都在這里完成。

我也和很多行業(yè)里的產(chǎn)品經(jīng)理交流過，發(fā)現(xiàn)大家都在形成某種相似、但各自版本不同的工作方式。

Decagon 產(chǎn)品總監(jiān) Bihan Jiang 說：

“Claude 抬高了優(yōu)秀產(chǎn)品團隊能做到的上限，也大幅縮短了從想法到原型之間的距離。過去，要把一個真正能給客戶看到、摸到的東西做出來，往往要花上幾周。現(xiàn)在，我會先在 Claude Cowork 里拉入 Slack、代碼庫和文檔上下文，再切到 Claude Code，幾個小時內(nèi)就能做出一個可演示版本。優(yōu)秀產(chǎn)品團隊一直都在用真實客戶測試自己的想法，這一點沒有變。變化在于，現(xiàn)在我們能把更多高質(zhì)量想法真正送進這個循環(huán)。”

Datadog 高級產(chǎn)品經(jīng)理 Kai Xin Tai 也提到：

“在一個 AI 原生的世界里做 PM，既是創(chuàng)造性的，也是偏研究型的。每一次新模型發(fā)布，都會改變能力邊界。我們在做 Datadog 的 Bits AI SRE agent 時，會通過真實生產(chǎn)事故的離線評測去研究它的優(yōu)勢和失敗模式，同時也會設(shè)計緊密的反饋閉環(huán)，不斷調(diào)整 UX，把 agent 卡住的地方暴露出來，再把這些洞察轉(zhuǎn)回產(chǎn)品改進。某種意義上，PM 的核心能力已經(jīng)從前期定義確定性，轉(zhuǎn)向加速發(fā)現(xiàn)。”

對今天的產(chǎn)品經(jīng)理來說，最令人興奮的一點，也許正是這些工作流仍在持續(xù)變化，并不斷放大我們的杠桿。

三、真正需要適應(yīng)的，不是 AI，而是 AI 的指數(shù)增長

METR 在 2026 年 3 月發(fā)布的《前沿 AI 模型的任務(wù)完成時間跨度》報告指出：Opus 4.6 大約有一半概率，可以完成那些需要人類將近 12 小時才能完成的軟件任務(wù)。

在 Claude Code 剛開始構(gòu)建時，當(dāng)時最前沿的 Sonnet 3.5（new），按 METR 的測量，只能完成大約相當(dāng)于人類 21 分鐘工作量的任務(wù)。

也就是說，16 個月時間里，能力跨度增長了大約 41 倍。

為了跟上這樣的變化速度，Claude Code 團隊本身也在變化。角色邊界開始互相滲透：設(shè)計師會寫代碼，工程師會做產(chǎn)品判斷，產(chǎn)品經(jīng)理會搭原型、做評測。這種混合式協(xié)作之所以能成立，并不是因為每個人都“什么都做”，而是因為團隊有非常清晰的戰(zhàn)略和目標(biāo)，讓每個人都能自主判斷優(yōu)先級。

在這樣的環(huán)境里，產(chǎn)品經(jīng)理真正重要的工作，不再是把所有事情都定義清楚，而是在模型能力快速變化帶來的模糊地帶里制造清晰感，推動團隊去重新思考“還能做得更大嗎”，同時幫團隊掃清路徑，讓產(chǎn)品更快落地。

我們團隊內(nèi)部，主要做了四個轉(zhuǎn)變。

1、放棄長路線圖，改用短沖刺與“支線任務(wù)”

傳統(tǒng)的 PM 思路里，探索往往發(fā)生在路線圖鎖定之前。先調(diào)研、寫 PRD、定方案，再把任務(wù)交給工程去實現(xiàn)。

但現(xiàn)在，我們越來越不依賴那種長期、穩(wěn)定的路線圖。相反，我們鼓勵團隊里的每個人——工程師、設(shè)計師、產(chǎn)品經(jīng)理——都去做“side quest”，也就是支線任務(wù)。

所謂支線任務(wù)，其實是一些不在正式路線圖里的短周期自主實驗：也許只是花一個下午去做個原型，也許是驗證一個你原本以為做不到的能力，也可能只是單純地看看，當(dāng)你把模型推到比自己想象更高的極限時，會發(fā)生什么。

Anthropic 里一些后來非常受歡迎的功能，比如桌面版 Claude Code、AskUserQuestion 工具，以及待辦列表，最早都是這樣長出來的。

2、用 demo 和 eval 取代“文檔先行”

在我們的團隊里，“先寫文檔再推動”的思路，已經(jīng)越來越多地被“先做原型再討論”取代。

我們甚至不再用傳統(tǒng) stand-up 的方式同步工作，而是直接看 demo。誰有新想法，就做出來給大家看。內(nèi)部用戶會去試，用得起來、有明顯參與度的東西，再繼續(xù)打磨并推向更廣泛的范圍。因為現(xiàn)在一個原型常常一個下午就能完成，所以判斷失誤的代價也變低了。

有一個很典型的例子：Noah 把自己的插件 spec 發(fā)給 Claude Code 后，模型直接返回了一個幾乎接近 production-ready 的原型。這個原型后來幾乎成了團隊最終交付方案的錨點，因為它讓整個團隊能非常快地驗證 UX是否成立。

我自己的一個建議是：你寫完 spec 之后，先別急著把它發(fā)給團隊，不妨先發(fā)給 Claude Code，看看它能不能直接給你做出來。哪怕只是一個粗糙版本，它也會立刻改變團隊討論的重心。

除了 demo，eval 也很重要。因為很多 AI 產(chǎn)品概念本身過于抽象，只有可測量之后，大家才知道自己到底在改什么。

比如在 agent teams 這個功能里——它允許用戶同時協(xié)調(diào)多個 Claude Code 實例協(xié)作——Conner 就手工設(shè)計了一組評測，用來判斷 agent teams 在哪些情況下表現(xiàn)好、哪些情況下不行、接下來應(yīng)該優(yōu)先修什么。你一旦能測量一個功能，就更容易真正改進它。

3、每次新模型發(fā)布，都要重新審視舊功能

在傳統(tǒng)軟件里，一個功能上線后，通常會進入相對穩(wěn)定的維護周期。但在 AI 產(chǎn)品里，情況完全不同。

你今天上線一個功能，下一代模型出來后，它明天就可能突然變得“本來應(yīng)該做得更好”。所以，每次模型發(fā)布，本質(zhì)上都是一次隱性的產(chǎn)品復(fù)盤提醒：你得回頭再看一遍你已經(jīng)做過的東西。

捕捉這種機會，最好的方式就是成為產(chǎn)品的重度日活用戶，并且有意識地去讓它做那些你覺得“應(yīng)該還太難”的事。

有時候它突然就能做成了。那一刻，其實就是信號：不是模型變好了這么簡單，而是產(chǎn)品應(yīng)該跟上了。

Claude Code 與 Chrome 的聯(lián)動能力，就是這樣發(fā)現(xiàn)的。我們注意到，用戶在用 Claude Code 搭 Web 應(yīng)用后，會切到 Chrome 里的 Claude 手動做測試。兩個工具之間，用戶會來回復(fù)制粘貼提示和指令。這個流程雖然笨，但已經(jīng)“能用”了。于是我們意識到，這種用戶自己搭出來的臨時流程，本質(zhì)上就是一種腳手架，而腳手架恰恰是在告訴你：這件事應(yīng)該被做成正式功能。

在做這類原型時，我們還有一個明確原則：先把能力做到極限，再考慮成本。token 往往要比你直覺里愿意給的更多。

很多團隊容易犯的錯，是太早開始優(yōu)化 token 成本，結(jié)果做出了一個能力被大幅削弱的版本。成本當(dāng)然重要，但它往往可以留到后面解決。因為隨著時間推移，更便宜的模型總會追上來。可在那之前，你首先得知道：這個功能到底能不能成立。

4、始終選擇“那個有效的簡單方案”

Anthropic 內(nèi)部有一個跨團隊都在遵循的原則：做那個有效的簡單方案。

原因也很直接。今天你為了繞開某個模型限制而設(shè)計的“巧妙方案”，很可能在下一代模型到來后，立刻變成多余的復(fù)雜性。實現(xiàn)越簡單，未來接入新能力就越容易。

Claude Code 里的待辦列表，就是一個很典型的例子。

最初上線這個功能時，模型并不能穩(wěn)定地在任務(wù)完成后自動勾選事項。于是我們加了一套系統(tǒng)提醒機制：每隔幾輪對話，就提醒一下 agent 去更新自己的 todo list。這種做法是有效的，但本質(zhì)上，它是個 hack。

后來新模型上線后，這種行為不需要提醒也能自然完成，我們就把提醒整個刪掉了。

類似的事情，我們已經(jīng)反復(fù)見過很多次。過去，我們的 system prompt 和 tool description 往往寫得非常重，因為需要靠大量提示工程去彌補模型能力上的不足。而隨著模型變強，這部分內(nèi)容反而能越來越精簡。僅在 Opus 4.6 這一代上，我們就把相關(guān) prompting 削減了 20%。

未來的 PM，更像是在浪頭上保持平衡

很多產(chǎn)品經(jīng)理過去習(xí)慣的是：盡可能細(xì)致地掌控完整產(chǎn)品體驗。

但 AI 時代會逼著你學(xué)會放手。尤其是在做 AI 產(chǎn)品時，那種感覺很像沖浪——最重要的不是把每一個動作都設(shè)計得完美，而是先確保自己始終留在浪上。

對我這種有點完美主義傾向的人來說，這是最難適應(yīng)的一種變化。可現(xiàn)在，PM 更重要的職責(zé)，已經(jīng)不再是把一切都定義清楚，而是分辨出那少數(shù)幾個真正不能妥協(xié)的點，然后把其他部分放開，讓團隊更快行動。

這一系列變化疊加起來，帶來的最直接結(jié)果就是：產(chǎn)品團隊的速度被大幅提升了。

當(dāng)一個 PM 能在一個下午里，從一個念頭走到一個可運行的原型，“要不我們試試看”與“來，你現(xiàn)在就試一下這個”之間，幾乎就不再有距離。

而在 Anthropic，發(fā)生變化的不只是 PM。數(shù)據(jù)科學(xué)、財務(wù)、市場、法務(wù)、設(shè)計團隊，也都在主動用這些工具重構(gòu)自己的工作方式。整個組織開始以接近同樣的速度推進，而不是層層等待交接。

所以，今天 PM 這個角色，實際上要同時追蹤兩條變化曲線：第一，AI 正在怎樣改變你的工作方式；第二，AI 又正在怎樣改變你的產(chǎn)品邊界。

這兩件事都看清楚，你就不會在那個“表格工具終于能跑通”的時刻感到意外。因為你會是那個最早意識到：它快要發(fā)生的人。

來源 | 產(chǎn)品設(shè)計頻道BackChannel

（ID：AIBackChannel）

作者 | Daniel ; 編輯 | 呼呼大睡

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