AI生成UI的工程化实践：检索引擎、规则系统与测试体系如何协同

先说我最近在折腾的一个AI前端生成项目叫 ui-ux-pro-max。这名字乍一看挺像那种“一个Prompt生成漂亮网页”的玩具但真正把它拆开之后我发现它根本不是一个Skill那么简单——它同时装了检索引擎、规则系统和一套完整的测试流程。刚开始我也觉得这是不是过度设计了但实际跑完一轮需求之后我的看法变了这三个东西缺一个都不行。这篇文章我想把它背后的设计逻辑、每个模块存在的意义以及它们之间怎么配合一次性讲清楚。如果你也在做AI生成UI、智能体前端落地或者想给你的Skill加一点工程化能力这篇应该对你有用。1. 内容整体设计与思路拆解1.1 这个Skill到底解决什么问题先纠正一个常见误区ui-ux-pro-max不是用来“从零画一个漂亮页面”的它的核心目标是在AI生成UI的过程中让输出结果保持稳定、可预期、且能真正跑起来。我们知道大模型生成代码尤其是生成HTML/CSS/JS这类前端代码最大的问题不是“生成不出来”而是“生成得太自由”。同一个Prompt你让它生成一个按钮今天给你圆角的明天给你方角的今天用Flex布局明天用Grid布局今天Bootstrap的class明天Tailwind的class。看起来好像都行但你一旦想基于这些代码做二次开发或者在真实项目里维护马上就乱套了。ui-ux-pro-max的定位就是解决这个“自由度过高”的问题。它把自己定义成一套端到端的UI生成工作流——你输入需求它先检索最合适的组件方案再套上规则约束生成逻辑最后用测试脚本验证输出的页面能不能用。整个过程不依赖模型临场发挥而是依赖一套离线准备好的知识库和校验体系。1.2 为什么是“三件套”而不是一个Prompt一开始我也在想是不是直接写一个复杂的System Prompt就能搞定所有事事实是Prompt能约束模型的“语气”但约束不了模型的“行为”。你可以在Prompt里写一百遍“请使用标准组件库”但模型一旦在上下文中看到某个设计稿的class命名它就可能照着那个样式跑偏。所以ui-ux-pro-max采用了“多模块协作”的架构而不是“单Prompt”架构检索引擎解决的是“模型不知道有什么可用”的问题它把可选方案预先准备好生成时直接检索注入避免模型瞎编组件或设计规范。规则系统解决的是“模型知道但不想遵守”的问题它把约束从“建议”变成“检测项”强制要求生成的代码在结构和属性上符合项目约定从机制上确保模型按约定输出。测试体系解决的是“模型以为自己写对了但实际跑不通”的问题。LLM写代码常常有“自信的幻觉”它输出一段看似完整的代码但里面可能缺了一个闭合标签或者事件绑定指向了不存在的元素ID。测试就是最后的兜底防线用可执行的脚本去验证输出结果而不是靠肉眼review或模型自述。这三者构成一个闭环检索解决“用什么”规则解决“按什么标准生成”测试解决“生成完到底能不能用”。这种架构思路其实已经脱离了“写提示词”的范畴更像是在做一个AI原生的小型应用框架。1.3 设计选型背后的取舍为什么不全交给模型我知道有人会问“既然大模型那么强为什么不直接让它自由发挥反正效果也不会差”实话说如果只是做演示Demo自由发挥确实够用。但一旦涉及真实项目比如给客户交付一个可维护的前端页面或者嵌入到一套已有的设计系统里自由发挥就是灾难。模型生成的代码风格不统一是小事更麻烦的是它常常“自创组件”——界面上看起来是一个下拉菜单实际上是用一堆自定义Div拼出来的后续维护的人根本看不懂也没法复用。把检索引擎加进来之后相当于我们把“选择组件”这件事从模型手里拿回来交还给一套确定性的代码。模型不需要记得住你们团队的Button长什么样也不需要知道设计规范里颜色变量的名字——它只要去检索并调用就好了。这样生成出来的页面每个组件在代码层面都是真实存在、可复用的而不是模型脑补出来的“概念组件”。这个取舍的核心原则是凡是能用确定性方案解决的就不要赌模型的采样概率。2. 核心细节解析与实操要点2.1 检索引擎给模型一双“看得见的手”这部分我重点说说检索引擎实现的关键细节。它不是搜索引擎没有爬虫也没有倒排索引。它本质上是把你项目里所有可用的UI组件、样式片段、设计Token做一次语义化切片然后存入向量数据库。当Skill收到用户需求时它会先做一次Embedding召回把最相关的组件代码段取出来拼接进Prompt上下文。举个例子如果用户描述的是一个“带图标的支付表单页面”检索引擎会先从库里召回Payment Form的布局模板、Input组件的代码、Button组件的变体、图标库的引用方式。这些会作为示例注入到Prompt中模型生成时就不再需要凭记忆“画”一个输入框而是基于召回结果进行组合与适配。这块有几个实操细节值得注意第一切片粒度必须足够细。我试过直接把整个页面当成一个文档存进去结果召回的准确率很低。用户输入的是“一个弹窗”但检索引擎召回的是整个Dashboard页面中间塞了大量无关代码。后来我改成按组件维度做切片一个Button、一个Input、一个Modal各存一条记录召回准确率才明显上来。第二metadata一定要设计好。每个向量切片不能只有代码文本本身还要带上组件类型、用途标签、依赖条件。比如某个组件依赖图标库那它的metadata里就得标注“需要引入icon-font这样模型生成时才不会漏掉依赖引用。第三召回数据要有排序策略。我建议优先召回“官方设计规范中的基础组件”其次才是“历史项目中沉淀的复杂业务组件”。基础组件的通用性高作为底稿最稳复杂组件容易带入历史业务逻辑用不好会带偏生成方向。2.2 规则系统把设计约束变成硬性校验项有了检索引擎解决“知道用什么”的问题规则系统负责的是“知道什么不能做”。它类似于前端项目里的ESLint作用——在模型生成结果出来之后做一次静态扫描把不符合约定的代码拦下来。规则系统覆盖的方面我大致归为四类结构规则。检查生成的HTML结构是否合乎语义化标准列表是否用了ul/li标题层级是否跳级组件外层容器是否有合理的语义标签。这块主要是防止模型生成一堆无意义的Div嵌套。样式规则。检查样式是否使用了设计规范中的Token变量而不是硬编码颜色值。比如如果设计规范里主色是var(--color-primary)规则系统就会拦截#1E90FF这样的魔法值。依赖规则。检查组件引用的JS功能是否有对应初始化。比如标准UI库里的下拉菜单通常需要实例化模型可能只生成了HTML结构却忘记写初始化脚本规则系统会识别这种“结构完整但行为缺失”的情况。命名规则。检查class命名是否符合项目的BEM约定ID命名是否有实际业务语义不允许出现div1、box2这类无意义命名。这几个规则里依赖规则是最容易被忽略但实际价值最大的。因为我发现大模型生成前端代码时最大的坑不是样式丑而是“看起来对实际点不动”。按钮渲染出来了但绑定事件的方法不存在输入框显示出来了但表单提交的action缺失。这类问题肉眼review很难全部发现用规则扫描一遍就清晰很多。规则系统运行在代码文本层用的是类AST的解析方式不会真正去浏览器里渲染页面。这样做的好处是扫描速度快一次生成结果的校验在几百毫秒内完成坏处是它只能校验“静态代码层面的规范性”没办法验证“页面在真实浏览器中的交互行为”。这也正是测试系统存在的意义。2.3 测试体系三层测试拦住“模型的自信”如果说规则系统是代码层的“体检医生”那测试体系就是运行时层面的“实战演习”。ui-ux-pro-max的测试体系分成了三层每一层负责验证不同的东西。第一层是结构完整性测试。它会去解析生成的HTML检查标签是否闭合、关键区块是否存在比如页面必须包含header、main、footer时这三个结构是否都生成了。这一层可以顺手做因为很多时候模型输出的代码只是看起来完整实则标签配对是错的。第二层是行为交互测试。这层会在无头浏览器里真实渲染页面模拟用户点击、输入、悬停等事件然后检查页面有没有正确响应。比如一个Tab切换组件测试脚本会自动点击每个Tab验证对应的内容面板是否依次显示。这层测试是用项目内置的模拟浏览器跑的不需要你本地装Chrome。第三层是视觉回归测试。它会渲染页面做截图然后和基准图做像素级对比检查有没有明显的布局错位或视觉崩溃。我们踩过一个坑有一次模型生成的代码在逻辑上完全正确规则扫描也全部通过但实际渲染出来的页面侧边栏和主内容区互相重叠找了半天原因发现是一个CSS Grid属性的缺省值在不同渲染引擎下的表现不一致。这种问题只有视觉回归测试才能拦得住。三层测试全部通过生成结果才被标记为“可用”。任何一层失败Skill都会把失败信息返回给模型并让它基于报错内容进行修正最多重试三次。这个“先生成后验证失败则反馈修正”的循环是测试体系的核心运行模式。3. 实操过程与核心环节实现3.1 使用流程从需求输入到可用页面前面讲了原理这部分我把整个使用流程顺一遍。我以一次“生成一个移动端登录页”的实操为例。首先我发现这个Skill最核心的使用方式不是直接提问而是先通过一个“需求录入格式”把信息补完。它的输入格式大概是我要生成一个[产品类型]的[页面类型]目标用户是[用户描述]页面必须包含[核心元素]整体视觉风格偏[风格词汇]。比如我录入的是“一个SaaS产品的移动端登录页目标用户是中小企业的管理员页面必须包含手机号输入、验证码获取、登录按钮视觉风格偏简洁商务。”录入完之后检索引擎开始工作。它会从组件库中匹配出几个登录表单的模板选项包括标准手机号输入组件、验证码倒计时逻辑、按钮的不同状态样式。这些内容会被整理成一段结构化的参考材料作为生成的“底稿”。底稿注入Prompt之后模型基于底稿进行生成而不是凭空创作。生成完成规则系统立刻对代码做静态扫描。我期望的校验结果是所有颜色值用的是设计Token手机号输入框有正确的typetel属性验证码按钮绑定了倒计时逻辑代码class命名符合BEM规范。任何一项不通过都会进入修正循环。3.2 生成阶段模型是怎么“照着底稿”工作的生成阶段和直接让AI写代码有一个重要的区别模型不是把检索到的代码原文粘贴出来而是把它们作为“风格参考”再结合用户需求中的业务逻辑做组合。这就引出一个关键点——检索提供了“确定的原料”但模型依然负责“不确定的组合”。这算是一种刻意的设计。如果全部用模板拼接页面会显得非常死板如果全部让模型自由发挥又会跑偏。折中方案是组件结构、设计Token、交互模式这些“不能用错的部分”交由检索引擎保证而排版布局、文本内容、元素的组合方式这种“可以灵活的部分”让模型自己决策。在实际生成过程中模型会在一个受控的上下文窗口里做生成。这个上下文窗口分两段第一段是系统指令声明UI生成原则和输出格式要求第二段是检索回来的组件材料和历史示例。模型需要在两组信息的共同约束下保证生成的代码既符合结构规范又和底稿保持一致的风格。3.3 代码示例一个带规则校验的生成配置为了让内容更具体我放一段我自己在用的配置示例。这不是完整的项目代码但能体现“规则校验是怎么嵌入生成流程的”。这是规则配置的一部分用JSON格式定义了几条规则{ rules: [ { name: use-design-tokens, type: style-declaration, action: deny, pattern: #[0-9a-fA-F]{3,8}\\b, message: 不允许硬编码颜色值请改用设计Token变量 }, { name: semantic-form-input, type: html-attribute, action: require, pattern: input[type\tel\], input[type\email\], input[type\password\], message: 输入框必须带有语义化的type属性 }, { name: bem-class-naming, type: class-name, action: enforce, pattern: ^(block|block__element|block--modifier)$, message: class命名必须符合BEM规范 }, { name: init-script-check, type: script-presence, action: require, pattern: new\\s(Dropdown|Modal|Tabs)\\(, message: 使用了组件库交互组件时必须包含对应的初始化脚本 } ] }这些规则在模型生成完之后跑一遍命中即返回错误信息给模型修正。实际使用中我把校验器做成一个轻量级的Node.js脚本放在Skill的执行流程中间不额外启动服务。3.4 测试反馈闭环失败会被“打回去重写”测试系统是有反馈闭环的这一点我认为是它和常规测试工具最大的不同。普通的前端测试比如Jest或Cypress是在代码写完之后跑目的是发现问题。但ui-ux-pro-max的测试结果是直接回流到Prompt上下文的。我举个例子。当时测试脚本发现生成的页面上登录按钮点击后没有触发任何请求。测试脚本记录了这个失败然后把“验证码”按钮无法正常获取验证码、登录按钮的点击事件未绑定有效函数”作为修正指令重新发送给模型让它针对问题进行修复。这个反馈修正循环最多执行三次。三次之后如果还有问题Skill不会再死磕而是会直接输出一个“生成报告”把未通过的测试项列出来说明哪些部分需要人工介入。从我的经验来看70%的问题在第一次修正循环里就会被解决剩下30%比较顽固的问题多半是需求描述本身有歧义需要你调整Prompt表述后从头再来。这里有一个很重要的心得测试失败时收集到的错误信息越具体修正效果越好。像“代码不完整”“有语法错误”这种反馈模型基本没法用但“查找到名为submitBtn的元素不存在实际生成的按钮ID为login_btn”这种反馈模型一看就知道问题在哪。4. 常见问题与排查技巧实录4.1 检索引擎召回了不相关内容怎么办我实际使用中遇到最多的问题是检索结果和需求强相关但场景错位。比如用户想要的是一个“注册页”但检索引擎把“登录页”的模板当成最相似的结果召回了导致生成的页面没有用户名输入框。排查思路是先看召回的metadata是否带了足够详细的场景标签。早期我的标签只写了“表单”后来升级成“登录表单/注册表单/信息收集表单”召回准确率提升明显。其次是调整检索的Embedding模型。我换过好几个Embedding模型不可否认的是更强的语义模型在理解“注册页”和“登录页”的差异上明显更准确这也确实是语义相似度检索绕不开的基础能力问题。还有一个小技巧给每个切片加权重基础组件权重高、复杂组件权重低。这样即使复杂组件的语义相似度略高基础组件也能优先被召回生成结果会更稳。4.2 规则系统误报太多怎么办规则系统跑起来后最烦的是它把一些其实是合格代码的情况判断为违规。尤其是BEM命名规则模型生成的class名经常是login-form-container这种中划线风格而我的规则要求双下划线的BEM写法导致误报率一度超过一半。解决思路是规则不是越严越好要设定合理的优先级。我把规则分成“硬性规则”和“建议规则”两档。硬性规则包括语义化标签、设计Token、初始化脚本这些不通过直接打回重写建议规则包括命名风格这类不通过只给警告不会阻断流程。这样既保证了下限又不会因为过度约束阻碍生成效率。硬性规则里我想特别提一个依赖配对的写法最好写清晰。之前我让模型生成一个折叠面板HTML结构完全正确但运行时报错原因是初始化脚本里引用的类名和HTML结构中的data属性对不上。后来我在建议规则里加了一条“组件库交互组件的初始化脚本必须使用模板中的对应class和data属性值。”这一类校验规则能拦住一大半看似合法实则无效的代码。4.3 视觉回归测试老是因为字体不一致失败这套系统在本地跑得好好的一到CI环境视觉回归测试就失败。查了大半天最后定位到是字体渲染差异。CI环境里没有安装项目设计规范要求的PingFang SC系统回退到了默认的Sans-serif字体于是所有带中文文本的页面截图全部对比失败。这个问题我能想到的直接解法是在测试容器里预装好设计规范指定的字体包或者把字体也纳入视觉对比的排除区域。另一个更省事的方法是在截图前统一设置页面font-family强制所有文本使用同一套安全字体这样至少能保证页面结构对比的稳定性。值得提醒的是如果你的视觉基准不是一次性生成的而是会迭代的建议在基准图命名上带上传参标识。比如login-page-1366px-1x.png清楚标出viewport尺寸和倍率否则后面跑回归测试时很容易拿不同尺寸的基准图在对比结果一片飘红。4.4 修正循环始终不通过怎么排查修正循环三次跑满还不过通常不是代码修正的问题而是问题出在需求描述上。我复盘过几次流程发现当需求描述过于模糊时比如只说“好看一点的登录页”系统每次生成的方案都不同第一次偏简洁风第二次偏渐变风第三次偏大图背景测试肯定不可能连续通过。这种情况我建议先停下来不要继续重复让Skill生成。先回去补需求细节把视觉风格、功能范围、页面模块说得更明确然后再开一轮生成。重来一次往往比死磕修正循环更快。另外我还会定期把模型生成失败的案例做留存分析。如果发现某类页面频繁失败说明这个场景下的检索引擎切片质量还不够丰富需要补充更多高质量组件模板。5. 这套系统的边界与扩展空间5.1 它不适合做什么必须承认ui-ux-pro-max这套方案也有自己的边界。它最适合的场景是有明确设计规范、有组件库积累、追求代码统一性和可维护性的UI生成需求。但如果你要的是纯粹的概念设计探索比如做一个完全颠覆传统布局的营销落地页这套系统反而会碍手碍脚。因为它的规则系统会一直尝试把生成结果拉回到设计规范的框架内压制模型的创造力。这个时候一个不带约束的自由生成模式反而更合适。在实际落地时我倾向于把它当成“工程化的UI生成器”而不是“创意设计助手”。说白了就是Content Generation的自动化能力在设计系统覆盖的范围内越界越多效果反而越不好。所以我的建议是如果要把这套模式推广到你的团队先对业务需求做一次分类。把需求分成“模板覆盖型”和“自由创新型”两拨前者走检索引擎规则测试的完整流程后者走轻量Prompt配合人工审核各取所长。5.2 后续可以怎么演进这套架构本身是通用的你可以把检索引擎的内容从“UI组件”换成“业务规范文档”把规则系统从“代码规范校验”换成“合规性检查”把测试从“前端页面测试”换成“业务流程冒烟测试”。这样一来它就从一个UI生成Skill演变成了一个更通用的“受控内容生成框架”。我自己已经在尝试的一个方向是把规则系统的校验对象从“前端代码”扩展到“生成过程的思考链”。也就是让模型在生成UI之前先输出一份“设计决策说明”解释它为什么选择这种布局、这种配色再基于这个说明做规则校验。如果决策说明本身不符合设计规范就直接返回修正而不是等代码生成完再返工。这样改完之后风格一致性又提升了一截。最后再分享一个小技巧如果你打算在自己项目里复刻这套架构哪怕是简化版也不要一开始就把所有规则全部补全。先把检索引擎跑通再做最小化的规则集最后接一个简单的结构测试脚本。等这个链路稳定后再逐步加视觉回归、依赖校验这些高阶能力。一口气把架构堆得太满调试的时候会很痛苦。总之拆完ui-ux-pro-max之后我最大的感受是AI生成式应用正在从“让模型发挥”走向“让模型在约束里发挥”。检索引擎、规则系统、测试体系这三件套本质上都是在给模型的自由上“画框”画框不是为了限制它而是为了让它在真正复杂的工程环境里交出稳定可靠的结果。这种“可控生成”的思路我估计会是未来各类AI工具落地的主流方向。