最近很多朋友问我同一个问题你天天说“用第一性原理想事情”到底是怎么个用法是不是就是多问几个为什么这个问题问得多了我发现大家不是不想用而是根本没人把“从零到一”的完整思考流程掰开揉碎讲清楚。网上能找到的多是案例故事看完觉得很震撼回头自己遇到问题依然不知道第一步该干嘛。所以这一章我决定把这套方法彻底写透。作为系列的第三章我会沿着前面两章的思路往下走——前两章一篇讲了怎么把复杂问题拆成小块另一篇讲了怎么用系统视角看整体。这一篇聚焦在一件事上怎么从最底层的事实出发重新推导出一个答案而不是在别人搭好的框架里修修补补。在很多行业里大多数讨论其实不是在思考而是在互相交换共识第一性原理要做的恰恰是打破这种交换。这篇内容适合所有需要做判断的人。不管是产品经理设计一个方案程序员排查一个诡异Bug还是运营在制定一个新策略甚至是一个普通人在思考“我到底该选哪份工作”都可以用同一套流程。它的核心价值就一句话帮你摆脱“因为大家都是这么做的所以我也该这么做”的惯性找到真正属于你自己的答案。1. 先把概念拆干净第一性原理究竟是什么1.1 回到源头它来自物理学的“还原思维”很多概念火起来之后大家反而把它原本的含义弄丢了。第一性原理最早是物理学里的说法它的核心是一种还原论思维任何复杂系统都可以还原到若干最基本的规则和定律然后从这些定律出发推导出一切。物理学里经常干这个事——从量子力学的基本方程出发理论上你可以推导出化学反应、材料性质甚至生物学里的一些规律。放在日常和商业语境里第一性原理的意思被引申为遇到问题时不先看别人怎么解决不先翻现成方案而是问一句“在事情最底层真正不变的约束条件是什么”然后从这些约束出发重新搭建你的判断。这里我想强调一个区分第一性原理的“第一性”不是指“第一层原因”而是指“不能再被推导的底层事实”。比如你发现转化率低追下去的原因可能是页面加载慢加载慢的原因是图片太大图片太大的原因是设计稿切图失误这每一步都还停留在原因层面的追问。第一性原理要追问的是比这更根本的东西用户为什么在这个页面停留他的决策依据是什么图片大小之外有没有一个完全不同的框架所以它跟常规意义上的“深挖”有本质区别——深挖是在同一维度上往下钻第一性原理是要跳出这个维度本身。1.2 第一性原理和“想当然”的本质区别为了让这个区别更直观我经常用一个“盖楼”的类比。假设你要一个“安静舒适的休息空间”一个人会想那我去看看哪里有合适的房子租一间再装修一下。这个思路没什么错但它是典型的框架内思维——你默认了“休息空间房子”这个前提。第一性原理的做法是先把“房子”这个前提剥掉退回到“我要什么”和“现状是什么”两层事实。你可能发现真正让你疲惫的不是没有休息场所而是通勤时间太长于是你发现答案根本不在“换个房子”而在“调整工作地点”或者“改变通勤方式”。这就是第一性原理和“想当然”的本质区别想当然是在既有选项里做选择第一性原理是重新定义选项本身。前者追求“在规则内做得更好”后者追求“换一套规则”。“从零到一”的“一”指的就是你重新推导出来的那套新规则。这也是为什么它能产出突破性方案——因为传统的类比式优化天花板是“现有最好方案”而第一性原理的天花板是“物理极限”和“真实约束”。1.3 为什么这两年它忽然火起来老实讲这套方法论被大量传播和近十年几个高难度行业的突破性进展关系很大。火箭过去被当成一次性昂贵消耗品这是几乎所有人默认的规则但有人没有接受这个规则而是把火箭拆成“材料成本制造工艺推进剂”进行计算发现抛开行业惯例之后发射的成本结构根本不是大家想的那个数字于是重新设计了一条完全不同的技术路线把成本压掉一个数量级。电动车电池也是同样的逻辑电池组贵大家都说行业就是这样但有人把它拆成原材料成本按锂、钴、镍的市场价格重新算了一遍发现材料成本远低于电池组的报价中间巨大的差额来自产业链、品牌溢价和集成方式。所以他们决定自己造最终把整个行业的成本拖了下来。这类故事传播之后大家记住的是“人家真牛”但很少有人真正拆解他们思考的过程。这也是为什么我一定要把流程写出来——第一性原理不是天才的灵光一现它是一套有顺序、有标准、可重复的思考动作。按我的经验只要能忍住“赶紧给答案”的本能冲动任何人都能复现这套流程。2. 从零到一的完整流程五个必须走过的台阶2.1 第一步把脑子里现成答案全部列出来很多人一上来就问“底层是什么”这是错的。第一步反而是先把脑中所有现成答案、行业惯例、默认假设全部写下来。这一步的目的不是分析而是“清场”。如果不清场你后续的每一次思考都会被这些默认假设拽回去。我建议用一张纸分三栏第一栏写“大家怎么做”比如市面主流方案的共同特征第二栏写“我们一直默认什么”比如默认必须月付、默认必须有客服、默认线下体验很重要第三栏写“我知道哪些限制条件”比如合规上限、物理特性、资金边界。写的时候不要评判不要觉得哪条蠢先全部铺开。这一步看着简单但大部分人做不好因为会下意识地把“自己认同的答案”和“事实”混在一起。比如写“客户就是嫌贵”这其实是一个有待验证的判断不是事实事实应该是“客户在付费页面的停留时间低于五秒然后直接关掉了”。区分这两者是第一性原理所有后续步骤的地基。2.2 第二步逐个质疑挖到不能再挖为止这一步是核心中的核心。拿着第一栏和第二栏的每一条用最狠的语气问自己这条真的是事实吗还是只是某个阶段、某种场景下的局部经验如果这条不存在那会发生什么我聊一个自己踩过的坑早先做内容产品时团队默认“用户需要作者身份背书”所以所有栏目都花力气做个人IP。后来用这个方法把这条拆到最底层发现用户真正要的只是“这段内容值不值得我看一分钟”作者身份只是证明内容质量的众多信号之一。于是我们做了一版纯内容页把作者信息降到最弱数据反而涨了四成。这件事让我记住了所谓默认假设通常只是众多解决方案里的一种。质疑的时候必须拿证据说话。每质疑一条就写下“我凭什么说它不是事实”——可以是一组数据、一次用户访谈、一个对比实验把证据列在旁边。如果找不到证据那就不能轻易说它不成立只能标记为“待验证假设”。这一步切忌变成抬杠大会我自己团队早期犯过这个错质疑到最后全靠嗓门定胜负那还不如不做。2.3 第三步找到真正的基本单元在连续质疑之后你会得到一批底层的“不可再分”要素。判断标准很简单如果这条要素消失你讨论的问题就不成立。比如火箭的底层要素里有“推进剂必须达到一定能量密度才能脱离地球引力”这是物理事实但“火箭必须是一整台一次性机器”不是底层要素它只是一个工程选择。这一步最难的地方在于保持“少即是多”。当你挖掘的时候最多留三到五个基本要素就够了如果你发现自己总结了十来个“基本要素”那说明你还没挖到底里面大部分其实是二级或者三级假设。提示判断基本要素的两个条件——第一你能说出它的数据来源或事实依据第二针对这个要素你至少能想到一个具体的行动。两个条件都满足不了说明还没拆到可用的层次。分解的终点不是“道理上更本质”而是“行动上更清晰”。我见过很多人拆到“人性底层”“商业本质”这种宏大词汇就停了听着很高级但回去之后完全不知道该做什么这种分解没有任何实操价值。2.4 第四步用基本单元重新搭建方案从底层要素出发重新问一个干净的问题如果世界上没有现成方案只有这几个底层事实我会怎么搭你不是去优化现有的楼而是要站在空地上重新设计一栋楼。这里有个技巧把“我不能做什么”暂时忘掉只问“在物理和逻辑允许的范围内有哪些可能路径”。然后把可能路径排列出来挑选一条看起来反直觉、但底层推导没有明显漏洞的方向作为候选方案。记住这个阶段不追求“完美方案”追求的是“来自底层推导的方案”。重新搭建的过程中你会发现自己原来的很多认知都要被推翻。举个例子如果你做的是软件订阅生意拆到底层发现边际成本趋近于零、用户付费意愿跟使用频次强相关那你就不该继续做“按功能收费”的方案而应该认真考虑“按用量收费”或“按效果收费”。这个结论在事后看很合理但在推导过程中它需要你有勇气对一个业务里最根基的商业模式动手。2.5 第五步小步验证拿真实数据说话第一性原理推导出来的方案往往反常识反常识意味着团队内部会有阻力也意味着你需要更谨慎地去验证。所以千万别一开始就全量投入而是找一个最小的、可以快速试错的切口。验证的目的是纠偏——第一性原理不是“拍脑袋从零开始”而是“从底层推导假设再回到现实里校验”。我常用的做法是设计一个两周到四周的小范围灰度实验两组用户一组走原方案一组走新方案控制相同的流量入口和用户特征只改变你要验证的核心变量。数据指标要提前定好不要等到实验结束了才讨论“到底看哪个数”。如果新方案数据更好那就继续扩大如果数据更差说明你的底层推导某个环节出了问题回到第二步重新质疑。数据差不是失败而是帮你把推导里隐藏的错误显性化了。3. 实操案例用第一性原理重新设计一个产品定价方案3.1 背景与初始困境我曾经在一个给中小电商卖家做库存管理工具的产品组里待过。这个产品本身没什么硬伤界面干净、功能完整但是转化率一直上不去销售天天吐槽客户嫌贵。我们当时的应对方式估计很多人眼熟销售说功能不够全我们把报表模块加厚客服说客户要批量导入我们又加了Excel批量操作最后功能列表越来越长客户反而说看不懂转化率不仅没涨退款率还升高了。当时团队内部形成了两个默认共识第一客户就是嫌价格贵第二想要提升转化就得让客户觉得“功能值这个价”。这两个共识听起来特别合理于是所有人都在价格折扣和功能堆砌上做文章。我也是在很多次复盘之后才意识到这两个共识本身就是最大的假设而真正把它们打破的就是第一性原理这套流程。3.2 质疑阶段剥离“行业惯例”我们拿着一张白纸把所有默认答案都列了出来行业主流是三档订阅、按功能数量分档定价、年度付更划算、功能越多价格越贵、客户说贵就得降价、竞品都在做套餐所以我们也得做。列完之后开始一条条质疑。第一条质疑客户真的嫌贵吗我们跑了一次付费意向调研结果很有趣只有不到30%的用户提到价格高大部分人在意的其实是“这个工具能不能在月底对账那天帮我省下两小时”。月底对账对小商家是真实痛点他们忙到凌晨不是不想买工具而是没时间研究工具。所以“贵”很可能只是表面抱怨真实问题是产品没有切到他们最疼的场景。第二条质疑三档订阅是必须的吗我们把三档模式的来源追溯到很多年前的软件行业当时按功能分档是为了区分专业版和家庭版降低渠道管理难度。如今云化产品按账号、按用量计费都很成熟功能分档只是历史惯性不是业务必然。第三条质疑年度付费是必须的吗小商家平均生命周期短很多撑不过一年你让他一次性付一年他心理压力极大。按需按月、随时暂停反而更贴合这群人的生意节奏。这些质疑的过程没有一条是拍脑袋都是用访谈数据、后台行为数据、回访录音作为支撑的。这一步也是我想强调的质疑不是抬杠而是要拿数据说话。3.3 分解阶段找到定价的基本要素经过几轮追问我们最终把“定价”这件事分解成了四个基本要素成本底线单个商户的服务器存储成本、客服支持成本、支付渠道手续费加一起大约每月8元。使用场景的支付意愿小商家最痛的时刻是月底对账一个月货品进出几百上千件手工对账要三四个小时他们的时间成本按每小时50元算一次对账相当于损失200元。付费习惯这群人习惯小额、灵活的支付方式对“一次性付一年”非常抗拒但对“每笔结算时按比例抽一点”并不敏感。业务增长边界这个工具的边际成本很低多服务一个客户几乎不增加额外成本所以不需要用高门槛去过滤低价值用户。这四个要素里没有一个涉及“功能数量”。这本身就是个信号我们之前做了那么多功能可能方向从一开始就跑偏了。功能堆砌的理由是“让客户觉得值”但底层事实说明客户愿意付钱的理由只有一个帮他省时间。清晰度立刻不一样了。3.4 重建阶段从成本、用户价值、场景反推价格基于上面四个要素我们重新设计了定价逻辑彻底抛弃了“功能越多越贵”的框架。新方案是低价的基础服务费按月度对账次数计费。基础服务费只收9元一个月刚好覆盖成本让更多人进来核心的“自动对账”功能按成功对账的订单笔数收费每100笔收5元。一个每月有800笔订单的商家月度费用大约是94049元而旧方案里包含对账模块的“专业版”定价是199元月。这个价格不是拍出来的计算逻辑是单次对账帮他省200元人工一个月四次就是800元我们收49元相当于只拿走他节省下来成本的6%用户价值感极强。不看功能数量不看行业套餐只看“你帮他省了多少钱从中拿走一小份”。这就是从基本要素推导出来的方案而不是从竞品抄过来的方案。这个定价也天然产生了销售逻辑不是“你想用哪个套餐”而是“你每月对几百笔账想不想省下那几百块”话术都变得顺了。3.5 验证阶段A/B测试与小范围试运行方案做出来之后团队内部第一反应是不敢相信毕竟砍掉三档套餐、改成按笔计费简直像在颠覆自己。但我不建议靠嘴上说服任何人直接做了一个灰度验证对照组保留原三档定价实验组使用新方案两周内观察同一渠道进来的新注册用户。数据结果出来实验组的注册到试用转化率提升了17%试用用户里主动发起咨询的比例翻了一倍最关键的是之前最让人头疼的退款率没有上升。后来又跑了一个月实验组里达到付费门槛的用户客单价虽略有下降但整体毛利率反而提升了因为大量长尾商户不再需要专人客服解释套餐自助支付的比重大幅增加销售团队也终于可以把精力从“解释套餐区别”转移到“帮用户理解对账效率”上。这个案例最终证明当定价逻辑回到用户真实成本和真实价值时很多“用户很难搞”的表象会自动消失所谓嫌贵很可能只是你的定价框架本来就建错了。4. 常见误区与排查指南为什么你的“第一性原理”总翻车4.1 误区一把“连续问五个为什么”当成第一性原理我见过最多的翻车现场就是把第一性原理等同于“打破砂锅问到底”。丰田的“五个为什么”确实是个好工具但它和第一性原理有本质区别五个为什么是在同一个问题维度上层层深入解决的是“找到根因”第一性原理是要跳到另一个维度解决的是“重新定义问题”。举一个我自己的失败经历。有一阵子团队线上活动转化率一直是1%上下我带着大家用五个为什么去挖为什么转化率低因为落地页跳出率高为什么跳出率高因为用户觉得内容没价值为什么没价值因为内容定位不准为什么定位不准因为前期调研太少。挖到第五层看起来是“调研太少”于是我们花了两周做了一堆用户访谈结果访谈完还是不知道应该改成什么因为调研得到的意见都是用户随口说的并不代表真实行为。后来我用第一性原理重新过了一遍先不问为什么转化率低而是问“用户在这个产品上最想完成的最小任务是什么”。把这个问题想清楚之后才发现我们思考的一直是“怎么把现有落地页改好”而真正的答案可能是“这个转化动作本身就多余”。两者的分工是五个为什么帮你找到原因第一性原理帮你判断方向。它们不冲突但不能混用。4.2 误区二分解到底层却忘了回到现实还有一种翻车是拆得很彻底拆到最后全是宏大叙事回到现实里根本落不了地。比如有人分析“如何提高团队执行力”一路拆到“公司使命”“文化土壤”“个体自驱力”听起来很底层但这跟没拆一样——因为这些东西你没法在一周之内动手改。我常跟团队说真正的第一性原理一定要回到“可操作的基本约束”上来。你拆出来的基本要素必须能对应到某个具体动作要么是改一行配置要么是调一个流程要么是换一个定价数字。如果拆完之后你手里没有任何一个可以立刻动手的改动点那这个分解就是一场大型头脑风暴表演不是思考方法论。4.3 误区三把类比思维完全丢掉还有些人学了第一性原理之后开始鄙视类比思维看什么都想“重新发明轮子”这其实走反了。第一性原理和类比思维不是对立关系它们是前后两个阶段第一性原理负责在空白地带找到新方向类比思维负责在既定框架里提高效率。绝大多数日常决策类比就够了只有那些“现有方案大量失效”“成本结构明显不合理”“行业默认规则长期没有被质疑过”的问题才值得动用第一性原理。我做技术选型的时候逻辑是分两步走先问“这个项目里哪些前提是绝对不能被挑战的”比如合规底线、主机的物理性能再问“哪些地方我只是习惯沿用而不是本质需要”比如某个旧框架、某个传统部署方式。前者保持类比思维直接抄成熟方案后者才启动第一性原理。顺序不能反反了就是在所有地方都重新造轮子大概率造出一堆半成品。4.4 问题速查表翻车现场对号入座我把这些年见过的问题整理成一张表你可以对照着看自己卡在哪一步| 症状 | 真正的问题 | 排查方向 | | 一直问为什么但问完没结论 | 把五个为什么当成目的 | 确认有没有跳出维度去重新定义问题 | | 拆得很深但不知道下一步做什么 | 拆到了“道理层”没拆到“行动层” | 检查每个基本要素是否满足“有数据有行动” | | 完全抛弃现有成熟方案 | 把类比思维和第一性原理对立 | 分清哪些前提绝对不可挑战哪些只是惯性 | | 方案反常识但没人敢用 | 缺少验证设计 | 找一个最小切口做灰度测试拿数据说话 | | 讨论到最后大家都在说空话 | 没有落地的产出物 | 要求每一步输出一个可写下的结论而不是口头认定 |这张表是我自己复盘用的。每次一个项目走完我都会对着它过一遍看看自己是不是又掉进同一个坑里。说实话掉坑很正常第一性原理本来就是反本能的处处都要跟你的舒适区对着干能发现自己掉进去已经是练习的第一步了。5. 实践心得与工具箱让这套方法真正融入日常5.1 什么类型的问题适合用第一性原理用久了之后我发现第一性原理并不是万能的它更适合四类问题第一成本结构长期不合理、没人解释为什么的领域比如某些行业的报价明显高于原材料成本加合理利润第二现有方案大量失效、大家都在抱怨但从没人挑战规则的问题比如某个流程所有人都嫌麻烦却都按规矩走第三行业里存在大量默认假设、并且这些假设已经很多年没有更新过的问题第四你自己反复遇到同一种困境、怎么优化都绕不开的时候。这四类问题有一个共同特征它们卡在“规则层”而不是“执行层”所以只有在规则层动手才有真正的突破。5.2 什么类型的问题别用第一性原理反过来下面这些情况我劝你别用时间极短的紧急决策。服务器挂了第一件事是恢复服务不是开会重新推导监控体系这是类比和经验救场的时候。已经有成熟最佳实践的领域你如果只是想给个人博客搭个站直接用现成方案别从HTML开始重新发明。还有团队认知水平不一致、没人愿意接受反常识结论的场合第一性原理得出反常识方案之后说服成本极高如果团队没有建立信任机制结果大概率是方案很好但推不动反而把项目拖垮。5.3 我的三个复盘问题和日常训练方法最后分享一个我自己坚持很久的训练方法。每周挑一个问题不管大小用第一性原理的完整五步走一遍然后在笔记本上回答三个复盘问题第一这个问题里我原本默认了哪些规则其中哪些被我成功拆掉了第二重新推导出来的答案和用类比思维得到的答案有什么明显差异第三这次推导里哪一个基本要素最难找为什么难训练多了你会发现最难的不是“拆”的动作而是“敢不敢拆”的勇气。大多数时候我们心里隐约知道某些规则可能有问题但所有人都在按规则走于是我们选择不说。第一性原理逼迫你把这些隐约感变成明确的质疑这个过程本身就是这套方法论最有价值的部分。我甚至会把这个训练用在生活小事上比如“为什么周末一定要出门社交”“为什么这个报表一定要早上九点前发”很多所谓的规矩拆完一轮之后你会发现它只是为了让某个上游环节舒服而不是为了最终结果。我自己在实际用这套方法的时候最大的感受是它不会让生活变容易反而会让生活变麻烦——因为你开始不断发现周围有各种经不起推敲的默认规则你会忍不住想较真。但每一次当你真的把一个旧规则拆散又重新搭起来那种“原来还可以这样”的豁然开朗又会让你觉得刚才的麻烦完全值得。这一章就先写到这里。下一章我会接着讲怎么把从零到一推出来的方案真正推到落地执行——毕竟再漂亮的底层推导最后如果没有组织、资源和节奏来兜底也只是一个漂亮的脑洞。希望这章的五个步骤和那个定价案例能给你下一次面对“大家都这么做”的时刻提供一个不同的角度。