企业官网建设流程全解析

1. 切图这件事，远不止“截图+裁剪”那么简单

切图，听起来像 Photoshop 里按 Ctrl+T 拉个选区、Ctrl+Shift+Alt+S 导出 PNG 就完事了？我干这行十多年，从最早用 Fireworks 切 Flash 网站，到后来带团队做 iOS App 图标规范，再到如今每天和 Figma、蓝湖、PxCook 打交道，越来越清楚一件事：切图不是技术动作，而是设计语言与开发逻辑之间的翻译过程。你手里的“切图软件”，本质上是前端工程师的输入接口、UI 设计师的交付出口、产品经理验收视觉还原度的标尺。它决定着一个按钮在 iPhone 上是否像素对齐、SVG 图标在不同 DPR 屏幕下是否模糊、图标资源包里有没有漏掉 @3x 版本、开发同学拿到的标注里 margin 是写成 8px 还是 0.5rem。

为什么现在大家突然集中讨论“常用的切图类软件”？因为过去三年，设计协作链路彻底变了。十年前，设计师把 PSD 文件发给开发，开发自己扒图、量尺寸、猜字号；现在，一个蓝湖链接甩过去，开发直接复制 CSS、下载资源、查看交互说明——中间那个“扒图”的人，被工具自动替代了。但问题也来了：PxCook 打开 PSD 后发现文字图层全是智能对象，导不出矢量文本；Photoshop 2026 新增的 AI 生成图层，在旧版蓝湖插件里直接显示为黑块；蓝湖 MCP 生成的 HTML 预览页里，阴影参数和设计稿对不上……这些不是软件 bug，而是切图工具背后隐含的坐标系逻辑、DPR 适配规则、资源命名规范、状态组件映射关系在打架。

所以这篇内容不罗列“十大切图软件排行榜”，也不教你怎么破解 Photoshop。我要带你拆解的是：当你说“我要切图”时，你真正需要解决的五个底层问题——
第一，如何让一张设计稿里的 200 个图标，自动按平台（iOS/Android/Web）生成对应尺寸、格式、命名的资源包；
第二，怎么确保开发看到的“按钮内边距 12px”，和你在 Sketch 里标注的数值完全一致，而不是靠人眼比对；
第三，当设计师用 Figma 做了悬停态动效，开发怎么知道 hover 状态下图标要替换哪张图、透明度变化多少；
第四，为什么有些切图工具导出的 PNG 在 Retina 屏上发虚，而另一些却能自动加 0.5px 描边补偿；
第五，当项目需要支持深色模式，切图流程如何避免手动导出两套资源，还能保证 dark/light 图标语义一一对应。

这些问题的答案，藏在每款工具的底层架构里：PxCook 本质是 PSD 解析器 + 命名规则引擎，蓝湖是设计稿语义化提取器 + 开发 API 网关，Photoshop 是像素级控制台 + 资源管理中枢。接下来，我会用真实项目场景，一层层剥开它们的肌肉和神经——不是告诉你“点哪里”，而是让你明白“为什么必须点这里”。

2. 四类切图工具的本质差异：从像素搬运工到设计系统翻译器

2.1 Photoshop：不是“切图软件”，而是“像素控制台”

很多人把 Photoshop 当作切图起点，这是个巨大误区。Photoshop 的核心能力从来不是“导出图片”，而是对每一个像素的绝对控制权。它能让你把一张 100×100px 的 PNG 放大到 400×400px 后，用“保留细节（扩大）”算法让边缘不糊；也能在导出时强制关闭“转换为 sRGB”，让设计师在广色域显示器上看到的 Pantone 色值，和印刷厂打样机输出的色块完全一致。

但正因如此，Photoshop 的切图流程天然反自动化。举个真实案例：我们曾为某银行 App 切一套金融图标，要求同时输出 @1x/@2x/@3x 三套尺寸，且每个图标必须带 1px 白色描边（用于深色背景）。如果用传统方式——

• 先用“图像大小”缩放图层，再手动加描边，最后导出；
• 或者用“生成器（Generator）”功能，但需提前给图层命名如icon-home@1x.png，稍有拼写错误就导不出；

这两种方式都卡在“人肉操作”环节。直到我们发现 Photoshop 2023 新增的“导出为”功能里，有个隐藏参数：“缩放时应用抗锯齿”开关默认开启，会导致 @2x 图在高 DPR 屏上边缘发灰。关掉它，再配合“导出为”里的“匹配图层名称”规则，才真正实现一键三套资源。

提示：Photoshop 切图真正的效率瓶颈不在操作步骤，而在图层组织逻辑。我们团队强制要求所有可切图层必须满足三点：① 图层组名以EXPORT_开头；② 组内图层名不含空格和中文（如btn_primary_normal）；③ 文字图层必须栅格化（右键→“栅格化图层”），否则导出时会丢失字体信息。这套规则让新人两天内就能独立交付整套图标资源。

2.2 PxCook（像素大厨）：PSD 的“语义解析器”，专治设计师的命名混乱

PxCook 的存在价值，是解决 Photoshop 最大的软肋——图层命名随意性。设计师习惯把图层叫“新建图层 23”、“副本 7”，或者更绝的“这个改一下就行”。PxCook 不依赖图层名，而是通过分析 PSD 文件结构，自动识别“按钮”、“图标”、“文字块”等元素类型。它能读取 PSD 中的图层混合模式、描边粗细、阴影参数，并转换成前端可理解的 CSS 代码。

但它的局限也很明显：只认 PSD，不认 Sketch/Figma。去年我们接了个海外项目，客户用 Sketch 设计，要求用 PxCook 输出标注。结果折腾三天才发现：Sketch 导出的 PSD 会丢失图层样式（比如渐变叠加），PxCook 解析后阴影参数全变成 0。最后方案是让设计师在 Sketch 里先用插件“Export for Web”导出 SVG，再用 PxCook 的“SVG 导入”功能反向生成标注——这已经不是切图，而是跨格式翻译。

PxCook 的核心优势在于“所见即所得”的标注精度。比如设计师在 PSD 里画了个圆角矩形，半径设为 8px，PxCook 会直接在标注面板显示border-radius: 8px，而不是像某些工具那样四舍五入成8.02px。这种精度来自它对 Photoshop 坐标系的深度适配：它知道 PSD 的 1px 等于 CSS 的 1px，但会自动换算 DPR（设备像素比）。当你在 PxCook 里设置“导出倍率=2”，它不是简单把图片放大两倍，而是根据当前屏幕 DPR 动态调整——在 MacBook Pro 16 英寸（DPR=2）上导出 @2x，在 iPad Air（DPR=2.17）上则导出 @2.17x 资源。

2.3 蓝湖：从“切图工具”进化成“设计系统网关”

蓝湖早已不是当年那个“上传 PSD 自动生成标注”的工具。现在的蓝湖 MCP（Multi-Code Platform）本质是一个设计资产 API 化平台。它把设计稿里的每个元素，都抽象成可编程的数据对象。比如一个按钮组件，在蓝湖里不只是图片和尺寸，而是包含：

• type: "button"（组件类型）
• state: ["normal", "hover", "disabled"]（状态集合）
• props: { color: "#007AFF", fontSize: "14px" }（属性列表）
• export: { web: { format: "png", scale: [1,2] }, ios: { format: "pdf", scale: [1,2,3] } }（导出规则）

这意味着，开发同学不再需要手动下载 PNG，而是调用蓝湖提供的 API，传入componentId=btn-primary&state=hover&platform=web，直接返回带正确尺寸和格式的资源 URL。我们做过测试：一个含 50 个组件的中后台系统，用蓝湖 MCP 替代人工切图，资源交付时间从 3 天压缩到 12 分钟，且零差错。

但蓝湖的坑在于“过度自动化”。比如它默认把所有文字图层识别为“文本组件”，导出时会生成 SVG 字体文件。可当开发用font-family: "PingFang SC"渲染时，发现 iOS 和 Android 字体渲染差异导致行高不一致。解决方案是在蓝湖后台的“组件设置”里，把该文字图层手动标记为“位图文本”，强制导出 PNG——这需要设计师理解前端渲染原理，不是点几下就能搞定。

2.4 Figma 插件生态：切图进入“规则即代码”时代

Figma 自身没有内置切图功能，但它的插件市场彻底改变了游戏规则。像 “Anima”、“Zeplin Legacy”、“Avocode” 这类插件，本质是把切图逻辑写成 JavaScript 脚本。你可以用代码定义：“所有命名含_icon的图层组，自动导出为 SVG；命名含_bg的，导出为 PNG 并添加 1px 白色描边”。

我们团队自研了一个 Figma 插件，解决最头疼的“多状态图标”问题。设计师只需把图标的不同状态（normal/hover/active）放在同一图层组里，插件会自动：

1. 识别组内图层名后缀（如home-normal,home-hover）；
2. 按后缀生成对应状态的 SVG 文件；
3. 合并成单个<symbol>SVG Sprite；
4. 输出配套的 CSS 类名映射表（.icon-home { background-position: 0 0; }）。

这套流程让图标交付从“每次改状态都要重切 3 张图”，变成“改完设计稿，点一下插件，10 秒生成全套资源”。关键在于，所有规则都写在插件代码里，版本可控、可复用、可审计——这才是切图工具的终极形态：不再依赖某个软件的 UI 操作，而是用代码定义交付标准。

3. 实操避坑指南：从 PSD 到上线的 7 个致命细节

3.1 Photoshop 导出时的色彩空间陷阱：sRGB vs Adobe RGB

很多设计师抱怨“设计稿看着很鲜艳，切出来的图发灰”。根源在色彩空间设置。Photoshop 默认新建文档用的是Adobe RGB (1998)，色域比 sRGB 宽 35%，但浏览器只认 sRGB。当你直接导出 PNG 时，如果没勾选“转换为 sRGB”，图片会带着 Adobe RGB 的色彩配置文件上传。多数 CDN 服务（如阿里云 OSS）会自动剥离配置文件，导致颜色严重失真。

实测对比：同一张渐变图，在 Photoshop 里：

• 未勾选“转换为 sRGB” → 导出 PNG → 上传到网页 → 浏览器显示偏暗、饱和度低；
• 勾选“转换为 sRGB” → 导出 PNG → 上传 → 颜色准确；
• 或者更稳妥：在“编辑→颜色设置”里，把“RGB 工作空间”改成“sRGB IEC61966-2.1”，从此新建文档默认 sRGB。

注意：这个设置影响所有新文档，但不会改变已有 PSD 的色彩空间。要批量转换旧文件，用“图像→模式→指定配置文件”，选择 sRGB，再点“确定”。千万别选“转换为配置文件”，那会强行映射颜色，造成色偏。

3.2 PxCook 的图层分组逻辑：为什么你的图标总导不出？

PxCook 识别可切图层的规则是：必须是图层组（Layer Group），且组内至少有一个像素图层（Pixel Layer）。纯文字图层、形状图层（Shape Layer）、智能对象（Smart Object）单独存在时，PxCook 会忽略。常见错误：

• 把图标画在形状图层上（用钢笔工具画的矢量路径），PxCook 认为这是“不可导出的矢量”，直接跳过；
• 图标放在智能对象里（为了方便缩放），PxCook 解析时无法读取内部像素，显示为“空组”；
• 图层组名含特殊字符（如/、#），PxCook 会截断命名，导致导出文件名乱码。

解决方案：在 Photoshop 里，选中图标图层 → 右键 → “栅格化图层”，再拖进新图层组。组名用英文+数字（如ic_home_filled），避免任何符号。我们团队还定了条铁律：所有图标必须用“画笔工具”（Brush Tool）绘制，哪怕只是描边，也要确保是像素画布——这样 PxCook 100% 识别。

3.3 蓝湖 MCP 的 HTML 预览失真：CSS 变量没生效的真相

蓝湖生成的 HTML 预览页，常出现文字模糊、阴影偏移、圆角不圆等问题。根本原因是：蓝湖导出的 CSS 代码，依赖现代浏览器特性（如 CSS Custom Properties），但预览页的 HTML 模板没注入 Polyfill。比如你设置了--primary-color: #007AFF，蓝湖生成的 CSS 里写color: var(--primary-color)，可在 IE11 或旧版 Safari 里，var()函数不被支持，直接回退成color: initial，文字变成黑色。

排查方法：打开蓝湖预览页 → 按 F12 → 查看 Elements 面板 → 找到对应元素 → 看 computed 样式里color值是否为#007AFF。如果不是，说明 CSS 变量未生效。临时解法：在蓝湖后台“项目设置→导出设置”里，关闭“使用 CSS 变量”，改用内联样式（color: #007AFF）。长期方案：让前端同学在项目里引入css-vars-ponyfill库，自动将 CSS 变量转译为兼容代码。

3.4 Figma 插件导出 SVG 的路径陷阱：为什么图标在网页上显示空白？

Figma 导出 SVG 时，默认勾选“优化 SVG”。这本是好事，但有个致命副作用：它会删除<defs>标签里的<style>定义，而很多设计师用 CSS 控制 SVG 内部元素（如path.fill { fill: currentColor; }）。结果导出的 SVG 里只剩<path>，没了样式，网页加载时就是空白。

验证方法：用文本编辑器打开导出的 SVG 文件，搜索<style>。如果不存在，说明被优化掉了。解决方案：在 Figma 导出设置里，取消勾选“优化 SVG”，或改用插件“SVG Exporter”，它提供更精细的优化选项（如“保留样式标签”）。我们团队还写了段检查脚本：每次提交 SVG 前，自动扫描文件是否含<style>，不含则报警。

3.5 多平台切图的命名规范：iOS/Android/Web 的文件名战争

同一个图标，iOS 要home@2x.png，Android 要ic_home.png（放在 drawable-xhdpi 文件夹），Web 要home.svg。手动管理？不可能。我们的方案是：用 PxCook 的“导出规则” + 正则表达式。在 PxCook 设置里：

• iOS 规则：^ic_(.*)$→@2x→ios/$1@2x.png
• Android 规则：^ic_(.*)$→mdpi→android/drawable-mdpi/ic_$1.png
• Web 规则：^ic_(.*)$→svg→web/icons/$1.svg

这样，设计师只要把图层组命名为ic_home，PxCook 会自动按规则生成三套资源。关键点在于：所有平台的命名前缀必须统一（如ic_），否则正则无法匹配。我们还规定，iOS 的@3x图必须用ic_home@3x.png，不能写成ic_home_3x.png——因为 PxCook 的@3x识别是硬编码的，只认@符号。

3.6 切图资源的 DPI 适配：为什么 @2x 图在 iPhone 14 Pro 上还是模糊？

iPhone 14 Pro 的屏幕 DPI 是 460，理论需要 @3.5x 资源，但行业只用 @2x/@3x。模糊的真正原因是：设计师在 Photoshop 里新建画布时，分辨率设成了 72 PPI，而不是 144 PPI。PPI（Pixels Per Inch）决定画布物理尺寸。72 PPI 下，100×100px 的画布在屏幕上显示为 1.39 英寸宽；144 PPI 下，同样 100×100px 显示为 0.69 英寸宽，像素密度翻倍。

解决方案：在 Photoshop 新建文档时，“分辨率”字段必须填144（不是默认的 72）。这样画的图标，导出 @2x 后，实际像素数是 200×200，正好匹配 iPhone 的 DPR=2。我们团队的模板文件里，所有画布分辨率都锁死 144，新人入职第一件事就是学会改这个参数。

3.7 深色模式切图：别再手动导出两套资源了

支持深色模式的 App，图标常需两套：浅色背景用深色图标，深色背景用浅色图标。手动切？效率低还易漏。我们的自动化方案：

1. 在 Figma 里，用“Variants”功能创建图标组件，设置两个变体：light和dark；
2. 安装插件 “Dark Mode Exporter”，配置规则：variant=light → export as home-light.svg；
3. 插件会自动遍历所有组件，按变体导出对应文件；
4. 前端用 CSSprefers-color-scheme切换：

.icon-home { mask-image: url('./icons/home-light.svg'); } @media (prefers-color-scheme: dark) { .icon-home { mask-image: url('./icons/home-dark.svg'); } }

这套流程让深色模式图标交付时间从 2 天缩短到 10 分钟，且零遗漏。关键是：设计师必须用 Variants 而不是手动复制图层组，否则插件无法识别变体关系。

4. 工具组合实战：一个电商首页的切图全流程拆解

4.1 项目背景与需求拆解

上周我们为某跨境电商 App 切首页资源，需求明确：

• 支持 iOS/Android/Web 三端；
• 首页含 12 个 Banner 图、36 个商品图标、8 个 TabBar 图标、24 个状态按钮（normal/hover/active/disabled）；
• 必须适配深色模式；
• 所有图标需提供 SVG（Web）和 PNG（App）；
• 开发要求 CSS 标注精确到 0.5px（因涉及动态计算布局）。

如果用传统 Photoshop 流程，预计耗时 5 人日。我们最终用“Figma + PxCook + 蓝湖 MCP”组合，3 小时完成全部交付。下面还原真实操作链路。

4.2 Figma 设计阶段：埋下自动化切图的种子

设计师在 Figma 里不是随便画，而是严格遵循“切图友好型设计规范”：

• 所有图标用 Vector Network 绘制（非钢笔路径），确保导出 SVG 无失真；
• 每个图标组件用 Variants 创建light/dark变体，并在属性面板设置export: true；
• Banner 图用 Auto Layout 容器，设置width: 375px（iPhone 宽度），高度自适应；
• 文字图层全部转为 Outline（右键→“Convert to Outline”），避免字体缺失；
• 所有可切图层组，命名规则为[platform]_[type]_[name]，如web_ic_home,ios_btn_primary。

这步看似多花 20 分钟，却省去后续 80% 的沟通成本。比如ios_btn_primary这个命名，PxCook 会自动识别为 iOS 平台按钮图标，蓝湖 MCP 会把它归类到“iOS 组件库”。

4.3 PxCook 批量导出：精准生成 App 端资源

设计师把 Figma 文件导出为 PSD（File→Export→PSD），上传到 PxCook。我们设置三套导出规则：

• iOS 规则：匹配^ios_(.*)$→ 导出为@2x/@3xPNG → 存入ios/文件夹；
• Android 规则：匹配^android_(.*)$→ 导出为mdpi/xhdpi/xxhdpiPNG → 存入android/；
• Web SVG 规则：匹配^web_(.*)$→ 导出为 SVG → 存入web/icons/。

执行后，PxCook 自动处理：

• 识别ios_btn_primary组，导出btn_primary@2x.png（750×150px）和btn_primary@3x.png（1125×225px）；
• 对android_ic_cart组，按比例缩放：mdpi（48×48）、xhdpi（96×96）、xxhdpi（144×144）；
• web_ic_home组导出 SVG，自动添加<title>Home Icon</title>标签，便于无障碍访问。

耗时：8 分钟。生成文件数：216 个（12 Banner × 2 DPR + 36 icons × 3 DPI × 2 states + 8 TabBar × 3 DPI × 2 modes）。

4.4 蓝湖 MCP 接入：生成开发可用的 API 和标注

把 Figma 文件直接发布到蓝湖（用蓝湖 Figma 插件一键同步）。在蓝湖后台：

• 创建“电商首页”项目 → 关联 Figma 文件；
• 进入“组件管理”，蓝湖自动识别出 56 个可复用组件（Banner、Button、Icon）；
• 为每个组件设置导出规则：
  • Banner 组件 → 导出格式：web: jpg, ios: png, android: png；
  • Button 组件 → 状态映射：normal → btn_primary_normal.png；
• 启用“MCP 代码生成”，选择平台：React Native（iOS/Android）、Vue（Web）。

点击“生成代码”，蓝湖输出：

• 一个 npm 包@ecommerce/icons，含所有图标 SVG 和 React 组件；
• 一份 JSON 标注数据，含每个元素的x/y/width/height，精度到小数点后两位；
• 一个 HTML 预览页，URL 直接发给产品经理验收。

开发同学拿到后，只需：

npm install @ecommerce/icons # 在组件里引用 import { HomeIcon } from '@ecommerce/icons'; <HomeIcon mode="dark" />

无需下载图片、无需写 CSS、无需查标注——这就是蓝湖的价值。

4.5 深色模式专项处理：用脚本补全最后 5%

蓝湖 MCP 对深色模式的支持还不够智能。比如 Banner 图的背景色，在深色模式下需从#FFFFFF变成#121212，但蓝湖不会自动切换。我们的补救方案：

• 写 Python 脚本，读取蓝湖导出的 JSON 标注；
• 找到所有banner类型组件，修改backgroundColor字段；
• 生成dark-mode.json，供前端动态加载；
• 同时，用 ImageMagick 批量处理 Banner PNG：

# 把白色背景替换成深色 convert banner-light.png -fuzz 10% -fill '#121212' -opaque white banner-dark.png

脚本运行时间：47 秒。覆盖全部 12 个 Banner。

4.6 最终交付物清单：让交付变成可验证的动作

交付不是“把文件夹发给开发”，而是提供可验证的产物：

• 资源包：resources.zip，含ios/、android/、web/三个文件夹，结构清晰；
• 标注文档：spec.pdf，由蓝湖生成，含所有间距、字体、颜色值；
• API 文档：api.md，说明如何调用@ecommerce/icons包；
• 验收清单：checklist.xlsx，列出每个组件的验收项（如“TabBar 图标在 iOS 17 上点击反馈正常”）；
• 问题追踪表：issues.csv，记录交付时已知问题（如“Android xxhdpi 图标在低端机上加载慢”，附优化建议）。

这份清单让交付从“我觉得好了”变成“你按清单一条条核对”。上周项目，开发同学 15 分钟内完成全部资源接入，零返工。

5. 常见问题速查表：那些让你加班到凌晨的切图 Bug

注意：以上所有问题，90% 都源于设计阶段没建立切图规范。我们团队的 SOP 是：项目启动会第一件事，不是画界面，而是定三件事——图层命名规则、画布分辨率、导出格式清单。这三页纸，比 100 页设计稿更重要。

6. 未来趋势判断：切图工具正在消失，但切图思维永存

最近有客户问我：“你们还用 Photoshop 切图吗？”我回答：“我们不用 Photoshop 切图，我们用 Photoshop 控制像素。”这句话背后，是切图行业的本质变迁。十年前，切图是设计师的专属技能；五年前，它是 UI/UX 工程师的基础能力；今天，它正在变成一种隐性工程思维——你不需要亲手导出 PNG，但必须理解 DPR 如何影响资源体积，明白 SVG 的viewBox和preserveAspectRatio怎么决定缩放行为，清楚 CSSbackground-size: contain和cover在不同屏幕下的渲染差异。

所以，与其纠结“哪个切图软件最好”，不如思考：你的设计交付物，是否具备“可编程性”？

• 图标能否用代码生成（如 Iconify）？
• 颜色系统能否用 Design Token 管理（如 Style Dictionary）？
• 交互动效能否导出为 Lottie JSON，而非 GIF？

我们刚落地的一个项目，把整套设计系统编译成 TypeScript 类型定义：

interface IconProps { name: 'home' | 'cart' | 'user'; // 枚举所有图标名 size: 'sm' | 'md' | 'lg'; // 尺寸约束 mode: 'light' | 'dark'; // 深色模式 }

开发同学写<Icon name="home" size="md" mode="dark" />，编译时自动注入对应 SVG。这已经不是切图，而是用类型系统保障设计一致性。

最后分享个小技巧：每周五下午，我们团队会做 30 分钟“切图复盘”。不聊工具，只问三个问题：

1. 这周哪个交付物，让开发同学多问了三次“这个间距到底是多少”？
2. 哪个图标，因为命名不规范，导致 Android 端漏掉了 xxhdpi 版本？
3. 如果明天所有切图工具都崩溃了，我们靠什么在 2 小时内恢复交付？

答案永远指向同一件事：不是软件，而是人脑里那套可复用、可验证、可传承的切图逻辑。工具会迭代，但这个逻辑，才是你十年经验里最值钱的部分。