OpenTiny NEXT 实战：用前端 AI SDK 与 GenUI 为 Web 应用注入智能能力

1. 从 HC 2026 现场看 OpenTiny NEXT 到底想解决什么问题今年 HC 大会我全程跟了下来OpenTiny 展台前前后后去了三趟。倒不是说展台布置得多花哨而是他们这次抛出来的 OpenTiny NEXT 确实踩到了很多前端团队正在头疼的那个点上——Web 应用怎么真正接上 AI 能力而不是在页面上挂一个聊天框就完事。先说清楚 OpenTiny NEXT 是什么。它是 OpenTiny 团队在 HC 2026 上正式对外发布的一套面向 Web 应用的智能化开发套件核心由三块组成一套前端 AI SDK、一套 GenUI 生成式界面引擎、以及一套把 AI 能力注入现有 Web 工程的适配层。说白了它想做的事情是让一个已经跑了三五年的中后台系统不用推倒重来就能把 AI 对话、智能表单、动态界面生成这些能力长进去。这件事为什么值得单独拿出来讲因为过去一年我接触过的前端团队十个里有八个都在做同一件事老板说我们要加 AI。然后团队花两周接了个大模型 API在右下角放了个悬浮球点开是个对话框。上线之后发现没人用因为用户要的是帮我把这批数据按季度汇总成图表而不是你好我是智能助手请问有什么可以帮您。OpenTiny NEXT 的思路不太一样。它把 AI 能力拆成了几个可组合的原子能力通过 SDK 的形式暴露给前端工程让开发者可以在具体的业务组件里按需调用。比如表格组件可以调用它的智能列配置能力表单组件可以调用它的自然语言转表单能力页面容器可以调用它的 GenUI 动态渲染能力。这个拆法我觉得是对的因为 AI 在 Web 应用里的价值从来不是有一个对话框而是让已有的交互变聪明。适合谁来参考这篇内容三类人。第一类是前端架构师正在评估怎么把 AI 能力体系化地引入现有工程第二类是中后台业务的前端负责人被老板的 AI 需求追着跑但不想做面子工程第三类是对 GenUI、前端 SDK 设计感兴趣的开发者想看看大厂在这块是怎么抽象接口的。如果你只是想知道怎么调一个对话 API那这篇可能不太对你的胃口。2. OpenTiny NEXT 的整体设计与方案选型拆解2.1 为什么是 SDK 而不是平台这是我在现场问的第一个问题。市面上做 AI 加 Web 的方案主流有两种路线一种是做一个 AI 中台业务方接入中台中台统一管理模型、提示词、会话另一种就是 OpenTiny NEXT 选的这条做 SDK把能力下沉到前端工程里。两种路线没有绝对优劣但适用场景差别很大。中台路线适合大集团、多业务线、需要统一管控的场景缺点是重接入周期长前端团队想调个参数得走工单。SDK 路线适合单一业务团队快速落地前端自己就能控制调用时机、参数、降级策略缺点是能力治理要靠团队自觉。OpenTiny NEXT 选 SDK 路线我理解背后的判断是AI 在 Web 应用里的调用点太分散了。一个页面里可能有十几个地方需要 AI 能力有的在表格列头有的在表单校验有的在搜索框。如果每个调用点都走中台网络往返和治理成本都受不了。SDK 直接跑在浏览器里调用链路短响应快而且可以跟组件生命周期绑定。提示SDK 路线的一个隐含前提是前端团队要有一定的工程能力能自己管理 API Key 的代理、能做请求降级、能处理流式响应的异常。如果团队里没人碰过这类事情建议先从中台路线起步。2.2 GenUI 为什么放在核心位置GenUI 这个词这两年出现频率很高但各家理解不一样。有的把它理解成AI 生成页面代码有的理解成AI 生成 JSON Schema 然后渲染。OpenTiny NEXT 的 GenUI 属于后者而且做得更细一层——它不是生成整个页面而是生成页面里的某个区块。这个选择很关键。生成整个页面听起来酷但实际落地时问题一堆生成的代码风格跟现有工程不一致、状态管理接不上、路由对不上、样式冲突。生成区块就务实多了区块的边界清晰输入输出可控跟现有工程的耦合面小。我现场看了一个 demo一个订单管理页面用户输入把最近三个月退款率超过 5% 的商品列出来按退款率倒序GenUI 引擎解析后动态生成了一个带筛选条件、排序规则、数据源配置的表格区块直接嵌在原有页面里。原有页面的头部、侧边栏、其他区块都没动。这个粒度我觉得是能落地的粒度。2.3 前端 AI SDK 的接口抽象思路OpenTiny NEXT 的 SDK 接口设计有几个细节值得说。它没有把所有能力塞进一个大对象里而是按能力域拆成了多个子模块ai.chat、ai.form、ai.table、ai.genui、ai.agent。每个子模块有自己的配置项和生命周期钩子。另一个细节是它区分了同步能力和流式能力。像自然语言转表单这种输入一句话输出一个表单配置属于同步能力一次请求一次响应。像对话、Agent 执行这种属于流式能力需要处理 SSE 或 WebSocket 的增量数据。SDK 对这两类能力用了不同的接口形态同步能力返回 Promise流式能力返回一个可迭代的流对象。这个区分看起来是小事但实际用起来差别很大。我见过太多 SDK 把流式能力包装成 Promise结果开发者拿到的是一个等全部生成完才 resolve的假流式用户体验跟同步没区别。OpenTiny NEXT 在这块没有偷懒。2.4 与现有 Web 工程的集成方式集成方式上OpenTiny NEXT 提供了三种粒度。最轻的是 CDN 引入适合老项目快速试水中间的是 npm 包按需引入适合有构建体系的工程最重的是工程级集成会往项目里注入配置文件、代理层、类型定义。我建议大多数团队从第二种开始。CDN 引入虽然快但类型提示没有调试体验差而且不好做 Tree Shaking。工程级集成虽然完整但会改动项目结构老项目接入时容易跟现有构建流程打架。npm 按需引入是个平衡点改动能控制在一个文件里。3. 核心能力拆解与实操要点3.1 前端 AI SDK 的初始化与配置SDK 初始化这块我踩过的坑主要在两个地方一是 API Key 的存放位置二是请求代理的配置。API Key 绝对不能放在前端代码里这是底线。OpenTiny NEXT 的文档里也强调了这一点推荐的做法是在自己的后端搭一个代理层前端 SDK 请求代理层代理层再去请求模型服务。代理层要做的事情包括鉴权、限流、日志、以及把模型服务的响应格式转换成 SDK 期望的格式。代理层的配置我一般会写成一个独立的配置文件大概长这样// ai-proxy.config.js export default { endpoint: /api/ai/proxy, timeout: 30000, retry: { maxAttempts: 2, backoff: exponential }, stream: { enabled: true, heartbeat: 15000 }, fallback: { onError: silent, message: 智能服务暂时不可用 } };timeout设 30 秒是因为大模型生成有时候确实慢设太短会频繁超时。retry设 2 次是因为网络抖动导致的失败重试一次基本能恢复重试太多次反而会放大服务端压力。heartbeat是流式连接的保活间隔15 秒是个经验值太短浪费请求太长容易被中间层断开。SDK 初始化代码本身不复杂import { createAI } from opentiny/next-sdk; const ai createAI({ proxy: /api/ai/proxy, modules: [chat, form, table, genui], locale: zh-CN, debug: process.env.NODE_ENV development });modules这个配置项我建议按需声明不要全开。全开的话打包体积会大不少而且有些模块初始化时会注册全局事件监听用不到的话是浪费。3.2 GenUI 区块生成的参数与边界控制GenUI 是 OpenTiny NEXT 里最需要小心使用的能力。它强大但也最容易失控。核心是要把生成的边界控制好。我一般会从三个维度设边界数据维度、交互维度、样式维度。数据维度控制的是 GenUI 能访问哪些数据源。不能让它随便查库要给它一个白名单。比如const genuiConfig { dataSources: [ { id: orders, schema: orderSchema, fields: [id, amount, status, createdAt] }, { id: refunds, schema: refundSchema, fields: [orderId, rate, reason] } ], maxRows: 1000, timeout: 5000 };maxRows设 1000 是防止生成的查询把数据库拖垮。timeout设 5 秒是防止慢查询阻塞页面。交互维度控制的是生成的区块能做什么。默认情况下GenUI 生成的区块应该是只读的不能直接触发写操作。如果业务确实需要写操作要显式声明const genuiConfig { interactions: { read: true, write: false, export: true, drilldown: true } };样式维度控制的是生成的区块跟现有页面的视觉一致性。OpenTiny NEXT 支持传入一个主题 token 对象GenUI 生成时会参考这些 tokenconst themeTokens { primaryColor: #1677ff, borderRadius: 6px, fontSize: 14px, spacing: 16px };不传 themeTokens 的话生成的区块会用默认样式跟现有页面大概率不搭。传了之后一致性会好很多但也不是 100%复杂组件还是需要人工微调。3.3 自然语言转表单的实现细节自然语言转表单是我觉得最实用的能力之一。中后台系统里表单太多了每个表单都要前端手写费时费力。用 AI 生成表单配置前端只需要渲染能省不少事。实现上SDK 会把自然语言描述转成一个表单 Schema前端拿到 Schema 后用现有的表单渲染器渲染。Schema 的格式我贴一个实际的例子{ fields: [ { name: productName, label: 商品名称, type: string, required: true, maxLength: 100 }, { name: refundRate, label: 退款率, type: number, min: 0, max: 100, precision: 2, suffix: % }, { name: refundReason, label: 退款原因, type: enum, options: [质量问题, 尺寸不符, 物流损坏, 其他], multiple: true } ], layout: vertical, labelWidth: 120px }这个 Schema 的字段类型是有限的SDK 文档里列了支持的类型string、number、boolean、date、enum、array、object。超出这个范围的需求AI 会尽量往最近似的类型上靠但可能不准。所以我的经验是用这个能力生成表单初稿然后人工过一遍比从零手写快但别指望完全不用改。注意自然语言转表单的准确率跟描述的详细程度强相关。你写做一个商品表单生成的结果会很泛。你写做一个商品表单包含商品名称必填最多100字、退款率0到100的百分比保留两位小数、退款原因多选选项为质量问题、尺寸不符、物流损坏、其他生成的结果基本能直接用。3.4 智能表格的列配置与数据映射智能表格能力解决的是另一个高频痛点表格列太多用户找不到想要的列或者不同角色的用户需要看不同的列。OpenTiny NEXT 的做法是让用户用自然语言描述需求SDK 生成列配置。列配置包括显示哪些列、列的排序、列的宽度、列的格式化方式。const tableConfig await ai.table.generateColumns({ dataSource: orders, userIntent: 我只关心订单金额、状态和下单时间金额要显示成带千分位的, role: finance });生成的结果大概是这样{ columns: [ { field: amount, title: 订单金额, width: 140, formatter: thousands }, { field: status, title: 状态, width: 100, formatter: statusTag }, { field: createdAt, title: 下单时间, width: 180, formatter: datetime } ] }这里有个细节formatter字段引用的是前端已经注册的格式化函数。SDK 不会生成格式化逻辑本身只会引用。这样做的好处是格式化逻辑可控不会出现 AI 生成的格式化代码有 bug 的情况。坏处是前端需要预先注册一批 formatter没注册的 formatter 会降级成默认显示。我一般会注册这么一批 formatterthousands千分位、percent百分比、datetime日期时间、date日期、statusTag状态标签、currency货币、fileSize文件大小。基本覆盖中后台的常见场景。4. 完整实操流程与关键环节实现4.1 从零搭建一个带 AI 能力的订单管理页面我拿一个实际做过的项目来拆。需求是一个订单管理页面支持自然语言筛选、智能列配置、以及一个 AI 助手侧边栏。第一步是工程准备。我用的是 Vite Vue 3先装依赖npm install opentiny/next-sdk opentiny/vue第二步是配置代理层。我在 Vite 的 dev server 里加了一个中间件生产环境用的是 Nginx 转发。代理层的核心逻辑是接收前端请求加上 API Key转发给模型服务把响应转成 SSE 格式返回。// vite.config.js export default defineConfig({ server: { proxy: { /api/ai/proxy: { target: http://localhost:3001, changeOrigin: true } } } });第三步是初始化 SDK。我在 main.js 里做全局初始化把实例挂到 app.config.globalProperties 上方便各组件调用。import { createApp } from vue; import { createAI } from opentiny/next-sdk; import App from ./App.vue; const app createApp(App); const ai createAI({ proxy: /api/ai/proxy, modules: [chat, table, genui], locale: zh-CN }); app.config.globalProperties.$ai ai; app.mount(#app);第四步是实现自然语言筛选。我在页面顶部放了一个搜索框用户输入自然语言回车后调用 SDK 的解析能力把自然语言转成筛选条件然后刷新表格。async function handleNaturalSearch(input) { const filters await this.$ai.table.parseFilter({ dataSource: orders, input, schema: orderSchema }); this.filters filters; this.loadData(); }parseFilter返回的是一个结构化的筛选条件对象格式跟大多数表格组件的 filter 配置兼容。如果返回的条件里有表格组件不支持的运算符需要在前端做一次映射。第五步是实现智能列配置。我在表格右上角放了一个列设置按钮点开后除了常规的勾选列表还有一个输入框用户可以用自然语言描述想要的列。async function handleColumnIntent(intent) { const config await this.$ai.table.generateColumns({ dataSource: orders, userIntent: intent }); this.columns config.columns.map(col ({ ...col, formatter: this.formatters[col.formatter] || this.formatters.default })); }第六步是实现 AI 助手侧边栏。这个用的是 chat 模块支持流式响应。async function sendMessage(text) { const stream await this.$ai.chat.stream({ messages: this.messages, context: { page: order-management, currentFilters: this.filters, visibleColumns: this.columns.map(c c.field) } }); for await (const chunk of stream) { this.currentReply chunk.content; } }context这个参数很关键。把当前页面的状态传给 AIAI 的回答才能跟当前场景相关。不传 context 的话AI 只能给通用回答价值大打折扣。4.2 参数计算与性能调优SDK 用起来之后性能是个绕不开的话题。我实测下来几个参数对性能影响最大。第一个是流式响应的 chunk 大小。SDK 默认的 chunk 大小是 20 个字符左右这个值偏小导致渲染频率过高。我调到 50 之后渲染帧率明显改善用户感知的流畅度反而更好因为人眼对 50 字符的增量感知跟 20 字符差不多但渲染压力小了一半。第二个是 GenUI 的缓存策略。GenUI 生成一个区块大概需要 1 到 3 秒如果每次进页面都重新生成体验很差。我的做法是把生成结果按用户意图 数据源 schema 哈希做缓存缓存有效期设 24 小时。同一个用户重复问同样的问题直接命中缓存。const cacheKey ${userId}:${hash(intent)}:${hash(schemaVersion)}; const cached await cache.get(cacheKey); if (cached) return cached; const result await ai.genui.generate({ intent, schema }); await cache.set(cacheKey, result, 86400);第三个是并发控制。一个页面里可能有多个 AI 调用点如果同时发起会打爆代理层。我加了一个简单的并发队列最多同时 3 个请求超出的排队。class AIQueue { constructor(concurrency 3) { this.concurrency concurrency; this.running 0; this.queue []; } async add(task) { if (this.running this.concurrency) { await new Promise(resolve this.queue.push(resolve)); } this.running; try { return await task(); } finally { this.running--; const next this.queue.shift(); if (next) next(); } } }4.3 降级策略与异常处理AI 能力再强也有不可用的时候。模型服务挂了、网络断了、代理层限流了这些都会发生。降级策略做不好AI 能力就是系统的脆弱点。我的降级策略分三层。第一层是超时降级请求超过 8 秒没响应直接返回降级结果同时后台继续等待等到了再更新 UI。第二层是错误降级请求失败时如果是筛选类能力降级成传统筛选表单如果是列配置类能力降级成默认列配置如果是对话类能力降级成提示文案。第三层是熔断降级连续失败 5 次后熔断 60 秒期间所有请求直接走降级不再尝试。const circuitBreaker { failures: 0, threshold: 5, cooldown: 60000, lastFailure: 0, canTry() { if (this.failures this.threshold) return true; if (Date.now() - this.lastFailure this.cooldown) { this.failures 0; return true; } return false; }, recordFailure() { this.failures; this.lastFailure Date.now(); } };提示降级策略一定要在接入 AI 能力的第一天就做不要等出问题了再补。我见过一个项目AI 能力上线后模型服务挂了半天整个订单页面白屏因为筛选逻辑强依赖 AI 返回。这种事故完全可以通过降级避免。5. 常见问题与排查技巧实录5.1 SDK 初始化失败与模块加载问题问题现象控制台报failed to load plugins或者某个模块的方法调用时报 undefined。排查思路先看modules配置里有没有声明这个模块。OpenTiny NEXT 的模块是按需加载的没声明就不会注册。再看 SDK 版本跟模块版本是否匹配有时候 SDK 升级了但某个模块没跟着升会出现接口不兼容。我遇到过一次ai.genui一直 undefined查了半天发现是modules数组里写的是genUI大小写错了。SDK 对模块名是大小写敏感的文档里写的是小写genui。这种低级错误排查起来最费时间建议配置项都从文档里复制别手敲。另一个常见问题是代理层返回的格式不对。SDK 期望的响应格式是特定的如果代理层直接把模型服务的原始响应透传SDK 解析会失败。代理层需要做一次格式转换把模型服务的响应转成 SDK 期望的格式。这个转换逻辑 SDK 文档里有示例照着改就行。5.2 流式响应中断与重连问题现象对话进行到一半突然停了没有报错也没有后续内容。排查思路先看网络面板确认是连接断了还是服务端没发数据。如果是连接断了看断开的时机如果是固定 30 秒或 60 秒断开大概率是中间层Nginx、网关的超时配置。Nginx 默认的proxy_read_timeout是 60 秒流式响应超过 60 秒没数据就会被断开。解决办法是在 Nginx 配置里调大这个值同时开启proxy_buffering off让数据实时透传location /api/ai/proxy { proxy_pass http://backend; proxy_read_timeout 300s; proxy_buffering off; proxy_cache off; chunked_transfer_encoding on; }如果是服务端没发数据看是不是模型服务在长文本生成时卡住了。这种情况需要在代理层加心跳每隔 15 秒发一个空 chunk保持连接活跃。重连逻辑我一般这样写检测到流中断后记录已接收的内容重新发起请求时把已接收的内容作为上下文传过去让模型接着生成。这样用户感知上就是卡了一下又继续了而不是从头再来。5.3 GenUI 生成结果不符合预期问题现象GenUI 生成的区块跟用户想要的差很远或者生成的区块渲染报错。排查思路先看用户输入的意图描述是否足够具体。GenUI 对模糊描述的处理能力有限给我做个报表这种输入生成结果基本靠猜。要引导用户把需求说清楚或者在 UI 上给一些示例输入。再看数据源 schema 是否完整。GenUI 生成时会参考 schema 里的字段名、类型、注释。如果 schema 里字段没有注释GenUI 只能靠字段名猜含义准确率会下降。我一般会在 schema 里给每个字段加description这个投入产出比很高。const orderSchema { fields: [ { name: amount, type: number, description: 订单金额单位元 }, { name: status, type: enum, description: 订单状态, options: [待付款, 已付款, 已发货, 已完成, 已取消] }, { name: createdAt, type: date, description: 下单时间 } ] };如果生成的区块渲染报错先看控制台的错误信息。常见的是生成的配置里引用了不存在的 formatter 或组件。这种情况在前端做一次校验把无效引用替换成默认值。5.4 常见问题速查表问题现象可能原因排查动作解决方案SDK 初始化报错模块名拼写错误检查 modules 配置从文档复制模块名某模块方法 undefined模块未声明检查 modules 数组添加对应模块流式响应 60 秒断开中间层超时查看网络面板断开时机调大 proxy_read_timeout流式响应无数据服务端卡住检查模型服务日志代理层加心跳GenUI 结果偏差大意图描述模糊检查用户输入引导具体描述或给示例GenUI 渲染报错引用了无效 formatter查看控制台错误前端校验并替换默认值请求频繁超时模型服务慢查看请求耗时分布调大 timeout 或加缓存页面卡顿流式渲染频率过高查看渲染帧率调大 chunk 大小5.5 几个我踩过的坑第一个坑是 API Key 泄露。早期图省事把 API Key 写在了前端环境变量里结果打包后能在 bundle 里搜到。虽然后来紧急换了 Key 并加了代理层但这件事给我提了个醒任何跟前端沾边的密钥都要假设它会泄露。代理层不是可选项是必选项。第二个坑是没做请求去重。用户快速点击搜索按钮会发起多个相同的 AI 请求浪费额度还拖慢响应。后来加了一个请求指纹相同指纹的请求在 1 秒内只发一次后续请求复用第一个的结果。第三个坑是忽略了移动端。桌面端跑得好好的移动端一测流式响应在弱网下频繁中断GenUI 生成的区块在小屏上布局错乱。后来针对移动端单独调了 chunk 大小和 GenUI 的布局约束才勉强能用。如果你的项目有移动端建议一开始就把移动端纳入测试范围。第四个坑是没做用量监控。AI 调用是有成本的不监控的话月底账单出来才知道超了。我后来在代理层加了一个简单的计数器按用户、按接口、按天统计调用次数和 token 消耗超阈值告警。这个投入不大但能避免很多麻烦。6. 我对 OpenTiny NEXT 这套东西的实际判断用下来这几个月我的整体判断是OpenTiny NEXT 在Web 应用接 AI这件事上方向是对的抽象层次也是对的。它没有去追那些听起来很酷但落不了地的概念而是老老实实把 SDK 接口设计好把 GenUI 的边界控制好把降级和异常处理考虑进去。这些东西不性感但真正做工程的人知道这些才是决定一个方案能不能上生产的关键。当然也有我觉得可以更好的地方。比如 GenUI 的缓存策略目前需要业务方自己实现SDK 层面如果能提供一套默认的缓存机制接入成本会更低。再比如流式响应的重连逻辑目前也是业务方自己写如果 SDK 能封装一层开发者会省不少事。还有文档有些接口的参数说明不够详细我是靠读源码才搞明白的。不过这些都是细节不影响整体判断。如果你正在评估怎么给现有 Web 应用加 AI 能力OpenTiny NEXT 值得花两天时间做个 POC。我的建议是先从一个具体的、边界清晰的能力开始试比如自然语言转表单跑通了再往其他能力扩展。不要一上来就全量接入那样出了问题不好定位。最后分享一个小技巧接入 AI 能力之前先把你现有系统的组件库、数据 schema、格式化函数整理一遍。这些东西整理得越清楚AI 能力接入后效果越好。AI 不是凭空变出能力它是基于你已有的东西做组合和生成。你已有的东西越规整它组合出来的结果就越靠谱。这个准备工作看起来跟 AI 无关但实际上是整个接入过程中最影响最终效果的一步。