你有没有发现，那些技术大佬做决定时，常常说不出为什么？
他们能在会议上侃侃而谈，列出十条理由支持某个方案。但真相可能是：他们先有了直觉，再倒推出了这十条理由。
这不是贬义。这是 expertise 真正的运作方式。
1980年代，心理学家 Gary Klein 跟踪研究消防员指挥官。他问这些人：在燃烧的建筑物里，你们怎么做判断？
答案是："我就是知道地板要塌了"，"那条走廊感觉不对劲"。
Klein 起初以为他们在谦虚。他反复追问，试图挖出背后的分析过程。但没有。根本没有分析。那位指挥官经历过七百场火灾，他的大脑建了一座模式图书馆——而他的意识无法完整读取这座图书馆。
急诊室的老医生走进病房，几秒钟内就知道病人比病历显示的更重。为什么？肤色、姿势、呼吸节奏、病人用眼睛追踪他的方式、角落里家属的坐姿。某种信号组合，在跨进门的瞬间就被处理了。病历是后来写的，医嘱是后来开的。但"要重视这个病人"的决定，发生在门口。
象棋大师看棋盘两秒，就能判断谁占优势。爵士乐手知道独奏者即将落在哪个音上。有经验的父母在孩子说完话之前，就知道他在撒谎。
模式是一样的：多年的重复训练，建造了一个比意识更快的模式探测器。而意识的任务，是为这个探测器已经做出的决定，构造听起来合理的解释。
这事成了，我们叫它"判断力"。这事砸了，或者我们不信任那个人，我们就叫它"偏见"。
机制完全相同。唯一的区别是模式库的质量，以及我们是否信任携带它的人。
在软件行业，这种现象无处不在——只要你开始留意。
架构师听到一个设计方案，立刻觉得哪里不对，然后花四十五分钟构建反对的理由。理由是真的。但理由不是信念的来源。信念来自一个类似的、他们亲眼看着失败的设计。
高级工程师在 code review 时，能在测试失败前嗅出 race condition。他们无法立刻指出哪行代码有问题。但他们知道有问题。
产品经理在需求评审时，能预感某个功能会被用户骂。不是基于数据——数据还没出来。是基于2016年那个被用户骂过的、感觉差不多的功能。
问题在于，这个行业假装这不是真的。
我们写设计文档，要求列出"决策理由"。我们开评审会，期待听到逻辑链条。我们提拔工程师，看的是他们能不能"清晰表达思维过程"。
这些都有价值。但它们描述的是决策的包装，不是决策的源头。
真正的源头往往更安静：一个深夜调试的 memory leak，一次生产事故的 post-mortem，一段三年前读过的代码，一个被否决的 PR 里的评论。这些经验碎片沉入意识底层，变成无法逐条列出的"感觉"。
然后某天，一个新的方案摆在面前。模式匹配启动。结论先于理由到达。
这不是说理由不重要。理由是用来沟通的，是用来说服的，是用来在团队里建立共识的。但如果你是那个做决策的人，你需要诚实面对：那个让你不舒服的"感觉"，可能是你最有价值的数据点。
当然，风险也很明显。
模式库可能是错的。你可能把2020年的教训，套在了2024年完全不同的情境上。你的"感觉"可能其实是偏见，是疲惫，是对某个同事的莫名反感。
所以好的工程师会这么做：他们尊重直觉，但不盲从直觉。他们用理由去检验直觉，而不是用直觉去挑选理由。当直觉和理由冲突时，他们愿意停下来，问自己——这个"感觉"从哪来？
这很难。承认自己的决策有一半是"黑箱操作"，在强调理性的技术文化里，几乎是一种职业风险。
但假装它不存在，代价更大。我们提拔了擅长倒推理由的人，错过了真正擅长识别模式的人。我们过度依赖可文档化的流程，低估了经验积累的沉默价值。我们在面试里问"你怎么思考"，却过滤掉了那些"还没思考就知道"的候选人。
更隐蔽的是，我们让年轻工程师误以为，成长意味着越来越能"说清楚"。
真正的成长，可能是越来越能"感觉对"——同时越来越清楚，哪些感觉值得信任，哪些需要被挑战。
下次你在会议上听到有人说"我就是觉得不太对"，别急着要理由。
问问他们：这个感觉，是从哪个火场带回来的？
热门跟贴