聊天并非最佳界面：为什么你的智能体不应只是一个文本框

有一个数据足以让人们停止“增加一个聊天机器人”的条件反射：在很大一部分 AI 功能中，大多数打开聊天窗口的用户从未发送过一条消息。据报道，大约有 60% 的用户在发送第一条消息前就放弃了，而相比之下，当同样的能力被封装在带有示例和一键启动点的设计好的空白状态（empty state）中时，用户的参与度要高得多。模型并没有失败。答案从未生成，因为问题从未被提出。用户打开一个空白框，看着闪烁的光标，然后离开了。

我们选择聊天界面是因为它是阻力最小的路径，而不是因为它就是正确的界面。当语言模型可以进行对话的那一刻，“与 AI 交流”就变成了“使用 AI”的代名词，每个产品团队都继承了同样的默认设置：一个文本框，一个发送按钮，以及一个模型会搞定剩下一切的承诺。对于大多数智能体（agent）实际承担的工作来说，这种默认设置其实是错误的。

聊天是一个不错的 输入原语 (input primitive)。但它是一个糟糕的 操作环境。这是两个不同的概念，将它们混为一谈会导致你在需要控制面板的地方只交付了一个闪烁的光标。

空白框是可发现性的失败，而不是用户的失败

一个没有提示的搜索框无法告诉你它能找到什么。一个没有提示的聊天框则更糟，因为你 可能 会说的内容空间是无限的，而真正有效的内容空间却是不可见的。用户面临双重困境：他们不知道如何表述请求（输入歧义），也不知道系统到底能做什么（能力歧义）。同时面对这两者时，大多数人会陷入僵局，要么给出一个模糊的查询，要么直接关闭标签页。

这不是通过更好的引导文案就能解决的训练问题。它是结构性的。空白画布假设用户可以将模糊的意图当场转化为形式良好的提示词（prompt），且无需任何脚手架——这一假设对高级用户有效，但对其他人则会失效。这种界面是在要求用户完成产品团队拒绝完成的设计工作。

你从普通 UI 中免费获得的每一种示能（affordance）在这里都缺失了。按钮说“你可以这样做”。表单说“这些是重要的字段”。菜单枚举了选项。而文本框什么也没说。它没有提供可发现性，没有约束，没有范围感，也没有关于你是在系统处理范围内还是范围外的反馈。你把一个拥有真实能力的产品隐藏在了一个光标后面。

当团队试图通过补丁将空白框修补回可用的界面时，迹象就显现了：建议提示词、示例气泡、“尝试询问……”占位符、斜杠命令、快速回复按钮。其中每一个都是一种微小的承认，即纯粹的对话是不够的——用户终究需要示能。在某些时候，诚实的做法是意识到你正在通过一个接一个的“补丁”重新发明菜单，那么干脆直接构建菜单好了。

聊天界面将能力和错误都隐藏在同一个光标之后

更深层的问题在智能体开始 行动 而非仅仅回答时显现。聊天记录是线性的文本流。这是对话的良好记录，却是过程的糟糕表示。当一个智能体计划一个多步骤任务、调用三个工具、编辑两个文件并在第四步出错时，所有这些都会被打平成一段滚动的散文。没有你可以看到的计划，没有你可以追踪的进度，没有你可以检查的状态，也没有在不可逆步骤运行前进行干预的清晰位置。

相比之下，运行软件真正需要的是：可见的计划、跨步骤的实时进度、可以在运行中途重定向的干预点，以及已执行操作及其原因的审计追踪。这些是控制界面的组成要素，而对话线程原生并不提供其中任何一项。你可以把它们强行拼凑在一起，但你全程都在与这种媒介作斗争。

这种模式产生的失败是无声且代价高昂的。智能体每一步有 95% 的正确率，记录看起来很合理，而那一个错误的动作——发送的邮件、删除的记录、发放的退款——却以同样的字体和同样的灰色气泡滚动而过。聊天界面让能力变得难以理解，也让错误变得难以察觉，而这两者都源于同一个设计选择：一切都是文本，一切权重相等，一切都是事后才显现。

优秀的智能体 UX 会反转这一点。它让智能体的能力预先变得清晰可见，并让智能体的操作事后变得可撤回。而闪烁的光标正好相反。

当你默认选择聊天时，你正在忽略的替代方案

“增加一个聊天机器人”是一个披着技术默认设置外衣的产品决策。以下是它默默排除掉的选项。

• 由智能体填充的结构化输入。 与其要求用户用散文描述供应商入驻流程，不如显示表单并让智能体填充，由人类纠正字段。对话退居其次，目标成为核心，双方都能看到同一个正在成形的物体。这通常是最大的改进：将自由文本请求转化为用户可以检查和编辑的结构化产物。

• 按钮、菜单和行内操作。 大多数智能体调用并不是新奇的请求；它们是十几种循环任务之一。在用户工作的地方将这些作为一等公民操作呈现——收件箱中的“总结此线程”按钮优于需要用户粘贴线程并解释需求的聊天窗口。

• 生成式 UI (Generative UI)。 智能体不再返回段落，而是返回一个 规范 (specification) ——卡片、列表、表单、小组件——由前端渲染为真实的界面。智能体决定出现什么以及如何构造；用户直接操作它。输出不再是你阅读的东西，而是你操作的东西。

• 智能体编辑的直接操作界面。 对于任何具有空间感或文档形状的东西——电子表格、画布、代码库、设计文件——正确的界面是产物本身，智能体进行你可以看到、对比 (diff) 和撤销的更改。你在原地观察工作的发生，而不是在侧边栏听取叙述。

• 完全没有聊天的环境感知和后台智能体。 杠杆率最高的智能体通常没有对话界面。它们根据事件运行，安静地工作，仅在达到权限边缘时才显现。设计问题从“对话的感觉应该是怎样的”转变为“智能体在什么条件下行动，被允许做什么，以及什么需要人类干预”。这是一个策略 (policy)，而不是一段对话。

这些都不禁止使用文本框。其中一些甚至 包含 文本框，作为处理真正开放式请求的备用手段。重点在于，文本框应该是逃生舱口 (escape hatch)，而不是整栋建筑。

什么时候聊天界面才是正确选择的框架

聊天界面并不总是敷衍了事的方案。对于特定形态的任务，它确实是最佳的交互模式。你应该能够定义这种形态，从而避免将其滥用到所有场景。

当交互本质上是迭代的——即用户需要不断澄清、细化和引导，且第五步的输出取决于前四步发生的所有事情时，请选择对话模式。开放式研究、写作与编辑、探索性分析以及“帮我理清思路”这类任务都非常契合。价值在于反复沟通的过程本身，任何结构化的 UI 都会阻碍这种闭环。

当任务定义明确、重复发生或具有重大影响时，应避免使用对话模式。如果你可以枚举输入项，它更需要一个表单。如果它是少数几个重复性工作之一，它需要的是按钮。如果它执行具有实际影响力（爆炸半径）的操作，它需要一个具备可见状态、自治层级和回滚机制的控制界面——琐碎任务静默处理，中等任务通知提示，不可逆任务则需人工审批。如果工作最好在无人值守的情况下完成，它应该是一个只在关键时刻打扰你的“隐形 Agent”，而不是一个你必须记得去打开的聊天框。

一个有用的直觉检查：如果你发现自己正在编写建议提示词标签、预设的快速回复以及“尝试询问……”之类的占位符来让聊天界面变得可用，那么界面就在告诉你它更希望是结构化的。倾听它的声音。那些标签其实是伪装的菜单，快速回复是伪装的按钮，而整个脚手架正是你在选择文本框时移除掉的“示能层”。

当我们唯一知道如何与模型交互的方式就是与其交谈时，将每个 AI 功能都以对话形式发布的本能反应是合理的。但现在情况已经变了。未来几年有趣的 Agent 产品不会是更好的聊天机器人——它们将是那些能让功能显而易见、让错误可逆的界面，并且只在任务真正需要对话时才采用它。闪烁的光标是设计问题的开始，而不是解决方案。