沟通崩了，问题不在你说什么

你措辞精准、逻辑严密，对方却一脸茫然——这种挫败感，职场人太熟了。问题到底卡在哪？

一、你以为的"清楚"，是对方的"天书"

原文作者Gomati Sekhar举了个扎心的例子：向没学过编程的人解释"递归函数"。

你的解释可能滴水不漏，但对方脑子里没有对应的认知框架。信息传递不是广播，是解码——而解码需要双方共享同一套底层知识。

这解释了为什么技术团队和业务团队永远在互相折磨。同一个词，两张完全不同的地图。

二、好奇心是稀缺品，多数人只有"确认欲"

作者区分了两种状态：真正的好奇（genuine curiosity）vs 只想确认自己已知的东西。

后者是沟通杀手。你问问题不是为了理解对方，是为了等一个机会说"我早就知道"。这种"伪倾听"让对话变成独角戏，双方各说各话。

技术人尤其容易踩这个坑——用专业术语筑起高墙，把不懂的人挡在外面，还怪对方"不专业"。

三、更好的倾听不是技巧，是放下预设

作者没给"积极倾听"的套路清单，而是指向更底层的东西：暂时悬置自己的判断。

不是等对方说完再反驳，是试着从对方的认知起点重新走一遍。这需要消耗认知资源，所以多数人选择偷懒——假装在听，实则在准备下一轮输出。

结果是：会议开了两小时，共识为零，各自带着更坚定的偏见离开。

四、信息密度 vs 理解带宽：产品经理的日常困境

作者没提这个词，但这是技术从业者的核心痛点。你脑子里装着完整的系统架构图，对方只有一张便签纸的容量。

强行塞满只会溢出。有效的沟通是分层交付：先给骨架，再填血肉，最后才是细节。但多数人反着来——生怕漏掉什么，结果对方什么都没接住。

这解释了为什么好的技术文档比好的代码更难写。代码跑给机器，文档写给人类。

五、一个被忽略的变量：情绪带宽

原文没展开，但值得技术人警惕。对方可能正被 deadline 追杀、被老板施压、被家庭琐事分心——此时你的"完美措辞"撞上的是一堵情绪墙。

沟通失败时，先检查通道，再检查内容。通道堵塞，再清晰的信号也是噪音。

数据收束：Gomati Sekhar 这篇文章 2026 年 4 月 27 日发布于 Medium，核心论点就一个——沟通的断裂点不在措辞，而在认知对齐与倾听质量。对每天开 5 个会、写 20 页文档的科技从业者来说，这比任何工具链优化都更值得投入。