当前位置：首页 > news >正文

通过Semi Design思考前端组件AI化

news 2026/7/9 2:01:46

前端正在被 AI 一步步干死，今天我不讲就业环境，我们通过 Semi Design 这个组件库来讲讲，前端组件是如何从 Ant Design X 这样的纯 AI 应用组件库，发展到 Semi Design 这样的组件库“AI 化”。

问题 1：如果不使用 MCP，大模型就不会自己查阅文档和调用 API 吗？

Semi design 官方内置了自己的 MCP，但是你有没有想过，如果我们不使用它的 MCP，让大模型自己去查阅文档和调阅组件的 API 会发生什么？如果使用了 MCP，这些问题就一定可以解决吗？先说一下，如果让大模型自己查阅文档和调用 API 存在三大硬伤：过时、幻觉、以及链路割裂。

如果没有 MCP（模型上下文协议）服务，大模型在帮你写代码时，通常只能依赖传统手段：

依赖内置的预训练数据（知识库）：比如模型的知识只截止到某一年。如果 Semi Design 在最近几个月更新了v2.x某个组件的 API，或者废弃了某个属性，大模型完全不知道，写出来的代码直接报错。
依赖传统的 RAG（联网搜索）：你给它一个网址，或者它自己去搜索。但传统搜索返回的是网页 HTML 文本，大模型需要自己去网页里“捞”关键信息。往往因为单次对话的 Context（上下文）太长、网页噪音太大（比如广告、导航栏），导致它漏掉关键参数。

以上的问题都是开发中真实存在的。我想如果真正做过 Vibe Coding 的同学，当你不使用任何 skill 或者 MCP，即使你告诉了大模型你使用的组件库，实现的效果依旧是非常糟糕甚至错误的。那么MCP 服务的本质改变了什么？

MCP 相当于给大模型提供了一个**标准化的“数据库/工具接口”**。

它不再是去“读网页”，而是通过semi-mcp直接调取结构化、最新、最精准的本地/官方 API Schema（数据结构描述）。
当你在 Cursor 或 Claude 里写代码时，AI 在后台会主动发起一个结构化请求：“给我看下最新版 Semi UI 的Table组件有哪些 props”。MCP 服务器会瞬间返回一个干净利落的 JSON 定义。

简单来说：不用 MCP，AI 像是凭记忆或看路边小广告给你写代码；用了 MCP，AI 就像直接连上了 Semi 官方团队的数据库，查阅的是 100% 精准的内部技术白皮书。因为这些 MCP 是由官方设定的，它直接指向的是最精准的官方文档，而不是普通地从一个网页进行数据的爬取或者筛选。

问题 2：官方的 Skill 相比没有时提升了什么？内部是怎么设计的？

提升了什么？

普通的 LLM 只懂通用的 React 语法。当你问：“帮我写一个复杂的带联动、带校验、还能动态增减行的表单”，普通 LLM 可能会用原生的 ReactuseState纯手写，或者用一些别扭的逻辑去拼凑 Semi 组件。

而有了Semi Skills的 Agent：

框架最佳实践：它天然知道 Semi 的 Form 有专门的Form.List针对动态增减，知道如何用useFormApi做优雅的跨组件表单联动，写出的代码是“Semi 官方推荐的最优雅解法”。
设计 Token 对齐：该组件非常注重 Design Tokens（控制颜色、间距等微调变量）。Semi Skills 会主动推荐你用全局 Token（如--semi-color-primary）而不是硬编码一个#33af84。

内部是怎么设计的？

一个成熟的组件库 AI Skill，内部设计一般包含三层架构：

System Prompt（系统提示词约束）：里面写死了严格的代码规范。例如：“你是一个字节跳动资深前端，你必须优先使用 Semi 内置组件。绝对禁止手写原生 CSS 布局，必须使用 Semi 的Space、Grid组件。”
Vector DB + Hybrid Search（混合向量检索）：里面塞满了大量的官方经典复杂案例（比如“B 端后台大盘”等标准模板库）。当你描述一个业务场景时，它能通过语义相似度瞬间匹配到最接近的官方 Demo，以此作为 Few-Shot（少样本提示）来生成代码。
Tool Call / Code Interpreter（工具回调）：内置了专门清洗代码、格式化 TS 类型、检查语法错误的逻辑工具，确保吐出来的代码能直接跑通。

而这些看似很复杂的架构设计，官方已经为我们准备好了。我们只需要把对应的 skill 引入到我们的项目中即可，这样可以极大地提高大模型的识别和使用效率。

问题 3：如果设计师不完全用官方 UI Kit，或者部分没遵循，D2C 还能用吗？

结论：可以使用，但生成的代码质量会根据“偏离程度”发生断崖式降级。

不知道大家有没有在自己的公司开发过相关的 D2C 项目。

其实，如果做过这个工具的同学就会知道，如果我们依据一套非常精准的，或者依据公司内部设计稿的设计范式来进行 Figma 的设计，理论上完全可以 1:1 地将设计稿生成代码。

而之所以绝大部分的 Figma MCP 或者 Skill 不能够把设计稿 1:1 复刻到代码上，主要就是因为在设计阶段没有一个固定的、规范化的模板，导致设计不规范，最终的结果就是代码生成得也不规范。

目前 Semi D2C（主要是通过 Figma 插件实现）的底层识别逻辑通常分为两部分：

而 semi design 这里不仅仅规定了内部的一套规则，还给我们提供了很多扩展的插槽，便于我们在官方 UI Kit 基础上做了微调、补充（换皮肤/改间距）。如果设计师只是改了品牌色、圆角大小、加了几个全局自定义组件，这些在 Figma 里其实被标记为 Design Tokens（设计令牌）或组件变体（Variants）。D2C 插件能自动识别出这些 Token 的变化，并在转出 React 代码时，自动套用我们团队的自定义主题。

如果我们不使用它内置的一些 UI key 套件的话，D2C 无法将其映射为具体的 React 组件，它只能通过视觉重构算法，强行用原生的<div>、<span>结合一堆绝对定位、Tailwind CSS 或 Flex 布局把这个样式硬塞出来。

这部分生成的代码会有很多“面条代码（乱糟糟的 div 嵌套）”，可维护性极差。前端开发拿到手之后，往往需要手动把这些乱七八糟的 div 删掉，自己用代码去重构。这个过程其实就是我们最开始接手去让 AI 生成前端界面遇到的最大的问题。

问题 4：D2C 的背景与痛点

背景与痛点：

大模型直接生成代码扁平化：用 Cursor 开发时，把需求喂给大模型生成前端代码，但生成的代码比较扁平化，组件封装能力不够好，拆分不够合理
可复用组件未被检索到：项目有可复用组件，但模型没有检索到，比如组件经历了两个版本：
- 第一版：CSR 架构下的组件
- 第二版：SSR 架构下的组件
- 因历史原因旧组件不能下线，AI 有时会找旧版本组件而非最新版本
Token 消耗大：让大模型读整个项目架构，token 消耗严重
Figma 转 Code 效果差：后端同事通过设计稿链接或者截图 Figma 参数喂给大模型生成前端界面，效果不好，产品走查时一直有问题
UI 同学对产品样式走查要求非常高

所以我们选择 Semi UI 。

面试题 1：组件实现方案

组件发布流程：
- UI 同学在 Figma 上画界面，把组件画好后发布成 NPM 包，发到团队的 library 中
- 前端同学拉取对应代码，更新组件库
- 利用 Figma 的 Dev Mode 模式进行 D2C 转换
前端架子搭建：
- 提前搭建架子，划分对应区域（如 sidebar 侧边栏区域、header、main 主区域等）
- 主区域下也会进一步划分，确保组件能放到界面正确的位置
不是组件直接上到界面上，而是有区域划分的架子
Design Token 设计：
- 由部门 Leader 提前完成设计
- 用于实现 D2C 转换中的设计规范量化（内部定制化方案）
代码后处理：
- Figma Dev Mode 转换得到的代码还是比较静态的
- 开发人员还需要在上面增加业务逻辑，根据业务逻辑做对应修改

面试题 2：MCP 能力接入

接入 Playwright MCP：
- 模拟真实点击浏览器的功能
- 方便做 E2E（端到端）测试
解决大模型幻觉问题：
- 保证大模型给的代码是真实的、实际场景有用的
Token 控制：
- 项目采用 monorepo 架构，所有项目放在一个仓库里，项目架构特别大
- 直接让 AI 读整个项目，token 消耗成本太高
- 接入 MCP 后，通过函数（如get component document）按需获取组件文档、组件列表和组件源码
- 先加载组件文档，了解组件适用场景，再进行开发
- 实现 Skills 渐进式披露读入，而非全量读取