华为开发者大会 HC 2026 结束回来快三周了我一直在整理 OpenTiny NEXT 的演示笔记和自己的实测记录。说实话作为一个常年泡在中后台管理系统里的前端工程师看到 OpenTiny NEXT 把 Web 应用开发往智能化方向推的那几步还是挺有感触的。它不再只是又一个组件库而是把自然语言生成界面、设计稿转代码、智能布局、交互状态补全这些能力连成了一条完整的开发链路。这篇文章我不打算写成新闻稿而是从一个实际想把它用起来的人的角度聊聊 OpenTiny NEXT 到底解决了什么问题、是怎么设计的、我们回来之后是怎么落地试验的以及过程中踩到了哪些坑。适合正在做前端基建、对 AI 辅助开发感兴趣、或者团队里想引入智能化开发范式的同学参考。1. OpenTiny NEXT 的定位转变从组件库到智能化开发基座1.1 传统组件库的尴尬零件很多但没有自动装配线我在不少团队里见过同一个场景组件库积累了五六百个组件按钮、表格、弹窗、表单、树控件应有尽有开发规范文档也写了一百多页。但真要做一个新的中后台页面从拿到设计稿到写出符合规范的页面新同学至少还要一两天。熟练工快一些可那部分时间基本都花在把设计稿翻译成栅格布局、响应式断点、交互状态这些重复劳动上。组件库本质上解决的是零件标准化问题但零件再多没有一个自动装配线生产节奏还是快不起来。OpenTiny 从前几代的 TinyVue、TinyNG 开始做的就是组件标准化这件事把 Vue 和 Angular 生态里的基础组件打磨到可复用的程度。而这次 HC 上发布的 OpenTiny NEXT最大的变化是从提供组件变成了提供加工组件的能力——让 AI 去理解业务需求、理解设计稿直接产出页面级的结果而不是组件级的结果。我举一个具体的对比。以前做一个商品列表页流程大概是设计稿切图 → 确定栅格列数 → 写搜索表单 → 写筛选条 → 写列表卡片 → 适配移动端断点 → 补 loading、空数据、错误重试这几个状态 → 再跟后端联调分页参数。一套下来熟练工也要大半天。OpenTiny NEXT 想做的事情是把其中的设计稿理解、布局推理、组件匹配、交互状态补全全部自动化让开发者把时间花在看业务逻辑上。1.2 三层结构组件层、智能化层、应用层在大会现场OpenTiny 团队把 NEXT 的架构讲得比较清楚我按自己的理解整理成三层。最底下是组件层包括组件标准、设计规范、无障碍支持这些是智能化生成的基础设施。中间是智能化层包含语义理解、视觉解析、布局推理、代码生成四个模块这是 NEXT 新增的核心。最上面是应用层包括 CLI 脚手架、低代码集成、业务接入适配等让智能化能力真正落到项目里。这个分层设计我比较认可。它没有把AI 生成页面做成一个黑盒而是把生成能力建立在标准组件之上。换句话说AI 生成的每一个页面元素落到代码层依然是你的组件库里那套组件数据结构、样式规范、无障碍属性都跟团队现有的约定一致。这比某些一键生成一个独立 HTML 文件的工具靠谱得多——后者生成的东西没法融入现有工程体系最后只能拿来看看。这里可以打个比方就像智能化小区并不是给每户换一个智能锁就完事了而是把门禁、照明、安防、物业全部联动成一套自动运转的系统。OpenTiny NEXT 在 Web 应用开发里想干的也是这件事单点智能化没有意义要把设计、布局、组件、交互这些环节全部打通应用才能整体变聪明。2. 四个核心智能化能力拆解为什么要这么设计2.1 自然语言生成界面把需求描述直接变成页面结构我们回来后第一个实验就是用自然语言生成一个数据管理页面。OpenTiny NEXT 支持直接输入一句话需求比如生成一个员工列表页包含搜索区、部门筛选、表格、分页表格支持排序它会在几秒钟内生成一个可以跑起来的页面骨架。这里我要说一下背后的原理因为它决定了这个功能的天花板。OpenTiny NEXT 并不是让大模型直接输出整段 HTML而是让模型先输出一个结构化的组件 schema再交给组件引擎渲染成真实页面。{ type: page, sections: [ { type: search-form, fields: [keyword, department] }, { type: filter-bar, fields: [status, dateRange] }, { type: data-table, columns: [name, department, role, status], pageable: true } ] }这个设计的精妙之处在于大模型只负责理解需求并选组件页面长什么样由组件引擎保证。这避免了模型自由发挥导致布局乱、组件样式不可控的问题。生成结果里每一个 section 都能对应到团队组件库里的真实组件后续接接口、改样式都还是常规开发流程。我们实测下来对于表单、列表、详情、审批流这类中后台高频页面生成质量已经能到能跑通的程度。对于偏营销的创意型页面比如大视觉的官网首页效果就一般。这符合我的预期因为这类页面本来就应该由设计师主导AI 强行生成反而别扭。2.2 设计稿转代码从视觉稿到组件代码的关键一跳第二个能力是设计稿转代码。过去这类工具有不少但大多停留在把设计稿变成静态 HTML的水准遇到团队自有的设计规范就歇菜。OpenTiny NEXT 的思路不太一样它把视觉识别和组件映射拆成了两步。第一步视觉模型读出设计稿的图层结构、坐标、间距、字号、圆角这些信息第二步把这些信息跟团队的 design token 做映射比如把设计稿里的主色 #1677ff映射成组件库里的brand-color把间距 24px 映射成space-6。这一步很关键映射到 token 之后生成的代码就能跟随团队的主题变量自动变化而不是写死一个颜色值。另外它对组件匹配做了容错。很多设计稿里的元素并不是标准组件而是手画的、拼凑的视觉稿。NEXT 的做法是先识别出最接近的组件类型然后允许开发者在界面上手动纠正映射关系。第一次纠正之后这个映射关系会被记录下来下一次再遇到类似元素就能自动匹配。我们测试了一张中等复杂度的商品管理页设计稿生成的页面结构完整度大概在八成左右剩下的两成主要集中在不规则间距和特殊插图上。整体结论是它能帮你省掉从 0 到 80% 的搭建时间但最后 20% 的精细调整还是需要人参与这不算缺陷反而是一种务实的定位。2.3 智能布局与自适应用容器锚点代替手动栅格计算平时写中后台页面最烦的其实是布局。不同内容量、不同屏幕宽度、不同数据密度布局都要跟着变。OpenTiny NEXT 的智能布局模块把这件事简化成了容器锚点 布局策略。你可以把页面的某个区域声明为一个锚点容器比如商品卡片区是一个 anchor系统会自动根据容器宽度、内容高度、数据条数推荐栅格列数和间距密度。想要紧凑一点就选 densitycompact内容量大就切 densitycomfortable配合响应式断点自动切换。GPTLayout anchorproduct-grid rowauto gapspace-4 breakpoints{[ { maxWidth: 768, columns: 2 }, { maxWidth: 1200, columns: 4 }, { maxWidth: 9999, columns: 6 } ]} /上面是示意代码具体 API 以你实际安装版本的文档为准。我想表达的是它把以前散落在 CSS 里的栅格逻辑收敛成了一个可配置的策略参数。虽然这不算特别新的概念但对团队统一布局规范、减少重复样式代码是有实际帮助的。我们团队接手过不少历史项目每个页面栅格写法都不一样统一布局策略之后至少能少一半的样式维护成本。2.4 语义化交互补全把最容易忘的几个状态自动补上这个能力看起来不起眼但实际用起来很惊喜。平时开发列表页loading 状态、空数据状态、错误重试状态、禁用状态、无权限状态这些都要手动写。忙起来忘掉空数据状态是常事测试同学一问没数据的时候页面长啥样就很尴尬。OpenTiny NEXT 在生成页面的时候会自动为每个组件补齐这些语义化交互状态。比如生成一个数据表格默认就会带上 loading 遮罩、空数据插画、请求失败重试按钮的完整代码。生成一个表单会自动带上校验错误提示、必填星标、禁用态样式。我们内部复盘的时候一致认为这个能力是投入产出比最高的一项。因为生成这些交互状态代码本身不复杂但判断哪些组件需要哪些状态、在什么场景下触发展示是需要业务理解的。NEXT 基于组件语义自动推断省去的不是敲代码的时间而是思考遗漏的成本。3. 实操把一个传统商城列表页改造成智能化开发流水线3.1 环境准备Node 版本、包管理器和项目脚手架纸上谈兵没意思说说我们实际动手的过程。我们自己内部维护了一个中后台管理系统这次选了一个任务管理列表页作为试点。环境是 Node.js 20 pnpm这是一个比较稳的组合。初始化项目我们用的是 OpenTiny NEXT 提供的 CLInpx opentiny/cli init task-manager --template next-starter cd task-manager pnpm install pnpm dev跑起来之后项目里已经预置了 OpenTiny NEXT 的组件库和智能化插件。需要注意CLI 版本更新很快具体命令名和模板名以你执行时的官方文档为准。我第一次跑的时候正好赶上版本小更新next-starter这个模板名在当时的版本里是存在的但如果你安装的是更新版本建议先执行--help看一眼可用的模板列表避免照着文章敲命令却报错。3.2 用自然语言生成页面骨架一个提示词搞定基础结构环境就绪后我打开智能化面板输入了下面这段提示词生成一个任务管理列表页包含关键字搜索框、状态筛选标签、任务表格表格列包括任务名称、负责人、优先级、截止时间、状态列支持分页和排序。页面需要有空数据状态和加载中状态。大约过了三秒钟页面骨架就生成出来了。生成结果的结构和我在 2.1 节展示的 schema 一致页面渲染出来后搜索框、筛选标签、表格、分页都在而且空数据插图和 loading 遮罩的代码也已经写在组件里了。这里分享一个提示词技巧把页面类型 包含区域 表格字段 需要的状态四件事一次性说清楚生成质量最高。如果只说生成一个列表页模型不知道列表里放什么字段就只能给一个通用模板后续还得改半天。3.3 上传设计稿做视觉补全规范化的关键一步骨架生成后我尝试用设计稿转代码能力把页面做得更贴近设计。我们的设计同学基于现有的任务管理页面重新出了一版视觉稿我把稿子导成 PNG 上传到面板里。系统识别出来的结果大体没问题。搜索框、筛选标签、表格、分页的位置都对应上了字体颜色和间距也都映射到了我们项目的 design token。有两处小偏差一是表格的表头行高识别成了 48px实际应该是 40px二是筛选标签的圆角识别成了 8px我们的规范是 4px。这两个问题我直接在生成结果的配置面板里改掉了不需要去改代码改完实时生效。从这个过程能看出这套工具对设计规范的亲和度它不是在还原一张图而是在匹配一套规范。识别偏差的容错方式也合理配置项可以直接修正不用回到设计稿重新识别。3.4 布局参数微调让页面在不同屏幕下都体面页面生成后我打开布局配置面板调整了几个参数。默认的栅格宽度是固定 100%我把内容区最大宽度设成 1440px并给表格旁边的操作按钮区域设了一个窄断点在小于 1024px 的屏幕上自动收进更多下拉按钮里。这一步完全是可视化的不用写媒体查询。它底下生成的代码是标准的 CSS Grid 和 container query如果后续要交给其他同事维护拆开看也不难理解。我个人的建议是不要把布局参数调得太细生成器给出的默认值通常已经覆盖了主流场景。你只需要关注两个地方一个是内容区的最大宽度一个是操作区域在小屏下的收纳方式这两个直接影响中后台页面的日常使用体验。3.5 接入真实数据与人工 review生成代码要怎么收敛页面结构 OK 之后接下来就是传统活。我把生成代码里的 mock 数据源替换成了后端接口接入分页参数和排序参数。这一步没有捷径因为后端字段跟页面字段不一定同名但有了页面骨架之后改起来很直接。接入完成后我做了一次人工 review重点看三方面表单校验规则、表格列的自定义渲染、权限控制。前两者是业务逻辑AI 没法替你决策第三个我单独看了一眼生成代码里没有内置任何权限指令所以我在页面顶层包了一个权限包裹组件确保无权限用户看不到编辑和删除按钮。这里我想强调一条经验AI 生成的东西一定要把它当作你写的代码来 review而不是AI 给的答案来接受。尤其在权限、数据安全、业务状态机这些地方人工把关是绝对不可省的一环。4. 本地部署与私有化把智能化能力关在自己家里4.1 为什么 Web 应用智能化要关注本地部署最近本地部署大模型让个人电脑智能化在技术社区讨论很多原理并不复杂把模型跑在自己的机器或内网服务器上数据不出域响应可控离线也能用。把这个思路放到 Web 应用智能化场景里理由其实是一样的。我们在做智能化改造试点的时候第一个被问到的就是设计稿传上去安不安全代码生成过程中料会不会被留存。这两个问题如果不解决再好的智能化能力团队也不敢用。OpenTiny NEXT 在这点上给了明确的路线模型可以分层部署敏感数据本地处理只有非敏感需求可以走云端大模型。4.2 模型选型按团队规模和敏感度分三层我整理了这样一个选型分层逻辑适合大多数中小团队直接参考层级运行环境适合场景硬件要求典型使用方式本地轻量版个人开发机日常代码生成、单页调试8GB 显存起步离线使用、数据不出本机私有化服务版团队内网服务器设计稿解析、批量生成、统一词表如 1 张 24GB 显存显卡即可内网访问、敏感业务数据可用云端 API 版公共云服务非敏感需求、探索性生成、快速验证无需自建效果最强、按量付费我们团队只有十几个人最终选的是私有化服务版主要原因是我们手上有一批客户项目的设计稿里面包含业务数据不能传到外部服务。部署私有化版本之后设计稿上传和代码生成全部走内网这一块的安全性顾虑就解决了。4.3 私有设计规范注入让 AI 生成符合你的规范而不是大众规范本地部署除了数据安全还有一个额外的好处你可以把团队自己的组件词表和设计 token 注入到模型服务里让 AI 更加理解你说的按钮到底是哪种按钮、主色到底是多少号颜色。具体做法是维护一份映射表把团队设计规范里的术语和组件名传给本地模型服务。例如卡片映射到TinyCard、下拉映射到TinySelect、标签映射到TinyTag。模型在生成 schema 时就会优先使用这些组件名而不是生成一个模棱两可的通用标签。这个步骤很值得做它相当于给 AI 做一次入职培训。不做的话AI 生成的页面总是带着一种大众脸气质组件都对但跟团队的视觉习惯不对味。做了之后生成的页面一眼看去就是你自己团队的东西。4.4 数据安全的边界建议哪些数据可以出域、哪些必须留下最后把安全边界说清楚纯属我们自己定的红线供参考不一定适合所有团队设计稿原件、包含真实业务数据的表格、客户信息、企业内部的权限结构这些一律只走本地部署的模型服务。脱敏后的页面结构描述、不包含业务数据的通用组件问题、公开的组件用法咨询可以走云端 API 以获取更好的生成效果。代码生成请求里凡是会带出字段名的一律在发出去之前做字段名替换生成完再替换回来。这个边界方案我们已经跑了小半年没有出过数据问题。智能化能力确实好用但安全边界就是那条命放松不得。5. 踩坑实录接入 OpenTiny NEXT 智能化链路的问题排查5.1 模型输出的组件名和实际组件库对不上第一个遇到的坑是模型生成的组件名跟我们本地组件库差了十万八千里。比如我们团队习惯用TinyDataGrid做表格模型第一轮生成的是DataTable虽然页面能显示但后续维护要改组件名很别扭。原因是模型训练数据里用的通用命名跟每个团队的真实组件命名不同。解决办法就是我在 4.3 节说的词表注入。把自定义映射表配好之后再生成的代码就全部使用团队规范组件名这个问题基本解决。5.2 生成的页面偶尔出现布局错乱有几次生成的页面在窄屏下表现很怪卡片区域没有收缩表格列也不换行。排查下来发现是智能布局模块在识别栅格策略时把部分区块当成了固定宽度容器。处理方式是在布局配置面板里把这个区域从 fixed 改成 fluid并设置最小宽度阈值。改完之后窄屏适配就正常了。这里也建议各位在生成之后用浏览器开发者工具切一次移动端视图花一分钟验证响应式能省掉后面很多返工。5.3 设计稿识别偏差集中在间距和圆角设计稿转代码识别错的概率不高但一旦错多半集中在间距和圆角这类数值上。一开始我们还以为是视觉模型精度不行后来发现是设计稿里用了不规范的自由绘制图层没有按 8px 栅格对齐。AI 只能忠实识别出 13px、17px 这种脏数据。这个问题的真正解法不在模型侧而在设计侧。我们跟设计同学约定所有交付给智能化流程的稿子先过一遍规范检查间距必须是 8 的倍数圆角只用规定的几个档位。做了这个约定之后设计稿识别的准确率直线上升。这个经验比调试模型参数有用得多。5.4 生成代码的可维护性结构化模板是关键还有同事担心生成代码不好维护。我们试过不同的生成模式发现 OpenTiny NEXT 生成出来的代码结构是模板化的页面组件、区块组件、配置数据各自分层。只要后续人不去硬写新的 CSS 覆盖而是通过配置参数调整页面代码的可维护性没问题。我们入了一个团队约定凡是由智能化生成的新页面必须保留 schema 配置文件后续改动优先改配置而不是改默认代码。这样一来哪怕 AI 重新生成一次页面也只需要替换配置不会把同事的手改动弄丢。这个约定坚持了两个迭代效果很好。下面是我们在一个多月里频繁遇到的问题速查整理成表格方便翻阅问题典型原因处理建议生成的组件名不是团队规范词表未注入维护自定义组件词表并注入模型服务窄屏下布局不收缩部分区块被识别为固定宽度布局配置改为 fluid 并设置最小宽度设计稿间距识别不准设计稿存在非 8 栅格数值在设计端统一规范后再上传生成代码被后续人员改乱没有保留 schema 配置约定配置驱动改动不直接改生成代码页面权限缺失模型不具备业务语义生成后人工补充权限包裹组件6. 团队落地试点选型、验收标准和节奏建议6.1 哪些页面适合第一批试点不是所有页面都适合一上来就智能化改造。我们做下来的经验是中后台的表单页、列表页、详情页、审批流页面是最适合的因为它们结构标准化程度高、组件复用率高、AI 生成质量好。不适合第一批试点的是偏创意的活动页、营销页、品牌官网首页以及重度可视化的复杂图表页面。前者需要强烈的视觉个性AI 生成的模板感太强后者交互复杂图表配置精细人工手写反而更快。选试点页面还有一个原则选那种团队成员都不愿意做的页面而不是技术含量最高的页面。这样智能化改造的效果最容易被感知也最容易获得团队认可。6.2 创建 AI 生成物的验收标准既然 AI 可以生成页面了团队就必须要有一套验收标准否则质量参差不齐。我们内部定的标准是四条交互状态齐全、响应式无错位、组件命名符合规范、权限控制无遗漏。交互状态指的是 loading、empty、error 三件套必须存在响应式要求在主流三档窗口宽度下不出现横向滚动条和元素重叠组件命名直接抽查几个关键组件不在自定义词表里的勒令整改权限控制是硬性要求涉及操作按钮的部分必须经过人工确认。这四条验证通过生成页面才允许合入主线。6.3 分阶段推进一周准备、两周试点、三周回头看最后说一下我们的推进节奏。第一周做基础准备包括搭建 CLI 环境、配置私有化模型服务、整理组件词表和设计 token 映射表。第二周挑两个列表页 一个表单页做正式试点记录效率数据和问题清单。第三周回头看把生成代码的缺陷率、人工返工时长、团队接受度做一次汇总再决定扩大到哪些页面。三周下来我们的结论是值得推广但不是无差别推广。掌握了工具特性的老同事效率提升明显不理解AI 生成需要 review的新同事会给评审带来不少返工工作量。所以建议后期正式铺开时把之前记录的踩坑清单整理成一个一小时的培训课程新加入的同事先看完再上手能少踩很多坑。我个人在实际操作中的体会是OpenTiny NEXT 最打动我的不是生成速度有多快而是它把智能化这件事做得足够克制。它没有试图替代开发者而是把最枯燥的搭建环节自动化把决策环节留给人。这一代开发者或许真的能告别设计稿翻译工这个角色了。最后再分享一个小技巧智能化生成功能最适合从空白页开始的场景如果是要改一个祖传老页面先别急着让 AI 重写把它拆成几个区块再做局部生成对比效果比整体替换好得多。