纲要
- Figma原型导出
- 页面选择与导出格式
- 导出选项对比：
Google AI Studio、Figma、即时原型、MCP与Skills的区别 ZIP压缩包导出
- 项目目录结构规划
- UI原型图文件夹（仅供查阅）
- 前端代码开发文件夹
- 目录树示例
- 导出产物分析
- HTML与图片资源
- Markdown设计文档
- CSS样式兼容性问题
- 后续优化方向
- 代码聚合与重构
Claude Code的应用场景
Figma原型导出
在完成Figma原型设计并确认界面布局与交互流程无误后，下一步是将设计稿导出为开发可用的格式。Figma提供了多种导出选项，需根据实际使用场景进行选择。
页面选择与导出操作
在Figma中，用户可通过右上角的导出按钮进入导出面板。支持单页面导出或多页面批量导出。若项目中包含多个页面（如登录页、仪表盘、设置页等），可按住Ctrl/Cmd键进行多选，一次性完成导出。
导出选项对比
Figma的导出面板提供了多个目标平台选项，各自适用场景不同：
| 导出目标 | 输出格式 | 适用场景 | 备注 |
|---|---|---|---|
Google AI Studio | 代码/设计稿 | AI辅助开发 | 需要开发者权限及代理环境 |
Figma（复制代码） | HTML/CSS/图片 | 直接粘贴至Figma | 以图片形式导入，非真实DOM结构 |
即时原型 | 原型稿 | 国内协作平台 | 与即时设计生态联动 |
MCP | 第三方服务接口 | 外部工具集成 | 由第三方提供在线服务或API |
ZIP | 压缩包 | 本地开发 | 包含HTML、CSS、图片及MD文档 |
MCP与Skills的架构区分
在AI辅助开发工具链中，MCP（Model Context Protocol）与Skills是两种不同层级的能力扩展方式：
Skills：指本地生成或掌握的技能，以“人”为单位。例如，开发者掌握Python编程或熟悉某一框架，即属于自身具备的技能。MCP：指第三方提供的外部能力，通常以在线服务、API接口或工具的形式存在。开发者无法直接学习或内置这些能力，只能通过调用方式使用。
用一个类比来区分：某家包子铺不会教授制作包子的技能（Skills），顾客只能通过购买（调用MCP）来获得成品。因此，凡是由第三方提供的功能，均可归类为MCP服务。
在绝大多数开发场景中，使用ZIP导出即可满足本地代码编辑与调试的需求。若项目需要集成外部API或第三方工具，可进一步评估MCP的接入方案。
导出步骤
- 在Figma中选中所需页面（支持多选）。
- 点击右上角“导出”按钮。
- 在导出面板中选择
ZIP格式。 - 点击导出，下载压缩包至本地。
项目目录结构规划
为了便于管理和后续开发，建议在项目根目录下按职责划分不同的文件夹。以下是一个推荐的目录结构示例：
project-root/ ├── 001-原型设计/ # 原始设计稿备份 │ └── design.figma ├── 002-UI原型/ # 从Figma导出的UI原型（仅查阅，不修改） │ ├── dashboard.html │ ├── login.html │ ├── settings.html │ ├── register.html │ ├── assets/ │ │ └── images/ │ └── design.md ├── 003-前端代码/ # 实际开发工作目录 │ └── frontend/ │ ├── index.html │ ├── css/ │ ├── js/ │ └── assets/ └── temp-可删除/ # 临时文件，可忽略 └── ...各目录职责说明
002-UI原型：存放Figma导出的静态原型文件，包括HTML、图片资源及设计说明文档（design.md）。该目录仅供产品经理、设计师或外部人员查阅，不建议在此目录中直接修改代码，以保持原型的完整性。003-前端代码：实际开发目录，将原型代码复制至此，并在此进行功能开发、样式调整和逻辑编写。该目录由前端工程师维护，所有改动均应在此目录中完成。temp-可删除：临时或废弃文件的存放位置，可随时清理。
通过这种目录分层，可以实现设计稿与开发代码的解耦，降低误操作风险，同时便于多人协作。
导出产物分析
解压从Figma导出的ZIP文件后，通常包含以下内容：
- HTML文件：每个Figma页面对应一个独立的HTML文件。
- 图片资源：位于
assets/或images/目录下，供HTML引用。 - Markdown设计文档：包含页面的设计说明、标注信息及版本记录。
常见问题：CSS样式兼容性
在实际导出过程中，可能会出现部分页面的CSS样式显示异常，例如：
- 布局错位
- 字体或颜色与设计稿不一致
- 响应式适配问题
这些问题通常源于Figma导出引擎生成的CSS代码与浏览器标准渲染之间存在细微差异。建议对导出的HTML文件进行以下检查与修正：
- 确认
DOCTYPE声明及字符编码设置正确。 - 检查外部样式表或内联样式是否完整加载。
- 使用浏览器开发者工具（
F12）排查具体元素的样式覆盖或缺失情况。
若样式问题较多，可考虑仅将导出的HTML作为结构参考，重新编写或使用CSS框架（如Tailwind CSS）进行样式重构。
后续优化方向
当前从Figma导出的代码较为分散，每个页面独立存在，缺乏统一的入口文件、路由管理及全局样式控制。在进入正式开发阶段前，建议通过以下步骤进行优化：
- 代码聚合：将多个HTML页面中的公共部分（如头部导航、底部Footer）提取为可复用的组件或模板。
- 样式整合：统一全局样式表，消除重复或冗余的CSS规则。
- 资源优化：压缩图片、合并静态资源请求，提升加载性能。
- 引入构建工具：根据项目规模，考虑使用
Vite、Webpack等工具进行模块化管理和热更新。
在下一阶段的开发中，将引入Claude Code等AI辅助编码工具，对导出的前端代码进行智能化重构，包括代码聚合、逻辑梳理以及可维护性提升。
总结
本次实践涵盖了从Figma原型导出到项目目录规划、导出产物分析及优化方向的完整流程。核心技术要点如下：
- Figma导出：支持多页面批量导出为
ZIP格式，输出HTML、图片及设计文档；MCP与Skills的架构区分关键在于能力来源——本地技能 vs 第三方服务。 - 目录结构设计：按职责分层，将UI原型与前端代码分离，便于设计评审与开发维护。
- 导出产物处理：导出的HTML可能存在CSS样式兼容性问题，需手动检查与修复；Markdown设计文档可作为开发参考。
- 优化方向：通过代码聚合、样式整合、资源优化及AI辅助工具（如
Claude Code）提升代码质量和开发效率。
