生成式界面进入项目之前，先把它关进组件边界里

生成式界面进入项目之前先把它关进组件边界里生成式 UI 的演示很有吸引力一句指令就能出现表单、图表和操作按钮。但演示默认输入完整、组件存在、接口成功真正的前端页面并没有这么宽容。模型返回内容会被截断字段会变形也可能给出产品根本没有注册过的组件名。这类能力不该被当作“让模型输出 HTML”。更可靠的做法是让模型描述一个受限的界面协议前端只从已经实现并审核过的组件库中选择渲染。模型负责提出结构应用负责决定哪些结构可以执行。先缩小模型能够表达的范围协议不宜一开始就覆盖整个页面。选择几个高频、风险低的组件就够了例如提示卡片、只读信息列表、普通按钮和确认框。每种组件只开放必要属性标题、文案、按钮文案、动作标识。颜色值、任意 CSS、任意 URL、事件处理函数都不应由模型直接提供。动作尤其需要单独设计。模型输出的应该是 actionId例如“打开退款说明”或“提交已填写的表单”而不是一段 JavaScript 或接口地址。客户端将 actionId 映射到白名单里的业务处理器并在执行前检查当前用户、页面状态和所需参数。这样即使模型编出了不存在的动作也只会得到一个可控的降级结果。文本内容同样是外部输入。React 默认会转义普通字符串保持这个默认值通常最省心。不要为了渲染一段备用 Markdown 就把内容交给危险的 HTML 注入接口若业务确实需要富文本使用经过维护的解析器和严格的标签、属性白名单。校验不是一道形式上的 JSON 解析收到返回后第一步是确认它能否完整解析第二步才是检查结构。运行时 schema 可以验证组件类型、必填字段、数组长度和枚举值也能给日志留下可读的失败原因。解析成功不代表内容可用一个对象语法正确却包含未知组件或不存在的 actionId仍然应该被拒绝。校验结果最好区分三种情况。完全合法的内容进入渲染可修复的小问题例如缺少可选说明文字可以补默认值协议不兼容、动作不在白名单、嵌套层级过深等问题直接使用降级组件。降级不必做得花哨一张说明卡片加上人工入口往往比渲染半截错误界面更好。要限制树的深度和节点数。没有限制的递归卡片会让渲染和调试都变得困难也会让异常模型输出占据页面。限制值应来自产品允许的交互复杂度而不是照搬某个示例数字。渲染器只认识注册表中的组件可以把渲染器理解为一张字典协议中的 componentType 映射到本地组件未知键没有默认“猜测”路径。每个组件只接收已经校验和转换过的 props。按钮类组件还应只接收安全的 actionId而不是原始请求参数。这种注册表设计还有一个好处组件升级时可以保留协议版本。服务端或提示词切换到新字段前前端可以同时支持旧版本并统计使用量若发现新版本的失败率异常也能快速把模型输出切回旧协议。不要依赖模型“总会记住最新格式”。生成式 UI 若需要展示检索结果、订单状态等数据数据源仍由应用提供。模型可以选择展示哪些已经授权的字段但不应自行拼接敏感数据查询。尤其在客服、财务和管理后台中界面动态生成不等于权限可以动态放开。把失败路径当作正常交互设计网络中断、超时、返回半截 JSON 都会发生。前端应在请求期间显示稳定的 loading 状态到达超时后停止等待并给用户继续操作的出口。不要保留上一轮响应的一半内容让用户以为那是一张可提交的表单。调试时准备一组固定样本很重要合法卡片、缺少字段、未知组件、未知动作、超深嵌套、非 JSON 文本和被截断的响应。每次修改 schema、渲染注册表或提示词都用这些样本跑一遍。它们比一段成功的录屏更接近线上会遇到的问题。还应记录但不泄露原始敏感内容协议版本、校验结果、降级原因、组件类型和任务标识通常足够定位问题。若要保存模型输出用于复盘需要遵循现有的数据脱敏与保留规则。生成式 UI 可以让界面更贴近当前任务但它仍然是应用的一部分。组件边界、权限判断、结构校验和降级体验由前端控制模型只是其中一个输入来源。把这条边界守住后续增加组件和场景才不会变成一次无约束的页面注入实验。