Cream Pocket Wallpaper AI Workflow

01

从交付内容开始拆 Workflow

我先把一套壁纸商品完整做了一遍，把每一步实际要产出的素材按顺序排开。

素材整理
  ↓
视觉方向
  ↓
锁屏壁纸
  ↓
内页壁纸
  ↓
真机设置与截图
  ↓
双机位展示图
  ↓
锁屏 / 内页单机位
  ↓
手持展示图

跑过几轮以后，重复工作基本集中在三段。

素材会散在不同网站里，保存后还要补来源、归档，再重新拿到生成工具里；锁屏和内页虽然属于同一套主题，但放到真实手机上以后，时间、日期、快捷按钮、App 图标和 Dock 会直接改变构图；展示图又会加入手机框、背景、屏幕内容、手部、透视、水印和 4K 角标。

我最后用三个条件判断一个任务要不要单独封装

• 会不会反复出现
• 输入和输出是否相对稳定
• 做完以后能不能单独判断结果是否可用

按照这个标准，素材采集先独立成插件，后面的制作拆成 3 个 Skill。真机设置、选图和最后的视觉验收继续留在流程里。

这个拆法也控制了项目范围。每一段只负责一个明确任务，后面再遇到问题时，可以直接修改对应 Skill，而不用重新动整条流程。

02

ImgPick｜把多平台素材统一接进飞书

ImgPick 是最先做出来的一段。

用户在支持的网站里选择目标飞书表格、开启拾取，再点击页面里的图片或作品卡片，插件会把标题、图片、来源和原始链接一起写进多维表格。

目前支持 9 类站点

• Pinterest
• 小红书
• YouTube
• Behance
• Dribbble
• Unsplash
• B 站
• 花瓣
• MakerWorld

站点差异放在 extractor 层处理

真正需要处理的，是不同网站的数据结构。

有的页面可以直接从 DOM 读取，有的要处理 srcset，小红书还会读取页面状态；无限滚动页面又会不断新增节点。

我把这些差异收进独立 extractor：

Page
 ↓
Site Extractor
 ↓
Unified Payload
 ↓
Background
 ↓
Feishu API
 ↓
Bitable

每个 extractor 最终输出同一组字段：标题 / 封面 / 详情图 / 原始链接 / 来源平台 / 添加日期。

后面的 Background 和飞书写入层只认统一 payload。Dribbble、MakerWorld 是后面补的站点，新增时主要修改站点侧逻辑，飞书入库部分可以继续沿用。

插件功能也随着使用过程继续调整。第一版只有一个目标表，后面增加了多目标表、页面内切换、来源链接、旧配置迁移和目标表隐藏 / 显示。

这里我一直把 ImgPick 的边界控制在“浏览器 → 素材库”。飞书已经承担分类、筛选和整理，插件不再重复做一套素材管理系统。

03

Wallpaper Skills｜把制作过程拆成 3 个连续任务

素材选定以后，后面的工作由 3 个 Codex Skill 接手。

三个 Skill 共用一组基础字段

• template_type
• scene_type
• layout_type
• overlay_type
• Style DNA：主体
• Style DNA：配色
• Style DNA：光线
• Style DNA：构图
• Style DNA：材质
• Style DNA：情绪

第一轮测试时，我发现只把上一张图片交给下一个 Skill 还不够。模型会重新解释整张图，前面已经确认过的构图、场景和画面气质又会被说一遍。

所以我把这些高频视觉判断结构化下来，和图片一起往后传。一套主题如果已经确定为低饱和蓝色、奶油白、柔和光线和大面积留白，进入 Lock / Home 阶段后，只需要处理屏幕角色和构图约束，不再重新定义整套风格。

04

Skill 01｜先把视觉判断整理成 Style DNA

第一步负责视觉方向。

Skill 会识别输入类型，再提取主体、配色、光线、构图、材质和情绪，同时区分哪些视觉特征可以继续沿用，哪些具体元素需要重新组织。

Input
 ↓
Type / Scene / Layout
 ↓
Style DNA
 ↓
Remix Strategy
 ↓
Prompt
 ↓
9:16 Wallpaper

把“风格信息”和“具体内容”分开处理

这样 Skill 01 的输出就不只是一张图片，还会留下后续 Skill 可以继续读取的视觉上下文。

05

Skill 02｜Lock / Home 按实际使用场景分别适配

第一批壁纸生成后，我直接放到手机里看，Lock 和 Home 的差异很快就暴露出来。

锁屏顶部有时间和日期，底部有快捷按钮；内页长期覆盖 App 图标和 Dock。同一个主体放在相同位置，最终使用效果会有明显差异。

所以第二个 Skill 会先判断：lock_screen / home_screen / uncertain，再补出缺失的一侧。

把两个任务拆开以后，后面再碰到“顶部留白不够”或“内页太抢图标”，只需要调整 Skill 02，不会影响前面的视觉逻辑。

Lock / Home 确认后，我会实际设置到 iPhone 上截图。Showcase 阶段直接使用真实的时间、按钮、App 图标和 Dock。

06

Skill 03｜从真机截图到一套可交付 Showcase

展示图的标准交付固定成 4 张：双机位展示图、锁屏展示图、内页展示图、手持展示图。这也是整套 Workflow 里改动最多的一段。

最早几张图是分别生成的，放在一起以后会出现细节漂移：锁屏裁切变了、时间位置变了、手机外框比例也不一致。

先确认母版，再派生其他展示图

双机位母版
   ↓
确认屏幕 / 背景 / 版式
   ↓
锁屏单机位
   ↓
内页单机位
   ↓
手持展示图

双机位先同时确认 Lock 和 Home，两个单机位继续从对应机位派生，尽量继承相同的屏幕内容、裁切、UI 和背景语言。

这个调整解决的是一套商品图内部的一致性问题。后面的图不再各自“重新生成一遍”。

手持图最后处理

手持图会增加手、指甲、手机角度、服装、背景和屏幕透视这些变量，所以我把它放到最后，并且直接使用已经确认过的锁屏版本。

出图后主要检查：屏幕内容有没有变化、手指和指甲是否正常、手机角度是否自然、背景是否抢主体。一体生成连续失败时，再决定是否进入贴屏兜底。

生成任务和固定处理分开

背景、生活方式场景会随每套壁纸变化，继续交给图片生成；角标、尺寸和固定位置有明确结果，直接交给代码。开放式视觉交给模型，确定性结果交给脚本。

07

测试与优化｜主要问题都出现在 Showcase

前两段壁纸生成稳定以后，测试主要集中在展示图。

4K 角标和水印位置不统一

最早每张图分别处理角标和水印，位置会有轻微偏差。后面我把 4K 角标独立出来，用 apply_4k_badge.py 根据画布尺寸统一计算位置。展示背景重新生成时，角标不会跟着变化。

Python 背景和壁纸气质不匹配

早期展示图背景主要由本地 Python 生成。尺寸和手机位置很好控制，但几套不同风格的壁纸放进去以后，背景会显得过于固定。后来标准流程改成根据当前壁纸的配色、材质和情绪生成背景。Python 模板保留在固定布局和 fallback 场景里。

多张展示图出现屏幕漂移

这个问题推动了前面的“母版 → 派生”调整。双机位先确认，锁屏和内页单机位继续沿用对应屏幕，手持图再接已经确认过的锁屏版本。

三个 Skill 里也保留了 evals.json 和质量清单，目前主要记录尺寸、安全区、视觉一致性、屏幕一致性、手机比例、手部质量和 4 张交付完整性。

自动 Eval 目前还停留在规格层。尺寸、输出数量、安全区这类确定性检查比较适合继续自动化，最终视觉仍然由人确认。

08

完整案例｜从素材到一套店铺交付图

下面这组是其中一次完整任务。

Style DNA

输入素材以浅蓝、奶油白和黄色为主，画面里有云朵和小狗。Skill 01 提取配色、构图、光线和整体气质，再生成第一张 9:16 壁纸。

Lock / Home

锁屏把主体集中到下半部分，顶部留给时间和日期；内页继续沿用同一主题，主体向下调整，中上区域给 App 图标留空。两张图确认后设置到真实 iPhone 上截图。

Showcase

真机截图先进入双机位母版，确认屏幕内容、裁切、背景和版式；锁屏 / 内页单机位从母版继续派生，手持图使用已经确认过的锁屏版本。最后由脚本补齐 4K 角标、统一尺寸和固定边距。

最终交付包括

• Lock Screen
• Home Screen
• Dual-device
• Lock Mockup
• Home Mockup
• Handheld

这套案例把几个关键设计放在了同一条任务里：Style DNA 跨 Skill 复用、Lock / Home 分场景处理、双机位母版继承，以及图片生成和确定性后处理的分工。