mirror of
https://github.com/linshenkx/prompt-optimizer.git
synced 2026-05-07 22:18:23 +08:00
46d7d0552d
- Strengthen the style migration contract around natural subject integration and visual hierarchy - Remove the image2image reference extraction entry from the migrated UI flow - Normalize migration placeholders and document the updated migration design
439 lines
14 KiB
Markdown
439 lines
14 KiB
Markdown
# 参考图与图像提示词优化过程总结
|
||
|
||
## 文档目的
|
||
|
||
这份文档用于沉淀本轮图像相关产品与提示词优化的收敛过程，重点回答两个问题：
|
||
|
||
1. 我们为什么从“通用图像提示词优化”逐步转向“参考图驱动”。
|
||
2. 在参考图链路里，提示词本身是如何一步步从“泛化优化”收敛到“复刻优先”的。
|
||
|
||
本文不追求记录所有中间讨论细节，而是保留真正影响当前方案的关键判断、提示词演化逻辑、测试结论与后续工作重心。
|
||
|
||
---
|
||
|
||
## 关联文档
|
||
|
||
- [融合式风格迁移设计说明](./fusion-style-migration-design.md)
|
||
|
||
---
|
||
|
||
## 一、产品路线的收敛过程
|
||
|
||
### 1. 最初的问题意识
|
||
|
||
最开始的讨论焦点是：当前图像优化模板太泛。
|
||
|
||
- `通用优化` 太温和，优化后往往只是在补细节，很难让用户明显感知“变好了”。
|
||
- `中文美学`、`摄影`、`创意` 等模板虽然更有风格，但更像主题类或偏好类模板，不是大多数用户的高频需求。
|
||
- 如果继续沿着“多模板扩张”走，很容易演变成几十上百个模板的模板库，用户选择成本和维护成本都会膨胀。
|
||
|
||
于是我们最初尝试过另一条路：少模板策略化，例如把文生图收敛成 `自动起稿 / 忠实优化 / 风格强化`，甚至在内部再细分出 `传播型 / 叙事型 / 风格型` 起稿卡。
|
||
|
||
### 2. 为什么这条路后来没有继续深化
|
||
|
||
随着讨论深入，我们逐步确认了一个现实问题：
|
||
|
||
- 大多数用户并不知道自己要什么风格，也描述不清楚。
|
||
- 如果用户已经知道自己要“小红书风”“关键词图”“绘本风”“朋友圈风”，那本质上更像是在找模板，不像是在用通用优化器。
|
||
- 如果用户完全不知道要什么，系统给出再聪明的“自动起稿”，也未必真的比原始提示词直接丢给模型更有价值。
|
||
|
||
这让我们意识到，图像优化器如果继续主打“从一句模糊自然语言里自动推导出更好的图像提示词”，价值并不稳。
|
||
|
||
### 3. 关键转向：从“泛化优化器”转向“参考驱动”
|
||
|
||
后面的讨论慢慢聚焦出一个更稳定的方向：
|
||
|
||
- 用户真正高频且明确的需求，不是“帮我把一句模糊提示词优化得更高级”。
|
||
- 而是：
|
||
- 我有一张图，想复刻它；
|
||
- 我有一张图，想借它的风格改写当前提示词；
|
||
- 我已经有一份成熟的结构化提示词或模板，想替换其中最显眼的部分继续复用。
|
||
|
||
换句话说，真正有价值的不是更泛化的提示词优化，而是更“参考驱动”的改造能力。
|
||
|
||
这也是为什么后续我们把注意力从“文生图模板体系重构”逐步转移到了“文生图里的参考图入口”。
|
||
|
||
---
|
||
|
||
## 二、交互方案是如何收敛到现在这版的
|
||
|
||
### 1. 入口层面
|
||
|
||
最终决定保持现有 `文生图 / 图生图` 一级入口和模板下拉不动，只在文生图里增加前置的 `参考图` 能力。
|
||
|
||
这样做的原因是：
|
||
|
||
- 不破坏当前产品入口心智；
|
||
- 不需要同时重构整个图像工作区；
|
||
- 可以先验证“参考驱动”的价值，再决定是否进一步产品转向。
|
||
|
||
### 2. 交互层面
|
||
|
||
`参考图` 最初有过几种交互设想：
|
||
|
||
- 直接上传后立即替换当前提示词；
|
||
- 上传后先做结构化提取，再进入变量编辑；
|
||
- 弹窗中暴露更多中间步骤与同步动作。
|
||
|
||
最终收敛成弹窗式确认流程，核心原因是：
|
||
|
||
- 用户需要在替换前看到结果，否则风险太高；
|
||
- 结构化提示词和变量都应可预览和轻编辑；
|
||
- 但中间过程不应该暴露得过细，否则会让产品看起来像“半成品工作台”。
|
||
|
||
于是弹窗保留了四个核心区域：
|
||
|
||
- 参考图缩略图
|
||
- 使用方式
|
||
- 生成后的提示词
|
||
- 变量预览
|
||
|
||
同时删掉了会增加复杂度但用户价值不高的动作，如：
|
||
|
||
- `同步变量`
|
||
- `重新提取变量`
|
||
- prompt 与变量的实时联动
|
||
|
||
最终保留的原则是：
|
||
|
||
- 用户可以改 prompt；
|
||
- 用户可以改变量值；
|
||
- 但系统不强行保持强一致联动。
|
||
|
||
### 3. 使用方式文案的收敛
|
||
|
||
早期文案使用过更偏实现层的表达，如：
|
||
|
||
- `迁移到当前提示词`
|
||
- `仅复刻参考图`
|
||
|
||
后来为了更符合用户认知，收敛成更直观的两种表达：
|
||
|
||
- `风格迁移`
|
||
- `复刻图片`
|
||
|
||
它们分别对应：
|
||
|
||
- `风格迁移`：当前提示词决定画什么，参考图决定怎么画；
|
||
- `复刻图片`：忽略当前原始提示词，尽量反推原图对应的结构化提示词。
|
||
|
||
---
|
||
|
||
## 三、提示词优化过程：从“泛化优化”到“复刻优先”
|
||
|
||
这部分是本轮最核心的收敛。
|
||
|
||
### 1. 第一阶段：意识到“优化”不等于“更像提示词”
|
||
|
||
一开始，图像相关提示词容易掉进一个常见误区：
|
||
|
||
- 把输出写得更完整；
|
||
- 用更多视觉词；
|
||
- 加更多风格词；
|
||
- 看起来更像“成熟提示词”。
|
||
|
||
但对参考图复刻而言，这种优化方向是错的。
|
||
|
||
因为复刻任务真正要的是：
|
||
|
||
- 尽可能还原原图；
|
||
- 尽量不脑补；
|
||
- 不凭经验把原图改造成“更高级但不一样”的图。
|
||
|
||
因此我们把复刻模板的第一原则改成：
|
||
|
||
`唯一目标：把这张参考图尽可能准确地翻译成一份可直接用于生图的结构化 JSON 提示词。`
|
||
|
||
这里的关键变化是：
|
||
|
||
- 从“生成一份可用提示词”转为“翻译原图”；
|
||
- 从“优化语言质量”转为“保真复现事实”。
|
||
|
||
### 2. 第二阶段：压制幻觉式风格词和社区套话
|
||
|
||
真实测试里很快暴露出另一个问题：
|
||
|
||
- 模型极容易自动补出 `8k / HDR / C4D / Octane / masterpiece / Pixar / Disney` 等词；
|
||
- 这些词并不来自图片，而是模型对“图像提示词”的训练先验。
|
||
|
||
这会直接破坏复刻质量，因为输出不再是“原图事实”，而是在套生图社区常见模板。
|
||
|
||
于是我们明确加入了强禁区：
|
||
|
||
- 禁止社区套话；
|
||
- 禁止品牌/IP/软件名；
|
||
- 风格或媒介只能用普通类别词，且必须有视觉证据。
|
||
|
||
例如允许：
|
||
|
||
- `3D卡通渲染`
|
||
- `日系角色设定插画`
|
||
- `双重曝光合成肖像`
|
||
|
||
不允许：
|
||
|
||
- `Pixar`
|
||
- `Disney`
|
||
- `C4D`
|
||
- `Octane`
|
||
|
||
这一步的作用不是让提示词更“规范”，而是让模型少把自己的视觉语料习惯带进结果。
|
||
|
||
### 3. 第三阶段：从“抽象风格总结”转向“画面类型 + 画面事实”
|
||
|
||
仅仅禁止幻觉还不够。
|
||
|
||
如果模型把图像总结成：
|
||
|
||
- “可爱、梦幻、高级、科技感”
|
||
|
||
即使没有用到禁词，仍然不够可复刻。
|
||
|
||
所以我们继续把提示词约束推向更“事实化”的方向：
|
||
|
||
- 先识别画面类型；
|
||
- 再在这个画面类型内部组织事实。
|
||
|
||
例如不是泛泛说“一个少女插画”，而是：
|
||
|
||
- 角色设定双视图展示图
|
||
- 主播棚拍
|
||
- 代码桌面场景
|
||
- 双重曝光肖像
|
||
- 动物抓拍摄影
|
||
|
||
这样做的原因是：
|
||
|
||
- 复刻一张图，真正关键的不只是主体是什么；
|
||
- 更关键的是它属于什么画面语法。
|
||
|
||
一旦画面语法判断对了，模型更容易保住：
|
||
|
||
- 构图
|
||
- 版式
|
||
- 光线
|
||
- 前中后景关系
|
||
- 特定的拍法或设计语言
|
||
|
||
### 4. 第四阶段：重新定义“变量”是什么
|
||
|
||
后面一个很重要的分歧是：复刻结果里到底要不要变量，以及变量应该是什么。
|
||
|
||
我们最初发现两个问题：
|
||
|
||
- 如果不强调变量，模型容易全部输出 `{}`；
|
||
- 如果太强调变量，模型又会把图里所有名词都抽成变量，反而破坏复刻。
|
||
|
||
因此我们重新定义了变量的产品语义：
|
||
|
||
变量不是“图里出现过的东西”。
|
||
|
||
变量应该是：
|
||
|
||
`用户下次最可能想改、而且改完以后这张图仍然算同一模板的控制位。`
|
||
|
||
基于这个定义，我们得到了几条重要规则：
|
||
|
||
- 变量只是锦上添花，不是主要目标。
|
||
- 风格、媒介、构图、景别、机位、光线、版式、材质、核心氛围、关键合成关系，一般不该变量化。
|
||
- 眼镜款式、毛发细节、动作细节这类低价值或易破坏复刻的内容，也不应优先变量化。
|
||
|
||
优先级则收敛成：
|
||
|
||
- 主体称谓或物种
|
||
- 一种主色
|
||
- 一项短文本或主题
|
||
|
||
并且通常只给 `1-2` 个变量，只有角色设定图或模板感极强的版式图才允许 `3` 个。
|
||
|
||
### 5. 第五阶段：引入“类型感知”的变量策略
|
||
|
||
进一步测试后我们发现，不是所有图都适合变量化。
|
||
|
||
因此又加入了一层类型感知规则：
|
||
|
||
默认考虑变量化的图：
|
||
|
||
- 角色设定图
|
||
- 主播/海报/封面类画面
|
||
- 单主体插画或 3D 吉祥物场景
|
||
|
||
默认不变量化的图：
|
||
|
||
- 抓拍摄影
|
||
- 双重曝光
|
||
- 写实纪实图
|
||
|
||
这样做的目的是：
|
||
|
||
- 不再强求所有输出都有变量；
|
||
- 让 `defaults: {}` 成为一种“合理结果”，而不是模型失败；
|
||
- 只在模板复用价值确实存在时才暴露少量变量。
|
||
|
||
### 6. 第六阶段：验证 LangGPT 风格是否值得引入
|
||
|
||
在此基础上，我们还专门验证了一个问题：
|
||
|
||
是否应把参考图复刻 prompt 改成 `LangGPT` 那类更完整的结构，例如：
|
||
|
||
- `Role`
|
||
- `Profile`
|
||
- `Goal`
|
||
- `Rules`
|
||
- `Workflow`
|
||
- `Initialization`
|
||
|
||
结论是：不值得直接采用完整 LangGPT 结构。
|
||
|
||
原因不是它“理论上不好”，而是实测没有稳定收益。
|
||
|
||
我们做了两轮真实 A/B：
|
||
|
||
- 第一轮：较强的 `LangGPT-lite` 候选，对比当前正式模板；
|
||
- 第二轮：尽量保持语义不变，只调整组织结构，再做一次对比。
|
||
|
||
结果都没有形成稳定优势：
|
||
|
||
- 第一轮是 `3 胜 3 负`；
|
||
- 第二轮也是 `3 胜 3 负`。
|
||
|
||
这说明：
|
||
|
||
- LangGPT 风格会让提示词看起来更分层、更规整；
|
||
- 但对“参考图复刻”这种强约束、多模态、直接产出 JSON 的任务，并没有稳定提升 fidelity。
|
||
|
||
因此最终结论是：
|
||
|
||
- 分析型、评估型、元提示词生成类任务，适合 LangGPT 风格；
|
||
- 参考图复刻与风格迁移，更适合当前这类“目标 + 强约束 + 变量策略 + 输出契约”的写法。
|
||
|
||
换句话说，我们吸收的是它的分节思想，而不是直接套完整模板。
|
||
|
||
---
|
||
|
||
## 四、架构与调用策略的收敛
|
||
|
||
在实现层，我们也经历过一轮从“更干净的分层架构”回到“更短链路”的过程。
|
||
|
||
### 1. 原本尝试过的三段式
|
||
|
||
一度我们把参考图链路拆成：
|
||
|
||
1. `ReferenceSpec`
|
||
2. `PromptDraft`
|
||
3. `VariableizedPrompt`
|
||
|
||
这套架构语义上更清晰，但也带来了问题：
|
||
|
||
- 调用次数增多；
|
||
- 等待时间变长；
|
||
- UI 更容易暴露中间过程；
|
||
- 一旦某一步结果不稳定，用户感知会更差。
|
||
|
||
### 2. 最终收敛成“单次视觉调用优先”
|
||
|
||
后面我们重新聚焦用户目标后，链路也跟着简化了：
|
||
|
||
- `复刻图片`：尽量一次视觉调用直接输出 `prompt + defaults`
|
||
- `风格迁移`：当前提示词与参考图一起参与，直接输出迁移结果和变量
|
||
|
||
这样做的核心考虑是：
|
||
|
||
- 用户关心的是最终可用结果，不关心中间的 spec；
|
||
- 单次调用更快；
|
||
- 中间层越少，越不容易在 UI 和语义上过度设计。
|
||
|
||
因此当前的实现方向是：
|
||
|
||
- 对外保持“一步到位”；
|
||
- 对内只保留必要的结构化契约，不把中间层暴露成产品概念。
|
||
|
||
---
|
||
|
||
## 五、真实测试中得到的结论
|
||
|
||
本轮不是只靠静态推理，我们做了真实多模态测试。
|
||
|
||
主要使用过：
|
||
|
||
- Gemini
|
||
- DashScope `qwen3.5-397b-a17b`
|
||
|
||
由于 Gemini 出现额度和速率限制，后续大量验证主要使用了 `qwen3.5-397b-a17b`。
|
||
|
||
测试图覆盖了多种类型：
|
||
|
||
- 校园熊猫
|
||
- 主播皮卡丘
|
||
- 代码熊猫
|
||
- 二次元双视图设定图
|
||
- 双重曝光肖像
|
||
- 秋日跳跃猫
|
||
|
||
这些测试帮助我们确认了几件事：
|
||
|
||
1. 参考图复刻这条能力是成立的，但必须把目标写成“尽量还原”，而不是“优化成成熟生图提示词”。
|
||
2. 变量可以保留，但只能作为加分项，不能当成核心卖点。
|
||
3. 类型感知变量化是必要的，否则要么全空，要么乱抽。
|
||
4. 完整 LangGPT 化没有形成稳定优势，不值得现在替换正式模板。
|
||
|
||
---
|
||
|
||
## 六、当前阶段的稳定结论
|
||
|
||
截至目前，可以认为我们已经收敛出以下稳定判断：
|
||
|
||
### 产品层
|
||
|
||
- 图像方向不应继续主打“通用提示词优化”。
|
||
- 更有价值的是“参考驱动”的能力：
|
||
- 复刻
|
||
- 风格迁移
|
||
- 定向改造
|
||
- 模板化复用
|
||
|
||
### 提示词层
|
||
|
||
- 参考图复刻的核心目标是 fidelity，不是 prompt polish。
|
||
- 提示词应优先表达：
|
||
- 画面类型
|
||
- 可见事实
|
||
- 画面语法
|
||
- 明确禁区
|
||
- 保守变量策略
|
||
|
||
### 变量层
|
||
|
||
- 变量不是“识别出的名词集合”。
|
||
- 变量是“保留模板骨架下，最值得用户改的少量控制位”。
|
||
|
||
### 方法论层
|
||
|
||
- LangGPT 的“分节思想”值得吸收；
|
||
- 但在参考图复刻任务上，不应直接套完整 LangGPT 模板。
|
||
|
||
---
|
||
|
||
## 七、接下来的重点
|
||
|
||
如果继续沿当前方向推进，后续更值得投入的不是“再发明更多泛化模板”，而是继续打磨以下几点：
|
||
|
||
1. 进一步压制幻觉风格词与 IP/软件名泄漏。
|
||
2. 提升不同画面类型下的 fidelity 稳定性。
|
||
3. 让变量只在真正有模板复用价值时出现。
|
||
4. 继续围绕 `复刻图片 / 风格迁移 / 定向改造` 构建更清晰的能力边界。
|
||
|
||
这意味着我们真正要优化的，已经不是“怎么把图像提示词写得更像提示词”，而是：
|
||
|
||
`怎么让系统更像一个可靠的“参考图翻译器”和“参考驱动改造器”。`
|
||
|
||
---
|
||
|
||
## 相关实现与参考文件
|
||
|
||
- [composition.ts](/C:/Users/15588/.codex/worktrees/8453/prompt-optimizer/packages/core/src/services/template/default-templates/image-prompt-composition/composition.ts)
|
||
- [migration.ts](/C:/Users/15588/.codex/worktrees/8453/prompt-optimizer/packages/core/src/services/template/default-templates/image-prompt-migration/migration.ts)
|
||
- [image-reference-prompt-contracts.test.ts](/C:/Users/15588/.codex/worktrees/8453/prompt-optimizer/packages/core/tests/unit/template/image-reference-prompt-contracts.test.ts)
|
||
- [summary.json](/C:/Users/15588/.codex/worktrees/8453/prompt-optimizer/.codex/tmp/prompt-optimizer/20260401-langgpt-lite-eval/summary.json)
|
||
- [summary.json](/C:/Users/15588/.codex/worktrees/8453/prompt-optimizer/.codex/tmp/prompt-optimizer/20260401-langgpt-lite-eval-v2/summary.json)
|