押注通用模型策略
解决什么问题
构建 AI 应用时的架构抉择：用编排器搭严格 workflow、微调小模型，还是直接给通用大模型工具和目标？
核心内容
这是 The Bitter Lesson（Rich Sutton）的产品推论：更通用的模型总是打败更专用的系统，所以永远押注更通用的模型。
三条具体戒律：
- 不要把模型装进盒子：不要用编排器强制"第一步→第二步→第三步"的严格 workflow。给模型一组工具 + 一个目标，让它自己决定调用什么、按什么顺序。一年前确实需要 scaffolding，现在几乎不需要。
- 不要预先塞满 context：与其把上下文一次性喂给模型，不如给它一个能自己获取 context 的工具。
- 默认不用小模型、不微调：除非有特定理由（成本/延迟约束），否则押注最通用的模型。
量化判断依据：scaffolding 通常只带来约 10-20% 的性能提升，而这些收益往往被下一代模型直接抹平——所以"几乎不如等下一个模型"。
Claude Code 的设计哲学是这一原则的极致版："产品即模型"（the product is the model）——暴露模型本身，只加最小脚手架和最小工具集。Boris 举的原初示例：给模型一个 bash 工具，没教它任何用法，它自己想出如何用这个工具回答"我在听什么音乐"。
适用边界
- Boris 承认某些应用有理由用小模型/微调，但那是例外不是默认
- "有灵活性时"适用；被成本或延迟硬约束的场景另论
- 规模化之后做成本优化（降级到 Haiku/Sonnet）是合理时点，但不要在探索期做
关键引述 · 原话
"Almost always you get better results if you just give the model tools, you give it a goal, and you let it figure it out." — Boris Cherny
"Maybe scaffolding can improve performance maybe 10%, 20%, something like this, but often these gains just get wiped out with the next model." — Boris Cherny
关联卡片
- The Bitter Lesson (Rich Sutton, 2019) - 与 `build-for-the-model-six-months-out--boris-cherny` 互补（架构下注 vs 时间下注） - 与 `latent-demand--boris-cherny` 的"模型维度"一致（看模型想做什么）
被这些卡引用
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2