AI 输出该是结构化界面，而非纯文本

AI 助手把我们训练成接受了一种奇怪的默认行为：请求一个结果，收到一堵文字墙，然后自己把这段文字转化成可用的东西。

这种默认行为对模型很方便。对人来说却不一定有用。

食谱不只是一段文字。项目计划不只是一份清单。对比不只是一段总结。这些结果都有结构、决策、状态和操作。当答案有了形状，界面也应该反映那个形状。

文本是一种传输格式，不一定是最终产品

文本非常适合解释、探索和处理模糊性。它便于携带、可搜索、易于生成。

但当用户需要以下操作时，文本就变成了糟糕的最终界面：

• 修改一个值并查看结果
• 保存一个持久化的输出

在这些情况下，用户需要做第二次转换：从文字到心理模型，再从模型到操作。

生成式 UI 改变了契约

生成式 UI 不应该意味着让模型随意写前端代码。那样会带来安全、一致性、可访问性和维护方面的问题。

一个更有用的契约要更窄：

解释用户的目标。

选择一个已批准的输出 schema。

用结构化数据填充该 schema。

让产品拥有渲染、验证、权限和操作。

模型提供结构化内容。应用控制界面。

一个 checklist schema 可以在不允许任意代码的情况下暴露可勾选的项目。一个 comparison schema 可以在不要求模型发明新组件的情况下使权衡可见。一个 plan schema 可以被编辑和保存，同时保持在已知的交互规则内。

一个有用的界面应该保留什么

生成的界面应该让四件事清晰：

1. 结果是什么

用户应该立即理解他们收到的是计划、食谱、表格、文档还是工作流。

可编辑的字段、可重排的步骤和明确的控件将静态答案变成可工作的界面。

3. 系统知道什么

来源、假设、模型选择和置信边界不应该消失在精心呈现的外表背后。

4. 下一步是什么

一个好的结果有一个明显的下一步：保存它、完善它、导出它、运行它，或者请求一个不同的版本。

为什么这是一个工程问题

返回界面不仅是设计决策。它改变了后端契约。

系统需要经过验证的 schema、用于持久化编辑的版本化产物、清晰的纯文本回退方案、感知权限的操作、无障碍的渲染器，以及对 schema 选择和失败模式的可观测性。

这就是为什么"加个 UI"是错误的心智模型。界面是产品协议的一部分。

Vira 围绕这个边界构建：开放的模型可以生成有用的结果，但产品应该决定这些结果如何变成可用的工作。

Vira 可以在对话是正确界面时返回对话。当一个请求受益于结构时，其生成式 UI 方向将结果映射到特定任务的界面——如计划、对比、表格、清单或文档。渲染器由应用控制，结果可以成为可重用的输出，而不是消失在聊天历史中。

这对开源 AI 很重要。开放模型使能力更具可移植性，但仅靠可移植性不能创造好产品。路由、工具、界面、存储和操作控制仍然需要整合在一起。

在构建生成式界面之前，问自己：

结构是否减少了用户的工作？

schema 是否足够稳定以进行验证？

可用的操作是否明确？

结果是否可以回退到清晰的文本？

用户是否可以检查、编辑、保存和导出它？

界面在小屏幕上能用吗？

如果答案是否定的，文本响应可能更好。

目标不是取代文本。而是停止把文本当作智能的唯一可能目的地。

AI 应该返回完成工作所需的最小有用界面——当界面真正使结果更容易理解和使用时。