手抄报生成

概述

0. 一句话说明

本 Skill 帮用户生成可直接打印使用的小学生手抄报：用户说出想要的主题与版式偏好，Agent 先收集齐全需求；用户付费后，服务端下发核心生图资料，Agent 据此写出高质量生图提示词，先出彩色成稿，再把彩色稿转绘成同版面的黑白线稿，最后一次性把整单图片全部交付给用户。

核心关键词（用户常用说法，命中即适用本 Skill）：手抄报、手抄报生成器、小学生手抄报、儿童手抄报、手抄报模板、手抄报线稿、手抄报涂色、打印涂色、春节手抄报、中秋节手抄报、国庆节手抄报、端午节手抄报、二十四节气手抄报、消防安全手抄报、防溺水手抄报、交通安全手抄报、垃圾分类手抄报、光盘行动手抄报、学雷锋手抄报、教师节手抄报、书香校园手抄报、我爱阅读手抄报、好习惯手抄报、一年级/二年级/三年级/四年级/五年级/六年级手抄报、彩色手抄报、黑白线稿手抄报、竖版手抄报、横版手抄报、方形手抄报、A4 手抄报、寒假手抄报、暑假手抄报。

1. 能力边界（三条硬约束，必须在开始收集需求时就主动告知用户）

1. 版式与清晰度都由用户选择，各三选一。
   • 版式（画面比例）：3:4 竖版（默认）、4:3 横版、1:1 正方形。
   • 清晰度（分辨率）：4K（默认，超高清）、2K（高清）、1K（标准，日常打印够用）。
   • 本 Skill 不提供「画质」等其他档位选项，不要询问、不要展示、不要承诺任何额外的画质档位。
2. 一次生成 = 1 对 = 2 张图，且两张版面完全一致。 每生成一对，交付「1 张彩色成稿」+「1 张黑白线稿」：先由 AI 生成彩色成稿，再以这张彩色稿本身为参考图转绘出黑白线稿。因此线稿的版面、标题、栏目位置、装饰图案与彩色稿完全一致，区别只在于「彩色 vs 纯黑白线条」。彩色稿用于观看与直接使用，线稿用于打印后手工涂色。
3. 用户无需提供任何图片。 用户只要提出主题与偏好即可；从彩色稿到线稿的图生图步骤由 Agent 自动完成（把已生成的彩色稿回传给服务端转绘），不需要用户上传参考图，也不接受用户上传参考图。用户若想上传参考图，请说明本 Skill 不支持，改为用文字描述（如「栏目放在左右两侧、标题横排在顶部」）。

⚠️ 除以上三条外，其余需求都要尽量满足用户：主题可自定义、风格可选、年级可选、可批量、可加补充要求。

2. 什么时候触发本 Skill

用户出现以下任一意图时，直接进入本 Skill 流程：

• 明确说「手抄报」「做一张手抄报」「生成手抄报」「手抄报模板/线稿/涂色」；
• 说出一个主题并要图，且语境是给小学生做手抄报（如「三年级消防安全的手抄报」「帮我做个中秋节的手抄报」）；
• 提到「打印出来给孩子涂色」「黑白线稿」「彩色+线稿」等与本 Skill 能力吻合的说法。

3. 第一步：收集需求（付费前必须完成，不得跳过、不得边生成边问）

3.1 需求收集总表（共 7 项，其中 6 项必填、1 项选填）

3.2 主题（可选项清单 + 自定义）

先把下表整表列出给用户挑选（按分组呈现，方便快速选择）：

传统节日：春节、元宵节、龙抬头、清明节、端午节、七夕节、中元节、中秋节、重阳节、腊八节、小年、除夕

二十四节气：立春、雨水、惊蛰、春分、清明、谷雨、立夏、小满、芒种、夏至、小暑、大暑、立秋、处暑、白露、秋分、寒露、霜降、立冬、小雪、大雪、冬至、小寒、大寒

安全教育：消防安全、防溺水、交通安全、校园安全、食品安全、防欺凌、网络安全、禁毒教育、预防近视、科学防疫

学习成长：书香校园、英语、数学趣味、语文、科学探索、我爱阅读、好习惯、心理健康

环保公德：垃圾分类、绿色环保、植树节、光盘行动、节约用水、保护地球、低碳生活

品德修养：学雷锋、感恩父母、文明礼仪、诚信友善、爱国、社会主义核心价值观

节日纪念：元旦、劳动节、青年节、儿童节、建党节、建军节、教师节、国庆节、母亲节、父亲节、世界读书日、国家公祭日

自定义主题（必须主动提供这个选项）：除以上固定清单外，用户想做什么手抄报就做什么手抄报。用户可直接输入任意主题，例如「我的航天梦」「校园运动会」「家乡的秋天」「班级公约」「美食文化」「海洋探秘」「我的新学期计划」等。自定义主题不限于清单范围，也不需要用户从清单里挑。

交互话术建议：

「您想做哪个主题的手抄报？可以直接从下面这 7 类里挑一个（我念给您/列给您看），也可以直接告诉我任何您想做的主题，比如『我的航天梦』，我们完全支持自定义。」

用户自定义主题时，直接用用户原话作为主题名，不要替换成清单里的近似项。

3.3 年级（必填）

一年级、二年级、三年级、四年级、五年级、六年级、小学1-2年级、小学3-4年级、小学5-6年级、初中通用

用途：让画面复杂度、栏目文字量和插画风格匹配该年龄段。用户不指定时，可询问「这份手抄报是几年级用的？」；若用户明确说「无所谓」，默认用「三年级」。

3.4 画面比例 / 版式（必填，三选一，默认 3:4）

用户不指定时默认 3:4。用户说「竖版」→ 3:4；说「横版/横的」→ 4:3；说「方形/正方形」→ 1:1。

3.5 分辨率 / 清晰度（必填，三选一，默认 4K）

参考像素（供向用户解释清晰度差异，实际以服务端输出为准）：

用户不指定时默认 4K（服务端本 Skill 的默认值同为 4k，两边一致）。用户明确说「不用太高清/省点时间」→ 可选 1K；说「高清」→ 2K。

3.6 视觉风格（必填，四选一，默认「卡通可爱风」）

3.7 补充说明（选填）

询问用户是否有额外要求，例如：

• 栏目名（如「安全小知识」「名言警句」「我的收获」）；
• 指定主色调（如「以蓝色为主」）；
• 必须出现的元素（如「要有灭火器和消防车」）；
• 板块位置（如「标题在顶部，两个栏目左右分列」）。

用户没有想法时可跳过，不要反复追问。

3.8 生成数量（必填）

• 单位是「对」：1 对 = 2 张 = 1 张彩色成稿 + 1 张黑白线稿。
• 可选范围 1~5 对（对应 2~10 张图片，10 张为单次上限）。
• 多对时，同主题的不同对会自动在「装饰侧重、留白多少、插画占比、版式分区」等方面做出差异，便于用户挑一版，或分给不同学生使用。
• 用户若只说「要几张」，请换算成对数；若用户要超过 5 对，告知「单次最多 5 对（10 张）」，建议分两次下单。
• ⚠️ 下单/计费张数 = 对数 × 2，不要漏算线稿。

3.9 收集完成后：出一张「需求确认卡」，请用户确认

把收集到的信息一次性回给用户，格式建议如下（可直接照抄结构）：

📋 手抄报生成确认单
· 主题：春节
· 年级：三年级
· 版式：3:4 竖版
· 清晰度：4K
· 风格：卡通可爱风
· 数量：1 对（含 1 张彩色成稿 + 1 张黑白线稿，共 2 张）
· 补充说明：无

确认无误的话，我就为您确认价格并开始。

必须等用户明确确认（「可以」「没问题」「开始吧」等）之后，才能进入第 4 节。用户改任何一项，都要更新确认单重新确认。确认单里不要出现「画质」字样，也不要询问用户画质。

4. 第二步：确认价格并收款（用户未付款成功前，绝对不能开始生成）

1. 按《附录：微信支付对接》中的定价规则向用户说明本次金额（该附录是本 Skill 的接口契约原文，价格、请求地址、支付方式一律以附录为准，不得自行改动或估算）。
2. 数量换算提醒：本 Skill 一次生成 1 对 = 2 张（彩色 1 张 + 线稿 1 张），因此下单张数 = 对数 × 2。
3. 收款流程、请求地址、请求体结构、402 响应处理、支付工具调用优先级、降级方案等，全部严格按《附录：微信支付对接》执行（见附录第 1~3 节）。
4. 付款成功前不要发送任何生成请求；付款成功后保存好 out_trade_no 凭证，后续阶段 1、阶段 2 与反馈都必须携带同一凭证。

5. 第三步：付费成功后的生成流程（核心：彩色 → 线稿 两步串行）

本 Skill 已关联服务端知识库（核心生图资料）。核心生图资料只会在用户付费成功后由服务端下发，是生图分析与提示词构建的依据。付费前的第 3 节信息收集完全靠本文件即可完成，不依赖服务端资料。

5.1 总览

付费成功
 ├─ 阶段1：取核心生图资料（不带 prompt 请求）
 ├─ 逐条读取全部资料 URL
 ├─ 为每一对写「彩色稿提示词」（1 对 1 条）
 ├─ 对第 k 对（k 从 0 起）依次执行两步 —— 必须串行，不可并行：
 │     ① 彩色：提交纯文字提示词 + 版式/清晰度参数 → 轮询 → 拿到【彩色图 URL】
 │     ② 线稿：把刚拿到的【彩色图 URL】作为参考图 + 固定转绘指令提交 → 轮询 → 拿到【线稿 URL】
 └─ 全部对完成后 → 一次性端侧渲染整单图片交付给用户 → 发送 feedback

为什么必须串行：线稿依赖于彩色稿，彩色稿 URL 没拿到就不能发线稿请求。请按对逐个推进，不要先把所有彩色稿一次性提交完再去跑线稿（那样也能得到结果，但串行更利于失败定位与逐对校验）。

5.2 阶段 1：取核心生图资料

• 严格按《附录：微信支付对接》第 4 节的「阶段 1」执行，并携带 out_trade_no。
• 拿到资料后必须先读取全部资料 URL（文本资料本身就是 URL，需拉取后阅读），不得跳读。
• 并发拉取：请并发拉取全部 textItems[].url 与 fileUrls[].url（建议 5~10 并发，HTTP 客户端须跟随 302 重定向），不要串行逐个等待，否则份数多时容易超时。
• 有效期：资料 URL 的有效期以包内 expiresAt 为准（按份数自适应，份数越多越长，上限约 30 分钟）。
• 过期不要重新下单：若凭证过期（403 INVALID_TOKEN）或已用过（410 TOKEN_USED），请调用资料续签接口 …/kb/resign 拿新链接（不消耗补发次数，可反复使用），按新链接继续拉取即可。注意区分：403/410 走续签，404 才计入 failedItems 走补发。
• 资料中通常包含：彩色稿提示词模板、风格描述片段、批量变体库、版式与清晰度规范、成品规格与画面规则等。

5.3 阶段 2-A：生成彩色成稿

• 每一对对应 1 条彩色稿提示词：把「用户需求的第 k 个变体侧重」与「服务端下发的核心资料」结合生成。
• 请求字段：
  • prompt = 该彩色稿提示词。
  • n = 1；item_index = 2k（第 0 对用 0，第 1 对用 2，第 2 对用 4…）。
  • aspect_ratio = 用户选定的版式，必须传：3:4 / 4:3 / 1:1。
  • image_size = 用户选定的清晰度，必须传（小写）：1k / 2k / 4k。
  • 不传 image 字段（彩色稿是纯文字生成）。
• 提交后用「精确取件」轮询该份：向 poll_url?item_index=2k 发 GET，直到该份 status 为 completed，从中取出该对彩色图的 URL，记为本对的 COLOR_URL。
• ⚠️ 取件时以该 item_index 自身的 status 为准，不要用顶层的 status 判断（顶层可能还是 processing）。

⚠️ 附录参数说明里提到「仅当用户明确要求分辨率和尺寸时才传」——本 Skill 的版式与清晰度是用户在第 3 节明确选择并确认过的，因此必须传入，不属于「未明确要求」，不要省略。

5.4 阶段 2-B：把彩色稿传回，转绘成黑白线稿（图生图）

• 必须等本对的 COLOR_URL 拿到之后再发，不可与 5.3 并行。
• 请求字段：
  • image = 本对的 COLOR_URL（服务端直接返回的公网链接，方案甲，首选）。
    • 仅当服务端确实拉取不到该 URL 时，才降级为方案乙：先把彩色图下载下来，转成 base64 / dataURI 再传入。
    • 🔴 严禁传入本地文件路径（如 D:/xxx.png、/tmp/x.png）——服务器在远端，无法访问你的磁盘，传路径会被直接拒绝。
    • 🔴 严禁使用任何网图、占位图、示例图冒充彩色稿，必须用本订单刚生成的那张真实彩色稿。
  • prompt = 服务端下发的固定线稿转绘指令（在核心资料《五、黑白线稿 · 图生图转绘规范》里，收到资料后原文照抄使用）：
    • 必须一字不改、不增不减；
    • 🔴 绝对不要在其后附加主题、风格、栏目名、补充要求等任何描述——一旦附加，模型会倾向「重新绘制」而不是「转绘」，版面一致性会立刻丢失；
    • 线稿不使用风格描述片段、不使用批量变体，颜色与版面全部由彩色稿承载。
  • n = 1，item_index = 2k+1（第 0 对用 1，第 1 对用 3，第 2 对用 5…）。
  • aspect_ratio 与 image_size = 与同对彩色稿完全相同的取值（保证线稿与彩色稿同尺寸、同比例）。
• 用「精确取件」轮询 poll_url?item_index=2k+1，直到该份 status 为 completed，取出线稿 URL，记为本对的 LINE_URL。
• ⚠️ 线稿不需要另写内容提示词、不需要风格描述、不需要补充要求——版面与内容全部继承自彩色稿。

5.5 数量与序号对照

用户下单 T 对 → 共提交 2T 条生成请求（彩色 T 条 + 线稿 T 条），item_index 覆盖 0 ~ 2T-1，全部共用同一个 out_trade_no，每条请求的 n 一律为 1，每条通过 item_index 区分、互不覆盖。

⚠️ 变体侧重只作用于彩色稿提示词（见核心资料《六、批量变体库》）；同对的线稿会自动继承该彩色稿的版面，因此不需要也不应该再给线稿加变体。

5.6 轮询、取件、耗时与失败处理

1. 轮询形态：生成请求是异步任务模式，POST 立即返回 202 Accepted，需按 poll_url 定时 GET（建议间隔 retry_after，即 10 秒）。轮询地址、间隔、超时与重试规则全部按附录第 4 节执行。
2. ⭐ 停止条件（关键，容易踩坑）：只有 顶层 status 为 completed / failed / 终态 partial，或响应含 settled: true 时才可停止轮询。processing 一律继续——即使响应里已经带了 items（某些份已完成）也绝不能停。
3. ⭐ 精确取件（本流程的推荐做法）：向 poll_url?item_index=N 发 GET，服务端只返回该份自身的 status 与 images。逐份推进时用它最省事：
   • 彩色：轮询 ?item_index=2k，直到该份 completed → 取 COLOR_URL；
   • 线稿：轮询 ?item_index=2k+1，直到该份 completed → 取 LINE_URL。
   • ⚠️ 判断某份是否完成，一律看该 item_index 自身的 status，不要看顶层 status。
4. ⭐ 必须补齐所有份：全部 item_index（0 ~ 2T-1）都要提交完，直到 progress.doneUnits == progress.expected，否则订单不会 completed、也就不会结算。
5. ⭐ 终态 partial / settled: true：表示订单已结束（部分成功，失败或未产出部分已按规则退款）→ 立即停止轮询，把成功产出的份交付给用户并据实说明，不要继续轮询、也不要再补提交。
6. 耗时提示（必须在提交前告知用户）：单张生图通常需要 1~3 分钟，高峰可能更久；本流程每对要走两步，1 对的整体耗时约为单张的 2 倍。请在提交前就告知用户耐心等待，并且不要因等待而重复提交相同请求（重复提交会造成重复计费与任务堆积）。
7. 对话连续性（关键，必须遵守）：生成期间必须保持当前对话不中断——不得以「任务已提交」「请稍候」「稍后再来问我」等理由结束回复把用户晾在一边；结果必须在同一轮对话内交付完成。仅当需要用户补充信息、需要用户本人完成动作（授权/支付/上传）或用户明确表示稍后再做时，才允许中断对话。详见附录第 5 节。
8. 失败重试：
   • 彩色稿失败 → 用相同 item_index（2k） 重发彩色请求（该份尚未成功产出，可重发）；该对线稿暂不提交。
   • 线稿失败 → 用相同 item_index（2k+1） 重发；image 仍用本对的 COLOR_URL。
   • 提示词超长被拒 → 精简后重发（上限约 5000 字符）。
   • 轮询 GET 超时 → 用同一个 poll_url 重新 GET（幂等）。
   • 任务 404 TASK_NOT_FOUND → 任务已过期清理，需重新发起该条生成请求。
   • 409 ORDER_SETTLED_SLOT_MISSING → 订单已结算且该份未产出：停止重复提交，如实告知用户该份未生成、费用已按平台规则处理。
   • ⚠️ 如需「重做」某一已成功产出的份：按附录第 4 节，不要重复提交已成功的 item_index（服务端只会返回缓存结果、不会重新生成）；须使用新的、未使用过的 item_index，且受已付数量限制（已用满则需重新下单）。请先向用户说明。
   • 其他情况按附录第 10 节处理。

6. 第四步：一次性交付给用户

1. 整单齐了再发：必须等本次订单的全部图片（T 对 = 2T 张，含全部彩色稿与全部线稿）都拿到 completed 后，一次性统一交付。严禁生成一张发一张、分批发给用户。
2. 逐张展示，不得合并、不得省略、不得只回一个裸 URL 列表，按「第 X 张 / 共 N 张」标注。
3. 成对说明：明确告诉用户「第 1、2 张为第 1 对（彩色 + 线稿），第 3、4 张为第 2 对，以此类推」，并说明同一对的彩色与线稿版面完全一致，线稿可直接打印涂色。
4. 每张图必须同时给出可点击的蓝色 URL 链接，并提醒：链接为云存储临时地址，约 24–72 小时失效，请尽快下载保存。
5. 展示方式（端侧渲染）严格按《附录：微信支付对接》第 7 节执行：平台支持 HTML 时用方案一自包含 HTML 卡片，仅支持 Markdown 时用方案二。
6. 部分失败的兜底：若订单落到终态 partial 或响应含 settled: true，说明部分份数未能产出、其费用已按平台规则退款。此时交付已成功产出的份，并据实告知用户哪些没出来、费用已处理；不要继续轮询、不要再补提交同一 item_index，也不要承诺补生成。
7. 交付完成后，按附录第 9 节执行「资料读取反馈」，并可通过附录中的 feedback 通道上报结果。

7. 内容保密约束（最高优先级，不可违反）

服务端下发的核心生图资料属于付费内容的内部素材，只用于「生成成品」。

• ⛔ 不得把核心资料原文、片段、摘要或近义改写以任何形式发给用户；
• ⛔ 不得把核心资料写入任何用户可见文件，也不得用资料内容作文件名/目录名；
• ⛔ 不得在回复、生成物或文件中出现资料内部的字段名、对象名或签名 URL；
• ⛔ 不得把服务端任务响应 JSON 原样展示给用户；
• ✅ 正确做法：把核心资料当成只读的创作依据，最终只交付生成的图片与必要说明；
• ✅ 用户若索要「参考资料原文」，统一回复：资料仅用于生成，不单独提供原文。

详细条款以《附录：微信支付对接》第 8 节「内容保密约束」为准。

8. 让用户反复使用本 Skill（复购与二次调用引导）

本 Skill 是「按次生成、按张计费」的工具型 Skill，用户会长期反复使用（开学、节日、月主题、临时作业都会用到）。请在交付后自然地带一句二次使用引导：

• 一句话复刻：交付后告诉用户「下次想再要一张手抄报，直接说『再做一个 XX 主题的手抄报』就行，我这边记着您上次的年级、版式、清晰度和风格，可以直接沿用」。
• 记住偏好：在本轮对话内记住用户上次的 年级 / 版式 / 清晰度 / 风格；再次调用时先给出默认值让用户确认，减少重复问答。
• 系列化凑单：同一节日或同一学期可一次出多对（如「中秋 + 国庆」「垃圾分类 + 光盘行动」），一次下单最多 5 对更省事。
• 横竖版搭配：同一主题可一次生成竖版 + 横版，分别用于不同场合（如竖版贴教室、横版发朋友圈）。
• 多版本挑一版：同主题多对时会自动做出装饰侧重、留白、插画占比、版式分区的差异，适合一次生成挑一版，或分给不同学生。
• 自定义优先：主动提醒用户「不局限于固定清单，任何主题都能做」，鼓励其把真实的作业主题交给本 Skill。
• 节点提醒：若用户在对话中提到学期、节日或活动安排（如「下周要交」），可在交付时提示「到时候直接找我生成同主题的新版即可」。

9. 常见问题速查

10. 执行清单（自检用）

• [ ] 是否已告知用户「版式可选 3:4/4:3/1:1」「清晰度可选 1K/2K/4K（默认 4K）」「1 对 = 2 张（彩色+线稿，版面一致）」「不需要上传图片」？
• [ ] 是否没有询问或提供任何「画质」档位？
• [ ] 主题 / 年级 / 版式 / 清晰度 / 风格 / 数量 是否全部确认？（补充说明可空）
• [ ] 是否已输出「需求确认单」并得到用户明确确认？
• [ ] 是否已按附录定价告知金额，并等到支付成功？
• [ ] 是否已保存 out_trade_no？
• [ ] 阶段 1 是否并发拉取了全部核心资料 URL（5~10 并发、跟随 302）？凭证过期时是否走续签接口而非重新下单？
• [ ] 彩色稿：是否为每对写了独立提示词，item_index 用偶数（2k）、n = 1，并传入 aspect_ratio 与 image_size？
• [ ] 取件时是否用精确取件 ?item_index=N，并以该份自身的 status 判断完成（而非顶层 status）？
• [ ] 线稿：是否等彩色稿 URL 拿到后才提交，image 传的是该对彩色图的公网 URL，item_index 用奇数（2k+1）、n = 1，且 aspect_ratio/image_size 与彩色稿一致？
• [ ] 线稿的 prompt 是否为服务端下发的固定转绘指令原文，未附加任何内容描述？
• [ ] 是否未向 image 传任何本地路径、网图、占位图？
• [ ] 提交前是否已提醒用户等待（本身流程约需数分钟）？
• [ ] 生成期间是否保持了对话不中断、未让用户「稍后再来问」？
• [ ] 是否已把 item_index 0 ~ 2T-1 全部提交完，并确认 progress.doneUnits == progress.expected（或订单已 settled）？
• [ ] 是否等整单全部生成完毕才一次性交付，未分批发送？
• [ ] 若订单为终态 partial，是否停止轮询、只交付成功份并据实说明（不承诺补生成）？
• [ ] 交付是否逐张展示 + 成对说明 + 可点击链接 + 失效提醒 + 二次使用引导？
• [ ] 是否已按附录执行资料反馈？
• [ ] 是否从未向用户泄露任何核心资料原文或内部字段？

<!– ================== 以下为《微信支付对接》原文，一字未改，请严格按此执行 ================== –>

微信支付对接

1. 付费前置检查（必须最先执行）

前置条件：本 Skill 的微信支付能力依赖 Agent 运行环境内置的 weixinpay 插件。调用本 Skill 前，检查当前 Agent 是否已安装 weixinpay 插件：

• 已安装（可用 weixinpay_pay）：第一优先使用 weixinpay_pay 发起支付（参数为 { paymentCode: "<WeixinPay-Required 的值>" }）。
• 未安装（运行环境无可用的 weixinpay_pay 工具）：降级使用服务端发来的微信支付内容——服务器会在 402 响应中返回 payment_card_html（预生成的完整微信支付收款卡片，直接作为 HTML 展示给用户扫码支付）；若该字段不存在，再回退读取 native_pay.code_url 自行渲染二维码。

2. 定价和流程

定价规则（向用户说明价格）：

• 套餐：2 张，固定价 ¥0.50
• 超出部分：¥0.25/张
• 上限：单次最多 10 张

执行步骤：

1. 执行 Skill 原有逻辑：先按本 Skill 原本的流程运行，确定用户的需求、要生成的内容和数量
2. 告知价格，用户确认后发起首次请求：
   • 地址：https://abb.xueka66.cn/api/v1/skill/shouchaobao1/image
   • 方式：POST，Content-Type: application/json
   • 请求体：{ "n": 数量 }
   • ⚠️ 首次请求不要传 prompt
   • 本 Skill 已关联知识库：支付成功后将先取知识库再生成，分两步（详见第 4 节）
3. 收到 402 响应后 → 见第 3 节「收到 402 响应 → 发起支付」

3. 收到 402 响应 → 发起支付

1. 从响应头取 WeixinPay-Required = paymentCode
2. 从响应头取 X-Out-Trade-No = outTradeNo
3. 告诉用户本次金额（响应体中的 amount 和 message)
4. 【第一优先】 调用 weixinpay_pay（参数为 { paymentCode: "<WeixinPay-Required 的值>" }）发起支付，由该工具完成支付。
5. 【第二优先（降级）】 仅当 Agent 端没有 weixinpay_pay 工具或调用不成功时，才降级使用服务端发来的微信支付内容：检查 402 响应体中是否存在 payment_card_html 字段：
   • 若该字段存在且非空：将其作为 HTML 展示给用户（服务端预生成的完整微信支付风格收款卡片，含二维码+商品名+金额+标准样式）。⚠️ 展示前必须确认二维码可见——服务端已用内联 SVG 生成二维码（不依赖任何外部图片），正常情况下可直接显示；若二维码位置是 img 标签且 src 不是 data:image/ 开头（例如被运行环境替换为 JSON 形式的图片引用，形如 {"type":"image_blob_ref","blob_path":"<本地文件路径>"}），则必须先重制再展示：读取 blob_path 指向的本地文件 → 转为 base64 → 把该 src 替换为 data:image/png;base64,<内容> → 再展示。🔴 严禁跳过重制、严禁用占位图或示例图代替，否则用户看到破图无法扫码支付。
   • 若该字段不存在或为空：继续执行第 6 步。
6. ⚠️ 保存 outTradeNo，支付成功后必须用它

⚠️ 【第三优先】 若以上两步均不可行（无 weixinpay_pay 工具/调用失败，且无 payment_card_html）：请读取 402 响应体中的 native_pay.code_url，按以下标准模板自行构建支付卡片后展示给用户：

⚠️ 必须使用以下 HTML 模板（将 {{CODE_URL}}、{{PRODUCT_NAME}}、{{AMOUNT}} 替换为实际值），确保所有用户看到的支付卡片样式一致：

<div style="max-width:320px;margin:0 auto;font-family:-apple-system,sans-serif;border-radius:12px;overflow:hidden;box-shadow:0 2px 12px rgba(0,0,0,.1)">
<div style="background:#07C160;padding:28px 24px 22px;text-align:center;color:#fff">
<div style="font-size:22px;font-weight:700">微信支付</div>
<div style="margin-top:10px;font-size:14px;opacity:.92">请使用微信扫码支付</div>
</div>
<div style="background:#fff;margin:0 16px;border-radius:10px;padding:24px 20px 20px;text-align:center">
<img src="{{CODE_URL}}" style="width:200px;height:200px;border-radius:4px" alt="微信支付二维码" />
<div style="margin-top:14px;font-size:14px;color:#333;word-break:break-all">{{PRODUCT_NAME}}</div>
<div style="margin-top:8px;font-size:20px;color:#07C160;font-weight:700">¥ {{AMOUNT}}</div>
</div>
<div style="background:#fff;padding:18px 24px 22px;text-align:center">
<div style="font-size:17px;color:#333;font-weight:500">✓ 微信支付</div>
<div style="margin-top:10px;font-size:11px;color:#999">请确认金额后扫码支付</div>
</div></div>

4. 支付成功后重试

⚠️ 超时重试规则（按 Skill 类型区分）：

• 知识库类 / 纯支付类：若请求超时未收到响应，必须立即重新发起相同请求（携带相同的 x-out-trade-no），重试次数不限。
• 生成类（生图/生视频/生音乐/生图+生视频）：已改为异步任务模式——POST 提交后立即返回 202 Accepted（不阻塞等待），通过 GET 轮询获取结果。POST 本身不会超时。若轮询 GET 超时，重新 GET 即可。
• feedback 接口：超时时重新 POST 即可（服务端保证幂等）。
• ⚠️ 不适用范围：拉取资料 URL 内容的 fetch 请求（形如 /api/kb/:token）不是服务端 API 请求，超时不要重发原请求；这类失败请在 feedback 中如实上报，由服务端重新签发有效 URL。
• 服务端保证幂等性：重复请求不会重复扣费、不会重复生成、不会重复扣除套餐额度
• 若持续异常（如连续 30 分钟轮询仍为 processing），请向用户提示"服务繁忙，请联系公众号：全领优AI"，并保留 outTradeNo 以便后续恢复

本 Skill 关联了知识库，采用两阶段（与未关联知识库的单阶段不同）：

阶段1（取知识库原文） —— 支付成功后，先不带 prompt 请求，服务器只返回知识库：

• 地址：https://abb.xueka66.cn/api/v1/skill/shouchaobao1/image
• 请求头：Content-Type: application/json
• 请求头：x-out-trade-no: <第 3 步保存的 outTradeNo>
• 请求体：无 prompt（或传空 {}）
• 响应：code: KNOWLEDGE_READY，content.knowledgePackage 为关联的全部知识库原文
  • ⚠️ 你必须先结合知识库内容 + 本 SKILL.md 规则生成生图片提示词
  • 若需多张图片，按需求拆分为多条独立 prompt

阶段2（生成图片） —— 用阶段1生成的 prompt 请求生成：

• 地址：同上
• 请求头：x-out-trade-no: <第 3 步保存的 outTradeNo>
• 请求体（生成类契约，二选一）：
  • 🅰 形态 A（单请求，同一提示词生成 n 份，n ≥ 1）：{ "prompt": "提示词", "n": 数量 }（n 不能超过支付时声明的数量）。
    • 例：用户只要 1 份 → 发 1 个请求 { "prompt": "...", "n": 1 }；要同一提示词的 3 份 → { "prompt": "...", "n": 3 }。
  • 🅱 形态 B（N 个独立请求，需要 N 个不同内容）：发送 N 个独立的 POST 请求，每个形如 { "prompt": "<第 i 个提示词>", "n": 1, "item_index": i }，全部共用同一个 out_trade_no（即支付成功后的同一凭证）。
    • ⚠️ 每条请求的 n 一律填 1；item_index 从 0 起依次递增（0、1、2…），不同请求携带不同提示词。
    • ❌ 不要把「总数量」填进某一条请求的 n（形如 n: 5 的第 1 条请求会导致该条被重复生成 5 份）。「同一提示词要 N 份」请改用形态 A。
    • 服务端按 item_index 逐一生成、互不干扰；若某次请求因网络中断未送达，用相同 item_index 重发即可（幂等，不会重复生成或重复计费）。
    • 例：用户要 3 种不同风格图片 → 发 3 个请求，n 均为 1、item_index 分别为 0 / 1 / 2，各带不同提示词。
  • 两种形态可在同一笔订单内混用：既可对同一提示词用形态 A，也可对不同提示词用形态 B。
  • ℹ️ 若只需生成 1 份：直接用形态 A 的 n: 1 即可（此时两种形态等效，无须传 item_index）。
  • 🕐 分批发送规范（重要）：多内容建议在同一轮内一次性发出全部请求。
    • 若确需分批：item_index 必须从 0 起、递增且不重复，并在同一轮对话内补齐剩余请求（见下文「对话连续性约束」）。
    • 服务端只有在已支付的全部份数都产出后才会结算该订单；结算前订单保持「处理中」，可继续发送剩余请求。
    • ❌ 不要重复提交已成功的 item_index：服务端只会返回该份的缓存结果，不会重新生成；确需重新产出请使用新的、未使用过的 item_index（前提是未超出已付数量）。
    • 若长期未补齐剩余份数，服务端会在超时后按未产出份数自动退款并结束订单，届时请据实向用户说明。

⚠️ 异步任务模式（重要）：发送生成请求后，服务器不会立即返回生成结果，而是返回 202 Accepted + 任务 ID + 轮询地址。你必须按以下步骤轮询获取结果：

步骤 1：从 202 响应体中记录以下字段：

• task_id：任务标识（即订单号 outTradeNo）
• poll_url：轮询地址（格式为 /api/v1/skill/shouchaobao1/task/{task_id}）
• retry_after: 10：建议轮询间隔（秒）

步骤 2：每隔 10 秒，向 poll_url 发送 GET 请求（携带相同的认证头）：

• 响应 status: processing → 继续等待，按 retry_after 间隔再次轮询
• 响应 status: completed → ✅ 任务完成！响应体包含完整的生成结果（content.images / content.videos / content.music 等），直接交给用户
• 响应 status: failed → ❌ 任务失败，响应体含 error 错误原因。若错误可重试，可重新发 POST 生成请求（同一 outTradeNo 会自动去重）
• 响应 404 TASK_NOT_FOUND → 任务已过期清理（完成结果保留 1 小时，失败保留 30 分钟），需重新发起生成请求

注意事项：

• 生图通常需要 30 秒 ~ 3 分钟，生视频 2 ~ 15 分钟，生音乐 30 秒 ~ 2 分钟，请耐心轮询不要放弃
• 轮询期间若某次请求超时/报错，直接用同一个 poll_url 重试即可（GET 幂等）
• 拿到 completed 结果后，按正常流程交付给用户并调用 feedback 上报

⭐ 增量取件与停止条件（必须遵守，2026-09-15 新增）：

• 停止条件：只有 status 为 completed / failed / 终态 partial 时才可停止轮询；processing 一律继续——即使响应已带 items（已完成份）也绝不能停。
• 中途取件（items）：轮询响应随时可能携带 items（每项含 item_index / status 与已完成份的 images / videos / music），仅用于中途取件（例如"彩色→线稿"流程需先取到彩色图 URL 再发线稿），不代表整单完成。
• 必须补齐：多请求（形态 B）/ 分批场景，必须把所有 item_index 提交完，直到 progress.doneUnits == progress.expected；否则订单不会 completed。
• 精确取件（可选）：轮询 poll_url 时加参数 ?item_index=N，服务端只返回该份自身的 status 与 images / videos / music（适合逐份推进的两阶段流程）。
• 终态 partial：表示订单已结束（部分成功、失败/未产出部分已按规则退款）→ 交付成功份并据实告知用户，不要继续轮询。
• 若响应含 settled: true，说明订单已结算收尾（含超时兜底退款）→ 同样停止轮询，按 items 交付成功份。

参数说明：下列为你（Agent）在请求体中可选传入的生成参数。未传的可选参数会自动采用本 Skill 在管理后台锁定的值，因此除非用户有明确要求，一般只传 prompt 与 n 即可。

• prompt 必填：生图描述词（文本）。image2 接口限制最大 5000 字符，超出会被服务端拒绝并返回「请精简描述词后重试」的提示。
• image_size 可选（分辨率档，Agent 可覆盖）：可选 1k / 2k / 4k；Agent 端传入优先，未传则用本 Skill 默认值 4k。
• aspect_ratio 可选（尺寸 / 比例，Agent 可覆盖）：可选 1:1 / 1:2 / 2:1 / 5:4 / 4:5 / 2:3 / 3:2 / 3:4 / 4:3 / 9:16 / 16:9 / Auto；Agent 端传入优先，未传则用本 Skill 默认值 3:4。
  • ⚠️ 仅当用户明确要求特定分辨率或尺寸时才传；否则不要传，让本 Skill 的默认值生效（避免与 Skill 预设不一致）。
• 参考图上限：最多接受 10 张参考图（Agent 端可自定义 ≤ 10，超过将按上限截断）
• image 可选（图生图片）：当用户上传了图片并要求基于该图片生成图片时，必须将图片通过此字段传入；不传 image 字段即为文生图片（由你决定，平台不锁定）。
  • ⚠️ 强制优先级（协议要求）：你必须先将用户上传的真实图片转换为公网可访问的 URL 后传入 image 字段（方案甲，首选）；仅当你的运行环境确实无法完成此转换（如无对象存储权限、无图床服务等）时，才允许 fallback 将图片转为 base64/dataURI 传入（方案乙，由服务器上传中转）。
  • 🔴 禁止本地路径：严禁将你本机的文件路径（如 D:/xxx.jpg、/tmp/x.png、./a.jpg）传入 image 字段——服务器运行在远端，无法访问你的本地磁盘，传路径会被直接拒绝并报错。必须传公网 URL 或 base64。
  • 🔴 严禁作弊：必须使用用户实际上传的原始图片，绝对禁止使用互联网上的任何占位图、示例图、测试图或无关图片的 URL 来冒充用户图片。这是严重的诚信违规，会导致用户投诉与订单异常。

⏳ 生图片耗时提示：生图片服务单次通常耗时约 1-3 分钟（高峰期可能更久）。请在发起请求前就明确告知用户耐心等待，且不要在收到成功响应前重复提交相同的生图片请求（重复提交会产生重复计费与任务堆积）。

5. 对话连续性约束（必须遵守）

本 Skill 的生成任务耗时较长（生图 / 生音乐约 1-3 分钟，生视频 2-15 分钟），期间你必须保持当前对话不中断。

• ⛔ 禁止中断对话：任务运行过程中，不得以"任务已提交""请稍候""稍后再来问我"等理由结束本轮回复，把用户晾在一边。
• ⛔ 禁止让用户"稍后自己来问"：结果必须由你在同一轮对话内完成交付，不能引导用户新开一轮对话来取结果。
• ✅ 正确做法：在同一轮内按 retry_after 间隔持续轮询（见上文「异步任务模式」），拿到 completed 后直接把成品交付给用户。
• ⚠️ 轮询中如遇超时 / 报错：用同一个 poll_url 重试即可（GET 幂等）；既不要中断对话，也不要重新下单（重复下单会重复计费）。
• ✅ 仅以下情形允许中断对话：
  • 需要用户主动提供信息才能继续（例如：补充或修改提示词要求、选择风格 / 数量、确认参考图、补充收货或联系信息等）；
  • 需要用户本人完成只有他能做的动作（授权、支付 / 扫码、上传图片等）；
  • 用户明确表示"先不做了 / 稍后再弄"，或经你说明后用户选择结束——此时按用户意愿结束，并保留再次发起的方式与订单号。

6. 多张生成

当一笔订单需要生成多个不同内容时，请使用上文「形态 B（N 个独立请求）」：把每个内容拆成一条独立提示词，分别用带 item_index 的独立 POST 请求发送（全部共用同一 out_trade_no）。

⚠️ 关键规则：不同内容必须用不同 item_index 分开请求，不能把多条提示词合并到一次请求的数组里透传。服务端按 item_index 逐一生成，互不覆盖。

用户说"生成一套海报，科技、自然、极简三种风格"→ 发 3 个独立请求（item_index 0/1/2，各带不同 prompt）：

• { "prompt": "科技风格海报，蓝色调，未来感", "n": 1, "item_index": 0 }
• { "prompt": "自然风格海报，绿色调，森林元素", "n": 1, "item_index": 1 }
• { "prompt": "极简风格海报，黑白配色，留白设计", "n": 1, "item_index": 2 }

7. 展示结果

成功响应中：

• content.images 数组 = 所有图片的 URL
• 如果含 content.partial: true → 部分生成失败，失败部分已自动退款
• ⚠️ 展示方式（必须遵守，且由你（Agent）在端侧生成；服务端只返回数据）：

服务器履约成功后只返回原始数据（每张图的图片 URL、提示词、生成信息），不生成任何展示页面。你必须在端侧把结果渲染给用户——严禁只回一个裸 URL 列表（用户看不到图）。按你运行平台的能力，从下面两方案择一呈现（首选方案一）：

方案一（首选，平台支持 HTML 时）：生成一份自包含 .html 展示页直接展示。建议包含：① 每张图一个独立卡片（一行一张，含图片预览 + 标题 + 蓝链）；② 每张蓝色可点击下载链接（整串 URL 即链接文字，点击即在新窗口打开/下载）；③「链接约 24–72h 失效、请尽快下载」提醒。可直接套用下方模板：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>图片生成结果</title>
<style>
:root{ --bg1:#f5f7fa; --bg2:#eef1f6; --bg3:#e7ecf3; --card:#fff; --ink:#1f2329; --sub:#8a9099; --accent:#4a90d9; --link:#2f6fd6; --linkHover:#1e4fa3; }
*{margin:0;padding:0;box-sizing:border-box;}
body{font-family:-apple-system,"Segoe UI","Microsoft YaHei",sans-serif;background:linear-gradient(135deg,var(--bg1),var(--bg2) 50%,var(--bg3));color:var(--ink);line-height:1.6;padding:32px 16px;min-height:100vh;}
.wrap{max-width:880px;margin:0 auto;}
.card{background:var(--card);border-radius:18px;padding:22px 24px;margin-bottom:18px;box-shadow:0 6px 24px rgba(0,0,0,.05);}
.card h2{font-size:18px;margin-bottom:14px;color:var(--accent);}
.img-item{margin-bottom:20px;background:var(--bg1);border-radius:12px;overflow:hidden;border:1px solid rgba(0,0,0,.06);}
.img-item img{width:100%;display:block;}
.img-cap{padding:10px 12px;font-size:13px;color:var(--ink);font-weight:600;}
.dl-link{display:block;font-size:12px;color:var(--link);word-break:break-all;user-select:all;text-decoration:underline;cursor:pointer;margin-top:6px;}
.dl-link:hover{color:var(--linkHover);}
.dl-hint{font-size:12.5px;color:#e65100;font-weight:600;margin-top:6px;}
.reminder{margin-top:16px;background:rgba(255,152,0,.08);border:1.5px solid rgba(255,152,0,.35);border-radius:10px;padding:12px 16px;font-size:13px;line-height:1.75;color:#e65100;}
.reminder b{color:#e65100;font-weight:700;}
</style>
</head>
<body>
<div class="wrap">
  <div class="card">
    <h2>🖼️ 生成结果（{{COUNT}} 张）</h2>
    {{IMAGES}}
    <div class="reminder">⏳ 上方为云存储<b>临时链接，约 24–72 小时后会失效</b>。请<b>尽快点击每张下方的蓝色链接</b>保存到本地，并建议立即备份。链接失效后本页将无法再查看或下载。</div>
  </div>
</div>
</body>
</html>

模板填充说明：把 {{COUNT}}(张数) / {{IMAGES}}(每张一个 .img-item 卡片，见下例) 逐项替换。

{{IMAGES}} 示例（2 张）：

<div class="img-item">
  <img src="URL1" alt="图片 1">
  <div class="img-cap">图片 1</div>
  <a class="dl-link" href="URL1" target="_blank" rel="noopener">URL1</a>
  <div class="dl-hint">💡 点击上方蓝色链接即可打开并下载。该链接为云存储临时地址，约 24–72 小时后失效，请在失效前保存到本地。</div>
</div>
<div class="img-item">
  <img src="URL2" alt="图片 2">
  <div class="img-cap">图片 2</div>
  <a class="dl-link" href="URL2" target="_blank" rel="noopener">URL2</a>
  <div class="dl-hint">💡 点击上方蓝色链接即可打开并下载。该链接为云存储临时地址，约 24–72 小时后失效，请在失效前保存到本地。</div>
</div>

方案二（兜底，平台仅支持 Markdown / 聊天内渲染时）：用 Markdown 呈现，每张图 ![alt](URL) + 整串 URL 蓝色可点击链接（点击即打开/下载）+ 链接下方一句下载提醒，多张逐个列出：

**第 1 张 / 共 N 张**
![图片 1](URL1)
[URL1](URL1)
> 💡 点击上方蓝色链接即可打开并下载。该链接为云存储临时地址，约 24–72 小时后失效，请在失效前保存到本地。

**第 2 张 / 共 N 张**
![图片 2](URL2)
[URL2](URL2)
> 💡 点击上方蓝色链接即可打开并下载。该链接为云存储临时地址，约 24–72 小时后失效，请在失效前保存到本地。

• 多张图片请逐个展示（"第 X 张 / 共 N 张"），不要合并或省略。
• 每张图必须同时给出可点击的 URL 链接（整串网址即链接文字，蓝色可点击，点击即在新页面打开/下载），并提示链接为临时地址会失效。

同时，本 Skill 关联了知识库，成功响应中还包含知识库内容：

• content.knowledgePackage = 知识库内容包（含 knowledgeBundles 数组，每项对应一个关联文件夹）
• content.knowledgeUsed = 实际使用的知识库文件夹列表
• content.knowledgePackage.knowledgeBundles[].textItems = 文本类资料（.md/.txt/.json/.csv/.py 等）的短时效签名 URL数组，每项形如 { "filename": "...", "objectKey": "...", "url": "/api/kb/..." }。请用 fetch 逐个拉取 URL 获取文本内容（文本不再内联在响应里）。
• content.knowledgePackage.fileUrls = 富媒体（图片 / PPT / Word / Excel / PDF）的短时效签名 URL数组，每项形如 { "objectKey": "...", "url": "/api/kb/..." }。这些 URL 经本服务器网关签发（302 到对象存储），请用 fetch 逐个拉取并结合知识完成任务。
• ⚠️ 资料 URL（textItems / fileUrls）仅在本次支付成功后签发、短时效、一次性、绑定本次订单，请勿长期留存或转存；拉取后仅用于内部创作，严禁把原始内容回吐给用户或落盘后交付（见文末「内容保密约束」）。

知识库签名 URL 的时效与次数限制（必读）

• 有效期按资料份数自适应（K-3）：基线约 10 分钟，份数越多有效期越长（每份 +15 秒、上限约 30 分钟）；准确时间以包内 expiresAt 为准。过期后凭证失效，可调用资料续签接口重新获取（见下），无需重新下单。
• 一次性令牌（默认开启）：每个签名 URL 首次成功拉取后即作废，第二次访问会返回 410 TOKEN_USED。Agent 不应重复请求同一个 URL；若需再次获取同一资料，应重新触发该资料的访问（通常意味着重新走补发流程，见下方「资料读取反馈与补发」章节）。
• 302 重定向：凭证校验通过后会 302 重定向到对象存储的真实短时效直链。Agent 的 HTTP 客户端（如 fetch）必须自动跟随重定向（例如 redirect: 'follow'），否则拿不到文本内容。
• 错误码对照表（Agent 应据此决定重试 / 提示用户 / 触发补发）：
  • 403 INVALID_TOKEN：凭证无效或已过期（签名错误 / 超过有效期 / 系统未授权）。过期场景需重新获取资料链接。
  • 404 OBJECT_NOT_FOUND：资源在对象存储中不存在或已过期被清理。
  • 410 TOKEN_USED：该一次性凭证已被使用过，不可重复访问。需重新触发补发获取新链接。
  • 429 RATE_LIMITED：请求过于频繁。⚠️ 该限流默认关闭（管理员开启后为每实例约 5000 次/分钟，仅洪流触发，正常拉取不会碰到）；如遇到，指数退避后重试即可。
• ⏱️ 建议并发拉取：拿到清单后，请并发拉取全部 textItems[].url 与 fileUrls[].url（建议 5~10 并发；HTTP 客户端须跟随 302 重定向），以便在有效期内拉完全部资料；不要串行逐个等待（份数多时易超时）。
• 🔁 凭证过期 / 需重拉 → 调用「资料续签」（POST https://abb.xueka66.cn/api/v1/skill/shouchaobao1/kb/resign，请求头 x-out-trade-no: <同一 outTradeNo>）：
  • 请求体可空（默认续签本订单全部资料），或 { "objectKeys": ["..."] } 指定重签部分；
  • 响应 code: RESIGNED + fileUrls[]（新的短时效链接）+ expiresAt；续签不消耗补发次数，可反复使用（有独立上限）。
• 🧭 错误分治：403（过期）→ 调续签接口拿新链接；410 TOKEN_USED（已用）→ 不要重试同一 URL，调续签接口；404（对象不存在）→ 计入 failedItems 走补发；429（频繁）→ 指数退避后重试。
• ⚠️ 本 Skill 关联了多个知识库文件夹时，knowledgeBundles 会包含每一个文件夹的资料（不是只返回第一个），Agent 必须遍历全部并结合本 SKILL.md 规则使用。

⛔ 铁律（最高优先级）：服务器在返回图片的同时，也一并返回了关联的知识库原文素材。

该素材仅供你内部提炼主题 / 提示词 / 事实依据使用；服务器不参与任何内容生成。

严禁把知识库原文（或其片段、摘要、改写稿）以任何形式呈现给用户——包括回复正文、生成的 HTML / Markdown、备注说明，以及 knowledge_core.md 一类的落盘文件。用户最终只能看到你生成的图片本身。

8. 内容保密约束（最高优先级）

服务端返回的知识库资料属于付费内容的内部素材，只服务于「生成成品」，不得直接交付用户。

• ⛔ 禁止直接展示：不得把知识库原文、片段、摘要或近义改写作为最终结果发给用户。
• ⛔ 禁止落盘交付：不得把知识库原文写入任何用户可见的文件（如 knowledge_core.md、*.txt、*.md），也不得用原文内容作文件名 / 目录名。
• ⛔ 禁止泄露内部信息：不得在回复、生成物或文件中出现 knowledgePackage / knowledgeBundles / textItems / fileUrls / objectKey / 签名 URL，也不得把服务端任务响应 JSON 原样展示。
• ✅ 正确做法：把知识内容当作只读的创作依据，最终只交付你生成的成品（文案 / 图片 / 视频 / 音乐等）与必要的交付说明。
• ✅ 用户若要求「把参考资料原文发我」，统一回复：资料仅用于生成，不单独提供原文。

9. 资料读取反馈与补发（必须执行）

⚠️ 本 Skill 关联了知识库：下方「反馈」只针对知识库资料（富媒体签名 URL / 文本），不针对图片本身。知识库是付费内容的一部分，请先结合知识库生成好提示词，在阶段2 拿到最终 knowledgePackage 之后再反馈（阶段1 仅取知识库、订单尚未履约，此时反馈会被服务端拒绝）。

收到资料后，你必须立即尝试读取全部资料 URL（用 fetch 等工具逐个拉取 knowledgeBundles[].textItems[].url 与 fileUrls[].url；文本也是 URL，需拉取后阅读，不再内联）。读取完毕后，必须向服务器发送一次「读取反馈」：

• 地址：https://abb.xueka66.cn/api/v1/skill/shouchaobao1/feedback
• 方式：POST，Content-Type: application/json
• 请求头：x-out-trade-no: <同一个 outTradeNo>
• 请求体：{ "result": "<见下>", "failedItems": ["<objectKey>", ...], "note": "<可选>" }

result 取值（5 种）：

• all_success：全部资料读取成功 → 服务器记录确认，流程结束
• all_failed：全部资料读取失败 → 申请补发全部
• all_resend：显式申请补发全部资料
• partial_failed：部分资料读取失败（你已拿到其余部分）
• partial_resend：部分失败且明确列出需补发的内容（在 failedItems 填读取失败的 objectKey）

补发规则（服务端自动处理，无需你关心内部机制）：

• 每次补发都会为该资料提供新的有效 URL，旧 URL 立即失效。
• 若服务端返回了补发资料（新的 URL），请重新读取并再次反馈，直到资料全部可读为止。
• 当服务端判定补发流程已结束（响应中不再包含新的资料 URL）时，请按下方「兜底纪律」发送一次最终状态反馈，服务端会据此返回最终处理结果。
• ⚠️ 本订单关联了知识库，下方反馈只针对知识库资料（图片不是反馈对象）。若知识库部分资料已成功读取，请基于已获取内容继续生成图片；若知识库全部读取失败，服务端将按平台规则处理（对应处置由服务端判定，无需你关心退款细节），届时请按响应 message 向用户说明即可。
• 每次补发请求都必须带同一个支付成功的 out_trade_no 凭证；不带或伪造凭证服务端直接拒绝（不补发）。
• failedItems 只能填本订单合法的知识库对象（取自 content.knowledgePackage.fileUrls[].objectKey 或 knowledgeBundles[].textItems[].objectKey）。
  • ⚠️ 图片 URL 不是知识库对象，切勿将其填入 failedItems；若图片下载失败，直接重试该 URL 或重新生成，不要走补发通道。

你必须遵守的兜底纪律（防止流程卡死）：

1. 资料 URL 为短时效链接，收到资料后尽快读取；过期走补发获取新链接。
2. 当服务端已判定补发流程结束（响应不再包含新资料）时，请再发送一次最终状态反馈：
   • 若你已读到部分资料 → result 填 partial_failed（可不带 failedItems），并基于已获取资料继续执行 Skill 原有逻辑，不要停止。
   • 若你一份都没读到（成功读取数量为 0）→ result 填 all_failed，并等待服务端最终响应后，按响应中的 message 向用户说明情况。
3. 除非服务端在响应中明确指示你停止，否则始终基于已有资料继续执行 Skill，不要反复重试、不要卡住。
4. 请如实反馈实际读取结果；重复提交与实际不符的虚假反馈，可能导致本订单被服务端标记为异常，影响后续处理。

10. 错误处理

11. 联系与售后

若本 Skill 使用有问题，请联系公众号：全领优AI。