刚入行那会儿我听到“第一性原理”这个词总觉得它要么是培训课上的玄学口号要么是创业者在路演PPT里用来撑场面的黑话。直到我自己带项目、做技术选型、被反复问“为什么这么做”问到答不上来时才意识到这个词真正描述的是科学世界里最基础的一种思考姿态先回到不可再简化的公理再从那里重新把系统搭起来。这篇文章我想聊聊我个人对第一性原理的理解以及它作为“科学世界的底层公理与宇宙法则”到底怎么落到真实的工作和判断里。不绕弯子地说它解决的三个核心问题分别是当行业共识失效时怎么找到新的突破口当成本高到离谱时怎么拆出真正的成本底线当所有人都说“应该这样”时如何重新判断“到底应该怎样”。这不是一套玄学方法论而是能从零一步步执行的思考程序适合做工程、做产品、做技术决策的人也适合任何一个不想被惯例惯性推着走的普通人。1. 第一性原理到底是什么从“常识”倒推到“公理”1.1 一句话版本回到系统最底层那张地图我习惯用一句话向新同事解释第一性原理把问题拆到不能再拆找到那些不证自明或者已经被严格验证的事实再从这些事实出发重新推导出解决方案。这个“不能再拆的事实”就是第一性。它可以是物理定律可以是数学恒等式也可以是资源约束和市场客观瓶颈共同特点是不依赖任何人的主观意愿、不依赖行业惯例、不依赖现有产品形态。举个例子很多人问我“为什么现在的电动车电池普遍铺在底盘下面”我第一反应不是去背供应链新闻而是先回到约束电芯需要布置空间、需要散热、需要碰撞保护、需要尽量降低重心。沿着这些约束推导底盘就是最优解区域。这种思考方式就是第一性原理的日常用法不看别人怎么布局先看系统本身逼你往哪个方向走。1.2 为什么它是科学世界的底层公理科学世界之所以能自洽运转靠的是少数几条被反复验证过的底层公理。能量守恒、热力学第二定律、最小作用量原理、对称性对应守恒律这些命题在无数实验中都没有被推翻于是成了整座科学大厦的承重墙。任何工程方案只要违背了这些公理无论中间过程多精巧最终都会碰壁。我当年读工程专业时总觉得热力学、材料力学这些课太抽象离真实产品很远。后来真正做研发才明白几乎每个“离谱方案”最后都能追查到它违反了哪条底层公理。比如某结构件反复开裂查到最后是设计时没考虑热膨胀系数的累积位移本质上是“材料受热必然膨胀”这种第一条物理常识被忽略了。所谓“科学世界的底层公理”并不神秘它就是那批无论你换什么技术路线都绕不开的铁律。第一性原理之所以被称为宇宙法则是因为它把人类主观偏好、商业模式、流行趋势统统剥离掉之后剩下的那部分仍然成立。1.3 和“类比思维”的本质区别想真正理解第一性原理最好和它的反面放在一起看。大多数人在绝大多数决策里用的是类比思维别人这么做成了我也这么做上代产品这么定下一代继续这么定行业内都是这个成本那它就是合理成本。类比思维速度快、风险分摊但它有一个致命缺陷——所有系统性的错误也会被继承下来。我通常会画一张简表帮助团队理解两种思维的差异维度类比思维第一性原理出发点已有方案、行业惯例、竞品做法客观事实、物理规律、数学关系推理方式横向移植看别人怎么做自己就怎么做纵向拆解从约束条件一步步往上推主要风险继承前人的系统性错误前提识别不全、拆解到位但推演链条过长迭代速度上手快见效快前期慢一旦突破边界就是量级提升适用场景局部优化、稳定期迭代方向选择、范式切换、重大成本重构需要强调的是我并不是说类比思维不好。在日常小改小动中类比思维效率极高直接抄最优实践是理性行为。关键要看你现在解决的是“能不能再多优化5%”还是“这个方向还对不对”。后者如果不回到第一性就永远只会在别人画的框里打转。2. 把第一性原理落成一串可操作的动作2.1 分解到不可再分的真命题第一性原理听起来宏大执行起来却是一件苦差事持续追问“为什么”直到对方答出“因为这是物理规律”或“因为这是硬约束”为止。我把这个过程叫“追问到真命题层”。所谓真命题就是那些不依赖语境、不依赖谁说了算、在所有情况下都成立或可通过数据严格验证的命题。操作方式并不复杂。拿一张白纸把要解决的问题写在最上面然后开始问要回答这个问题我需要先知道哪些事实每一个事实继续往下问这个事实还能再拆吗直到拆出来的东西要么是已经验证的数据比如材料抗拉强度、延迟测试P99值要么是基本数学关系比如成本等于固定成本加可变成本要么是物理定律。这时候才算摸到了第一性。我见过太多人嘴上说“我在用第一性原理”实际只拆了两层就停下来了。拆到“产品成本高是因为物料成本高”就等于没拆再往下追问“哪些物料贵、贵在原材料还是加工费还是良率损耗”才算切入正题。越是拆到细节越能发现真正卡住系统的那只手。2.2 区分客观约束与人为约束在拆解过程中一定会遇到两类约束把它们搞混是大多数推演翻车的原因。第一类是客观约束比如“光速有限”“材料有疲劳极限”“每天只有24小时”“服务器吞吐量有物理上限”。这类约束无法改变只能顺应或绕开。第二类是人为约束比如“公司规定必须用某个供应商”“行业惯例是这么报价的”“老板说这个模块必须三个月交付”。人为约束看起来也很硬但它是可以被改变、被替代的。我自己的习惯是在拆完一轮之后把所有约束列成两栏左边写“物理与数学上的硬限制”右边写“制度与习惯上的软限制”。然后重点攻击右边逐条问如果完全不考虑这个惯例系统会怎样很多时候你会惊讶地发现行业里默认的“铁律”其实是几十年前的技术瓶颈遗留下来的习惯早就不成立了。第一性原理最大的杀伤力正是对人为约束的祛魅。2.3 基于公理重新合成而不是在旧方案上打补丁找到真命题之后下一步是“重新合成”。这一步最容易犯的错误是拆解做得非常漂亮最后拼回来的却还是原来的旧方案只是把补丁打得更好看了一点。真正的重新合成要求你先清零再搭积木。我常用一个比方旧方案是一栋老房子类比思维是在原结构上加个阳台、换扇窗户第一性原理则是把房子拆成砖块、钢筋、水泥然后问“如果我们手里就这些材料现在要满足新的居住需求应该怎么摆”结构可能完全不同甚至柱子不会在原来的位置但每块材料都物尽其用。举个实际例子。传统车身设计里电池包和车身是两个独立系统车身负责承载电池包负责储能。如果从第一性出发会发现电池包本身是一个质量很大、刚度很高的箱体它为什么不能作为车身结构的一部分参与承载沿着这个思路出现了电池车身一体化技术本质上就是把“电池”和“结构”两个原本分开的积木重新拼在了一起。这不是在优化原方案而是重构方案。2.4 日常拆解练习费米估算是最好用的入门动作第一性原理的能力是可以训练的最好的入门训练方法是费米估算。费米估算的名字听起来高深内核很简单把一个看似完全没法回答的问题拆成一条可计算的乘除链每一环都基于常识或公开数据去近似最后得出一个量级正确的结论。比如“估算一座城市一天需要多少外卖骑手”先估算城市人口、外卖渗透率、日均下单频次得到订单量再估算一位骑手高峰期能完成的订单数得到骑手需求最后考虑骑手工作时长修正结果。整个过程不查数据库靠的是把“城市人口”“订单频率”这类基本事实层层组合。这种训练之所以是入门的黄金动作是因为它强迫你养成“任何大问题都能拆成小事实”的肌肉记忆。不要小看近似值的意义第一性原理的核心往往不在精确计算而在量级感和方向感如果你算出来某个方案和常规方案差着两个数量级那中间一定有结构性机会或结构性陷阱。3. 三个真实场景把第一性原理完整走一遍3.1 商业航天火箭凭什么可以重复使用我在很长一段时间里都觉得火箭回收是“别人家的奇迹”。但用第一性原理拆一遍逻辑非常清晰。当时行业的默认前提是火箭是一次性消耗品发射一次就报废一枚成本自然也按一次性硬件摊销。如果停留在这个层面所有优化都只能围绕“把火箭造便宜一点”展开天花板极低。但回到第一性火箭发射中消耗掉的到底是什么一枚火箭里燃料液氧、甲烷等的成本占比非常低大头是箭体结构、发动机、航电设备这些硬件。既然燃料几乎免费而硬件极其昂贵那么只要让硬件重复使用单次发射成本就能被摊薄几个数量级。正是在这个“燃料便宜、硬件昂贵”的基本事实之上垂直回收、重复使用才成为必然选择而不是一项炫技。把案例简化成数字假设一枚火箭硬件成本1000万燃料成本10万一次性使用单次成本1010万。如果硬件能重复使用10次单次成本就是100万加10万约110万直接下降近一个数量级如果能复用50次成本就逼近燃料成本。这就是为什么后来几乎所有商业航天玩家都在研回收复用技术因为物理事实摆在那里谁先做到复用谁就拿到了成本上的降维优势。第一性原理在这个案例里的作用是把“火箭应该用完就扔”从默认前提变成被质疑对象。3.2 新能源电池成本下降的真正来源早些年大家讨论电动车普及最大的拦路虎就是动力电池太贵。行业普遍反应是“等电池产业慢慢成熟规模上去了自然会降价”。这种观察并没有错但它不是一条可用于决策的推导链。用第一性原理拆解电池成本一块电池包的成本大致等于材料成本锂、镍、钴、石墨等 加工制造成本 良率损耗 集成成本。再往下拆材料成本是否天生昂贵并不是。锂元素在地壳里含量并不算稀缺只是开采提纯产能暂时不足钴才是真正又少又集中的资源。所以沿着第一性推断两条明显路径是扩大上游材料产能摊薄成本开发低钴或无钴的化学体系从材料源头去掉缺口。这两条路今天都已经成为现实。更有意思的是“能量密度”这个约束。电池续航的本质是单位重量或单位体积能存多少电。早期电池包布局松散集成效率低大量空间被结构件浪费。从第一性出发既然电芯本身是刚性的为什么不用电芯直接作为结构的一部分于是有了从传统电池包到无模组化、电池车身一体化的演进。每一步都不是追随潮流而是被“能量密度”“成本结构”这些基本公理逼出来的最优解。新能源产业表面上是在拼产品实际上是在拼谁更早把问题拆到了元素和物理那一层。3.3 软件架构一个服务到底该不该拆聊完硬件再看一个软件场景。这几年微服务架构几乎成了默认答案新项目不问需求直接拆十几个服务已经是常态。但用第一性原理问一下“微服务到底解决什么问题”答案其实集中在三件事独立部署、独立扩展、隔离故障。再往下问“我当前这个系统的约束是什么团队多少人发布频率多高单点故障会导致什么后果”顺着这些约束重新合成很多项目根本不适合一上来就拆微服务。团队只有五个人服务拆到十几个光维护服务间通信、配置、发布编排就把精力耗光了。这时候拆服务的首选代价远大于收益。软件架构里的第一性不是“业界最佳实践”而是“业务需要多快的迭代速度”“团队协作的瓶颈在哪”“故障影响范围怎么控制”。我见过一个很典型的反例某平台把订单、支付、库存拆成三个服务理由是“以后扩展方便”结果每次改一个字段要同时改三个服务、协调三次发布、排查三份日志。后来重新用第一性推了一遍发现系统当前阶段最大的约束是“上线速度”而不是“拆分粒度”最终把三个服务重新合并成一个反而把上线时间缩短了一半。这个例子不是说微服务不好而是提醒架构选型的最佳判据永远是面向约束的第一性推理而不是照抄大厂文章。4. 我踩过的坑常见误区与排查方法4.1 最容易犯的三个误区第一性原理用多了我自己也踩过不少坑最典型的三个几乎每隔一段时间就会在团队里重新出现一次。第一个坑是把“我的目标”当成“第一性”。比如“我们公司今年一定要做到行业第一”这句话再义正言辞也不是公理它是一个主观愿望。第一性原理要求你找到的是客观约束和客观事实主观目标可以作为评估方案的指标但不能作为推导的大前提。如果你发现自己围绕一个口号在拆解拆到后面全是“必须做到XX”就要警惕了。第二个坑是用“行业共识”冒充“基本事实”。我一度也犯过这个毛病把“行业规格都是这样的”当作不能动的约束。实际上很多行业规格只是历史阶段的产物并不是物理必然。检验方法很简单对每一个你说出的“事实”追问一句“这个结论有没有可验证的来源换一个前提它还成立吗”如果答案是“大家都这么说”它就只能算假设不能进入推理链条。第三个坑是只拆不解停在“分析瘫痪”。有些人拆解能力很强把问题拆成三十个因素却迟迟不敢重新合成。原因大多是追求完美想等所有数据都确认后再动手。但第一性原理的价值恰恰在于“基于现有确定的少数公理先给出一个可行框架再逐步修正”。在工程现场方向正确但粗糙的行动永远好过完整但迟到的分析。4.2 怎么判断自己是不是又想歪了因为第一性原理的产出经常挑战惯例所以也需要一套自查机制用来判断你的推演是真的面向底层还是只是给旧结论找了一套新说辞。我有一个三层检查清单每次做完方案我都会拿它过一遍你推理中的每个“基本事实”是否都可以用物理规律、数学关系或公开可验证的数据支撑如果有任何一条来自“公司规定”或“大家习惯”它就必须被标成待删项。从前提推导到结论的过程中是否存在“因为所以”的跳跃尤其是那些你觉得“显然成立”的环节往往是隐藏假设最密集的地方。把每一步“显然”写成显式命题再问一次它是否成立。最终方案相比原方案是本质结构不同还是只是微调参数如果只是把旧方案的数字改小一点说明你可能根本没有真正完成“清零再构建”只是在旧路线上加快了速度。这套检查并不复杂但非常消耗耐心。我的经验是很多自以为高明的第一性分析都倒在第二层推理链里藏着一句“显然应该有XX”而那个XX正是行业惯例换了个马甲。4.3 第一性原理的边界什么时候别硬套强调完价值也得说清楚边界。第一性原理不是所有场景下的最优工具更不该成为“凡事都要从零推导”的行为艺术。第一种不适用的情境是常规优化。当系统运行稳定只需要把某个效率提升5%时类比思维和最佳实践往往是更高效的路径。此时非要重新拆一遍底层逻辑投入产出比很低。我通常会把资源分配成“二八开”八成的精力用于基于对标和经验的持续优化两成的精力用于对那些决定未来的重大方向做第一性推演。第二种不适用场景是信息高度不确定时。如果系统的基本构成要素都还没搞清楚强行从“公理”出发就很容易变成空中楼阁。这就好比连桥梁的荷载路径都没弄明白先讨论最优梁截面方向对了也落不了地。第三种是时间极度紧迫的救火场景。线上故障正在烧钱第一件事是止血而不是坐下来重新设想一套系统架构。第一性原理解决的是“为什么我们会在一个错误方向上走这么远”的根因问题不适合处理眼前正在冒烟的危机。5. 把第一性原理训练成肌肉记忆5.1 从“解释一个现象”开始第一性原理的日常训练并不需要遇到惊天项目才能做最简单的起点是解释日常现象。比如在饭店门口等位可以顺手拆一下“为什么这家店要排队”店铺坪效怎么算、翻台率如何影响边际利润、等位如何成为营销手段、周边同类供给是否不足。再比如看新闻说某芯片涨价可以试着拆“涨价”由供需缺口驱动还是库存周期驱动供需缺口又由哪几个工厂的产能约束决定。这种训练看起来像是打发时间的思维游戏实际上是在反复强化“现象→要素→约束→结论”的路径。拆多了之后你再遇到工作里的复杂问题时会下意识地不再满足于“行业报告怎么说”而是想先看看约束条件本身什么样。这是把第一性原理内化成直觉的最有效方式把它变成一种日常的观察习惯而不只是一项项目工具。5.2 把“大家都在用”当成危险信号当你开始以第一性原理的视角生活时会发现一句高频咒语正在悄悄偷走你的判断力“大家都在用”“行业都这样”“以前一直如此”。我并不是说流行方案没有参考价值恰恰相反流行方案通常是因为在当时的条件下解决了真问题才流行起来。但流行方案的适用条件会过期。更好的做法是每次听到“大家都在用”时不要直接采用或反驳而是把这句话转译成一个开放问题大家用它的原因是什么那些原因在当前我的约束下还成立吗这个转译动作本身就是在强迫自己把“类比默认项”降级为“待验证假设”。实际工作中我常用一个很笨但有效的办法在评审会上任何人说出“别人都这么做”我就要求他在白板上写出“别人这么做的三个前提条件”。往往写到第二个他本人就开始怀疑了。把潜藏的类比识别出来是第一性原理最重要的日常动作。5.3 建立一份自己的“已验证事实清单”长期使用第一性原理的人最后都会沉淀出一份属于自己的“公理清单”。这份清单上的每一条都经过你自己的实践或严格验证是可以反复信赖的知识底座。比如做硬件的人清单上可能有“散热能力与风道横截面积强相关”“结构刚度与厚度三次方相关”做软件的人清单上可能有“分布式系统的核心难点在于数据一致性”“接口一旦多版本共存维护成本非线性增长”。积累这份清单有两个要点。第一每条都必须是一句话能说清楚、可以检验的命题而不是含糊的价值观。第二要定期复核因为随着技术演进有些“事实”会过期。比如曾经的“硬盘随机读写性能远低于顺序读写”在新型存储时代需要重新修正。这个清单越厚你在做第一性推演时的起点就越可靠速度也会越快因为不需要每次都从零开始验证那些已被沉淀的公理。我个人在实际项目里最能体感到的第一性原理价值不在那些光鲜的大决策上而是在日常汇报里。每次当我说“让我先回到约束推一遍”而不是“竞品怎么做的我们照做”讨论的质感就会明显不一样。这篇文章最后再分享一个小技巧把你认为已经用第一性原理推出来的结论原原本本写下来给一个懂行的朋友看请他专门挑你推理链条里“藏起来的假设”。这个方法我用了很多年几乎每次都能抓出一两个你以为理所当然、实际上漏洞百出的隐含前提。第一性原理不提供标准答案它只提供一个更不容易自欺欺人的起点。