Latent Demand：Claude Code 和 Cowork 背後的產品心法，以及為什麼你不該框住 AI

本文整理自 Lenny's Podcast 2026 年 2 月播出的單集。

{{< youtube We7BZVKbCVw >}}

{{< spotify "episode/1bx2B9lDhiujXPU2u20AAX" >}}

{{< apple-podcast "tw/podcast/head-of-claude-code-what-happens-after-coding-is/id1627920305?i=1000750488631" >}}

---

去年 5 月的某天早上，Anthropic 的 Claude Code 負責人 Boris Cherny 走進辦公室，看到資料科學家 Brendan 的電腦螢幕上開著一個終端機視窗。Brendan 不是工程師，平常根本不會碰 terminal。但他不知道怎麼搞的，自己下載了 Node.js、裝好 Claude Code，然後在終端機裡面做 SQL 分析。

Cherny 嚇了一跳。一個終端機工具，連很多工程師都嫌麻煩不想用，結果一個非技術人員自己摸索著裝好了，還在上面跑數據查詢。一週之後，整個資料科學團隊都在做一樣的事。

這個場景，就是 Cherny 口中「latent demand」的完美範例。

Latent Demand：觀察「濫用」，然後為它做產品

Latent demand 的概念很直白：當使用者用你的產品去做它原本不是設計來做的事情時，這就是一個強烈的信號，告訴你應該為那個用途做一個專門的產品。

Cherny 用 Facebook Marketplace 的起源來說明。大約 2016 年左右，Facebook 的產品團隊發現一件事：Facebook 社團裡 40% 的貼文都是在買賣東西。沒有人設計社團來做這件事，但使用者硬是把它變成了一個交易平台。貼照片、寫價格、留言說「我要」、私訊談細節。流程笨拙，但需求擋不住。

Facebook 先做了買賣社團（讓這個行為更順暢一點），然後做了 Marketplace（一個專門的產品）。結果大家都知道了。Facebook Dating 的誕生也是類似的路徑：60% 的個人資料瀏覽來自非好友、異性使用者。數據在那邊，只要你願意看。

Claude Code 和 Cowork 的關係完全符合這個模式。過去六個月，越來越多非技術使用者拿 Claude Code 來做跟寫程式毫無關係的事。有人用它來種番茄（認真的），有人用它分析自己的基因組數據，有人用它從損壞的硬碟裡救回婚禮照片，還有人用它來看 MRI 影像。這些人跳過了重重障礙去使用一個終端機工具，只因為 AI agent 的能力太好用了。

Cherny 和團隊看到這個現象後，決定做一個讓非技術人員也能用的 agent 產品。這就是 Cowork 的由來。

10 天造出 Cowork

Cowork 的開發故事本身就是一個產品案例。團隊花了幾個月探索各種方向，嘗試了很多不同的選項。最後有人說了一句：不然我們就直接把 Claude Code 放到桌面 App 裡？

就這樣，用 Claude Code 本身來開發，10 天就做完了。這個產品上線後的表現比 Claude Code 當初好得多，幾乎是立即爆紅。Cherny 認為這是因為 latent demand 已經被充分驗證過了。Claude Code 花了好幾個月才被大家搞懂，但 Cowork 的需求在它出生之前就已經存在。

Cowork 裡面有一套完整的安全機制，包括一個虛擬機器來隔離 agent 的操作。這些安全元件全部都是 Claude Code 寫的。10 天、全部由 AI 寫、包含複雜的安全架構，Cherny 用這個故事來說明「寫程式已被解決」不只是修辭。

值得一提的是，Lenny Rachitsky（節目主持人）之前寫過一篇 50 個非技術用例的文章，Anthropic 的 PM 拿那篇文章作為 eval 的基準。當 Cowork 能完成 50 個用例中的 48 個時，團隊判斷它可以上線了。Lenny 聽到自己成了一個 eval 基準時的反應非常有趣。

第二層 Latent Demand：觀察模型想做什麼

Cherny 在訪談中提出了 latent demand 的一個進化版本。傳統的做法是觀察使用者想做什麼，然後為他們做產品。但在 AI 時代，還有第二層：觀察模型想做什麼，然後讓它更容易做到。

他解釋，很多人在開發 LLM 應用時，會先設計一個嚴格的工作流程，然後把模型塞進去。第一步做什麼、第二步做什麼、第三步做什麼，配上一個精密的 orchestrator 來控制流程。Claude Code 的做法完全相反。團隊把模型當作產品的核心，給它最少的工具、最少的 scaffolding，讓它自己決定怎麼使用工具、按什麼順序操作。

Cherny 用「on distribution」這個研究用語來描述這個概念：你想看模型在自然狀態下會做什麼，而不是強迫它走你設計好的路線。在產品開發的語言裡，這就是 latent demand，只不過對象從使用者變成了模型。

這個思維的實際意義是：如果你的 AI 產品需要大量的 scaffolding 才能正常運作，你可能走錯了方向。一年前也許還需要那些腳手架，但現在的模型已經不需要了。

Bitter Lesson：永遠押注更通用的模型

Cherny 在 Claude Code 團隊內部推崇一個概念：Rich Sutton 十幾年前寫的 "The Bitter Lesson"。核心觀點很簡單，更通用的模型長期來看一定會打敗更專用的模型。

Sutton 當初是在自駕車等領域的語境下講這件事，但 Cherny 認為這個道理在 AI 產品開發中有非常多推論。他列舉了幾個：不要花太多精力去 fine-tune 小模型，不要做太多 scaffolding，不要建複雜的 orchestration workflow。這些東西也許能把當前模型的表現提升 10% 到 20%，但下一個模型出來的時候，這些增益通常就被抹平了。

更務實的做法是：用最強的通用模型、給它工具和目標、讓它自己想辦法。如果你有那個彈性，就押注更通用的模型，然後等下一代出來自然解決你現在解決不了的問題。

這聽起來像是叫大家不要做事、等就好了。但 Cherny 要表達的其實是一個產品策略的選擇：你的工程資源是有限的，與其把時間花在可能被下一個模型淘汰的 workaround 上，不如把時間花在理解使用者需求、設計更好的工具界面這些不會被淘汰的事情上。

給工程師無限 Token，別太早優化成本

Cherny 經常跟其他公司的技術主管聊天，他給的建議一致而明確：一開始不要限制 token 用量。給工程師足夠的額度讓他們自由實驗，最瘋狂的創新往往就是從不受限的探索中冒出來的。

他承認 Anthropic 內部有些工程師每個月的 token 消耗達到「六位數美元」的水平。但他的邏輯是：相對於工程師的薪資，一個人的 token 實驗成本其實不算高。當某個實驗真的跑出有價值的結果、需要規模化時，那才是該開始優化成本的時候。用 Haiku 或 Sonnet 替代 Opus，用 prompt 工程降低 token 消耗，這些都是之後的事。

他也提到一個有趣的趨勢：一些公司已經開始把「無限 AI token」當作一種員工福利，跟免費午餐、健身房會員放在同一個類別。這在兩年前完全無法想像。

我的觀察

Latent demand 作為一個產品框架，其實不新。但 Cherny 把它延伸到「觀察模型想做什麼」這一層，確實是一個值得注意的新維度。傳統的產品開發是以人為中心的：觀察使用者行為、理解使用者需求、為使用者設計。AI 時代多了一個對象：模型本身也有「行為傾向」，你可以順著它的傾向去設計產品，而不是硬把它塞進一個預設的框架裡。

Bitter Lesson 的啟示對臺灣的 AI 新創團隊尤其重要。過去兩年，很多團隊花了大量時間在 prompt engineering、RAG pipeline、fine-tuning 上面，這些確實帶來了改善。但如果每次模型升級都會把你辛苦做的 workaround 變得多餘，你就得重新思考時間投入的配置。這不是說這些技術沒價值，而是你得區分哪些投入是持久的（使用者介面、領域知識、資料整理），哪些是暫時的（特定模型的 prompt 技巧、scaffolding）。

10 天造出 Cowork 這個故事還有另一層意義。它說明了當你的 latent demand 訊號夠強的時候，產品開發的速度可以快到讓傳統的產品管理流程顯得荒謬。不需要三個月的需求訪談、六個月的開發週期、兩個月的測試。需求已經在那裡了，使用者已經在用笨辦法解決了，你只要做一個不那麼笨的版本就好。