之前项目上线前两天，登录接口突然随机超时。 我学着用计算思维把问题拆成网络、缓存、数据库三个模块， 每个模块的日志都翻遍了，还画了接近十张时序图， 折腾到第三天下午也没查出来。 最后同事蹲在机房把网线换了个交换机端口，十分钟恢复。
当时我坐在工位上发呆，脑子里冒出一个问题：我到底是在用计算思维解决问题，还是在用计算思维逃避问题？ 那阵子又刚好读到一篇爆款，说计算思维是人人都该掌握的底层能力，分解问题、模式识别、抽象化和算法设计， 仿佛不会这个就没资格当现代人。 我甚至去学人家用“四步法”整理书桌——把桌面拆成书籍、线材、杂物和垃圾， 结果更不知道哪些该扔，脑子里全是类目的边界冲突。 真正让我动手丢掉旧教材的，是想起毕业后真的再没翻开过它们。 这个判断来自体感，不是计算的结果。
拿设计思维和计算思维对比更有意思。 设计师先来一堆模糊发散，慢慢收敛到一个“好像就是它”的答案，再拿原型给用户碰。 计算思维却天生要求步骤可执行，所以一遇上“连什么叫成功都说不好”的事就露怯。 有一次产品经理想让我把推荐逻辑拆成点击率模型和时效模型，然后用一个权重比把它们拼起来。 我反问他“惊喜感”应该放在哪个模型，他半天没答。 后来我终于想明白，计算思维应该叫“可表达思维”——它擅长把你已经想明白的东西丝滑地转成流程， 但它造不出那个“想明白”的瞬间。 现在我习惯在正式动手前把需求先写成几行伪代码。不用运行，只要写出来，哪一步是拍脑门立刻暴露。 就这么个小动作，帮我挡回了好几个荒诞需求。
假如你也正在纠结“别人都说计算思维有用，可我就是使不上劲”，我劝你别硬往思维方式上使劲， 把它当成一把口袋里的瑞士军刀就好。 但用的时候要配上另一种东西，我暂时叫它“现实感”。 计算思维负责拆解和表达，而决策留给那个会犹豫、会累、会想起某阵风的你。 我现在遇到重要选择，会先把条件列成一张可比较的表，然后合上电脑下楼走二十分钟， 回来以后往往答案已经冒出来了，而它并不在表里。 每次做完理性拆解，我都会强制自己停十分钟，再用直觉总览一遍，这个习惯已经帮我避开好几个坑。 如果当初处理超时问题能先写一句“现象：随机超时，与用户无关”，而不是急着拆解，可能早就会检查到物理链路了。 说了这么多，我的立场其实就一条：计算思维是手艺，不是哲学。 手艺值得练，但别让锤子定义你看到的所有问题。
