溝通崩了，問題不在你說什么

你措辭精準、邏輯嚴密，對方卻一臉茫然——這種挫敗感，職場人太熟了。問題到底卡在哪？

一、你以為的"清楚"，是對方的"天書"

原文作者Gomati Sekhar舉了個扎心的例子：向沒學過編程的人解釋"遞歸函數"。

你的解釋可能滴水不漏，但對方腦子里沒有對應的認知框架。信息傳遞不是廣播，是解碼——而解碼需要雙方共享同一套底層知識。

這解釋了為什么技術團隊和業務團隊永遠在互相折磨。同一個詞，兩張完全不同的地圖。

二、好奇心是稀缺品，多數人只有"確認欲"

作者區分了兩種狀態：真正的好奇（genuine curiosity）vs 只想確認自己已知的東西。

后者是溝通殺手。你問問題不是為了理解對方，是為了等一個機會說"我早就知道"。這種"偽傾聽"讓對話變成獨角戲，雙方各說各話。

技術人尤其容易踩這個坑——用專業術語筑起高墻，把不懂的人擋在外面，還怪對方"不專業"。

三、更好的傾聽不是技巧，是放下預設

作者沒給"積極傾聽"的套路清單，而是指向更底層的東西：暫時懸置自己的判斷。

不是等對方說完再反駁，是試著從對方的認知起點重新走一遍。這需要消耗認知資源，所以多數人選擇偷懶——假裝在聽，實則在準備下一輪輸出。

結果是：會議開了兩小時，共識為零，各自帶著更堅定的偏見離開。

四、信息密度 vs 理解帶寬：產品經理的日常困境

作者沒提這個詞，但這是技術從業者的核心痛點。你腦子里裝著完整的系統架構圖，對方只有一張便簽紙的容量。

強行塞滿只會溢出。有效的溝通是分層交付：先給骨架，再填血肉，最后才是細節。但多數人反著來——生怕漏掉什么，結果對方什么都沒接住。

這解釋了為什么好的技術文檔比好的代碼更難寫。代碼跑給機器，文檔寫給人類。

五、一個被忽略的變量：情緒帶寬

原文沒展開，但值得技術人警惕。對方可能正被 deadline 追殺、被老板施壓、被家庭瑣事分心——此時你的"完美措辭"撞上的是一堵情緒墻。

溝通失敗時，先檢查通道，再檢查內容。通道堵塞，再清晰的信號也是噪音。

數據收束：Gomati Sekhar 這篇文章 2026 年 4 月 27 日發布于 Medium，核心論點就一個——溝通的斷裂點不在措辭，而在認知對齊與傾聽質量。對每天開 5 個會、寫 20 頁文檔的科技從業者來說，這比任何工具鏈優化都更值得投入。