003.“第一性原理”：如何做技术决策
出处：掘金
原作者：ErpanOmer
作为一个技术 Leader，我最常被问到的问题就是：“老大，我们这个新项目，到底该用 A 方案还是 B 方案？”
而最安全、也最无用的回答，就是那句经典的 —— 看情况决定
看情况当然是对的，因为所有技术决策都离不开具体的业务场景、团队能力和时间窗口。但如果我们的思考只停留在这里，那决策过程就很容易变成凭感觉、随大流，或者谁声音大听谁的
为了摆脱这种决策模式，我花了很长时间，总结出了自己的一套第一性原理
什么是技术决策的第一性原理？
第一性原理这个词，最近几年很火。它的核心，就是回归本质，从事实出发
说白了，就是把一个复杂的问题，拆解成最基础、最不可动摇的事实，然后从这些事实出发，一步步推导出结论
在技术决策中，它最大的作用，是帮助我们对抗类比思维的诱惑
- 类比思维：“A 公司用了微前端，我们也用吧！”、“B 框架在 GitHub 上 Star 最多，我们就选它！”
- 第一性原理思维：“我们的业务模块，真的需要被独立部署和迭代吗？我们团队的规模和 DevOps 能力，是否足以支撑多个独立仓库的维护成本？”
你看，后者虽然更累，但它能让你做出真正适合你的决策，而不是盲目地抄别人的作业
我个人的技术决策清单
下面就是我的 4 条第一性原理，每次遇到重要的技术决策时，我都会用它们来拷问自己和团队
问题和工具匹配原则
“我们遇到的，真的是个钉子吗？还是我们只是想试试手里的新锤子🔨？”
这是我放在第一位的原则。永远从问题出发，而不是从解决方案出发
工程师，尤其是热爱技术探索的工程师，很容易犯一个毛病：看到一个很酷的新技术，就总想在项目里找个地方把它用上（所谓的技术或简历驱动开发）
举个例子：
前段时间，团队里有同学提议，要在我们新的中后台项目里，引入 GraphQL
我的第一反应不是去讨论 GraphQL 的好坏，而是拉着团队一起回答几个问题：
- 我们当前遇到了什么现有 REST API 无法解决的、极其痛苦的问题吗？
- 前端是否真的需要那么高的查询灵活性？我们的后端接口，是不是已经足够稳定和定制化了？
- 我们团队，包括后端同学，对 GraphQL 的学习成本和服务端改造的成本，有充分的评估吗？
最后我们发现，对于我们这个业务相对固定的中后台来说，引入 GraphQL 的复杂性，远远大于它带来的收益。我们不能因为手里拿着锤子，就把所有东西都看成钉子
可逆性原则
“我们做的这个决定，是一扇双向门🚪，还是一扇单向门？”
这是亚马逊创始人贝索斯提出的一个著名心智模型
- 双向门：决策是可逆的，如果你选错了，可以比较轻松地退出来，再走另一扇门
- 单向门：决策是不可逆的，或者逆转的成本极高。一旦走进去，就很难回头
我们应该把绝大部分的精力和争论，都花在单向门的决策上
双向门：为项目选择一个状态管理库，是用 Zustand 还是 Valtio？它们都是轻量级的，API 也很简洁。即使我们选错了，未来花一两个星期的时间，迁移成本是完全可以接受的。对于这类决策，我会鼓励团队快速尝试，不用过度纠结
单向门：选择整个项目是基于 Next.js 的 App Router（服务端组件），还是基于 Vite 的纯客户端渲染（CSR）？这个决定，会深远地影响我们后续的开发模式、部署方式、性能模型、招聘标准。这是一个典型的单向门，一旦选定，未来想要更换架构，成本是灾难性的。对于这类决策，我会组织多次的深入调研、技术分享和方案评审
维护成本
“这个技术方案，半年后、一年后，谁来为它维护？”
一个技术方案的成本，绝不只是前期的开发成本。总拥有成本（TCO） = 开发成本 + 维护成本 + 学习成本 + 沟通成本... 而其中，维护成本往往是最大、也最容易被忽略的
举个例子:
一个新人提议，用一个 GitHub 上刚火起来的、非常酷的 CSS-in-JS 库，它能解决我们现在方案的一些小问题
我会问他几个问题：
- 这个库的社区活跃吗？作者弃坑的风险有多大？
- 它的文档和生态完善吗？遇到问题，我们能快速找到解决方案吗？
- 半年后，当作者不再维护时，我们团队有能力接手它的源码，自己维护吗？
- 如果我明天招一个新人，他需要花多久才能上手这个小众的库？
很多时候，选择一个更无聊、但更主流、社区更稳定的技术（比如 Tailwind CSS 或 CSS Modules），对团队的长期健康来说，是更明智的选择
简单性原则
“有没有更简单的方案，能实现 80%的效果？”
如无必要，勿增实体。这是架构设计中的奥卡姆剃刀 原理。当面对两个都能解决问题的方案时，永远选择那个更简单的。复杂性，是软件质量的头号杀手
为了实现一个简单的、跨组件的通信，我们真的需要引入 Redux 吗？
一个简单的 React Context，甚至一个从上层传下来的回调函数，是不是就足够了？
我们不要为了追求所谓的架构完整性，而去堆砌我们根本不需要的复杂性
在很多场景下，没有设计，就是最好的设计
写在最后
第一性原理，它给我的不是一个答案，而是一个提问的框架
它强迫我慢下来，强迫我穿透技术的表象，去思考那个最本质的问题：
我们到底要解决什么？我们付出的代价是什么？我们能否承担这个代价？
一个技术 Leader 的价值，不在于他知道所有技术的答案，而在于他拥有一套可靠的决策流程，来带领团队，在充满不确定性的技术世界里，找到那条最适合自己的路