據彭博社最新報道，截至今年7月底，Anthropic的年化營收執行率已突破650億美元，相比2025年底約90億美元的水平，在7個月內增長超7倍。剛剛結束的二季度，Anthropic初步收入超過115億美元，同比增幅達14倍，並首次實現營業利潤轉正。在前沿模型公司普遍依賴鉅額融資、持續消耗算力的階段，這是一條罕見的增長曲線。

推動增長的當然有Claude模型本身，但模型能力並不會自動轉化為收入。過去幾年，Anthropic一面推進前沿模型能力，一面推出Claude Code、MCP、Cowork等帶有新品類意味的產品。這家公司常常能在模型跨過能力閾值後，迅速找到釋放能力的產品形態，並實現商業化。這很難歸因於幾次偶然的產品判斷。畢竟，押注Coding的公司並不少，Anthropic卻率先把前沿模型變成了可用、可驗證的產品，並跑出了複利。

特殊崗位連線研究與產品

要理解這些問題，可以從Anthropic內部一種特殊的崗位說起。Dianne Penn是Anthropic第一位技術產品經理，她在2023年加入，公開使用過的職務名稱包括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需要把這些判斷帶回研究、產品和工程團隊。

從使用者反饋到訓練目標

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則把產品目標變成可測試的輸入、理想輸出和通過條件。研究團隊用它比較訓練方法，產品團隊用它驗證問題是否解決，模型釋出團隊則用它防止能力退步。產品願景由此進入研究和訓練管線，幾支團隊也有了討論問題的共同尺度。

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”——模型已經擁有潛在能力，市場上卻沒有合適的產品把它釋放出來。

Claude Code的原型與演進

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官方介紹，它既是一款產品，也是一套收集真實工作流反饋的研究工具。

Cowork：10天做出新品類

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的改進。

下一代模型：能力軸而非功能清單

在傳統軟體公司裡，路線圖通常長得很具體——下個季度上線什麼功能、哪個版本改哪個介面、哪些需求排進下一次釋出。Dianne Penn表示，Anthropic並不會從具體的版本和功能開始規劃。團隊會先把版本號暫時放到一邊，設想一個更遠的場景：如果Claude最終真的能夠承擔某項工作，它應該會做什麼？這張想象中的規劃圖，則會由一條條能力軸組成。

Dianne用整理日曆來說明這種區別。要替使用者重排工作日曆，Claude必須先讀懂頁面和日程，理解會議內容，發現時間衝突，判斷哪些會議可以移動。如果過程中出現新的衝突，還要及時調整原計劃。因此，“重排日曆”並不是一項孤立功能，而是視覺識別、語言理解、工具呼叫、錯誤恢復等能力共同作用的結果。內部討論的重點，不是“把日曆功能放進哪個版本”，而是判斷這些基礎能力的成熟度。如果當前模型已經接近目標，剩餘缺口或許可以通過增加資料、強化學習和後訓練補齊；如果模型只能完成其中很小一部分，問題可能仍在基礎研究或訓練方法層面。

Anthropic的產品、工程和研究團隊會共同判斷能力缺口，再決定下一步是補充資料、開展強化學習，還是回到更底層的研究。Alex Albert用了一個很不軟體工程的詞來形容Anthropic打造模型的過程——“培養”。Alex也是Anthropic的一名技術研究產品經理。他提到，即使團隊已經決定了訓練設定、技術路線和模型架構，也只能對結果形成直覺。模型進入訓練後，才會逐漸顯露出擅長與不擅長的領域，有時還會出現未被預料的行為。它不是按照圖紙組裝出來的功能，更像一個在訓練環境、反饋訊號和約束條件下成長的複雜系統。因此，Research PM必須從模型構思階段就進入流程。Alex不能等模型訓練完成後再尋找市場，而要在訓練開始前參與定義“模型需求”。

與此同時，每一代模型還要解決上一代暴露的問題。團隊既要思考“希望模型具備什麼能力”，也要不斷確認“它實際上長成了什麼樣”。Research PM的視野還必須跨越所有產品介面。同一個底層模型，進入Claude.ai、API、Claude Code和Cowork後，會獲得不同的系統提示、工具、上下文和工作方式，最終表現也可能截然不同。Anthropic打造的並不是一顆孤立的模型，而是模型與執行環境組成的完整系統。

Co-design Loop：模型與產品共同演進

支撐模型與產品協同創新的，不只是一組特殊崗位和工作流程，還有Anthropic的文化理念。AI大幅降低了原型成本。一個想法不必先爭取完整團隊和大筆資源，而是可以先做出來，交給同事使用，再根據真實行為判斷是否值得繼續。Anthropic內部極為重視這種“原型文化”。除了產品和工程團隊，研究、銷售、招聘等部門的員工，也會主動搭建各種工具原型。Alex用“讓千朵花綻放”形容這種文化。原型也是觀察模型能力的一種方法。模型在研究實驗中獲得新能力，被內部員工迅速放進新的工具、流程和場景。那些真正有用的原型會吸引更多人使用，暴露出實驗室裡難以預料的用法和失敗，併為下一輪產品與模型改進提供訊號。Claude Code從個人工具走向內部流行，再成為正式產品，就是這種文化最典型的結果。

產品進入真實世界後，另一個問題隨之出現：反饋規模遠遠超過人工處理能力。Anthropic顯然很重視使用者反饋。數以百萬計的使用者通過不同渠道使用Claude。如果只靠產品經理逐條閱讀，反覆出現的問題很容易被情緒表達、偶發故障和語境差異淹沒。Alex提到，如今他們更多地使用Claude分析關於Claude的反饋。團隊先讓模型對大量反饋進行分組和聚類，找出反覆出現的主題，再把零散問題抽象成可以診斷的失敗型別。有時，幾十個案例已經足以證明某種缺陷穩定存在。它們未必能精確代表線上總體失敗率，卻能揭示出值得關注的模式。這種“用模型改進模型”的迴圈，正是Anthropic能夠快速迭代的關鍵。

評論視角

鈦媒體這篇文章通過深流研究所的視角，拆解了Anthropic的增長邏輯。作者認為，Anthropic的成功並非偶然，而是源於一套將研究與產品緊密結合的機制。從設立研究產品經理崗位，到將使用者反饋轉化為訓練目標，再到通過原型文化快速迭代產品，Anthropic構建了一個“模型與產品協同演進”的閉環。這種模式使得Anthropic能夠在模型能力突破後，迅速找到商業化路徑，從而在競爭激烈的AI市場中脫穎而出。文章也指出，Anthropic的路徑並非唯一，但它的實踐為行業提供了有價值的參考：如何將前沿研究轉化為可用的產品，並實現商業上的複利效應。