作为一个技术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的价值，不在于他知道所有技术的答案，而在于他拥有一套可靠的决策流程，来带领团队，在充满不确定性的技术世界里，找到那条最适合自己的路。
这个观点你们怎么看？🤞