生成式表单 Schema：字段能生成，校验也要跟上

生成式表单 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 影响 B，B 影响 C，C 又反过来影响 A，最后用户点一下，页面像算盘珠子乱飞。Schema 应限制联动方向和深度。

还要处理权限。没有权限的字段，不只是隐藏，还要在提交时过滤。前端隐藏只是体验，后端校验才是边界。

最后，生成表单要有快照测试。Schema 输入固定，渲染结构应该稳定。否则模型或渲染器升级后，页面悄悄变样，排查会很痛苦。

提交协议也要独立于渲染协议。字段在页面上怎么摆，和提交给后端的 payload 结构不是一回事。生成式表单如果把两者绑死，改布局就可能影响接口。Schema 里最好区分 view schema 和 submit schema。

国际化也别事后补。label、placeholder、错误文案都应该用文案 key，而不是让模型直接写死中文或英文。否则表单生成得越多，后面多语言债务越大。

最后，权限和校验要后端再跑一遍。前端 Schema 是体验层，不能当安全边界。生成式 UI 再聪明，也挡不住用户自己构造请求。

五、总结

生成式表单 Schema 要覆盖 UI、数据和行为。字段定义、校验、显示条件、权限和提交动作都要协议化。模型可以辅助生成，但生成结果必须经过 Schema 校验和测试。能生成页面不稀奇，能生成可维护、可校验、可上线的表单才算工程化。