Agent不再堆叠文字，开始使用界面来回答

当用户让 Agent 安排一组间歇训练时，它可以写出“运动40秒、休息20秒，共8轮”，也可以继续补充动作说明和注意事项。但当训练真正开始，用户需要的已经不是更完整的文字，而是一个能够启动、暂停、倒计时并提示当前轮次的计时器。

文字适合解释任务，却未必适合承载任务。聊天产品长期把模型的输出收束在同一种容器里：无论答案包含计划、比较、选择、提醒还是操作步骤，最终都会被组织成一段向下延伸的文本。模型完成了信息生成，用户仍需从中提取条件、记住步骤，再把回答转换为实际行动。

Yui试图改变这种分工。它是一款运行在iPhone上的生成式界面，Agent可以根据当前任务调出计时器、选项、表单、清单和图表等可操作组件。9月27日发布的两个版本又加入了调音器、节拍器、键盘、和弦与循环器，同时调整了聆听状态、麦克风入口和顶部导航。

这些界面并不是由模型临时决定按钮的位置、颜色和尺寸。Yui建立了一套名为Yui Lines的界面语言。Agent只需发出类似timer 40/20x8 Tabata的指令，系统便会识别其中的任务类型与参数，调用预先设计好的原生计时器。用户启动或完成操作后，结果会被传回Agent，成为后续处理的一部分。

这种机制把生成式UI中原本混在一起的两类决定分开了：模型判断此刻需要哪种界面，产品负责规定这个界面如何工作。

如果布局、控件与交互行为都由模型自由生成，产品虽然能够回应更多临时需求，却很难稳定地保证一致性、可访问性和操作结果；如果所有页面仍由团队逐一预设，界面又无法根据任务变化及时调整。Yui采取的是一种受约束的生成：Agent可以调用和组合既有的界面词汇，却不能随意发明组件的行为。

计时器如何倒计时，表单如何校验，选项怎样提交，仍由客户端确定。生成发生在任务与组件的匹配层，而不是像素层。它没有取消设计，而是把设计从某一张固定页面，转移到一套可被模型调用的规则之中。

组件库也因此获得了不同于以往的职责。过去，设计系统主要帮助设计师与开发者维持产品的一致性；当Agent成为组件的调用者以后，视觉规范和代码实现已经不够。每个组件还需要拥有明确的语义：它适合处理什么任务，需要接收哪些参数，可能产生哪些状态，用户完成操作后应向Agent返回什么。

一个组件如果只有清晰的视觉样式，却缺少准确的使用条件，人可以凭借项目经验判断，模型却只能根据名称和上下文猜测。设计系统中那些长期依赖团队默契的部分，必须被转化为可以读取、调用和验证的规则。

设计师面对的对象也不再只是一组固定页面，而是一套界面语法。哪些内容适合继续使用文字，哪些任务应当切换为表单、比较视图或直接操作；信息不足时界面如何降级；组件无法加载或旧版本无法识别时，用户怎样继续完成任务；不同组件返回的结果如何进入下一步流程，都需要在单个组件之外得到定义。

Yui目前仍处于TestFlight测试阶段，主要连接用户自行运行的Hermes、OpenClaw或支持Webhook的Agent。它所提供的界面仍由有限的预设组成，也尚未证明这套方法能够覆盖账户管理、多人协作与复杂企业流程。受约束的组件体系提高了稳定性，同时也限制了它能够表达的任务范围。

因此，Yui解决的并不是“让AI设计任何页面”，而是一个范围更小、也更接近现实产品的问题：当文字不再是完成任务的最佳媒介，Agent如何调用一个可靠、可操作并能继续参与后续流程的界面。

生成式UI未必需要让AI自由设计屏幕。更可行的起点，是让它判断何时应该停止解释，转而提供一个真正能够完成任务的界面。