Cowork

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• China, Open Source & AI Competitiveness — Andrew Ng
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• The Founder's Playbook: Building an AI-Native Startup

摘要#

Anthropic 的知識工作代理產品，也是 Claude Code 的姊妹產品。Claude Code 面向產出為程式碼的工作；Cowork 則面向產出為非程式碼的工作：簡報、收件匣分類、客戶資料檔、上市文件、會議準備。產品由 Cat Wu 共同領導。

定位（Cat Wu 的說法）#

• Claude Code（CLI） — 一次性的程式設計任務；CLI 最先取得新功能；「所有工具中最強大的」
• Claude 桌面版／IDE 中的 Claude Code — 需要預覽窗格的前端工作；較適合不熟悉終端機的非技術使用者
• Claude Code 行動版／網頁版 — 在 AFK 狀態下啟動任務；推出前是「缺少的產品」——有人會在戶外把筆電連到手機上
• Cowork — 任何產出不是程式碼的工作

Cat Wu 如何使用#

連結 Google Calendar、Slack、Gmail、Google Drive——「脈絡越多越好」。一種工作流程是：晚上把大綱草稿和相關的 Twitter／上市籌備室連結交給 Cowork，隔天早上回來就有一份精修過的 20 頁簡報，再給一輪意見繼續調整。系統載入了 Anthropic 的設計系統，因此簡報看起來就像出自設計師之手。

人們為何使用它（據 Cat Wu 所述）#

「Applied AI」團隊是內部第二大 token 使用者，僅次於工程團隊；他們使用 Cowork 來：

• 準備客戶會議（「資料檔」工作流程：整理昨天的問題、行動項目，以及 ETA 研究）
• 清空收件匣／Slack 待處理項目
• 制定上市計畫、撰寫內部文件，以及從 Salesforce、Gong 和 Slack 擷取資料製作客製化簡報

與 Anthropic 整體路線圖的關聯#

• Boris Cherny 將 Cowork 視為整合通用 MCP 與電腦操作的場域——使用與 Claude AI 相同的 MCP 連接器，也運用 Anthropic 在電腦操作方面的領先能力，支援沒有 MCP 的軟體（Opus 4.7 的表現「相當不錯」）。
• 「公司裡已經沒有任何手寫程式碼了」——Cowork 涵蓋這項說法中的非程式碼部分（SQL、簡報、營運文件全都由模型生成）。

創辦人手冊中的定位（2026 年 5 月）#

The Founder's Playbook 將 Cowork 定位為 AI 原生新創公司各階段的營運層：

• 構想階段 — 自動化客戶聯繫與排程。Cowork 使用已驗證的目標客群輪廓來研究潛在客戶、撰寫個人化聯繫內容、透過 MCP 連接 Gmail／Calendar、管理郵件往來，並在第 7 天追蹤。
• MVP 階段 — 管理回饋迴路的後勤工作：聯繫早期使用者、安排回饋訪談、以結構化方式收集錯誤與功能需求，以及每週彙整。
• 上市階段 — 在營運層面取代創辦人親自投入注意力：盤點創辦人的例行任務，分類為可自動化、可委派或只能由創辦人處理，並為適合自動化的任務建立工作流程邏輯。PM 作業系統包括排定衝刺、分流錯誤，以及每週彙整指標。
• 擴張階段 — 企業級營運：工單分派、升級處理工作流程、因產品變更而觸發的文件更新、續約追蹤及定期報告。另包含 GTM 戰術執行：內容流程、外展序列、分析師簡報後勤，以及 CRM 資料維護。

手冊的說法是：Cowork 加上 Claude Code，能讓「小型團隊擁有大型組織的支援能力」。手冊也特別提到 Skills，指出它們能把創辦人反覆使用的工作流程整理成規範。

反事實情境：OpenAI 沒有拆分產品（2026 年 7 月）#

Cowork 的存在代表一項押注——程式設計代理與知識工作代理之間自然的分界，在於產出是什麼。OpenAI 面臨同樣的問題（Codex 在非開發者之間的採用率開始加速），卻做出相反選擇：共用同一套 harness，Codex 與 ChatGPT Work 介面只有 git 狀態可見性、以差異為主的顯示方式，以及沙箱預設值有所不同。Akshay Nathan 給出的理由是角色界線正在消融，因此「試圖依照使用者是誰來劃出明確界線會很困難……我們不該把他們框住。」

請注意，兩者的分界並不完全相同：Cat Wu 的規則按產出類型劃分，避開了 Nathan 部分的質疑——但它仍要求使用者在知道任務會產出什麼之前先選擇介面。也請留意日期：本頁資料來自 2026 年 5 月，Nathan 的說法則是 2026 年 7 月，因此差距可能部分來自時間落差，而非意見分歧。雙方都沒有提出證據；應將其視為兩項仍在進行的產品押注。完整比較請見 Shared Harness, Differentiated Surfaces。

第三位加入者，採取第三條軸線：OpenWorker（2026 年 7 月）#

上一節將此類產品描述為兩種產品押注：Anthropic 依產出類型拆分，OpenAI 則保留單一 harness。在下方訪談前幾天，Andrew Ng 提出了第三種立場（China, Open Source & AI Competitiveness — Andrew Ng，practitioner-opinion）：與 Rohit Prasad 合作打造的 OpenWorker，是一款於 2026 年 7 月推出、開放原始碼且以本機優先的桌面代理。

重點在於，它沒有挑戰 Cowork 的論點，而是採納了這個論點。 Ng 對產品的描述幾乎就是 Cat Wu 的規則原話：「AI 不只是讓你聊天，而是真的替你做事……它可以產出完成且精修過的文件，而不是只給我可複製貼上的內容；它也可以真的替你寄出電子郵件，或在 Slack 傳送簡短訊息。」在桌面上產出完成的非程式碼工作，而不是只進行對話。

他採取的差異化軸線是所有權，而非分界，並明確表示不打算在能力上競爭：「我其實很看好 Claude 的 Cowork、ChatGPT……以及 Gemini Antigravity 這類工具，它們都很不錯——而 OpenWorker 是任何人都能使用的免費開放原始碼版本。」他增加的軸線是開放原始碼、本機運作，以及不受模型限制——這與他一貫的主張相符：應保留不同模型供應商之間的選擇空間，只是將這個原則往上套用到代理產品。如今這個類別有三種仍在進行的押注：依產出類型拆分（Cowork）、單一 harness 搭配各介面自己的 UX（OpenAI），以及採納相同論點，但拆開綑綁且不綁定特定模型（OpenWorker）。只有第三種能用供應商以外任何人都看得到的採用數據來驗證。

關鍵引言#

• （Cat Wu）「如果我在做的事情產出是程式碼，我會使用 Claude Code、桌面版，或行動版 Claude Code。如果產出不是程式碼，我就會用 Cowork。」
• （Boris Cherny）「我覺得 Claude design 是個很好的例子。現在已經相當不錯了，未來還會好上很多。」（他在談願景時，指的是 Cowork 這類產品。）

相關連結#

• Claude Code — 姊妹產品
• Shared Harness, Differentiated Surfaces — OpenAI 的反事實方案：以各介面自己的 UX 設計偏好共用同一套 harness，而不是依產出類型拆分產品
• Claude Design — 姊妹產品 Anthropic Labs；Cowork 的產出是簡報／文件，Claude Design 的產出則是視覺設計／原型；Boris Cherny 在此將 Claude Design 列為願景案例
• Cat Wu — 產品主管
• Boris Cherny — 將它列為投資領域
• Anthropic — 供應商
• Engineer PM Convergence — Cowork 加上 Claude Code，讓非工程職能也能實現「人人都寫程式」以及「人人都透過代理執行營運工作」
• AI Employee Framing — Cowork 的部署介面（Gmail、Slack、Calendar、Drive）正是決定如何採用「AI 作為員工」框架的場域；HBR 研究指出，採用何種框架會改變責任歸屬與審查品質
• Human-AI Accountability Redesign — 非程式碼代理的產出（簡報、資料檔、收件匣分類）缺乏編譯器／測試驗證，因此比 Claude Code 更需要重新設計責任歸屬，而非更不需要
• Agentic Misalignment (AM) — Cowork 式部署（長脈絡、使用工具、對個別行動的監督薄弱）正是 AM 評估的典型場景
• AI-Native Startup Lifecycle — Cowork 是創辦人四個階段的營運層
• Founder as Agent Orchestrator — Cowork 加上 MCP 整合，讓獨立創辦人能實際承擔代理編排者的角色
• Compounding Data Moat — Cowork 執行企業支援層的工作，讓工作流程的鎖定效應在 Scale 階段持續累積
• Conversation Artifacts — Cowork 的產出（簡報、資料檔、收件匣分類）屬於 AEI Cadences 報告分類的產物；Cowork 資料也被納入其中「Claude conversations」的整體描述
• Problem-Solution Fit Discipline — Cowork 在構想階段負責研究、審查訪談架構，以及訪談後彙整，構成驗證方法的營運層
• Fiona Fung — 負責 Cowork 的工程與產品（並共同負責 Claude Code）；她曾協助小型企業客戶導入 Cowork，親身感受導入過程的痛點（Dogfooding as Product Discipline）

待解決的問題#

• Cowork 類型的產出應採用什麼評估方法？Cat Wu 表示記憶功能很受益於評估；但簡報品質要如何衡量仍不清楚。

已解決問題#

• Cowork 的 harness 與 Claude Code 相比如何？兩者都提供 Skills、MCP、子代理，但非程式碼產出的失效模式不同（沒有測試套件、沒有編譯器，也沒有差異可供審查）。答案：沒有編譯器時如何驗證：Cowork 的 Harness 與 Claude Code 的比較，以及為何切片驗證器仍不可或缺——兩者使用相同的基礎功能，但驗證階梯相反，因此 harness 的防護重心重新分配：Claude Code 仰賴事後的確定性驗證器堆疊，既能捕捉錯誤，也能在合併前限制損害；Cowork 則改用判斷編碼（載入的設計系統最接近風格檢查器、evals／LLM 評審，以及決策檢查點上的人工審查），並讓動作前分類器閘門承擔關鍵防護，因為錯誤會直接進入線上 SaaS 狀態，中間沒有紅色測試攔截。失效模式分成明顯的（建置失敗）與隱晦的（一份看起來流暢、內容也沒問題的精美簡報——也就是「看似成功的失敗」），因此這裡更需要重新設計責任歸屬，而非更不需要。

延伸整理#

• 沒有編譯器時如何驗證：Cowork 的 Harness 與 Claude Code 的比較，以及為何切片驗證器仍不可或缺 — 與 Claude Code 的 harness 比較：非程式碼介面用什麼取代編譯器

資料來源#

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• The Founder's Playbook: Building an AI-Native Startup
• China, Open Source & AI Competitiveness — Andrew Ng — Andrew Ng，Washington Post Live（2026-07-29，practitioner-opinion）：上述 OpenWorker 段落。這是在訪談中推廣產品，不是評估——他肯定地提到 Cowork，卻沒有提供比較