為下一個模型打造產品

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Designing with Claude: From prompt to production
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Jeff Dean: The 1% Rule for Building in AI
• OpenAI Codex lead on the new shape of product work
• Rewriting Bun in Rust

摘要#

這是 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 稻草人打造產品 → 你會高估能力，推出依賴當下不存在能力的空中樓閣。
• 為下一個具體版本（約六個月後的模型）打造產品 → 先做出「差一點就能運作的東西」，以研究預覽形式推出，並讓你有合理把握能預測的下一次發布補上缺口。

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

OpenAI 方面的佐證：相同形態，不同智慧（Ambrosino）#

Andrew Ambrosino 提供了第二個具體的事後案例，也是對這項押注最精準的表述。他談到 Codex app 時說：

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

他將此歸納為**「相同功能、不同智慧、重新發布」模式**：Operator（在 ChatGPT 中）→ Atlas 的 agent mode → Codex 內建瀏覽器，都是「本質上相同的功能」；「你可能得把這個東西發布六次，才終於讓它能運作——形態或許完全不必改變」。改變的是底層模型。因此他提醒團隊別固執己見——「不行，這個功能行不通，所以它是個糟糕的功能」是錯誤解讀；正確的想法是「它或許還沒準備好」（能運作的版本是用來對照未來模型的素材，不代表已可推出）。

他警告的過度押注——「對當下而言太 AGI-pilled」。 Ambrosino 以一個特別坦率的跨廠商例子，指出校準另一端的失敗模式（下一節警告的 AGI 稻草人）。最初的 Codex 網頁版「把一項任務交給模型，然後它就自行完成」——這是一種完全委派、AGI 風格的產品形式——但「模型完成得不怎麼樣」。同時，Claude Code「完全在本機執行，沒有連到雲端……不假裝自己有那麼 AGI-pilled——它會問你問題，你不能直接把人生交給它代辦」，而且它「效果好得多，因為當時模型的能力就到那裡」。他的教訓是：「當時我們太 AGI-pilled 了。」押注必須符合模型實際所在的位置；將互動形式配合當前能力，可能勝過押注模型尚無法支援的委派方式。（Interaction Models 從互動設計角度描述的也是這種產品契合落差。）

再次丟給模型的紀律：Bun 重寫案（Cherny）——以及第一手說法沒有提到什麼#

第三個事後案例，也是第一個「押注下一個模型」在任務而非產品上奏效的案例（YC 訪談，2026 年 7 月，practitioner-opinion）：Bun 團隊的 Jared 將 Bun 執行環境從 Zig 全面改寫成 Rust，持續當作「每次新一代模型推出時，都丟給模型試試看的其中一個測試題」。每個模型都失敗——「即使有引導也不行」——直到 Fable 出現，接著在 11 天內以動態工作流程完成（以既有測試套件驗證，目前已在 Claude Code 中投入正式使用）。Cherny 將其歸納成一項長期建議：面對任何真實工程問題，「就一直拿最新模型去試，看它能不能直接完成。因為先前的模型做不到，不代表新模型也做不到。」這是最純粹的押注形式——完全沒有花工程力氣補償，任務本身始終固定不變，作為評測，所有工作都由發布節奏完成。

第一手說法講的是另一回事，而這個差異對本文很重要。 Jarred Sumner——也就是受訪時所說的「Jared」，也是 Bun 的創作者——在訪談前一個月就公開了完整方法（Rewriting Bun in Rust，2026-07-08，case-study；Sumner 是 Anthropic 員工）。他的說法證實了成果和模型歸因：移植工作使用尚未發布的 Fable 5，Sumner 表示「一開始我沒預期它會成功」。但他沒有佐證反覆重試的做法。Sumner 完全沒提到曾經反覆把改寫任務交給早期模型。他所述的是一次性的決定，而且當時考慮的替代方案完全不同：團隊原先的計畫是自行實作 Zig smart pointers，再搭配風格指南；改寫則是在他「不想用另一種方式做」時提出的一週實驗（「不如我花一週測試 Anthropic 的新模型能不能用 Rust 重寫 Bun？」）。

這對本文的押注論點有三個影響：

• 「跨世代固定任務作為評測」是 Cherny 的說法，不是實際操作者的說法。 這可能確實發生過，只是沒提及；但知識庫唯一的第一手敘述並不支持這種說法。最清楚的反覆重試案例，其做法本身尚未獲證實，但成果仍然成立。
• 觸發因素是經濟考量，而非好奇心。 Sumner 的說法是「直到最近，程式語言的選擇還是一個單向決策」——這次押注之所以奏效，是因為某類工作的成本大幅下降，而不是定期測試終於成功。這是不同於「每次發布都再試一次」的訊號，而且更容易預測。
• 「完全沒有花工程力氣補償」並不正確。 這次執行需要約 3 小時的模式盤點來產生 PORTING.md、專用工作流程來產生 LIFETIMES.tsv、在 3 個檔案上試跑、約 50 個手動調整的工作流程、git 命令拒絕清單、cgroup 隔離，以及連續 11 天的人工監控。即使補償用的鷹架為零，harness 規模仍然很大——兩者並不相同（Harness Shrinkage as Models Improve）。

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

同樣的邏輯也會改變路線圖。Ambrosino 說：「時間越短的事，需要越詳細的規劃」；但九個月的計畫「必須非常模糊，因為你加上的任何精確度都是假精確，只會浪費時間」。十一月規劃的事情「十二月時或許還成立，但後來並沒有照那樣發展」。因此，規劃就變成預測特定時間點的模型能力：在他上一家公司，流程變成「列出所有感興趣的事情、全部做成原型、決定哪些現在已準備好、讓其他項目繼續醞釀；每次模型有重大突破，就替換成新模型再試一次——因為功能好不好，取決於模型是否夠聰明，而不是功能的形態。」這就是由能力不確定性所驅動的最小化規劃。

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

這是 The Bitter Lesson 和 Harness Shrinkage as Models Improve 在產品方面的呈現：能力會隨著版本發布逐漸移入模型，因此為了彌補當前限制而打造的鷹架，是一項會折舊的資產。如果某種缺口會隨規模擴大而消失（推理、遵循指令、多模態保真度），用工程手段修補它，就像打造一根很快便要拆掉的拐杖。關鍵在於分辨哪些缺口應該「等模型進步」，哪些則需要持久的 harness 工作（Harness Shrinkage as Models Improve 的但書：機械式驗證、安全、品牌與角色不會移入模型）。

必須掌握的張力#

Anthropic 之外有一種更尖銳的張力：Jeff Dean 建議創辦人把「模型差不多做得到」視為避開該市場的理由，而不是投入原型的訊號——「找模型成功率為 0% 或 1% 的事情，而不是 20% 的。」相同訊號，結論相反；調和兩者的關鍵在於誰擁有會因模型發布而受益的產品介面。詳見 The 1% Rule for Wedge Selection。

「做出差一點就能運作的原型」也直接牴觸 Problem-Solution Fit Discipline 所說的原型作為證據陷阱：快速原型證明的是打造原型可行，而不是問題確實存在。調和方式是：為下一個模型打造產品，處理的是能力風險（技術能否達標？——能，等它進步），而非市場風險（有人想要這個嗎？——原型無法回答）。你仍然要透過使用者驗證需求；只是不用耗費工程資源，硬要模型具備下一代會直接帶來的能力。Carey 自己的保障措施是，這項押注建立在 Compounding Loop Optimization 和每日接觸使用者之上——即使特定能力缺口留待模型補足，產品形態仍持續接受驗證。

延伸閱讀#

• Harness Shrinkage as Models Improve — 母題；本文是它在產品策略上的推論，而該頁的「為下一個模型打造產品」一節也指向本文
• 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 倍，因此稍後再用更低成本挖掘）是「為下一個模型打造產品」的另一面；兩者都押注可預測的發布節奏
• The 1% Rule for Wedge Selection — 直接的矛盾觀點：Dean 將相同的「模型大約有 20% 的機率答對」訊號解讀為不該投入的理由。兩者依產品所有權調和：本文談的是你已擁有的產品中的能力缺口（模型發布是補助），1% 規則談的是公司要做什麼（模型發布是競爭者）
• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — 停滯分析：這項押注是針對發布節奏的低成本買權；若停滯，就以能力餘裕作為避險，若有需要則重新累積 harness，作為備用紀律
• The Code-Quality Payoff Is Token-Indexed — 同樣以「立足於當下」為前提，但討論工程紀律而非產品缺口：DHH 認為架構工藝是對 token 稀缺的押注，並指出這種推論正是 AI psychosis 的起點

待解決的問題#

• 如何在下一次發布前，判斷某個缺口應該「等模型進步」還是需要持久的 harness？判斷錯誤，就可能推出空中樓閣，或打造出最後會拆掉的拐杖。部分解答：What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful?——存續分類法就是判別工具：行為／能力（任務先驗結構）上的缺口屬於「等模型進步」；邊界、組織特定紀錄、身分、部署結構或面向使用者的可理解性缺口，則屬於任何版本都無法補上的持久 harness 缺口。發布前的判斷依據，是修補措施會將什麼資訊編碼進去。
• 這項策略是否適用於無法優先掌握下一個模型資訊的前沿實驗室以外團隊？外部團隊押注的是自己無從預見的版本。

已解答問題#

• 這項押注仰賴可靠的發布節奏，以及可預測的能力曲線（Task Time-Horizon Scaling）。若模型進步停滯（停滯但已擴散的未來），「為下一個模型打造產品」會如何發展？已解答：What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful?——只要做法正確，策略便能平順退化，因為它其實是針對發布節奏的低成本買權：停滯時損失的是權利金（原型組合到期而未行使），而不是整家公司，前提是市場驗證與能力押注彼此分開。三道緩衝：停滯後，Latent Capability Overhang 仍能讓有效能力提升（挖掘模型取代「等待模型」）；原本錯誤的做法——打造補償用的拐杖——重新分類為正確做法（「太 AGI-pilled」的修正成為長期立場）；競爭則轉向從未移入模型的持久層面。只有在校準失誤時，押注才會徹底失敗：推出核心循環仰賴缺失能力的產品；無論發布節奏是否持續，這種產品都是空中樓閣。

參考來源#

• 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：「二月的 app 若在十一月推出就會失敗——唯一的差別是模型」；「當時我們太 AGI-pilled 了」
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny，YC 訪談（2026-07-27，practitioner-opinion）：Bun 從 Zig 改寫為 Rust 的反覆重試案例，以及「持續把最新模型丟給它試」
• Rewriting Bun in Rust — Jarred Sumner，bun.com（2026-07-08，case-study）：同一改寫案的第一手敘述——一次為期一週、以 smart-pointer 替代方案為對照的實驗，而非每一代都重試，並且需要規模龐大的準備 harness
• Jeff Dean: The 1% Rule for Building in AI — Jeff Dean，YC Startup School 2026（2026-07-30，practitioner-opinion）：與本文相反的經驗法則——應選擇模型成功率為 0–1% 的領域，而非 20% 的領域