聊生成式UI和A2UI这个概念圈里讨论了大半年真正敢在业务线上稳定跑的团队其实不算多。原因倒不复杂让大模型画一个页面出来做个demo很容易二三十行提示词、一个渲染容器就能搞定可一旦要把生成出来的界面当成正经前端工程去维护马上就会撞上稳定性、权限控制、埋点、性能、无障碍、回归测试这一整串问题。这篇是AI工程化系列里A2UI的第二篇我默认你已经看过了第一部分的背景和理念所以这里直接讲实现链路和工程化兜底手段。重点说三件事A2UI的完整架构怎么搭、从提示词到页面上线有哪些关键节点、以及如何把AI自动生成测试用例和代码审查接进同一个工程闭环。适合正在做生成式UI PoC、或者打算把它放进正式迭代流程的团队参考。很多人第一次接触生成式UI第一反应是这不就是文生网页吗我刚接触时也这么想真正动手后发现完全不是一回事。文生网页是独立的生成行为生成完就结束了而A2UI的核心在于Agent参与决策循环模型要基于当前任务目标、用户上下文、实时数据动态调整界面内容与结构甚至要根据用户对上一个界面的反应来决定下一步渲染什么。这里面的工程复杂度是几何级上升的。1. 生成式UI与A2UI先搞清楚这三层逻辑1.1 三层概念别混淆LLM、生成式UI、A2UI我把最近被问最多的一个话题拿出来先拆解LLM能对话生成式UI能出页面A2UI能动态决策这三者的边界其实经常被搞混。我的理解是这样的LLM层是做语义理解和内容生成它本身不关心界面长什么样它只负责把输入变成输出生成式UI是在LLM之上加了一层界面描述协议让模型输出结构化的UI描述比如JSON Schema再由渲染端把描述翻译成真实组件A2UI则更进一步把界面生成放进一个感知-决策-执行-反馈的Agent循环里模型可以读取当前状态、决策下一步展示什么内容、评估用户交互结果然后继续调整界面。举个例子一个订单概览页如果用传统前端写是静态模板加数据请求如果用生成式UI你让模型根据订单状态生成一个页面布局如果升级成A2UI那么当系统发现用户是高风险逾期用户时Agent会在渲染前主动加一个风险提示卡片和分期引导而不是等用户自己去摸信息。这个根据业务状态主动变化的能力正是A2UI和单纯文本转网页的本质差别。1.2 A2UI要解决的工程问题不只是省人力我听到不少人一开始把A2UI定位成降本工具好像目的是裁掉前端。这个认知会把项目带偏。A2UI真正要解决的工程问题是动态场景下的界面适配成本问题。传统前端数据变化靠模板和状态管理业务规则一多分支判断就爆炸生成式UI把界面结构从代码中解耦出来由模型根据数据实时决定A2UI再把决策过程也解耦出来用Agent去执行多步推理比如先判断用户画像再决定展示哪些模块再决定模块顺序。我在实际项目中最大的体感是界面不再是写死的它变成了业务策略的一种外在表达。这一点在权限复杂的业务系统里特别有优势。以前每个角色都有不同首页配置前端要做一堆权限判断现在Agent在生成页面前就把权限约束过滤掉了渲染端只收到一份已经符合权限范围的schema天然不会越权展示。当然这也意味着渲染端必须严格校验不能完全信任模型输出。1.3 先判断你的场景适不适合A2UI不是所有页面都适合走生成式UI。根据我的实操经验以下场景确实适合千人千面的Dashboard、运营活动页、权限差异大的管理系统、以及需要根据实时数据频繁调整布局的页面。不适合的场景也有不少固定布局的复杂表单流程、强交互的编辑器、对像素级设计有严格要求的品牌页面。我的判断标准很简单如果页面结构在90%的情况下是固定的只有内容在变化那就用模板别上生成式UI只有当你需要结构本身也动态变化时A2UI才有发挥空间。选错场景会让团队陷入花了大代价解决一个小问题的困局。2. 核心架构拆解A2UI的完整链路该怎么搭2.1 意图解析层把自然语言和业务状态变成结构化表达A2UI链路的第一件事是把用户意图和系统状态转换成一个模型可以理解并操作的上下文。很多团队会直接用对话文本去生成页面这样做的结果就是输出极不稳定。我建议在意图解析层就引入结构化中间产物比如一个意图对象它至少包含三部分任务目标task用户当前要完成什么比如查看本月消费明细约束条件constraints角色权限、可用组件范围、合规要求上下文快照context接口数据schema、当前路由、设备信息、用户状态。这一步可以用一个小的分类模型加规则引擎来做不一定非要用大模型。我甚至建议能用规则就先上规则因为意图解析层的稳定性直接决定后续页面生成的稳定性。规则兜不住的长尾意图再交给LLM识别识别结果统一转成JSON格式后续生成层只认JSON。做过一版之后你会明显感觉到把上下文放在前面处理比让模型自己去理解原始数据要可控得多。模型拿到的不是一堆散乱的接口返回值而是已经整理过的、带了字段说明的和取值范围的上下文物件生成质量会提升一个量级。2.2 生成决策层约束下的界面结构推理这是A2UI的核心部分也是与普通生成式UI最不同的地方。A2UI不仅要生成静态好看的界面还要生成当前情境下最合理的界面所以这一层我认为本质是一个决策问题而不是纯生成问题。具体落地时我用的是一次性多候选生成排序筛选的策略。让模型同时生成3到5个候选schema然后用一个轻量排序器可以是一个规则函数也可以是一个很小的打分模型根据任务完成度、信息密度、交互成本等指标挑选最优结果而不是只让模型输出一个答案。这样能明显降低偶发性跑偏的概率。另外这一层必须限定模型工具调用范围。我发现让Agent自由调用所有工具是一件非常危险的事情。比如一个查订单页面模型可能会因为幻觉调用一个不存在的优惠券接口导致运行时数据缺失。我的做法是在工具层加白名单定义模型能做什么和不能做什么并在提示词里显式声明工具边界。你可以把这句话加进System Prompt你只能使用以下工具不要臆造接口也不要把未在工具列表中出现的能力当作可用能力。2.3 渲染适配层跨端组件怎么对齐生成式UI落地最容易被低估的是渲染适配层。模型输出的schema是逻辑描述它不关心你的项目用的是React还是Vue也不关心按钮是Element还是Ant Design。而真实业务中组件体系必须保持统一否则设计规范会混乱无障碍、埋点这些横切能力也无处安放。我现在的推荐做法是在渲染层之上加一个组件注册表。每一个UI Schema里出现的组件名都必须在注册表里登记过绑定了对应的真实组件实现、props映射关系和埋点标识。渲染层拿到schema后逐项查表渲染查不到的组件名直接走兜底组件或者报错提示不试用动态加载一个未注册组件的偷懒方案后患非常多。对于跨端我会把注册表按端分开维护Web端、小程序端各有自己的注册表但Schema层面保持统一。这样模型不需要学习多套语法渲染层各端各解释各的工程上更干净。实际操作中设计这套协议花费的时间会占到整个项目周期的三成以上但我觉得非常值得没有稳定的协议后面所有的稳定性保障都无从谈起。3. 实操环节从Prompt到可上线页面的关键实现3.1 定义一个收敛的UI Schema协议在开始写Prompt之前必须先定协议。我见过不少团队跳过这一步直接让模型输出JSX结果就是模型生成的东西五花八门今天写React组件明天写HTML标签渲染端根本没法维护。我这里给出一份简化的Schema示例你可以基于它扩展{ version: 1.0, root: { type: page, layout: vertical, children: [ { type: header, props: { title: 订单概览, subtitle: 最近30天消费 } }, { type: card, props: { title: 本月消费, value: ¥1,280.00 } }, { type: list, props: { dataSource: $transactions, item: { type: row, props: { label: $item.title, value: $item.amount } } } }, { type: button, props: { text: 查看全部订单, action: { type: navigate, target: /orders } } } ] } }这份协议里有几个关键设计思路组件类型被收敛在很小范围内数据引用用$前缀模型不需要内联真实数据只负责引用字段事件动作也被限定了类型只能navigate、submit、openModal等。这样一来渲染端就变得非常简单它只需要把schema翻译成组件树然后把action映射到统一的事件分发器里剩下的业务逻辑由业务方自己接管。3.2 编写稳定可复现的提示词策略A2UI里提示词不是一次性魔法它的目标是在方差中求稳定。我自己实践下来有三条提示词策略很重要第一在System Prompt里写入Schema定义和示例不给模型自由发挥的空间。你可以把上一节的schema JSON直接粘贴进去并标注必须严格遵守该结构禁止新增未定义的组件类型或事件类型。第二用Few-shot示例引导生成风格。每个示例尽量贴近真实业务案例让模型看到好的输出长什么样。比如你要做业务Dashboard就给一个包含header、kpi卡片、趋势图表的示例要做一个表单页就再给一个包含表单组件、校验规则的示例。模型会在输出时自觉模仿示例的结构。第三增加一条思考确认机制。让模型在生成schema前先用一行文字简述它的决策理由比如用户是VIP所以首屏展示权益卡片。这个做法看似多了一步实际上对生成质量帮助很大。它相当于强制模型进行推理链而不是直接跳到结果。实测下来增加这个环节后生成页面的任务完成度能从70%左右提升到85%以上。我还建议把temperature调低一般控制在0.2到0.4之间。这个值不是拍脑袋定的我试过用0.7跑业务页面会频繁出现组件顺序错乱的问题调到0.2以后结构稳定性明显提升但表达多样性也减少了所以对业务系统来说0.3比较合适。3.3 渲染端接入与动态校验渲染端接入看起来简单无非是做一个schema到组件的翻译器但真正要上线有两条红线不能踩。第一条红线渲染前必须做Schema校验。这个校验不只是JSON格式校验还包括组件名是否在注册表内、props是否满足最小必填集合、事件action类型是否在允许列表内。我建议用JSON Schema校验框架加自定义规则两层第一层拦住格式问题和未知组件第二层拦住业务语义问题。校验失败时请直接拒绝渲染并返回错误信息不要尝试尽力渲染。第二条红线渲染数据要与Schema解耦。模型生成schema时应该只引用数据字段名而不是把真实数据写死在schema里。渲染端拿到schema后在根据字段名去获取数据再通过统一的上下文注入机制绑定到组件上。这样做的好处是模型不需要知道敏感真实值既降低了幻觉概率也减少了数据泄露风险。关于动态校验我个人的经验是针对线上环境给所有生成schema打一个版本号每次变更都diff一下方便排查问题。实践中偶发性页面不显示和组件崩溃一度让我们排查了很久最后发现是模型偶尔输出一个非法组件名渲染端没有兜底直接抛异常。后来加了一层未知组件兜底渲染把渲染失败降级为一个简单的错误提示卡片线上问题才初步稳定下来。4. AI工程化在测试与代码审查里的落地4.1 AI自动生成测试用例能到什么程度说完A2UI主链路再聊一个大伙儿都很关心、但市面上很少讲透的话题AI自动生成测试用例。A2UI上线后页面变成动态生成手动维护测试用例基本不现实了因为同一个页面今天长这样明天长那样。所以从第一天起就必须把测试生成纳入工程化体系。我在项目里跑通的做法是让AI基于UI Schema自动生成交互测试用例。具体分两条线走静态分析线解析schema结构对每个组件生成基础断言比如按钮存在性、卡片标题非空、列表有数据源等行为语义线把用户真实业务路径转化为交互脚本比如登录后进入订单页点击第一笔订单的详情按钮期望跳转到详情页并生成对应的Playwright测试脚本。实测下来AI生成的测试用例对冒烟级覆盖非常高效能很快发现组件崩溃、字段缺失、跳转失败这类问题。但要说让AI做到像素级断言或者复杂业务链路自动推理现阶段还有距离。稳定性最好的是基于schema的语义断言而不是基于文本的黄金快照断言。因为页面会动态变文本类的断言今天通过明天就失败了而语义断言判断的是页面上是否存在订单卡片金额字段是否正常展示这种业务级问题了更能容忍生成变化。4.2 代码审查自动化让AI从PR里拦下隐患如果说AI生成测试是事后兜底那AI代码审查就是事前拦截。A2UI项目的代码审查跟普通Web项目有非常大的区别不只是看人的代码质量还要审查模型生成的schema变更和注册表变更之间的匹配关系。我试过一个很典型的场景某个组件从schema里被模型删掉了但注册表里仍然保留看起来没什么事反过来模型悄悄引入了一个新组件名注册表没有对应实现渲染端直接崩。这个场景完全可以用AI审查来拦。我在CI流水线中加了一个Agent审查步骤大概逻辑是这样当PR提交时自动提取以下信息——改动的schema diff、组件注册表diff、渲染端代码diff然后让AI审查这些diff重点关注是否存在未注册组件、是否有事件动作未被处理、是否有权限约束遗漏、是否引入了新的数据引用。AI审查给出disagree时PR会打回给提交者处理这个过程大概每个PR多花一两分钟但它能拦住的隐患动辄是整个页面的运行时错误。4.3 测试与审查的工程闭环一条流水线串起来测试生成和AI审查不是两条孤立的工作流我最后把它们统一进了一条CI流水线由四步组成schema变更触发测试用例生成自动生成针对新schema的冒烟测试集运行测试集发现渲染、组件、事件绑定等基础问题AI审查PR中的schema和注册表变更标记不匹配项将测试结果和审查意见汇总到PR评论由提交者决定修复还是调整。这条流水线跑起来之后A2UI页面上线的过程才真正变得可控。说实话动态生成页面最让人害怕的就是不知道改了什么会导致线上出问题。有了这条流水线至少每一次变更都被记录、被测试、被审查后面查问题也有据可循。我强烈建议所有在做生成式UI的团队在项目管理工具或者CI平台里先把这个框架搭起来再放开手让Agent生成页面。5. 常见问题与排查技巧实录5.1 生成内容不稳定页面结构偶尔乱掉这是A2UI上线后最常见的问题。同一个提示词上午生成的是卡片在前列表在后下午就变成列表在前卡片在后把业务方吓得不敢用。我的排查思路是先检查temperature确认是否在0.2到0.4之间再看是否给模型提供了过大的自由裁量空间比如没有明确组件顺序约束最后看是否缺少Few-shot示例示例越具体模型越能稳定模仿。建议在System Prompt里加入如果信息类型相同请按以下优先级排列状态提示、核心指标、操作入口、辅助信息。这相当于把业务方最看重的信息层级直接教给模型比让它自由发挥稳定得多。5.2 交互事件丢失、埋点上报异常A2UI动态生成页面后埋点是一个特别容易被忽略的坑。传统前端埋点会写在组件回调里而生成式UI的组件是模型指定的如果埋点逻辑交给模型自由生成那基本等于没有埋点。我后来把埋点收敛到渲染层统一处理My组件注册表里每个组件都绑定了一个默认的event listener组件一旦渲染点击、曝光、跳转这些基础事件都会自动上报不需要模型参与。如果你发现自己页面上的数据明显比之前少了大概率是没做这层统一埋点。排查方法很简单打开一个生成页手动点击某个按钮看network面板里有没有对应的上报请求。如果没有基本就是事件绑定漏了。5.3 AI生成测试用例断言率低过不了流水线有读者反馈说AI生成的测试用例第一次跑普遍不过断言率很低。我遇到过类似情况原因基本是两条断言级别太细或者数据引用有问题。如果断言写的是卡片只显示一次且金额文案为¥1,280那页面结构调整一下或者金额格式变一下用例就会挂。建议把断言保持在业务语义级别比如页面上存在订单卡片列表数据源非空点击详情后URL跳转正确。另外如果你的schema里本身就有数据引用测试生成时也必须喂真实数据源不能在测试环境里用空数据跑。很多断言不过本质上是因为页面还没有拿到数据就急着断言内容存在。这里整理一份排查速查表方便大家直接抄作业现象可能原因处理方式页面结构偶发错乱temperature过高或缺少组件顺序约束调低temperature到0.3加入排序规则新组件渲染失败组件未注册或注册表不同步在Schema校验中拦截未注册组件降级兜底点击无响应事件action未绑定或未在允许列表内渲染层统一接管事件绑定不依赖模型自由生成埋点数据缺失埋点逻辑未收敛到渲染层在组件注册表内统一配置默认埋点测试断言频繁失败断言粒度太细或测试数据为空改为语义断言测试中注入真实数据结构生成页面空白schema校验失败被静默忽略增加严格的渲染前校验错误直接暴露在日志中做A2UI工程化这段时间我的体会是真正的难点不在模型能力而在工程约束。模型能给出让人眼前一亮的设计但最终决定线上页面稳定性的是渲染层的校验、注册表的收敛、测试和审查的闭环。你要有心理准备这类项目的前期投入比普通前端要大尤其在协议设计、渲染兜底这些看不见的地方。最后提醒一个很小的坑模型偶尔会生成非法的schema在调试环境里你可能看不出来但一上生产环境就会变成页面白屏。建议在开发环境里就开启严格校验模式让任何非法schema都以显著的报错形式暴露出来不要用能显示就行的宽容标准放过去否则上线后迟早会还回来的。