L2-01：多后端AI图片生成 —— 统一抽象层设计

🎯 学什么：如何设计一个优雅支持 5+ 个 AI 图片后端的 Skill——一套统一参数 + 一个后端映射表 = 用户无需关心底层 API（API：程序间通信接口） 差异。核心洞察：用户只需要说「需求」，Skill 负责翻译成各后端的「方言」。 💡 难易度：⭐⭐ | ⏱️ 预计时间：45 分钟 ⚠️ 此 Skill 已被 baoyu-imagine 取代，但它是理解「多后端抽象」设计模式的最佳教材。

---

1. 课程概览

💡 白话小课堂：你有 5 个不同的 AI 画师——DALL-E、Stability、Imagen……每个画师听指令的方式完全不一样：有的需要你说「画布宽度1024高度1024」，有的需要你说「尺寸1:1」。这个 Skill 就像一个万能翻译官——你说人话（「我要一张 1024x1024 的写实风格猫片」），它负责翻译成每个画师能听懂的方言。

本课的独特定位——多后端抽象设计模式：

🔑 核心秘诀：多后端抽象的核心思想只有一句话——用户只需记住一套参数（prompt（Prompt：给 AI 的输入指令）、size、style、quality），剩下的翻译工作 Skill 帮你搞定。这不仅是减少用户负担，更是一个「可扩展性」设计：新增第 6 个后端只需在映射表加一行，用户完全无感知。

⚠️ 避坑指南：很多新手把 API 密钥直接写在配置文件里（EXTEND.md），然后不小心提交到 GitHub（GitHub：代码托管平台）——爬虫几分钟内就能抓取密钥，一夜之间账单几千块。安全边界铁律：EXTEND.md = 偏好配置，环境变量 = 密钥。两者永远不能混。

---

2. 多后端挑战详解 —— 为什么同一需求要说三遍？

2.1 参数差异全景

不同 AI 图片 API 对同一个概念（「方形的图」）有完全不同的表达方式：

🔑 设计要点：这张表不只列出差异，更揭示了统一的可能——虽然参数名和格式不同，但语义是相同的：每个后端都有「尺寸」「质量」「风格」这三个概念，只是表达方式不同。统一抽象就是找出这些语义等价并建立映射。

2.2 不只是参数名不同——参数值的转换也复杂

问题：用户说「我想要一张高质量的方形图」
  
DALL-E 需要你说：    size="1024x1024"（只有一个尺寸，没有质量参数）
Stability 需要你说：  width=1024, height=1024, steps=40（steps 越高越精细）
Imagen 需要你说：     aspectRatio="1:1", sampleCount=4（sampleCount=4 取最佳）
  
三种「方言」，一个意思。

更复杂的是——有些后端根本不支持某些语义：

OpenAI DALL-E 没有「风格预设」概念 → Skill 不能把 style_preset 传给 DALL-E
Imagen 不支持「负向提示词」(negative prompt) → Skill 不能把 negative_prompt 传给 Imagen
  
→ 抽象层需要知道每个后端「能做什么」和「不能做什么」
→ 不能做的参数 → 静默忽略，而不是报错

🔑 核心洞察：统一抽象层不是简单的「参数名替换」——它需要三样东西：(1) 参数名映射（size → width+height / aspectRatio）；(2) 值转换（"1024x1024" → "1:1"）；(3) 能力矩阵（每个后端支持哪些参数，不支持的就跳过）。

---

3. 统一抽象层设计 —— 三层架构详解

3.1 为什么要三层而不是两层？

两层架构（过度简化）：
  User Input → [翻译层] → Backend API
  问题：翻译层 = 一堆 if-else——每加一个后端，翻译函数膨胀一次
  → 3 个后端还好，10 个后端就是意大利面代码

三层架构（本 Skill 的选择）：
  User Input (统一参数) → [参数标准化] → [后端映射] → [API 调用]
                           Layer 1        Layer 2       Layer 3

3.2 Layer 1：参数标准化 —— 用户说的「人话」→ 统一参数

用户输入（自然语言或结构化参数）：
  "画一张猫的写实照片，方形，高质量"

↓ 标准化 ↓

统一参数对象：
{
  "prompt": "一只猫的写实照片",
  "size": "1024x1024",         // 统一尺寸格式（WxH）
  "quality": "high",            // 统一质量等级（low / medium / high）
  "style": "photorealistic",   // 统一风格名称
  "model": "dall-e-3"          // 用户偏好或自动选择
}

标准化规则：

• 尺寸统一为 WxH 格式（如 1024x1024、1792x1024）
• 质量统一为三个等级：low / medium / high
• 风格统一为一组预定义值：photorealistic、illustration、watercolor、flat-vector 等
• 如果没有指定 model → 使用 default_model（从 EXTEND.md 读取）

3.3 Layer 2：后端映射 —— 统一参数 → 后端专用参数

这是整个 Skill 的核心——Backend Mapping 表：

Backend Mapping Table（概念上的设计）：

┌──────────────┬──────────────┬──────────────┬──────────────┐
│ 统一参数      │ DALL-E 3     │ Stability SD │ Imagen 3     │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ size:        │ size:        │ width: W     │ aspectRatio: │
│ "1024x1024"  │ "1024x1024"  │ height: H    │ "1:1"        │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ quality:     │ （不支持）    │ steps:       │ sampleCount: │
│ "high"       │ 使用默认值    │ high→40      │ high→4       │
│              │              │ med→25       │ med→2        │
│              │              │ low→15       │ low→1        │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ style:       │ （不支持）    │ style_preset:│ （不支持）    │
│ "photoreal"  │ prompt 中加   │ "photographic"│ 静默跳过     │
│              │ "photo" 前缀  │              │              │
└──────────────┴──────────────┴──────────────┴──────────────┘

🔑 设计要点：注意 DALL-E 和 Imagen 都「不支持」style 参数——但处理方式不同。DALL-E 迂回处理（在 prompt 中加描述），Imagen 静默跳过（不给不支持的参数）。这是映射表设计的关键细节：不仅要映射「怎么传」，还要处理「不支持时怎么办」。

3.4 Layer 3：API 调用 —— 生成最终请求

统一：
  所有后端通过同一个调用接口发出请求
  返回结果统一标准化（URL 或 Base64）
  错误处理统一（区分「参数错误」「认证错误」「速率限制」）

3.5 新增一个后端的操作步骤

这是三层架构的核心优势——新增后端非常轻量：

新增 Midjourney API 后端只需两步：

Step 1：在 Backend Mapping 表中加一行
  midjourney:
    size: 转换为 --ar 1:1（从 "1024x1024" 推算宽高比）
    quality: 转换为 --q 0.5/1/2
    style: 转换为 --style 参数

Step 2：在 API 调用层加一个后端适配器
  MidjourneyAdapter:
    认证方式：API key
    调用格式：POST /v1/imagine {...}
    响应格式：{ "taskId": "..." }（异步返回，需要轮询）

用户完全无感知——他们仍然说「我要一张 1024x1024 的写实风格猫片」。

🔑 设计要点：三层架构的核心价值在「可扩展性」——新增后端不影响 Layer 1（用户接口），只改 Layer 2（映射表）+ Layer 3（适配器）。用户接口稳定 = 学习成本恒定。

---

4. 安全边界设计 —— 为什么 EXTEND.md 不能存密钥

4.1 两类配置的天然边界

Skill 有两类配置需求，它们的安全等级完全不同：

4.2 为什么 EXTEND.md 绝对不能放密钥？

EXTEND.md 的特征：
  → 它是 Skill 目录下的普通文本文件
  → 可能被 git add 然后 git push 到公开仓库
  → 可能被通过分享 Skill 给别人而一起传出去
  → AI 读取 SKILL.md 时会一并读取 EXTEND.md

环境变量的特征：
  → 操作系统级别隔离
  → 不会进入 git 仓库（.gitignore 默认排除）
  → 不会被 Skill 分享给他人
  → 进程间隔离

最坏情况推演：
  Developer 把 OPENAI_API_KEY 写在 EXTEND.md → git push 到 GitHub
  → 5 分钟内，GitHub 爬虫扫描到 API key
  → 攻击者用它调用 GPT-4 生成内容 / 挖矿
  → 一觉醒来，账单 $3,000+
  → API 服务商检测到异常，封号
  → 正常业务中断

4.3 安全边界的最佳实践

EXTEND.md 里放什么：
  ✅ default_model: "dall-e-3"
  ✅ default_size: "1024x1024"
  ✅ default_quality: "high"
  ✅ preferred_style: "photorealistic"
  ✅ max_images_per_batch: 5

EXTEND.md 里不放什么：
  ❌ api_key: "sk-abc123..."
  ❌ openai_api_key: "..."
  ❌ any_credentials: "..."

环境变量里放什么：
  export OPENAI_API_KEY="sk-..."
  export GOOGLE_API_KEY="..."
  export STABILITY_API_KEY="..."

🔑 设计要点：这个安全边界不是「建议」，而是 Skill 设计的硬性规则。任何涉及第三方 API 的 Skill（图片、翻译、语音、AI 对话）都必须遵循。把它写进 SKILL.md 让 AI 知道——如果有人把密钥放进 EXTEND.md，AI 应该主动警告。

4.4 default_model —— 偏好管理的核心

多后端 Skill 最容易被忽略的设计是「让用户设一次偏好后就不再需要每次选择」：

没有 default_model：
  → 每次用户说「生成一张图」→ AI 问「用哪个模型？」
  → 用户每次都要回答「DALL-E 3」
  → 10 次生成 = 10 次重复选择
  → 用户觉得这个 Skill 很啰嗦

有 default_model：
  → 用户在 EXTEND.md 设 default_model: "dall-e-3"
  → 每次用户说「生成一张图」→ 自动用 DALL-E 3
  → 除非用户明确说「用 Imagen 生成」
  → 10 次生成 = 0 次重复选择
  → 用户觉得这个 Skill 很省心

🔑 设计要点：这和 L1-08 的 EXTEND.md 偏好管理是同一个设计模式——default_model 让用户「一次配置、永久生效」。核心逻辑：用户不应该为每次使用重复做相同的选择。

---

5. 结构拆解：多后端抽象型 Skill 模板

从 L2-01 提取「多后端抽象型」Skill 的通用模板：

什么时候用多后端抽象型？ → 当同一功能有多个第三方服务可选时：AI 对话（OpenAI / Anthropic / Google）、翻译（DeepL / Google / OpenAI）、语音（ElevenLabs / Azure / Google）——任何需要「一套接口对接多个后端」的场景。

多后端抽象型与 Level 1 模式的对比：

---

6. 电商案例：多平台商品主图统一风格生成

🛒 实战案例：某家居生活品牌在淘宝、拼多多、抖音三个渠道同时销售同一批 150 款新品，每个平台对主图尺寸要求完全不同——淘宝 800×800（1:1 白底图）、拼多多 750×352（长条横幅）、抖音 3:4 竖版（1080×1440）。传统做法：摄影师拍一套白底图，设计师手动裁切适配 3 个平台 × 150 款 = 450 次操作。设计外包报价 ¥12,000，排期 10 天。

用多后端抽象 Skill 统一生成：

平台	需求尺寸	后端选择	为什么
淘宝	800×800 白底	DALL-E 3	产品材质还原度最高，白底干净
拼多多	750×352 场景横幅	Stability AI	场景图风格预设丰富，性价比高
抖音	1080×1440 竖版带文案	Google Imagen	竖版构图自然，文字渲染清晰

统一参数入口：运营只需输入「产品名 + 品类 + 一张参考图」，Skill 根据平台自动选后端、调尺寸、统一风格。150 个产品 × 3 个平台 = 450 张图，统一参数驱动，零手动适配。

效果：

• 生成时间：450 张图从设计外包 10 天 → 6 小时（含人工抽检）

• 成本：设计外包 ¥12,000 → API 费用约 ¥240（平均 $0.035/张 × 450）

• 风格一致性：三个平台主图色调统一（同一套色彩参数驱动），品牌识别度提升

• 拼多多主图点击率从 3.6% → 5.2%（场景横幅比白底产品图点击率高 44%）

• 抖音商品卡曝光-点击率从 2.1% → 4.0%（3:4 竖版图在信息流中更抓眼）

🔑 启示：多后端抽象不只是「兼容多个 API」——它是「同一批产品用一套参数同时产出适配不同平台的视觉资产」。运营不需要知道 DALL-E vs Stability vs Imagen 的区别，只需要说「我要这批新品上三个渠道」，Skill 自动把 150 个产品的尺寸、风格、后端全部路由到位。

---

7. 动手实践

设计一个「多 LLM 对话」Skill multi-llm-chat：

• 支持 OpenAI / Anthropic / Google / OpenRouter 4 个后端
• 统一参数：prompt、max_tokens、temperature、system_prompt
• 内部映射每个后端的参数名和格式

💡 提示：想想 4 个后端各自有哪些参数名不一样？OpenAI 用 max_tokens，Anthropic 用 max_tokens（一样），但 Google Gemini 用 maxOutputTokens——这就是需要映射的地方。

---

8. 掌握检验

Q1：多后端抽象的核心价值是什么？

• A) 通过批量调用多个后端来加速图片生成
• B) 用户只需记住一套统一参数，Skill 内部负责翻译成各后端专用格式
• C) 将多个后端的图片拼接成一张大图
• D) 自动比较多个后端的图片质量并只保留最好的

Q2：为什么 API key 应该放环境变量而不是 EXTEND.md？

• A) 环境变量读取速度更快
• B) EXTEND.md 有文件大小限制
• C) EXTEND.md 可能被 git 提交或分享而泄露，环境变量是系统级隔离
• D) 环境变量原生支持加密存储

Q3：default_model 解决的核心问题是什么？

• A) 降低 API 调用成本
• B) 用户设一次偏好后无需每次手动选模型
• C) 保证所有图片使用相同的分辨率
• D) 自动绕过 API 速率限制

Q4：下表中，Google Imagen 的尺寸参数在统一抽象中会被映射成什么？

• A) Skill 会让用户分别填写 width 和 height
• B) Skill 会让用户选择一个 aspectRatio 值
• C) 用户统一填 size: 1024x1024，Skill 内部把它转成 aspectRatio: "1:1"
• D) Skill 不支持 Google Imagen，只用 DALL-E

Q5：假如你要给这个 Skill 新增第 6 个后端（如 Midjourney API），你需要做哪两件事？用户会感知到变化吗？为什么？

Q6：课程中提到安全边界是「EXTEND.md = 偏好配置，环境变量 = 密钥」。请解释：

• EXTEND.md 里应该放什么类型的配置？
• 如果开发者把密钥错放到 EXTEND.md 里并提交到 GitHub，最坏会发生什么？

---

9. 答案

点击查看答案

Q1：B — 多后端抽象的核心价值是「用户说人话，Skill 做翻译」。用户只需了解 prompt、size、style、quality 一套参数，Skill 内部自动映射到不同后端的参数名和格式。这也意味着维护 1 个 Skill 而非 5 个。

Q2：C — EXTEND.md 可能被 git 提交、分享给他人、或被 AI 读取；环境变量是操作系统级别隔离的，不会被意外泄露到代码仓库。这是「安全边界」的核心设计。

Q3：B — 多后端 Skill 的常见错误是每次都让用户选模型。default_model 让用户设一次偏好（比如「我主要用 DALL-E 3」），之后全自动，无需每次重复选择。

Q4：C — 这正是统一抽象的核心：用户只需要说 size: 1024x1024，Skill 内部根据后端不同自动翻译——对 DALL-E 保持 "1024x1024"，对 Stability 拆成 width=1024, height=1024，对 Google Imagen 换算为 aspectRatio: "1:1"。

Q5：需要在 Backend Mapping 层做两件事：(1) 定义新后端的 provider 名称和 api_key 引用；(2) 在映射表中添加一行，把统一参数（size、style、quality）翻译成新后端的专用格式。用户完全无感知——他们仍然只说「我要一张 1024x1024 的写实风格猫片」，Skill 内部判断最优后端并自动翻译参数。

Q6：EXTEND.md 应存放偏好配置（如 default_model、default_size、default_quality 等用户偏好），而非密钥。如果把密钥提交到 GitHub：(1) 爬虫会在几分钟内抓取到密钥；(2) 攻击者可以用它调用 API 挖矿或生成内容，一夜之间账单可能高达数千元；(3) 对应的 API 服务商检测到异常后会封号，影响正常业务。

（5/6 通过）

---

10. 延伸阅读

• [[L2-02-智能图表生成|下一课：AI图表一键生成]] — 双模 Skill 设计模式
• [[L1-12-AI图片生成|L1-12：AI图片生成]] — 回顾 Prompt 七要素公式（单后端场景）
• [[L1-05-封面图智能生成|L1-05：封面图生成]] — 回顾 AI 生成型 Skill 的三条铁律