公众号图片生成器

概览

按微信公众号发布场景生成正确画布尺寸的位图图片。生成前必须逐步明确图片类型、主题内容、视觉风格和必要文案；信息足够后也不要直接生图，必须先汇总生图信息并等待用户确认。用户确认前，不要调用图片生成或编辑工具。如果用户需求模糊，先整理已有信息，给出合理建议，再追问最关键的缺口。用户只说“公众号封面图”或“封面”时，默认优先建议兼顾大小封面的 1283 × 383 方案。

尺寸判断

所有尺寸单位都是像素。用户给出精确尺寸时，优先使用用户尺寸。用户说出明确类型时，按下表选择尺寸。用户只说“公众号图片”“微信推文图片”“配图”等笼统说法时，不要直接生成，先让用户选择图片类型。用户只说“公众号封面图”“推文封面”或“封面”时，先建议做 1283 × 383 的兼顾大小封面；如果用户明确只要首图，再使用 900 × 383。

封面兼容策略

公众号文章封面只上传一张图，但常见展示里同时存在大封面 2.35:1 和小封面 1:1。用户只说“公众号封面图”时，优先推荐 1283 × 383 的兼顾大小封面：左侧 900 × 383 是大封面主视觉，右侧 383 × 383 是小封面裁切区。

生成 1283 × 383 兼顾大小封面时：

1. 左侧 900 × 383 用作大封面主视觉，可以承载标题、卖点和氛围。
2. 右侧 383 × 383 必须能独立成立，放主体、关键词、图标或强识别元素，不依赖左侧文字。
3. 必须采用分区生成再拼接的方式，不要直接调用图片生成工具生成一张 1283 × 383 整图。
4. 先生成左侧 900 × 383 大封面主视觉，再生成右侧 383 × 383 小封面裁切区，最后用本地脚本拼接成一张 1283 × 383 图片。
5. 分区生成时，两张图必须保持统一的视觉风格、色彩、字体气质和主题元素。
6. 关键标题不要跨越左右区域边界，避免小封面裁切后文字断裂。
7. 小封面区域不要放过长文字，优先放 1 个短词、图形符号或核心视觉。
8. 如果生成工具输出尺寸不精确，先分别裁剪或缩放到 900 × 383 和 383 × 383，再拼接；拼接后必须检查最终图片尺寸正好是 1283 × 383。
9. 如果用户明确不需要兼顾小封面，再退回 900 × 383 的公众号大封面/首图方案。

需求澄清与建议

用户只给出零碎信息时，不要把所有问题一次性抛给用户。先把已知信息整理成一句话，再判断下一步最影响生成结果的缺口，一次只追问一个关键问题，并提供可选建议。

优先澄清顺序：

1. 图片用途和尺寸：先确认是兼顾大小封面、首图、小封面、次图、横版海报、文章配图、二维码、视频封面等哪一种。用户只说“封面图”时，先建议兼顾大小封面 1283 × 383。
2. 文章或活动内容：确认文章主题、核心观点、产品/活动名称、目标读者。
3. 主文案：如果用户没有给标题或口号，根据文章内容给出 2 到 3 个可选标题。
4. 视觉风格：如果用户没给风格，根据内容建议 2 到 3 个方向，例如专业商务、温暖生活、科技感、节日促销、简洁信息图。
5. 品牌约束：询问是否有品牌色、标志、二维码、必须出现的人物/产品，或不能出现的元素。

当用户描述很模糊时，按这个格式回应：

我先按你给的信息理解为：【已知信息摘要】。
我建议做成：【图片类型 + 尺寸】。如果是公众号封面图，优先建议兼顾大小封面 `1283 × 383`，左侧做大封面，右侧做小封面裁切区。
风格可以选：
1. 【建议风格一】
2. 【建议风格二】
3. 【建议风格三】

为了继续生成，我还需要先确认一个问题：【当前最关键问题】？

如果用户提供的是文章正文、链接摘要或零散想法，先提炼图片生成需要的信息：主题、受众、情绪、关键词、主标题、辅助元素。不要要求用户重新组织完整生成需求。

生成前确认

只要任务会调用图片生成或图片编辑工具，生成前必须先向用户汇总一次最终生图信息，并明确询问是否确认开始。即使用户已经提供了完整信息，也要先停下来确认，不要边汇总边生成。

确认摘要保持简短，至少包含：

1. 图片类型和尺寸。
2. 主题或文章内容摘要。
3. 主文案和辅助文案；没有文案时写“无文字”或“待用户确认”。
4. 视觉风格、色彩或氛围。
5. 必须出现的元素和避免内容。
6. 兼顾大小封面时，说明左侧大封面和右侧小封面裁切区的安排。
7. 兼顾大小封面时，明确说明会先分别生成 900 × 383 和 383 × 383，再拼接成 1283 × 383。

使用这个格式等待确认：

我先汇总一下生图信息：
- 图片类型与尺寸：【类型】，【宽】×【高】 px
- 主题内容：【摘要】
- 文案：【主文案 / 辅助文案 / 无文字】
- 风格：【视觉风格】
- 画面元素：【必须出现的元素】
- 避免内容：【限制或无】
- 生成方式：【如为兼顾大小封面，写明先生成 900×383 和 383×383，再拼接为 1283×383】

确认后我再开始生成。这样可以吗？

用户明确回复“确认”“可以”“开始生成”“就这样”“OK”等同意表达后，才开始调用图片生成或编辑工具。如果用户修改了任一项信息，先更新摘要并再次请求确认。

工作流程

1. 从用户请求中提取已有信息：图片用途、尺寸、文章内容、主题、文案、风格、品牌元素。
2. 判断是否足够生成：至少需要明确图片类型或尺寸，以及基本主题。缺少其中任一项时，先澄清。
3. 如果用户只说“封面图”“公众号封面图”或“推文封面”，先建议：“推荐做兼顾大小封面 1283 × 383，左侧是 900 × 383 大封面，右侧是 383 × 383 小封面裁切区；如果只需要首图，也可以做 900 × 383。”
4. 如果尺寸或类型仍不明确，只问一个简短问题：“你想生成哪种公众号图片？例如：兼顾大小封面 1283 × 383、公众号首图 900 × 383、小封面 383 × 383、次图 200 × 200、文章配图 1080 × 1080。”
5. 如果主题、文章内容或风格不明确，先根据已有零碎信息给出建议，再问最关键的一个问题。
6. 当信息足够生成后，不要立即生图；按“生成前确认”格式整理一份简短生成需求：图片类型、尺寸、主题、主文案、风格、元素、限制。
7. 等待用户明确确认。用户确认前，不要调用任何图片生成或编辑工具；用户提出修改时，先更新摘要并再次确认。
8. 用户确认后，使用可用的位图图片生成或编辑工具生成图片。提示词里写清楚目标画布尺寸，并在工具支持时使用原生尺寸参数。
9. 对 1283 × 383 兼顾大小封面，必须分两次生成：第一次生成 900 × 383 大封面，第二次生成 383 × 383 小封面，然后使用 scripts/stitch_compatible_cover.py 拼接。
10. 如果生成结果是本地图片文件，检查实际尺寸。概念正确但尺寸不对时，先裁剪或缩放到目标画布，再交付给用户。

提示词模板

生成图片时，在提示词中写明尺寸和公众号使用场景：

生成一张微信公众号【图片类型】，尺寸为【宽】×【高】像素。
主题和文案：【简要内容】。
视觉风格：【风格描述】。
画面元素：【必须出现的元素】。
避免内容：【不要出现的元素】。
确保手机端阅读清晰，关键文字留出安全边距，不要使用过小细节。

生成 1283 × 383 兼顾大小封面时，不要直接生成整图。按下面两段分别生成：

生成一张微信公众号大封面主视觉，尺寸为 900 × 383 像素。
主题和文案：【简要内容】。
视觉风格：【风格描述】。
画面元素：【必须出现的元素】。
避免内容：【不要出现的元素】。
确保手机端阅读清晰，关键文字留出安全边距。
不要为右侧小封面预留区域。

生成一张微信公众号小封面裁切区图片，尺寸为 383 × 383 像素。
主题和文案：【短文案或无文字】。
视觉风格必须与大封面统一。
画面元素：【核心主体、关键词或图标】。
避免内容：【不要出现的元素】。
小封面必须单独成立，不依赖大封面文字；不要放过长文字。

两张图生成后，使用 scripts/stitch_compatible_cover.py left.png right.png --output final.png 拼接，并验证最终尺寸为 1283 × 383。

常见错误

• 用户没有指定尺寸或明确类型时，不要先生成。
• 用户只给零碎信息时，不要简单回复“请提供完整需求”；先整理信息、给出建议、再追问一个关键问题。
• 不要一次问太多问题。先解决最影响结果的问题，再逐步明确主题、文案、风格和品牌限制。
• 不要在信息足够后直接生图；必须先汇总生图信息，等待用户确认后再开始生成。
• 不要把“我将按这些信息生成”当作用户确认；确认必须来自用户的新回复。
• 不要把“封面”默认理解成 900 × 383 首图；公众号封面图优先建议兼顾大小封面 1283 × 383。
• 不要直接生成 1283 × 383 整图作为兼顾大小封面；必须先生成 900 × 383 和 383 × 383 两张分区图，再拼接。
• 不要混淆“公众号小封面”和“公众号次图”：小封面是同一篇文章封面的 383 × 383 方形展示区，次图是多图文次条的 200 × 200 封面。
• 不要为已知类型自创尺寸，除非用户明确要求自定义尺寸。
• 文字较多的图片要控制文案长度，并保证高对比度，因为公众号图片主要在手机端观看。

脚本

• scripts/stitch_compatible_cover.py left.png right.png --output final.png
• 把左侧大封面裁剪或缩放为 900 × 383，把右侧小封面裁剪或缩放为 383 × 383，再拼接为 1283 × 383。
• 生成后必须检查脚本输出的最终尺寸；如果不是 1283 × 383，不要交付。