北京
你有沒有發現，那些技術大佬做決定時，常常說不出為什么？
他們能在會議上侃侃而談，列出十條理由支持某個方案。但真相可能是：他們先有了直覺，再倒推出了這十條理由。
這不是貶義。這是 expertise 真正的運作方式。
1980年代，心理學家 Gary Klein 跟蹤研究消防員指揮官。他問這些人：在燃燒的建筑物里，你們怎么做判斷？
答案是："我就是知道地板要塌了"，"那條走廊感覺不對勁"。
Klein 起初以為他們在謙虛。他反復追問，試圖挖出背后的分析過程。但沒有。根本沒有分析。那位指揮官經歷過七百場火災，他的大腦建了一座模式圖書館——而他的意識無法完整讀取這座圖書館。
急診室的老醫生走進病房，幾秒鐘內就知道病人比病歷顯示的更重。為什么？膚色、姿勢、呼吸節奏、病人用眼睛追蹤他的方式、角落里家屬的坐姿。某種信號組合，在跨進門的瞬間就被處理了。病歷是后來寫的，醫囑是后來開的。但"要重視這個病人"的決定，發生在門口。
象棋大師看棋盤兩秒，就能判斷誰占優勢。爵士樂手知道獨奏者即將落在哪個音上。有經驗的父母在孩子說完話之前，就知道他在撒謊。
模式是一樣的：多年的重復訓練，建造了一個比意識更快的模式探測器。而意識的任務，是為這個探測器已經做出的決定，構造聽起來合理的解釋。
這事成了，我們叫它"判斷力"。這事砸了，或者我們不信任那個人，我們就叫它"偏見"。
機制完全相同。唯一的區別是模式庫的質量，以及我們是否信任攜帶它的人。
在軟件行業，這種現象無處不在——只要你開始留意。
架構師聽到一個設計方案，立刻覺得哪里不對，然后花四十五分鐘構建反對的理由。理由是真的。但理由不是信念的來源。信念來自一個類似的、他們親眼看著失敗的設計。
高級工程師在 code review 時，能在測試失敗前嗅出 race condition。他們無法立刻指出哪行代碼有問題。但他們知道有問題。
產品經理在需求評審時，能預感某個功能會被用戶罵。不是基于數據——數據還沒出來。是基于2016年那個被用戶罵過的、感覺差不多的功能。
問題在于，這個行業假裝這不是真的。
我們寫設計文檔，要求列出"決策理由"。我們開評審會，期待聽到邏輯鏈條。我們提拔工程師，看的是他們能不能"清晰表達思維過程"。
這些都有價值。但它們描述的是決策的包裝，不是決策的源頭。
真正的源頭往往更安靜：一個深夜調試的 memory leak，一次生產事故的 post-mortem，一段三年前讀過的代碼，一個被否決的 PR 里的評論。這些經驗碎片沉入意識底層，變成無法逐條列出的"感覺"。
然后某天，一個新的方案擺在面前。模式匹配啟動。結論先于理由到達。
這不是說理由不重要。理由是用來溝通的，是用來說服的，是用來在團隊里建立共識的。但如果你是那個做決策的人，你需要誠實面對：那個讓你不舒服的"感覺"，可能是你最有價值的數據點。
當然，風險也很明顯。
模式庫可能是錯的。你可能把2020年的教訓，套在了2024年完全不同的情境上。你的"感覺"可能其實是偏見，是疲憊，是對某個同事的莫名反感。
所以好的工程師會這么做：他們尊重直覺，但不盲從直覺。他們用理由去檢驗直覺，而不是用直覺去挑選理由。當直覺和理由沖突時，他們愿意停下來，問自己——這個"感覺"從哪來？
這很難。承認自己的決策有一半是"黑箱操作"，在強調理性的技術文化里，幾乎是一種職業風險。
但假裝它不存在，代價更大。我們提拔了擅長倒推理由的人，錯過了真正擅長識別模式的人。我們過度依賴可文檔化的流程，低估了經驗積累的沉默價值。我們在面試里問"你怎么思考"，卻過濾掉了那些"還沒思考就知道"的候選人。
更隱蔽的是，我們讓年輕工程師誤以為，成長意味著越來越能"說清楚"。
真正的成長，可能是越來越能"感覺對"——同時越來越清楚，哪些感覺值得信任，哪些需要被挑戰。
下次你在會議上聽到有人說"我就是覺得不太對"，別急著要理由。
問問他們：這個感覺，是從哪個火場帶回來的？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
