从“会聊天”到“会搭页面”：一次 TinyEngine + MCP 的前端智能化实战思路

前端智能化这两年有一个很明显的变化：

AI 的角色，正在从"页面里的聊天助手"变成"真正参与页面生成、组件选择、工具调用和交互执行的开发助手"。

如果把这个趋势拆开看，至少有 4 个关键方向：

AI 对话
MCP / WebMCP 工具调用
生成式 UI
低代码平台承接 AI 结果

在这条链路里，我认为一个很值得写、也很值得实践的组合是：

TinyEngine + TinyVue + MCP

原因很简单：

TinyEngine 能承接"AI 生成的页面结构"
TinyVue 能提供可复用的组件物料
MCP 能让 AI 不只是输出文字，而是查询组件、模板、规范和业务工具
三者组合后，AI 才真正从"会聊天"变成"会搭页面"

这篇文章不写泛泛概念，而是从开发者视角，尝试梳理一条更可落地的路径：

如何用 TinyEngine 作为页面承接层，让 AI 生成页面骨架，再通过 MCP 调用工具，让结果从一次性文本输出变成可继续编辑的前端页面。

一、为什么 TinyEngine 是"前端智能化"的关键承接层

TinyEngine 的官方定位很明确：

TinyEngine is a low-code engine based on which you can build or develop low-code platforms in different domains.

简单说，它不是一个单纯的页面编辑器，而是一个可定制、可扩展、可二次开发的低代码引擎。

官方仓库和文档里提到的能力包括：

在线实时搭建页面
支持二次开发或集成
支持第三方组件接入
支持高低代码混合开发
直接生成可部署源码
平台接入 LLM 能力辅助搭建应用

这几点放在一起，意味着 TinyEngine 特别适合做一件事：

承接 AI 生成结果。

传统 AI Coding 的常见结果是：

一段 Vue 代码
一段 React 代码
一个 HTML/Tailwind 页面

这些结果的问题在于：
能看，但不好继续改。

而 TinyEngine 的价值在于：

AI 先生成页面描述
TinyEngine 把它变成可视化页面
前端和产品再继续修改
最终仍可导出源码交付

项目地址：

AtomGit：https://atomgit.com/opentiny/tiny-engine
GitHub：https://github.com/opentiny/tiny-engine

二、为什么光有 AI 还不够，还要有 TinyVue 和 MCP

如果只是"让 AI 生成页面"，很多工具已经能做。

但真正进入业务场景后，问题并不在"能不能生成"，而在：

生成的页面是否用的是现有组件体系
生成结果能否继续维护
AI 是否能调用业务工具，而不是只靠提示词猜

这就是 TinyVue 和 MCP 的作用。

1. TinyVue：给 AI 一个稳定的组件物料层

TinyVue 是 OpenTiny 体系里的核心组件库，官方强调的是：

企业级
多端
Vue2 / Vue3 支持
丰富组件物料

对于 AI 页面生成来说，组件库不是"锦上添花"，而是"边界条件"。

如果没有组件物料层，AI 生成页面时往往会出现这些问题：

组件命名不一致
属性结构不统一
设计风格不稳定
后续不好维护

而如果基于 TinyVue，AI 在生成页面骨架时就有了明确约束：

可选哪些组件
组件有哪些 props
表单、表格、按钮、弹窗怎么组织
页面风格如何统一

TinyVue 文档：
https://docs.opentiny.design/tiny-vue/guide/introduce

2. MCP：让 AI 不只是"猜"，而是"查"

MCP 的价值，核心不在协议本身，而在于它让 AI 可以通过标准方式接入工具。

对于前端智能化来说，一个最典型的问题是：

AI 能不能知道当前项目里有哪些组件？有没有现成页面模板？设计规范要求是什么？接口字段长什么样？

如果只靠 prompt，这些信息很容易过期，也很容易不准。

但如果通过 MCP，把这些能力变成工具，AI 就可以先查，再生成。

例如一个面向 TinyEngine 的 MCP 工具体系，可以很轻量地先定义成：

searchComponents(keyword)：查询可用 TinyVue 组件
getPageTemplate(scene)：查询业务页面模板
getDesignRules(pageType)：查询页面设计规范
getFormSchema(businessType)：查询已有表单结构

这个变化很关键。

因为它把 AI 从"参数记忆型生成器"，变成"可查询、可调用、可执行的页面助手"。

三、一个更适合落地的 demo：需求评审助手页面生成器

为了避免文章停在抽象层，我用一个实际场景来讲：

需求评审助手页面生成器

目标是：

输入一段自然语言需求
AI 自动生成一个评审页面的骨架
页面基于 TinyVue 组件
若需要，AI 可以通过 MCP 查询组件和模板
生成结果进入 TinyEngine 画布，可继续可视化编辑

例如用户输入：

text 复制代码

帮我生成一个"需求评审"页面：
左侧显示需求基础信息，右侧显示评审意见；
底部包含优先级、负责人、状态和提交按钮；
整体风格使用企业后台风格，结构清晰，适配 PC。

一个合理的系统输出，不应该直接是一大段 Vue 代码，而应先转成结构化页面描述，例如：

json 复制代码

{
  "pageName": "requirement-review",
  "layout": "two-column",
  "components": [
    {
      "componentName": "Form",
      "props": {
        "title": "需求基础信息"
      }
    },
    {
      "componentName": "Textarea",
      "props": {
        "label": "评审意见"
      }
    },
    {
      "componentName": "Select",
      "props": {
        "label": "优先级"
      }
    },
    {
      "componentName": "Select",
      "props": {
        "label": "负责人"
      }
    },
    {
      "componentName": "Select",
      "props": {
        "label": "状态"
      }
    },
    {
      "componentName": "Button",
      "props": {
        "text": "提交评审",
        "type": "primary"
      }
    }
  ]
}

这个中间层非常重要。

因为只要有了结构化 Schema，AI 生成的结果就能：

被校验
被纠错
被映射到 TinyEngine 画布
被继续编辑

也就是说，AI 输出不再是一次性代码，而是一个可维护的页面描述。

四、实现这类系统，我建议拆成 4 层

第 1 层：自然语言输入层

负责接收业务需求。

这一层可以是：

聊天输入框
表单式输入
上传需求文档
上传页面草图

TinyEngine 的 AI 插件文档里已经明确提到，它支持：

自然语言搭建页面
上传图片生成页面
对话式调整组件、样式和属性
Agent / Chat 模式切换

这意味着，至少在产品层面，这种交互方向已经是明确的。

官方文档：
https://docs.opentiny.design/tiny-engine/guide/new-ai-plugin-usage.html

第 2 层：页面 Schema 生成层

这一层负责把自然语言转成结构化描述，而不是直接生成代码。

我建议最少包含：

ts 复制代码

interface PageSchema {
  pageName: string
  layout: 'single-column' | 'two-column'
  components: Array<{
    componentName: string
    props?: Record<string, any>
    children?: any[]
  }>
}

这一步的意义有 3 个：

便于校验 AI 输出
便于和 TinyEngine 物料体系对接
便于后续扩展成模板、规则和权限系统

如果没有 Schema 层，AI 结果很容易变成"一次性生成页面"，而不是"可持续编辑页面"。

第 3 层：MCP 工具层

这一层的作用，是让 AI 在生成页面前先查清楚上下文。

一个极简的 MCP 工具定义示意可以是：

json 复制代码

{
  "tools": [
    {
      "name": "searchComponents",
      "description": "根据关键词搜索 TinyVue 组件"
    },
    {
      "name": "getPageTemplate",
      "description": "根据场景获取页面模板"
    },
    {
      "name": "getDesignRules",
      "description": "获取当前业务场景的设计规范"
    }
  ]
}

AI 在执行页面生成时，可以采用这样的流程：

根据用户意图识别场景
调 getPageTemplate 查相似模板
调 searchComponents 查可用组件
调 getDesignRules 补齐布局和交互规则
再生成最终页面 Schema

这时，AI 的生成依据就不是"凭印象"，而是"先查工具，再输出"。

第 4 层：TinyEngine 承接层

这一层负责把页面 Schema 映射成可视化页面，并允许后续人工修改。

TinyEngine 特别适合承接这一步，原因在于它本身就具备：

可视化页面搭建能力
组件物料体系
插件扩展机制
页面导出与交付能力

这也是我认为 TinyEngine 在"AI 前端"里非常关键的一点：

AI 不是替代低代码，而是把低代码变成 AI 可协作的页面生产平台。

五、如果真正落地，这套方案最有价值的不是"生成页面"，而是 3 个能力变化

1. 从"生成代码"变成"生成可编辑页面"

这和常规 AI Coding 的差别很大。

传统生成式前端往往停留在：

给代码
给样例
给静态页面

而基于 TinyEngine 的路径更像：

给结构化页面
进入可视化编辑器
再由人继续修改和交付

这使得 AI 不再是"一次性生成器"，而成为页面生产流程的一部分。

2. 从"问答助手"变成"页面助手"

如果 AI 只能解释组件、生成代码片段，它更像开发问答工具。

但当它能：

帮你选布局
推荐组件
生成页面骨架
修改属性
按规则调整样式

它就开始进入真正的前端工作流。

这也是为什么 TinyEngine 的 AI 插件很值得关注。

官方文档里提到的能力，实际上已经覆盖了这条路径：

创建页面
调整样式
修改属性
调用 MCP 工具
多会话管理

3. 从"会说"变成"会查、会调、会执行"

这是 MCP 最核心的价值。

很多"AI 前端"最大的问题是：

知识不更新
不知道项目有哪些组件
不知道已有模板
不知道设计规范
不知道接口结构

而 MCP 能让这些能力变成工具。

这会直接改变 AI 的工作方式：

先查组件
再查模板
再查规范
最后输出页面

从结果上看，这比单纯优化 prompt 更有效。

六、和普通 AI Coding、Dify、Coze 相比，这条路线有什么不同？

和普通 AI Coding 的区别

普通 AI Coding 更擅长：

写代码
改代码
解释代码

但 TinyEngine + MCP 这条路线更适合：

生成页面结构
对接组件库
用工具查上下文
把结果交回可视化页面平台

也就是说，它更接近"页面生产"，而不是"代码补全"。

和 Dify 的区别

Dify 更偏：

LLM 工作流
RAG / Agent 应用
后台服务型智能应用

而 TinyEngine 更偏：

页面承接
组件物料
低代码编辑
AI 与前端工程结合

Dify 更像 AI 应用平台，

TinyEngine 更像 AI 前端页面平台。

和 Coze 的区别

Coze 更适合：

Bot
插件型应用
对话式分发

而 TinyEngine 更适合：

页面级 AI 生成
前端组件体系接入
低代码与工程结合
页面交付和维护

所以这几类产品的差异，不在"谁更强"，而在"谁面向哪类场景"。

七、如果我要真正做这个 demo，我会怎么落地

这里给一条更务实的实现路径。

第一步：跑起 TinyEngine

官方仓库给出了标准方式：

bash 复制代码

npx @opentiny/tiny-engine-cli@latest create-platform my-ai-platform
cd my-ai-platform
pnpm install
pnpm dev

参考：

第二步：接入 TinyVue 组件物料

让页面生成过程不再"自由发挥"，而是约束在 TinyVue 组件范围内。

这样可以统一：

组件命名
属性结构
页面风格
表单 / 表格 / 弹窗等交互模式

第三步：定义 Schema 映射规则

确保 AI 生成的页面描述能落进 TinyEngine，而不是只输出自然语言或源码字符串。

例如：

ts 复制代码

function mapSchemaToMaterial(schema: PageSchema) {
  return schema.components.map((item) => ({
    componentName: item.componentName,
    props: item.props || {},
    children: item.children || []
  }))
}

这一步是"AI 结果可维护"的关键。

第四步：加一个最小 MCP 工具层

先不要一口气接很多工具。

最小闭环就够：

查组件
查模板
查设计规则

这样既能体现 MCP 价值，又不会把文章写散。

第五步：做一轮真实调试

这一步在文章里非常重要，因为最能体现技术深度。

可以专门写一节"我遇到的 4 个问题"，例如：

AI 生成的组件粒度太粗
相同需求下页面结构不稳定
组件 props 不完全匹配
模板与业务规则之间存在冲突

然后分别说明你如何通过：

Schema 校验
组件白名单
设计规则工具
模板优先级

把结果收敛回来。

这部分最容易拉开文章质量。

八、我对"前端智能化"的一个判断

如果只保留一句话，我会这样说：

前端智能化真正的重点，不是让 AI 会写页面代码，而是让 AI 能理解组件、调用工具、生成结构，并把结果交回一个可维护的前端系统。

为什么我会把 TinyEngine 放在这条路径的中心？

因为它正好解决了一个常被忽视的问题：

AI 生成出来的内容，最后由谁承接？

如果没有承接层，AI 的结果通常停留在聊天窗口里。

而 TinyEngine 这类平台的价值，就是把这些结果变成：

可编辑页面
可复用资产
可维护配置
可交付工程

这也是我觉得 TinyEngine + MCP 这条线很值得持续关注的原因。

结语

如果今天要做一个真正有落地感的 AI 前端应用，我不会只做一个聊天框。

我更愿意做的是：

用 AI 理解需求
用 MCP 查询组件与模板
用 TinyVue 约束生成边界
用 TinyEngine 承接页面结果
最后再把页面交还给开发者继续编辑和交付

这条链路不一定最轻，但它更接近真实前端生产过程。

从这个角度看，TinyEngine 的价值不只是"低代码引擎"，而是它正在变成：

前端智能化里承接 AI 结果的一层基础设施。

参考链接

OpenTiny TinyEngine AtomGit：https://atomgit.com/opentiny/tiny-engine
OpenTiny TinyEngine GitHub：https://github.com/opentiny/tiny-engine
TinyEngine 官方介绍：https://docs.opentiny.design/tiny-engine/guide/introduction
TinyEngine AI 插件使用指南：https://docs.opentiny.design/tiny-engine/guide/new-ai-plugin-usage.html
TinyVue 官方文档：https://docs.opentiny.design/tiny-vue/guide/introduce