L1-05：文章封面图生成 —— 给你的文章穿上漂亮的外套

🎯 学什么：从「索取型 API（API/应用程序接口：让不同软件之间互相通信的"插座"，调用它就能使用外部服务功能）」到「生成型 API」的范式转换——学会设计需要「预览→确认→迭代」的 AI 生成型 Skill。这是四种核心架构（工具型→流水线型→API桥接型→AI生成型）的最后一环。 💡 难易度：⭐⭐ | ⏱️ 预计时间：45 分钟

---

1. 课程概览

💡 白话小课堂：上一课（L1-04）扒 YouTube 字幕是「索取已有的数据」——字幕本来就存在，你只是把它拿过来。这一课生成封面图是「创造新数据」——这张图之前根本不存在，是 AI 从零画出来的。索取型 API 的结果是确定的，拿到就是拿到了。生成型 API 的结果是不确定的——同一段 prompt 生成三次，会出三张不同的图。

四种核心架构全对比——L1-05 是这一系列的最后一块拼图：

⚠️ 避坑指南：不要让用户记住各平台尺寸数字（公众号 900×500、小红书 1080×1440、Twitter 1600×900……）。Skill 应内置平台规范，用户只需说「给这篇博客生成封面」，尺寸是 Skill 的事。

🔑 核心秘诀：生成型 Skill 的三条铁律——Prompt 落文件（可审查）、生成后预览（用户确认）、支持迭代（不满意就改）。这三条铁律不是可有可无的「好习惯」，而是因为生成结果不可预测，必须用流程兜底。

---

2. 索取型 vs 生成型：范式转换详解

这是 L1-05 最核心的认知升级。两种 API 的差异不只是「数据源不同」，而是整个 Skill 的设计逻辑都不同。

2.1 结果确定性的差异

索取型 API（L1-04 YouTube 字幕）：
  输入：https://youtube.com/watch?v=xxx
  输出：每次都是同一份字幕文本
  流程：调脚本 → 拿结果 → 完成
  信任模型：信任脚本（脚本不出错，结果就是对的）

生成型 API（L1-05 封面图）：
  输入：「给这篇关于理财的文章生成封面」
  输出：每次都是一张不同的图（同一段 prompt 生成三次 = 三张不同的图）
  流程：调 API → 预览 → 用户判断 → 不满意？调整 → 重新生成 → 再预览 → ...
  信任模型：不信任 AI（结果不可预测，必须人类把关）

🔑 一句话总结：索取型 Skill 的终点是「拿到数据」；生成型 Skill 的终点是「用户满意」。

2.2 设计逻辑的连锁反应

因为结果不确定，生成型 Skill 的每个设计决策都围绕「如何让不确定的结果变得可控」：

2.3 五维参数系统

baoyu-cover-image 用 5 个维度控制封面图的视觉风格：

🔑 设计要点：注意每个维度的默认值都是 auto 或一个中庸选项——不是开发者随便写的。auto 意味着「AI 会根据文章内容智能选择」，用户不需要懂 Type/Palette/Rendering 这些专业概念。title-only 作为 Text 默认值是因为「封面放标题」是最常见需求。如果默认是 none（无文字），大部分用户反而需要每次手动加。

风格放 EXTEND.md，参数放命令行——决策边界：

EXTEND.md（持久偏好，设一次用终身）：
  ✓ preferred_type: "minimal"        ← 「我一直喜欢极简风」
  ✓ preferred_palette: "warm"        ← 「品牌色是暖色调」
  ✓ quick_mode: true                 ← 「不要每次都问我，直接生成」

命令行参数（每次不同，临时覆盖）：
  ✓ --aspect 1:1                     ← 「这次要发Instagram，用方形」
  ✓ --text none                      ← 「这张不要文字，纯视觉」
  ✓ --ref photo.jpg                  ← 「参考这张图的配色」

🔑 决策原则：高频不变 → EXTEND.md（不浪费交互次数），低频可变 → 命令行参数（保留灵活度）。

---

3. 三条铁律详解

生成型 Skill 必须遵守三条规则——不是因为「规范要求」，而是因为生成结果不可预测，没有这三条铁律，Skill 就是一个不可控的黑箱。

铁律 1：Prompt 必须落地成文件（生成前）

规则：在调用任何图片生成后端之前，必须把完整 prompt 写入 prompts/NN-{type}-[slug].md。

错误的做法：
  AI 在脑子里构造了一段 prompt → 直接调 API 生成图片 → 完成
  问题：prompt 丢了。满意的图想复现？不知道当时用的什么 prompt。
       不满意的图想改进？不知道上次写了什么，只能从头来。

正确的做法：
  AI 构造 prompt → 先写文件 prompts/01-cover-investing-101.md → 再调 API
  好处：prompt 变成可审查、可迭代、可复现的资产

为什么必须在调用 API 之前写文件？ 两个原因：

1. 可审查——用户在看图之前可以先看 prompt，判断 AI 是否理解了文章核心。如果 prompt 跑偏了（「理财文章」的 prompt 写成了「关于钱的励志鸡汤」），不用等生成就能发现。
2. 可复现——如果某次生成的封面特别满意，prompt 文件就是「配方」。下次生成类似封面时可以直接基于这个文件微调，不需要从零猜测。

铁律 2：生成后必须预览（生成后）

规则：生成完图片后展示给用户，等用户确认——而不是直接保存、直接发布、或者假设用户满意。

为什么不能自动保存？
  因为「生成成功」≠「用户满意」。
  生成型 API 的成功率（技术上没报错）接近 100%，但满意率可能只有 60%。
  如果不预览，用户看到不满意的封面时已经晚了——文件已经覆盖了旧的。

预览环节的设计：
  → 生成图片
  → 展示给用户：「这张怎么样？」
  → 用户三个选择：
    1. 「就这张」→ 保存，完成
    2. 「再来一张」→ 调整 prompt → 重新生成 → 再预览
    3. 「还是不对，改一下配色/风格」→ 改参数 → 重新生成 → 再预览

铁律 3：支持迭代反馈（不满意时）

规则：用户不满意不是 Bug，是正常流程的一部分。Skill 必须内置「不满意→调整→重新生成→对比」的循环。

迭代不是「AI 做错了，让它重做」——
而是「第一版是草案，用户给出反馈，第二版更接近用户想要的」。
这更像设计师和客户之间的工作流程，而非命令行工具的一次性执行。

好的迭代设计：
  ✓ 保留上一版封面（不覆盖），方便对比
  ✓ 让用户可以指定调整方向：「颜色太暗了」「文字太小」「风格太抽象」
  ✓ AI 把反馈翻译成参数变化：太暗 → palette 从 dark 改为 warm

差的迭代设计：
  ✗ 每次重新生成覆盖上一版（用户无法对比）
  ✗ 用户只能说「不满意」但无法描述哪里不满意
  ✗ AI 不理解反馈，重新随机生成一张（可能更差）

🔑 三条铁律对应三个阶段：生成前 → 生成后 → 不满意时。覆盖了生成型 Skill 的完整交互生命周期。

---

三条铁律 vs L1-03 的核心约束

两课都有「硬规则」，但性质完全不同：

---

4. 结构拆解：AI 生成型模板

从 L1-05 中提取可复用的「AI 生成型」Skill 模板。注意这和前面三种架构的差异——增加了确认闸门和迭代循环。

四种架构模板总览：

---

5. 电商案例：抖音直播间封面图批量生成——按每日品类轮播

🛒 实战案例：某服装店铺在抖音日播8小时，每天换3个品类专场（早场"通勤穿搭"、下午场"约会连衣裙"、晚场"大码女装"），每场需要1张直播间封面图。运营每天花40分钟做3张封面——找图、加字、调色、导出。问题是：忙的时候直接沿用上一场的图，用户刷到以为是"又播同一场"直接划走。

用 baoyu-cover-image 统一直播间封面策略：

1. 项目级 EXTEND.md：固定品牌色 #E84A6F（品牌粉），布局 minimal，模板类型 live-stream
2. 为抖音直播间配置1080×1920竖屏尺寸（占据推荐流的手机全屏预览）
3. 每日3场封面按品类生成：早场→浅色底+通勤场景词（"上班穿什么"）、下午场→亮色底+品类词（"约会战袍"）、晚场→暖色底+人群词（"大码也好看"）
4. Prompt模板固化：「{品类词} + {当日主打款名} + {价格锚点}」三个变量，运营只需改3个词
5. Prompt保存为 prompts/live-{日期}-{场次}.md，方便后续复用和微调

效果：

• 3张封面制作时间从40分钟 → 2分钟（改3个变量一键生成，省95%）

• 封面统一风格后，直播间推荐流曝光点击率从4.1% → 6.7%（+63%）

• 每日三场切换后，用户不再混淆场次——每场封面品类信息一目了然

• 一个月积累90张封面图全部prompt存档，复播同类目时直接调用历史prompt

🔑 启示：抖音直播间的封面图不是"一张好看的图"，而是"用户在推荐流里0.3秒内决定要不要点进来的信号"。品类轮播的直播间最怕封面和内容对不上——用户点进来发现不是封面上的品，3秒就划走。AI生成让每场直播有"专属封面"，成本为零。

---

6. 手写模仿

场景：设计一个「图标生成器」Skill icon-generator

• 输入：应用名称 + 风格 + 颜色
• 输出：多尺寸图标（16/32/64/128/256/512）
• 关键设计决策：Prompt 模板 → 尺寸批量生成 → 预览
• 三条铁律如何应用？（prompt 落文件？预览？迭代？）

点击查看思路

三条铁律的应用：

1. Prompt 落文件：生成前将 prompt 保存为 prompts/icon-{app-name}.md，包含应用名、风格描述、颜色值、各尺寸要求
2. 预览确认：先生成 512×512 主图标展示给用户，确认后再批量生成其他尺寸
3. 迭代反馈：用户说「太复杂了，简化」→ 修改 prompt 加 minimalist, simple shapes → 重新生成主图标 → 确认 → 批量

关键设计：不要在确认前批量生成所有尺寸——万一用户对主图标不满意，6 个尺寸全白生成。先生成一个预览，确认满意后再批量。

---

7. 掌握检验

Q1：生成型 API（如封面图生成）和获取型 API（如 YouTube 字幕提取）的核心设计差异是什么？

• A) 生成型 API 不需要参数，获取型 API 需要参数
• B) 生成型 API 结果不确定，需要「预览→不满意→重来」的迭代反馈机制；获取型 API 结果确定，一次调用即可
• C) 生成型 API 比获取型 API 运行速度快
• D) 获取型 API 需要 API Key，生成型 API 不需要

Q2：baoyu-cover-image 内置了各平台的封面图尺寸规范。以下哪个尺寸对应 Twitter/X 平台？

• A) 1200×630
• B) 1200×627
• C) 1600×900
• D) 1080×1080

Q3：AI 生成型 Skill 有哪三条特殊规则（铁律）？请逐一列出，解释每条规则的设计目的，并说明它们分别对应生成流程的哪个阶段。

Q4：为什么 prompt 必须落地成文件（prompts/NN-*.md），而不能只在运行时生成在内存里？给两个理由。这条规则为什么必须在调用 API 之前执行？

Q5：为什么封面图的风格（layout type）配置用 EXTEND.md 偏好系统而不是命令行参数？风格和具体参数（如这一次要不要用渐变色）的决策边界在哪里？举例说明什么该放 EXTEND.md、什么该放命令行。

Q6：以下哪项不属于 AI 生成型 Skill 的三条铁律？

• A) Prompt 落地成文件，在调用生成后端之前
• B) 生成后提供预览，由用户确认而非直接保存
• C) 支持迭代：不满意→调整 prompt→重新生成→对比
• D) 每次生成后自动发布到社交媒体

Q7：某美妆电商想让 5 个编辑的封面图风格统一。从 EXTEND.md 配置到跨平台发布，完整的标准化方案包括哪些步骤？为什么「先生成主预览再批量」比「批量生成 6 个尺寸」更好？

---

8. 答案

点击查看答案

Q1：B — 生成型 API 的结果具有不确定性（每次生成的图片可能不同），因此必须支持迭代反馈（预览→不满意→调整→重新生成）。获取型 API 的数据是预先存在的，结果是确定的，一次调用即可。A 错在"生成型不需要参数"（实际上封面图生成需要文章内容、风格、尺寸等参数），C 不成立（生成型通常更慢），D 不成立（生成型同样需要 API Key）。

Q2：C — Twitter/X 标准封面尺寸为 1600×900。A（1200×630）对应 Blog hero，B（1200×627）对应 LinkedIn，D（1080×1080）对应 Instagram。Skill 内置这些规范，用户只需说"给这篇博客生成封面"而不需要记忆尺寸数字。

Q3：三条铁律：1) Prompt 必须落地成文件（生成前）——在调用生成后端之前，将完整 prompt 写入 prompts/NN-*.md，使 prompt 成为可审查、可迭代、可复现的资产；2) 提供预览机制（生成后）——生成后展示给用户而非直接保存，让用户确认是否满意，避免自动保存不满意的图片；3) 支持迭代反馈（不满意时）——如果用户不满意，调整 prompt → 重新生成 → 对比新旧结果，形成"不满意就改"的闭环。这三条分别对应生成前、生成后、不满意时三个阶段。

Q4：两个理由：1) 可审查——用户可以看到 AI 用来生成封面图的完整 prompt，判断 prompt 是否准确反映了文章内容，这是质量控制的关键环节；2) 可迭代可复现——如果用户对某次生成的封面满意，prompt 文件可以作为"配方"保留，将来生成类似封面时可以复现或微调，而不需要从头猜测。必须在调用 API 之前执行的原因：如果在生成之后才写文件，那「可审查」的价值就丢失了——用户已经看到不满意的图了，看 prompt 只能知道「为什么失败」，而不能在生成之前就发现 prompt 跑偏。

Q5：风格（layout type）是持久偏好而非每次决策——一个用户或品牌通常有固定的视觉风格（如 minimal、bold、gradient），不需要每次生成封面都重新选择。用 EXTEND.md 存储风格让用户"设一次、用终身"。命令行参数适用于每张封面图都不同的临时决策——例如某次想在 minimal 基础上临时改为 gradient 风格。决策边界：高频不变 → EXTEND.md（品牌色、风格偏好），低频可变 → 命令行参数（--aspect 1:1 发 Instagram、--ref photo.jpg 参考某张图）。最好的设计是：EXTEND.md 存默认值，命令行参数允许临时覆盖。

Q6：D — "自动发布到社交媒体"不是 AI 生成型 Skill 的三条铁律之一，也没有在课程中提到。三条铁律都围绕"质量可控"这个核心：prompt 可审查（铁律 1）、结果可预览（铁律 2）、不满意可迭代（铁律 3）。

Q7：标准化方案包括四个步骤：1) 项目级 EXTEND.md 固定品牌视觉规范（品牌色 #FF6B8A、布局 minimal）——解决"5 个编辑风格各异"的问题；2) 为不同平台配置对应尺寸（公众号 900×500、小红书 1080×1440、微博 1200×630）——解决"跨平台尺寸适配"问题；3) prompt 归档（保存到 prompts/NN-article-slug.md）——解决"复现和跨编辑复用"问题；4) 预览 + 迭代筛选——解决"AI 生成质量不可控"问题。"先生成主预览再批量"比"批量生成 6 个尺寸"更好，原因：在确认主图标/封面图满意之前批量生成所有尺寸是浪费——如果用户对主图不满意，所有尺寸都白生成。正确流程是先生成一个预览 → 用户确认满意 → 再生成全尺寸。这样既省 API 费用，也避免用户面对 6 张不满意的图时无意义的迭代。

（6/7 通过）

---

9. 延伸阅读

• [[L1-06-图文卡片制作|下一课：图片卡片生成]] — 三层架构：内容层/模板层/渲染层
• [[L1-04-YouTube字幕提取|上一课：YouTube字幕提取]] — 回顾索取型 API 的设计模式
• [[L1-03-Markdown格式化排版|L1-03：Markdown格式化]] — 回顾「核心约束」与「三条铁律」的对比