这是事实，还是规矩？——第一性原理在带人、处人和做项目里的用法

先把结论放这儿：第一性原理不要求你更聪明，它只要求你分清一件事——哪些约束是天生的，哪些只是别人告诉你的。

这句话听起来平淡，但真正拿它去动手，能拆掉的东西会比你预想的多，也能保住的比你预想的少。这篇只回答一个问题：遇到一个决定、一场摩擦、一个期限，怎么分辨里面哪些是真的动不了，哪些其实只是习惯。最后一节讲的是最容易翻车的地方，也最值得先看。

它其实就是亚里士多德的一句话

亚里士多德在《物理学》里给过一个说法：每个知识体系里都有一些不能再往前推的基本命题，其余的结论都从它们推出来。这句话后来被叫作第一性原理，听起来像个高级方法论，实质只是一句提醒——你的推理得有个真实的起点，不能从别人的结论起步。

现代语境里，它几乎专指跟「类比推理」对着干的那一套。

	类比推理（多数人的默认）	第一性原理
起点	别人怎么做、上次花了多少	这件事的底层事实
动作	在现有做法上做微调、砍价	拆到不能再拆，重新往上搭
结果	改一个数，动不了结构	可能得出「这条路根本不用走」
风险	把别人的天花板当成自己的天花板	拆过头，把有用的东西也拆了

马斯克那个电池的例子被引用得最多：电池组的市场价长期在每千瓦时五六百美元这个量级，按类比推理，能做的只有跟供应商磨价；按第一性原理，就把电池拆成镍、铝、碳、聚合物这些原材料，去看大宗商品市场上的价格，算下来只要八十美元上下。中间那四五百美元不是物理定律，是工艺、良率和规模。

那个差价就是问题的全部：它不是天上掉下来的价格，它是某个工程问题的当前答案。 是当前答案，就可以改写。

三步，而且真的只有三步

第一步，把默认接受的结论写出来。这一步最难，因为默认的东西通常看不见。你在会上脱口而出「这个得上会过一下」「这个得找原厂报个价」，这两句话背后都藏着没被检查过的假设。

第二步，逐条追问底层。追问的姿势不是「为什么」，是：「这条约束属于哪一类——物理、生理、时间、法律、合同，还是以前都这么做？」

第三步，只从留下来的硬约束往上重建方案。硬约束之外的东西都是可选项，不是前提。

分辨的时候有个笨办法很好用：把约束分成三类。

• 天然的：光速、人的注意力时长、一天二十四小时、材料强度、监管要求、已经签掉的合同。这一类别碰，碰了只会浪费你的信誉。
• 历史的：组织的习惯、行业的惯例、三年前某次事故之后加的一道检查。这一类是重灾区，也是所有改进的空间所在。
• 某个人的偏好：最常见，也最容易被伪装成第二类。有人把「我不放心」说成「流程要求」。

真正难的不是拆，是知道自己在拆哪一类。下面几个场景，都是同一套动作。

带人：先问这个动作在解决什么问题

周会到底要不要开，别在会上讨论。 会议的底层需求只有三样：信息同步、当场要拍板的事、目标对齐。把这三样拆开单独看，很多周会就没有存在理由了——如果信息同步早就由一份随时能看的文档完成，那这场会只是在复述文档。这时候正确的答案不是「周会缩短到三十分钟」，而是「取消周会，另开一个只处理需要拍板事项的短会」。会议不是管理本身，它是补信息差的工具。信息差没了，工具就该收起来。

「缺一个运维」这句话，通常下得太快。 更靠前的问法是：要消灭的是哪一类故障、哪一类重复的手工劳动？答案经常不是加一个人，而是把某台机器退役、把某个动作自动化、把某段流程从两个人经手改成一个人。先说清楚要消灭什么，再决定拿什么去消灭。顺序反过来，人招进来之后你会发现他一天干两小时活，剩下时间在维护「有这个岗位」这件事本身。

人不动，原因只有四层。 不知道做什么（目标模糊）、不会做（能力）、不想做（动机）、做不了（权限、资源、卡在别的部门）。这四层得一层层看下去，因为大部分管理的激励工具只对第三层有效。如果实际卡在第四层——他没有那个权限，或者上游根本不给他数据——你加压，他唯一能做的动作就是让数字好看一点。这不是人品问题，是压力被导向了唯一可动的地方。

信任的底层只有两条：行为可预测、利益方向一致。 团建不产生这两条。一顿饭吃完，第二天的分工还是靠猜、承诺还是随时改，那信任一分都没长。可预测来自公开的决策规则——什么情况下会怎么判，事先说清楚；利益一致来自把目标绑在同一个可核查的结果上。这两条做到了，不需要饭局；做不到，饭局只能让失望来得晚一点。

处人：人是被自己的约束说服的

职场摩擦的第一层分解：信息不对称、情绪需求、真实的利益冲突。放在这上面看，八成以上的摩擦其实是第一层——对方不知道你已经知道的信息，或者你不知道他头上压着什么。把这类问题当成「沟通态度」去处理，就会一直空转：双方都在努力表态，谁也没补上那个信息差。

所以讲道理经常没用，原因不是道理不好。 人不是先判断对错再行动，是先有立场再找理由，这个过程在自己脑子里也察觉不到。你要找的不是更有力的论证，而是他在意的那个约束：他的上级怎么考核他、他要担什么风险、他要在谁面前保住面子、他手上有没有这个人。方案只有嵌进他的约束里才会真的被接受。说服的本质不是把对方说服，是给对方的处境里放一个可行的选项。

反过来对自己也有用：当你特别想争赢某件事的时候，先问自己一句——我现在是在保护哪一个约束？十次里有六七次，答案是「我不想承认我之前的判断错了」。那这就不是事实之争，别再花时间找论据了。

关系维护的底层很土：高频、低成本、双向。 一次大人情换来的是人情债，不是关系结构；对方会因为欠你而回避你，不会因为欠你而信任你。真正积累的是那种随时能问一句话、十分钟能解决的小事——它可重复，而且双方都在付。

做项目：四件事只能动三件

工期不要用类比估。「上次类似的项目三个月」这种算法会系统性地偏乐观，因为每个项目都认为自己这次是例外——这就是规划谬误，它是结构性的，不是谁不认真。第一性原理的做法是把工作拆成本身能落到「谁、几天、在等谁」的工作包，再叠加真实的资源冲突（那个人同时在三个项目上）。这样做出来的数字通常比类比更难看，但你敢对它负责。

用户说要「导出 Excel」，别马上开始做导出。 真实需求很可能是「每周给领导一份能看的东西」。那么该交付的是一份自动生成的图表加一封定时邮件，而不是一个导出按钮。听到解决方案的时候，退回去看问题本身——用户描述的是他想到的手段，不是他的困境。

范围、时间、成本、质量，四个里只能动三个。 这不是谈判技巧，是算术。范围蔓延的本质，是有人想在不改另外三个的前提下塞进一个新变量；它在物理上就不成立。把这句话平静地说出来，比陪着开三次协调会有用——因为它把「你能不能想办法」变成了「你选哪一个」。

风险不要列清单。「这个项目可能有哪些风险」这种问法太抽象，答案必然是套话。换成：「哪一个环节一旦断了，整个交付立刻停？」要找的是单点，不是清单的长度。一个项目通常只有两三个真正的单点，它们值得你亲自去确认。

技术上的判断也是同一套动作。一台服务器的配置够不够、一块显卡能不能跑起某个模型，标准流程不是看厂商话术，也不是「大家都这么配」，而是把显存、内存带宽、上下文长度、实测吞吐这些数摆出来，算得出来就上，算不出来就换。当你把判断落到可以被验算的量上，争论就自动结束了。

有三种情况，别用它

这一节比前面所有内容都重要，因为误用它的代价比不用它更大。

一、老规矩大多是当年某次事故换来的。 拆之前，先问它当初解决了什么问题。为什么两个系统明明能对接，却坚持每月人工对一次账？很可能因为五年前出过一次错账，回滚了一次，从那以后多了这道人工检查——而当年知道原因的人已经离职了。不问就拆，你拆掉的不是一个冗余动作，是一个真实存在过的故障的补丁。真正的第一性原理是从问题出发，不是从「推翻一切」出发。后者只是形式上的反叛。

二、人的领域有涌现属性。 组织氛围、士气、默契这些东西不能从「每个人都理性」推出来。把人简化成利益最大化的个体，模型会很简洁，也会很错。这一块该用的是观察和经验，不是推导。

三、成本很高。 每个决定都从头推一遍，人会瘫痪。正确的用法是把它省着用：只在代价大、结论可疑、或者已经反复失败的地方用——重大选型、长期制度、那个第三次出问题的环节。日常执行继续用经验和类比，那不是懒惰，那是把预算花在刀刃上。

回到开头那个问题：怎么分辨哪些是事实、哪些只是别人告诉你的？

答案里没有聪明，只有耐心——把约束一条条摊开，看它属于天然的那一类，还是某个已经不记得原因的昨天。前者认了，后者值得动手。

大部分让人憋屈的规矩，其实是一次谁都不记得的妥协留下来的。它能不能拆，取决于你知不知道它当初在挡什么。