生成式 UI 工程化：从 Prompt 草图到可维护组件

生成式 UI 工程化从 Prompt 草图到可维护组件一、生成 UI 不难生成可维护 UI 才难生成式 UI 工具可以很快产出页面草图。输入一句“生成一个订单管理后台”几秒钟后就有表格、筛选栏、按钮和弹窗。问题是这些代码往往只适合预览。组件边界混乱样式写死状态散落业务字段没有类型交互缺少异常处理。看起来像页面实际上不是工程资产。低质量生成代码最大的风险是让团队误以为已经完成了 70%。真正接入项目时会发现剩下 30% 全是硬骨头。设计系统要对齐组件 API 要稳定权限和数据要接入错误和 loading 要处理性能还要测。生成式 UI 的正确定位不是直接替代前端开发而是提高原型到工程初稿的效率。它应该输出受约束的组件而不是随意拼出的页面。二、工程链路生成前先定义约束flowchart TD A[产品需求] -- B[设计系统约束] B -- C[组件 Schema] C -- D[Prompt 生成页面草图] D -- E[AST/ESLint 校验] E -- F[人工 Review] F -- G[接入真实数据] G -- H[视觉与交互回归]生成式 UI 的关键在生成前。设计系统约束包括颜色、间距、组件库、响应式规则和交互模式。组件 Schema 则定义哪些组件可用、每个组件允许哪些 props、字段类型如何映射。没有这些约束模型会自由发挥生成十个页面就有十种风格。生成后要进入静态校验。比如禁止内联大段 style禁止直接写死接口地址禁止使用不存在的组件禁止把业务逻辑塞进 JSX。能自动发现的问题不要留给人眼。三、落地示例用 Schema 限制组件生成范围下面是一个简化的组件 Schema。它不是给用户看的而是给生成流程和校验流程共同使用。interface ComponentSpec { name: string; allowedProps: Recordstring, string | number | boolean | array; children?: boolean; } const specs: ComponentSpec[] [ { name: DataTable, allowedProps: { columns: array, dataSource: array, loading: boolean, }, }, { name: SearchForm, allowedProps: { fields: array, collapsed: boolean, }, }, ];模型生成后可以用 AST 扫描组件是否符合 Schema。下面是伪代码式的校验流程。function validateGeneratedComponent(ast: Node, specs: ComponentSpec[]): Finding[] { const findings: Finding[] []; traverse(ast, node { if (!isJSXElement(node)) return; const spec findSpec(node.name, specs); if (!spec) { findings.push({ level: error, message: 未知组件${node.name} }); return; } for (const prop of node.props) { if (!spec.allowedProps[prop.name]) { findings.push({ level: warning, message: 组件 ${node.name} 不允许 prop ${prop.name} }); } } }); return findings; }这样做的好处是生成结果不再完全靠人工判断。只要违反组件契约就能自动拦截。生成式 UI 才能接入 CI而不是停留在聊天窗口里。四、权衡分析约束越强自由度越低强约束会减少模型创意。比如只能使用既有组件库就很难生成特别新颖的交互。但企业项目通常更需要一致性而不是惊喜。后台系统尤其如此用户要的是稳定、清晰和可预测不是每页都有新花样。生成式 UI 也不适合直接处理复杂业务状态。审批流、权限矩阵、跨表单联动这些需要明确领域模型。模型可以生成骨架但状态机和权限边界必须由工程设计决定。还有一个现实问题是维护责任。代码一旦合入仓库就属于团队资产。不能因为它是模型生成的就降低 Review 标准。生成代码应该接受同样的 lint、测试、类型检查和性能预算。生产落地补充从能跑到可维护从生产落地角度看这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束读者很难判断它能否放进真实系统。评估时建议先定义三类指标正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信稳定性指标回答失败时是否可控成本指标回答持续运行是否划算。三类指标要同时进入验收清单不能只用平均耗时或单次成功率证明方案有效。五、总结生成式 UI 的工程化重点是约束。先定义设计系统和组件 Schema再让模型生成受控代码最后用 AST、ESLint 和人工 Review 进入项目流程。不要把预览代码直接当生产代码。落地建议从低风险页面开始比如列表页、详情页和简单表单。先验证组件一致性和校验链路再逐步扩展到复杂交互。生成式 UI 能提高效率但前提是它尊重工程边界。