為下一個模型而打造

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Designing with Claude: From prompt to production
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• OpenAI Codex lead on the new shape of product work

摘要#

這是 Harness Shrinkage as Models Improve 的產品策略推論，如今由三位 Anthropic 成員各自獨立表述：不要打造已經能運作的東西——製作幾乎能運作的東西，並押注下一個模型版本會補上差距。 Dan Carey 提供了最清楚的案例：Claude Design 上線時，團隊有一份問題清單，而這些問題「不是靠巧妙的工程解決……我們是靠 Opus 4.7 推出後解決的」。Boris Cherny 打造 Claude Code 時知道「它六個月內不會有 PMF，因為我們是在為下一個模型打造」。Cat Wu 將這種紀律表述為：「打造還不一定能運作的產品，這樣你才知道缺少什麼……然後有了最新模型，就可以直接替換進去」。由於模型快速進步，把工程力氣花在逼今日的模型做到下一季模型免費就能做到的事，都是浪費——「模型版本發布就像一股能托起所有船的潮汐」。

Carey 的表述（以及為何它最清楚）#

「你不會想要處理已經能運作的東西。你往往會想製作幾乎能運作的東西……下一個模型可能會直接修正那些無法靠工程解決的問題。我們在 Claude Design 上就遇到過這種情況……我們靠 Opus 4.7 推出後解決了它們。」

這是對這項押注罕見而具體的回顧式確認：一個具名產品（Claude Design）、一個具名模型（Claude Opus 4.7），以及一個明確結果（未解決的原型缺口由版本發布補上，而不是靠工程解決）。Boris 和 Cat 是從前瞻角度陳述策略；Carey 則展示了它如何奏效。

關鍵校準：是下一個模型，不是稻草人 AGI#

這項押注很容易被誤讀為「為某種想像中的超級 AI 打造」。Cat Wu 正是防範這種誤讀——她在自己的實體頁面上記錄的立場是「為當前模型打造」：「為超級 AGI 強模型打造產品非常容易。困難的是弄清楚，對當前模型而言，如何引出最大的能力？」這兩者可以整合成一條規則：

• 不要只為今日的模型打造 → 你會做得不夠，下一個版本一到，交付的東西就過時。
• 不要為遙遠未來的 AGI 稻草人打造 → 你會做過頭，交付依賴於不存在能力的空中樓閣。
• 為下一個具體版本（約為距今 ~6 個月的模型）打造 → 製作「幾乎能運作的東西」，把它作為研究預覽推出，讓下一個版本——一個你可以合理預測的版本——補上差距。

Carey 點出了原型所追求的目標：不是完整性，而是「那一絲魔法……某種未來可能變得完整的東西」。

OpenAI 方面的確認：相同形態、不同智慧（Ambrosino）#

Andrew Ambrosino 提供了第二個具體的回顧式案例——也是對這項押注最精準的表述。他對 Codex 應用程式的說法是：

「我非常確定，我們二月發布的 Codex 應用程式，如果十一月就準備好，絕對會在市場上失敗——唯一的差別就是十一月和二月之間的模型。完全相同的形態……它的結果只因幾個月的時機不同，就截然不同。」

他將其概括為**「相同功能、不同智慧、重新發布」模式**：Operator（在 ChatGPT 中）→ Atlas 中的代理模式 → Codex 裡的應用程式內瀏覽器，都是「本質上相同的功能」，而且「你可能需要把這個東西發布六次，才會真正運作——形態可能完全不變」。改變的是底層模型。因此他教導團隊不要固執——「不，這行不通，所以這是個糟糕的功能」是錯誤的解讀；「它可能只是還沒準備好」（可運作的版本是用來對照未來模型測試的產物，而不是可發布的成品）。

他警告的過度押注——「對當下而言太 AGI-pilled」。 Ambrosino 用一個異常坦率的跨供應商案例，指出校準另一側的失敗模式（下一節會警告的 AGI 稻草人）。最初的 Codex 網頁版本「給模型一項任務，它就離開去完成」——一種完全委派、AGI 形狀的產品形式——但「模型沒有把任務做得很好」。與此同時，Claude Code 問世時「完全在本機運作，沒有接上雲端……沒有假裝自己有那麼 AGI-pilled——它會問你問題，你不能直接把人生委派給它」，而且它「運作得好得多，因為那就是當時模型的能力所在」。他的教訓是：「我們對當下而言太 AGI-pilled 了。」這項押注必須根據模型實際所在的位置校準；讓互動形態符合當前能力，可能勝過押注模型尚未支援的委派。（這正是 Interaction Models 從互動設計角度描述的產品適配缺口。）

在模型不確定性下規劃（推論）#

同一套邏輯也會重塑路線圖。Ambrosino 說：「事情越接近短期，就越需要細節」——但九個月的計畫「必須非常模糊，因為你加入的任何精確度都是虛假的精確，而你只會浪費時間」。十一月規劃的任何事情「可能在十二月時仍然正確，但並不是實際發生的事」。因此，規劃變成在時間軸上預測模型能力：在他上一家公司，流程變成「列出所有我們感興趣的事、全部製作原型、決定哪些現在已經準備好、讓其他的放著醞釀，而每次模型有新的飛躍，就把那件事重新試一次並替換模型——因為功能是否好，取決於模型是否夠聰明，而不是它們的形態」。這就是由能力不確定性特別驅動的 planning-minimization。

為何這是苦澀教訓的推論#

這是 The Bitter Lesson 與 Harness Shrinkage as Models Improve 在產品側的表現：能力會在版本發布間遷移進入模型，因此為補償當前限制而建造的腳手架，是會折舊的資產。如果缺口屬於可隨規模擴展而消失的類型（推理、遵循指令、多模態保真度），用工程修補它，就是在打造一根很快便會刪除的拐杖。這項紀律是辨認哪些缺口屬於「等待模型」的缺口，哪些則是持久的 harness 工作（Harness Shrinkage as Models Improve 的但書：機械式驗證、安全性、品牌／角色不會向內遷移）。

必須維持的張力#

「製作幾乎能運作的東西」與 Problem-Solution Fit Discipline 的原型即證據陷阱直接衝突：快速原型證明的是打造可行，而不是問題真實存在。兩者的調和方式是：為下一個模型打造，關注的是能力風險（技術能到達那裡嗎？——可以，等它），而不是市場風險（有人想要這個嗎？——原型無法回答）。你仍然要透過使用者驗證需求；只是不要耗費工程力氣，去逼出下一個模型會交給你的能力。Carey 自己的安全機制，是讓這項押注建立在 Compounding Loop Optimization 與每日使用者接觸之上——即使特定能力缺口留給模型補上，產品形態仍持續獲得驗證。

相關連結#

• Harness Shrinkage as Models Improve — 母題；這是它的產品策略推論，而該頁面的「Build for the next model」段落也指向此處
• The Bitter Lesson — 根本原則：能力向內遷移，因此補償性腳手架會折舊
• Claude Opus 4.7 — 補上 Claude Design 未解決缺口的具體模型版本
• Claude Design — 案例研究產品
• Dan Carey — 回顧式表述；Boris Cherny 與 Cat Wu 從前瞻角度陳述它
• Prototype Over PRD — 如何快速撰寫「幾乎能運作」的押注
• Compounding Loop Optimization — 在能力缺口等待模型期間驗證產品形態的循環
• Problem-Solution Fit Discipline — 反向紀律：不要讓「幾乎能運作」變成「原型驗證了這個想法」
• The Verifiability Thesis — 下一個模型可靠改善的是可驗證回饋能力；不可驗證品味的缺口，更不適合「等待它消失」
• Andrew Ambrosino / Codex — OpenAI 方面的回顧（Codex 二月與十一月的比較），以及「相同功能、不同智慧、重新發布六次」的表述
• Polish No Longer Signals Readiness — 「它可能只是還沒準備好」會把可運作版本重新標記為待測產物，而非可發布成品——同樣的階段訊號修正
• Interaction Models — 讓互動形態符合當前能力（Codex 網頁版「太 AGI-pilled」對上 Claude Code 的本機、提問形式），就是在互動設計層實踐這項押注
• Why AI Lags at Design — Ambrosino 預期下一代模型會補上的能力，典型的「等待模型」缺口
• Latent Capability Overhang — 悲觀的孿生概念：「等待下一個模型」（每次版本發布都讓某項能力的成本降低 10–100 倍，因此稍後再以更低成本挖掘）是「為下一個模型打造」的另一面；兩者都押注於可預測的版本發布節奏

開放問題#

• 在下一個版本發布前，如何區分「等待模型」的缺口與持久的 harness 缺口？判斷錯誤，你不是會交付空中樓閣，就是會打造一根終將刪除的拐杖。
• 這項押注仰賴可靠的發布節奏與可預測的能力曲線（Task Time-Horizon Scaling）。如果模型進步停滯（停滯但擴散的未來），「為下一個模型打造」會發生什麼事？
• 這項策略能否普遍適用於前沿實驗室以外的地方？前沿實驗室能優先看見下一個模型；外部團隊押注的是自己看不見的版本。

資料來源#

• Designing with Claude: From prompt to production — Carey：「我們靠 Opus 4.7 推出後解決了它們」
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next — Boris：「為下一個模型打造」
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — Cat：「打造還不一定能運作的產品」
• OpenAI Codex lead on the new shape of product work — Ambrosino：「二月的應用程式如果十一月推出會失敗——唯一的差別就是模型」；「對當下而言太 AGI-pilled」