架构师必备：解决技术问题当从第一性原理开始
潘锦 2026-10-23 07:15 广东
以下文章来源于：架构和远方
架构和远方专注 AIGC SaaS 技术架构和技术团队管理，坚持分享技术架构和技术团队管理上的思考和总结。对于 AIGC 工程架构、研发效能、团队管理和思维、创业过程中的技术选型、大型网站架构、高性能高可用可扩展架构实现也会有所涉及。
很多所谓的「技术难题」，其实根本不是技术问题。
前两天系统陆续告警，海外服务器访问图片 CDN 经常会出现异常，连接慢，超时，或者下载到一半了失败，错误日志如下：
Connection broken: IncompleteRead(49292 bytes read, 2611057 more expected)',IncompleteRead(49292 bytes read, 2611057 more expected
当看到这些，第一个反应就是加重试和延长超时时间，有一些缓解，但是还是会出错。
当某天下午又有问题出现后，忽然想起，重试和延长超时时间并不是解决本质的问题，只是缓解了问题。
从第一性原理，尝试脱离业务查找图片 CDN 无法访问的问题，尝试发现直接访问存储的外网地址是正常的，但是通过 CDN 会有问题，ping cdn 的域名，延时还能接受。现在看只能是回源的问题，于是找云服务商来定位日志，最终的原因是回源没有带源站地址，导致海外访问受限（为什么，这点云没有做详细解释，模模糊糊说是跨境的问题，因为在国内，之前的配置是没有问题的）。
一、什么是第一性原理？
这个词听起来很高大上，其实道理很简单。
想象你是个外星人，刚刚来到地球，看到人类在用轮子运输货物。你不会想"轮子就应该是圆的"，而是会问"为什么需要运输？""什么形状最省力？"通过基础的物理定律，你会发现圆形确实是最优解。
这就是第一性原理的精髓——抛开所有的经验、惯例和「理所当然」，回到最基础的事实和逻辑，重新推导解决方案。
在技术领域，我们太容易被各种「最佳实践」、「业界标准」、「大厂方案」所影响。遇到问题，第一反应往往是去搜索现成的解决方案，或者套用以前的经验。这本身没错，但当这些方法都不管用时，就需要回到问题的本质了。
二、为什么我们需要第一性原理？
做技术久了，你会发现一个有趣的现象：很多所谓的「技术难题」，其实根本不是技术问题。
比如，系统性能差，大家就想着优化代码、加缓存、扩容。但如果从第一性原理出发，先问问「用户真正的需求是什么？」，可能会发现某些功能根本没人用，直接下线就解决了性能问题。（有些问题不用解决，解决问题本身就行）
再比如，团队总是出线上故障，常规思路是加强测试、完善监控、制定流程。但深入分析会发现，80%的故障都源于某个老旧模块，与其不断打补丁，不如花时间重构它。
技术圈有个词叫「过度工程」，说的就是用复杂的方案解决简单的问题。为什么会这样？因为我们太习惯于在既有框架内思考，忘记了问题的本质可能很简单。
三、技术思维的三个陷阱
在日常工作中，有三种思维陷阱特别容易让我们偏离问题的本质：
1. 经验主义陷阱
"上次遇到类似问题就是这么解决的。"
经验是财富，但也可能是枷锁。技术在变，业务在变，用户在变，昨天的解决方案未必适合今天的问题。
曾经见过一个案例，某电商网站的订单系统经常超时。后台小哥凭经验判断是数据库性能问题，花了大量时间优化 SQL、加索引、分库分表。结果呢？问题有所减轻，但是还是会出现。
后来从头分析才发现，真正的瓶颈是订单生成时要调用外部服务做各种校验和预处理，其中一个服务响应特别慢。如果一开始就从基础事实出发——「订单生成需要多长时间？时间都花在哪里？」——问题早就解决了。
2. 权威崇拜陷阱
「Google是这么做的，肯定没错。」
大厂的方案确实值得学习，但照搬往往水土不服。Google 的解决方案是基于它的业务规模、技术栈、团队能力设计的，这些前提条件你都具备吗？
记得有个创业公司，看到大厂都在搞微服务，也把自己不到 10 人的团队、日活 1 万左右的产品拆成了十几个服务。结果呢？运维成本暴增，开发效率直线下降，最后不得不重新合并服务。
3. 工具依赖陷阱
「用了最新的框架，一定能解决问题。」
技术圈总是充满各种新工具、新框架、新概念。但工具只是工具，关键是要解决什么问题。
曾经见一个项目，前端框架从 jQuery 升级到 Angular，又换成 React。每次重构都说是为了「提升开发效率」和「改善用户体验」。可实际上，用户的核心诉求——"页面加载太慢"——从来没有被真正解决过。
如果从第一性原理思考：用户要的是什么？快速加载。为什么慢？图片太大、请求太多。怎么解决？压缩图片、合并请求。这跟用什么框架其实关系不大。
当然，框架升级并不是一个一定不对的事情，技术的升级也是有必要的，但是需要看其本质是想改变什么。
四、第一性原理的实战应用
说了这么多理论，来看看在实际技术问题中如何应用第一性原理。
案例一：神秘的数据库连接池爆满
有个项目突然开始频繁报数据库连接池满的错误。常规思路是什么？加大连接池、优化慢查询、增加数据库实例。
但我们决定从基础事实开始：
第一步：确认基础事实
连接池大小：100
平均活跃连接数：20-30
报错时连接数：100
每个请求的数据库操作：2-3次
第二步：分解问题
既然平时只用20-30个连接，为什么会突然用满100个？
通过监控发现，每天下午3点左右连接数会激增。这个时间点有什么特殊的？
第三步：追踪本质
深入代码发现，有个定时任务在下午3点执行，它会并发处理大量数据。关键是，这个任务的事务没有正确关闭，导致连接无法释放。
第四步：简单解决
修复事务管理的bug，问题彻底解决。连接池大小维持在50就足够了。
如果一开始就盲目扩大连接池，不仅掩盖了真正的问题，还会增加数据库的负担。
案例二：永远优化不完的首页
另一个经典案例是首页性能优化。产品经理总是抱怨首页加载慢，技术团队已经做了各种优化：
静态资源上CDN ✓
图片懒加载 ✓
接口合并 ✓
服务端缓存 ✓
数据库索引优化 ✓
但用户还是觉得慢。怎么办？
回到基础问题：用户说的「慢」到底是什么？
通过用户访谈发现，他们说的「慢」不是首页加载慢，而是「找到想要的商品慢」。原来首页堆积了太多内容，用户需要不断滚动、寻找，体验自然不好。
真正的解决方案：
简化首页内容
改进搜索和分类
个性化推荐
技术优化做到极致，不如产品设计的一个小改进。这就是第一性原理的力量——让你跳出技术视角，看到问题的全貌。
案例三：微服务还是单体？
这可能是近几年最容易引发争论的架构问题。很多团队一上来就要搞微服务，理由通常是：
大家都在用微服务
微服务更先进
方便团队协作和扩展
容易扩展
但如果用第一性原理思考：
基础问题是什么？
我们要构建一个满足业务需求的系统。
核心约束是什么？
团队规模：5 个人还是 50 个人？
业务复杂度：简单 CRUD 还是复杂业务逻辑？
性能要求：日活千万还是几万或几千？
开发效率：快速迭代还是稳定运行？
从零思考架构：
如果你的团队只有 5 个人，业务逻辑也不复杂，那么单体应用可能是最优选择：
部署简单
调试方便
没有网络开销
事务处理简单
随着业务增长，当单体应用真的成为瓶颈时，再考虑拆分也不迟。这时你会更清楚哪些模块需要独立，哪些可以保持在一起。
记住，微服务不是目标，解决业务问题才是。
五、如何培养第一性原理思维？
知道第一性原理重要是一回事，真正在工作中应用又是另一回事。这里分享一些我的实践经验：
1. 养成追问「为什么」的习惯
遇到问题不要急着动手，先问几个为什么：
为什么会出现这个问题？
为什么以前没有这个问题？
为什么是现在出现？
为什么影响的是这些用户？
每个「为什么」都可能让你更接近问题的本质。
2. 区分表象和原因
医生看病会区分症状和病因，技术问题也一样。
用户说「系统很卡」是症状，真正的原因可能是：
网络延迟高
服务器 CPU 占用率高
数据库死锁
前端渲染性能差
甚至可能是用户电脑太老... （之前工业互联网创业时就遇到过这种情况）
不要被症状迷惑，要找到真正的病因。
3. 建立度量和验证机制
第一性原理强调基于事实，而不是猜测。所以要学会度量和验证：
性能问题：先测量，找到瓶颈在哪
稳定性问题：收集数据，分析故障模式
用户体验问题：做用户调研，理解真实需求
数据会告诉你真相，而不是你的直觉。
4. 练习「从零开始」思考
定期做这样的思维练习：
「如果让我从零开始设计这个系统/解决这个问题，我会怎么做？」
这能帮你跳出现有框架的限制，找到更优解。
5. 保持谦逊和好奇
技术发展太快，昨天的真理可能今天就过时了。保持开放的心态，随时准备推翻自己的认知。
同时，不要羞于承认「我不知道」。正是这种诚实，才能让你回到基础事实，而不是基于错误的假设做决策。
六、什么时候用第一性原理？
需要说明的是，不是所有问题都需要用第一性原理。如果每个问题都从零开始思考，效率会非常低。
适合使用第一性原理的场景：
常规方法失效时：试过各种方案都不管用，说明可能方向就错了
面对全新问题时：没有先例可循，必须从基础原理推导
需要创新突破时：想要 10 倍改进而不是 10% 优化
资源极度受限时：必须找到最本质、最经济的解决方案
存在重大分歧时：团队争论不休，需要回到基础事实达成共识
不适合的场景：
有成熟解决方案的常规问题：比如做个登录功能，不需要重新发明轮子
时间紧急的情况：先用已知方案解决燃眉之急，后续再优化
成本敏感的场景：从零开始的成本可能远高于使用现成方案
七、第一性原理与工程实践
有人可能会问：强调第一性原理，是不是意味着否定所有的最佳实践和设计模式？
并不是。
第一性原理是一种思维方式，不是要你抛弃所有经验。正确的做法是：
理解原理：知道最佳实践背后的原理是什么
判断适用性：这个原理在当前场景下是否依然成立
灵活应用：根据实际情况调整，而不是生搬硬套
举个例子，「数据库索引可以提升查询性能」是个最佳实践。但背后的原理是什么？索引通过空间换时间，用额外的存储来加速查找。
那么在什么情况下这个实践可能不适用？
表很小，全表扫描比使用索引更快
写入频繁，索引维护成本太高
查询模式复杂，单个索引无法覆盖
理解了原理，你就能做出正确的判断。
八、一个思维框架
最后，分享一个我常用的思维框架，帮助在实际工作中应用第一性原理：
第一步：定义问题
问题的表象是什么？
影响范围有多大？
什么时候开始的？
第二步：收集事实
哪些是可以测量的数据？
哪些是已经验证的事实？
哪些是推测和假设？
第三步：分解结构
系统由哪些部分组成？
各部分如何相互作用？
问题可能出在哪个环节？
第四步：追溯原理
这个环节的基本原理是什么？
在当前场景下原理是否成立？
有什么隐含的假设？
第五步：重构方案
基于原理，最简单的解决方案是什么？
这个方案的风险和成本如何？
如何验证方案的有效性？
第六步：迭代优化
实施后效果如何？
是否还有改进空间？
学到了什么新的认知？
九、写在最后
技术圈有句话：「没有银弹」。意思是没有一种技术或方法能解决所有问题。第一性原理也不是银弹，但它是一种强大的思维工具。
在这个技术快速迭代、框架层出不穷的时代，掌握第一性原理思维尤其重要。它能帮你在纷繁复杂的技术选择中保持清醒，找到问题的本质，做出正确的决策。
下次遇到棘手的技术问题时，不妨停下来问问自己：
「如果我是第一个遇到这个问题的人，没有任何前人经验可以借鉴，我会怎么思考？」
答案可能会让你惊喜。
真正的高手不是掌握了多少技术，而是掌握了技术背后的原理。当你能够从第一性原理出发思考问题时，你就真正理解了技术的本质。
这条路可能不太好走，需要不断质疑、思考、验证。但相信我，这是成为技术专家的必经之路。
与其做一个熟练的技术工人，不如做一个会思考的问题解决者。
以上。
作者丨潘锦
来源丨公众号：架构和远方（ID：ArchMoreFuture）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
本文转载自微信公众号「dbaplus社群」，查看原文。版权归原作者所有，如有侵权请联系删除。