Anthropic 產品負責人：從 6 個月到 1 天的發版秘密，Harness 會被模型當早餐吃掉

可以說，Anthropic 的產品發布節奏，算得上是業界獨一無二的了。

如果你做一張行事曆圖，把 Anthropic 最近的產品發布標出來，就會發現：幾乎每天都有新功能上線。

最近，Lenny Rachitsky 邀請到 Kat Wu，也就是 Anthropic Claude Code 和 Cowork 的產品負責人，錄製了一集 Podcast 訪談。節目資訊密度極高，從 PM 角色的轉變、Anthropic 的內部流程，到原始碼外洩事件和 OpenClaw 的決策，全都聊了個透徹。

我把當中的關鍵訊息整理了出來，分享如下：

她是誰

Kat Wu 之前當了多年的工程師，短暫做過創投，後來加入 Anthropic，成為 Claude Code 和 Cowork 的產品負責人。

她和 Boris（Claude Code 的創造者暨技術負責人）搭檔。

Boris 負責產品願景，定義三到六個月後產品應該長成什麼樣子。Kat 則負責把願景拆解成可執行的路徑，並協調市場、銷售、財務等各個團隊。

「我們大概有 80% 的想法是一致的。剩下的 20%，誰比較在意就由誰來主推。」

她們團隊有一個特點：幾乎所有 PM 都有工程背景，設計師也曾是前端工程師。

這倒不是刻意為之。Kat 的解釋是，具備工程背景的人能更快判斷一件事情做起來到底有多困難，而這個判斷在當前的節奏下實在太關鍵了。

快到什麼程度

Anthropic 的產品迭代週期，從六個月壓縮到一個月，有些功能甚至只用一天。

而這背後的秘訣，倒也沒有什麼複雜的方法論。

Kat 提到了三件事：

設定清晰的目標。

大型語言模型太泛用了，如果不鎖定使用者和場景，團隊很容易迷失方向。比如 Claude Code 的目標使用者是專業開發者，而某個功能要解決的問題是「權限彈窗太多導致疲勞」，目標是讓企業開發者能安全地實現零權限提示。

光這一條就排除了大量不相關的方案。

Research Preview 機制。

幾乎所有功能都以 Research Preview 的形式先上線。使用者知道這是一個早期版本，可能不會永久保留。這樣做的好處是，團隊不需要做到完美才能發布，一兩週就能把東西推出去。

Launch Room 流程。

工程師覺得功能差不多了，就把它丟進一個叫「evergreen launch room」的頻道。文件負責人 Sarah、產品行銷經理負責人 Alex、開發者關係團隊的 Tarek 和 Lydia 會迅速跟進，隔天就能發布。

「我們希望移除一切阻礙發布的障礙。團隊裡每個人都應該能在一週之內，甚至一天之內，把自己的想法變成產品。」

Lenny 忍不住追問：你們內部用了模型……是不是因為這樣才快的？

Kat 的回答是：

「我們確實在內部用了這些模型，它確實加快了一點速度。但大部分的加速來自流程和團隊文化。」

模型會吃掉你的產品

Kat 聊到了一個值得注意的現象：每次新模型出來，她們做的第一件事，是刪功能。

Claude Code 最早有個待辦清單功能。當時的模型在做大規模程式碼重構時，總是改了 5 個呼叫點就停了，明明有 20 個要改。團隊想了個辦法：讓模型先列個清單，然後逐項完成。

結果這招非常管用。

但到了 Opus 4 之後呢，模型自己就會主動列清單、逐項完成了。待辦清單從一個「必要的拐杖」變成了「可有可無的輔助介面」。

「每次發布新模型，我們都會通讀整個系統提示，逐段反思：模型還需要這個提醒嗎？如果不需要了，就刪掉。」

Lenny 舉了個例子：「模型會把你的輔助工具當早餐吃掉。」

Kat 表示同意。

但更讓她興奮的是新模型解鎖的全新能力。比如程式碼審查：她們試了好幾個版本，準確率一直不夠。直到 Opus 4.5 和 4.6 出來，才達到了讓工程團隊真正依賴它的水準，現在 Anthropic 內部合併 PR 之前，必須先過 Claude 的程式碼審查。

「提前做好還沒完全能用的產品原型很重要。這樣新模型一出來，你直接換上去看看差距有沒有被彌合，就可以了。」

這和之前 Mike Krieger 在 Podcast 裡說的是一樣的思路：為未來的模型做產品。

原始碼外洩

上個月 Claude Code 原始碼外洩的事情，Kat 也做了回應。

「我們第一時間就進行了排查。這是人為失誤的結果，有人在用 Claude 寫 PR 更新套件發布流程時出了差錯。雖然經過了兩層人工審查，但還是漏掉了。」

Lenny 問那個人還在嗎，Kat 的回答很能體現 Anthropic 的文化：

「這是流程問題。最重要的是從中學習，加上更多防護措施。大部分的改進已經上線了。」

OpenClaw 的抉擇

Lenny 還問到了 OpenClaw。最近 Anthropic 限制了第三方工具（如 OpenClaw🦞）使用 Claude 的訂閱額度，社群一片譁然、抗議。

Kat 的解釋是：Claude 的需求成長太快，訂閱額度本來是為第一方產品設計的。第三方工具的使用模式不同，為基礎設施帶來了額外的壓力。

「我們花了很多時間研究怎麼做最平順的過渡。能給每位使用者一些點數作為緩衝，這讓我比較欣慰。但我們確實需要優先保障第一方產品和 API。」

Lenny 自然是站在 Anthropic 這邊：

「你們在 200 美元月費下提供幾乎無限的使用量，本身就在補貼使用者。公司也需要盈利。」

Cowork 被低估了

節目裡還有一段，是關於 Cowork 的。

Kat 用 Cowork 為即將到來的 Code with Claude 大會做了一份 20 頁的演講稿。她的做法是：連接好 Google Calendar、Slack、Gmail 和 Google Drive，然後告訴 Cowork 演講的主題和敘事方向。

Cowork 花了大概一個小時，翻閱了 X 上的產品發布記錄、團隊內部的 launch room 頻道和 demo 頻道，自己整理出一份 20 頁的簡報。

「我早上起來讀了一遍，還挺不錯的。文字稍微多了點，做了一輪回饋調整。但視覺上看起來就像 Anthropic 的設計師做的一樣，因為 Cowork 能讀取我們的設計系統範本。」

她把產品分成兩類來用：輸出是程式碼的，用 Claude Code。輸出不是程式碼的（PPT、文件、郵件），用 Cowork。

Applied AI 團隊（負責幫客戶採用 Claude API 的技術型市場團隊）應該是 Anthropic 內部除了工程師之外最大的 token 消耗者。

他們用 Cowork 在每次客戶會議前自動生成簡報：明天要見哪些客戶、他們之前問過什麼、待辦事項是什麼、某個功能的最新上線時間是什麼。

這些都是他們自己搭建的工作流程，做好了之後分享給團隊其他人。

PM 的未來

Kat 對 PM 角色變化的看法，是這集節目裡最值得記錄下來的部分。

「程式碼變得越來越便宜了。那什麼變得更有價值呢？決定寫什麼。」

她說 Anthropic 目前更傾向於招募有產品品味的工程師，傳統意義上的 PM 反而不是第一選擇。

團隊裡有不少工程師可以從看到 X 上的用戶回饋開始，到週末就自己上線一個功能，幾乎不需要 PM 參與。

「PM 和工程師這兩個角色正在融合。你多招募些有產品品味的工程師，或者多招募些 PM 來指導工程方向，效果差不多。」

但融合的代價呢？

產品一致性。

有時候同一個需求會有兩個功能在進行，因為團隊內部有兩種方案都覺得好，乾脆都上線讓使用者來投票。對新用戶來說，這意味著要花更多時間弄清楚該用什麼。

Kat 坦言，/powerup 功能（一個內建的教學引導）其實違背了他們最初「產品應該直覺到不需要教學」的原則。但功能實在太多了，用戶確實需要有人告訴他們：這一百個功能裡，哪十個是必須用的。

問模型為什麼犯錯

Kat 分享了一個做 AI 產品的獨特技巧：讓模型自己反思它的行為。

比如她發現模型改了前端程式碼後會跑測試，但……就是不會真的打開頁面看一眼使用者介面。她就問模型：你為什麼不檢查使用者介面呢？

模型的回答有時會讓人意外：

「有時候模型會說，系統提示裡的某段話讓它產生了困惑。有時候它會說，我把驗證任務委派給了子代理，但子代理沒做，而我也沒有檢查它的工作。」

這些回饋，就直接指向了輔助工具層面的改進方向。

「對模型的決策保持好奇心，問它為什麼做出了那個選擇，你就能看到是什麼誤導了它，然後修復輔助工具來填補這個空隙。」

50 個 Claude 同步執行

聊到未來的路線圖，Kat 把產品演進拆成了幾個階段，像堆積木一樣：

第一步：單一任務成功。給一個清晰的提示，模型能不能穩定地輸出可以合併的程式碼或者可以分享的文件？

第二步：多任務同步執行。2025 年底 multi-coding 就已經開始流行。目前使用者大概同時跑 6 個 Claude。

第三步：50 到幾百個 Claude 同時跑。到那時候，本機的記憶體肯定是不夠用了，任務得跑在雲端。介面需要告訴你哪些任務需要你看一眼，而且模型應該能自己驗證工作，這樣你看到「已完成」的時候可以放心地信任它。

「而且這個過程要能自我改進。你給了一次回饋，模型在之後的每次執行中都不會再犯同樣的錯誤。」

Just Do Things

Kat 的人生座右銘是：Just do things。

「工作本來就是虛擬的概念。如果你理解了約束條件，你就能想出該做什麼，然後就去做。快速行動，從錯誤中學習，如果做錯了就道歉並修復。」

這話放在 Anthropic 的語境下不難理解：她說很多公司裡角色界限分明，PM 做 PM 的事，工程師做工程師的事。

而 Anthropic 鼓勵的是跨界：你看到一個問題，不用管它屬於誰的地盤，直接解決它。

別停在 95%

最後一個值得記下來的建議，是關於自動化的。

Kat 說她見過兩種極端：一種人從來不做自動化，另一種人沉迷於折騰工具配置、加 MCP、搞 Skills，花的時間比真正完成任務還多。

而更常見的問題是……很多人把自動化做到 95% 之後，就放棄了。

「如果一個自動化不能 100% 運作，那它就不是真正的自動化。最後那 5% 確實需要更多時間，但你得投入這個精力，教 Claude 你的偏好，給它回饋，直到它能完全可靠地執行。」

她自己也承認在用 Cowork 做 Gmail 收件匣清零時，也還沒做到 100%。

但這就是方向：找到你重複做的、不喜歡做的事情，交給 AI，然後把它打磨到完全可靠。省下來的時間，去做你真正想做的事。

這才是 AI 帶給每個人的真正槓桿。

◇ ◆ ◇

相關連結：

• Lenny's Podcast 原文：https://www.lennysnewsletter.com/p/how-anthropics-product-team-moves

• YouTube 完整影片：https://www.youtube.com/watch?v=PplmzlgE0kg

• Kat Wu 的 X：https://x.com/_catwu