我最近越来越觉得，对于技术平时应该采取一种诸葛亮式的“观其大略”方法，也就是大概看看一个东西的思路，要解决的问题和解法，实际应用效果咋样等等。换句话说，建立基本概念，但不深入细节。

让 ChatGPT 做概述综述，再针对各个关注点追问是比较好的方法，我感觉节约了我 90% 的时间精力。看书的话就是快速拉完一章（通常拉完一本书的时间还是太长），看个大概，留个印象，不深究。

细节只在动手做的时候去了解，而且并不展开，解决问题达到效果就好。越快越简单搞定细节问题越好，不管是问 ChatGPT 还是查 Google Stackoverflow 还是问人，以快为要。

东西做出来了，出于好奇心，可以查查这些细节背后的东西，展开一下。多数情况下可能是满足“为什么要这样设计”的好奇心。但这块随意，没有硬性要求。

诸葛亮这么做的原因是：东汉造纸术造成了书籍爆发，之前好不容易拿到一本书皓首穷经倒背如流的做法已经落后版本。

我们现在的情况是：各种框架和技术是处于生态系统演进行程中的竞争关系，每过几年“显学”就要发生变动，开发范式和架构就要发生大的变动（看看 Web 领域）。

那么如果你投资过多时间精力在一种具体的框架或者技术上，抠了太多的细节，把一些 specific know-how 搞得太熟，过两年这项框架或者技术本身演进到新版本，或者生态系统演进到新版本将其抛弃，那你的这些投资就变成了沉没成本。

诚然，任何技术细节都有背后的设计思想和技术规律，如果细品也能有技术细节本身以外的收获，把一两种语言或者框架搞得特别熟特别深入，也并不是一件坏事，甚至可以说是一个必要阶段。（类似于先入世才能出世？）

但是作为一种总体策略，我们跟一个具体的语言或者技术绑定过深，投资过多，可能并不是最优解。即使是 C 和 Linux 那样的常青树，虽然不会说没有用武之地，但其生态位是在缩窄的。我们没有必要跟着它们一起特化到这些特定生态位（例如嵌入式），而完全可以反过来跟着整个生态系统一起进化。

也就是说，一般的策略可能是“预测一种技术将要成为显学 → 赶紧投资时间精力 → 变成这种技术的专家或者熟手 → 在同类竞争者不多时取得竞争优势”，于是就是什么火了或者要火培训班和卖课的就一拥而上，过几年开始哀嚎啥啥啥没人要了。这实际上还是一种掌握技能思维，着眼点在技术本身，相对被动（除非你主动做课去割）。

但在计算机领域，技能实际上都可以学会的，新的技能涌现速度也比别的行业快得多。如果我们转变思路，变成能快速入行任何领域，能快速用各种语言各种技术各种框架（包括新的旧的）做出来东西，来满足我们和别人的需要，来丢到市场上看反馈。这就是把技术当工具的思维了，着眼点在整个系统，相对主动。