第一性原理与追问本质

第 8 章 · 架构师成长

「别人都上微服务了，我们是不是也该拆？」 若只停在这里，答案要么是盲目跟，要么是盲目不跟。第一性原理的追问是：我们要解决的具体问题是什么？ 是单机扛不住、还是多团队要独立发布、还是老代码难以维护？然后问：在这些约束下，满足目标的最小可行方案是什么？ 可能拆两个服务就够，也可能先做模块化与自动化发布更划算。不依赖「大家都这么做」或「大厂都这么搞」，而从基本事实与约束出发推导，就是第一性原理；持续问「为什么」「到底要解决什么」直到触及不可再拆的事实，就是追问本质。本章讲什么是第一性原理、何时用它何时复用既有模式、在技术选型与业务设计中的运用，以及如何避免从众。

一、什么是第一性原理：从基本事实与约束出发推导

第一性原理（First Principles）指的是：不依赖类比、惯例或「别人都这样」，而是从不可再拆的基本事实和约束出发，一步步推导出结论或方案。在架构与决策里，「基本事实」可能是物理定律、业务规则、合规要求、团队能力边界；「约束」可能是时间、预算、技术栈、历史包袱。从这些出发，问「要达成目标，最少必须满足什么」，再推导出可选方案，而不是从「别人怎么做的」反推我们该怎么做。

追问本质则是把「为什么」一层层问下去，直到触及第一性：例如「为什么要上缓存？」→「因为读多写少、DB 扛不住。」→「为什么 DB 扛不住？」→「因为单机 QPS 上限和当前流量。」→「那除了缓存，能否扩容、读写分离、或减少无效查询？」这样就不会停在「大家都上缓存」的层面，而是回到「我们要解决的是读压力」这一本质，再在多种手段里选合适的。

一句话： 第一性原理是「从事实与约束出发推导，而不是从类比与惯例反推」；追问本质是「把『为什么』问到不可再问，再基于那个根因做选择」。

两条路径：从左「别人/惯例→照做→方案？」从右「事实+约束→推导→方案」

案例：选消息队列时，若按惯例会直接对比 Kafka / RabbitMQ / Pulsar 的 feature 列表。按第一性原理会先问：我们要解决什么？是削峰、解耦、还是顺序/可靠？当前量级与团队能力如何？从「必须满足的约束」（如延迟要求、运维能力、已有技术栈）出发，可能推出「当前阶段用云厂商的托管队列就够，不必自建 Kafka」或「必须保证顺序与 exactly-once，只能在某几个里选」。推导出的选项和「别人用啥」可能一致也可能不一致，但理由清晰、可复盘。

二、追问本质：把「为什么」问到根

追问本质可以用一条「为什么链」来练：对每个结论或方案问「为什么需要这个」，再对答案继续问「为什么」，直到落到基本事实或不可再分的需求。下面这张图示意：从表层的「要上某某技术」往下追问，最终落到「要解决什么问题、在什么约束下」。

追问本质：从「要上微服务」问到根因（多团队、流量不均），再从根因推导方案

三、何时用第一性原理、何时复用既有模式

第一性原理适合问题新、约束特殊、或现有做法明显不适配时；复用既有模式适合问题成熟、业界有稳定实践、且我们的约束与别人接近时。两者不互斥：可以先用第一性原理把「要解决什么、约束是什么」想清楚，再在满足约束的候选里选成熟模式。

适合用第一性原理时

问题新、没有现成套路可抄
约束特殊（合规、成本、技术栈、历史包袱与别人不同）
现有做法明显不适配，或「大家都这么做」但说不清为什么
需要向他人解释「我们为什么选这个」并经受质疑

适合复用既有模式时

问题成熟、业界有稳定实践（如 CRUD、缓存、消息队列的常见用法）
约束与多数场景接近，没有特殊限制
时间紧、试错成本高，优先选「被验证过」的方案
团队对某模式已熟悉，复用可降低学习与维护成本

何时从第一性原理推导、何时复用既有模式——可先想清约束再选模式

案例：做「用户行为埋点与分析」时，先按第一性原理问：要分析什么（转化、留存、路径）？数据量级与实时性要求？合规与隐私约束？从这些推出「需要事件模型、可扩展的 schema、可选实时/批处理」。再在满足约束的方案里选：若量不大、实时要求不高，用现成的 Segment + 数仓即可（复用模式）；若量极大、要秒级聚合，再推导到 Lambda/Kappa 或自研方案。这样既不会盲目上最重方案，也不会盲目抄一个不适配的。

四、在技术选型与业务设计中的运用

技术选型： 先列出「必须满足的约束」（性能、一致性、运维能力、团队技能、成本），再问「要解决的核心问题是什么」，然后从约束和问题推导出候选集，而不是从「某大厂用了啥」反推。选型文档里最好有一节「我们为什么需要这些能力、在什么约束下」，这样以后复盘或换人都能看懂当时逻辑。

业务设计： 产品或运营提需求时，用「追问本质」澄清：这个功能要解决的业务问题是什么？成功长什么样？有没有更小的方案能达到同一目标？避免「业务说要 A 就做 A」，做到「业务要的是结果 B，A 只是其中一种手段」，再在多种手段里选性价比高的。

反例：因为大家都这么做。

某团队看到同行都在做「中台」，就立项建商品中台、订单中台，没有先问「我们有多少业务线要复用、复用频率多高、当前重复建设的痛苦有多大」。建完后发现只有一条主业务线在用，其他线仍各写各的，中台成了「多一套要维护的接口」。若一开始用第一性原理问：中台要解决的是多业务线复用与一致性，我们的业务线数量和复用需求是否足够支撑中台投入？ 可能结论是「先做两个业务线共用的能力抽象，而不是一上来就中台品牌」。从众而不从约束与目标推导，容易做出一堆没人用得上的架构。

小结： 第一性原理是从基本事实与约束出发推导，不依赖类比与惯例；追问本质是把「为什么」问到根因再选方案。何时用第一性原理、何时复用模式，取决于问题是否新、约束是否特殊、现有做法是否适配。在技术选型与业务设计中，先想清「要解决什么、约束是什么」，再推导或选择方案，并避免「因为大家都这么做」的从众。

自检： 最近一次技术选型或方案决策，能否写出一段「我们要解决 X、在约束 Y 下，所以选 Z」？若写不出来、只能说出「别人都这么用」，说明还没回到第一性；试着用「为什么链」追问三层，再补上这段话。

五、小结

第一性原理是从基本事实与约束出发推导方案，追问本质是把「为什么」问到不可再问再决策。与「类比/惯例」路径相对：前者从事实与约束推导出方案，后者从别人做法反推。适合用第一性原理时：问题新、约束特殊、现有做法不适配或需经受质疑；适合复用模式时：问题成熟、约束接近、时间紧或团队已熟悉。在技术选型与业务设计中先澄清问题与约束再选方案，避免从众。下一章我们会讲权衡与取舍：架构即权衡，如何显式列出选项与标准、做可逆决策。