生成式表单 Schema字段能生成校验也要跟上一、生成一个表单很简单生成一个能用的表单很难生成式 UI 经常从表单开始。给模型一句“生成用户资料编辑页”它很快能吐出输入框、下拉框和按钮。问题是真实表单不是控件堆叠。字段类型、校验规则、权限、默认值、联动关系、提交副作用一个都不能少。如果 Schema 只描述“长什么样”那它只是页面配置。工程化表单 Schema 要描述“能做什么”和“不能做什么”。否则生成出来的表单像样子货交给用户就开始漏水。二、表单 Schema 要包含 UI、数据和行为一个可维护 Schema 至少包含字段定义、校验规则、显示条件、权限和提交动作。flowchart TD A[表单 Schema] -- B[字段定义] A -- C[校验规则] A -- D[显示条件] A -- E[权限控制] A -- F[提交动作] B -- G[渲染器] C -- G D -- G E -- G F -- H[提交服务]生成式 UI 不能只生成 B。C 到 F 才决定它能不能进生产。三、Schema 类型要先稳定下面示例是一个简化字段定义。重点是把校验放进协议。type FieldSchema { name: string; label: string; kind: text | number | select; required?: boolean; maxLength?: number; visibleWhen?: { field: string; equals: string }; permission?: string; }; function validateField(field: FieldSchema) { if (!field.name || !field.label) throw new Error(missing field identity); if (field.kind text field.maxLength field.maxLength 500) { throw new Error(text field too long); } }模型生成 Schema 后先过协议校验再渲染。别让模型直接写 JSX 进页面。四、表单联动要限制复杂度字段联动很容易失控。A 影响 BB 影响 CC 又反过来影响 A最后用户点一下页面像算盘珠子乱飞。Schema 应限制联动方向和深度。还要处理权限。没有权限的字段不只是隐藏还要在提交时过滤。前端隐藏只是体验后端校验才是边界。最后生成表单要有快照测试。Schema 输入固定渲染结构应该稳定。否则模型或渲染器升级后页面悄悄变样排查会很痛苦。提交协议也要独立于渲染协议。字段在页面上怎么摆和提交给后端的 payload 结构不是一回事。生成式表单如果把两者绑死改布局就可能影响接口。Schema 里最好区分 view schema 和 submit schema。国际化也别事后补。label、placeholder、错误文案都应该用文案 key而不是让模型直接写死中文或英文。否则表单生成得越多后面多语言债务越大。最后权限和校验要后端再跑一遍。前端 Schema 是体验层不能当安全边界。生成式 UI 再聪明也挡不住用户自己构造请求。五、总结生成式表单 Schema 要覆盖 UI、数据和行为。字段定义、校验、显示条件、权限和提交动作都要协议化。模型可以辅助生成但生成结果必须经过 Schema 校验和测试。能生成页面不稀奇能生成可维护、可校验、可上线的表单才算工程化。