前两天系统陆续告警，海外服务器访问图片 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. 保持谦逊和好奇

技术发展太快，昨天的真理可能今天就过时了。保持开放的心态，随时准备推翻自己的认知。

同时，不要羞于承认「我不知道」。正是这种诚实，才能让你回到基础事实，而不是基于错误的假设做决策。

什么时候用第一性原理？

需要说明的是，不是所有问题都需要用第一性原理。如果每个问题都从零开始思考，效率会非常低。

适合使用第一性原理的场景：

1. 常规方法失效时：试过各种方案都不管用，说明可能方向就错了
2. 面对全新问题时：没有先例可循，必须从基础原理推导
3. 需要创新突破时：想要 10 倍改进而不是 10% 优化
4. 资源极度受限时：必须找到最本质、最经济的解决方案
5. 存在重大分歧时：团队争论不休，需要回到基础事实达成共识

不适合的场景：

1. 有成熟解决方案的常规问题：比如做个登录功能，不需要重新发明轮子
2. 时间紧急的情况：先用已知方案解决燃眉之急，后续再优化
3. 成本敏感的场景：从零开始的成本可能远高于使用现成方案

第一性原理与工程实践

有人可能会问：强调第一性原理，是不是意味着否定所有的最佳实践和设计模式？

并不是。

第一性原理是一种思维方式，不是要你抛弃所有经验。正确的做法是：

1. 理解原理：知道最佳实践背后的原理是什么
2. 判断适用性：这个原理在当前场景下是否依然成立
3. 灵活应用：根据实际情况调整，而不是生搬硬套

举个例子，「数据库索引可以提升查询性能」是个最佳实践。但背后的原理是什么？索引通过空间换时间，用额外的存储来加速查找。

那么在什么情况下这个实践可能不适用？

• 表很小，全表扫描比使用索引更快
• 写入频繁，索引维护成本太高
• 查询模式复杂，单个索引无法覆盖

理解了原理，你就能做出正确的判断。

一个思维框架

最后，分享一个我常用的思维框架，帮助在实际工作中应用第一性原理：

第一步：定义问题

• 问题的表象是什么？
• 影响范围有多大？
• 什么时候开始的？

第二步：收集事实

• 哪些是可以测量的数据？
• 哪些是已经验证的事实？
• 哪些是推测和假设？

第三步：分解结构

• 系统由哪些部分组成？
• 各部分如何相互作用？
• 问题可能出在哪个环节？

第四步：追溯原理

• 这个环节的基本原理是什么？
• 在当前场景下原理是否成立？
• 有什么隐含的假设？

第五步：重构方案

• 基于原理，最简单的解决方案是什么？
• 这个方案的风险和成本如何？
• 如何验证方案的有效性？

第六步：迭代优化

• 实施后效果如何？
• 是否还有改进空间？
• 学到了什么新的认知？

写在最后

技术圈有句话：「没有银弹」。意思是没有一种技术或方法能解决所有问题。第一性原理也不是银弹，但它是一种强大的思维工具。

在这个技术快速迭代、框架层出不穷的时代，掌握第一性原理思维尤其重要。它能帮你在纷繁复杂的技术选择中保持清醒，找到问题的本质，做出正确的决策。

下次遇到棘手的技术问题时，不妨停下来问问自己：

「如果我是第一个遇到这个问题的人，没有任何前人经验可以借鉴，我会怎么思考？」

答案可能会让你惊喜。

真正的高手不是掌握了多少技术，而是掌握了技术背后的原理。当你能够从第一性原理出发思考问题时，你就真正理解了技术的本质。

这条路可能不太好走，需要不断质疑、思考、验证。但相信我，这是成为技术专家的必经之路。

与其做一个熟练的技术工人，不如做一个会思考的问题解决者。

以上。

上周，运营同学小 X 兴冲冲地找我：”老板，我这有个推广方案，算下来获客成本只要 30 块一个，要不要试试？”

她打开 PPT，里面密密麻麻的数据分析，转化漏斗画得很专业。看得出来，她花了不少心思。

“如果按照这个方案，”她继续说道，”投入 10 万，预计能带来 3000 多个新用户。相比其他渠道，这个 ROI 算是很不错了。”

我问了她一个问题：”假设这个方案真的有效，获客成本确实是 30 块。那么，你觉得我们会花 100 万、1000 万来做这个推广吗？”

小 X 愣住了。

“如果答案是不会，”我接着说，”那我们为什么要开始呢？”

这个对话，让我想起了一个词——终局思维，也就是今天我们要聊的。

我们都在用战术的勤奋，掩盖战略的懒惰

这些年，我见过太多类似的场景：

产品经理在复盘报告里写道：”本季度 DAU 增长 15%，用户留存提升 3 个百分点，各项指标都在往好的方向发展。”听起来很棒，但如果你问他：”按照这个增速，我们什么时候能实现盈利？”他可能就答不上来了。

技术负责人说：”我们这个月修复了 200 个bug，系统稳定性提升到 99.98%。”但如果你问：”这个系统三年后还在用吗？”大家都会沉默。

市场部说：”这次活动很成功，获得了 10 万次曝光。”但如果你问：”这 10 万次曝光最终能转化成多少有效用户？”数据就开始模糊了。

为什么会这样？因为我们都习惯了低头赶路，在自己熟悉的地方做事，却忘了抬头看路。

什么是终局思维

简单来说，终局思维就是从终点出发，倒推现在应该做什么。

这有点像下棋。新手下棋，只看眼前一两步。高手下棋，会在脑海中推演整盘棋的走向。当你知道最终要达到什么局面时，每一步棋都会有的放矢。

但在现实中，我们往往是反过来的：

• 因为竞争对手在做，所以我们也要做
• 因为这个功能用户有需求，所以我们要开发
• 因为这个渠道便宜，所以我们要投放

这就像蒙着眼睛开车，也许能往前走，但很可能走错方向，或者原地打转。

一个价值千万的教训

2015 年，我在一家 P2P 公司做技术负责人。那时候正是 P2P 最火的时候，资本疯狂涌入，所有人都在抢市场份额。

我们的策略很简单：烧钱补贴，快速扩张。

运营团队每天都在汇报好消息：

• “今天新增用户 5000！”
• “这个月资金流水过亿了！”
• “我们在这个城市的市场份额已经第二了！”

技术团队也跟着疯狂加班，不断开发新功能，支撑业务增长。最忙的时候，我们一周上线一个新的 APP。

直到有一天，CFO 在高管会上问了一个问题：”按照现在的烧钱速度，我们的钱还能烧多久？”

“大概 6 个月。”

“那 6 个月后呢？”

会议室里一片寂静。

后来的故事你们可能猜到了。寒冬来临，公司资金链断裂，不得不大规模裁员。那些曾经引以为豪的用户数据，在失去补贴后迅速归零。

这件事给我的教训是：如果一件事的终局不成立，那么过程中的所有努力都是徒劳。

终局思维的四个层次

经过这些年的实践和思考，我发现终局思维可以应用在不同的层次上：

1. 个人发展的终局思维

去年，团队里一个小伙伴找我聊职业规划。他很纠结：”我是继续做技术，还是转产品经理？”

我问他：”你想过5年后、10年后的自己是什么样子吗？”

“没想那么远，就是觉得产品经理好像更有前途。”

“那我们换个角度，”我说，”你觉得什么样的人生是成功的？”

他想了很久：”能够创造价值，被人需要，同时收入也不错。”

“那你觉得，是深耕技术更容易达到这个状态，还是转产品？”

这个问题让他陷入了沉思。一周后，他告诉我，他决定继续做技术，但会更多地从产品视角来思考技术问题。

现在，他已经是公司的技术架构师，不仅技术过硬，产品思维也很强。更重要的是，他找到了自己的方向。

2. 团队管理的终局思维

作为管理者，我经常问自己一个问题：三年后，我希望这个团队是什么样子？

基于这个思考，我做了几个看起来「不划算」的决定：

• 投入 20% 的时间做技术分享和技术建设。： 很多人觉得这是浪费时间，直接写代码不是更高效吗？但我知道，一个学习型的团队才能持续成长。
• 鼓励大家参与开源项目。： 短期看，这会占用工作时间。但长期看，这能提升团队的技术视野和影响力。
• 坚持代码评审和文档规范。： 刚开始大家都觉得麻烦，但一年后，新人上手时间从一个月缩短到一周。

这些投入，在当下看都是成本，但从终局看都是投资。

3. 产品决策的终局思维

以某个曾经很火的工具类产品为例，最初是个简单好用的手机清理工具。但为了增长，不断添加功能：

• 新闻资讯（因为能带来广告收入）
• 小游戏中心（因为游戏分发赚钱）
• 电商导购（因为电商返佣高）
• 甚至还加了交友功能

结果原本的核心用户觉得产品变得臃肿，纷纷卸载。新功能带来的用户又留不住，因为有更专业的产品。最后，什么都想做，什么都做不好。

在产品决策时，终局思维体现在三个层面：

• 第一，用户价值的终局。： 你要持续问自己：我们究竟在为用户解决什么问题？这个问题在未来是否依然存在？比如，Notion的终局是”第二大脑”。所以他们的每个功能都围绕着”如何更好地组织和连接信息”。即使用户要求加入视频会议功能，他们也拒绝了，因为这偏离了核心价值。
• 第二，商业模式的终局。：产品最终靠什么赚钱？这个赚钱方式是否可持续？LinkedIn早期尝试过广告模式，但很快意识到，对专业人士来说，付费获得更好的求职和社交机会更合理。所以他们坚定地走付费会员路线，即使增长速度比免费模式慢，但用户质量和收入质量都更高。
• 第三，竞争格局的终局。： 这个市场最终会是什么格局？赢家通吃还是百花齐放？视频会议市场，Zoom 意识到最终会是几家巨头共存（因为企业客户需要备选方案），所以专注于”最好用”而不是”功能最全”。而社交网络市场趋向赢家通吃，所以Facebook会不惜代价消灭或收购潜在对手。

产品决策的终局思维，不是让你预测未来，而是让你在每个决策点上问自己：这个选择是让我们离终局更近，还是更远？如果一个功能、一个项目、一个策略无法回答这个问题，那它可能就不该存在。

4. 技术架构的终局思维

技术选型是最需要终局思维的地方。

2021 年，我们要重构整个技术架构。团队里有很多声音：

• “用最新的技术栈，保持技术领先！”
• “用最稳定的方案，降低风险！”
• “用最流行的框架，方便招人！”

我把大家召集起来，画了一张图：三年后，我们的技术架构应该是什么样子？

经过讨论，我们达成了共识：

• 能支撑 10 倍的业务增长
• 能快速响应业务变化
• 能让团队规模化成长
• 能控制运维成本

基于这个终局，我们选择了微服务架构，虽然初期投入大，但为后续的发展奠定了基础。现在回头看，这个决策帮我们节省了至少一年的时间。

如何培养终局思维

说了这么多，你可能会问：道理我都懂，但怎么才能真正做到呢？

1. 经常问「然后呢」

这是我养成的一个习惯。每当要做决策时，我都会连问三个「然后呢」：

• 我们要做这个功能 → 然后呢？→ 用户会使用 → 然后呢？→ 提升用户活跃度 → 然后呢？→ 增加用户付费意愿…

通过不断追问，你会发现很多决策其实经不起推敲。

这里和我们常用的「5W」方法一样。

2. 学会算长期账

很多时候，我们被短期利益蒙蔽了双眼。

比如，为了完成这个月的 KPI，疯狂做活动拉新。但如果这些用户留存率很低，那么下个月你需要更多的活动来维持数据。这就像吸毒，越陷越深。

正确的做法是算长期账：这个用户的生命周期价值是多少？获客成本是多少？留存率如何？只有这些数据支撑，决策才不会跑偏。

3. 建立自己的原则

终局思维不是要你预测未来，而是要你建立原则。

比如几个原则：

• 不做无法规模化的事情
• 不做违背用户长期利益的事情
• 不做团队无法持续的事情

有了原则，很多选择就变得简单了。

4. 定期复盘和调整

终局不是一成不变的。随着认知提升、环境变化，我们对终局的理解也会改变。

我的做法是，每个季度做一次深度思考：

• 我们的终局假设还成立吗？
• 有什么新的信息需要考虑？
• 当前的路径是否需要调整？

记住，终局思维不是固执，而是在变化中保持方向感。

技术架构上三个常见的误区

在实践终局思维的过程中，特别是在技术决策中，也有不少坑。这里分享几个常见的误区：

误区1：过度设计的陷阱

很多技术团队在设计系统时，容易陷入”一步到位”的幻想。

典型的场景是这样的：某电商公司要做一个订单系统，技术负责人想：”既然亚马逊能做到每秒处理几十万订单，我们也要按这个标准设计。”

于是团队设计了一个”宏伟”的架构：

• 完整的微服务拆分，订单、支付、库存、物流各自独立
• 分库分表设计，预设了 1024 个分片
• 引入了消息队列、分布式缓存、服务网格
• 部署了完整的容器化方案

结果呢？系统上线一年，日订单量还不到 1000 单。那些精心设计的高并发方案，反而成了负担：

• 运维成本极高，需要维护几十个服务
• 开发效率极低，一个简单功能要改好几个系统
• 故障率反而上升，因为链路太长太复杂

教训：终局思维不是让你现在就建造航母，而是让你的小船能够逐步升级成航母。

Netflix 的架构演进就是很好的例子。他们从单体应用开始，随着业务增长逐步拆分，而不是一开始就搞微服务。这种演进式的架构，才是真正的终局思维。

误区2：技术选型的赌徒心态

另一个常见误区是，把赌注全压在某个”未来技术”上。

如当年，GraphQL 刚火起来，某团队在新项目中全面使用。理由很简单：这是未来的趋势，早用早受益。

为了这个决定，他们：

• 花了两个月培训团队
• 重写了所有的 API 接口
• 改造了前端的数据层
• 甚至自己造了一些轮子

一年后回头看，GraphQL 确实有它的优势，但对当前的业务场景来说，REST API 完全够用。投入的成本，远远大于收益。

教训：技术的终局不是最新，而是最合适。

选择技术时，应该考虑：

• 团队的学习成本
• 社区的成熟度
• 实际的业务需求
• 长期的维护成本

不要因为某个技术”可能”是未来，就all in。技术债务，也是债务。

误区3：忽视路径依赖的理想主义

第三个误区是，只看到理想的终局，却忽视了现实的约束。

某个传统企业决定数字化转型，CTO 提出了一个激进的方案：”三年内，全面云原生化。”目标很美好：

• 所有应用容器化
• 全面使用云服务
• 采用 DevOps 文化
• 建立数据中台

但现实是：

• 核心系统是20年前的COBOL代码
• 运维团队平均年龄45岁，没人懂 Kubernetes
• 很多业务逻辑藏在存储过程里
• 合规要求数据不能出企业内网

强推的结果可想而知：

• 老系统改造困难重重，进度一拖再拖
• 团队抵触情绪严重，骨干员工纷纷离职
• 新老系统并存，维护成本翻倍
• 业务部门怨声载道，因为系统经常出问题

忽视现实约束的终局思维，不是思维，是幻想。

更深层的认知

这些误区背后，反映了一个更深层的问题：很多人把终局思维理解成了”终局决定论”。

真正的终局思维是什么？

1. 它是指南针，不是 GPS

   • GPS 告诉你具体怎么走
   • 指南针只告诉你方向
   • 具体路径要根据地形（现实情况）调整

2. 它强调的是进化，不是设计

   • 生物不是被设计出来的，是进化出来的
   • 好的架构也是如此，需要不断适应环境

3. 它追求的是反脆弱，不是完美

   • 完美的系统往往很脆弱
   • 能够从失败中学习、进化的系统才是强大的

举个例子，Linux 的成功不是因为 Linus 一开始就设计好了一切，而是因为它的架构允许持续演进。相比之下，很多”设计完美”的操作系统都消失在历史长河中了。

在技术世界里，活下来的不是最强的，而是最能适应变化的。终局思维的真谛，是让你既有方向感，又保持灵活性。

做时间的朋友

终局思维的本质：不是追求当下的最优解，而是追求长期的最优解。

在这个快节奏的时代，大家都在追求快：

• 快速成功
• 快速变现
• 快速增长

但真正有价值的东西，都需要时间来沉淀：

• 深厚的技术功底，需要时间
• 优秀的团队文化，需要时间
• 忠诚的用户群体，需要时间
• 持续的竞争优势，需要时间

所以，与其做时间的敌人，不如做时间的朋友。

其实，终局思维不是什么高深的理论，它只是提醒我们：

在奔跑之前，先想想要去哪里。

人生很长，不必着急。但人生也很短，不能迷路。

当我们学会站在终点看起点，很多困扰我们的问题都会迎刃而解。因为我们会发现，那些让我们焦虑的事情，在时间的长河里，不过是一朵小小的浪花。如当年韩寒在《三重门》中说的：「都只是棺木上的一缕尘埃」。

而那些真正重要的事情——我们的成长、我们的价值、我们的影响力——会像复利一样，随着时间的推移越来越有分量。

最后，问一句：

如果今天的选择，要用十年后的自己来买单，你还会这样选吗？

想清楚这个问题，你就拥有了终局思维。

愿我们都能成为时间的朋友，在正确的道路上，从容前行。