企业官网建设流程全解析

1. 一套壁纸包从立项到上线的整体思路

这周一早上打开后台，一条留言躺在那里：新壁纸什么时候上。我盯着屏幕上那个还没整理完的导出目录，突然意识到这套壁纸企划已经做到第三期了。第一期是试水，六张图，随手导了几个尺寸就发出去了，结果评论区第一条就是“我的平板用不了，糊成一片”。第二期我开始认真做分辨率矩阵，但主题选了七个，回头一看有四个色调撞在一起，用户根本分不出来。到了第三期，我决定把这件事做扎实——9款全新主题，覆盖桌面、手机、平板三端，目标是真正能撑起日常数字生活的那张背景图。

壁纸这个品类看起来门槛极低，谁都会换背景，但要做成一整套能发布、能被长期使用的包，坑比想象中多。它不像一张插画，画完就完事；它得同时满足审美、可读性、适配、压缩、分发这几件事，任何一环掉链子，用户第一眼就会觉得“廉价”。这套内容适合两类人看：一类是想自己做一套壁纸包的设计或开发朋友，另一类是纯粹好奇一张壁纸背后要折腾多少道工序的读者。下面我把第三期从立项、拆主题、算尺寸、写脚本到排错的完整过程摊开讲，能直接抄的部分我都给了参数和代码。

1.1 为什么定在9款，而不是6款或12款

数量这个事我纠结了很久。第一期6款，发布后收到的反馈是“不够选”；第二期7款，因为我当时觉得凑个整数没意义。第三期我拍板9款，理由是三个维度的平衡。

从感知价值看，用户下载一个壁纸包，心里有个隐形的数量预期。低于8款，他会觉得这是个“小更新”；9到12款之间，感知上就是“一整包”；超过12款，边际收益急剧下降——大部分用户最终只会用其中一两张，剩下的躺在相册里吃灰，而我这边每多一款就要多导出一整套分辨率的文件，工作量是线性增长。

从分组结构看，9这个数字刚好能拆成三组，每组三款。分组的好处是让用户在挑选时有决策路径：先选心情（清爽、沉稳、活泼），再选具体那张。如果是7款，分组成3+3+1，那个“1”会很尴尬；10款分成3+3+4，最后一组失衡。

从更新节奏看，这套企划是季度更新。9款意味着每季度我要准备9个主题的完整素材，按我实际的工作量测算，从构思到成品上线大约是三周半。如果拉到12款，工期会突破五周，中间一旦有插队需求就会拖更，而拖更是这类长期企划最大的杀手。

一个反直觉的经验：壁纸包的价值不在“张数多”，而在“每一张都能被某个人设成常用”。9款里如果有3款是用户长期留着的，这个包就算成功；12款里如果只有1款被留下，剩下11款都是成本。

1.2 主题分组按使用场景，而不是按风格

这是我第二期踩过的最大的坑。第二期我是按“风格”分组的：扁平风三张、渐变风两张、插画风两张。结果用户反馈很统一——“好看是好看，但不知道什么时候用”。风格是创作者的语言，场景才是用户的语言。

第三期我改成按使用场景分组，也就是一天里三个不同的时间段落：

• 晨间与通勤组：亮度偏高、饱和度中等偏上，配色偏冷白和浅青。这个时段用户多在室外或地铁里看手机，屏幕反光严重，壁纸太暗会显得脏，太艳会刺眼。这三款的核心指标是“在强光下依然干净”。
• 工作与专注组：低饱和、低对比、大面积留白或低频率纹理。这类壁纸的目的是不抢注意力，桌面图标压在下面依然清晰。三款都控制在主色调不超过两个色相的范围内。
• 夜间与放松组：深色底、点缀少量高亮元素。这里有个技术细节必须提前考虑——OLED屏幕在纯黑区域几乎不发光，深色壁纸确实更省电，但如果整张图都是纯黑加一颗小星星，用户滑动桌面时会觉得“空”。所以这三款我都在深底上保留了一层极低亮度的渐变，让画面有呼吸感。

这种分组方式还有个附带好处：用户换壁纸是有节律的。早上换成清爽的，晚上换成深色的，一套包被反复打开的次数明显高于按风格分组的版本。

1.3 技术路线选型：矢量源文件加位图导出

壁纸的生产路线基本就两条：纯位图手绘，或者矢量/程序化生成后导出位图。我最终选的是矢量源文件 + 批量位图导出的混合路线，理由得说清楚。

纯位图手绘的优势是质感细腻，笔刷、噪点、纸张纹理这些效果矢量很难还原。但它有个致命问题：分辨率绑死。你在1920×1080的画布上画的图，放到3840×2160的显示器上要么拉伸模糊，要么重画一遍。9款主题乘以6种分辨率，等于54张图，重画是不现实的。

矢量源的好处是无限缩放。我在设计工具里只维护一份母版，导出时按目标尺寸重新渲染，边缘永远是锐的。代价是失去了一部分手绘质感，所以我在导出后加了一道“后处理”：用程序叠加极轻微的噪点层和渐变映射，让画面不至于太“电子”。这道工序后面第4节会写具体的脚本。

还有一类主题是纯渐变和几何构成，这类我干脆不用设计工具，直接用代码生成。好处是参数化——色标、角度、半径全是变量，改一个数字就能生成一个变体，调色阶段效率极高。

2. 9款主题的逐个拆解与设计要点

这一节我把9款主题按三组拆开讲，重点不是描述“长什么样”，而是讲每一款在参数上做了什么取舍，以及为什么这么取。所有主题围绕同一个视觉形象展开——一个圆头圆脑的小家伙，它的位置、大小、明度在每一款里都经过计算，不是随手摆的。

2.1 晨间组：低饱和不等于寡淡

晨间组三款我内部代号叫“晨雾”“浅滩”“风起”。它们共同的难点是：低饱和度很容易做出“洗过一遍”的灰败感。我第一版就是这样，整张图看起来像蒙了一层雾，评论区直接说“是不是压缩坏了”。

问题出在明度结构上。低饱和配色的图，如果明度差也小，画面就塌了，没有层次。我的解决办法是保留一处高对比锚点：主体形象的轮廓线与背景的明度差拉到至少40%（在0-100的明度标尺上），其余部分维持在15%以内的柔和过渡。这样画面整体是淡的，但眼睛有落点。

具体到参数，晨雾的主色是H210附近、S18%、L88%，背景到主体的渐变跨度只有6个L值；浅滩是H190、S22%、L84%，配一点点暖色反光；风起用了最激进的留白，主体只占画面面积的11%，位置在右侧三分之一线上。第三款是最冒险的，实测下来喜欢的人很喜欢，觉得“干净”，不喜欢的觉得“啥也没有”，这属于正常分布，我不打算为了讨好所有人把它做得更满。

这里有个实操心得：做低饱和壁纸时，把屏幕亮度调到50%以下再看一遍。很多在满亮度下看着刚好的图，在暗光环境里会变成一片糊。晨雾那款我就是在晚上十点重新调了一次背景渐变的上限亮度。

2.2 工作组与高对比组：可读性永远排第一

工作专注组三款是“格线”“静水”“整页”。这三款的设计约束最严格，因为它们的核心任务是不干扰桌面图标和文字。

这里必须先说清楚一个事实：绝大多数桌面环境会给壁纸叠加一层半透明遮罩，或者给图标文字加阴影，但遮罩的强度因系统而异，你不能指望它。所以壁纸本身必须预留足够的“安静区”。

我的做法是把画面切成网格，标记出图标密集区和空白区，然后把所有高频细节（线条、纹理、小元素）压到空白区。格线那款尤其典型，它本身就是网格主题，如果网格线均匀铺满，图标压上去就完全看不清了。所以我把网格的线条透明度做了空间渐变：画面左下角（图标最密集）线条透明度降到12%，右上角保持45%，中间平滑过渡。这个处理在预览图上几乎看不出来，但实际用起来差别巨大。

高对比组我放了一款深底亮字感的“墨池”，主色L值只有9%，主体形象用接近纯白的L96%。这款的难点是对比度过高导致的边缘光晕——在部分屏幕上，黑底白边会有轻微的发虚感。解决办法是给主体轮廓加一圈1.5px的中间调过渡，而不是硬切。

2.3 极简与插画组：构图要靠安全区倒推

剩下的三款是插画属性更强的“夜航”“纸鸢”“长街”。这三款在构图上花的功夫最多，因为它们有明确的叙事元素，而叙事元素一旦放错位置，在手机上就会被裁掉一半。

我的构图流程是倒着来的：先定安全区，再画内容。具体做法是先拿手机锁屏的比例（大约9:20）画一个框，把顶部18%和底部22%涂灰，表示会被系统时钟和快捷方式遮挡的区域，剩下中间那块才是有效画布。所有关键元素必须落在这块区域里，边缘元素只允许是装饰性的、可牺牲的。

夜航那款的小家伙坐在一条小船上，船的位置我调了四次才定下来，因为放在画面正中会显得呆板，放在下三分之一又容易撞到底部的快捷方式图标。最后落在中间偏下8%的位置，同时把上方留出大面积的深色天空，反而让构图更稳。

纸鸢和长街是横向构图为主的，桌面端很好看，手机端会裁掉两侧。这种情况我没有强行适配，而是做了两个版本的构图——桌面版展开全景，手机版把主体挪到中间并重新调整元素密度。同一个主题，两份构图，这是9款主题实际产出18套画面的原因。

2.4 九个主题的关键参数速查

把上面这些参数整理成表，方便对照。分辨率那一列指的是主力规格，完整矩阵在后面第3节。

表格里“手机端是否独立构图”这一列是关键。9款里有5款做了独立构图，另外4款因为本身就是留白型设计，裁切后反而更干净，所以直接中心裁切。判断标准很简单：把母版按9:20中心裁一刀，如果主体完整、构图不散，就不做独立版；一旦主体被切或者画面重心偏移，就必须重画。

3. 多端适配：让壁纸在每块屏幕上都不糊

分辨率这件事，我见过太多人栽跟头。最常见的误解是“我导出1920×1080，所有电脑都能用”。实际上现在主流笔记本的物理分辨率早就超过这个数了，壁纸被拉伸后那种软绵绵的糊感，一眼就能看出来。这一节把分辨率矩阵、安全区、色彩和命名这四件事讲透。

3.1 分辨率矩阵与像素计算的完整过程

先说结论：壁纸的像素尺寸至少要不低于目标设备的物理分辨率，理想情况是刚好相等或略大。小于物理分辨率一定会被插值放大，产生模糊；远大于物理分辨率则是浪费体积，因为系统会缩小，缩小虽然不糊，但文件白白变大。

主流设备分辨率我按三类整理：

这里有个容易被忽略的点：DPI 对壁纸毫无意义。壁纸是纯像素渲染，系统不会读取图片里的 DPI 元数据去缩放。所以导出时填300还是72，对最终显示效果没有任何影响，只影响你放到打印流程里时的物理尺寸。我见过有人为了“高清”把 DPI 设成600，结果文件体积翻倍，画质一点没变。

再算一笔像素账，理解一下为什么4K壁纸的文件体积压不下来。一张 3840×2160 的 8 位 RGB 位图，每个像素占 3 字节，未压缩体积是：

3840 × 2160 × 3 = 24,883,200 字节 ≈ 23.7 MB

这就是为什么无损 PNG 的4K壁纸动辄十几兆。手机端 1440×3200 同理：1440 × 3200 × 3 = 13,824,000 字节 ≈ 13.2 MB。这个数字决定了后面的压缩策略必须精细，不能一味追求无损。

我的完整导出矩阵最终定为：桌面 1920×1080 / 2560×1440 / 3840×2160 / 3440×1440（带鱼屏单独渲染），手机 1080×2400 / 1170×2532 / 1440×3200，平板 2048×2732 / 2732×2048。9款主题 × 9种规格 = 81个文件。这个数量听起来多，但脚本跑起来是一次性的。

3.2 安全区计算与裁剪策略

安全区是壁纸设计里最实用的一个概念。因为同一张图会在不同比例的设备上被裁切，你必须知道哪些区域是“必然可见”的，哪些是“可能被切掉”的。

手机端的算法我先说清楚。以 1440×3200 为例，系统时钟通常占据顶部约 12% 到 18% 的高度，底部的手电筒、相机快捷方式占约 18% 到 22%。取保守值，顶部预留 18%、底部预留 22%：

顶部遮挡：3200 × 18% = 576 px 底部遮挡：3200 × 22% = 704 px 有效高度：3200 − 576 − 704 = 1920 px 有效区域占全图比例：1920 / 3200 ≈ 60%

也就是说，手机上真正“安全”的只有中间60%的高度。任何核心元素必须落在这一段里。这个数字比我一开始的直觉要小很多，我第一版壁纸就是把主体放在中间偏下，结果被底部图标压住了脸。

桌面端的安全区相对宽松，但也不是没有。底部任务栏在100%缩放下大约占40到48像素，右侧如果有图标列，会占 80 到 100 像素。以 3840×2160 计算，底部 48 像素占比不到2.5%，几乎可以忽略，但右侧图标区在宽屏上会被拉伸，所以我把所有装饰性元素都限制在画面左侧60%的范围内。

带鱼屏（21:9）是完全不同的问题。16:9的图放到21:9的屏幕上，左右会被拉伸得厉害，或者上下留黑边。我的处理是不硬套，直接按 3440×1440 重新渲染一版，把原本在两侧的元素往外推，中间区域保持不变。

3.3 色彩空间、色深与压缩参数

色彩这块的坑比分辨率更隐蔽，因为它不会“明显糊”，而是让你觉得“看着有点怪但说不上哪怪”。

色彩空间统一用 sRGB。这是最重要的一条。现在不少设计工具默认导出 Display P3，理由是色域更广、颜色更艳。但问题在于：如果用户的设备或查看器不支持 P3，系统会做色彩映射，结果是颜色偏灰或者过饱和。壁纸这种东西要的就是“在哪看都一致”，所以宁可牺牲一点色域，也要保证一致性。我在导出脚本里强制指定 sRGB 配置文件，并且在验收时检查每张图是否嵌入了 ICC 描述。

色深保持 8 位。10位或16位对渐变过渡确实有好处，能减少色带，但绝大多数系统在设置壁纸时会降到8位处理，你多出来的位数全被扔掉，只换来更大的文件。真要解决渐变色带，正确做法是在8位图里加一点极轻微的噪点做抖动（dithering），这比提升色深有效得多。

压缩参数按用途分两套。无损 PNG 只给两类图用：纯色大块面、有锐利几何线条的主题，因为 JPEG 在这些地方会产生明显的边缘色渗。其余带渐变的、有插画细节的主题，统一走 JPEG，质量设 88 到 92，色度抽样必须关掉（也就是常说的 4:4:4），这一条是防止彩色边缘发虚的关键。如果目标平台支持 WebP，那优先用 WebP，质量 85 的 WebP 在视觉上基本无损，体积能比 JPEG 再小 30% 左右。

实测数据：夜航那款 3840×2160，PNG 无损 14.2 MB，JPEG 质量90 得到 3.1 MB，WebP 质量85 得到 1.9 MB。三者肉眼对比，在正常观看距离下几乎没有差别。最终我发布的是 JPEG 加 WebP 双版本。

3.4 命名规范、目录结构与版本管理

命名规范这件事，做的时候觉得是小事，等到要热更新一款主题的时候就知道多重要了。我第二期就是吃了这个亏，文件名叫“新版最终改3.png”，结果上线后发现要换其中一张，找文件找了十分钟。

现在的命名规则是固定字段用下划线连接：

boby_vol3_01_chenwu_desktop_3840x2160.jpg

拆开看：企划代号、期数、主题编号、主题代号（拼音，避免中文在部分系统解压乱码）、设备类型、分辨率、扩展名。这套规则的好处是可以直接用文件名做排序和筛选，脚本处理时不需要额外的映射表。

目录结构按“先设备后主题”组织，而不是按主题分：

vol3/ ├── desktop/ │ ├── 1920x1080/ │ ├── 2560x1440/ │ ├── 3840x2160/ │ └── 3440x1440/ ├── mobile/ │ ├── 1080x2400/ │ ├── 1170x2532/ │ └── 1440x3200/ ├── tablet/ │ ├── 2048x2732/ │ └── 2732x2048/ └── preview/

按设备分的好处是用户下载时能直接拿到自己需要的那一档，不用在一个大文件夹里翻。同时脚本遍历也更简单，外层循环设备，内层循环主题。

版本管理上我用的是最土但最可靠的办法：源文件目录里放一个changelog.md，每次改动记录日期、主题编号、改动内容。第三期上线后我改过一次晨雾的背景渐变，就是靠这个文件在五分钟内定位到具体是哪个版本的源文件。

4. 实操流程：从源文件到可下载的成品包

前面讲的是设计和参数，这一节全是落地动作。整个流程我跑过三遍，第三遍才把脚本稳定下来。如果你要自己做，可以按这个顺序走。

4.1 素材整理与图层规范

导出脚本能不能跑通，取决于源文件的图层结构是否规范。我在设计工具里给每个主题定的图层命名规则是三层结构：

• bg_*：背景层，包括底色、渐变、纹理。这一层对未来裁切是“可牺牲”的。
• subject_*：主体层，也就是那个小家伙和它的道具。这一层必须完整落在安全区内。
• deco_*：装饰层，星星、毛发、小点之类的细节。这一层在手机端可以整体隐藏。

命名统一之后，脚本可以按前缀做选择性导出。比如生成手机版时，脚本可以只导出bg_和subject_两层，把deco_关掉，画面立刻就干净了，不用手工改。

另一个规范是所有颜色必须走全局色板，不能有游离的手填色值。第三期9款主题共用了32个色值，全部定义在一份色板文件里。这样做的直接收益是：上线前我统一把整体饱和度下调了3%，只改了色板里的几个数字，81个文件重跑一遍十分钟搞定，如果每个图层都是手填色，这个改动量是不可想象的。

4.2 批量导出脚本

导出我用 Python 加 Pillow，配合设计工具的命令行导出能力。核心逻辑是双层循环：遍历主题，遍历尺寸，按尺寸做相应的裁切策略。

from PIL import Image, ImageOps import os SIZES = { "desktop": [(1920, 1080), (2560, 1440), (3840, 2160), (3440, 1440)], "mobile": [(1080, 2400), (1170, 2532), (1440, 3200)], "tablet": [(2048, 2732), (2732, 2048)], } # 带鱼屏单独走扩展逻辑，不做中心裁切 ULTRawIDE = (3440, 1440) def fit_center(src_path, out_path, size, mode="cover"): img = Image.open(src_path).convert("RGB") if size == ULTRawIDE and mode == "extend": # 按高度等比缩放，左右用边缘色延展，避免主体被裁 ratio = size[1] / img.height new_w = int(img.width * ratio) img = img.resize((new_w, size[1]), Image.LANCZOS) canvas = Image.new("RGB", size, img.getpixel((0, img.height // 2))) offset = (size[0] - new_w) // 2 canvas.paste(img, (offset, 0)) canvas.save(out_path, "JPEG", quality=90, subsampling=0) return # 其余尺寸统一中心裁切，保证主体不偏 out = ImageOps.fit(img, size, method=Image.LANCZOS, centering=(0.5, 0.5)) out.save(out_path, "JPEG", quality=90, subsampling=0)

几个关键点值得单独说。第一，ImageOps.fit用的是中心裁切加 Lanczos 重采样，比直接resize拉伸要清晰得多，代价是两侧会被裁掉，所以才有前面说的安全区设计。第二，subsampling=0对应 4:4:4 色度抽样，这一行不加，彩色边缘就会发虚，尤其是纸鸢那款的暖色轮廓，不加这个参数差别肉眼可见。第三，带鱼屏走的是extend分支而不是fit，因为21:9裁切16:9的图会切掉太多上下内容，用边缘色延展反而更自然。

脚本跑完之后的输出目录，就是第3.4节说的那套结构，直接打包就能发。

4.3 自动校验脚本

人眼盯81张图是不现实的，会漏。所以我写了一个校验脚本，在导出后自动检查四项：尺寸是否精确、色彩模式是否为RGB、是否嵌入了sRGB描述、文件体积是否超阈值。

from PIL import Image import os MAX_KB = 4096 # 单张4K图不超过4MB def check(path, expect_size): img = Image.open(path) issues = [] if img.size != expect_size: issues.append(f"尺寸不符: {img.size} != {expect_size}") if img.mode != "RGB": issues.append(f"色彩模式异常: {img.mode}") if os.path.getsize(path) / 1024 > MAX_KB: issues.append(f"体积超标: {os.path.getsize(path)//1024} KB") return issues

这个脚本帮我抓到过两次问题。一次是某个主题的平板横版导出时尺寸算错了，少了一个像素，肉眼完全看不出来，但系统设壁纸时会做一次非整数缩放，边缘会有一点点模糊。另一次是某张图导出后体积到了 6.8 MB，排查发现是渐变的噪点层强度设得太高，噪点本身就极难压缩，把强度从 4% 降到 1.5% 之后，体积直接掉到 2.7 MB。

校验脚本一定要在发布前跑全量，不要只抽检。我第二期就是抽检了前20张，结果第63张出了尺寸问题，被用户发现指出来，很尴尬。

4.4 预览图与详情页制作

成品包的最后一步是预览图。用户下载前只会看预览，预览做得差，前面所有功夫都白费。

预览图我做了两套：一套是单张缩略图，宽度压到 800px，用来在详情页里逐张展示；另一套是九宫格拼图，把9款主题排成 3×3，用来做封面。拼图的做法是统一裁成正方形再拼，这样视觉上整齐，避免不同主题因为长宽比不同而高低不齐。

详情页的排版我踩过一个坑：一开始我把所有分辨率都列出来，密密麻麻一堆数字，用户根本看不懂。后来改成“按设备选择”的四张卡片——Windows 电脑、Mac 电脑、手机、平板，每张卡片后面藏着对应的分辨率列表。点选之后再展开，转化路径短了很多。

还有一个小细节：预览图的背景色。如果主题本身是浅色的，预览图外围的留白就用浅灰（L96）；深色主题用深灰（L18）。这样每张预览图放在页面上都不会“浮”，整体看起来是一套东西，而不是九张拼凑的图。

5. 常见问题与排查技巧实录

发布前三期下来，我遇到的问题基本集中在四类，每类都有明确的排查路径。这一节按症状组织，方便对照。

5.1 壁纸发灰、发脏、颜色不对

这是出现频率最高的问题，通常有三个来源。

第一个是色彩空间不匹配。源文件是 P3 或 Adobe RGB，导出时没转 sRGB，结果在只支持 sRGB 的设备上颜色被错误映射，整体发灰。排查方法很简单：把图丢进支持色彩管理的查看器，看是否提示“未嵌入配置文件”。解决办法是在导出时强制转换到 sRGB，而不是“另存为”时保留原配置。

第二个是压缩过度导致的暗部色块。深色主题特别明显，墨池那款用质量70导出时，深蓝区域会出现一块一块的色斑。这是因为 JPEG 在低亮度区域分配的信息量少。解决办法是把深色主题的导出质量提到92以上，或者干脆用 PNG。

第三个是系统叠加的遮罩。有些系统会给壁纸自动加一层半透明黑或模糊效果，用户以为是壁纸本身的问题。这个无法从壁纸端解决，但可以在详情页加一行说明：“若画面偏暗，请检查系统壁纸设置中是否开启自动调暗”。

5.2 模糊、锯齿、边缘发虚

模糊的来源几乎都是源图分辨率不够被放大。判断方法：把壁纸按 100% 比例在目标屏幕上查看，如果像素是“两个像素糊成一个”，那就是插值放大的痕迹。

锯齿则多半是缩放算法的问题。早期我用的是双线性插值，边缘会有明显的阶梯感；换成 Lanczos 之后明显改善。但 Lanczos 也有副作用，在极细的线条上会产生轻微的振铃（边缘出现淡淡的光晕），所以格线那款我最终没有用重采样，而是直接从矢量重新渲染，因为它是纯几何线条，渲染出来天然锐利。

边缘发虚还有可能是色度抽样。前面提过，JPEG 默认的 4:2:0 会让彩色边缘的信息量减半，红色、橙色的轮廓最容易看出来。把subsampling设为 0 就能解决。

5.3 主体被裁掉、桌面图标看不清

这两个问题本质上是同一个：没有做安全区验证。

主体被裁的表现是：在电脑上看好好的，一到手机上小家伙只剩半个头。原因是没有按目标比例做独立构图。排查方式是拿目标设备的实际比例画一个框，把母版套进去，看主体中心点是否落在框内。如果偏移超过15%，就该做独立版了。

图标看不清的表现更隐蔽，因为用户往往不会直接反馈，而是“用两天就换了”。排查方法是在壁纸上叠一层半透明的图标网格模拟图，看图标与背景的对比度。我的标准是：图标区域内的背景明度标准差不超过8，如果超过，说明背景太“花”，需要降低那一片区域的细节密度。格线那款的局部透明度渐变就是照着这个标准调出来的。

5.4 问题速查表

把上面这些整理成一张表，出问题时从上往下对一遍。

6. 几个踩过坑才明白的细节

做这套东西最大的体会是，壁纸的门槛不在“画得好看”，而在“用得舒服”。好看决定用户会不会下载，舒服决定用户会不会留着。

第一个体会是关于“减法”的。第一期我总想把画面填满，觉得空着是浪费；第三期反过来，每一款我都先做满，然后一层一层删，删到再删就散了为止。风起那款删到最后只剩一条弧线和一个色块，反而成了这一期反馈最好的一张。用户盯着屏幕的时间是以小时计，画面里的每一个元素都在持续消耗注意力，少即是多这件事在壁纸上体现得特别明显。

第二个体会是关于“一致性”的。9张图分开看都还行，放在一起就容易露怯——色温不统一、明度跨度太大、线条粗细跳脱。我的做法是先把9张缩到 200px 宽并排铺一屏，远看整体是否像一套东西，再逐张放大看细节。这个“先远后近”的检查顺序，比一张一张精修要高效得多。

第三个体会是关于反馈的。用户说“不好看”其实信息量为零，但用户说“我手机上用着字看不清”“锁屏的时候时间挡住脸了”，这就是可以直接改的需求。所以我在详情页留了一个反馈入口，明确请用户说明设备和具体问题。第三期收集到的反馈里，有六成都是和适配相关的，这比任何设计上的自我感觉都可靠。

最后一个实用的建议：如果你也打算做壁纸包，先把导出脚本和校验脚本写好，再开始画。听起来顺序反了，但脚本会让你在设计时就时刻想着“这张图在九个尺寸下表现如何”，很多适配问题在设计阶段就被规避了，而不是等到导出后返工。我第三期能压到三周半完成，靠的就是这个顺序。