Anthropic 產品負責人：從 6 個月到 1 天的發版秘密，harness 會被模型當早餐吃掉
整理版優先睇
Anthropic產品負責人公開快速發版秘密：鎖定清晰目標、Research Preview機制、Launch Room流程；模型進步後要不斷刪走舊有輔助功能，『harness會被模型當早餐食咗』。
呢篇文章係Lenny Rachitsky同Anthropic嘅Claude Code同Cowork產品負責人Kat Wu嘅訪談整理。Kat Wu本身係工程師出身，後來做咗VC，最後加入Anthropic。佢同Boris（Claude Code創造者）拍檔，負責將產品願景拆解成可行路徑。呢次訪談信息密度極高，講咗Anthropic點樣做到幾乎每日有新功能發佈、內部流程、模型演進對產品嘅影響，同埋PM角色嘅變化。
Anthropic嘅產品迭代週期從六個月壓到一個月，甚至一日，關鍵係三件事：設定清晰目標（鎖定用戶同場景），採用Research Preview機制（唔使完美就推出），同埋Launch Room流程（功能接近完成就丟入指定頻道，第二日就發佈）。Kat強調，大部分加速來自流程同團隊文化，而唔係用咗Mythos模型。
另外，每次新模型出嚟，團隊第一件事係刪功能，因為舊時模型需要嘅「枴杖」（例如to-do list）新模型自己就做到。模型會「食咗」你嘅harness。Kat仲分享咗PM與工程師角色融合嘅趨勢、自動化要做到100%可靠等見解。總括嚟講，Anthropic嘅快速發版同持續創新依賴一套清晰嘅流程同敢於刪除嘅心態。
- Anthropic發版從6個月壓到1日，靠清晰目標、Research Preview同Launch Room流程。
- 每次新模型出，團隊會逐段檢查system prompt，刪除唔再需要嘅輔助功能（例如to-do list）。
- 模型進步會「食咗」你嘅harness，所以要提前為未來模型做產品原型。
- PM同工程師角色融合，Anthropic傾向招有產品品味嘅工程師；但會犧牲產品一致性。
- 自動化要追求100%可靠，唔好停喺95%；問模型點解犯錯可以指引harness改進。
Lenny's Podcast 原文
Anthropic產品團隊如何快速發版
YouTube 完整視頻
訪談完整視頻
Kat Wu X
Kat Wu的Twitter
快速發版嘅秘密：流程與文化
Anthropic嘅產品迭代週期，從六個月壓到一個月，甚至一日。呢個速度背後並冇複雜嘅方法論，關鍵係三件事：設定清晰目標、Research Preview機制、Launch Room流程。
設定清晰目標：鎖定用戶同場景，例如Claude Code嘅目標用戶係專業開發者，咁就排除大量不相關方案。
Research Preview機制讓團隊唔使完美先推出，一兩星期就可以上線。Launch Room流程係一個內部頻道，工程師覺得功能差不多就丟入去，相關同事迅速跟進，第二日就發佈。
模型進步與功能刪減
每次新模型出嚟，團隊第一件事係刪功能。早期模型需要「枴杖」，例如to-do list幫手完成大型重構；但Opus 4之後，模型自己就會列清單逐個完成，to-do list變成可有可無。
每次發佈新模型，團隊都會通讀整個system prompt，逐段反思：模型仲需要呢個提醒嗎？如果唔需要，就刪掉。
Lenny形容呢個現象係「模型會將你嘅harness當早餐食咗」。Kat仲興奮表示，新模型解鎖咗代碼審查能力，Anthropic內部而家合併PR前必須先過Claude嘅代碼審查。
管理決策同團隊文化
對於源碼泄露事件，Kat回應係人為失誤，經過兩層審查仍然漏咗。但佢哋冇追究個人，而係視為流程問題，加上更多防護措施。
最重要係從中學習，加上更多防護措施。大部分改進已經上線。 ——Kat Wu
至於OpenClaw限制第三方工具使用Claude訂閲額度，Kat解釋係因為需求增長太快，訂閲額度本來為第一方產品設計，第三方工具增加咗基礎設施壓力。佢哋花咗好多時間研究最平滑嘅過渡方式。
呢啲決策體現咗Anthropic嘅文化：優先保障第一方產品同API，同時盡量減少對用戶嘅影響。
Cowork同PM角色融合
Cowork係一個被低估嘅產品。Kat用佢嚟製作20頁演講稿，連接Google Calendar、Slack等，Cowork自動整理出文稿，視覺效果似Anthropic設計師作品。
輸出係代碼嘅用Claude Code，輸出唔係代碼嘅（PPT、文檔、郵件）用Cowork。
PM嘅未來：代碼變得越來越平，決定寫咩變得更有價值。Anthropic傾向招有產品品味嘅工程師，傳統PM需求下降。PM同工程師角色融合，但會犧牲產品一致性，例如/powerup功能違背直覺原則。
自動化建議與未來路線
Kat分享咗一個獨特技巧：讓模型自己反思點解犯錯。問模型點解唔檢查UI，可能會揭示system prompt嘅誤導或者sub-agent冇做驗證。呢啲反饋直接指向harness改進。
對模型嘅決策保持好奇心，問佢點解做出嗰個選擇，你就能夠睇到係咩誤導咗佢，然後修復harness嚟填補呢個空隙。
自動化方面，唔好停喺95%。如果一個自動化唔可以100%運作，就唔係真正嘅自動化。要投入精力教Claude你嘅偏好，直到佢完全可靠。
未來路線：從單任務成功，到多任務並行（目前6個Claude），再到50到幾百個Claude同時跑。任務要跑喺遠端，模型要能自我驗證同自我改進。
可以話，Anthropic 嘅產品發佈節奏，算係獨一份嘅。
如果你整張日曆圖出嚟，將 Anthropic 近排嘅產品發佈標示曬出嚟，就會發現：幾乎日日都有一個新功能上線。
最近 Lenny Rachitsky 請咗 Kat Wu 嚟，佢係 Anthropic Claude Code 同埋 Cowork 嘅產品負責人，做咗一期 Podcast。節目資訊密度相當高，由 PM 角色嘅變化、Anthropic 嘅內部流程，到源碼洩漏事件同埋 OpenClaw 決策，全部傾咗一輪。
我將裏面嘅關鍵資訊撈咗出嚟，分享如下：
她是誰
Kat Wu 之前做咗好幾年工程師，簡短做過 VC，之後加入 Anthropic，成為 Claude Code 同埋 Cowork 嘅產品負責人。
佢同 Boris（Claude Code 嘅創造者同埋技術負責人）夾檔。
Boris 負責產品願景，定義三到六個月後產品應該係點樣。Kat 就負責將願景拆解成可執行嘅路徑，兼夾協調市場、銷售、財務等各個團隊。
“ 我哋大概 80% 嘅想法都係一致嘅。剩下嘅 20%，邊個在意啲就邊個去推。
佢哋團隊有一個特點：幾乎所有 PM 都有工程背景，設計師都做過前端工程師。
呢個唔係刻意為之。Kat 嘅解釋係，有工程背景嘅人可以更快判斷一樣嘢做起嚟到底有幾難，而呢個判斷喺現時嘅節奏下實在太關鍵喇。
02快到咩程度
Anthropic 嘅產品迭代週期，由六個月壓到咗一個月，有些功能甚至只用一日。
而呢個背後嘅秘密，倒也冇複雜嘅方法論。
Kat 提到咗三樣嘢：
設定清晰嘅目標。
LLM 太通用了，如果唔鎖定用戶同埋場景，團隊好容易迷失方向。譬如 Claude Code 嘅目標用戶係專業開發者，而某個功能要解決嘅問題係「權限彈窗太多搞到用戶好攰」，目標係讓企業開發者可以安全咁實現零權限提示。
呢條就排除咗大量唔相關嘅方案。
Research Preview 機制。
幾乎所有功能都以 research preview 嘅形式先上線。用戶知道呢個係早期版本，可能唔會永久保留。咁做嘅好處係，團隊唔需要做到完美先可以發佈，一兩星期就可以將嘢推出去。
Launch Room 流程。
工程師覺得功能差唔多了，就將佢丟入一個叫「evergreen launch room」嘅頻道。Docs 負責人 Sarah、PMM 負責人 Alex、DevRel 團隊嘅 Tarek 同埋 Lydia 會迅速跟進，第二日就可以發佈。
“ 我哋希望移除一切阻礙發佈嘅障礙。團隊入面每個人都應該可以喺一星期之內，甚至一日之內，將自己嘅想法變成產品。
Lenny 忍不住追問：你哋內部用咗 Mythos 模型……係咪因為呢個先咁快？
Kat 嘅回答係：
03“ 我哋確實喺內部用咗呢啲模型，佢確實加快咗少少速度。但係大部分嘅加速係來自流程同埋團隊文化。
模型會食咗你嘅產品
Kat 傾到咗一個值得注意嘅現象：每次新模型出嚟，佢哋做嘅第一件事係刪功能。
Claude Code 最早有個 to-do list 功能。嗰時嘅模型喺做大規模代碼重構時，總係改咗 5 個調用點就停咗，明明有 20 個要改。團隊諗咗個方法：讓模型先列個清單，然後逐個完成。
結果呢招非常管用。
但係到咗 Opus 4 之後呢，模型自己就會主動列清單、逐個完成咗。to-do list 由一個「必要嘅枴杖」變成咗「可有可無嘅輔助界面」。
“ 每次發佈新模型，我哋都會通讀成個 system prompt，逐段反思：模型仲需要呢個提醒嗎？如果唔需要喇，就刪走佢。
Lenny 舉咗個例：「模型會將你嘅 harness 當早餐食咗。」
Kat 表示同意。
但係更令佢興奮嘅係新模型解鎖嘅全新能力。譬如代碼審查：佢哋試咗好幾個版本，準確率一直唔夠。直到 Opus 4.5 同埋 4.6 出嚟，先至達到咁讓工程團隊真正依賴佢嘅水平，而家 Anthropic 內部合併 PR 之前，必須先過 Claude 嘅代碼審查。
“ 提前做好仲未完全做到嘅產品原型好重要。咁樣新模型一出嚟，你直接換上去睇嚇差距有冇被填補到，就可以喇。
呢個同之前 Mike Krieger 喺 Podcast 裏面嘅思路一樣：為未來嘅模型做產品。
04源碼洩漏
上個月 Claude Code 源碼洩漏嘅事，Kat 都有回應。
“ 我哋第一時間就排查咗。呢個係人為失誤嘅結果，有人用 Claude 寫 PR 更新包發佈流程嗰陣出咗錯。雖然經過咗兩層人工審查，但係依然漏咗。
Lenny 問嗰個人仲喺唔喺度，Kat 嘅回答好能體現 Anthropic 嘅文化：
05“ 呢個係流程問題。最緊要係從中學習，加上多啲防護措施。大部分改進已經上線喇。
OpenClaw 嘅抉擇
Lenny 仲問到 OpenClaw。最近 Anthropic 限制了第三方工具（如 OpenClaw🦞）使用 Claude 訂閲額度，社區一片嘩然、抗議。
Kat 嘅解釋係：Claude 嘅需求增長太快，訂閲額度本嚟係為第一方產品設計嘅。第三方工具嘅使用模式唔同，俾基礎設施帶嚟咗額外嘅壓力。
“ 我哋用咗好多時間研究點樣做最平滑嘅過渡。能俾每個用戶一啲 credits 作為緩衝，呢個令我有啲欣慰。但係我哋確實需要優先保障第一方產品同埋 API。
Lenny 梗係站在 Anthropic 呢邊：
06“ 你哋喺 200 美元月費下提供幾乎無限嘅使用量，本身就係補貼用戶。公司都需要賺錢。
Cowork 被低估咗
節目入面仲有一段，係關於 Cowork 嘅。
Kat 用 Cowork 為即將到嚟嘅 Code with Claude 大會整咗一份 20 頁嘅演講稿。佢嘅做法係：連接好 Google Calendar、Slack、Gmail 同埋 Google Drive，然後告訴 Cowork 演講嘅主題同埋敍事方向。
Cowork 用咗大約一個鐘，翻查咗 X 上嘅產品發佈記錄、團隊內部嘅 launch room 頻道同埋 demo 頻道，自己整理咗一份 20 頁嘅演示文稿。
“ 我朝早起身睇咗一遍，仲okay。文字多少少，做咗一輪反饋調整。但係視覺上睇埋去就好似 Anthropic 嘅設計師整嘅一樣，因為 Cowork 可以讀取我哋嘅設計系統模板。
佢將產品分成兩類嚟用：輸出係代碼嘅，用 Claude Code。輸出唔係代碼嘅（PPT、文檔、電郵），用 Cowork。
Applied AI 團隊（負責幫客戶採用 Claude API 嘅技術型市場團隊）應該係 Anthropic 內部除咗工程師之外最大嘅 token 消耗者。
佢哋用 Cowork 喺每次客戶會議前自動生成 briefing：聽日要見咩客戶、佢哋之前問過啲咩、Action items 係啲咩、某個功能嘅最新上線時間係幾時。
呢啲都係佢哋自己搭建嘅工作流，整好咗之後分享俾團隊其他人。
07PM 嘅未來
Kat 對 PM 角色變化嘅睇法，係呢期節目入面最值得記低嘅部分。
“ 代碼變得越嚟越便宜咗。咁咩變得更有價值呢？決定寫啲咩。
佢話 Anthropic 而家比較傾向請有產品品味嘅工程師，傳統意義上嘅 PM 反而唔係第一選擇。
團隊入面有唔少工程師可以由睇到 X 上嘅用戶反饋開始，到週末就自己上線一個功能，幾乎唔需要 PM 參與。
“ PM 同埋工程師呢兩個角色喺度融合。你多請啲有產品品味嘅工程師，或者多請啲 PM 嚟指導工程方向，效果差唔多。
但係融合嘅代價呢？
產品一致性。
有時同一個需求會有兩個功能喺度做，因為團隊內部有兩種方案都覺得幾好，就索性都上線讓用戶投票。對新用戶嚟講，呢個意味住要花多啲時間去搞清楚應該用邊個。
Kat 坦言，/powerup 功能（一個內置嘅教學引導）其實違反咗佢哋最初「產品應該直覺到唔需要教學」嘅原則。但係功能實在太多喇，用戶確實需要有人告訴佢哋：呢一百個功能入面，哪十個係必須用嘅。
08問模型點解犯錯
Kat 分享咗一個做 AI 產品嘅獨特技巧：讓模型自己反思佢嘅行為。
譬如佢發現模型改咗前端代碼之後會跑測試，但……就係唔會真係打開頁面睇一眼 UI。佢就問模型：你點解唔檢查 UI 呢？
模型嘅回答有時會令人意外：
“ 有時模型會話，system prompt 入面嘅某段說話令佢產生咗困惑。有時佢會話，我將驗證任務委派咗俾 sub-agent，但係 sub-agent 冇做，而我都冇檢查佢嘅工作。
呢啲反饋，直接指向咗 harness 層面嘅改進方向。
09“ 對模型嘅決策保持好奇心，問佢點解做出咗嗰個選擇，你就可以睇到係咩誤導咗佢，然後修復 harness 嚟填補呢個空隙。
50 個 Claude 並行
傾到未來嘅路線圖，Kat 將產品演進拆成咗幾個階段，好似砌積木咁：
第一步：單個任務成功。俾一個清晰嘅 prompt，模型能不能穩定咁輸出可以合併嘅代碼或者可以分享嘅文檔？
第二步：多任務並行。2025 年底 multi-coding 就已經開始紅喇。目前用戶大概同時跑 6 個 Claude。
第三步：50 到幾百個 Claude 同時跑。到咁嘅時候，本地機器嘅記憶體肯定唔夠用咗，任務要跑喺遠端。界面需要告訴你邊啲任務需要你睇一眼，而且模型應該可以自己驗證工作，咁你睇到「已完成」嘅時候可以放心咁信任佢。
10“ 而且呢個過程要能自我改進。你俾咗一次反饋，模型喺之後嘅每次運行入面都唔會再犯同一個錯誤。
Just do things
Kat 嘅人生座右銘係：Just do things。
“ 工作本嚟就係假嘅。如果你理解咗約束條件，你就可以諗到應該做啲咩，然後就去做。快速行動，從錯誤中學習，如果做錯咗就道歉並修復。
呢句說話放喺 Anthropic 嘅語境下唔難理解：佢話好多公司入面角色界線分明，PM 做 PM 嘅嘢，工程師做工程師嘅嘢。
而 Anthropic 鼓勵嘅係跨界：你睇到一個問題，唔需要理佢係邊個嘅地盤，直接解決佢。
11唔好停在 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
可以說，Anthropic 的產品發佈節奏，算得上是獨一份的了。
如果你做上一張日曆圖，把 Anthropic 最近的產品發佈標出來，那就會發現：幾乎每天都有一個新功能上線。
最近，Lenny Rachitsky 請到了 Kat Wu，Anthropic Claude Code 和 Cowork 的產品負責人，訪談了一期播客。節目信息密度相當高，從 PM 角色的變化、Anthropic 的內部流程，到源碼泄露事件和 OpenClaw 決策，全都聊了個遍。
我把裏面的關鍵信息拎了出來，分享如下：
她是誰
Kat Wu 之前做了多年工程師，短暫做過 VC，後來加入 Anthropic，成為 Claude Code 和 Cowork 的產品負責人。
她和 Boris（Claude Code 的創造者和技術負責人）搭檔。
Boris 負責產品願景，定義三到六個月後產品應該長什麼樣。Kat 則負責把願景拆解成可執行路徑，並協調市場、銷售、財務等各個團隊。
“ 我們大概 80% 的想法是一致的。剩下的 20%，誰更在意就誰來推。
她們團隊有一個特點：幾乎所有 PM 都有工程背景，設計師也曾是前端工程師。
這倒不是刻意為之。Kat 的解釋是，有工程背景的人能更快判斷一個東西做起來到底有多難，而這個判斷在當前的節奏下實在是太關鍵了。
02快到什麼程度
Anthropic 的產品迭代週期，從六個月壓到了一個月，有些功能甚至只用一天。
而這背後的秘訣，倒也沒有複雜的方法論。
Kat 提到了三件事：
設定清晰的目標。
LLM 太通用了，如果不鎖定用戶和場景，團隊很容易迷失方向。比如 Claude Code 的目標用戶是專業開發者，而某個功能要解決的問題是「權限彈窗太多導致疲勞」，目標是讓企業開發者能安全地實現零權限提示。
這一條就排除了大量不相關的方案。
Research Preview 機制。
幾乎所有功能都以 research preview 的形式先上線。用戶知道這是一個早期版本，可能不會永久保留。這樣做的好處是，團隊不需要做到完美才能發佈，一兩週就能把東西推出去。
Launch Room 流程。
工程師覺得功能差不多了，就把它丟進一個叫「evergreen launch room」的頻道。Docs 負責人 Sarah、PMM 負責人 Alex、DevRel 團隊的 Tarek 和 Lydia 會迅速跟進，第二天就能發佈。
“ 我們希望移除一切阻礙發佈的障礙。團隊裏每個人都應該能在一週之內，甚至一天之內，把自己的想法變成產品。
Lenny 忍不住追問：你們內部用了 Mythos 模型……是不是因為這個才快的？
Kat 的回答是：
03“ 我們確實在內部用了這些模型，它確實加快了一點速度。但大部分的加速來自流程和團隊文化。
模型會吃掉你的產品
Kat 聊到了一個值得注意的現象：每次新模型出來，她們做的第一件事，是刪功能。
Claude Code 最早有個 to-do list 功能。當時的模型在做大規模代碼重構時，總是改了 5 個調用點就停了，明明有 20 個要改。團隊想了個辦法：讓模型先列個清單，然後逐個完成。
結果這招非常管用。
但到了 Opus 4 之後呢，模型自己就會主動列清單、逐個完成了。to-do list 從一個「必要的枴杖」變成了「可有可無的輔助界面」。
“ 每次發佈新模型，我們都會通讀整個 system prompt，逐段反思：模型還需要這個提醒嗎？如果不需要了，就刪掉。
Lenny 舉了個例子：「模型會把你的 harness 當早餐吃掉。」
Kat 表示同意。
但更讓她興奮的是新模型解鎖的全新能力。比如代碼審查：她們試了好幾個版本，準確率一直不夠。直到 Opus 4.5 和 4.6 出來，才達到了讓工程團隊真正依賴它的水平，現在 Anthropic 內部合併 PR 之前，必須先過 Claude 的代碼審查。
“ 提前做好還沒完全能用的產品原型很重要。這樣新模型一出來，你直接換上去看看差距有沒有被彌合，就可以了。
這和之前 Mike Krieger 在播客裏說的是一樣的思路：為未來的模型做產品。
04源碼泄露
上個月 Claude Code 源碼泄露的事情，Kat 也做了回應。
“ 我們第一時間就排查了。這是人為失誤的結果，有人在用 Claude 寫 PR 更新包發佈流程時出了差錯。雖然經過了兩層人工審查，但還是漏了。
Lenny 問那個人還在嗎，Kat 的回答很是體現了 Anthropic 的文化：
05“ 這是流程問題。最重要的是從中學習，加上更多防護措施。大部分改進已經上線了。
OpenClaw 的抉擇
Lenny 還問道了 OpenClaw。最近 Anthropic 限制了第三方工具（如 OpenClaw🦞）使用 Claude 訂閲額度，社區一片譁然、抗議。
Kat 的解釋是：Claude 的需求增長太快，訂閲額度本來是為第一方產品設計的。第三方工具的使用模式不同，給基礎設施帶來了額外的壓力。
“ 我們花了很多時間研究怎麼做最平滑的過渡。能給每個用戶一些 credits 作為緩衝，這讓我比較欣慰。但我們確實需要優先保障第一方產品和 API。
Lenny 自然是站在 Anthropic 這邊：
06“ 你們在 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 在每次客戶會議前自動生成 briefing：明天要見哪些客戶、他們之前問過什麼、Action items 是什麼、某個功能的最新上線時間是什麼。
這些都是他們自己搭建的工作流，做好了之後分享給團隊其他人。
07PM 的未來
Kat 對 PM 角色變化的看法，是這期節目裏最應該記下來的部分。
“ 代碼變得越來越便宜了。那什麼變得更有價值呢？決定寫什麼。
她說 Anthropic 目前更傾向於招有產品品味的工程師，傳統意義上的 PM 反而不是第一選擇。
團隊裏有不少工程師可以從看到 X 上的用戶反饋開始，到週末就自己上線一個功能，幾乎不需要 PM 參與。
“ PM 和工程師這兩個角色在融合。你多招些有產品品味的工程師，或者多招些 PM 來指導工程方向，效果差不多。
但融合的代價呢？
產品一致性。
有時候同一個需求會有兩個功能在做，因為團隊內部有兩種方案都覺得好，乾脆都上線讓用戶來投票。對新用戶來說，這意味着要花更多時間弄清楚該用什麼。
Kat 坦言，/powerup 功能（一個內置的教程引導）其實違背了他們最初「產品應該直覺到不需要教程」的原則。但功能實在太多了，用戶確實需要有人告訴他們：這一百個功能裏，哪十個是必須用的。
08問模型為什麼犯錯
Kat 分享了一個做 AI 產品的獨特技巧：讓模型自己反思它的行為。
比如她發現模型改了前端代碼後會跑測試，但……就是不會真的打開頁面看一眼 UI。她就問模型：你為什麼不檢查 UI 呢？
模型的回答有時候會讓人意外：
“ 有時候模型會說，system prompt 裏的某段話讓它產生了困惑。有時候它會說，我把驗證任務委派給了 sub-agent，但 sub-agent 沒做，而我也沒有檢查它的工作。
這些反饋，則直接指向了 harness 層面的改進方向。
09“ 對模型的決策保持好奇心，問它為什麼做出了那個選擇，你就能看到是什麼誤導了它，然後修復 harness 來填補這個空隙。
50 個 Claude 並行
聊到未來的路線圖，Kat 把產品演進拆成了幾個階段，像搭積木一樣：
第一步：單個任務成功。給一個清晰的 prompt，模型能不能穩定地輸出可以合併的代碼或者可以分享的文檔？
第二步：多任務並行。2025 年底 multi-coding 就已經開始火了。目前用戶大概同時跑 6 個 Claude。
第三步：50 到幾百個 Claude 同時跑。到那時候，本地機器的內存肯定是不夠用了，任務得跑在遠端。界面需要告訴你哪些任務需要你看一眼，而且模型應該能自己驗證工作，這樣你看到「已完成」的時候可以放心地信任它。
10“ 而且這個過程要能自我改進。你給了一次反饋，模型在之後的每次運行中都不會再犯同樣的錯誤。
Just do things
Kat 的人生座右銘是：Just do things。
“ 工作本來就是假的。如果你理解了約束條件，你就能想出該做什麼，然後就去做。快速行動，從錯誤中學習，如果做錯了就道歉並修復。
這話放在 Anthropic 的語境下不難理解：她說很多公司裏角色界限分明，PM 做 PM 的事，工程師做工程師的事。
而 Anthropic 鼓勵的是跨界：你看到一個問題，不用管它屬於誰的地盤，直接解決它。
11別停在 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