AWS Wechat Article Images

配图

公众号封面 & 配图 AI 生成 —— 按文章内容自动匹配画风，一稿多方案，风格体系可复用。

套件说明 · 本 skill 属 aws-wechat-article-* 一条龙套件（共 9 个 slug，入口 aws-wechat-article-main）。跨 skill 的相对引用依赖同一 skills/ 目录，建议一并 clawhub install 全套。源码：https://github.com/aiworkskills/wechat-article-skills

能力披露（Capabilities）

本 skill 调 image_create.py 调外部图像 API 生成封面与正文配图。会把图片提示词（可能含文章主题片段）发给用户配置的图像生成端点。 具体行为：

• 凭证读取：aws.env 的 IMAGE_MODEL_API_KEY
• 凭证外发：该 key 以 Authorization: Bearer 头发送到 image_model.base_url 指定端点（常见为 DALL-E、gpt-image 兼容 /v1/images/generations，或多模态模型 /v1/chat/completions，具体由用户配置）
• 内容外发：每张图片的 prompt（文本）作为 JSON POST body 发送；prompt 内容来自本篇 imgs/prompts/*.md（可能包含文章标题、章节摘要）
• 下图 SSRF 防御：若 API 响应返回图片 URL（而非 base64），脚本仅允许下载 http/https 公网地址；内网 / 环回 / 链路本地 / 保留地址全部拒绝（防止恶意或被劫持的模型端点把脚本当作 SSRF 跳板）
• 文件读：仓库内 .aws-article/config.yaml、本篇 article.yaml、article.md、imgs/prompts/*.md、references/cover-method.md、references/image-method.md、references/cover-examples/*.md、.aws-article/products/{产品名}/images/*（业务配图库，本篇涉及用户业务时优先复用）
• 文件写：本篇 imgs/*.{png,webp}、可选 img_analysis.md
• shell：仅 {python} {baseDir}/scripts/image_create.py、user_image_prepare.py（{python} = 本机 Python 3 解释器，见 main SKILL 第 0 步：Windows 用 py -3 -X utf8，macOS / Linux 用 python3）

建议：用专用 key（最低权限、独立计费），避免使用 account 级 master key。

配套 skill（informational）

本 skill 是 aws-wechat-article-* 一条龙公众号套件的配图环节（入口 aws-wechat-article-main）。工作流中的若干步骤会读取同级 ../aws-wechat-article-main/references/*.md 等共享文档（首次引导、env/config 示例、articlescreening schema 等）。

• 套件完整装齐到同一 skills/ 根目录时，跨 skill 引用都能读到。
• 单独安装本 skill 时，跨 skill 引用的步骤会在读取阶段遇到 file not found；本 skill 内的生图脚本仍可用。

完整 9 slug 清单见 源码仓库。

路由

完整长文从选题到发布 → aws-wechat-article-main；图片消息/九宫格等多图推送 → aws-wechat-sticker。

读取文章中的配图标记，按内容形态生成图片：封面 12 个形态、正文配图 8 个形态，均按内容判断而非账号审美。专注于长文配图，贴图请用 sticker。

脚本目录

Agent 执行：确定本 SKILL.md 所在目录为 {baseDir}。

配置检查 ⛔

任何操作执行前，必须按 首次引导 执行其中的 「检测顺序」。检测通过后才能进行以下操作（或用户明确书面确认「本次不检查」）：

从选题到发布的前置规则见 aws-wechat-article-main/SKILL.md；本 skill 只描述配图步骤。

图片模型：image_model（provider、base_url、model、default_size、default_quality 等）在 config.yaml；IMAGE_MODEL_API_KEY 在 aws.env。键名对照 {baseDir}/../aws-wechat-article-main/references/env.example.yaml。

base_url 须为完整端点路径，脚本根据路径判断调用模式：

• https://xxx.com/v1/images/generations — DALL-E / gpt-image 等
• https://xxx.com/v1/chat/completions — Gemini 等多模态模型（通过中转站生图）

比例怎么传（因端点而异）：/v1/images/generations 用 size 像素串；Gemini 系模型走 /v1/chat/completions 时用 extra_body.imageConfig（比例 + 分辨率档位），这是 Gemini 特有结构，只对识别为 Gemini 系的模型发送（模型名含 gemini / nano-banana / imagen），其余模型保持「尺寸并入提示 + 生成后裁切」以免严格网关报 400。可用 image_model.aspect_mode（auto / imageconfig / none）显式覆盖。无论走哪条路径，最终都会按 aspect 校正到目标比例。

交互约定：可提示用户上述项是否已填；一条龙下通常已通过 validate_env.py。须遵守 main 的智能体行为约束——未通过环境校验且未获用户明确「本次例外」时，不得假装已走专用生图 API。

封面风格 + 正文配图

• 封面：按 cover-method.md 七步推导——找张力、定关系、找隐喻、套视觉语言、2.35:1 布局、写成散文、回看。封面模板（references/cover-styles/）提供第四步的内容形态与文案规格（字号/颜色/位置），共 12 个，默认全选为候选池，Agent 按文章内容挑一个。范例见 cover-examples/。
• 先分工再选形态 ⛔：排版侧的版式组件和信息位配图干同一件事，同一份内容只能给其中一个。判据是内容里有没有空间关系（大小/流向/嵌套 → 图；纯文字并列/对照/枚举 → 组件）。五个形态的实测归属见 image-method.md 第一步半。
• 正文配图：8 个内容形态，见 references/image-styles/。判断只有一条——删掉这张图，读者会看不懂（信息位，必须带文章真实内容）还是读不下去（节奏位，不加字）？都不影响就不要这张图。

封面 vs 正文（资源策略）⛔

说明：全局 config.yaml 的 image_source: user 表示「正文以用户/素材引用为主」；不豁免上述「封面须脚本生成」规则，除非用户同时提供了封面文件并声明仅用该封面。

工作流

配图进度：
- [ ] 第1步：环境检查 + 本篇约束与文章
- [ ] 第2步：解析配图标记
- [ ] 第3步：确定风格
- [ ] 第4步：生成配图方案
- [ ] 第5步：展示方案并等待确认 ⛔
- [ ] 第6步：生成图片（**脚本失败时**见同节「调用失败」分支，勿静默吞掉报错）
- [ ] 第7步：插入文章

正文配图来源优先级（Agent）⛔

仅适用于正文插图（不含封面；封面见上文「封面 vs 正文」）。在为正文 placeholder 调用 image_create.py、写入 imgs/prompts/ 之前，须先判断是否可用本地业务配图库，避免业务相关文章（教程 / 产品介绍 / 案例 / 自家界面截图）「有现成业务配图却重新生成」：

1. 仓库业务配图库：若本篇涉及用户业务，先 ls .aws-article/products/，进入相关产品的 images/ 子目录，列出并阅读 同名 .md（含路径与画面说明），按主题匹配后，在 article.md 中直接引用对应 .png / .webp（或复制到本篇 imgs/ 再引用）。与正文严格相关才用，避免硬凑。
2. 用户上传 / 本篇 image_source: user：用户提供的图或上述引用策略，走「用户供图模式」与 img_analysis.md（正文部分）。
3. 仍缺图或须原创插画：再按 image-method.md 选形态、写 imgs/prompts/、执行 image_create.py（或 Agent 降级生图）。

说明：业务配图库属「仓库内业务资源」，不必等用户手动上传才查；与「用户供图模式」并列，而非仅附属于后者。

第1步：环境检查 + 本篇约束与文章

• 全局：读 .aws-article/config.yaml — cover_aspect、cover_style、image_density、caption_style、multi_image_count、tone 等以之为准（完整字段见 articlescreening-schema.md 与 config.example.yaml）。
• 本篇：若同目录有 article.yaml，读取 default_cover_image_style、default_article_image_style（应为单元素列表，代表本篇已选预设）及 cover_image 等字段。
• 读取 article.md（或当前流程规定的正文来源）。
• 当 image_source: user（全局或本篇）时，进入「用户供图模式」：先创建本篇 imgs/ 并生成/更新 img_analysis.md，记录每张图的内容分析、建议章节与推荐用途。

第2步：解析配图标记

提取所有 ![类型：描述](placeholder)。实证 类型提示用户提供素材或从 .aws-article/products/{相关产品}/images/ 搜索（业务配图库）。

用户供图模式（新增分支）

当用户上传图片并指定主题时，按以下顺序执行：

1. 立即确保 {article_dir}/imgs/ 存在，并将用户图片放入该目录。
2. 生成/维护 {article_dir}/img_analysis.md（每图至少包含：文件名、图片内容、建议章节、推荐用途、图注建议）。
3. 硬性约束：img_analysis.md 中“推荐用途：封面”必须且只能出现 1 次；其余图片用途应为“正文”。
4. 同步更新本篇 article.yaml：image_source: user（从模型生图切换到用户供图状态）。
   • 字段取值只允许 generated / user。
5. 写稿阶段直接使用用户图片路径（如 imgs/淘米.png），不再使用 placeholder。

顺序说明：imgs/ 落图 → 分析并写好 img_analysis.md → 再跑 write.py；写稿时以 img_analysis.md 为准，把图片插到与内容匹配的章节位置。

发布后换图重发（新增分支）

当用户明确说「这篇文章配图不满意，换成我上传的新图并重新发草稿箱」时，按以下流程：

1. 用户指定目标文章目录（drafts/YYYYMMDD-slug/）。
2. 将新图放入该目录 imgs/，并更新 img_analysis.md（仍需满足“封面仅 1 张”）。
   • 同步把本篇 article.yaml.image_source 更新为 user。
3. 按 img_analysis.md 重新映射图片到 article.md 对应章节（允许重排章节以匹配图序）。
4. 运行 format.py 重新生成 article.html（不要只改旧 html 局部）。
5. 进入终审：确认 article.md / article.html 无 placeholder，且引用图片文件均存在。
6. 回到发布步骤执行 publish.py full（publish_method: draft 时写入草稿箱）。

可用素材库（与上文「配图来源优先级」一致）：

• .aws-article/products/{产品名}/images/：业务配图库（产品截图、品牌素材等）；本篇涉及用户业务时优先读同名 .md 再选图。若已用业务配图满足正文，可不再走生图 API。

第3步：确定风格

封面与正文配图分别确定风格，走各自的预设目录。

封面风格

预设发现：Agent 扫描两个目录合并可用封面预设列表：

1. 内置：{baseDir}/references/cover-styles/（随 skill 安装；文件名形如 简约.example.md，预设名取 .example.md 之前的部分即 简约，可直接引用无需复制）
2. 用户自定义：.aws-article/presets/cover-styles/（用户创建或预设包导入）

加载优先级：

1. 用户当次指定（如「封面要简约风」）
2. 本篇 article.yaml.default_cover_image_style（单元素列表）→ 从内置或 .aws-article/presets/cover-styles/<名>.md 加载（用户文件同名优先于内置）
3. fallback：custom_cover_image_style 为空即全选，Agent 按 cover-method.md 第四步从 12 个形态里挑——判断只有一条：主体在 345px 缩略图里能否被一眼认出。

每个封面模板 .md 含五个字段：用于 / 主体 / 影调 / 文案 / 版式。「文案」不可缺省——缺了产出的是背景图而不是成品封面。画什么由 cover-method.md 从文章推导。Schema 见 cover-styles/README.md。

正文配图风格

预设发现：内置 8 个于 {baseDir}/references/image-styles/（<名>.example.md，预设名取 .example.md 之前的部分），用户自定义放 .aws-article/presets/image-styles/<名>.md，同名覆盖。默认全选为候选池，Agent 按每个图位的作用挑形态。schema 与判断标准见 image-styles/README.md。

加载优先级：

1. 用户当次指定（如「正文要扁平插画」）
2. 本篇 article.yaml.default_article_image_style（单元素列表）→ 加载 .aws-article/presets/image-styles/<名>.md
3. fallback：custom_article_image_style 为空即全选，Agent 按 image-method.md 逐个图位判断——删掉它读者会看不懂（信息位）还是读不下去（节奏位）？都不影响就删掉该图位。

第4步：生成配图方案

封面：按 cover-method.md 走完前六步，产出一个 prompt 文件：frontmatter 含 aspect，正文是 150–300 字的散文，标题文案（4–7 字，从文章标题提炼钩子；字高占画面 25–35%，是画面第一元素）连同位置、字体感、颜色、大小一起写在里面。不要关键词清单，不要写「不要 X」，不要照抄预设或范例里的场景。

正文配图：按 image-method.md 六步逐个图位处理。信息位的内容必须从文章里取，不能让模型自由发挥——实测会生成无关鸡汤并自带 emoji。

封面 prompt frontmatter 必须包含 aspect：从 config.yaml 的 cover_aspect 读取（如 2.35:1），写入 YAML frontmatter。image_create.py 据此映射到 API 支持的最接近尺寸生成，装有 Pillow 时再居中裁切到该比例（如 2.35:1 → 1792x763）。值须加引号（aspect: "2.35:1"），未加引号的 16:9 会被 YAML 解析成整数。缺少 aspect 时退回 config.yaml 的 image_model.default_size（默认 1024x1024）。

图片内文字：画面中出现的文字必须为中文。在 prompt 里直接写出要显示的中文文案（如「传统对话AI」「OpenClaw」），禁止只写 “labels in Chinese” 或 “Chinese or English OK”，否则模型会生成英文。

Prompt 构建：封面见 cover-method.md，正文配图见 image-method.md；通用规则（图中文字、构图要求、高级布局）见 prompt-construction.md

第5步：展示方案并等待确认 ⛔

• 一条龙流程且用户对风格无特殊要求：与 main 约定一致，按默认预设自动执行，不单独确认，但须在结果里列出每张图的类型、风格与 prompt 文件路径。
• 单独触发本 skill、用户明确提出风格要求、或方案涉及用业务配图库替换正文图位：先展示方案（每图：位置、Type、Style、prompt 要点、来源），等待用户确认后再进入第 6 步。

第6步：生成图片

封面：见「封面 vs 正文」— 默认必须先写好 imgs/prompts/ 中封面 prompt（含 aspect 与 config.yaml 的 cover_aspect 一致），再执行 image_create.py generate … -o ../cover.png（或等价输出路径）。

封面回看（必做）：cover.* 生成后打开图片，按 cover-method.md 第七步 对五条：标题字对不对全不全、主体位置与标题区、元素 ≤3、缩略图可读、与文章相关。不过关回到出问题的那一步改 prompt 再生成——标题错了改文案写法，主体乱跑改布局描述，与文章无关是张力没找准；不要不改 prompt 盲目重跑。当前环境看不了图时，退而运行 {python} {baseDir}/scripts/image_create.py check cover.png 做纯代码检查——只有尺寸与近单色两项。标题区干净度只对「先出底图再用 --title-font 合成标题」那条路有效；本方法的标题由模型画进图里，文字本身就是高边缘密度，套这项会把正确的封面判为不合格。

生成方式（优先级，正文）：

0. 已在「正文配图来源优先级」中用尽素材库 / 用户图：本节不再对该图位重复生图（封面仍须单独按上款处理）。
1. 缺图时优先：调用专用生图 API（scripts/image_create.py）— 依赖 config.yaml 的 image_model + aws.env 的 IMAGE_MODEL_API_KEY
2. 自动降级：模型未配置（退出码 2、stderr 含 [NO_MODEL]）且当前 Agent 支持图片生成、并已获用户明确同意代生图 → Agent 读取 imgs/prompts/*.md 中的 prompt + frontmatter（size/quality），用自身多模态能力按相同 prompt 生图 → 告知用户 ℹ️ 图片模型未配置，本次由当前对话模型直接生图（使用相同配图方案） → 生成后正常执行第 7 步（插入文章）
3. 故障降级（退出码 1）→ 按本节下方「调用失败」表格分类处理
4. 用户供图：跳过生图 — 当 image_source=user 或用户明确”使用我上传的图片”时，不调用 image_create.py，改为”读图分析 + 写稿引用 + 重排版”

必须告知用户当前使用的方式：

• 已配置且调用脚本 → ℹ️ 使用 image_create.py 调用专用生图模型（{model}）
• Agent 降级生图（退出码 2）→ ℹ️ 图片模型未配置，本次由当前对话模型直接生图（使用相同配图方案）
• 故障降级 / 仅 prompts → ℹ️ 本次未走 image_create.py（原因：…）

⛔ 故障降级（退出码 1）时的终点：只做到第 4 步（或第 5 步）。产出 imgs/prompts/*.md 与方案；不执行「替换 article 中的 placeholder」或「修复 HTML」。若 imgs/README.md 尚不存在或需补充当前方案的说明，可创建/更新（如何配置 aws.env / config.yaml、如何跑 image_create.py batch、如何在 article.html 中替换）；若已存在且已涵盖当前方案，不必重写。

注意：退出码 2（模型未配置）且 Agent 支持图片生成、并已获用户明确同意代生图时，不受上述终点限制——Agent 降级生图后继续执行第 7 步。

调用专用 API 时（在仓库根执行，{baseDir} 按上表解析；路径按本篇 imgs/ 调整）：

{python} {baseDir}/scripts/image_create.py batch drafts/YYYYMMDD-slug/imgs/prompts/ -o drafts/YYYYMMDD-slug/imgs/

单张：{python} {baseDir}/scripts/image_create.py generate imgs/prompts/01-cover.md -o imgs/01-cover.png

连通性自检：{python} {baseDir}/scripts/image_create.py test（失败时退出码 1 并打印分类提示，可按下方表格处理）

图片规格：references/specs.md

image_create.py 调用失败时（智能体必选分支）

只要执行了 image_create.py 且非零退出或 stderr 有 API/网络错误，就必须走本节，不得只说「生图失败」而不分类、不摘要报错。

运行脚本后须把终端 stderr 中的具体报错摘要给用户（含 ❌、HTTP 状态码、【配置/认证】、网络错误（可重试）、[NO_MODEL] 等关键行），勿只说「失败」。

禁止：配置明显错误时静默改用 Agent 却不说明；网络降级后不告知「本次未走专用生图」。

第7步：插入文章

仅当已生成图片时执行：替换 placeholder 为实际图片路径，输出到 imgs/。

封面排除：封面图（![封面：...]）仅用于微信文章封面上传，禁止作为 <img> 嵌入 HTML 正文。替换 placeholder 时跳过封面标记行（或直接删除该行），封面图单独复制到文章根目录 cover.{ext}。publish.py 也支持从 imgs/ 目录自动发现封面图（cover.* 或 *-cover.*）。

修复 HTML 的触发条件：仅当在 article.html 中确实存在 href="placeholder" 或 placeholder 被渲染成可点击链接时，才将误转的 <a> 改为 <img> 或占位说明；不要默认每次都执行「修复流程图占位」或「修复 HTML」。

⛔ 插图入正文之后又重跑生图时，必须复核引用。 端点返回的格式会变（同一 prompt 这次 PNG 下次 JPEG），脚本会删掉同名旧后缀的图并打 [WARN]，article.md / article.html 里的 imgs/xxx.png 就指向了不存在的文件。实测踩过：补跑两张分辨率不达标的图，其中一张换成了 .jpg，正文引用当场断掉且不报错。重跑后按文件名主干（05-金句卡片）重新匹配实际存在的文件，两个文件一起改。

过程文件