SeeAny 电商套图
当用户想生成一整套商品图，而不是单张图时，使用这个 skill。
第一步：先解决 API Key
必须按下面的顺序处理 API Key：
- 如果已经设置了
SEEANY_API_KEY，直接使用。 - 如果用户在当前对话里粘贴了 SeeAny API Key，就仅在本次会话里使用它。
- 如果两者都没有，就停止调用，并明确告诉用户：
- 打开https://www.seeany.com/developer/keys
- 创建或查看 API Key
- 把 API Key 粘贴到聊天里，让 WorkBuddy / OpenClaw 继续执行
不要索取 callback secret 或其他凭证。这里只需要 API Key。
除非用户明确要求，不要把用户粘贴的 API Key 写入仓库文件。
第二步：必须带 User-Agent
调用 SeeAny API 时必须显式带 User-Agent 请求头，否则可能被网站防火墙拦截。
建议值：
seeany-apiworkbuddyopenclawarkclawxclaw- 或其他能标识调用方的名称
如果调用方没有自己的标识，默认使用 seeany-api。
第三步：必须使用用户提供的图片
这个 skill 只能使用用户明确提供的商品图片。
严格规则：
- 如果用户上传了图片，就只能使用这些图片。
- 如果用户提供了公网图片 URL，就只能使用这些 URL。
- 不允许擅自去 Unsplash、Pinterest、Google、商品站点或任何其他外部网站搜索替代图片。
- 不允许因为“看起来更合适”就自行换图。
- 如果用户提供的是本地文件，且当前环境无法直接上传到 SeeAny，可提示用户：
- 先调用POST /api/upload/image上传图片（字段名file或image，仅支持开发者 API Key）
- 使用返回的图片 URL 继续提交任务 - 如果没有用户图片，就不要臆造商品图，也不要自动抓取网络图片，应该直接说明缺少可用图片输入。
优先级规则：
- 第一优先级：用户当前会话上传的图片
- 第二优先级：用户当前会话明确给出的图片 URL
- 除此之外，不允许使用任何其他图片来源
这个 Skill 做什么
- 提交
POST /api/ai/grouptask - 使用
aiTypeId=2373 - 由 WorkBuddy / OpenClaw 先基于商品图和商品信息规划
groups - 脚本只负责规范化、校验、提交和轮询，不负责写死套图文案
- 当用户要看进度或最终结果时，查询
GET /api/developer/task/status
推荐工作流
- 先收集最小输入：
- 商品图
- 商品名称或商品类目
- 卖点文案（如果有）
- 平台、市场、语种（如果有）
- 确认这些商品图就是最终要使用的输入图，不要替换为外部图片 - 如果用户已经明确给了每个组图项的要求，就保留这些要求。
- 如果用户没有给
groups，先根据参考框架自行规划groups，再调用脚本。 - 提交任务。
- 返回受理后的
task_uuid。 - 只有当用户要求查看进度或结果时，再去轮询。
调用约定
- 提交任务时运行
scripts/seeany_ecommerce_sets.py submit - 查询状态时运行
scripts/seeany_ecommerce_sets.py poll submit从 stdin 或--payload-file读取 JSON- 调用时必须显式带
User-Agent - API Key 优先顺序：
1.--api-key
2.SEEANY_API_KEY
3. 用户在当前对话粘贴的 API Key - 不要为了凑出可运行命令而输出大段 shell 示例；重点是构造正确的
groups
输入说明
product_images会映射成inputImgs- 如果传了
groups，会在轻量规范化后直接使用 - 如果没传
groups，脚本会返回缺少组图规划的提示，让你先根据框架生成groups - 提交时会自动补齐
aiTypeId=2373、aiType=imageSets - 支持传入
productType、productName、sellingPoints、platform、desMarket、desLang、visualStyle inputImgs最多 6 张；每组refImgs还需符合所选模型的输入限制- 默认模型是
nano-banana-pro - 默认分辨率是
2K
组图规划原则
在生成 groups 时，遵守这些原则：
- 先看商品图事实，再判断适合的图类，不要硬套固定模板。
- 图类应优先从这些方向中筛选，而不是全部都上：
- 白底主图
- 细节材质图
- 场景氛围图
- 功能卖点图
- 尺寸参数图
- 痛点对比图
- 结构拆解图
- 包装开箱图 - 常规建议输出 4 到 8 组；只有商品确实适合时再扩展。
- 每组都必须有明确用途，避免同义重复。
prompt要具体描述：
- 画面目标
- 主体与构图
- 场景或背景
- 光影
- 材质细节
- 文案/UI（仅在适合的信息型图类中出现）
- 风格和避免项- 不得编造图片里无法确认的结构、功能、尺寸、配件、人物使用方式。
- 不要把所有图都规划成同一种比例或同一种画面。
- 只有适合该商品时，才规划信息型图类或拆解类图。
prompt 编写要求
每个 group.prompt 都应该是可直接执行的出图描述词，不要只写抽象词。
推荐顺序：
- 画面目标
- 主体与构图
- 场景或背景
- 光影
- 材质细节
- 文案/UI（仅在信息型图类需要时出现）
- 画质与风格
- 避免项
必须遵守：
- 只描述从商品图和用户输入中可以合理确认的事实。
- 不要编造商品内部结构、尺寸数字、包装内容、配件数量、使用场景中的真人动作。
- 不要把 prompt 写成“高级感、氛围感、大片感”这种空泛堆词。
- 不要默认加入低价促销风、夸张海报风、强发光、悬浮感、比例失真、材质失真。
- 如果是信息型图片，文案要少、清晰、分区明确，不能写成杂乱长海报。
常见图类写法
以下不是固定模板，而是用于约束每类图应该关注什么。
白底主图- 目标：适合电商首图，突出商品完整外观。
- 应写入 prompt：纯白背景、商品完整居中、边缘清晰、真实接地阴影、无多余装饰。
-
避免：悬浮、背景偏灰、主体裁切、道具喧宾夺主。
-
细节材质图 - 目标：展示纹理、工艺、表面处理、关键细节。
- 应写入 prompt：近景或微距、局部特写、真实材质纹理、可见工艺细节。
-
避免：为了“丰富画面”加入无关元素，或虚构不存在的材质结构。
-
场景氛围图 - 目标：展示商品在真实环境中的使用感和气氛。
- 应写入 prompt：环境类型、主体摆位、空间层次、环境光、真实景深。
-
避免：与商品用途不符的场景，或场景过强导致商品不清楚。
-
功能卖点图 - 目标：突出 1 到 3 个核心卖点。
- 应写入 prompt：卖点分区、视觉重点、少量文字/图标、商品仍为主角。
-
避免：文案过多、布局拥挤、变成促销海报。
-
尺寸参数图 - 目标：表达尺寸或尺度关系。
- 应写入 prompt：标注区域、对比参照、结构化信息表达。
-
避免：编造精确尺寸数字；如果用户没提供尺寸，只能表达“尺寸展示位”或相对尺度逻辑。
-
痛点对比图 - 目标：做优势与劣势、前后状态或新旧方案对比。
- 应写入 prompt：左右或上下分区、对比对象、差异点、商品优势强调。
-
避免：虚构竞品细节，或使用过度贬损性的表达。
-
结构拆解图 - 目标：展示可见结构层次。
- 应写入 prompt：分层逻辑、爆炸图/拆解视图、部件关系。
-
避免：对看不见的内部结构进行编造。
-
包装开箱图 - 目标：展示包装、配件和开箱秩序。
- 应写入 prompt：包装摆放、开箱层次、配件陈列、整洁秩序感。
- 避免：加入用户未提供的赠品、说明书内容或包装文案。
输出质量检查
在提交前，自检每个 group：
cateName是否是明确图类，而不是空泛命名。name是否比cateName更具体，而不是简单重复。prompt是否具体到可以直接生成画面。- 不同
group的用途、比例、画面是否有明显区分。 inputImgs是否不超过 6 张，且每组参考图数量符合所选模型限制。- 是否没有使用任何用户未提供的外部图片。
参考文件
references/payloads.md：输入 JSON 和响应结构references/group_patterns.md：默认组图规划规则
