拆解Anthropic：押注 coding 的公司很多，為什麼它先吃到複利？

深流研究所2026.08.20 17:05 · 來自北京全文6931字模型與產品，如何協同演進？文 | 深流研究所，作者 | 吳絳楓據彭博社最新報道，截至今年7月底，Anthropic年化營收運行率已經突破650億美元。與2025年底約90億美元的水平相比，這一數字在7個月內增長超7倍。剛剛結束的二季度，Anthropic初步收入也已超過115億美元，同比增幅達到14倍，並首次實現營業利潤轉正。在前沿模型公司普遍依賴鉅額融資、持續消耗算力的階段，這是一條罕見的增長曲線。推動增長的當然有Claude模型本身，但模型能力並不會自動轉化為收入。

過去幾年，Anthropic一面推進前沿模型能力，一面推出Claude Code、MCP、Cowork等帶有新品類意味的產品。這家公司常常能在模型跨過能力閾值後，迅速找到釋放能力的產品形態，並實現商業化。這很難歸因於幾次偶然的產品判斷。畢竟，押注 Coding 的公司並不少，Anthropic 卻率先把前沿模型變成了可用、可驗證的產品，並跑出了複利。它是怎麼做到的？1、在研究和產品之間，Anthropic設置了一種特殊崗位要理解這些問題，可以先從Anthropic內部一種特殊的崗位說起。Dianne Penn是Anthropic第一位技術產品經理。

她在2023年加入Anthropic，公開使用過的職務名稱包括Head of Product for AI Research and Labs、Head of Product for Research and Labs，以及 Head of Research Product Management。這些說法雖有差異，卻都指向一個特殊的交叉點：一端進入AI Research，跟進模型研究團隊的工作；另一端連接產品實驗室Labs，用原型探索新能力可能長出什麼產品。在傳統軟件公司，技術地基相對穩定，產品經理可以圍繞明確需求規劃功能。但在前沿模型公司，這塊地基每隔幾個月就可能改變。

今天做不到的產品，下一代模型可能突然做到了；當下為彌補模型缺陷搭建的複雜流程，半年後也可能成為限制新模型的腳手架。Dianne和團隊的核心工作，正是研究和管理這種不確定性：實驗室裡剛出現的能力，哪些已經接近可用？用戶說“Claude不好用”，缺的是模型、工具、界面，還是工程基礎設施？當用戶拿Claude完成團隊未曾設想的任務時，那是偶然技巧，還是一種新的產品可能？Dianne需要把這些判斷帶回研究、產品和工程團隊。2、如何把用戶的一句「不好用」，變成模型的訓練目標？2023年7月，Claude 2上線後的一次bug排查，初步展示了這套工作方式如何運轉。

當時，用戶頻繁抱怨Claude 2“不太會遵循指令”。這個反饋看似嚴重，卻無法直接指導模型研究。用戶不會區分問題來自預訓練、後訓練、還是系統提示、或者工具調用。他們只能描述任務沒有完成。Dianne和團隊開始閱讀用戶授權分享的失敗軌跡，追問任務究竟在哪一步停下。沿著案例向下查，他們發現，在早期這類投訴中，大約80%都指向一個具體得近乎瑣碎的問題：Claude無法穩定輸出正確的JSON。少一個括號，API就會拒絕請求。字段不符合schema，工具調用便無法解析。對聊天機器人而言，這些只是格式錯誤；對需要連續調用工具的Agent而言，它意味著工作流會在第一道接口處斷掉。

團隊從真實失敗中收集了約30—40個案例，逐一寫清輸入、理想輸出和通過條件，把它們變成一組可以重複運行的eval。此後，Claude每一代模型都要重新接受測試。按照Dianne在公開採訪中的講述，這組評測如今已達到接近99.9%—100%的通過率，JSON格式遵循也不再是主要投訴。Anthropic沒有把這些反饋停留在投訴歸類層面。團隊把模糊的“不好用”還原為具體任務軌跡，定位可復現的失敗，再將失敗案例寫成可重複運行的eval。這些評測由研究與產品團隊共同維護，逐漸成為模型能力的一部分規格。Dianne常說：“Evals are the new PRDs。

”傳統PRD可以描述功能，卻很難精確定義一個概率系統應該如何行動；eval則把產品目標變成可測試的輸入、理想輸出和通過條件。研究團隊用它比較訓練方法，產品團隊用它驗證問題是否解決，模型發佈團隊則用它防止能力退步。產品願景由此進入研究和訓練管線，幾支團隊也有了討論問題的共同尺度。3、從用戶行為到訓練方向，Coding 如何成為戰略重點？2023年末，Dianne和團隊又注意到一種變化。過去，人們使用代碼模型，主要是補一行代碼、寫一個函數，或者解釋一段程序。後來，越來越多用戶開始要求Claude一次生成更長、更完整的代碼，甚至把一整段編碼任務交給模型。

沒有人直接要求Anthropic“做一個agentic coding產品”，但用戶已經改變了自己的行為。對此，Dianne和團隊需要判斷：這種變化究竟是噪聲，還是真實存在的場景需求。Dianne回憶，預訓練、推理、研究和產品團隊會一起討論，這種能力改善是否穩定，哪些失敗需要進入評測，併成為下一代模型要解決的問題。在Dianne 看來，編程尤其適合形成這樣的反饋閉環。代碼能否運行、測試能否通過、改動是否破壞現有系統，通常都有明確結果。與許多開放式知識任務相比，coding更容易同時成為產品場景、訓練方向和評測環境。

發現這類用戶行為，Anthropic 把長代碼生成提升為 Claude 3 系列及後續模型的重點能力方向。Anthropic沒有披露具體訓練配方，但可以確認的是，coding獲得了更高優先級。團隊建立了更貼近長任務的評測，並在模型測試和發佈判斷中更加重視它。2024年3月，Claude 3 Opus發佈。Coding開始成為Claude區別於其他模型的一項用戶認知，並吸引了一批早期開發者和Claude擁護者。三個月後，Claude 3.5 Sonnet發佈，coding能力進一步增強。Anthropic官方說明，Claude 3.

5 Sonnet將內部agentic coding評測的成績從38%推高至64%；獲得工具後，模型已經可以編寫、編輯、執行和排查代碼。模型的角色開始從代碼生成器變成軟件工程協作者。但用戶仍要手動搬運代碼庫上下文、複製結果、執行命令，再把報錯貼回聊天框。Dianne把這種狀態稱為“product overhang”——模型已經擁有潛在能力，市場上卻沒有合適的產品把它釋放出來。4、先做出原型，再讓真實使用決定產品去留Claude Code的出現，填補了這段空白。2024年下半年，Boris Cherny加入Anthropic Labs團隊。

為了熟悉公司的公開API，他給自己寫了一個極小的終端聊天程序：先給模型接上bash，後來又增加文件編輯能力，用Sonnet 3.5不斷測試。這就是Claude Code最初的原型。兩天後，Boris把原型發給同事試用。第二天，他發現坐在對面的工程師已經用它寫起了代碼。Boris沒有推動正式的內部部署，只發過一篇介紹帖，工具卻在工程師之間口口相傳。在一次內部產品評審會上，看到日活曲線近乎垂直增長，Anthropic創始人Dario發出質問，他們是不是在強迫員工使用。最初約三個月，Claude Code基本由Boris一人推進。

它的許多重要功能，並不是團隊在會議室裡提前規劃出來的，而是用戶先用自己的辦法補足產品缺口。有人會寫一個Markdown文件，記錄項目結構、編碼規範、測試命令和注意事項，要求Claude每次先閱讀；另一些用戶則反覆提醒Claude：“先不要寫代碼，先討論思路，給我一個計劃。”當這些行為反覆出現，團隊便把它們從提示技巧收攏為正式產品能力：前者成為CLAUDE.md，後者發展為Plan mode。Claude Code在內部迅速普及後，Anthropic還面臨一個選擇：是否把它保留為內部生產力優勢？

Boris主張將它開放出去，因為實驗室裡的合成eval雖然可以控制變量，卻無法還原模型進入真實代碼庫後會發生什麼。2025年2月，Claude Code以研究預覽版推出。Anthropic官方介紹，它既是一款產品，也是一套收集真實工作流反饋的研究工具。5、只用10天，Anthropic為什麼就能做出Cowork？Claude Code發佈後，Boris不斷看到用戶拿它做與編程無關的事。有人用它規劃旅行、整理郵件和製作幻燈片，也有人讓它從損壞的硬盤中找回照片，或接入攝像頭和家用設備。這些人並不關心Claude寫了多少代碼。代碼只是Agent為完成任務臨時使用的工具。

他們真正需要的，是把目標和資料交給Claude，讓它自己查找信息、編寫腳本、調用工具，最後交付結果。甚至一些沒有編程經驗的用戶，也開始主動學習這個有門檻的編程工具。到2025年末，Anthropic內部已有多個團隊探索如何讓Claude從回答問題走向執行任務，也積累了桌面應用、虛擬機、規劃工具、Skills和一批未公開的原型。真實的用戶信號讓團隊意識到，通用知識工作Agent的需求已經出現，發佈時機也逐漸成熟。Boris提出，可以把這些組件與Claude Code組合起來，做一個非程序員也能使用的版本。他們希望儘快做出這款產品的原型。

負責Claude桌面產品的Felix Rieseberg和一個小團隊開始趕工。他們沒有重新開發一套Agent，而是直接複用Claude Code的agent harness，再把此前散落在不同團隊裡的組件組裝起來。每名工程師會同時運行3—8個Claude Code Agent：一個開發界面，一個處理後端邏輯，一個調研技術方案，其他Agent則修復內部用戶剛剛在Slack裡報告的問題。工程師主要負責劃分任務、作出產品決策和驗收結果。10天后，Cowork完成開發。但它並非在10天裡憑空誕生：此前一年多積累的模型能力、Claude Code的Agent能力、各團隊做過的原型和基礎設施，都已經就位。

團隊只是等到能力與需求同時越過閾值，把它們收攏成了一款產品。Cowork也以研究預覽版發佈。它把Claude帶進了比代碼庫更模糊的工作環境：模型不僅要調用工具，還要理解不夠明確的要求，判斷何時詢問用戶，並交付真正可用的文檔、表格和演示文稿。由此形成的真實用例、暴露的失敗，也會反饋給下一輪模型、工具和agent harness的改進。6、Anthropic 如何規劃下一代模型？在傳統軟件公司裡，路線圖通常長得很具體——下個季度上線什麼功能、哪個版本改哪個界面、哪些需求排進下一次發佈。Dianne Penn表示，Anthropic並不會從具體的版本和功能開始規劃。

團隊會先把版本號暫時放到一邊，設想一個更遠的場景：如果Claude最終真的能夠承擔某項工作，它應該會做什麼？這張想象中的規劃圖，則會由一條條能力軸組成。Dianne 用整理日曆來說明這種區別。要替用戶重排工作日曆，Claude 必須先讀懂頁面和日程，理解會議內容，發現時間衝突，判斷哪些會議可以移動。如果過程中出現新的衝突，還要及時調整原計劃。因此，“重排日曆”並不是一項孤立功能，而是視覺識別、語言理解、工具調用、錯誤恢復等能力共同作用的結果。內部討論的重點，不是“把日曆功能放進哪個版本”，而是判斷這些基礎能力的成熟度。

如果當前模型已經接近目標，剩餘缺口或許可以通過增加數據、強化學習和後訓練補齊；如果模型只能完成其中很小一部分，問題可能仍在基礎研究或訓練方法層面。Anthropic 的產品、工程和研究團隊會共同判斷能力缺口，再決定下一步是補充數據、開展強化學習，還是回到更底層的研究。Alex Albert用了一個很不軟件工程的詞來形容Anthropic打造模型的過程——培養。Alex 也是Anthropic的一名技術研究產品經理。他提到，即使團隊已經決定了訓練設置、技術路線和模型架構，也只能對結果形成直覺。模型進入訓練後，才會逐漸顯露出擅長與不擅長的領域，有時還會出現未被預料的行為。

它不是按照圖紙組裝出來的功能，更像一個在訓練環境、反饋信號和約束條件下成長的複雜系統。因此，Research PM 必須從模型構思階段就進入流程。Alex 不能等模型訓練完成後再尋找市場，而要在訓練開始前參與定義“模型需求”。與此同時，每一代模型還要解決上一代暴露的問題。團隊既要思考“希望模型具備什麼能力”，也要不斷確認“它實際上長成了什麼樣”。Research PM 的視野還必須跨越所有產品界面。同一個底層模型，進入 Claude.ai、API、Claude Code 和 Cowork 後，會獲得不同的系統提示、工具、上下文和工作方式，最終表現也可能截然不同。

Anthropic 打造的並不是一顆孤立的模型，而是“模型與運行環境”組成的完整系統。7、Co-design Loop：如何讓模型與產品共同演進？支撐模型與產品協同創新的，不只是一組特殊崗位和工作流程，還有Anthropic的文化理念。AI大幅降低了原型成本。一個想法不必先爭取完整團隊和大筆資源，而是可以先做出來，交給同事使用，再根據真實行為判斷是否值得繼續。Anthropic內部極為重視這種「原型文化」。除了產品和工程團隊，研究、銷售、招聘等部門的員工，也會主動搭建各種工具原型。Alex用“讓千朵花綻放”形容這種文化。原型也是觀察模型能力的一種方法。

模型在研究實驗中獲得新能力，被內部員工迅速放進新的工具、流程和場景。那些真正有用的原型會吸引更多人使用，暴露出實驗室裡難以預料的用法和失敗，併為下一輪產品與模型改進提供信號。Claude Code從個人工具走向內部流行，再成為正式產品，就是這種文化最典型的結果。產品進入真實世界後，另一個問題隨之出現：反饋規模遠遠超過人工處理能力。Anthropic顯然很重視用戶反饋。數以百萬計的用戶通過不同渠道使用Claude。如果只靠產品經理逐條閱讀，反覆出現的問題很容易被情緒表達、偶發故障和語境差異淹沒。Alex提到，如今他們更多地使用Claude分析關於Claude的反饋。

團隊先讓模型對大量反饋進行分組和聚類，找出反覆出現的主題，再把零散問題抽象成可以診斷的失敗類型。有時，幾十個案例已經足以證明某種缺陷穩定存在。它們未必能精確代表線上總體失敗率，卻能把“感覺它不太行”變成“這個行為可以被複現和驗證”。這形成了一個看似奇特的循環：Claude幫助產品經理分析Claude，生成測試Claude的問題，甚至輔助評估Claude的回答。但模型不會因此自動決定產品路線。聚類是否合理、失敗是否真正影響用戶、樣本是否貼近真實任務，以及問題是否值得佔用昂貴的訓練資源，仍然需要產品經理和研究人員作出判斷。

原型越多，模型能力被發現得越早；真實使用越深入，反饋越具體；eval越貼近任務，下一輪訓練越有方向。模型與產品由此不再彼此等待，而是在同一個co-design loop中共同演進。如今，這套循環，正在更多 AI 公司內部轉動起來。比如，姚順雨加入騰訊後，著力推動模型與產品 Co-design，讓模型研發更貼近真實需求。這一思路已在 Hy3 和 WorkBuddy 上初見成效：Hy3在WorkBuddy 首發上線後，自選模型用戶中選擇Hy3的佔比達到60%。調用量增長帶來更多真實反饋，推動 Hy3 持續迭代。更強的模型能力，又進一步改善了 WorkBuddy 的體驗。

類似的轉變也發生在馬斯克的 AI 版圖中。核心團隊流失、產品落地不暢，曾讓 xAI 陷入低谷，馬斯克也坦言要“從地基開始重建”。Cursor 的加入成為轉折點。它補上了真實任務入口，也讓 SpaceX AI 跑通開發者反饋、模型訓練與產品驗證的閉環。AI 產業最早比的是理論突破與技術路線，隨後比的是算力規模與數據質量。下一階段，勝負或許更多取決於——產品與模型的齒輪能否真正咬合，循環能否轉得足夠快，以及每一次循環，能否成為下一次加速的複利。