165 阅读
在工程学（包括软件工程、机械、电子、建筑等）中，除了追求精简的奥卡姆剃刀原理（Occam’s Razor），还有几个公认的、跨学科的底层原则。这些原则是无数工程师用鲜血、资金和失败换来的底层逻辑，掌握它们能让你在面对复杂系统时保持清醒。
我们可以将这些底层原则分为三大核心维度：设计与架构、系统与容错、认知与执行。
一、 设计与架构原则（关于“如何创造”）
1. 奥卡姆剃刀的孪生兄弟：KISS 原则 (Keep It Simple, Stupid)
- 核心内涵：大多数系统如果保持简单，而不是搞得复杂，工作得最好。
- 工程应用：奥卡姆剃刀侧重于“假设和理论”的精简，而 KISS 侧重于“结构和设计”的简单。不要为了彰显技术而引入不需要的框架、零件或奇技淫巧。最好的零件，就是没有零件，因为它绝不会坏。
2. 帕累托法则 (Pareto Principle / 80-20 法则)
- 核心内涵：在很多事件中，大约 80% 的结果产生于 20% 的原因。
- 工程应用：
- 性能优化：80% 的系统延迟通常由 20% 的核心代码或瓶颈引起（不要盲目过早优化）。
- 需求管理：20% 的核心功能满足用户 80% 的使用场景（MVP – 最小可行性产品的理论支撑）。
3. 高内聚，低耦合 (High Cohesion, Low Coupling)
- 核心内涵：一个模块内部的各个元素应该紧密相关（内聚），而模块与模块之间的依赖应该尽可能少且清晰（耦合）。
- 工程应用：无论是软件的微服务架构、芯片的模块化设计，还是汽车零件的组装，这一原则决定了系统是否易于扩展、维护和Debug。如果动了 A 模块导致远在天边的 B 模块崩溃（屎山代码或连锁设计灾难），就是违反了这一原则。
二、 系统与容错原则（关于“如何防错”）
4. 墨菲定律 (Murphy’s Law)
- 核心内涵：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。
- 工程应用：这是工程学的安全基石。真正的工程师从不寄希望于“运气”或“用户会规规矩矩操作”。
- 防御性设计：必须做最坏的打算。
- 衍生原则：容灾与冗余（Redundancy）。例如飞机的双发动机、服务器的双机热备、数据的多中心备份。
5. 鲁棒性原则 / 波斯塔尔法则 (Robustness Principle / Postel’s Law)
- 核心内涵：发送时要保守，接收时要开放（Be conservative in what you do, be liberal in what you accept from others）。
- 工程应用：源自早期互联网 TCP 协议的设计。
- 你输出的数据或产品，必须严格符合标准、极其规范（保守）。
- 你接收外部的输入或用户的奇葩操作时，要具备极强的包容性和容错能力，不能轻易崩溃（开放）。
6. 核心链条的“单一故障点”原则 (SPOF – Single Point of Failure)
- 核心内涵：系统中的某个部件一旦失效，会导致整个系统停止工作。
- 工程应用：在设计系统架构时，必须识别并消除 SPOF。如果一个大型系统的生死取决于某一个网络网关、某一个特定的轴承、或者某一个员工的个人状态，这个系统就是极度脆弱的。
三、 认知与执行原则（关于“如何思考”）
7. 第一性原理 (First Principles Thinking)
- 核心内涵：剥离事物的表象和层层叠加的经验，将其拆解到最基本的真理（物理学定律、数学逻辑等），然后从这个源头重新向上推导。
- 工程应用：打破“过去大家都这么做”的路径依赖。
- 埃隆·马斯克颠覆航天和电动车的核心武器。 电池太贵？不要看市场上卖多少钱，去算算锂、钴、镍、石墨等原材料在伦敦商品交易所的原子成本是多少，然后从头设计制造工艺。
8. 康威定律 (Conway’s Law)
- 核心内涵：设计系统的组织，其产生的设计等同于该组织的沟通结构。
- 工程应用：组织架构决定系统架构。如果三个团队分别开发一个系统的不同部分，最终这个系统大概率会有三个独立的子系统。工程问题往往不止是技术问题，更是人的沟通和管理问题。
9. 权衡取舍与天下没有免费的午餐 (Trade-off / No Free Lunch)
- 核心内涵：任何优化的背后都有代价，不存在在所有维度（时间、空间、成本、质量、安全）上都完美的方案。
- 工程应用：
- 在分布式系统中，有 CAP定理（一致性、可用性、分区容错性只能三选二）。
- 在项目管理中，有 项目管理三角形（时间、成本、质量相互制约）。
- 优秀的工程师不会盲目追求“最好”，而是追求在当前约束条件下的“最适合（Trade-off）”。
总结：如何应用这些原则？
学习工程学时，可以把这些原则当成你的底层检查清单（Checklist）：
- 当你设计一个新东西时，问问自己：它够 KISS 吗？符合第一性原理吗？
- 当你评估一个现有的复杂系统时，问问自己：它的模块是否高内聚低耦合？哪里是它的单一故障点（SPOF）？
- 当你面对突发故障时，合上眼默念：墨菲定律诚不我欺，赶紧去找那 20% 的核心瓶颈。
掌握了这些，你就超越了单纯的“搬砖”或写代码，开始具备控制复杂系统的“主导者”思维了。