生成式 UI Schema先约束状态再生成页面一、没有 Schema 的生成很容易散生成式 UI 如果只给模型一段自然语言需求它可能生成看起来不错的页面但状态、事件、字段和权限都不稳定。页面一多组件协议就会混乱后续维护成本会上升。Schema 的作用是把可变需求压进可控结构。字段类型、组件类型、布局约束、交互事件、数据源和权限都应该提前定义。模型可以填充和组合但不能随意发明协议。二、Schema 要描述数据和交互flowchart TD A[业务需求] -- B[UI Schema] B -- C[组件渲染器] B -- D[状态管理] B -- E[权限校验] C -- F[页面输出]只描述布局是不够的。按钮点击做什么、表单字段如何校验、列表数据从哪里来、空状态如何展示都需要进入 Schema。否则生成页面只是静态壳子。Schema 还要区分展示字段和提交字段。很多低代码系统的问题就来自表单展示和接口协议耦合太死。字段映射写清楚后端接口调整时才不至于牵连整个页面。三、类型定义要稳定type UISchema { version: string layout: form | table | detail fields: FieldSchema[] actions: ActionSchema[] } type FieldSchema { key: string label: string component: input | select | date required?: boolean }Schema 必须版本化。新增字段、废弃组件、改变 action 语义都可能影响历史页面。渲染器要根据 version 做兼容而不是让旧配置突然失效。function validateSchema(schema: UISchema) { if (!schema.version) throw new Error(missing schema version) if (!schema.fields.length) throw new Error(empty fields) }生成前后都要校验。模型生成 Schema 后先走 schema validator再进入渲染器。这样错误能在结构层被拦住而不是等页面运行时报错。四、权限和设计系统不能缺席action: type: submit permission: order:update confirm: true生成式 UI 不能绕过权限。按钮是否可见、字段是否可编辑、操作是否需要二次确认都要写进 Schema并由运行时校验。只靠前端隐藏按钮不够后端也要验证。设计系统同样要进入约束。颜色、间距、组件规格和响应式规则不能让模型自由发挥。模型越自由页面越容易变成风格拼盘。约束越清晰生成结果越稳定。Schema 还要考虑国际化和无障碍。字段 label、错误提示、按钮文案不能直接写死在生成结果里应该引用文案 key。表单控件要有 aria 描述动态错误要能被读屏识别。生成式 UI 如果忽略这些基础要求后期补起来会非常费劲。数据源配置也要有白名单。模型不能随便生成一个接口地址渲染器只能从已注册的数据源里选择。数据源参数要经过类型校验和权限校验避免页面配置变成绕过后端约束的新入口。五、总结生成式 UI Schema 要先约束状态、字段、事件、权限和设计系统再让模型生成配置或页面。低代码和生成式 UI 的核心不是少写代码而是让变化被协议管理避免每个页面长成孤岛。