对话不是默认，界面也不是答案

目前主流 AI 产品的入口，几乎都是一个对话框。写作、设计、编程，订机票、查报销，新一代产品都被压缩成了一行输入。

这是一种过度迁移。大模型的能力是通过对话演示出来的，不等于用户的需求是对话式的。

但反过来主张 AI 产品应该回到传统界面、对话框是设计倒退，同样是一种二元偏见。对话有它真正生效的场景，只是这些场景比想象中窄。

更准确的说法是：AI 产品形态没有默认值，它由三件事共同决定——用户和自己需求的关系、用户对 LUI 的历史预期、操作本身的物理性质。这三件事互相独立，决定了一个具体场景里对话和界面孰优孰劣。

一、用户和自己需求的关系

用户面对一个待完成的任务时，大致有三种状态。

第一种是需求模糊——用户大致知道自己有个目标，但具体要什么不清楚。这种状态下，界面有一种对话不具备的功能：它能教育用户摸清自己想要什么。一个有结构的页面把可能性摊开，用户在浏览选项的过程中识别出"是这个，不是那个"。这不是浪费——它恰好是绝大多数普通用户唯一能用来表达需求的方式：通过识别，而不是通过描述。

第二种是需求明确且可被结构化——月度报销、机票筛选、电商下单。这类需求每一项都能落到具体的字段、选项、范围。界面把所有字段摊在用户面前让他识别，永远比让他用自然语言描述要快、要准、要省力。"如果我能点，为什么我要说"，说的就是这种情况。

第三种是需求明确但无法被结构化——"帮我写一段邮件，告诉客户这次发货会延迟，但口气不要太怂"。用户清楚自己要什么，但你设计不出一个能预先列出所有"口气"选项的界面。这种需求只能用语言表达，对话式在这里不是次优解，是唯一解。

三种状态里，前两种界面有压倒性优势。对话式真正合理的场景，只限于第三种。

但即便在第三种状态下，对话也带着一个隐性损耗——"用户知道自己要什么"和"用户实际说出了什么"之间，始终有一个 gap。一个人完全可能精确地知道自己想要什么，又同时完全说不清楚。这条 gap 是 prompt engineering 在 C 端始终长不大的根本原因；它不出现在交互界面上，但出现在每一次"AI 没听懂我意思"的挫败感里。

二、用户对 LUI 的历史预期

今天观察到的对 LUI（Language User Interface）的抗拒，未必是抗拒 LUI 本身。

更可能的原因是：人们对 AI 失望太多次了。很多嵌入软件内的对话 AI 与软件本身的功能集成做得很差，只是套了个壳；再加上模型本身能力的限制，用户在尝试任何 LUI 之前，普遍抱着低预期。

由此带来一个有意思的现象：很多被津津乐道的 aha moment，本质上是"低预期与高功能之间的落差"——"它竟然还能做到这个！"

这意味着今天的 LUI 抗拒，大半是过去两年劣质实现欠下的负债，不是这个交互形式本身的天花板。随着 agent 越来越能做到"言出法随"（说出需求就直接得到结果），这种抗拒会逐步消解。

把这一条单列出来的意义在于：当我们看到用户讨厌某个 LUI，不必然说明这个场景不适合 LUI——它可能只是说明这个 LUI 做得不够好。对当下用户态度的观察，不能直接外推成对未来形态的判断。

三、操作本身的物理性质

前两件事都关于用户认知。第三件事跟用户无关，是关于操作本身的。

把任何应用的所有操作拆开看，无非两类：post（执行动作、产生变化）和 get（查询信息、读取状态）。

对 post 操作——订机票、发邮件、生成报告——用 agent 实现是可以接受的。"从智能体开始思考、决定调用什么工具"确实存在一段时延，但这个时延相对于整个任务执行过程是九牛一毛。用户愿意为一个能完成长程任务的 agent 等几秒钟。

但 get 操作完全不同。从数据库查询到前端展示只需要毫秒级，而且页面展示对人类来说远比一段文字回复友好。让 AI 走一遍"理解—决策—调用—生成"再回答"今天天气怎么样"，既是对用户耐心的浪费，也是对信息密度的浪费——一段天气描述的信息量永远比不上一张配色合理的天气卡片。

所以对高频 get 操作，并无 agent 的存活空间。这条几乎是工程层面的硬约束，和用户认知无关。再聪明的 agent，也跑不赢页面直接渲染。

一种合理的组合形态：a2ui + skills + 快应用

三件事合起来看，得到的不是单一形态，而是一种组合。

a2ui（agent to UI）——让 agent 在需要的时候临时生成界面，而不是只能用文字回复。post 操作里那些需要用户确认、选择、微调的环节，应当落到一个临时生成的 UI 上。这样既保留了 agent 处理长程任务的能力，又用界面承接了第一节里那个"识别比描述更高效"的环节。a2ui 是对话和界面的真正融合形态，而不是其中一方的胜利。

skills——把 agent 的能力封装成可被复用、有清晰边界的技能单元。这是对"超级 agent 包打一切"幻觉的纠正：agent 不应该是一个无所不能的对话框，而应该由一组确定性的能力组成。每个 skill 可以独立验证、独立替换、独立调用，agent 的不确定性被约束在 skill 边界内部。

快应用——高频 get 操作的归宿。一个能秒开、按需调用、用完即走的轻量应用形态，避开了 agent 的时延，保留了页面的信息密度。它对应的正是第三节里那条工程硬约束。

这三者之间是分工，不是替代。一个完整的 AI 产品大概率同时包含这三种形态：长程任务交给 agent + a2ui，可复用能力下沉为 skills，高频查询用快应用承接。

把这三件事拼起来，才接近 AI 产品形态当下合理的样子。