Claude產品負責人：AI時代的產品經理工作流

本篇取自 Anthropic 旗下 Claude Code 產品負責人 Cat Wu 的分享：當模型能力以指數級速度提升，產品管理團隊該如何重構自己的工作流、節奏與判斷方式。

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

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

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

而不到一年后，Opus 4.6 已經能相當穩定地“一次成型”完成 Excalidraw 的功能需求。穩定到什么程度？穩定到我們愿意在數千名專業開發者面前現場演示。

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

但指數級進化的模型，打破了這個假設。

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

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

下面是我的一些體會。

一、我是怎么走到 Claude Code 產品管理這條路上的

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

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

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

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

二、一套新的產品管理工作流，正在形成

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

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

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

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

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

我也和很多行業里的產品經理交流過，發現大家都在形成某種相似、但各自版本不同的工作方式。

Decagon 產品總監 Bihan Jiang 說：

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

Datadog 高級產品經理 Kai Xin Tai 也提到：

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

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

三、真正需要適應的，不是 AI，而是 AI 的指數增長

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

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

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

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

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

我們團隊內部，主要做了四個轉變。

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

傳統的 PM 思路里，探索往往發生在路線圖鎖定之前。先調研、寫 PRD、定方案，再把任務交給工程去實現。

但現在，我們越來越不依賴那種長期、穩定的路線圖。相反，我們鼓勵團隊里的每個人——工程師、設計師、產品經理——都去做“side quest”，也就是支線任務。

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

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

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

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

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

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

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

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

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

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

在傳統軟件里，一個功能上線后，通常會進入相對穩定的維護周期。但在 AI 產品里，情況完全不同。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

很多產品經理過去習慣的是：盡可能細致地掌控完整產品體驗。

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

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

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

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

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

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

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

來源 | 產品設計頻道BackChannel

（ID：AIBackChannel）

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

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