你措辞精准、逻辑严密，对方却一脸茫然——这种挫败感，职场人太熟了。问题到底卡在哪？
一、你以为的"清楚"，是对方的"天书"
原文作者Gomati Sekhar举了个扎心的例子：向没学过编程的人解释"递归函数"。
你的解释可能滴水不漏，但对方脑子里没有对应的认知框架。信息传递不是广播，是解码——而解码需要双方共享同一套底层知识。
这解释了为什么技术团队和业务团队永远在互相折磨。同一个词，两张完全不同的地图。
二、好奇心是稀缺品，多数人只有"确认欲"
作者区分了两种状态：真正的好奇（genuine curiosity）vs 只想确认自己已知的东西。
后者是沟通杀手。你问问题不是为了理解对方，是为了等一个机会说"我早就知道"。这种"伪倾听"让对话变成独角戏，双方各说各话。
技术人尤其容易踩这个坑——用专业术语筑起高墙，把不懂的人挡在外面，还怪对方"不专业"。
三、更好的倾听不是技巧，是放下预设
作者没给"积极倾听"的套路清单，而是指向更底层的东西：暂时悬置自己的判断。
不是等对方说完再反驳，是试着从对方的认知起点重新走一遍。这需要消耗认知资源，所以多数人选择偷懒——假装在听，实则在准备下一轮输出。
结果是：会议开了两小时，共识为零，各自带着更坚定的偏见离开。
四、信息密度 vs 理解带宽：产品经理的日常困境
作者没提这个词，但这是技术从业者的核心痛点。你脑子里装着完整的系统架构图，对方只有一张便签纸的容量。
强行塞满只会溢出。有效的沟通是分层交付：先给骨架，再填血肉，最后才是细节。但多数人反着来——生怕漏掉什么，结果对方什么都没接住。
这解释了为什么好的技术文档比好的代码更难写。代码跑给机器，文档写给人类。
五、一个被忽略的变量：情绪带宽
原文没展开，但值得技术人警惕。对方可能正被 deadline 追杀、被老板施压、被家庭琐事分心——此时你的"完美措辞"撞上的是一堵情绪墙。
沟通失败时，先检查通道，再检查内容。通道堵塞，再清晰的信号也是噪音。
数据收束：Gomati Sekhar 这篇文章 2026 年 4 月 27 日发布于 Medium，核心论点就一个——沟通的断裂点不在措辞，而在认知对齐与倾听质量。对每天开 5 个会、写 20 页文档的科技从业者来说，这比任何工具链优化都更值得投入。
热门跟贴