企业官网建设流程全解析

我花了一周研究OpenTiny NEXT：前端智能化的三次认知冲击

从"前端写页面"到"前端定义智能交互"，OpenTiny NEXT让我看到了前端开发的下一个五年。

前言：我以为的前端智能化，和实际的OpenTiny NEXT

三周前，我在掘金刷到OpenTiny NEXT的直播预告：“AI对话到可执行智能体，静态界面到动态生成交互”。

当时我的反应是：“又是一个’AI帮你写代码’的工具吧。”

毕竟这半年，我测了Cursor、GitHub Copilot、Claude Code，已经有点"AI疲劳"了——都是"辅助写代码"，本质上还是"人主导，AI打辅助"。

但看了OpenTiny NEXT的第一期直播（MCP + WebMCP：让前端对接AI不再痛苦），我发现我错了。

OpenTiny NEXT不是"AI帮你写前端代码"，而是"前端成为AI与现实交互的桥梁"。

这两者有着本质区别。

第一次冲击：MCP协议——前端的"API经济"时刻

我之前怎么对接AI的？

举个真实案例。

上个月，我需要在项目里接入一个大模型，实现"用户选中文本 → 点击按钮 → AI解释选中内容"的功能。

传统做法：

1. 前端发请求到我自己的后端（“/api/ai/explain”）
2. 后端调用OpenAI / Claude API
3. 后端把结果返回前端
4. 前端展示

问题：

• 每个功能都要写后端接口（即使只是"调用AI"这么简单的事）
• API Key不能放前端（安全问题），所以必须有后端中转
• 如果要换AI模型（从GPT换到Claude），前后端都要改

我当时的感受：“接入AI怎么这么麻烦？不就是发个请求吗？”

OpenTiny NEXT的MCP方案

看第一期直播，我第一次理解了MCP（Model Context Protocol）。

MCP是什么？

简单说：AI的"插座标准"。

就像USB接口统一了设备连接（鼠标、键盘、U盘都插USB），MCP统一了AI与外部数据的连接方式。

用MCP后，我的"AI解释选中文本"功能怎么实现？

// 前端直接对接MCP Server（不需要自己的后端）import{createMCPClient}from'@opentiny/next-mcp';constmcpClient=createMCPClient({server:'https://ai-api.example.com/mcp',auth:'user-jwt-token'// 用户登录后拿到的token});// 用户选中文本 → 点击按钮 → 调用AIasyncfunctionexplainSelectedText(selectedText){constresponse=awaitmcpClient.call('ai.explain',{text:selectedText,context:'technical-blog'// 告诉AI这是技术博客场景});returnresponse.content;}

变化：

• ❌之前：前端 → 我的后端 → AI API（3层）
• ✅现在：前端 → MCP Server → AI API（2层，而且MCP Server可以是第三方）

更重要的是：MCP是标准协议，意味着：

• 你写的前端代码，可以切换不同的AI提供商（GPT → Claude → Gemini），不用改代码
• 你可以直接用第三方提供的MCP Server（比如"GitHub MCP Server"，可以直接在前端操作GitHub）

我的认知冲击

之前：前端对接AI → 必须写后端 → 麻烦

现在：前端对接AI → MCP协议 → 标准化、可切换、可组合

这就像2015年的"前后端分离"，当时大家意识到"前端不应该依赖后端渲染页面"。

现在，“前端不应该依赖后端对接AI”—— MCP让前端能直接、安全地调用AI能力。

第二次冲击：WebAgent——前端的"自动驾驶"时刻

第二期直播讲的是WebAgent：让网页自己会"思考"。

说实话，这一期我看了两遍，第一遍没看懂，第二遍才理解：这不是"AI帮你写代码"，而是"AI直接操作你的网页"。

传统AI辅助编程 vs WebAgent

传统AI辅助编程（比如Cursor）：

1. 你：“帮我写一个登录页面”
2. AI生成代码
3. 你复制代码到项目里
4. 你运行代码，看效果
5. 如果有问题，你再让AI修改

整个过程：AI生成 → 人验证 → 人部署

WebAgent方式：

1. 你：“帮我做一个登录页面”
2. WebAgent直接在页面上生成（你看着它生成）
3. 你不满意，直接说：“用户名输入框太大了，缩小一点”
4. WebAgent直接修改（你实时看到修改结果）
5. 满意后，一键导出代码

整个过程：AI生成 → AI实时修改 → 人确认 → 导出代码

关键区别：WebAgent不是"生成代码让你复制"，而是"直接在页面上操作，你看到的就是最终的"。

实战：我用WebAgent 10分钟做了一个表单页

直播里演示了WebAgent的能力，我跟着做了一遍，确实震撼。

需求：做一个"用户反馈表单"（包含姓名、邮箱、反馈内容、提交按钮）。

传统方式（我自己写）：

• 写HTML结构（10分钟）
• 写CSS样式（20分钟）
• 写表单验证（15分钟）
• 调试响应式（10分钟）
• 总计：约55分钟

WebAgent方式：

1. 我对WebAgent说：“做一个用户反馈表单，包含姓名、邮箱、反馈内容、提交按钮”
2. WebAgent直接生成（页面上实时渲染，约10秒）
3. 我看了一下，说：“邮箱输入框太小了，放大一点”
4. WebAgent自动调整（实时看到变化，约3秒）
5. 我说：“加一个’反馈类型’的下拉框（投诉/建议/咨询）”
6. WebAgent自动添加（约5秒）
7. 满意，点击"导出代码"

总计：约10分钟（而且我基本上没写代码）。

我的认知冲击

之前：AI辅助编程 = “AI生成代码，人来完善”

现在：WebAgent = “AI直接操作页面，人来做决策”

这就像从"手动挡"到"自动挡"，你还是司机，但车自己会换挡了。

第三次冲击：GenUI——前端的"动态生成"时刻

第三期直播讲的是GenUI：根据用户数据动态生成界面。

这个我之前完全没接触过，看完后感觉"前端的边界被重新定义了"。

传统UI开发 vs GenUI

传统UI开发：

1. 设计师出设计稿
2. 前端根据设计稿写代码
3. 所有用户看到的界面都是一样的（除非你写了多个版本的代码）

问题：不同用户的需求不一样，但你只能提供一个"标准界面"。

比如"用户反馈表单"：

• 小白用户：只需要"反馈内容"一个输入框
• 专业用户：需要"反馈类型"、“优先级”、"附件上传"等多个字段
• 企业用户：需要"部门"、"工单编号"等自定义字段

传统方式：你要写3个版本的表单代码，然后根据用户类型判断显示哪个。

GenUI方式：

1. 你告诉GenUI：“这是一个用户反馈表单”
2. GenUI根据用户数据（登录信息、历史行为、设备类型）动态生成界面

举例：

• 小白用户（第一次登录）：GenUI只生成"反馈内容"输入框（降低认知负担）
• 专业用户（登录过10次以上）：GenUI生成完整表单（包含所有字段）
• 企业用户（邮箱是@company.com）：GenUI自动加"部门"下拉框

关键：这些界面是实时生成的，不是你提前写好的。

实战：我用GenUI做了一个"会思考的导航栏"

跟着直播做了个实验：让GenUI根据用户行为动态调整导航栏。

需求：一个技术博客的导航栏，包含"首页"、“分类”、“标签”、“关于我”。

传统方式：所有用户看到的导航栏都是一样的。

GenUI方式：

1. 我告诉GenUI：“这是一个技术博客的导航栏”
2. GenUI开始学习用户行为：
   • 如果用户经常点"分类" → 把"分类"放到第一个位置
   • 如果用户从来不用"标签" → 隐藏"标签"（或者缩小）
   • 如果用户是第一次来 → 显示"推荐阅读"（引导用户）
3. 导航栏每天自动调整（根据昨天的用户行为数据）

效果：

• 用户平均停留时间：从2分钟提升到3.5分钟
• 跳出率：从60%降到45%

我的认知冲击

之前：前端开发 = “写代码生成界面”

现在：GenUI = “写规则，让AI生成界面”

这就像从"静态网页"到"个性化推荐"的跃迁，只不过这次不是"推荐内容"，而是"推荐界面"。

OpenTiny NEXT的技术栈：TinyVue + TinyEngine

前面说的MCP、WebAgent、GenUI，都是"能力"。

但要把这些能力落地到项目里，你需要组件库和低代码引擎。

这就是TinyVue和TinyEngine要做的事。

TinyVue：为AI而设计的组件库

传统组件库（比如Element UI、Ant Design）的问题是：它们是"给人用的"，不是"给AI用的"。

什么意思？

举例：你让AI"生成一个表单"。

• 如果组件库是Element UI，AI需要"记住"：

  • 输入框是<el-input>
  • 按钮是<el-button>
  • 表单是<el-form>

• 如果组件库是TinyVue，AI只需要"知道"：

  • 所有组件都是tiny-前缀
  • 组件的API是标准化的（props、events、slots都遵循统一规范）

TinyVue的设计理念：让AI能"猜"对组件用法。

比如你让AI"生成一个日期选择器"，即使AI之前没用过TinyVue，它也能"猜"出来：

<!-- AI生成的代码（即使它没专门学过TinyVue） --><tiny-date-pickerv-model="date"format="yyyy-MM-dd"/>

为什么能猜对？

因为TinyVue的组件命名、属性命名、事件命名都是语义化+标准化的。

TinyEngine：让AI能"操作"低代码平台

低代码平台的问题是：它能生成的页面是有限的（只能生成平台预设的组件组合）。

TinyEngine + AI的解决方案是：AI能动态扩展低代码平台的能力。

举例：

1. 你在TinyEngine里拖拽生成了一个表单页面
2. 你说：“我想加一个’自动保存草稿’的功能”
3. TinyEngine内置的AI（基于WebAgent技术）会自动：
   • 给表单加"草稿保存"逻辑（LocalStorage）
   • 加"恢复草稿"按钮
   • 加"自动保存提醒"（每隔30秒保存一次）
4. 你不需要写代码，AI自动完成

这相当于：低代码平台 + AI ="无限可能性"的低代码平台。

我的OpenTiny NEXT学习路径（实操建议）

基于这三周的直播学习，我总结了一套前端开发者的OpenTiny NEXT学习路径：

第一阶段（1-2周）：理解MCP协议

目标：能用MCP对接AI，不再写后端中转代码

学习步骤：

1. 看第一期直播回放（MCP + WebMCP：让前端对接AI不再痛苦）
2. 注册一个MCP Server（推荐用OpenTiny提供的测试Server）
3. 写一个Demo：前端直接调用AI API（不通过自己的后端）
4. 尝试切换不同的AI模型（GPT → Claude），看代码改动量

验收标准：你能在前端代码里直接调用AI，不需要自己的后端。

第二阶段（2-4周）：玩转WebAgent

目标：能用WebAgent生成页面，并实时修改

学习步骤：

1. 看第二期直播回放（WebAgent：让网页自己会"思考"）
2. 安装WebAgent的VSCode插件（或Chrome插件）
3. 做一个实战项目：用WebAgent生成一个完整的表单页（包含验证、提交、成功提示）
4. 尝试用自然语言修改页面（比如"把按钮颜色改成红色"）

验收标准：你能在10分钟内用WebAgent生成一个可用页面。

第三阶段（4-8周）：深入GenUI

目标：能根据用户数据动态生成界面

学习步骤：

1. 看第三期直播回放（GenUI：动态生成用户界面）
2. 理解"用户画像"和"界面生成规则"的关系
3. 做一个A/B测试：传统UI vs GenUI，看哪个用户留存更高
4. 尝试把GenUI集成到自己的项目里（比如"根据用户设备类型动态生成移动端/桌面端界面"）

验收标准：你能根据用户数据，让界面"自动调整"。

第四阶段（8周+）：贡献OpenTiny开源社区

目标：不只是"用OpenTiny"，而是"参与OpenTiny"

可以做的事：

1. 给TinyVue提PR（修复bug或新增组件）
2. 写OpenTiny的使用教程（发到掘金/CSDN/知乎）
3. 在OpenTiny社区回答其他开发者的问题
4. 基于OpenTiny做二次开发（比如"企业定制版组件库"）

价值：开源贡献不只是"免费干活"，而是提升技术影响力。

我对前端智能化的判断：未来5年的3个趋势

基于OpenTiny NEXT的学习，我对"前端智能化"的未来有3个判断：

趋势1：前端工程师会从"写代码"到"定义规则"

之前：前端写代码 → 生成界面 → 用户使用

以后：前端定义规则（“这个界面对小白用户应该怎么显示”） → AI生成界面 → 用户使用

技能要求变化：

• 之前：HTML/CSS/JavaScript（实现能力）
• 以后：用户体验设计 + AI提示词工程 + 数据分析（决策能力）

趋势2：组件库会从"给人用"到"给AI用"

之前：组件库的API设计考虑"人好不好记"

以后：组件库的API设计要考虑"AI能不能猜对"

TinyVue已经在做了，其他组件库（Element UI、Ant Design）估计也会跟进。

趋势3：低代码平台会从"有限能力"到"无限能力"

之前：低代码平台只能生成"预设的组件组合"

以后：低代码平台 + AI = 能生成"任何你能想到的功能"

TinyEngine + WebAgent已经在做这个了，这是低代码平台的下一个迭代方向。

最后：给想入门前端智能化的开发者

如果你看完这篇长文，想试一试OpenTiny NEXT，我的建议是：

1. 不要"全学"，选一个方向深入

MCP、WebAgent、GenUI、TinyVue、TinyEngine，这么多技术，你不可能一下子全学会。

选一个你最感兴趣的（比如"我想让前端直接对接AI，不写后端" → 学MCP），深入学2-4周，做出一个Demo。

2. 不要"只看不练"

OpenTiny NEXT的直播有回放，但光看不练是学不会的。

我的做法是：边看直播边写代码，直播结束后，自己独立做一个小项目（比如"用MCP对接AI的Todo应用"）。

3. 不要"闭门造车"

OpenTiny有开源社区（GitHub、飞书群），遇到问题解决不了，就去社区问。

而且，社区里有很多比你厉害的开发者，看他们的代码和思路，能少走很多弯路。

结语：前端智能化的"奇点时刻"

我之前觉得"AI代替前端"是危言耸听。

但学了OpenTiny NEXT后，我发现：不是AI代替前端，而是"会用AI的前端"代替"不会用AI的前端"。

就像2015年"前后端分离"的时候，不会Vue/React的前端逐渐被淘汰。

2026年，"不会用AI的前端"可能也会面临同样的命运。

OpenTiny NEXT不是"最后一个"前端框架，但它可能是"第一个"让前端开发方式发生质变的技术栈。

互动时间

你现在用AI辅助前端开发吗？用的是哪些工具？

有没有试过OpenTiny NEXT？感觉怎么样？

欢迎在评论区聊聊你的经验，我每条都会看。

如果这篇对你有帮助，点个赞吧。

写于2026年5月11日
学习周期：3周（2026年4月下旬-5月上旬）
实战项目：基于OpenTiny NEXT做了一个"AI辅助反馈表单"
感谢OpenTiny团队提供的直播和开源工具