有一个数据足以让人们停止“增加一个聊天机器人”的条件反射：在很大一部分 AI 功能中，大多数打开聊天窗口的用户从未发送过一条消息。据报道，大约有 60% 的用户在发送第一条消息前就放弃了，而相比之下，当同样的能力被封装在带有示例和一键启动点的设计好的空白状态（empty state）中时，用户的参与度要高得多。模型并没有失败。答案从未生成，因为问题从未被提出。用户打开一个空白框，看着闪烁的光标，然后离开了。
我们选择聊天界面是因为它是阻力最小的路径，而不是因为它就是正确的界面。当语言模型可以进行对话的那一刻，“与 AI 交流”就变成了“使用 AI”的代名词，每个产品团队都继承了同样的默认设置：一个文本框，一个发送按钮，以及一个模型会搞定剩下一切的承诺。对于大多数智能体（agent）实际承担的工作来说，这种默认设置其实是错误的。
聊天是一个不错的 输入原语 (input primitive)。但它是一个糟糕的 操作环境。这是两个不同的概念，将它们混为一谈会导致你在需要控制面板的地方只交付了一个闪烁的光标。
过去两年中最受赞誉的交互模式——文本逐字显现，仿佛机器正在放声思考——对于屏幕阅读器用户来说，这更像是噪音而非语言。你的模型输出的每一个 Token 都是一次 DOM 变更。如果在这个流中插入一个简单的 aria-live 区域，屏幕阅读器会尝试播报每一次到来的变更，从而产生断断续续、相互重叠的洪流，每秒钟会在句中重置几十次。使你的产品显得充满灵性的功能，恰恰是让那些依赖辅助技术的人无法使用它的元凶。
这就是无障碍债，而生成式 UI 积累这种债务的速度比以往任何界面模式都要快。其原因是结构性的：传统的 Web 内容是静态且可预测的，因此你可以推理一次后即发布。生成式界面在每次交互时都会发生变化——一个提示词返回列表，下一个返回表格，再下一个流式输出 600 字的文章，随后是一个工具调用组件。这里没有可供审计的固定 DOM，没有可验证的稳定 Tab 键顺序，也没有代表“页面”的单一快照。无障碍契约必须在无限的生成输出空间中保持有效，而几乎没有人为此进行测试。
一名用户向你的购物智能体询问“150 美元以下、足弓支撑良好的跑鞋”。智能体尽职地返回了 12 个选项，但它们表现为单个聊天气泡中一长串超出视口的子弹点文本。用户滚动屏幕，找不着看到哪了，然后输入“只显示 Asics”——此时，你的智能体重新运行了整个搜索，而不是过滤它已经拥有的结果集。三轮对话后，用户正在通过一次一个提示词来发明一种查询语言，而你的产品感觉就像一个披着聊天气泡外壳的命令行。
这是我不断看到团队在交付时陷入的失败模式。他们在用户实际上想要的分面搜索（faceted-search）产品之上构建了一个聊天产品。模型没问题。检索也没问题。问题出在 UI 上，它的形态不适合这项任务。
我能给出的最简短的结论是：聊天是一种输入模态，而不是输出模态。智能体的职责是将用户意图转化为结构化查询。一旦结果集超过三项，正确的做法是渲染 UI，而不是继续说话。
上周二发布给用户的按钮标签从未经过文案人员之手，从未在 Figma 中评审过，从未进行过 QA，甚至在推理阶段（inference time）之前都不存在。它是由一个模型生成的，该模型在对话中途决定，收集送货地址的正确方式是渲染一个包含六个字段的内联表单，而不是再进行三轮文字交流。表单生效了，标签也没问题。团队中没有人能告诉你究竟是哪次模型运行生成了它，因为追踪记录（trace）已经从热存储中移出，而评估套件测试的是文本输出，而非组件图。
这就是生产环境中的生成式 UI（Generative UI）：模型不再仅仅是一个偶尔调用工具的文本生成器。它是一个输出为组件树的 UI 编译器，而设计系统现在是模型必须遵守的契约，而不仅仅是人类松散遵循的指南。这种转变打破了一整套假设——针对静态规范的 QA、固定布局的无障碍审计、最终字符串的文案审查、构建时的设计系统一致性检查——而大多数团队在替换掉这些旧流程之前，就已经发布了功能。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
