企业官网建设流程全解析

Figma 这几年已经被很多人贴上了“UI 设计工具”的标签，但如果只把它当成画界面稿的软件，你会错过它真正值钱的部分：一条从创意到视觉、从视觉到代码的可复用生产链路。

这期 POSESHOW 第 87 期的主题是“书本是映照着文明的镜子”，对应角色是“图书委员长”。初看很像一次手办摆拍或海报创作，但如果用技术视角拆开，它其实是很好的 Figma 实战样本：一个带中文长文案、需要角色主视觉、还要把图标和标注交付给前端的项目。尤其当后端或前端同学接手这类设计稿时，真正的问题往往是：如何在 Figma 里把一张“看起来很好看的图”，变成一套“能维护、能导出、能协作、能被代码使用”的资产体系。

这篇文章不打算讲基础到新建画板的操作，而是以这个主题项目为主线，完整走一遍需求拆解、环境准备、中文排版、字体处理、图标转 JSON、MCP 接入开发流程，最后给出常见坑和工程建议。读完你会理解：为什么说 Figma 的核心能力不是“画图”，而是“把视觉表达结构化”。

1. 这篇文章真正要解决的问题

如果你只是偶尔用 Figma 做一张活动海报，你大概率会遇到下面这些麻烦：

• 海报标题是一段中文长句，“书本是映照着文明的镜子”这句话不能随便拉一下文本框就完事，字重、字距、行高、对齐方式都会影响整体气质。
• 主视觉需要一个“图书委员长”角色，素材可能是从某个素材库导入的，导入后发现图层乱成一团，后续想改袖子颜色、换书本封面，根本找不到对应图层。
• 海报里需要用到几个图标，最终前端实现时要的是 SVG、JSON 或者图标字体，而不是一张截图。但从 Figma 里导出之后，路径数据经常对不上，坐标偏移。
• 团队协作时，设计稿里用的中文字体其他人电脑没有，打开文件就变成方框。
• 如果你想用 AI 编程助手基于设计稿生成页面代码，发现助手根本读不懂设计稿里的图层结构。

从这些痛点往回看，Figma 真正解决的不是“画图”这一步，而是把设计稿变成了一种可编程的中间产物。这篇博文要解决的核心问题是：如何用 Figma 完成一个包含中文长文案、自定义角色、图标导出和开发交付的完整设计项目，并且在过程中尽量做到结构化、可复用、可排查。

适合读这篇文章的读者有三类：正在用 Figma 做视觉物料的设计师，需要从设计稿中提取图标和素材的前端同学，以及正在尝试 Figma MCP、想打通设计与 AI 编程工作流的开发者。如果你只是随便看看，不打算动手，这篇文章读起来也不会太吃力，因为核心思路都是场景化的。

2. 从“书本是映照着文明的镜子”到 Figma 设计稿

先还原这个项目的源头。主题句是“书本是映照着文明的镜子”，角色是“图书委员长”。从设计角度来看，这句话包含几个可视觉化的关键词：

• 书本：代表知识、阅读、图书馆。
• 镜子：代表反观、映射、倒影。
• 文明：代表秩序、积累、时间。
• 图书委员长：一个拟人化角色，通常是戴着委员长袖标、抱着书或正在整理书架的人物。

把这些关键词落到视觉上，常见的处理方式是：主视觉中心放一个“图书委员长”角色，背景用书墙或书架，人物面前有一面半透明镜子，镜子里映着书本的光影，标题文字放在画面上方或下方。这样既扣住主题，又有叙事感。

但设计稿不能只停留在“感觉”。在 Figma 里动手之前，应该先做一次需求拆解，把项目拆成可执行的交付物：

这张表的意义在于：打开 Figma 之前，每个需求都已经有对应的承接方式。否则你很容易在图层里东拼西凑，最后文件变成一锅粥。

一个更重要的判断是：这类主题海报项目，最好的做法不是把整个画面平铺成一张不可拆分的图，而是先定义好“文字系统、颜色系统、角色组件、图标组件”，再组装画面。这样后续无论是改文案还是换角色姿势，成本都很低。

所以，这篇文章在讲“画海报”的过程时，实际上是在讲一套可复用的 Figma 项目组织方法。掌握了这套方法，你以后做任何主题视觉，都不需要从零开始。

3. 环境准备：客户端、中文界面、字体

3.1 Figma 客户端还是 Web 端

Figma 有网页版和桌面客户端两种常见使用方式。网页版的好处是免安装、打开链接就能看文件；桌面客户端则更适合处理大文件、调用本地字体、离线缓存更稳定。如果你是做“图书委员长”这种需要大量素材导入和字体排版的完整项目，建议安装官方桌面客户端。

操作系统方面，Windows 和 macOS 都可以。如果你同时在浏览器里使用 Figma，注意浏览器翻译插件不要误翻译设计稿内容，有时候插件会强制改写界面语言，导致操作入口位置变化，看起来像出了 bug。

3.2 关于“Figma 汉化”和中文支持

很多国内用户搜索“figma 汉化”“figma 中文版”“figma 中文语言包”，是因为 Figma 官方界面默认主要是英文。这里要特别提醒一句：不建议下载来路不明的第三方修改版或汉化补丁，因为这类版本可能篡改安装包或读取本地文件，存在账号安全风险。

更稳妥的做法是：

• 直接使用官方 Figma 客户端，界面保持英文，但编辑区内容可以是任意语言，中文文案不受影响。
• 如果英文界面实在影响操作，可以使用浏览器自带的逐字翻译功能，只在阅读界面时临时开启，不修改本地文件。
• 团队内部可以建立一份常用操作中英文对照表，降低沟通成本。

从使用体验看，Figma 的中文编辑能力本身没有问题，真正容易出问题的是字体。如果你在文件里用了电脑没有安装的中文字体，打开文件会显示乱码或自动替换字体。

3.3 字体安装与刷新

“书本是映照着文明的镜子”这类中文长文案，对字体要求很高。推荐的做法是：使用思源宋体、思源黑体、阿里巴巴普惠体、HarmonyOS Sans 这类开源或者可免费商用的字体，并且让团队成员统一安装同一版本。

安装字体后，Figma 客户端通常能自动检测到系统字体。如果列表里没出现，可以重启客户端，或者在 Figma 的字体下拉菜单里刷新。网页版则依赖本地系统字体，机制类似。

这里很容易踩的一个坑是：设计稿里用了特殊字体，但导出 PNG 或交付给前端后，对方打开连接看到的是“字体缺失”的提示。解决方案是：在设计稿中用组件封装文字样式，同时在交付文件里附上字体来源；如果涉及前端实现，优先把标题导出为图片，正文用 Web Font。

3.4 工作区与文件组织

针对这个主题项目，建议在 Figma 里把文件分为三个页面：

• Cover：封面画板，用于预览。
• Design：正式设计稿，海报、Banner、图标放在这里。
• Dev：交付页，包含导出切图标注、JSON 示例、字体色彩说明。

页面用英文或拼音命名都可以，团队统一就好。重点是让协作的人一眼就知道什么东西去哪找。

4. 项目初始化与核心画板搭建

打开 Figma 后，先新建一个项目文件，然后立即做四件事：设置页面、创建 Frame、定义网格、建立设计规范。

以“图书委员长”主题海报为例，Frame 尺寸可以设为纵向海报比例，比如 1200×1600，或者适合 Web 投放的 1440×900。更推荐的做法是：先建一个 1440×900 的 banner，再建一个 1200×1600 的竖版海报，副本可以覆盖不同投放场景。

Frame 建议这样处理：

• 把 Frame 命名为poster-1200x1600或banner-1440x900。
• 在 Layout Grid 中开启网格，比如 12 列网格，列间距 16px。
• 在画板外留一块区域放置参考图、素材图和注释。

网格的价值不是让你死板地套栅格，而是让文字和角色位置在视觉上有一个参照系。尤其是主题标题放在画面中央时，有网格辅助会更容易做出稳定的构图。

接下来建立基础样式：

• 颜色：从主题里提取主色，比如深棕（书柜）、米白（纸张）、金色（文字点缀）。
• 文本样式：定义title-64、subtitle-32、body-24等等。
• 效果：给“镜子”元素定义统一的玻璃拟态效果，供重复使用。

这一步做完后，你的文件已经有了一套“设计规则”，后续所有内容都是在这个规则上生长出来的。这比一边画一边临时选颜色、临时改字号要高效得多。

5. 主题海报实战：完整设计流程

5.1 主视觉角色：“图书委员长”组件化

“图书委员长”是这期海报的核心角色。如果你手里已经有插画素材，可以直接把插画导入，但要注意命名和分层。比较推荐的做法是：把角色拆成“身体、头部、袖标、书本、饰物”几个部分，每一部分单独命名，然后把它们组装成一个组件。

组件化的好处是，你可以通过修改组件的属性来切换角色的不同状态，例如：

• 是否戴眼镜。
• 手里拿的是打开的书还是合上的书。
• 袖标文字是“图书委员长”还是其他。

在 Figma 里实现方式是在组件上添加 Variant，每个 Variant 对应一种状态。这样你在多张海报里复用同一个角色时，只需要切换属性，不需要复制粘贴再手动修改图层。

5.2 标题排版：中文长文案的节奏

标题“书本是映照着文明的镜子”共 11 个字，属于典型的“主题标语”式标题。排版时可以从三个角度入手：

• 字重对比：标题主句用粗体，副标题或来源用常规体。
• 字距控制：中文标题可以适当增加字距，让文字更透气。
• 行长控制：如果竖排，每列字数保持稳定；如果横排，尽量在 8 到 12 个字的范围内。

标题在 Figma 里建议使用 Auto Layout 包裹，这样增加或删减后文时，文本框会自动调整。你还可以把标题文字所在的容器命名为title-block，便于导出给前端时对应。

实际操作时，可以直接用“文本样式”统一管理。比如：

title-64-extra-bold：用于主标题，字重 800，行高 88。 subtitle-32-regular：用于副标题说明，字重 400，字距 4。

这样一来，后续前端同学可以从设计稿的标注面板里直接看到字号、字重、行高和字距，不用反复询问。

5.3 素材与背景：书架、光影、镜子

背景氛围建议用真实摄影图或高质量插画。Figma 社区有一些免费的图书馆、书墙素材，也可以用官方插件从图片库导入。导入后，把图片放到角色底层，再叠加一层半透明的矩形作为“镜子”区域。

镜子的视觉逻辑是：它应该能反射书本的影像。一种简单的做法是复制一组书本图形，整体旋转或翻转，降低透明度，放到镜子区域，形成倒影感。

这里有三个很实用的技巧：

• 使用混合模式中的 Screen 或 Overlay，让倒影更自然。
• 给镜子区域添加模糊效果，比如 Background Blur。
• 在镜子边缘加一条细线框，暗示玻璃边界。

背景和角色都到位后，整个画面就有了层次。此时先不要急着导出，应该先检查图层结构是否符合预期：背景在底层，角色在中层，标题和文字在最上层。

5.4 组件复用与资源整理

做完整海报后，把里面用到的图标、作品信息卡片、按钮等，都整理成组件，放进“资源库”页面。后续做同一主题的延伸物料，比如手机壁纸、公众号头图、官网 banner，都可以直接拖拽复用。

整理原则是：

• 图标统一命名：ic-book、ic-star、ic-arrow 等。
• 配色统一走颜色变量，不要直接填充色值。
• 字体统一走文本样式，不要临时改字体。

这样，整个“图书委员长”主题项目就不只是一张海报，而是一套小型设计系统。这是 Figma 比传统画图工具强的地方。

6. 让图标可交付：SVG 转 JSON 的三种方式

“figma 如何将图标转换成 json”是很多前端同学会搜的问题。为什么需要 JSON？因为在 Web 或小程序开发中，图标往往需要以 SVG path 数据形式嵌入代码，或者以 JSON 配置的方式前端动态加载。如果手动去图标网站下载 SVG 再转 JSON，效率很低，而且容易版本错乱。

下面提供三种方案，覆盖不同场景。

6.1 方案一：手动导出 SVG，再用脚本转 JSON

这是最直观的方式：在 Figma 里选中图标图层，右键选择 Export，格式选 SVG，得到文件后，用脚本把 SVG 文件内容转成 JSON。

转换脚本可以用 Python 写，核心思路是遍历指定目录下的 SVG 文件，读取文件内容后存入 JSON。示例代码如下：

# 文件路径：scripts/svg_to_json.py import json import os import re def svg_to_json(svg_dir="./icons", output_path="./icons.json"): icons = {} for filename in os.listdir(svg_dir): if not filename.endswith(".svg"): continue name = os.path.splitext(filename)[0] file_path = os.path.join(svg_dir, filename) with open(file_path, "r", encoding="utf-8") as f: svg_data = f.read() # 提取 viewBox 和内部 path 数据 view_box_match = re.search(r'viewBox="([^"]+)"', svg_data) paths = re.findall(r'<path[^>]*d="([^"]+)"', svg_data) icons[name] = { "viewBox": view_box_match.group(1) if view_box_match else "0 0 24 24", "paths": paths } with open(output_path, "w", encoding="utf-8") as f: json.dump(icons, f, ensure_ascii=False, indent=2) print(f"已生成 {output_path}，共 {len(icons)} 个图标") if __name__ == "__main__": svg_to_json()

这段代码的原理是：用正则表达式从 SVG 中提取 viewBox 和<path>的 d 属性。一个图标通常由一到多个 path 组成，把它们放进 JSON 以后，前端可以按需渲染。

运行方式：

python scripts/svg_to_json.py

需要说明的是，这个脚本适合比较规范的 SVG 文件。如果图标包含渐变、复杂滤镜，正则提取可能丢失样式，建议导出时尽量使用纯 path 图标。

6.2 方案二：通过 Figma REST API 拉取 SVG 并生成 JSON

当图标数量很多，或者你希望在 CI 流程里自动同步图标时，手动导出就不太现实了。这时可以使用 Figma REST API。

整体流程是：

1. 在 Figma 中获取文件 File Key。
2. 拿到图层节点 ID。
3. 调用GET /v1/images/:key接口，指定 format=svg。
4. 根据返回的图片 URL 下载 SVG。
5. 再把 SVG 转成 JSON。

以下是 Node.js 示例：

// 文件路径：scripts/figma-svg-to-json.js const fs = require("fs"); const path = require("path"); // 这里用占位符代表实际请求逻辑，完整实现建议参考官方 REST API 文档 async function fetchSvgFromFigma(fileKey, nodeId, outputPath) { const apiKey = process.env.FIGMA_API_KEY; const headers = { "X-Figma-Token": apiKey }; // 1. 请求 SVG 导出链接 const imageResp = await fetch( `https://api.figma.com/v1/images/${fileKey}?ids=${encodeURIComponent(nodeId)}&format=svg`, { headers } ); const imageData = await imageResp.json(); // 2. 从返回的 images 中取出 svg 地址 const svgUrl = imageData.images[nodeId]; if (!svgUrl) { console.error("未取到 SVG 地址，请检查 nodeId 和 API 权限"); return; } // 3. 下载 SVG 内容 const svgResp = await fetch(svgUrl); const svgText = await svgResp.text(); // 4. 写入本地文件或直接转成 JSON fs.writeFileSync(path.join(outputPath, `icon-${nodeId}.svg`), svgText, "utf-8"); console.log(`已保存 icon-${nodeId}.svg`); } // 使用示例（需要先设置环境变量 FIGMA_API_KEY） fetchSvgFromFigma("YOUR_FILE_KEY", "1234:5678", "./downloads");

使用前需要先创建 Figma 开发者应用，获取访问令牌。这里要特别注意安全边界：

• API Token 只存环境变量，不要提交到代码仓库。
• Token 权限按最小化原则，只读文件即可。
• 建议使用专门的只读 Token，不要用个人账号主 Token。

这个方案最接近“自动化”的目标。把脚本挂到 CI 上，每次设计稿发布后自动拉取最新图标，前端组件库就能自动更新。

6.3 方案三：开发一个 Figma 插件，直接导出 JSON

前面两种方案都依赖外部脚本，对设计师来说并不直观。更优雅的方式是在 Figma 内直接安装或开发一个插件，选中图标后一键导出 JSON。

如果你需要自己开发插件，核心文件有两个。

第一个是清单文件：

{ "name": "图标导出 JSON", "id": "icon-json-exporter", "api": "1.0.0", "main": "code.js", "editorType": ["figma"] }

第二个是插件主逻辑：

// 文件路径：code.js figma.showUI(__html__, { width: 320, height: 240 }); figma.ui.onmessage = async (msg) => { if (msg.type === "export-json") { const nodes = figma.currentPage.selection; if (nodes.length === 0) { figma.notify("请先选中至少一个图层"); return; } const result = {}; for (const node of nodes) { if ("exportAsync" in node) { const svg = await node.exportAsync({ format: "SVG" }); // 将 ArrayBuffer 转成字符串 const svgText = String.fromCharCode(...new Uint8Array(svg)); // 这里可以再做 path 提取，或者直接保存原始 SVG result[node.name] = svgText; } } // 将 JSON 发送给 UI 面板，方便复制 figma.ui.postMessage({ type: "json-result", data: JSON.stringify(result, null, 2) }); } };

插件的好处是设计师不需要理解 API，也不需要跑命令行，选中图层点一下就能拿到 JSON。但开发插件本身有一定门槛，适合团队里有前端背景的同学来做。

这一步做完，“图标转 JSON”就不再是某个不可解释的黑魔法，而是一条可重复执行的流程。你可以根据团队情况选择手动脚本、REST API 或插件方案。

7. 用 MCP 和 API 把设计稿接入开发流程

近两年“Figma MCP”热度涨得很快。MCP 的全称是 Model Context Protocol，可以简单理解成一套让 AI 编程助手读取外部工具数据的标准协议。接入 Figma MCP 之后，AI 助手可以直接读取设计稿里的图层名、样式值、间距标注，甚至根据设计稿生成页面代码。

这就解决了一个老问题：以前前端写页面时，要反复看设计稿、切图、量间距，现在 AI 工具能直接拿到结构化信息，减少了“看图猜数值”的过程。

但这里需要有一个清醒的判断：Figma MCP 并不会自动把设计稿变成完美代码。它的作用是缩小“设计意图”和“代码实现”之间的信息差，最终代码质量仍然取决于设计稿的规范程度和开发者的 review 能力。如果你的图层命名乱七八糟，颜色都是直接色值，没有样式变量，AI 读出来的东西也会很乱。

7.1 配置思路

Figma 官方的 Dev Mode MCP Server 是在开发者工具生态里出现的。通常配置方式是在支持 MCP 的客户端中，新增一个 “mcpServers” 配置。

通用配置结构如下：

{ "mcpServers": { "figma-dev-mode": { "command": "npx", "args": ["-y", "figma-developer-mode-mcp", "--stdio"], "env": { "FIGMA_API_KEY": "你的只读Token" } } } }

注意：具体包名和启动参数要以官方文档为准，不同版本可能调整。配置完成后，AI 助手会在对话中多出“读取 Figma 文件”相关工具能力，你可以直接提供文件链接或文件 key 让它读取。

7.2 接入前要注意什么

• Token 安全：不要把 Token 暴露在共享配置里，尽量使用环境变量。
• 权限范围：建议创建最小权限 Token，只给需要的文件或团队。
• 敏感设计稿：如果设计稿涉及未公开产品功能，不要传到第三方 AI 服务。
• 额度与频率：MCP 调用会受到平台限制，频繁请求可能失败。具体额度以 Figma 官方文档说明为准。
• 人工确认：AI 生成的代码只是草稿，生产环境必须经过代码评审和视觉比对。

对于个人开发者，MCP 的价值在于快速“读懂”设计稿；对于团队，MCP 的价值更大：它相当于把设计稿变成了 AI 可读的接口文档。你可以在日常工作中先拿一个小型页面做试点，验证流程后再铺开。

8. 导出交付与效果验证

项目做完之后，导出交付这一步直接决定设计稿能否被下游使用。

8.1 针对不同物的导出方式

• 海报成品图：导出 PNG，尺寸按 Frame 实际大小，建议 2x 导出以保证清晰度。
• 图标资源：导出 SVG，或通过脚本生成 JSON。
• 设计标注：直接把 Figma 链接分享给开发，开发在 Dev Mode 下查看标注。
• 字体与色彩说明：单独生成一份设计规范说明，或者在交付页中做好标注。

这里有一个容易被忽略的环节：发布前要逐项检查导出文件。打开导出的 PNG 看文字是否模糊、边缘是否有残缺；打开 JSON 看 viewBox 和 path 是否完整；把 SVG 拖进浏览器看渲染效果是否和 Figma 一致。

8.2 验证清单

如果你是用脚本导出图标 JSON，建议再写一个最小验证脚本：

node -e "const icons=require('./icons.json'); console.log(Object.keys(icons));"

这个命令会列出 JSON 里所有图标名称，如果数量对得上，说明导出过程基本正常。如果某些图标缺失，回到 SVG 文件确认导出时是否选中了图层。

9. 常见问题与排查思路

以下是实战中比较常见的几类问题，整理成表，方便遇到时快速排查。

排查的原则是：先看错误日志，再定位环节，最后修配置。不要一上来就重装客户端，很多问题只是 Token 或字体这种细节引起的。

10. 最佳实践与工程建议

把这类主题型设计项目长期做好，需要建立一些工程习惯。以下几条是这个项目最值得沉淀的经验。

10.1 图层命名就是接口设计

图层命名可能看起来只是小事，但在 MCP 和 AI 辅助开发时代，命名直接决定下游工具能不能读懂。推荐命名规则：

• 页面层：page-home、page-poster。
• 组件层：comp-book-cover、comp-role-figure。
• 图标层：ic-book-open、ic-star-line。
• 文本层：text-title、text-subtitle。

命名统一之后，AI 工具从设计稿读取信息时给出的代码质量会明显提升。

10.2 用变量和样式代替临时取色

主题项目中有大量重复颜色，比如木质色调、纸张色调、文字金色。建议全部用 Color Variables 定义，而不是每个图层直接填色值。后续如果想整体调整色调，只需要改变量，不需要逐层替换。

同理，文本样式也统一管理。用 Auto Layout 排布文字块，避免“手动拖拽文本框导致字体位置对不齐”的情况。

10.3 自动化脚本进入版本库

图标转换脚本、SVG 下载脚本、JSON 校验脚本，都应该放进 Git 仓库，并配好 README。团队里其他人可以通过脚本重复执行，而不是依赖某个同学的电脑环境。

10.4 安全边界

• API Token 只存环境变量或密钥管理服务。
• 生产环境执行的脚本，必须经过 review。
• 不要在不信任的 AI 工具中上传未公开的设计稿。
• 团队共享 Figma 链接时，注意文件权限是“查看”还是“可编辑”。

10.5 版本管理与协作

Figma 自带版本历史，但建议团队仍然约定：每个正式交付版本都在封面页标注日期和版本号。设计评审时用 Figma 的评论功能直接标注问题，避免在聊天里口述“右上角那个颜色改一下”这种模糊反馈。

11. 总结与后续学习方向

“书本是映照着文明的镜子”这期 POSESHOW 主题项目，表面上是做一张海报，其实完整走通了 Figma 在视觉项目中的全链路：需求拆解、设计系统搭建、中文排版、组件化角色、图标导出、API/MCP 接入开发流程、导出验证和团队协作。

如果只记住一句话，那就是：Figma 的竞争力从来不是“画图”，而是把视觉表达变成结构化数据。图层命名、样式变量、组件复用、脚本导出、MCP 读取，这些能力叠加起来，才让设计稿真正成为设计与代码之间的可编程中间层。

下一步你可以从三个方向继续深入：

• 把自己最近的一张活动海报，按本文提到的组件化和样式变量方式重构一遍，体验组织方式带来的差异。
• 把前端项目中最常用的 20 个图标整理成 Figma 组件，写好导出脚本，尝试在 CI 中自动更新。
• 申请一个只读 API Token，接入 MCP 客户端，用一段真实组件代码验证 AI 生成结果，再评估是否值得在团队中推广。

这类实践不需要一次做完，每次做一小块，积累下来就会形成属于你自己的 Figma 工作流。到时候你会回头发现：一张“好看”的海报只是表面，真正有价值的是它背后那条高效、规范、可复用的生产链路。