服装穿搭大片 Lookbook

概述

上传模特身份卡、服装配饰图与风格参考图，一次生成一整套可直接发布的服装穿搭大片。

主要功能

你给素材，它出一整套能直接发的大片。

一次交付 6 张成图，按观看节奏排好——远看气势 → 看全造型 → 看叠穿层次 → 看动势 → 贴近看脸与配饰 → 松弛收尾。输出可直接发布的成图，并附一致性自检报告与消耗明细。

它把「AI 生图」和「时尚大片」之间的差距补在哪：

• 🎞 不像 AI 图 —— 高级感来自约束：单主光、影不填平、光有动机、负空间大，不靠堆形容词
• 🧑 模特不变脸 —— 身份锚点跨图逐字复用，每张都带身份卡参考，漏带就绝不变脸
• 👔 衣服不走样 —— 造型锚点原文照抄；改一个字，衣服就在镜头之间变样
• 🚫 不越权加料 —— 只补「构成完整造型的最小必要集」，已上传的锁定项不可替换
• 📐 一套图不重样 —— 焦段、景别、观看距离、空间尺度强制拉开
• 👁 不像商品目录 —— 有「贴近的一格」，脸与配饰都看得清

不做的事：不做单件商品图（白底图 / 主图 / 卖点图 / 尺寸图 / 平铺图 / 无模特商品特写），

也不做照片转手绘插画——那是另一套镜头逻辑。

一次生成 = 一套穿搭大片

六镜头按观看节奏排列，镜头之间焦段、景别、场景、姿态强制拉开；机位由环境与服饰推导，不套固定机头：

⭐ 05 Close 是必备格，不能省：一组穿搭大片里，脸与配饰的细节只有这一格给得了。

全身交代气势、半身交代层次，两者都离得远——「贴近看」只能由中近景/特写来给。

一组没有近景的大片 = 一组看不清人和配饰的全身照。

💡 不要求每格都「带情绪」：情绪是结果、不是任务；任务是「这一格让人看到什么」，

该来的时候自己会来。为了情绪硬让模特「表演」反而假——表情随场景与光线自然发生即可。

📐 张数：默认 6 张（上面这一套）；5 / 8 张档位与选法见 references/shot-recipes.md §3。

三个核心机制

1. 模特身份锚点 —— 从 1–3 张身份卡提取 9 项特征，跨图、跨批次锁定同一张脸；每张图都带身份卡参考，不漏带就绝不变脸。
2. 素材三级权限 —— 🔒 已上传的必须全部入画，不得替换 ／ ➕ 未上传的按需补齐（补齐范围由景别决定）／ ⛔ 不需要的一律不加，不做无中生有。
3. 锚点原文照抄 —— 身份与造型锚点逐字复用，镜头之间只换摄影参数与调度；批量模式下由 segments 机制在物理上保证逐字一致，不靠人肉复制。

它是怎么做到的：四位专业角色

它不做「往提示词里加几个形容词」的事，而是把时尚摄影与造型设计的工作方法结构化，由四个角色分工协作：

再加一套调度规范（directing-guide.md）：人站在哪里、什么角度、什么视线、什么姿态。

语言规则（硬规则 · 最高优先级）⭐

凡是给用户看的文字，一律使用简体中文。 包括但不限于：

• 全过程播报：读素材、建清单、定流派、组装提示词、逐镜头提交、轮询、下载的每一步说明
• 提问与选项：AskUserQuestion 的 question、选项 label 与 description 全部中文
• 方案确认单：素材清单、流派选项与推荐理由（留用户勾选位）、镜头清单、场景与调度设计、费用——全中文
• 设备授权引导：链接说明、验证码、点击操作、有效期——必须整段中文（可直接照抄 --auth-start 返回 JSON 的 display_zh 字段）
• 交付说明：风格分析、镜头自检结果、后续建议

唯一例外（仅此两处可为英文）：

1. 写入 Qx-Image 的生图提示词（脚本 --prompt 的值）——模型对英文摄影术语更敏感；
2. 流派名与镜头名的英文代号（如 Quiet Luxury、Hero）可作为中文名称的括注出现。

除这两处外，不得对用户输出英文段落。即使宿主 AI 默认英文，也必须用中文交流。

触发场景

• 用户上传照片 / 服装图 / 模特身份卡，要求生成「高级感穿搭图」「造型图」「时尚大片」
• 提到「情绪大片」「氛围感大片」「穿搭大片」「有情绪」「要有故事感」
• 提到「lookbook」「造型画册」「品牌画册」「editorial」「大片感」「穿搭搭配」
• 提到「模特要统一」「用这个模特」「固定模特」
• 提到「造型师」「搭配设计」并希望出图
• 用户给了风格参考图或文字风格描述，想复刻那种摄影语言与调性
• 服装品牌需要成套的造型呈现（非单张电商图）

适用范围：本 Skill 面向成套穿搭呈现（lookbook / 造型画册 / editorial 大片 / 情绪大片）。

⛔ 不做单件商品图：电商平台的白底图 / 主图 / 卖点图 / 尺寸图 / 平铺图 / 无模特商品特写

属于另一套镜头逻辑（把商品信息交代清楚），不是本 Skill 的事，请改用宿主环境中对应的电商商品图技能。

本 Skill 的每一格都必须是穿在身上的造型，靠环境与观看节奏说话，而不是把单品摊开交代。

若用户要的是把实拍照片转成手绘插画，同样不属于本 Skill 范围。

关于算点边界

算点边界（token.qixuai.com）是面向 Agent 用户的算力平台 —— 统一的大模型与图像生成网关。

本 Skill 是算点边界的官方技能之一，图像生成能力由平台的 Qx-Image 模型提供，无需 API Key、设备授权一键接入。

💡 关于「积分」：本 Skill 消耗的是算点边界平台（token.qixuai.com）的生图积分，与 WorkBuddy / CodeBuddy 等宿主 AI 工具自身的额度无关。

设计规范与规则（权威核心）⭐

本 Skill 有 9 份单一事实源，出图前必须读取相关文件：

文件	管什么
references/model-identity.md	模特身份卡：跨图统一模特 + 肖像授权红线
references/photographer-playbook.md	摄影轴：焦段/机位/光形/光比/景别/构图/调色 + 禁词表
references/stylist-playbook.md	造型轴：廓形/色彩/材质/层次/配饰/妆发 + §11 素材清单三级权限
references/style-genres.md	§0 流派推荐逻辑 + 8 个内置流派 + §9 自定义流派
references/shot-recipes.md	六镜头任务配方（机位按环境推导）+ 可变镜头库 + §3 张数预案 + 镜头差异纪律
references/directing-guide.md	调度：站位 / 机位角度 / 视线 / pose 库
references/scene-director.md	场景库 / 光影设计 / 写实质感词库 / 反千篇一律机制
references/prompt-templates.md	八段组装公式 + 三档字符预算（真实上限 2000）+ --measure 度量
references/plan-schema.md	批量计划文件格式 + template 机制 + 断点续跑 + 自动裁剪

四条不可妥协

常见误判（务必避免）

工作流程

Step 1: 读素材 · 建立模特身份

先识别素材类型，三类可任意组合：

模特处理三种情形：

⚠️ 肖像授权：若使用真人身份卡，必须确认是本人 / 已获模特书面授权 / 已购商用授权素材。

方案确认单中必须有「素材授权确认」一项（详见 model-identity.md §5）。

Step 2: 登记素材清单（三级权限）⭐

按 stylist-playbook.md §11 逐件登记，标注三态：

🔒 锁定项 Locked     — 用户已上传，必须全部入画，不得替换或增减同品类第二件
➕ 可补项 Derivable  — 未上传但构成完整造型必需，由搭配设计师补，须服从锁定项风格
⛔ 禁止项 Forbidden  — 不必要 / 与风格冲突 / 用户未提，一律不加

补齐范围由镜头景别决定（stylist-playbook.md §11.3）：

能用构图规避的，不要用补充解决。 补得越多，越偏离用户意图。

Step 3: 定风格流派（推荐给你，由你选）

按 style-genres.md §0 的推荐逻辑给出选项列表，然后停下来等用户选：

1. 读素材四个维度：色彩体系 / 材质与剪裁 / 气质指向 / 穿着场合
2. 输出：A 首选流派 + 理由 ／ B、C 备选 + 与首选的差异 ／ 不推荐项 + 原因
3. 明确征询用户选择（回复 A/B/C，或自定风格），并说明未选择前不开始生成
   • 💡 宿主支持时可用 AskUserQuestion 把 A/B/C 做成可点选项（首选放第一位并在 label 末尾标「推荐」），用户点选才算选定。
4. 用户选定后，把用户选定的流派写回确认单，不要写成「推荐流派」

⚠️ 推荐 ≠ 默认值。不要自作主张按首选直接往下走，也不要说「我先按静奢风开始了」。

流派决定整组图的光线、色彩、空间与情绪，是用户该拍板的决策。

1. 用户要自定义时走 style-genres.md §9：
   • 文字描述 → 映射到七个维度（缺的用默认补齐并明示）
   • 风格参考图 → 按 §9.2 七维度逐项分析
   • 产出同构配方表（含英文基底），命名后可长期复用

Step 4: 出设计方案确认单（必须先获确认 ⭐）

不要跳过这一步直接生图。 向用户展示：

用户确认后才进入 Step 5。方案变更需重新确认；仅重试或补余额不重复确认。

⚠️ 确认单里凡是有可选项的（流派、可补项、镜头张数档位），一律让用户勾选，不要预填默认值蒙过去。

用户只回复了「确认」但没选流派时，要回去问清流派，不要替他决定。

Step 5: 授权预检

⚠️ 生图前先跑 python <skill_dir>/scripts/generate.py --check-auth（会在线校验令牌真伪）。

退出码 0 = 已授权且服务端校验通过，直接生图；3 = 未授权 / 令牌已失效（脚本会自动清理失效令牌），先走下面的设备授权。

无网络环境可加 --offline，只看本地令牌在不在。

🤖 AI 工具请用两步式授权（推荐，不会阻塞超时）：

1. 运行 python <skill_dir>/scripts/generate.py --auth-start → 先做可写性预检，再请求授权链接 + 验证码（stdout JSON，含 verify_url / user_code / device_code / display_zh / writable / token_file）。
   • 只要返回 writable: true 就放心让用户点链接。脚本会在多个候选路径里自动选一个能写的存（首选 ~/.qixuai/device_token.enc，写不进自动改存 %TEMP%qixuaidevice_token.enc）。token_file 字段即预告的实际落盘位置。
   • ⚠️ 只有返回 write_denied（退出码 7，说明所有候选路径都不可写）才需要先处置：按 suggested_token_file 加 --token-file 重跑 --auth-start，别让用户白点。
   • ⚠️ 一次授权只调用 --auth-start 一次。每调用一次都会生成新的 device_code；重复调用会让「用户授权的码」与「脚本轮询的码」错位，用户就白授权一次。
2. 用简体中文把链接和验证码展示给用户，然后停下等待用户回复（验证码约 15 分钟有效）。
   • ✅ display_zh 字段就是现成中文话术，原文转述即可。
   • 💡 verify_url 是已带验证码的一键链接，务必给完整链接。
3. 用户回复「已授权」后，把 device_code 原样传入：

python <skill_dir>/scripts/generate.py --auth-poll --device-code "<device_code>"

• 退出 0 {"status":"authorized"} → 已拿到令牌，直接生图；
• 退出 4 {"status":"pending"} → 用户还没点完「允许」。等用户确认后用同一个 device_code 再跑一次，可反复跑直到成功。这不是错误，绝不要因此重新 --auth-start。
• 退出 6 {"status":"failed"} → 先 --check-auth（会在线校验）：返回 0 说明其实已授权、直接生图。
• 退出 8 {"status":"save_failed"} → 极罕见，且授权其实已经成功，只是所有正式路径都没写进去（不是授权失败！）。按 JSON 里的 recovery_file 迁过去：

python <skill_dir>/scripts/generate.py --import-token "<recovery_file>"

用户无需重新授权。⚠️ 绝不要重新 --auth-start——device_code 已被消费，重发只会让用户白点一次。

⭐ 「授权到底成功没有」只看 --check-auth 的退出码（0 = 可用）。

它现在会同时报两个维度：local（本地有没有令牌文件）与 online（服务端是否认可这个令牌）；

输出里出现 "status":"invalid" 就说明是僵尸令牌，不要当成已授权。

而且脚本会自动收编写盘失败时暂存的令牌（%TEMP%qixuai_token_*.json），

所以用户已经点过「允许」的情况下，重跑一次就能直接用，永远不需要让用户点第二次。

🧟 什么是「僵尸令牌」：用户在算点边界控制台撤销授权后，服务端令牌已失效、本地文件却还在。

若只查本地文件，就会把它当成「已授权」——--auth-poll 秒回 {"reused":true}，

device_code 根本没被消费，用户刚点的「允许」被直接丢弃；

表现为「授权成功 → 仍然 401 → 提示失败 → 要点两三次才成功」。

✅ 本 Skill 的行为：--auth-poll 复用本机令牌前必须先在线校验；判定失效就清理僵尸令牌，

继续用你这次的 device_code 换取新令牌。--check-auth 与生图前预检同样在线校验，

401 一律自动清理本地失效令牌并返回退出码 3。

⇒ 控制台撤销后，重新授权一次就立刻生效，不需要点第二次。

💻 终端/人类一步式：python <skill_dir>/scripts/generate.py --auth --output /dev/null

🚫 令牌文件由脚本独占管理：不要用 shell 命令去手动创建 / 写入 / 删除 ~/.qixuai/device_token.enc。

手动干预会绕过回读校验，制造「报了成功其实没写成」的假象，反而让用户被反复要求授权。

路径有问题就用 --token-file 让脚本自己写到别处。

Step 6: 生成（成套一律走批量并发 ⭐）

一套 lookbook 有 6 个镜头，不要一张一张跑。 逐张模式是阻塞式的（提交 → 等到出图 → 下载 → 退出），六张要 8–10 分钟；批量模式把所有镜头一次提交、服务端并行生成，总耗时 ≈ 2–4 分钟（单张 70–100s，渠道繁忙时更慢），而且参考图只上传一次供全部镜头复用。

① 先写计划文件（格式见 references/plan-schema.md）

把身份锚点、造型锚点、流派基底写进 segments，各镜头用 template 引用：

{
  "references": ["<身份卡.jpg>", "<服装图1.jpg>", "<服装图2.jpg>"],
  "defaults": { "size": "2:3", "quality": "high", "output_dir": "<工作区>/generated-images" },
  "segments": {
    "identity": "<身份锚点，原文>",
    "styling":  "<造型锚点，原文>",
    "genre":    "<流派英文基底>",
    "realism":  "realistic skin texture, true-to-life fabric weave, natural highlight rolloff"
  },
  "shots": [
    { "name": "01-hero", "shot": "...", "directing": "...", "scene": "...",
      "template": "{identity}. {shot}. {styling}. {directing}. {genre}. {scene}. {realism}. 2:3 aspect ratio" }
  ]
}

⭐ 锚点只存在一份，逐字一致由机制保证——不靠人肉照抄六个镜头。

② 一次跑完 · 但必须在同一回合等到结果 ⭐⭐

python <skill_dir>/scripts/generate.py --plan "<plan.json>" --concurrency 6

⏱️ 预计耗时 2–4 分钟，超过宿主命令的默认超时（约 2 分钟）——必须用后台运行（run_in_background）

或显式加大超时，然后等它跑完再动。否则命令被掐断，你只看到一堆「排队中」却永远看不到结果。

🚦 回合纪律（硬规则 · 违反即失败）⭐⭐

生图是异步的：命令返回 ≠ 出图完成。禁止在结果出来之前结束回合。

❌ 不允许的收尾（一旦这么说，用户不追问就永远没有下文——你没有「下一轮」）：

• 「生成任务已提交，预计 3 分钟完成，完成后我会立刻把整套成图呈现给你」
• 「正在生成中，稍后为你呈现结果」
• 任何形式的「先结束这一轮，等下再给你」

✅ 唯一合法的两种回合收尾：

💡 什么才算跑完：脚本每 30s 打一行 [进度] x/y 已出图 · 已运行 Ns · 仍在等待——这是心跳，不代表完成。

只有 [4/4 完成] / [4/4 未完成] / [4/4 完成 · 部分失败] 这三行是终局信号，三种状态互斥、用词不同，不要读混。

逐张模式同理，终局是 [完成] 已下载到 … 或 [未完成] …。

🚫 不要用「已提交」向用户汇报进度：脚本的提交日志刻意写成「排队中」，就是因为「已提交」容易被读成「做完了」。

出图完成前，正确的播报是「6 个镜头的出图任务都在排队，正在等待结果」，而不是「已生成 / 已完成」。

参数说明

• --plan 计划文件路径（镜头、参考图、共享段落都在里面）
• --concurrency 同时运行的任务数，默认 6
• 不加任何重做参数时断点续跑：已成功的镜头自动跳过，不会重复扣积分
• --only "03-half" 单张重做（Step 7.3 用）：只重做名单内镜头，其余一律不动；绝不覆盖旧图，自动写到 -v2
• --force 全量重做：忽略 manifest 重做全部镜头（同样不覆盖，会写到 -v2）。⚠️ 会全量扣分，非必要不用
• --measure 干跑度量：打印每张字符数 + 各段贡献 + 最胖的段在哪。零积分、不需要授权
• --no-trim / --safe-limit 控制提交前的自动裁剪（默认开启、安全线 1900）
• references 自动去重，顺序约定：① 身份卡 → ② 本 look 服装配饰 → ③ 风格参考图（≤16 张，单张 ≤10MB）

写 plan 之前先跑一次度量（比事后反复压缩省事得多）：

python <skill_dir>/scripts/generate.py --plan "<plan.json>" --measure

输出每张的总长、占上限比例、每一段各占多少、是否超线。退出码 0=全在安全线内，9=有镜头超线（提醒，不是失败）。

⚠️ 提示词长度：服务端上限 2000 字符。

2001+ 会被接受后写库报 Data too long → state=error，积分照扣；

>5000 才在提交阶段 HTTP 400 免费拒绝。

所以：先 --measure 看清，--plan 会自动兜底裁剪，不要靠心算估长度、更不要反复手工压缩。

只有单张试风格时才用逐张模式：

python <skill_dir>/scripts/generate.py 
  --image "<身份卡.jpg>" --image "<服装图.jpg>" 
  --prompt "<完整提示词>" --size 2:3 --quality high 
  --output "<工作区>/generated-images/<look>-01-hero.png"

退出码：0 全成功 ／ 2 计划文件有问题 ／ 3 未授权 ／ 9 部分镜头失败（其余成功，用断点续跑补做）／ 124 尚未跑完（超时，服务端还在排队——不是失败，也绝不是「已完成」，重跑同一条命令断点续跑即可）。失败处理：401/403→重新授权；402→积分不足不扣费；state=error 里含 Data too long→提示词超 2000，跑 --measure 精简后重试。

⛔ 绝对不要向用户索要 API Key。本 skill 不内置、不接受任何 API Key（没有 --api-key 参数、不读环境变量、不复用共享凭据）。

✅ 唯一正确做法：引导用户完成算点边界账号设备授权。

Step 7: 交付 + 自检报告 → 要不要重做由用户决定（绝不擅自扣积分）⭐

7.0 积分口径（硬规则）⭐⭐

本 Skill 消耗的是「算点边界积分」——算点边界算力平台（token.qixuai.com）的生图计费单位。

它不是宿主 AI 工具（WorkBuddy / CodeBuddy / TRAE / QClaw…）自己的额度或积分。

两者互不相干：宿主工具里的额度不会因为出图而减少，这里扣的是用户算点边界账号里的积分。

因此，凡向用户报积分，一律写明「算点边界积分」（交付开场可写「算点边界生图积分」），禁止裸写「积分」「分」——那会被理解成宿主工具的额度，用户会以为「没花钱」或「扣错地方了」。

💡 首次交付时补一句说明（只第一次说，之后不必重复）：

「以上积分为算点边界平台的生图计费，与你所用 AI 工具自身的额度无关。」

7.1 先交付成品，再报自检

第一步必须把整套图一次性呈现给用户（present_files），让用户先看到成品；然后再附自检报告。报告只负责「指出风险」，不替用户下结论。

开场第一句必须明确「已完成」（固定句式，数字按 manifest 实际值替换）：

整套图已生成完成，共 6 张，本次消耗 60 算点边界积分（累计 128 算点边界积分），耗时 3 分 12 秒。

（以上积分为算点边界平台 token.qixuai.com 的生图计费，与你所用 AI 工具自身的额度无关。首次交付时补这一句，之后不必重复。）

⚠️ 不要用「已提交」「预计完成」「有结果再给你」这类未完成语气开场 —— 交付就交付，没交付就直说没交付（见 Step 6 回合纪律）。交给用户的第一句话必须让他知道图已经在这儿了。

按 shot-recipes.md §5 逐项核对（身份锚点 / 造型锚点 / 素材清单 / 妆发调色写实模块 / 摄影参数是否在变），重点：

• [ ] 身份锚点逐字一致，且每张都带身份卡参考图
• [ ] 造型锚点逐字一致
• [ ] 素材清单：锁定项全部出现，无越权添加
• [ ] 妆发 / 调色 / 写实模块一致
• [ ] 只有摄影参数、调度、场景在变

自检报告格式（全中文）：

7.2 停下来问用户 ⭐（硬性停顿）

⚠️ 发现不一致时绝对不要自动重做。 重做会再扣算点边界积分，必须由用户决定。

❌ 反例：「发现 03 偏色，已重做这一张，共消耗 70 算点边界积分」——擅自替用户花钱。

把「建议确认的镜头」交给用户，并明确写清三件事：

1. 每张重做大约再扣多少算点边界积分（含首次消耗与重做后累计）
2. 用户可以只挑其中几张重做，也可以全部保持现状（成品已满足需求就不必再花钱）
3. 需要调整的话，请用户给出方向（换场景 / 改姿态 / 调颜色 / 收紧某个词）

宿主支持可点选时用 AskUserQuestion，选项示例：

7.3 重做不覆盖原图，另存新文件 ⭐

用户确认要重做后再执行。原图必须原样保留，重做结果另存一张，方便新旧对比：

# 推荐：只重做名单内的镜头，其余完全不动
python <skill_dir>/scripts/generate.py --plan "<plan.json>" --only "03-half"
# 多张：--only "01-hero,03-half"

• --only 名单外的镜头一律不动（不会重跑、不会扣分）；名单内的镜头即使 manifest 显示已完成也会重做
• 脚本保证不覆盖：目标文件已存在时自动改写到 03-half-v2.png、-v3.png……旧图永远保留
• 逐张模式同理：--output 指向已存在的文件时，自动写到 -v2
• manifest 会与上一版合并（不丢其他镜头记录），并额外给出 points_this_run（本次重做消耗）
• 交付时把新旧两版一起呈现，让用户自己挑

7.4 交付物

1. 全套成图（present_files 一次性呈现；有重做则新旧版本一起给）
2. 中文说明：造型主张、流派与理由、身份与造型锚点、每张镜头名/任务/场景/调度
3. 自检报告：哪些一次通过、哪些建议确认、依据哪条规范
4. 算点边界积分与耗时：首次消耗 + 本次重做消耗 + 累计（读 manifest 的 points_this_run / points_total；报给用户时一律写成「算点边界积分」，不要裸写「积分」），耗时读 elapsed_seconds

只出提示词模式（不生成图片）

用户若明确说「只要提示词」「先给方案不出图」「我要提示词」——只交付提示词，不调用生图脚本、不出图。

输出格式：

若用户既要提示词、又希望拿到后能直接跑 → 直接产出 plan.json（格式见 references/plan-schema.md），用户一条命令就能出整套图。这是最推荐的交付形态。

并附上共享的身份锚点、造型锚点、流派基底段落，方便用户自行复用或投喂其他平台。

常见问题处理

• 「发现不一致就自己重做了」 ❌：重做会再扣算点边界积分，不能替用户决定。→ 先交付成品 + 自检报告，用 AskUserQuestion 问用户要不要重做、重做哪几张（Step 7.2）；用户说不用就别重做。
• 报积分时裸写「积分」，用户误以为是宿主 AI 工具的额度 ❌⭐：本 Skill 扣的是算点边界平台（token.qixuai.com）的生图积分，与 WorkBuddy / CodeBuddy / TRAE 等工具自身的额度完全无关（宿主额度不会因为出图而减少）。→ 一律写「算点边界积分」；首次交付补一句「以上积分为算点边界平台的生图计费，与你所用 AI 工具自身的额度无关」。见 Step 7.0。
• 「说了完成后会呈现，结果一直没下文」 ❌⭐：生图是异步的，命令返回 ≠ 出图完成。→ 必须在同一回合内等到终局信号（[4/4 完成]）再交付；若超时（退出码 124）就如实说「现在还没跑完」并给断点续跑命令。绝不允许用「完成后我会呈现」结束回合（Step 6 回合纪律）。
• 把「排队中」当成「已生成」 ❌：脚本提交日志写的是「排队中」，[进度] 心跳只代表还在等。→ 只有 [4/4 完成] 是完成，[4/4 未完成] / [4/4 完成 · 部分失败] 都必须如实告知用户「还没出全」。
• 重做把原图覆盖了 ❌：会让用户没法对比。→ 用 --only "<镜头名>"，脚本会自动写到 -v2/-v3，永远不覆盖；交付时新旧两版一起给（Step 7.3）。
• 模特在镜头间变脸：身份锚点漏写，或该张漏带身份卡参考图。→ 锚点原文照抄 + 每张都传身份卡图。
• 多出没上传的配饰 / 换了用户的裤子：造型越权。→ 按 stylist-playbook.md §11 重新登记清单，锁定项神圣不可改。
• 只上传上衣，裤子怎么办：属于「可补项」，由搭配设计师按上衣风格设计下装（全身镜头还需补鞋）；半身镜头则不必补鞋。
• 六张图像同一张：镜头差异不足。→ 按 shot-recipes.md §4 拉大焦段（35/50/85）与景别（全身/七分或半身/中近景）差距，并拉开调度与场景。
• 03 Half 与 05 Close 看起来像同款：两张都是 85mm 且都含上半身，最容易撞。→ 03 必须 waist-up 半身、普通浅景深；05 必须 medium close-up 中近景/特写、极浅景深 + 明确表情指令（见 shot-recipes.md §1-05）。
• 一组图「平」，看着像商品目录：缺贴近的一格、六格观看距离全一样。→ 序列里必须有 05 Close 这样一格近景/特写，且六格的观看距离 ≥3 档、空间尺度 ≥2 种（shot-recipes.md §4）。
• 动态镜头跑偏成「同框多动作」或糊掉：04 Dynamic 只抓一个瞬间。→ 提示词里必须带三句负向约束 single moment / no multiple exposure / no duplicated subject；动作感靠姿态与低机位，不靠模糊。想专门展示面料流动，按需追加 Flow（长曝光拖影，见 shot-recipes.md §2）。
• 场景千篇一律：→ 按 scene-director.md §5 轮换七维变量；同批次至少 3 个变量不同。
• 人物面部不够清晰（远景/全身里脸糊成一团、认不出是同一个人）⭐：几格离得远时脸只占几十分之一，模型容易敷衍。→ ① 全身/远景加面部清晰短语 features clearly readable even at full-body distance, face lit；② 脸别落进阴影，主光要照顾到面部；③ 每格都要有眼神光 sharp focus on the eyes with a catchlight；④ 05 Close 必须带完整面部模块。见 scene-director.md §4.4。
• 配饰落位不合理（眼镜该戴在脸上却被别在衣服上、丝巾没系、胸针飘空）⭐：参考图大多是平放的商品图，模型自己猜不准。→ 参考图里有佩戴方式的一律照参考图；没有的按 stylist-playbook.md §12.3 默认落位表取（眼镜→戴上／别在领口，需明写）；每件配饰的落位必须写进造型锚点逐字一致；看不见的配饰不要写进该格（免得被挪到脸上）。
• 六格像一套固定机头、没有空间感与呼吸感 ⭐：机位被当成配方照抄了。→ 机位要由环境与服饰推导（directing-guide.md §8 有环境→机位对照表）；每格留足负空间与进深线索，别把画面塞满（photographer-playbook.md §5.1/§5.2、shot-recipes.md §0 原则 3）。
• 环境像贴了一块背景板 / 塑料感：缺写实模块或场景描述太笼统。→ 按 scene-director.md §4.3 拼三段写实模块（基础 + 环境 + 面部），并给墙面/地面/家具加真实材质与使用痕迹、给人与家具加接地影。
• 画面塑料感 / AI 味：缺写实模块，或光被填平。→ 加 realistic skin texture, true-to-life fabric weave, natural highlight rolloff，恢复 2:1 光比。
• 用户要「8K 超写实」：不要真的写 8k（无效标签）。→ 按 scene-director.md §4 换成有效的写实词族，并说明为什么。
• 用户给了风格参考图：走 style-genres.md §9 自定义流派流程，按七维度逐项分析后产出配方表，不要直接照抄人家的画面。
• 画面发灰发闷：低饱和 + 低光比叠加。→ 恢复光比，饱和度只降 10–15%。
• 姿态僵硬：调度里只写了站位没写动作。→ 按 directing-guide.md §4 补具体动作。
• state=error：看描述里的关键词判断——
  • 含 Data too long for column 'prompt_text' → 提示词超 2000 字符（服务端落库截断）。⚠️ 这类失败积分照扣。→ 跑 --measure 看哪段最胖，精简后重试；--plan 默认已自动裁剪，正常不该再出现。
  • 其他 → 按 prompt-templates.md §6 对照排查。
• 写 plan 时在反复手工压缩提示词：立刻停手——上限是 2000 字符，余量充足。先跑 --measure 一次看清全部镜头长度，再让 --plan 自动兜底裁剪。
• 未授权 / 令牌失效：先 --check-auth（在线校验）；未授权用 --auth-start + --auth-poll（AI 工具）或 --auth（终端）。不要向用户索要 API Key。
• 「刚授权，下一步又要重新授权」：若 --auth-poll 返回 pending（退出码 4），这不是错误——等用户点完「允许」，用同一个 device_code 再跑一次即可。千万不要重新 --auth-start。
• 🧟 「在控制台撤销授权后，重新授权了还是 401 / 要点两三次才成功」：这是僵尸令牌——服务端已失效、本地文件还在。若只查本地文件就会返回 reused:true，device_code 没被消费，用户的「允许」被丢弃。

→ 脚本会在复用前在线校验、401 自动清理僵尸令牌并继续兑换；你只需照常走一次授权即可。→ 若仍遇到，按序排查：① --check-auth 看 online 是否为 false（是则本地令牌是僵尸，脚本会自动清）；② --check-auth 返回 0 就直接生图；③ --auth-poll 报 save_failed（退出码 8）→ 用 --import-token "<recovery_file>"，不要重新发码；④ 只有 --auth-start 报 write_denied（所有路径都不可写）才需要 --token-file。

• --check-auth 输出怎么读 ⭐：{"local":…, "online":…} 两个维度——local=true, online=false = 僵尸令牌（已自动清理）；local=false = 从没授权过；两者皆 true 才是真可用。expires_at 为 null 表示不设本地过期（正常，有效性以在线校验为准）。
• ⚠️ 403 不等于令牌失效：设备密钥调 /v1/models 本来就返回 403 insufficient_scope，脚本据此判定「有效」。只有 401 才判失效——不要因为看到 403 就让用户重新授权。
• 确认授权没成功：不要反复 --auth-start。判断授权状态只看 --check-auth；save_failed ≠ 授权失败，重发码只会让用户白点一次。
• 怀疑「沙箱写不了 ~/.qixuai」：不要自己 mkdir、测写入、手动抢救令牌——令牌文件由脚本独占管理。脚本已内置多路径降级与自动收编，手动干预只会绕过回读校验、制造「报成功其实没写成」的假象。
• 想知道环境会不会出问题：跑 --check-auth——它会报告实际令牌路径、在线校验结果与本地过期时间；未授权时还会给出可写性诊断与处置建议。
• 不小心用英文给用户讲流程：违反「语言规则」。用户可见文字必须简体中文。

前置配置（一次性鉴权 · 强制算点边界授权）

本 skill 不内置、不接受任何 API Key：没有 --api-key 参数、不读环境变量、不复用共享凭据。所有生图都强制走算点边界账号的设备授权（RFC 8628）——这是算点边界平台引流与曝光的核心设计，确保每一个使用本 skill 的用户都会成为算点边界账号用户、消耗平台算力。

令牌经 DPAPI 加密存于 ~/.qixuai/device_token.enc，之后所有调用自动复用。

授权方式一：两步式（🤖 AI 工具推荐）

# 第 1 步：请求授权码并立即返回（不阻塞、不写文件）
python scripts/generate.py --auth-start
#   → stdout JSON 含 verify_url / user_code / device_code / display_zh
#     用【简体中文】把 display_zh 原样展示给用户

# 第 2 步：用户回复「已授权」后，把 device_code 原样传入
python scripts/generate.py --auth-poll --device-code "<上一步的 device_code>"
#   → 退出 0 = authorized  → 直接生图
#   → 退出 4 = pending     → 等用户确认后用【同一个 device_code】再跑一次
#   → 退出 6 = failed      → 先 --check-auth 复核再决定是否重来

⚠️ device_code（长串、无连字符）= --auth-poll 用的机器码；user_code（短码、含连字符，如 9DFG-HWU3）= 给用户看的码。第 2 步只能传 device_code，传错会报 invalid_grant。

⏱️ --auth-poll 是短轮询（默认最多 30s）、绝不长阻塞，因此不会被 AI 工具的命令超时掐断。

🚫 一次授权只调一次 --auth-start。

授权方式二：一步式（💻 终端 / 人类）

python scripts/generate.py --auth --output /dev/null

预检

python scripts/generate.py --check-auth            # 0=已授权且在线校验通过  3=未授权/令牌已失效
python scripts/generate.py --check-auth --offline  # 无网络时：只看本地令牌在不在
# 输出 JSON 含 local（本地有无令牌）/ online（服务端是否认可）/ token_file / expires_at
# 判定失效时会自动清理本地「僵尸令牌」，并给出重新授权指引

令牌存储位置（多路径自动降级 ⭐）

令牌不需要手动指定路径。脚本按顺序自动找可写位置：

• 写入：③ 失败自动降到 ④，任一成功即算成功 —— 「写不进首选路径」不再退化成「授权失败」。
• 读取：③ → ④ 任一存在即用；都没有则自动收编 qixuai_token_*.json 暂存令牌（未过期即导入并清理）。
• 想知道令牌实际在哪：跑 --check-auth，输出的 token_file 就是真实位置。

💡 有些宿主（AI 工具沙箱）会拦截对 ~/.qixuai 的写入，此时令牌会落到 ④，功能完全不受影响。

令牌有效性以「在线校验」为准 ⭐

• 平台 /oauth/token 不返回 expires_in，因此不设本地过期（expires_at: null）——

有效性一律由 probe_token_online() 在线判定。服务端若确实下发了 expires_in，则照用其值。

• ⚠️ 本地时间戳不作为「令牌失效」的依据，避免出现「令牌其实还有效、却被本机判成过期而被迫重新授权」。
• 在线探针 = GET /v1/models：免费、不扣积分。

200/403 → 有效（设备密钥范围不含 models:read，返回 403 属正常）；401 → 已失效。⚠️ 只有 401 才算失效，403 绝不当成失效去删令牌。

令牌抢救（save_failed 后 · 极罕见）

python scripts/generate.py --import-token "<recovery_file>"

无需用户重新授权，直接迁移令牌并做回读校验。正常情况下用不到：脚本会在读取时自动收编暂存文件。

API 契约

鉴权 Authorization: Bearer <token>；上传 POST /v1/images/uploads（multipart，字段 file，≤10MB）；生图 POST /v1/images/generations?async=true（model Qx-Image）；轮询 GET /v1/tasks/{id}（5s）；设备授权 POST /oauth/device/code + POST /oauth/token。