Back to Prompt Optimizer

参考图与图像提示词优化过程总结

docs/workspace/image-reference-prompt-optimization/README.md

2.10.214.2 KB
Original Source

参考图与图像提示词优化过程总结

文档目的

这份文档用于沉淀本轮图像相关产品与提示词优化的收敛过程,重点回答两个问题:

  1. 我们为什么从“通用图像提示词优化”逐步转向“参考图驱动”。
  2. 在参考图链路里,提示词本身是如何一步步从“泛化优化”收敛到“复刻优先”的。

本文不追求记录所有中间讨论细节,而是保留真正影响当前方案的关键判断、提示词演化逻辑、测试结论与后续工作重心。


关联文档


一、产品路线的收敛过程

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. 继续围绕 复刻图片 / 风格迁移 / 定向改造 构建更清晰的能力边界。

这意味着我们真正要优化的,已经不是“怎么把图像提示词写得更像提示词”,而是:

怎么让系统更像一个可靠的“参考图翻译器”和“参考驱动改造器”。


相关实现与参考文件