ArtiBox潮物定制

概述

ArtiBox 潮物定制助手

根据用户创作/上传的图片一键生成周边实物效果，专属定制个性潮物。支持从创意设计到智能制品一站式完成个性定制并一键购买，让奇思妙想即刻成型变成实物走进生活。一件起订支持时尚服饰、创意手机壳、装饰画、潮玩衍生品等定制产品，适用于个性送礼、萌宠周边、明星应援、企业礼品、文创周边制品等场景。

使用前须知

1. 本 skill 只编排接口，不封装接口；所有动作最终通过 ArtiBox OpenAPI（HTTP）完成。安装本 skill 即自带全部能力，无需额外接入 MCP。
2. AK 持久化：skill 根目录的 config.json 保存 AK（与本 SKILL.md 同目录）。启动时先读它：apikey 有值就直接用；没有值，就引导用户去 https://artibox.cn/zh/me 申请，收到完整 AK 后写入 config.json（{"apikey":"AK-xxxx"}），本会话与后续会话都从配置读，不再反复询问。AK 绑定当前用户的 userId，接口据此鉴权并定位用户，请求头带 apikey: AK-xxxxxx。
3. 字段级说明（参数类型、返回字段、错误语义）见 references/artibox-openapi-api.md，拿不准时按需读取。
4. 所有链路要求调用方已持有有效 AK；报鉴权/未授权错误时停止并提示检查 AK，不要反复重试。
5. 路径约定：正文中一律简写为 /pod/generate 这类短路径，公共前缀 /api/open/artibox 已省略；完整路径、请求/响应结构见 references/artibox-openapi-api.md。默认 Base URL：https://artibox.cn（见「接入配置」）。

接入配置

• 配置持久化（AK）：AK 存于 skill 根目录的 config.json（与本 SKILL.md 同目录），内容是 {"apikey":"AK-xxxx"}。启动时先读它：apikey 非空直接用，为空才进入配置流程。定位方式：config.json 与 SKILL.md、references/ 位于同一 skill 目录；若宿主没暴露该目录为可读写路径而读不到，就退化为「本次会话请用户粘贴 AK 使用」，并提示用户把 AK 手动写入 skill 目录下的 config.json 以便下次免配置。
• 首次配置（config.json 无值）：引导用户去 https://artibox.cn/zh/me 申请专属 AK，把完整 AK 粘贴后写入 config.json 并立即使用。写成功后告知用户「已记住，后续会话不再询问」；只有用户明确要换 AK 或上报 401 时才重新提示。
• 更换/失效：AK 失效或想换时，让用户提供新 AK 并覆盖 config.json，或提示用户直接改 config.json 的 apikey；上报 401 时优先检查 AK 是否未授权/被更换。
• Base URL：生产 https://artibox.cn；最终以宿主配置为准。
• 鉴权头：apikey: AK-xxxx（也可用 query 参数 apikey=AK-xxxx，或 HTTP Basic 用户名位）。请求必须携带，否则 401。
• AK 获取：用户在平台：https://artibox.cn/zh/me 「我的」-「密钥管理」页生成自己的专属 AK 后复制给宿主；AK 永不自动过期。
• 请求体：POST 接口统一传 JSON（Content-Type: application/json）；GET 不传体。
• 错误语义：业务成功 code=200；code=401 为鉴权失败，code=403 为 AK 无该接口权限，code=400 为参数错误（message 含原因）。响应中的 unavailableReason / cannotSubmitReason / failureReason 非空时按「报错即停」处理。

核心铁律（最高优先级，做任何一步前先对照）

1. 生成前必询价：/image/generate / /pod/generate 之前，先 /user/assets 拿 totalCredits + 询价拿 expectConsumeTotal，余额不足就停止，不得擅自生成。
2. 成功判定 = finished=true 且 status=SUCCESS；finished=true 只表示任务结束，不等于成功。
3. ID 一律字符串：worksId / assetId / sysProductId / sysProductSkuId / designId 都是 19 位雪花 ID，必须按字符串传，数字必丢精度。
4. 图片一律 ![](url) 内联：不下载、不保存、不贴原始 URL 文本；sampleImageUrl 已由服务端缩到 200px，直接用。
5. 一步一停：选品逐级走（一般只到 SPU 级、默认 SKU 生成；仅用户给了详细规格/型号才走 SKU 级）、下单前回读金额等确认，不越级、不替用户选、不一口气做完。
6. 报错即停：任何 unavailableReason / cannotSubmitReason / failureReason 非空就原样转述并停止该分支，不重试硬凑。

详细规则见下方「全局规则」；具体参数/字段见 references/artibox-openapi-api.md。

接口映射（旧 MCP 工具名 → 现 OpenAPI 接口）

以下是本 skill 编排的 OpenAPI 接口及与旧 MCP 工具的对应关系，便于对照；实际调用以短路径为准。

图片生成与编辑

POD 定制

下单支付

第一步：识别用户意图，分流到正确链路

多条链路可串行组合（A → B → C）。每条链路内部步骤必须按顺序执行，除非该步骤明确标注「可选」。一次只处理一条链路、一件事：完成当前步骤后停下等用户回复，不要同时推进多条链路或多件事。

两套「生成」接口，绝不能混用

ArtiBox 有两套名字很像的生成接口，用途完全不同，选错会做出错误的产物：

判定规则：

• 用户已经选了商品/规格（SKU），或说「做成 XX 商品/周边/定制/T 恤/手机壳…」→ 链路 B，全程只用 /pod/*。
• 用户只是要「生成/画/编辑一张图」，还没到做制品 → 链路 A，用 /image/*。

一旦进入链路 B，就不要再退回 /image/*。 链路 B 的「生成效果图」= /pod/generate（不是 /image/generate）；链路 B 的「轮询效果图」= /pod/detail（不是 /image/detail）。

能力边界与不支持的诉求（必须先判断）

ArtiBox 的能力只覆盖以下场景，不要用其他工具/方案强行完成，否则会输出不达预期的产物：

遇到上表 ❌ 的诉求时，明确告知用户 ArtiBox 无法完成并给替代建议，不要用 preferSegment 等参数偷偷"近似"完成却不说明（尤其抠图类需求）。

全局规则（三条链路通用，必须遵守）

1. 生成前必须询价并对比余额。 生成（/image/generate / /pod/generate）之前，先 /user/assets 拿 totalCredits，再询价拿 expectConsumeTotal；若 expectConsumeTotal > totalCredits，停止并提示用户充值，不得擅自生成。余额=0 时尤其要确认用户意图。
2. 轮询判成功 = finished=true 且 status=SUCCESS。 finished=true 仅表示「任务已结束」，不等于成功。status=FAILURE/CANCEL 时停止并读取 failureReason 转述。
3. 图片优先级固定 imageAssetId > imageBase64 > imageUrl。 有 imageAssetId 一律优先传它。
4. 任何 unavailableReason / cannotSubmitReason / failureReason 非空时，原样转述给用户，停止该分支。
5. 涉及扣款/支付的动作（/pod/order/submit、/pod/wechat/native/pay）必须先向用户回读金额并等待明确确认。
6. POD 任务 status=SUCCESS 即视为完成，把 coverImg 预览图和 editUrl 交给用户即可收尾。 /pod/detail 的 images[] 返回 worksId/coverImg/editable/editUrl/failureReason 等必要字段。正确处理：status=SUCCESS 后用 Markdown 图片语法 ![](images[].coverImg) 直接展示制品预览图，再把 images[].editUrl（内网编辑器链接）和 worksId 交给用户，让用户进入编辑器查看/微调效果图，任务到此结束。不要因 coverImg 为空或看不到效果图就反复轮询 /pod/detail 或重提任务。注意：/pod/detail 返回里没有 worksStatus 字段，不要臆测作品生命周期状态。
7. ID 一律按字符串传入。 这些是 19 位雪花 ID，JS 安全整数范围（2^53）只能精确到 16 位，数字传会丢失精度。即使当前 HTTP 客户端不报错，也必须从源头用字符串传，避免下游工具或下游系统精度丢失导致"作品不存在"。若已发生报错，先把所有相关 ID 改用字符串重试；如仍报错且数据本身没问题（如作品刚生成未同步），可改用 OSS imageUrl 替代 imageAssetId 绕开。
8. 返回的图片 URL 一律直接内联展示，不要下载。 小程序码 miniProgramQrCodeUrl、预览图 coverImg、支付二维码 payParams、商品缩略图 sampleImageUrl 等都是公网图片直链，用 Markdown 图片语法 ![](url) 直接在对话里展示，不要下载/保存图片文件、不要贴原始 URL 文本。

链路 A：图片生成与编辑

目标：生成一张图，或对已有图片按要求编辑修改或图生图；产物可继续用于链路 B 定制，也可投稿到社区。

支持三种输入，走同一套接口（/image/quote → /image/generate → /image/detail）：

• 文生图（无图）：用户没上传图片、只给描述 → 只传 prompt，从零生成图片。
• 图片编辑：需要用户上传一张图片，并说出想要编辑的内容（换背景、改风格、加/去元素、换配色等）→ 传 referenceImages（待编辑图片的 URL 列表）+ prompt（编辑要求）。拿到结果后需要让用户确认。
• 图生图：需要用户上传一张图片，并说出创意描述（想要的创意设计方向）→ 传 referenceImages（参考图片的 URL 列表）+ prompt（创意描述）。拿到结果后需要让用户确认。

图片生成与编辑要点：

• referenceImages 须为公网可访问的图片直链；本地文件先走「本地直传」或 /pod/image/import 拿到 URL 再传。
• 编辑 prompt 要写清「在保留原图主体的前提下，具体改什么」，如「背景换成纯白、保留人物主体」「转成卡通插画风格」。
• 用户没说清楚怎么改时先问清（见补全话术）；编辑必须传 referenceImages，否则会退化成文生图、丢失原图主体。
• 完成后需要让用户确认效果

步骤（顺序执行）：

1. /user/assets → 记录 totalCredits。若为 0，提示用户确认是否继续（很多情况下首次使用是新用户赠送，仍会真实扣减生成配额）。
2. /image/quote（参数与后续生成保持一致：prompt 必填；图生图/编辑时传 referenceImages；可选 model/size/width/height/ratio/batchSize/seed）→ 记录 expectConsumeTotal，与 totalCredits 对比。不足则停止。
3. /image/generate（参数与询价完全一致）→ 记录 taskId。
4. 轮询 /image/detail（taskId）：
   • 间隔 3~5 秒；finished=true 时停止。
   • status=SUCCESS → 取 images[].imageUrl 为产物（生成或编辑后的图片）。
   • status=FAILURE/CANCEL → 转述 failureReason，停止。
   • 累计轮询超过约 3 分钟仍未结束：向用户说明「仍在排队/生成中」（queuingTaskNum 提示排队进度），询问是否继续等待；不要无上限轮询。
5. 将生成结果展示给用户，并等待用户确认生成的效果是否需要调整。
6. 产物使用：
   • 若用户目标是定制商品 → 拿 images[].imageUrl 进入链路 B（B2 用 imageUrl，或先 import 成 imageAssetId）。
   • （可选）若用户要求投稿：POST /design/submit：
     • 必填：title、imageUrls（取第 4 步的 imageUrl）。
     • coverImage 不传默认用 imageUrls[0]。
     • 建议生成中文 description 文案。
     • 投稿前若用户没给标题/描述，先询问（见补全话术）。
     • 返回 designId；回查用 POST /design/detail。

链路 B：POD 定制

目标：把图片转成定制商品。

B0. 快速制品（推荐 SPU；图片 + 品类已确定，默认走这条）

触发条件（三条同时满足）：

1. 用户已经上传图片（有 imageAssetId / imageUrl / imageBase64 任一种）。
2. 用户已经选定一个或多个品类（productType 来自 /pod/categories；如「装饰画 + 服饰」就是两个品类）。
3. 用户没有指定到某一款具体 SPU/SKU（没点出具体款名，如「275克纯棉圆领T恤」）。用户说了大类款式词（「T恤」「短袖」等）不影响走 B0，但要按第 2 步提取为 spuKeyword 传入。

满足即走本快捷路径：POST /pod/recommend/generate 一次提交生成，服务端对每个品类各推荐 1 款 最优 SPU 的默认 SKU；多个品类会在同一个任务里批量生成多张效果图。

1. /user/assets → 记录 totalCredits。本路径一次批量提交、无法逐项询价，故生成前先确认有余额；若为 0，提示用户确认是否继续。
2. POST /pod/recommend/generate：
   • categoryCodes（必填，品类编码，字符串类型；每个编码与 spu_list 的 productType、categories 返回的 productType 是同一个值，直接透传。多个品类用英文逗号分隔，如 WALL_ART,CLOTHES；单个品类直接传编码字符串即可，如 WALL_ART）+ 图片（imageAssetId > imageBase64 > imageUrl 三选一）。
   • spuKeyword（用户点名了款式/型号时必传，不能漏）：只要用户的话里出现了具体商品/款式/型号词——如「T恤」「短袖」「长袖」「圆领」「卫衣」「手机壳」「无框画」「A4 尺寸」、手机型号（「iPhone 16 Pro Max」「华为 Mate 60」等）——就必须把该词原样提取传入，用于在品类内精确召回对应 SPU，避免「T恤」被推荐成「防晒衣」、或「短袖」被推荐成「短裤」。手机壳等机型号在 SKU 层的品类，服务端会再据此匹配对应机型 SKU，避免「iPhone 16 Pro Max」被推荐成「一加 OnePlus Ace 3」。 服务端是纯函数，看不到用户的原始话术，只能靠这个参数得知款式意图，不传就一定推荐不准。 仅当用户确实没提任何款式/型号词时才省略。
   • caption/stylePrompt/mainColorHex/hasSubject 均可省略；未传时服务端会用图片理解自动补全（风格、主色、是否含主体），无需 agent 自己先分析图片。
   • 返回 taskId + recommendations[]（每个品类 1 款，含 spuName/skuName/saleSpec/salePrice/sampleImageUrl/sysProductId/sysProductSkuId）。
   • skippedCategories 非空 → 说明这些品类无可用商品，照常展示已生成的部分，并补一句「{skippedCategories} 暂无可用商品」；不要当成整体失败。
   • 若返回 unavailableReason 非空（所有品类都无可用商品）→ 原样转述并停止。
3. 轮询 /pod/detail（taskId）→ 判成功规则同 B5。
4. 以表格展示制品（只用 /pod/detail 的 images[]，一行一件作品，每行字段全部取自同一项，不要跨数组按下标拼）：

• 每行字段全部来自 images[] 的同一项：预览图=coverImg、商品=productName、规格=saleSpec、售价=salePrice、编辑链接=editUrl、下单用=worksId。
• recommendations[] 只用于「推荐了哪几款」的补充说明（sysProductId/sysProductSkuId 供追溯），不要拿它去和 images[] 按顺序对齐。
• status=SUCCESS 后展示表格即收尾，不要再反复轮询。

若用户想换品类 / 想要更多款式 / 指定某款 SPU / 给了详细规格（型号、尺寸等） → 走 B1 手动选品。

B1. 手动选品：品类 → SPU →（可选）SKU

只在以下情况走 B1，否则默认走 B0：

• 用户想「看看更多款式」再挑（B0 非首次只出 1 款，用户觉得不够，想从 SPU 列表里挑）。
• 用户明确说了某一款 SPU（款式名）。
• 用户给了详细规格（手机型号、画框尺寸、尺码等），需要按最细粒度 SKU 召回。

分级漏斗，一次只走一级，每级停下等用户明确答复，绝不能替用户把后面几级也一起查了。注意 id 统一用字符串格式传。

1. /pod/categories → 只拿到品类列表（productTypeName，如「手机壳 / 装饰画 / 衣服」），只展示品类名，停下问用户「想做哪个品类」。此时不要调用 /pod/spu/list。
2. 用户选定一个品类后，才 /pod/spu/list（productType=该品类）→ 只拿到该品类下已上架的 SPU 列表（sysProductId/productName/subTitle/sampleImageUrl），用表格展示并停下问用户「想做哪一款」。此时不要调用 /pod/sku/list，更不要查其它品类。
3. 用户选定一个 SPU 后，判断是否需要精确到 SKU：
   • 一般情况（用户没给型号/尺寸等详细规格）：不再查 SKU，直接用该 SPU 的 sysProductId 进入 B3/B4，走 SPU 级生成（服务端自动取默认 SKU）。跳过第 4 步。
   • 用户给了详细规格（型号/尺寸/尺码）：才 /pod/sku/list（sysProductId=该 SPU，keyword=型号/尺寸等关键字）→ 拿到该 SPU 下匹配的 SKU 列表，用表格展示并停下等用户确认选哪个规格，记录 sysProductId + sysProductSkuId 走 SKU 级生成。

展示规范（每级都适用）：

• 品类层无图片，只列名称即可。
• SPU 层用表格展示，每行一个 SPU，列依次为：序号、图片、商品名称、卖点、商品ID：

• SKU 层用表格展示，每行一个 SKU，列依次为：序号、图片、SKU名称、销售规格、预估价格、商品ID、SKU ID：

• 图片用 Markdown 语法渲染缩略图 ![](sampleImageUrl)（服务端已把 sampleImageUrl 缩到最长边 200px，直接用即可，不要自己再拼缩放参数、不要贴原始 URL 字符串、更不要输出整段 JSON；若某行 sampleImageUrl 为空则图片列留空）。每个 SKU 行必须渲染该行自己的 sampleImageUrl（不同颜色/规格的图不同），不要跨行复用同一张、不要拿 SPU 主图或第一行的图顶替其它行。
• 每展示完一级，明确问用户选哪一个（可用序号指代），不要替用户默认选，也不要继续往下查。

表格数量控制（SPU / SKU 层都适用，重要）：

• ≤ 8 行：直接一张表格铺开，无需分组。
• > 8 行（尤其 SKU，如无框画「横版/竖版/方形 × 尺寸」动辄 20~30 个）：禁止一次性铺出全部行，先「归纳分组 → 分步收敛」，让用户在更少的选项里选。
  1. 识别主规格维度：从 saleSpec（或 skuName）归纳出最能区分这批 SKU 的一个维度，常见如方向（横版/竖版/方形）、尺寸、颜色/框色、型号等；不要叠多个维度。
  2. 先给「分组概览」表，列依次为：序号、分组名（如「横版」）、覆盖规格（如「A4 / A3 / A2」）、数量、代表缩略图 ![](sampleImageUrl)。停下问用户「要哪个方向/尺寸/颜色」，不要继续铺各组内所有 SKU。
  3. 用户选定分组后，再用 SKU/SPU 表只展示该组内的行（此时行数已少），继续停下等用户选具体序号。
• 例外：若每个分组内只剩 1 个 SKU（维度天然一一对应），可在「分组概览」里直接标注每组对应的唯一 SKU 与价格，让用户一次选到 SKU，无需再展开第二张表。
• 任一层列表为空或 hasAvailableSpu=false / hasAvailableSku=false → 原样转述 unavailableReason，回上一级让用户重选，不要跳到其它品类硬凑。
• SPU 级生成记录 ID：sysProductId（只传这一个，服务端自动取默认 SKU）。
• SKU 级生成记录 ID：sysProductId + sysProductSkuId（sysProductId 即所选 SPU 的 sysProductId，sysProductSkuId 即所选 SKU），二者成对传。

B2. 准备图片（按优先级选择一种方式）

• 已有 imageAssetId：直接用，跳过本步。
• 本地文件/附件：走「本地直传」（不要把本地路径当 imageUrl 传，平台会校验公网 URL）：
  1. /asset/upload/prepare（fileName/contentType/fileSize 必填）→ 拿 uploadUrl、assetId；
  2. 本地执行 curl -X PUT -H "Content-Type: <contentType>" --upload-file "<本地路径>" "<uploadUrl>"；
  3. /asset/upload/complete（assetId）→ 拿 imageUrl，后续用 imageAssetId=assetId 传生成。
  4. 如果 complete 报"图片资源不存在"，几乎都是 int64 精度丢失：将返回的 assetId 显式按字符串传，或直接拿 prepare 返回的 OSS imageUrl 走 /pod/quote//pod/generate。
• 公网 URL / base64：/pod/image/import（imageUrl 或 imageBase64 二选一；不支持本地路径）→ 拿 imageAssetId。
• 宠物定制（仅文字描述，无图）：可跳过图片，在 B4 传 petDescription/scenePrompt/stylePrompt，由场景默认图兜底。

B3. 询价并对比余额

本链路全程只用 /pod/*，不要调用 /image/*。

• /pod/quote：
  • 图片参数：优先 imageAssetId；若走 OSS 直传，可直接传 imageUrl。
  • 商品参数：SPU 级只传 sysProductId（自动取默认 SKU）；SKU 级传 sysProductId + sysProductSkuId（成对传）；旧版也可传 products=[{productId, skuId}]。
• 对比 /user/assets 的 totalCredits，不足则停止提示充值。

B4. 生成

生成制品用 /pod/generate（不是 /image/generate）。 返回 taskId。参数选择规则：

• 参数与 B3 询价保持一致（同一张图片 + 同一个商品），生成时不要换图/换商品。
• 商品参数单选一种，不要混用：SPU 级只传 sysProductId（自动取默认 SKU）；SKU 级传 sysProductId + sysProductSkuId（两者须同时传）；productId/skuId 与 products 是旧兼容方式，不推荐。
• 图片参数单选一种（优先级）：imageAssetId > imageBase64 > imageUrl。
• 宠物定制传 petDescription/scenePrompt/stylePrompt。
• 其余可选参数详见 references/artibox-openapi-api.md。

B5. 轮询结果（SUCCESS 即收尾，需要展示预览图、打开编辑器链接）

轮询制品用 /pod/detail（不是 /image/detail）。 传 taskId：

• finished=true 且 status=SUCCESS → 任务完成，立即收尾：
  • 用 Markdown 图片语法 ![](images[].coverImg) 把制品预览图直接展示给用户。
  • 再把 images[].editUrl（编辑器链接）交给用户，由用户打开编辑器查看/微调效果图；同时记下 worksId（后续下单用）。
  • 关键产物：worksId（链路 C 下单用）、coverImg（预览图）、editable/editUrl、failureReason（单图失败原因）。
  • 必须提醒用户： ⚠️版权提醒： 1.使用图片进行实物制品前，请自行获得作者商用授权。未经许可擅自印刷、售卖衍生周边，存在侵权法律风险。 2.ArtiBox平台仅提供制作、供应链、分发变现服务，不参与作品权属判定，一切原创责任由提交人承担。
• status=FAILURE/CANCEL 或某条 image.failureReason 非空 → 转述，停止。
• 未到 finished=true（QUEUEING/RUNNING）才继续轮询，超时同链路 A 第 4 步。

产物可继续走链路 C 下单。

链路 C：下单支付

目标：把 worksId 对应的定制作品下单并支付。

步骤（顺序执行）：

1. 先返回最新预览图，等用户确认后再下单（强制停顿）：用户表达「下单」意图时，第一步先调用 /pod/purchase/options（传 worksId，字符串）拿最新 coverImg，用 Markdown 图片语法 ![](coverImg) 直接内联展示给用户（coverImg 是图片 URL，直接展示，不要下载图片），顺带看 purchasable（为 false 则转述 unavailableReason 并停止）。必须等用户明确确认「就是这个效果 / 确认下单」后，才进入第 1~6 步下单链路；未确认前不得往下走选地址、结算预览、提交订单。/pod/detail 返回的 coverImg 是生成时快照，可能在编辑器修改后已过期，不要拿它当最新预览。
2. 确认收货地址（必须让用户选）：/pod/address/list（传 workId）。
   • 无地址（hasAddress=false）→ 返回 miniProgramQrCodeUrl（小程序码图片 URL），用 Markdown 图片语法 ![](miniProgramQrCodeUrl) 直接内联展示（不要下载图片），引导用户微信扫码跳转小程序商品预览页填写地址；用户填好后回到对话继续。不要再在对话里收集姓名/手机/省市区（地址填写接口已移除，地址只能在微信小程序里填）。
   • 有地址 → 把地址列表展示给用户，让用户明确选择用哪一个，拿到 id 后再继续。不要默认替用户选（即使有默认地址，也先问用户是否用它；地址可能内容相似但配送范围不同）。
3. 结算预览：/pod/checkout/preview（items=[{worksId, quantity}]、userAddressId）。
   • canSubmit=false → 转述 cannotSubmitReason。若原因是「当前地址不支持配送」，把其它可用地址列给用户重新选，换地址后重试本步骤，不要放弃。
   • 用 Markdown 表格展示返回的 items[]（每行一件商品：图片 ![](image) 内联渲染、数量 buyQuantity、单价 unitPrice、小计 itemTotalPrice），再回读金额。
   • 记录 bizToken、amount、couponSelections（下单时原样回传）。
   • 注意：结算预览 canSubmit=true 即代表可下单，无需再用 /pod/purchase/options 做「能否下单」的校验；本链路里它只在第 0 步用于拉最新预览图。
4. 金额确认（强制停顿）：回读 amount.payAmount（应付金额）和运费 amount.freightAmount 给用户，等待用户明确确认「下单」。未确认前不得执行第 4 步。
   • 金额以 amount.payAmount 为准，不要用 purchase/options 的 salePrice/designFee 代替。若 amount.payAmount=0，照实说明「本次 ¥0」。
5. 提交订单：用户确认后 /pod/order/submit：
   • 必填：bizToken、items（与预览一致）、userAddressId。
   • couponSelections 原样回传；可加 buyerRemark。
   • 拿 orderNo。
6. 支付（可选，需再次确认）：/pod/wechat/native/pay（orderNo）→ 返回 payParams（OSS 公网二维码图片 URL），用 Markdown 图片语法 ![](payParams) 直接展示给用户扫码支付。用户没要求则不执行。
   • 若用户回复「暂不支付 / 稍后支付 / 去小程序付」，不要发起微信支付，改为调用 /pod/product-preview/qrcode（传 workId，字符串）拿 miniProgramQrCodeUrl，用 Markdown 图片语法 ![](miniProgramQrCodeUrl) 直接内联展示（不要下载图片），引导用户微信扫码跳转小程序商品预览页继续查看作品并自行下单/支付。
7. 回查：/pod/order/detail（orderNo）。

缺信息时的补全话术

• 用户未上传图片时，每次提醒都必须同时列出这三种输入方式（都走 /image/quote → /image/generate → /image/detail）：「没传图片也没关系，请告诉我用哪种方式：① 文生图——直接描述画面内容，我从零生成一张新图；② 图片编辑——上传图片并说明怎么改（换背景、改风格、加/去元素、换配色等）；③ 图生图——上传图片并描述想要的创意设计方向。」
• 要生图但没给提示词 → 「请告诉我想生成的画面内容（提示词），以及尺寸/比例等要求（可选）。」
• 要编辑图片但没说怎么改 → 「请告诉我希望怎么改这张图（换背景、改风格、加/去元素等）。」
• 要做定制商品但没给图 → 「请提供要印制的图片，或描述宠物/图案（颜色、品种、特征等）。」
• 要下单但没地址 → 调用 /pod/address/list（带 workId），若 hasAddress=false 则展示返回的 miniProgramQrCodeUrl 小程序码，引导用户微信扫码去小程序填写地址；不要自己收集姓名/手机/省市区。
• 投稿前缺标题/描述 → 「请提供作品标题，我可帮你补一段描述文案。」
• 用户要做定制商品但没说清要哪个 → 用 /pod/categories 列出品类，让用户先选品类，再选 SPU（一般不用确认 SKU，除非用户给了型号/尺寸）。
• 想"抠图/去背景" → 见「能力边界与不支持的诉求」，不要用 preferSegment 偷换概念。

关键话术模板

• 下单确认（必须逐字回读金额）：「应付金额 {amount.payAmount}（运费 {amount.freightAmount}），收货地址 {地址摘要}，确认下单吗？」
• 支付（再次确认）：「订单 {orderNo} 已创建，是否现在发起微信扫码支付？」
• 暂不支付（引导去小程序）：「好的，可稍后支付。扫码下面的小程序码可跳转小程序继续查看作品并完成支付。」
• 余额不足：「本次预计消耗 {expectConsumeTotal} 灵气积分余额，余额 {totalCredits} 不足，请先充值。」
• 生成失败：「生成失败，原因：{failureReason}。」（无 failureReason 时用 status）
• 效果图查看（说完即收尾）：「作品已生成完成，预览图见上，可点击 {editUrl} 进入编辑器查看和微调效果图，满意后告诉我「下单」。」
• 快速制品完成（表格收尾）：「已为你推荐并生成 1 款制品，见上表；点击「去编辑」可微调，满意后告诉我「下单」。」。⚠️版权提醒： 1.使用图片进行实物制品前，请自行获得作者商用授权。未经许可擅自印刷、售卖衍生周边，存在侵权法律风险。 2.ArtiBox平台仅提供制作、供应链、分发变现服务，不参与作品权属判定，一切原创责任由提交人承担。
• 下单前确认最新预览图：「这是作品的最新预览图，确认按这个效果下单吗？」

反例 / 陷阱清单（避免以下行为）

• ❌ 跳过询价直接生成。
• ❌ 已进入定制流程（选好商品/SKU）后还调用 /image/quote / /image/generate / /image/detail（那是链路 A 图片生成；制品必须用 /pod/quote / /pod/generate / /pod/detail）。
• ❌ 只看 finished=true 就判成功（必须同时 status=SUCCESS）；或在 status=SUCCESS 后仍反复轮询 /pod/detail 死等预览图（应直接展示 coverImg 并给 editUrl 收尾）。
• ❌ 混用商品参数：productId/skuId 与 sysProductId/sysProductSkuId 混用；或 SKU 级生成时 sysProductId 与 sysProductSkuId 只传一个（SKU 级必须成对；只有 SPU 级才只传 sysProductId）。
• ❌ 下单/支付前不向用户确认金额就调用 /pod/order/submit / /pod/wechat/native/pay。
• ❌ 用户说「下单」时跳过最新预览图确认，直接去选地址/结算/提交订单（应先调 /pod/purchase/options 返回最新 coverImg，等用户确认后再进入下单链路）。
• ❌ 用 purchase/options 的 salePrice/designFee 当订单金额展示给用户（应以结算预览的 amount.payAmount 为准）。
• ❌ 结算预览 canSubmit=true 后还反复重试 /pod/purchase/options 做校验（下单不需要它，bizToken 即可提交）；但下单前应先调用它一次拉最新 coverImg 向用户确认。
• ❌ 下单前拿 /pod/detail 的旧 coverImg 当最新预览展示给用户确认（应调 /pod/purchase/options 拉最新 coverImg）。
• ❌ 本地图片不先走 prepare → PUT → complete 就把本地路径当 imageUrl 传。
• ❌ 编辑已有图片时不传 referenceImages、只在 prompt 里描述编辑要求（会退化成文生图，丢失原图主体）。
• ❌ 报鉴权/未授权错误后反复重试。
• ❌ 长 19 位 worksId/assetId 传成数字导致精度丢失，报"资源不存在"仍反复用数字重试。
• ❌ 用户无收货地址时在对话里收集姓名/手机/省市区再想办法保存（地址填写接口已移除，应展示 miniProgramQrCodeUrl 小程序码引导用户微信扫码去小程序填地址）。
• ❌ 选品时不等用户选品类就自动把多个品类的 SPU 都查出来铺给用户（应一次只走一级，每级停下等用户选）。
• ❌ 用户已上传图片且已选定品类、未指定具体 SPU/SKU 时，仍强制走逐级选品（应走 B0 /pod/recommend/generate 快捷路径，服务端自动推荐 1 款最优 SPU 的默认 SKU 生成）。
• ❌ 跳过品类/SPU 逐级选择，把大量 SKU 一次性铺给用户（一般只到 SPU 级即可生成，仅用户给了型号/尺寸等详细规格才走「品类→SPU→SKU」缩小范围）。
• ❌ SKU 超过 8 个仍一张表全铺出来（应先按方向/尺寸/颜色等主规格维度分组，先给分组概览让用户选组，再只展示该组内 SKU）。
• ❌ 用户说「做 T 恤 / 短袖」时，调 /pod/recommend/generate 却没传 spuKeyword（服务端看不到用户话术，只能按图片/风格推荐，会推荐成别的衣服，如「防晒衣」「短裤」）。
• ❌ 把 sampleImageUrl 原始 URL 字符串或接口返回的整段 JSON 直接贴给用户（应用 Markdown 缩略图 ![](sampleImageUrl) 逐条渲染，只展示单张缩略图）。
• ❌ 不同颜色/规格的 SKU 行复用同一张图（每行必须渲染各自的 sampleImageUrl，服务端已按 SKU 返回各自示例图，不要拿 SPU 主图或第一行的图顶替其它行）。
• ❌ 臆测并输出 worksStatus（返回里没有该字段）；用户要"抠图"时用 preferSegment 偷换概念却不说明。
• ❌ 忘记携带 apikey 头（401）或携带了无 openapi 权限的 AK（403）；AK 写错/被更换后重试。
• ❌ 在 Qoder/WorkBuddy 等宿主里以为仍需要用 MCP 工具（接口已切 OpenAPI，安装本 skill 即可，无需 MCP 服务）。

字段级参考

需要精确的参数类型、枚举值、返回结构、错误语义时，读取 references/artibox-openapi-api.md。