142 lines
5.8 KiB
Markdown
142 lines
5.8 KiB
Markdown
# 连环画工作流与结构化提示词经验总结
|
||
|
||
更新日期：2026-04-30
|
||
|
||
## 背景
|
||
|
||
本轮连环画工具从“故事分镜生图”扩展为“多场景多页图片生成”：用户可以选择宣传册、产品手册、绘本、报刊、杂志、教程等创作场景，先让文本模型生成公共提示词和每页图片提示词，再批量生成图片并导出 ZIP、PPTX 或 PDF。
|
||
|
||
这类工具的难点不在单次生图，而在工作流边界：PDF 输入、场景默认模板、结构化 JSON 提示词、串行/并行任务、历史记录和导出都必须保持轻量、可恢复、可解释。
|
||
|
||
## 经验原则
|
||
|
||
### 1. 用户语义可以扩展，内部实体保持稳定
|
||
|
||
用户看到的入口可以从“连环画”扩展到“多图生成”，支持产品手册、城市文旅、教程步骤、杂志专题等更多场景。
|
||
|
||
但内部 `comic-creator` id、存储 key、任务元数据不应跟着频繁改名。展示层放宽语义，数据层保持稳定，可以避免历史记录、懒加载注册和任务回填断裂。
|
||
|
||
### 2. 场景模板只做起点，不覆盖用户创作
|
||
|
||
场景下拉的默认提示词应降低用户启动成本，但不能覆盖已经手写的内容。
|
||
|
||
经验规则：
|
||
|
||
- 输入为空时自动填入场景模板。
|
||
- 输入仍是旧模板时允许自动替换。
|
||
- 输入已被用户改写时，只显示“套用模板”入口。
|
||
- 文本版和结构化 JSON 版模板都要随场景维护。
|
||
|
||
### 3. PDF 是素材来源，不是附件摆设
|
||
|
||
当用户上传 PDF 时，规划提示词必须明确告诉文本模型：PDF 是主要素材来源，用户创作需求用于限定目标和取舍。
|
||
|
||
经验规则：
|
||
|
||
- 要求模型读取 PDF 的事实信息、结构层级、品牌/产品定位、关键词和视觉线索。
|
||
- 要求模型把 PDF 内容重组为当前场景下的多页图文方案。
|
||
- PDF 文件、截图、base64 不进入长期记录；记录只保存轻量来源信息、规划结果和任务引用。
|
||
- 带 PDF 时文本模型只允许选择 Gemini 相关模型，避免用户选到不支持 PDF 入参的模型。
|
||
|
||
### 4. “生成的提示词类型”控制模型输出，不控制用户输入
|
||
|
||
提示词类型容易被误解成“用户输入格式”。更准确的语义是：让文本模型生成文本提示词，还是生成图片模型可用的结构化 JSON 提示词。
|
||
|
||
落地时要同步调整：
|
||
|
||
- UI 文案使用“生成的提示词类型”。
|
||
- 构建给文本模型的系统提示词按该选项切换。
|
||
- 用户原始输入仍可自由写自然语言或 JSON。
|
||
- 结构化模式下，`pages[].prompt` 是单页图片提示词的 JSON 对象或 JSON 字符串。
|
||
|
||
### 5. 视觉结构化 JSON 要有统一 schema
|
||
|
||
图片、PPT 单页和连环画页面都属于视觉页面类提示词，应使用统一的 `layout + style` schema，避免不同入口各写一套半结构化字段。
|
||
|
||
推荐结构：
|
||
|
||
```json
|
||
{
|
||
"layout": {
|
||
"header": {
|
||
"location_title": "",
|
||
"main_title": "",
|
||
"subtitle": ""
|
||
},
|
||
"body": {
|
||
"content_blocks": {
|
||
"block_type": "",
|
||
"left_column": {
|
||
"title": "",
|
||
"content": []
|
||
},
|
||
"right_column": {
|
||
"title": "",
|
||
"content": []
|
||
}
|
||
}
|
||
},
|
||
"footer": {
|
||
"elements": ""
|
||
}
|
||
},
|
||
"style": {
|
||
"background": "",
|
||
"elements": "",
|
||
"colors": [],
|
||
"fonts": []
|
||
}
|
||
}
|
||
```
|
||
|
||
非视觉类结构化提示词不要套用页面布局 schema，例如视频、音频、文本和 Agent 场景。
|
||
|
||
### 6. 公共提示词和单页提示词继续分层
|
||
|
||
公共提示词承载整套作品的一致性：画风、色板、字体、角色/品牌、构图规律和禁止事项。
|
||
|
||
单页提示词只描述本页差异：页面用途、画面主体、构图、可见文字、信息重点和情绪。不要把公共规则重复塞进每页，否则提示词变长、修改困难，也容易让图片模型把字段名或说明文字画进图里。
|
||
|
||
### 7. 页数展示必须基于真实规划结果
|
||
|
||
规划预览不能为了 UI 简洁只渲染前几页。用户要求 6 页时，即使模型只返回 4 页，也要补齐到 6 页并明确显示“已规划 6/6 页”。
|
||
|
||
经验规则：
|
||
|
||
- 数据层按用户页数补齐缺失页。
|
||
- UI 展示全部规划页。
|
||
- 缺失页标记为“待补全”，让用户能编辑后继续生成。
|
||
- 清理模型返回标题里的重复页码前缀，例如 `第1页：第1页：...`。
|
||
|
||
### 8. 导出要按当前图轻量生成
|
||
|
||
ZIP、PPTX、PDF 都应使用当前选中的页图，不把历史候选图误导出。
|
||
|
||
经验规则：
|
||
|
||
- 记录里只保存图片 URL、mime、taskId、生成时间等轻量引用。
|
||
- ZIP 包含图片、`manifest.json`、提示词 Markdown 和补全下载脚本。
|
||
- PPTX 用图片铺满页面，按当前图片参数比例保持不拉伸。
|
||
- PDF 逐页读取图片写入，避免一次性把所有远程图片 Blob 放进内存。
|
||
- 缺图页要在 manifest 中可见，不能静默消失。
|
||
|
||
## 检查清单
|
||
|
||
- 工具展示名和场景文案是否足够通用，避免只暗示“故事”？
|
||
- 场景模板切换是否不会覆盖用户手写内容？
|
||
- 带 PDF 时，文本模型是否限制为 Gemini，且提示词明确说明 PDF 用法？
|
||
- “生成的提示词类型”是否真正影响传给文本模型的规划指令？
|
||
- 结构化 JSON 是否使用统一 `layout + style` 视觉 schema？
|
||
- 非视觉 structured 场景是否没有被错误套用页面布局 schema？
|
||
- 规划预览是否展示全部页，并显示实际规划页数？
|
||
- 导出是否只使用 URL 轻量引用，避免持久化 base64 或大 Blob？
|
||
|
||
## 验证建议
|
||
|
||
```bash
|
||
pnpm --dir packages/drawnix test src/components/comic-creator/utils.test.ts src/components/comic-creator/task-sync.test.ts
|
||
pnpm --dir packages/drawnix test src/services/prompt-optimization-service.test.ts
|
||
pnpm nx run drawnix:typecheck
|
||
git diff --check
|
||
```
|