前端正在被 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 定义。简单来说不用 MCPAI 像是凭记忆或看路边小广告给你写代码用了 MCPAI 就像直接连上了 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 生成前端界面遇到的最大的问题。问题 4D2C 的背景与痛点背景与痛点大模型直接生成代码扁平化用 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 转换得到的代码还是比较静态的开发人员还需要在上面增加业务逻辑根据业务逻辑做对应修改面试题 2MCP 能力接入接入 Playwright MCP模拟真实点击浏览器的功能方便做 E2E端到端测试解决大模型幻觉问题保证大模型给的代码是真实的、实际场景有用的Token 控制项目采用 monorepo 架构所有项目放在一个仓库里项目架构特别大直接让 AI 读整个项目token 消耗成本太高接入 MCP 后通过函数如get component document按需获取组件文档、组件列表和组件源码先加载组件文档了解组件适用场景再进行开发实现 Skills 渐进式披露读入而非全量读取面试题 3如何量化 UI 还原度像素差异率Playwright 截图与 Figma 设计稿做像素级对比计算差异像素占比阈值卡 95% 甚至更高Semi UI 覆盖率AST 扫描统计样式值中走 token 变量和组件库的比例硬编码魔法值/非组件库 越少越好否则还得再审查非组件库 UI人工审查面试题 4页面还原指标是怎么提升的UI 直接用组件库设计设计稿和代码共用一套组件Design Token 落地间距颜色等全部 token 化Figma Dev Mode MCP 按需读组件文档AI 生成的代码用对组件、用对参数Playwright 自动校验前置 CI 卡点走查前先自动截图对比测试修复