01原理
化简不是偷懒，而是给问题排顺序。大多数商业问题看起来复杂，是因为几十个变量同时摆在桌上，彼此缠在一起。芒格的做法是先找出其中少数几个“不用多想”的大问题：答案几乎是确定的，而且一旦定下来，会顺带排除掉一大片选项。这几个问题定了，剩下要真正动脑的部分往往只剩原来的一小块。
这和“简化成一个漂亮的数字”是两回事。芒格引爱因斯坦那句话，敲打的正是另一头：简单到丢掉了决定结果的东西，就不再是化简，而是算错。在 1996 年的演讲里，他批评学院派心理学一个个倾向分开做实验，却不研究几种倾向叠在一起时的巨大效应，等于把最要紧的那部分简化没了。好的化简只删噪音，不删主因。
对 10 人以内的 AI 公司，这条尤其值钱。小团队最稀缺的是注意力，而模型、框架、定价、渠道每周都在变，几乎每个决定都能被讨论成“看情况”。先问一句：这里面哪几件事其实已经有明显答案？比如“我们是否要在第一年自己训练基座模型”，对绝大多数小团队答案明显是否。把它们先定死，后面的讨论才有边界。
为什么成立
化简之所以有效，首先是组合数学：每多一个悬而未决的选项，方案空间就成倍增长；定下一个大问题，删掉的是整条分支，而不是一片树叶。其次是认知容量：人在同一时间能认真权衡的因素很少，问题一大，就会退回到凭印象或凭最后听到的意见做决定。先把“明显”的部分定下来，等于把有限的思考留给真正不确定的部分。
但化简有一个必须守住的下限：被删掉的变量必须真的不影响结论。最危险的删法，是删掉那些会对你的动作做出反应的东西，比如用户、对手、供应商的行为，因为它们恰恰会在你行动之后改变。检验一次化简是否合格，看的不是模型短不短，而是被删的东西改变后，结论是否还站得住。
02芒格怎么说
芒格把“化简”当作他解决实际问题的第一条工具。1996 年 7 月 20 日的非正式演讲《关于实际思维的实际思考？》里（他在演讲中以可口可乐的创业为例），他列了五条“极简的一般观念”，第一条就是先决定那些不用想就能定的大问题，用它们把问题变小。同一场演讲里他也搬出爱因斯坦“尽可能简单，但不能更简单”，批评学院派心理学把问题简化过了头。2003 年在加州大学圣巴巴拉分校的 Herb Kay 讲座上，他自称专门挑简单问题来做，现场用两三个一眼能答的问题拆解了一家家具店的成功，并抱怨受过多年训练的人答不出“答案很明显的明显问题”。
The first helpful notion is that it is usually best to simplify problems by deciding big no-brainer questions first.
第一条有用的观念是：通常最好先把那些不用多想就能定的大问题定下来，以此把问题化简。
In a long career, I have assimilated various ultrasimple general notions that I find helpful in solving problems.
在漫长的职业生涯里，我吸收了一些极其简单的一般观念，发现它们对解决问题很有帮助。
And it violates Einstein's injunction that “everything should be made as simple as possible, but no more simple.”
这也违背了爱因斯坦的告诫：“一切都应该尽可能简单，但不能更简单。”
I specialize in simple problems.
我专门做简单的问题。
Obvious questions, with such obvious answers.
明显的问题，答案也这么明显。
03怎么用
- 01
开会前先列“不用讨论”的清单
在任何大决策（选方向、定价、招第一个销售）之前，先花十分钟写下：哪些问题的答案我们其实已经知道？例如“不做需要大规模线下交付的客户”“不在没有付费用户之前做多语言”。逐条确认后写进文档，讨论只针对清单之外的问题。如果有人想重新打开清单里的某一条，要求他拿出新的事实，而不是新的感觉。
- 02
系统设计从最笨的方案开始
做智能体或工作流时，先搭一个固定步骤、没有自主规划的版本，用真实任务测出基线，再决定每一层复杂度是否值得加。每加一个组件（记忆、多智能体、工具路由），都要回答它在评测上多换来了几个点、多花了多少钱和多少排障时间。答不上来的，就先不加。
- 03
用一两个变量定义业务
芒格在 2003 年讲座里说，极端成功常来自把一两个变量做到极致。小团队可以反过来用：选出你要做到极致的那一两个指标（比如“交付速度”或“单次任务成本”），然后凡是与它冲突的功能、客户和合作，默认拒绝。这样日常大量的取舍不用每次重新讨论。
- 04
给每次简化写下“删掉了什么”
做财务模型、容量估算或用户增长预测时，在旁边单列一栏：为了好算，我假设了哪些东西不变？模型价格、竞争对手反应、用户行为会不会因为我们的动作而改变？每季度回头看一次这栏，哪个假设变了，就重算。化简可以粗，但删掉的东西必须看得见。
04案例
西南航空：只飞一种飞机
西南航空 1971 年 6 月 18 日开航，最早在达拉斯、休斯敦和圣安东尼奥之间飞。它几乎只用波音 737，唯一的例外是上世纪七八十年代之交短暂用过的六架 727-200；到维基百科统计时，机队有 803 架 737。单一机型这个决定一旦定下，后面一长串问题就不用再分别讨论：飞行员可以开机队里任何一架飞机，备件种类少，培训时间和成本低。它从 1973 到 2019 财年连续 47 年盈利。盈利当然有很多原因，不能都记在机型上；但这是“先定一个大问题、让下游问题自动变小”的典型做法。[4]
内布拉斯加家具城的堪萨斯城新店：两个问题拆开一个“奇迹”
芒格在 2003 年的讲座上出了一道题：伯克希尔刚在堪萨斯城开了一家家具家电店。当时全世界卖得最多的同类门店也是伯克希尔的，一年卖 3.5 亿美元；这家开在陌生城市的新店，一开张就按每年 5 亿美元以上的速度在卖，3200 个停车位天天停满。为什么？他没有去分析管理、文化或选址，只问了两个几乎不用想的问题：在一个陌生城市一炮而红，它是低价店还是高价店？一年能卖出 5 亿美元的笨重家具，店得有多大？答案分别是低价和巨大，而巨大意味着品类多。再补一个问题：为什么以前没人这样做？因为开这么大的店要花一大笔钱。三个明显的问题，就把一个看似复杂的成功拆完了。这些数字都是芒格在讲座里给的。[2]
Claude Code 拿掉向量检索，改用 grep 式搜索（大公司案例）
这不是小团队案例，但决策本身很适合小团队参考。据 OfficeChai 2025 年 5 月 27 日对一段视频访谈的报道，Anthropic 的 Claude Code 负责人 Boris Cherny 说，早期版本用的是 RAG：用现成方案（他记得是 Voyage）给代码库建索引。问题随之而来：代码一改，索引就跟不上；维护索引本身有大量复杂度；索引要存在某个地方，把敏感代码交给第三方也是负担。团队最后改成“智能体式搜索”：不预先建索引，让模型按需反复调用 glob 和 grep 这类普通代码搜索工具。他说这种做法的效果“远超其他所有方案”，自己也觉得意外，但承认依据主要是感觉，外加一些内部基准；代价是更高的延迟和 token 消耗。对小团队，这里的化简是先回答一个大问题：我们到底需不需要一套要持续维护的检索基础设施？[3]
6 人团队的“第一年不做清单”
一家 6 人的合同审阅 AI 公司，季度规划会上列出了 23 个待议事项。创始人先让大家用二十分钟只做一件事：找出答案明显的大问题。结果定下三条：第一年不自训模型，只调用现成模型；只做英文和中文两种合同；不接需要私有化部署的客户。这三条一定，23 项里有 11 项直接作废，比如评估 GPU 租赁、做德语界面、搭本地部署安装包；剩下 12 项里又有 5 项变成了单纯的执行问题。真正需要讨论的只剩 7 项。半年后客户结构变了，他们重新打开了“私有化部署”这一条，因为当初定它的前提（客户都能接受云端）已经不成立。
05误用与边界
把“删掉不重要的”变成“删掉不好算的”
最常见的错误是按难易程度而不是按影响程度删变量。用户行为、对手反应、模型厂商调价都难算，却往往决定结局。删之前先问：如果这个变量变了，结论会不会翻？会，就不能删，哪怕只能给一个粗略区间。
“明显”的答案其实是偏见
先定“不用多想”的问题，前提是答案真的明显，而不是团队里资历最深的人觉得明显。小团队尤其容易把创始人的旧经验当作常识。一个检验办法是：这个答案能否用一两条外部事实或数字支撑？只能靠“大家都知道”撑着的，不算明显，应该退回待讨论清单。
化简一次，就再也不回头
Claude Code 放弃索引、改用按需搜索，部分前提是模型已经强到能自己找路，而且团队愿意付更多延迟和 token。前提一变，结论也可能变：代码库大到搜索太慢、客户对响应时间更敏感时，当初删掉的复杂度可能需要加回来。把每次化简当作有有效期的假设，而不是永久的原则。
06检查清单
下次做相关决策前逐条过一遍。勾选只保存在你的浏览器里。
08来源
- 1
- 2
- 3
- 4