AI 工具仍在收取「对话税」
Tea and Bits 的一篇文章谈到了和 LLM 对话带来的疲惫感,也提醒我们:AI 编程工具需要减少社交层面的管理成本,而不只是生成更多内容。
AI 驱动 · 每小时限 20 次请求

Ohad 在 Tea and Bits 的文章里提出,LLM 让人疲惫,是因为它们要求用户在本该是工具的东西上消耗社交精力。文章对比了两类工具:一类是像汽车、键盘、编辑器快捷键那样「具身化」的工具,另一类是需要反复协商、改写措辞、甚至对模型发火的对话式工具。
我的看法是,这篇文章之所以重要,是因为它点出了一笔不会出现在 benchmark 图表里的成本:对话税。AI 编程工具可以很强大,但如果用户得像照顾一个脆弱的合作者那样去管理它,而不是像操作一个可靠的仪器那样使用它,注意力照样会被耗尽。
答案快照
| 问题 | 我的看法 |
|---|---|
| 发生了什么? | 6 月 25 日 Tea and Bits 的一篇文章指出,LLM 常常让人觉得累,因为使用它们需要动用的是社交脑,而不是无缝的工具操作。 |
| 为什么重要 | 这篇文章给一个真实的采用难题起了个准确的名字:AI 的帮助可以很有价值,但同时也在割裂注意力、心流和验证工作。 |
| 谁会从中受益? | 那些希望 AI 辅助真正降低协调成本,而不是把成本挪到提示词和代码审查里的开发者、团队和工具构建者。 |
| 我的核心观点 | 最好的 AI 工具,不会是那些说话最像人的。而是那些需要最少社交管理、就能产出可验证成果的工具。 |
文章并不是在说 AI 没用
我不认为 Tea and Bits 这篇文章是在反 AI。文章明确承认,有些任务现在一个人就能完成,而在一年前这几乎不可能。它更尖锐的观点在于界面成本:一个好工具会逐渐融入肌肉记忆,而一个聊天机器人形状的工具却要求用户参与一场社交仪式。
这个区分很有用,因为它把能力和使用体验分开了。模型可以生成可用的补丁、总结代码库、起草测试,但用户仍然要决定提供什么上下文、相信哪些输出、验证到什么程度、什么时候重新开一个会话、什么时候停止和系统争论。输出可能有价值,但交互本身仍然昂贵。

市场卖的是「委托」
这种张力在 AI 编程产品的宣传里随处可见。Cursor 的首页把 Agent 描述成一种方式:把任务交出去,用户只专注于决策,让想法变成代码。这个承诺之所以吸引人,是因为它指向了真实的痛点:现代软件工作有太多的杂事、太多的上下文、太多做了一半的循环。
但委托并不等于甩手不管。Anthropic 的上下文工程文章指出,Agent 的工作正在从寻找神奇的提示词,转向整理进入模型的上下文:指令、工具、外部数据、消息历史等等。这是一个更成熟的说法,但也印证了那篇文章的担忧:如果用户或系统必须不断整理对话,才能让 Agent 正常表现,那界面就还远谈不上无摩擦。
社区的反应两极分化
原文引用的 Lobsters 讨论很有价值,因为它没有给出一个整齐划一的答案。一些评论者说,和 AI 对话已经变得轻松,更像搜索。另一些人则提出了老生常谈的担忧:幻觉、研究能力退化、代码审查,以及当生成的作品掩盖了精通之路时,学习者还能不能培养出判断力。
作者在那个帖子下的回复把这个分歧说得更精确了:简短的查询可以很轻量,但涉及代码库的问题,感觉更像是在问一个同事,却没有同事带来的好处——因为模型可能需要你仔细措辞、反复追问、不断纠正。这和我觉得最有用的那层区分是一致的。问题不在于对话本身,而在于那种消耗了社交精力,却几乎换不回任何关系、责任共担或共同理解的对话。

数据和这种感受是一致的
调查和研究背景让这篇文章不像是一种私人情绪。2025 Stack Overflow 开发者调查显示,资深开发者大量使用 AI:47.3% 每天使用 AI 工具,17.2% 每周使用。但同一份调查也显示,对 AI 工具准确性持不信任态度的开发者比信任的更多:46% 对 33%,只有 3.1% 的受访者表示自己高度信任 AI 的输出。
这种组合正好解释了疲惫感。工具已经普及到成为日常,但还远没有可信到可以视而不见。用户可以很快得到帮助,但随后还是要为验证买单。
2026 年的一项纵向研究《AI 编程助手对软件工程的影响》也指向同一个方向。研究跟踪了专业软件工程师,做了两轮问卷调查,发现了一个「生产力—体验悖论」:84% 的受访者在两个时间点都报告了生产力提升;但报告开发者体验在至少一个维度上变差的匹配参与者比例,从 14% 几乎翻倍到 27%——即便反馈循环变快了,心流状态和认知负荷仍在恶化。
Anthropic 的编程技能研究则补充了一个学习视角。文章指出,对 AI 的依赖并不都一样;用 AI 求快,可能会以技能发展为代价,尤其是在出问题时调试的能力。这是同一种税的另一种形式:任务也许完成了,但人并没有获得同样持久的理解。
生产力数字说明不了全部
METR 关于开发者生产力的研究,很好地提醒我们不要急着下结论。他们在 2025 年初做了一项随机研究:16 位资深开源开发者处理 246 个真实 issue,被允许使用 AI 工具时,反而多花了 19% 的时间。METR 后来警告说这些数据已经过时,并在 2026 年 2 月的更新中表示,开发者现在大概率比 2025 年初被 AI 加速得更多。但他们也指出,选择效应和多 Agent 工作流让新信号很难解读。
我认为这提醒我们要更精确,而不是更愤世嫉俗。AI 工具可以进步得很快,某些工作流可能已经明显更快。但一个加速估算,并不能自动回答这些问题:工作是不是变得更碎片化了?输出是不是真的被理解了?队友是不是分走了原本可以用于真正协作的社交精力?

我的结论
Tea and Bits 这篇文章之所以重要,是因为它给一场经常被简化为「模型能力」的讨论,加上了一个人机界面的视角。我不会用下一代编程 Agent 能不能进行更温暖的对话来评判它们。我会看它们能不能减少产出小规模、可审计、测试充分的变更所需的对话轮数。
真正的胜利条件,不是一个更像人的模型。而是一个需要更少社交管理的工具:更清晰的命令界面、更好的默认上下文、更快的纠正循环、明确的来源标注、以及易于检查的输出。如果 AI 工具能做到这些,它们就会更像键盘,而不是更像会议。如果做不到,那即便生成的代码再惊艳,对话税也依然要交。
许可
新闻文本 © 2026 Mark Huang。 新闻文本可在非商业场景下分享或翻译,但需署名并链接到 https://markhuang.ai/zh/news/ai-tools-conversation-tax.
建议署名: 基于「AI 工具仍在收取「对话税」」(作者:Mark Huang),原文发布于 https://markhuang.ai/zh/news/ai-tools-conversation-tax。