# AI 工具仍在收取「对话税」

**Summary:** Tea and Bits 的一篇文章谈到了和 LLM 对话带来的疲惫感，也提醒我们：AI 编程工具需要减少社交层面的管理成本，而不只是生成更多内容。

- Canonical: https://markhuang.ai/zh/news/ai-tools-conversation-tax
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-06-26
- Section: News
- Tags: AI, 开发工具, 用户体验, 效率, LLM
- Source: [Tea and Bits](https://ohadravid.github.io/posts/2026-06-tool-talking/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一位卡通开发者面露疲态，旁边是一个发光的 AI 助手，等待着熟悉的键盘和桌面工具](https://cdn.markhuang.ai/news/ai-tools-conversation-tax/hero.webp)

*这个故事里的疲惫，不只是敲提示词那么简单。而是一种感觉：本该是工具的东西，却不断把用户拖进一场社交互动循环。*

Ohad 在 [Tea and Bits 的文章](https://ohadravid.github.io/posts/2026-06-tool-talking/)里提出，LLM 让人疲惫，是因为它们要求用户在本该是工具的东西上消耗社交精力。文章对比了两类工具：一类是像汽车、键盘、编辑器快捷键那样「具身化」的工具，另一类是需要反复协商、改写措辞、甚至对模型发火的对话式工具。

我的看法是，这篇文章之所以重要，是因为它点出了一笔不会出现在 benchmark 图表里的成本：对话税。AI 编程工具可以很强大，但如果用户得像照顾一个脆弱的合作者那样去管理它，而不是像操作一个可靠的仪器那样使用它，注意力照样会被耗尽。

## 答案快照

| 问题      | 我的看法                                                                  |
| ------- | --------------------------------------------------------------------- |
| 发生了什么？  | 6 月 25 日 Tea and Bits 的一篇文章指出，LLM 常常让人觉得累，因为使用它们需要动用的是社交脑，而不是无缝的工具操作。 |
| 为什么重要   | 这篇文章给一个真实的采用难题起了个准确的名字：AI 的帮助可以很有价值，但同时也在割裂注意力、心流和验证工作。               |
| 谁会从中受益？ | 那些希望 AI 辅助真正降低协调成本，而不是把成本挪到提示词和代码审查里的开发者、团队和工具构建者。                    |
| 我的核心观点  | 最好的 AI 工具，不会是那些说话最像人的。而是那些需要最少社交管理、就能产出可验证成果的工具。                      |

## 文章并不是在说 AI 没用

我不认为 Tea and Bits 这篇文章是在反 AI。文章明确承认，有些任务现在一个人就能完成，而在一年前这几乎不可能。它更尖锐的观点在于界面成本：一个好工具会逐渐融入肌肉记忆，而一个聊天机器人形状的工具却要求用户参与一场社交仪式。

这个区分很有用，因为它把能力和使用体验分开了。模型可以生成可用的补丁、总结代码库、起草测试，但用户仍然要决定提供什么上下文、相信哪些输出、验证到什么程度、什么时候重新开一个会话、什么时候停止和系统争论。输出可能有价值，但交互本身仍然昂贵。

![一个卡通工作台被分成两半：一边是顺手的手动工具，另一边是密密麻麻的空白 AI 对话气泡](https://cdn.markhuang.ai/news/ai-tools-conversation-tax/why-it-matters.webp)

*核心的 UX 差距在于：一类工具会融入操作本身，另一类助手却不断要求对话式的监督。*

## 市场卖的是「委托」

这种张力在 AI 编程产品的宣传里随处可见。[Cursor 的首页](https://cursor.com/)把 Agent 描述成一种方式：把任务交出去，用户只专注于决策，让想法变成代码。这个承诺之所以吸引人，是因为它指向了真实的痛点：现代软件工作有太多的杂事、太多的上下文、太多做了一半的循环。

但委托并不等于甩手不管。Anthropic 的[上下文工程文章](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)指出，Agent 的工作正在从寻找神奇的提示词，转向整理进入模型的上下文：指令、工具、外部数据、消息历史等等。这是一个更成熟的说法，但也印证了那篇文章的担忧：如果用户或系统必须不断整理对话，才能让 Agent 正常表现，那界面就还远谈不上无摩擦。

> **Info:**
>
> 我关心的产品问题很简单：助手到底是减少了协调工作，还是把每个任务都变成了一场和概率型实习生之间的微型管理会议？

## 社区的反应两极分化

原文引用的 [Lobsters 讨论](https://lobste.rs/s/csgzki/exhaustion_talking_tool)很有价值，因为它没有给出一个整齐划一的答案。一些评论者说，和 AI 对话已经变得轻松，更像搜索。另一些人则提出了老生常谈的担忧：幻觉、研究能力退化、代码审查，以及当生成的作品掩盖了精通之路时，学习者还能不能培养出判断力。

作者在那个帖子下的回复把这个分歧说得更精确了：简短的查询可以很轻量，但涉及代码库的问题，感觉更像是在问一个同事，却没有同事带来的好处——因为模型可能需要你仔细措辞、反复追问、不断纠正。这和我觉得最有用的那层区分是一致的。问题不在于对话本身，而在于那种消耗了社交精力，却几乎换不回任何关系、责任共担或共同理解的对话。

![一位卡通开发者站在中间，一边是带着空白对话气泡的发光 AI 助手，另一边是站在抽象形状白板前的队友](https://cdn.markhuang.ai/news/ai-tools-conversation-tax/tradeoff.webp)

*这里的取舍不只是人和机器的对比。而是有限的注意力和社交精力，在工作日里被花在了哪里。*

## 数据和这种感受是一致的

调查和研究背景让这篇文章不像是一种私人情绪。[2025 Stack Overflow 开发者调查](https://survey.stackoverflow.co/2025/ai)显示，资深开发者大量使用 AI：47.3% 每天使用 AI 工具，17.2% 每周使用。但同一份调查也显示，对 AI 工具准确性持不信任态度的开发者比信任的更多：46% 对 33%，只有 3.1% 的受访者表示自己高度信任 AI 的输出。

这种组合正好解释了疲惫感。工具已经普及到成为日常，但还远没有可信到可以视而不见。用户可以很快得到帮助，但随后还是要为验证买单。

2026 年的一项纵向研究[《AI 编程助手对软件工程的影响》](https://arxiv.org/html/2605.23135v1)也指向同一个方向。研究跟踪了专业软件工程师，做了两轮问卷调查，发现了一个「生产力—体验悖论」：84% 的受访者在两个时间点都报告了生产力提升；但报告开发者体验在至少一个维度上变差的匹配参与者比例，从 14% 几乎翻倍到 27%——即便反馈循环变快了，心流状态和认知负荷仍在恶化。

Anthropic 的[编程技能研究](https://www.anthropic.com/research/AI-assistance-coding-skills)则补充了一个学习视角。文章指出，对 AI 的依赖并不都一样；用 AI 求快，可能会以技能发展为代价，尤其是在出问题时调试的能力。这是同一种税的另一种形式：任务也许完成了，但人并没有获得同样持久的理解。

## 生产力数字说明不了全部

METR 关于开发者生产力的研究，很好地提醒我们不要急着下结论。他们在 2025 年初做了一项随机研究：16 位资深开源开发者处理 246 个真实 issue，被允许使用 AI 工具时，反而多花了 19% 的时间。METR 后来警告说这些数据已经过时，并在 [2026 年 2 月的更新](https://metr.org/blog/2026-02-24-uplift-update/)中表示，开发者现在大概率比 2025 年初被 AI 加速得更多。但他们也指出，选择效应和多 Agent 工作流让新信号很难解读。

我认为这提醒我们要更精确，而不是更愤世嫉俗。AI 工具可以进步得很快，某些工作流可能已经明显更快。但一个加速估算，并不能自动回答这些问题：工作是不是变得更碎片化了？输出是不是真的被理解了？队友是不是分走了原本可以用于真正协作的社交精力？

![一位卡通开发者拿着放大镜，仔细检查发光的 AI 生成拼图块，再把它们拼进更大的结构](https://cdn.markhuang.ai/news/ai-tools-conversation-tax/workflow-risk.webp)

*审查负担本身就是界面的一部分。如果输出来得更快，却需要仔细重构，那省下的时间只是挪了地方，并没有消失。*

## 我的结论

Tea and Bits 这篇文章之所以重要，是因为它给一场经常被简化为「模型能力」的讨论，加上了一个人机界面的视角。我不会用下一代编程 Agent 能不能进行更温暖的对话来评判它们。我会看它们能不能减少产出小规模、可审计、测试充分的变更所需的对话轮数。

真正的胜利条件，不是一个更像人的模型。而是一个需要更少社交管理的工具：更清晰的命令界面、更好的默认上下文、更快的纠正循环、明确的来源标注、以及易于检查的输出。如果 AI 工具能做到这些，它们就会更像键盘，而不是更像会议。如果做不到，那即便生成的代码再惊艳，对话税也依然要交。