1225 lines
54 KiB
Plaintext
1225 lines
54 KiB
Plaintext
你现在真实能调用哪些创作工具？请区分实际可生成和只能建议的能力。”
|
||
以下是我实际可调用的创作工具，按能力类型分类：
|
||
|
||
🎨 图片生成与编辑
|
||
实际可生成：
|
||
|
||
文生图 — 根据文字描述生成图片
|
||
图生图 — 基于参考图转换/重绘
|
||
局部编辑 — 定向修改图片局部区域（inpainting）
|
||
风格转换 — 全局风格重绘
|
||
比例裁切 — 修改图片宽高比（reframe）
|
||
分辨率提升 — 图片超分放大（upscale，最高支持 8K）
|
||
🎬 视频生成与编辑
|
||
实际可生成：
|
||
|
||
文生视频 — 根据文字描述生成视频片段
|
||
图生视频 — 以图片为首帧/尾帧生成视频
|
||
视频编辑 — 对已有视频进行风格/内容修改
|
||
参考视频生成 — 提取参考视频的动作/风格生成新视频
|
||
🎵 音频生成
|
||
实际可生成：
|
||
|
||
背景音乐（BGM） — 根据风格/情绪描述生成音乐（基于 Suno）
|
||
文字转语音（TTS） — 单人旁白、双人对话/播客/访谈
|
||
BGM + 配音组合 — 为同一视频协同生成背景音乐和旁白
|
||
🎞 后期成片
|
||
实际可生成：
|
||
|
||
多片段拼接 — 将多个视频/图片素材按顺序合成
|
||
BGM + 配音混音 — 将音频轨道混入视频
|
||
字幕叠加 — 手动字幕或自动语音转字幕
|
||
自定义字体生成 — 从参考图或风格描述生成品牌字体（TTF）
|
||
图片超分 — 作为后期流程的一环
|
||
🔍 对齐与参考收集（辅助能力，不直接输出媒体）
|
||
工具 用途
|
||
网页搜索 收集真实人物、品牌、风格参考图
|
||
网页内容分析 解析用户提供的 URL（图片/视频/PDF/网页）
|
||
品牌资产读取 提取品牌色、Logo、字体等设计规范
|
||
Pinterest / Google Drive 连接 从用户账号拉取素材
|
||
❌ 不在范围内的能力
|
||
HTML / 前端页面 / 交互应用
|
||
代码生成与执行
|
||
3D 模型建模
|
||
视频实时预览或流式播放
|
||
对已有音频进行混音（只能生成新音频，混音由成片工具完成）
|
||
有具体创作需求随时告诉我，我会直接执行。
|
||
|
||
“我说‘帮 still day 做品牌官网首页’，你内部会怎么拆任务？先别生成，解释你的判断流程。”
|
||
判断流程说明
|
||
收到这个请求后，我会按以下顺序判断：
|
||
|
||
第一步：范围判断
|
||
"品牌官网首页" = HTML 页面 + 前端交互 + 代码结构。
|
||
|
||
这属于 HTML/前端页面/代码类产物，不在我的交付范围内。我的能力边界是 AI 媒体生产：图片、视频、音频、成片资产。
|
||
|
||
第二步：判断是否有可拆解的媒体子任务
|
||
虽然整个官网不能交付，但官网首页通常包含若干媒体生产子任务，这些是我能做的：
|
||
|
||
子任务 类型 我能做？
|
||
Hero 区主视觉图 图片生成 ✅
|
||
品牌氛围视频/Loop 视频 视频生成 ✅
|
||
产品展示图/场景图 图片生成 ✅
|
||
品牌 BGM / 环境音 音频生成 ✅
|
||
自定义品牌字体 字体生成 ✅
|
||
页面 HTML 布局与交互 前端代码 ❌
|
||
响应式排版实现 前端代码 ❌
|
||
第三步：对齐缺口识别
|
||
即便只做媒体子任务，当前信息也不足以直接生成，需要确认：
|
||
|
||
Still Day 是什么品牌？ — 行业、产品、调性完全未知，需要搜索或用户补充
|
||
已有品牌资产？ — Logo、主色、字体、现有视觉有没有可参考的
|
||
用户实际想要什么？ — 是想要首页设计稿（图片）？还是媒体素材？还是误以为我能做整站？
|
||
结论
|
||
我会直接告诉你：官网首页本身超出我的交付范围，但如果你需要首页用到的媒体资产（主视觉、氛围视频、品牌字体等），我可以承接。
|
||
|
||
你实际想要的是哪部分？ 或者 Still Day 是你自己的品牌，可以告诉我更多背景，我来判断哪些媒体资产我可以帮你做。
|
||
|
||
“什么情况下你会先问我问题，而不是直接生图？”
|
||
只有以下几种情况我会先问你，其余情况我会直接生成：
|
||
|
||
会先问的情况
|
||
1. 多张独立图共享同一个新主体，但没有一致性锚点
|
||
比如你说"帮我生成这件衬衫的正面、侧面、背面三张图"，但没有提供任何人物/模特参考。三张图必须是同一个人穿同一件衣服，我没有锚点无法保证一致性，需要先确认或生成锚点。
|
||
|
||
2. 关键事实我无法从对话或工具中获取
|
||
比如你说"用 Still Day 的品牌风格生成一张海报"，但 Still Day 是什么品牌、什么调性、有没有视觉规范，我完全不知道。这时我会先搜索或问你。
|
||
|
||
3. 请求超出我的交付范围，需要澄清你真正想要什么
|
||
比如上面的官网例子，我不确定你要的是整站还是媒体素材，需要先对齐。
|
||
|
||
不会问、直接生成的情况
|
||
你提供了足够的描述，哪怕我觉得提示词可以更好
|
||
我只是想补充审美词、镜头词、画质词、材质颜色描述——这不是问你的理由
|
||
多张"同风格""同色调""同系列"图，不涉及同一个新主体的身份一致性
|
||
一张九宫格、四视图、角色设定表——内部多个格子默认一次生成，不需要问
|
||
参考图的用途从你的原话可以明显判断出来
|
||
一句话原则
|
||
问题只服务于我无法自行解决的事实缺口，不服务于让结果"更好看"。
|
||
|
||
如果你不确定某个请求我会不会直接动手，直接发过来就行。
|
||
|
||
“如果我只说‘不够高级’，你会如何把它拆成具体修改项？”
|
||
这是个好问题，答案是：我不会自己拆。
|
||
|
||
原因
|
||
"不够高级"是你的主观判断，不是修改指令。
|
||
|
||
如果我自己把它拆成"增加留白、调暗背景、换细线字体、降低饱和度……"，那些是我的审美解读，不是你的原话。按规则，我不能把经验知识和多模态推断写进修改指令。
|
||
|
||
我实际会做的事
|
||
如果画布上有已生成的图
|
||
我会看一眼当前图，然后直接问你一个聚焦的问题：
|
||
|
||
"高级感不够，是觉得哪个方向？颜色太杂、排版太满、质感不对、还是整体氛围差太远？"
|
||
|
||
给你几个方向选，而不是让你从零描述。
|
||
|
||
如果你懒得说
|
||
你可以直接给我一张"你觉得够高级"的参考图，我按那张图的方向改，不需要你语言化。
|
||
|
||
如果你就是想让我自己判断
|
||
你可以说"你觉得怎么改更高级就怎么改"——这是你的明确授权，我才会用自己的判断动手，并告诉你我改了什么方向。
|
||
|
||
一句话原则
|
||
"不够高级"是反馈，不是指令。我需要把它变成你确认过的修改方向，才会动手。
|
||
|
||
“你会如何记住 still day 的品牌约束，并在下一轮继续使用？”
|
||
直接说结论：我没有跨对话的持久记忆。
|
||
|
||
实际工作方式
|
||
在同一次对话内
|
||
我能记住你说过的所有内容——品牌色、字体、调性、你确认过的参考图、你否定过的方向。这一轮对话里，Still Day 的约束会持续生效。
|
||
|
||
跨对话（新开一个对话）
|
||
上一轮的内容完全清空。我不会自动记住 Still Day 是什么品牌。
|
||
|
||
你能做的事
|
||
1. 保存品牌资产到画布
|
||
如果你把 Logo、主色板、参考图放在画布上，下次打开同一个项目，这些素材还在，我可以直接读取画布状态继续工作。
|
||
|
||
2. 开头直接告诉我
|
||
每次新对话开始时，一句话带上约束：
|
||
|
||
"Still Day 是极简护肤品牌，主色是米白和深绿，风格参考这张图"
|
||
|
||
我立刻生效，不需要你重复解释背景。
|
||
|
||
3. 使用品牌资产工具
|
||
如果你在平台上建立了品牌资产包（Brand Kit），我可以通过工具直接读取，不依赖你手动复述。
|
||
|
||
一句话原则
|
||
约束活在这次对话或画布资产里，不活在我的记忆里。管理品牌一致性，画布比对话更可靠。
|
||
|
||
“你搜索参考时会怎么改写我的需求？搜索结果怎么进入生图 prompt？”
|
||
两个问题分开说清楚。
|
||
|
||
第一个问题：我会怎么改写你的需求去搜索？
|
||
不改写你的需求本身，但会拆解搜索目标。
|
||
|
||
搜索工具有自己的内部分解逻辑，我只需要告诉它：
|
||
|
||
背景是什么（你的项目目标）
|
||
现在要找什么（具体搜索对象）
|
||
比如你说"用黄海的风格做一张海报"，我传给搜索工具的是：
|
||
|
||
背景：做一张黄海风格的海报
|
||
任务：找黄海的代表作品和视觉语言示例
|
||
我不会把"黄海风格"翻译成"中国电影海报大留白极简构图"再去搜——那是我的解读，不是你的原话。
|
||
|
||
第二个问题：搜索结果怎么进入生图 prompt？
|
||
结论：搜索结果不会自动进入 prompt 文字。
|
||
|
||
具体规则是：
|
||
|
||
搜索图可以做的事
|
||
作为 reference_image_urls 传给生图工具——让模型直接看图理解风格
|
||
作为一致性锚点，在你确认后用于后续多张图
|
||
搜索图不能做的事
|
||
我不会把图里看到的内容转述成文字写进 prompt
|
||
比如搜到黄海的海报是"大面积留白+人物居中+水墨晕染"，我不会把这些描述词写进 prompt
|
||
为什么
|
||
因为那是我对搜索结果的多模态解读，不是你的原话。写进 prompt 就变成了我替你做的审美决策。
|
||
|
||
唯一的例外
|
||
你明确说"就按这张图的风格来"——这是你的确认，我才会把这张图的 URL 作为参考图传入，让模型自己去理解，而不是我转述。
|
||
|
||
一句话原则
|
||
搜索结果以图片 URL 的形式影响生成，不以我的文字描述的形式影响 prompt。你的原话才能进 prompt。
|
||
|
||
“你给图片模型的最终 prompt 大概长什么样？请展示结构，不要真实生成。”
|
||
用一个具体假设场景展示结构，不触发生成。
|
||
|
||
假设请求
|
||
"参考这张图，帮 Still Day 做一张护肤品的春季海报，竖版"
|
||
|
||
最终工具调用结构
|
||
task_type : generate_image
|
||
|
||
prompt : 参考这张图，帮 Still Day 做一张护肤品的春季海报，竖版
|
||
↑ 用户原话机械复述，不增不减
|
||
|
||
reference_image_urls : https://xxx.cdn/user-uploaded.jpg
|
||
↑ 用户提供的参考图 URL，原样传入，不描述图里的内容
|
||
|
||
aspect_ratio : 9:16
|
||
↑ "竖版"映射到比例参数
|
||
|
||
output_name : Still Day 春季护肤海报
|
||
|
||
tool_hint : （空）
|
||
↑ 用户没有指定模型，不填
|
||
每个字段的来源说明
|
||
字段 内容来源 禁止写入的内容
|
||
prompt 用户原话，机械复述 我对参考图的视觉描述、审美增强词、镜头词、材质颜色推断
|
||
reference_image_urls 用户提供的 URL 原样 不能是我猜的地址、搜索结果未经确认的图
|
||
aspect_ratio 用户说"竖版"→ 映射规则转换 不能忽略尺寸信息
|
||
output_name 用户语言命名 不用英文（除非用户用英文）
|
||
tool_hint 用户显式指定模型时才填 不能自行假设填写
|
||
prompt 里绝对不会出现的内容
|
||
❌ 米白色背景，极简构图，高饱和春日绿植
|
||
↑ 颜色是我从参考图推断的
|
||
|
||
❌ 柔和自然光，浅景深，高端质感
|
||
↑ 审美增强词，用户没说
|
||
|
||
❌ The image shows a skincare product...
|
||
↑ 不翻译成英文
|
||
|
||
❌ 参考图中的产品瓶身呈现磨砂质感...
|
||
↑ 不把参考图内容转述进 prompt
|
||
一句话原则
|
||
prompt = 用户原话。视觉信息走 URL 字段，不走文字描述。
|
||
|
||
“如果我说‘没有上一版色彩好看，但要更大厂’，你会如何保留和修改？”
|
||
拆开来说清楚。
|
||
|
||
首先识别这句话里有几个指令
|
||
部分 类型 含义
|
||
"没有上一版色彩好看" 保留指令 上一版的色彩方案要继承
|
||
"但要更大厂" 修改指令 在色彩不变的基础上，调整某个维度
|
||
我会怎么处理
|
||
色彩部分——保留
|
||
上一版图片的 URL 已经在画布上，我会把它放进 reference_image_urls，让模型直接看上一版的色彩，不需要我用文字描述"那版是什么颜色"。
|
||
|
||
"更大厂"部分——需要对齐
|
||
这是我唯一会停下来问你的地方。
|
||
|
||
"大厂感"是主观判断，不是修改指令。我不会自己把它拆成：
|
||
|
||
❌ 更多留白 / 字体更细 / 去掉装饰元素 / 色块更克制
|
||
|
||
那是我的审美解读，不是你的原话。
|
||
|
||
我会问你一个聚焦的问题：
|
||
|
||
"更大厂是指哪个方向——排版更简洁、质感更精致、还是整体更有国际品牌感？或者你有一个参考品牌/图片？"
|
||
|
||
你回答后，工具调用长这样
|
||
task_type : edit_image 或 generate_image
|
||
|
||
prompt : 保留上一版的色彩，[你确认的大厂方向原话]
|
||
|
||
reference_image_urls : https://xxx.cdn/上一版图片.jpg
|
||
↑ 色彩锚点，原样传入
|
||
如果你懒得描述"大厂"
|
||
直接扔给我一张你觉得够大厂的品牌图，我用它做视觉参考，不需要你语言化。
|
||
|
||
一句话原则
|
||
色彩保留靠上一版 URL，不靠我转述颜色。"更大厂"是反馈不是指令，需要你确认方向后才动手。
|
||
|
||
“你怎么决定一次生成 1 张、3 张还是 4 张图？”
|
||
数量由你的需求决定，不是我自己选的。拆开说清楚。
|
||
|
||
决定数量的唯一依据：最终交付物台账
|
||
我会先问自己：用户最终要收到几张独立的图？
|
||
|
||
不是看你列了几个修改动作，不是看描述有多复杂。
|
||
|
||
三种典型情况
|
||
情况一：生成 1 张
|
||
你的需求指向一个最终资产，不管内部有多少元素。
|
||
|
||
"帮我做一张九宫格人设图" → 1 张（九宫格是一张图的内部排版）
|
||
"正面+侧面+背面三视图海报" → 1 张（三视图是一张图里的内容）
|
||
"改一下背景颜色，再加个 Logo" → 1 张（两个动作服务同一张图）
|
||
情况二：生成多张，但需要先建锚点
|
||
你要多张独立的图，而且它们共享同一个新主体，但没有一致性参考。
|
||
|
||
"同一个模特穿这件衬衫，生成正面、侧面、背面三张图"
|
||
→ 模特是新生成的，三张图必须是同一个人
|
||
→ 先生成或确认模特锚点，再并行生成 3 张
|
||
→ 最终交付 3 张，但不能直接跳到 3 张
|
||
情况三：生成多张，直接并行
|
||
你明确要多张独立图，且不涉及新主体一致性问题。
|
||
|
||
"生成 4 个不同风格的封面方案" → 4 张，直接并行生成
|
||
"做 3 张不同场景的产品图" → 3 张，直接并行生成
|
||
"同风格的春夏秋冬四张海报" → 4 张，直接并行生成
|
||
不会影响数量的因素
|
||
这些不决定数量 原因
|
||
描述有多复杂 复杂描述可以是一张图的内容
|
||
列了几个修改动作 多个动作服务同一张图就是 1 张
|
||
我觉得"多几个方案更好" 用户没要求就不主动加
|
||
任务看起来重要 重要性不等于数量多
|
||
一句话原则
|
||
数量 = 你最终要收到几张独立的图。我数交付物，不数动作、不数格子、不数我的判断。
|
||
|
||
“如果生成失败一半，你会怎么处理已经成功的结果？”
|
||
直接说我的处理方式。
|
||
|
||
基本原则
|
||
已成功的结果不会重新生成，失败的部分单独补。
|
||
|
||
具体处理流程
|
||
第一步：展示已成功的结果
|
||
成功的图/视频/音频正常交付给你，不扣押、不等失败的补完再一起给。
|
||
|
||
第二步：明确告诉你哪个失败了
|
||
说清楚是第几张、哪个任务、失败在哪个环节，不模糊带过。
|
||
|
||
第三步：直接重试失败的部分
|
||
用完全相同的参数重新调用，不改 prompt、不改参考图、不趁机"优化"。
|
||
|
||
几种具体场景
|
||
场景一：4 张里失败 1 张
|
||
交付成功的 3 张
|
||
告知第 4 张失败
|
||
直接重试第 4 张，参数不变
|
||
场景二：锚点成功，但依赖锚点的终图失败
|
||
锚点图已确认 → 保留
|
||
直接用同一个锚点 URL 重试失败的终图
|
||
不重新生成锚点
|
||
场景三：失败原因明确是参数问题
|
||
比如尺寸不支持、模型限制触发，我会告诉你具体原因，并说明需要调整什么，等你确认再重试，不自作主张改参数。
|
||
|
||
场景四：连续重试仍然失败
|
||
告诉你失败原因，不继续无意义重试，让你决定下一步——换参数、换模型、还是放弃这张。
|
||
|
||
不会做的事
|
||
把成功的结果重新生成"保持一致"
|
||
趁重试机会改 prompt 或"顺手优化"
|
||
沉默等待所有任务结束再统一汇报
|
||
自行决定用不同参数重试而不告知你
|
||
一句话原则
|
||
成功的保留，失败的补。补的时候参数不变，除非你说要改。
|
||
|
||
你内部判断任务类型时，intent 有哪些？比如 chat / image / edit / video / audio / clarify / search，是固定枚举吗？”
|
||
直接说实情：我没有固定的 intent 枚举表。
|
||
|
||
我实际的判断方式
|
||
不是先分类再执行，而是直接走一个决策流程：
|
||
|
||
用户说了什么
|
||
↓
|
||
在我的交付范围内吗？
|
||
（图片 / 视频 / 音频 / 成片 → 是；HTML / 代码 / 交互 → 否）
|
||
↓
|
||
需要补充信息吗？
|
||
（关键事实缺失 / 一致性锚点缺失 → 先对齐；信息足够 → 直接执行）
|
||
↓
|
||
最终交付物是什么类型、几个？
|
||
（定义台账：数量 / 源素材 / 操作 / 锚点）
|
||
↓
|
||
选工具和参数
|
||
（generate_media / edit_media / audio_agent / media_finishing_agent）
|
||
↓
|
||
执行
|
||
你列的那些标签对应的实际处理
|
||
你说的标签 我实际对应的判断
|
||
chat 不涉及媒体生产，直接回答
|
||
image 新建图片 → generate_media
|
||
edit 修改已有图片 → edit_media edit_image / reframe / upscale
|
||
video 新建或编辑视频 → generate_media 或 edit_media edit_video
|
||
audio 音频生成 → audio_agent
|
||
clarify 关键信息缺口，需要对齐才能执行
|
||
search 需要外部事实 → grounded_search 或 web_fetch
|
||
finishing 已有素材的后期合成 → media_finishing_agent
|
||
但这些不是我内部的枚举值，是我根据需求内容自然推导出来的工具选择。
|
||
|
||
为什么没有固定枚举
|
||
因为一个请求可以同时触发多个"类型"：
|
||
|
||
"搜一下黄海的海报风格，然后帮我生成一张竖版海报"
|
||
→ 先 search，再 image
|
||
→ 不是单一 intent，是一个有依赖关系的执行序列
|
||
固定枚举会强迫每个请求归入一个桶，但实际任务经常是跨桶的。
|
||
|
||
一句话原则
|
||
我判断的不是"这是什么类型的请求"，而是"要交付什么、用什么工具、按什么顺序"。工具选择是结果，不是分类标签。
|
||
|
||
“请展示一次完整工具调用的 JSON 结构，包含文生图、图生图、局部编辑、扩图、超分分别有哪些字段。”
|
||
用同一个假设场景展示五种调用结构，不触发生成。
|
||
|
||
1. 文生图
|
||
{
|
||
"task_type": "generate_image",
|
||
"output_name": "Still Day 春季海报",
|
||
"prompt": "帮 Still Day 做一张护肤品的春季海报，竖版",
|
||
"aspect_ratio": "9:16",
|
||
"tool_hint": ""
|
||
}
|
||
字段说明：
|
||
|
||
无任何图片输入
|
||
prompt 纯文字描述
|
||
尺寸信息映射到 aspect_ratio
|
||
2. 图生图（参考图生成）
|
||
{
|
||
"task_type": "generate_image",
|
||
"output_name": "Still Day 风格重绘",
|
||
"prompt": "参考这张图，生成一张 Still Day 护肤品海报",
|
||
"reference_image_urls": "https://cdn.xxx/reference.jpg",
|
||
"aspect_ratio": "9:16",
|
||
"tool_hint": ""
|
||
}
|
||
字段说明：
|
||
|
||
用户提到的图通过 reference_image_urls 传入
|
||
prompt 不描述图里的内容，只复述用户原话
|
||
多张参考图用逗号分隔，顺序与用户原话一致
|
||
3. 局部编辑（定向修改）
|
||
{
|
||
"task_type": "edit_image",
|
||
"output_name": "Still Day 海报局部修改",
|
||
"prompt": "把左上角的 Logo 换成白色，背景改成米白色",
|
||
"reference_image_urls": "https://cdn.xxx/current-poster.jpg",
|
||
"tool_hint": ""
|
||
}
|
||
字段说明：
|
||
|
||
task_type 是 edit_image，不是 generate_image
|
||
被编辑的图通过 reference_image_urls 传入
|
||
prompt 只写用户指定的修改动作，不描述图的现有内容
|
||
4. 扩图（比例修改）
|
||
{
|
||
"task_type": "reframe",
|
||
"output_name": "Still Day 海报扩图",
|
||
"prompt": "",
|
||
"source_image_url": "https://cdn.xxx/current-poster.jpg",
|
||
"aspect_ratio": "16:9"
|
||
}
|
||
字段说明：
|
||
|
||
task_type 是 reframe
|
||
被处理的图走 source_image_url，不走 reference_image_urls
|
||
prompt 留空，reframe 是纯机械操作
|
||
目标比例映射到 aspect_ratio
|
||
5. 超分（分辨率提升）
|
||
{
|
||
"task_type": "upscale",
|
||
"output_name": "Still Day 海报超分",
|
||
"prompt": "",
|
||
"source_image_url": "https://cdn.xxx/current-poster.jpg",
|
||
"target_longest_size": 4096
|
||
}
|
||
字段说明：
|
||
|
||
task_type 是 upscale
|
||
被处理的图走 source_image_url，不走 reference_image_urls
|
||
prompt 留空
|
||
目标分辨率映射到 target_longest_size（像素值）
|
||
字段归属对照表
|
||
字段 文生图 图生图 局部编辑 扩图 超分
|
||
task_type generate_image generate_image edit_image reframe upscale
|
||
prompt ✅ 用户原话 ✅ 用户原话 ✅ 用户原话 ⬜ 留空 ⬜ 留空
|
||
reference_image_urls ❌ ✅ ✅ ❌ ❌
|
||
source_image_url ❌ ❌ ❌ ✅ ✅
|
||
aspect_ratio 按需 按需 按需 ✅ ❌
|
||
target_longest_size ❌ ❌ ❌ ❌ ✅
|
||
tool_hint 指定时填 指定时填 指定时填 ❌ ❌
|
||
一句话原则
|
||
source_image_url 只给 reframe / upscale 用。其他所有情况下用户提到的图都走 reference_image_urls。
|
||
|
||
“如果用户上传多张参考图，你怎么判断每张图的角色？比如 logo、商品图、风格图、色彩参考、构图参考。”
|
||
直接说判断逻辑。
|
||
|
||
判断来源只有一个：用户原话
|
||
我不会自己看图然后猜"这张应该是风格参考"。角色必须来自用户明确说的话。
|
||
|
||
三种情况
|
||
情况一：用户明确说了每张图的用途
|
||
直接按原话映射，不做任何解读。
|
||
|
||
"图1做风格参考，图2是产品主体，图3用Logo"
|
||
→ 图1 → reference_image_urls（风格参考）
|
||
→ 图2 → reference_image_urls（产品主体）
|
||
→ 图3 → reference_image_urls（Logo来源）
|
||
→ prompt 里保留用户原话的角色描述
|
||
情况二：用户没说角色，但从原话可以明显推断
|
||
从请求的动词、语境直接映射，不需要问。
|
||
|
||
"参考这张图的构图，重新生成一张产品图"
|
||
→ 这张图 = 构图参考，原话已经说清楚了
|
||
|
||
"把这个Logo放到海报右下角"
|
||
→ 这张图 = Logo素材，用途显而易见
|
||
|
||
"用这张图的色调生成春季海报"
|
||
→ 这张图 = 色彩参考，原话明确
|
||
情况三：用户上传了多张图，但没说任何角色
|
||
这时我不猜，直接问一个聚焦的问题：
|
||
|
||
"这几张图分别怎么用？比如哪张是风格参考、哪张是产品主体？"
|
||
|
||
角色确认后怎么进工具字段
|
||
所有用户明确指定用途的参考图，统一走 reference_image_urls，按用户原话的语义顺序排列。角色描述保留在 prompt 里。
|
||
|
||
{
|
||
"prompt": "图1做风格参考，图2是产品主体，图3用Logo，生成一张春季海报",
|
||
"reference_image_urls": "https://cdn.xxx/style.jpg, https://cdn.xxx/product.jpg, https://cdn.xxx/logo.jpg"
|
||
}
|
||
绝对不会做的事
|
||
禁止行为 原因
|
||
看图自动判断"这张是风格图" 多模态理解不能替代用户指定
|
||
把搜索结果图自动归入某个角色 未经用户确认不能写入用途映射
|
||
把图里的视觉内容转述进 prompt 不描述参考图的内容，只传 URL
|
||
自行决定某张图"更适合做色彩参考" 角色分配权在用户，不在我
|
||
一句话原则
|
||
图的角色来自用户原话，不来自我看图的判断。原话说清楚了直接映射，没说清楚就问，不猜。
|
||
|
||
“搜索到的参考图在什么情况下会自动进入 reference_image_urls？是否需要用户确认？”
|
||
直接说规则：需要用户确认，不会自动进入。
|
||
|
||
完整规则
|
||
搜索结果图的默认状态
|
||
搜索完成后，图片作为候选参考展示给你，不自动写入任何工具字段。
|
||
|
||
进入 reference_image_urls 的唯一条件
|
||
你明确选择或确认某张搜索图要用。
|
||
|
||
✅ "就用第二张，做风格参考"
|
||
✅ "这张不错，按这个方向生成"
|
||
✅ "把搜到的第一张作为构图参考"
|
||
→ 以上都是明确确认，我才把对应 URL 写入 reference_image_urls
|
||
未确认的搜索结果不能做的三件事
|
||
禁止行为 具体说明
|
||
自动写入 reference_image_urls 即使我觉得某张图"很合适"
|
||
转述图片内容写进 prompt 不能把搜索图描述成视觉事实
|
||
作为一致性锚点使用 锚点必须是已确认的参考
|
||
一个容易混淆的场景
|
||
你说："搜一下黄海的海报风格，然后帮我生成一张"
|
||
|
||
错误处理：搜完直接把搜索结果图塞进 reference_image_urls 生成
|
||
正确处理：把搜索结果展示给你 → 等你确认用哪张或说"直接生成" → 再执行
|
||
唯一的例外
|
||
你在请求里直接授权：
|
||
|
||
"搜黄海的风格，找到后直接用最相关的那张生成"
|
||
→ 这是你的明确授权
|
||
→ 我可以选最相关的图写入 reference_image_urls
|
||
→ 但我会告诉你用了哪张，不会沉默处理
|
||
一句话原则
|
||
搜索图是候选，不是素材。从候选变成素材，需要你说一句"用这张"。
|
||
|
||
“如果用户说‘参考 COS / Acne / Apple 官网’，你会把这些品牌词写进 prompt，还是先搜索图片作为参考？”
|
||
直接说判断：先搜索，不写进 prompt。
|
||
|
||
为什么不直接写进 prompt
|
||
"COS / Acne / Apple 官网风格"是品牌专有名词，不是视觉描述。
|
||
|
||
如果我把它直接写进 prompt：
|
||
|
||
模型不一定能准确理解这些品牌的具体视觉语言
|
||
我也不能把"Apple 官网风格"自己翻译成"极简留白、大字体、冷白背景"写进去——那是我的经验解读，不是你的原话
|
||
实际处理流程
|
||
第一步：搜索品牌视觉参考
|
||
用 grounded_search 找这些品牌的官网截图、视觉语言示例、代表性页面图。
|
||
|
||
第二步：把搜索结果展示给你
|
||
作为候选参考图呈现，不自动使用。
|
||
|
||
第三步：等你确认
|
||
✅ "用 Apple 那张，做风格参考"
|
||
✅ "三个品牌都参考，偏 COS 的排版"
|
||
✅ "直接用搜到的最相关的"
|
||
→ 确认后写入 reference_image_urls
|
||
第四步：生成
|
||
{
|
||
"prompt": "参考 COS / Acne / Apple 官网风格，生成一张产品海报",
|
||
"reference_image_urls": "https://cdn.xxx/cos-ref.jpg, https://cdn.xxx/apple-ref.jpg"
|
||
}
|
||
prompt 保留你的原话，视觉信息通过确认后的图片 URL 传入。
|
||
|
||
如果你同时提供了官网链接
|
||
"参考这个 https://www.cos.com 的风格"
|
||
→ 用户给了具体 URL
|
||
→ 直接用 web_fetch 抓取页面内容和截图
|
||
→ 不需要搜索，不需要猜
|
||
一句话原则
|
||
品牌词是搜索线索，不是 prompt 内容。视觉语言通过图片 URL 传入，不通过我对品牌的经验描述传入。
|
||
|
||
“当用户说‘你觉得怎么改就怎么改’时，你会如何把自己的审美判断转成工具参数和 prompt？”
|
||
这是少数几个我可以主动动手的场景，但有一套明确的处理方式。
|
||
|
||
为什么这句话是有效授权
|
||
"你觉得怎么改就怎么改"是你把审美决策权显式交给我。这是唯一让我可以用自己判断填补 prompt 的情况。
|
||
|
||
我会做的四件事
|
||
第一件：基于当前图做判断，不凭空发挥
|
||
我会看画布上的图，识别最明显的问题点，比如：
|
||
|
||
信息层级混乱
|
||
色彩对比不足
|
||
留白比例失调
|
||
字体与风格不匹配
|
||
只针对可观察到的问题提出修改，不做"让它更好看"的泛化增强。
|
||
|
||
第二件：把判断转成具体修改动作，不转成审美形容词
|
||
❌ 让整体更高级、更精致、更有质感
|
||
✅ 减少背景元素，增加留白比例
|
||
✅ 标题字号放大，正文字号缩小，拉开层级差
|
||
✅ 背景色从暖白调整为冷白
|
||
第三件：修改动作直接写进 prompt
|
||
{
|
||
"prompt": "减少背景装饰元素，增加留白；标题字号放大与正文拉开层级；背景色调整为冷白",
|
||
"reference_image_urls": "https://cdn.xxx/current.jpg"
|
||
}
|
||
不写"更高级""更大厂""更精致"——这些是结果描述，不是修改指令，模型无法执行。
|
||
|
||
第四件：执行后告诉你我改了什么方向
|
||
生成完成后说明：
|
||
|
||
"我判断主要问题是层级不清和留白不足，调整了字号比例和背景密度，你看是否符合预期。"
|
||
|
||
让你知道我的判断逻辑，方便你下一轮纠正方向。
|
||
|
||
我不会做的事
|
||
禁止行为 原因
|
||
把审美判断写成形容词堆进 prompt 模型执行不了"更高级"
|
||
修改你没有问题的部分 授权是"怎么改"，不是"全部重做"
|
||
沉默执行不说明改了什么 你需要知道方向才能纠正
|
||
把多模态观察写成视觉事实描述进 prompt 规则限制，即使有授权也不描述图片内容
|
||
一句话原则
|
||
授权让我可以做判断，但判断必须转成具体可执行的修改动作写进 prompt，不能转成审美形容词。执行后我会说明改了什么，让你保持控制权。
|
||
|
||
“如果用户连续说 v1 不好、v2 好一点、v3 色彩更好，你怎么决定下一版继承哪一版？”
|
||
直接说判断逻辑。
|
||
|
||
核心原则
|
||
每一轮反馈都是增量指令，不是全量替换。 我需要追踪每个维度的最新状态，而不是只看最后一句话。
|
||
|
||
追踪方式：按维度记录最优版本
|
||
把用户的反馈拆成独立维度，每个维度记录最后一次明确认可的版本：
|
||
|
||
维度 v1 v2 v3 当前最优
|
||
整体方向 ❌ 不好 ✅ 好一点 （未提） v2
|
||
色彩 （未提） （未提） ✅ 更好 v3
|
||
其他维度 （未提） （未提） （未提） 未确认
|
||
下一版的构建逻辑
|
||
整体方向基础 → 继承 v2
|
||
色彩方案 → 继承 v3
|
||
用户新指令 → 叠加在以上基础上
|
||
两张图都进 reference_image_urls，prompt 里说明各自的继承用途：
|
||
|
||
{
|
||
"prompt": "继承 v2 的整体方向，使用 v3 的色彩方案，[用户新的修改指令]",
|
||
"reference_image_urls": "https://cdn.xxx/v2.jpg, https://cdn.xxx/v3.jpg"
|
||
}
|
||
几种容易判断错的情况
|
||
"v3 色彩更好"不等于"v3 整体更好"
|
||
用户只认可了 v3 的色彩，没有说整体推翻 v2。不能把 v3 当成唯一基础。
|
||
|
||
用户说"好一点"不等于"完全满意"
|
||
v2 是当前整体方向的最优选，但不代表 v2 所有维度都被认可，未被提及的维度视为待确认。
|
||
|
||
最新一句话不自动覆盖所有之前的认可
|
||
v1 不好 → v2 好一点 → v3 色彩更好
|
||
最后一句只更新了色彩维度，不覆盖 v2 的整体方向认可
|
||
如果维度之间有冲突
|
||
比如 v2 的整体构图和 v3 的色彩在同一张图里无法共存，我会先问你：
|
||
|
||
"v2 的构图和 v3 的色彩在这里有冲突，优先保哪个？"
|
||
|
||
不自作主张取舍。
|
||
|
||
一句话原则
|
||
继承不是选一个版本，是按维度拼最优状态。每个维度的最新明确认可就是这个维度的当前锚点。
|
||
|
||
“你怎么区分 edit_image 和 generate_image？什么时候是基于上一版修改，什么时候是重新生成？”
|
||
直接说判断规则。
|
||
|
||
核心判断标准
|
||
用户是否要求保留原图的某个基础状态。
|
||
|
||
不是看修改幅度大小，不是看描述复不复杂。
|
||
|
||
两种情况的判断树
|
||
用户需要保留原图的某个部分或状态？
|
||
↓
|
||
是 → edit_image（基于原图定向修改）
|
||
↓
|
||
否 → generate_image（重新生成）
|
||
edit_image 的典型场景
|
||
用户明确要在原图基础上改，原图是操作对象：
|
||
|
||
"把背景换成白色" → 保留主体，改背景
|
||
"去掉左上角的文字" → 保留其余，改局部
|
||
"把产品颜色改成黑色" → 保留构图，改颜色
|
||
"Logo 换成这个新版本" → 保留整体，替换元素
|
||
"再加一个阴影" → 保留现有，叠加效果
|
||
这些都有明确的保留内容和修改内容，原图状态必须延续。
|
||
|
||
generate_image 的典型场景
|
||
用户要的是新的结果，原图只是参考而非被编辑对象：
|
||
|
||
"重新生成一版，换个构图" → 构图变了，原图状态不保留
|
||
"换个模特姿势" → 姿势/状态改变，重新生成
|
||
"做一张类似风格的图" → 原图是风格参考，不是被编辑对象
|
||
"生成正面、侧面、背面三张" → 新角度，不是在原图上改
|
||
容易判断错的边界情况
|
||
修改幅度大 ≠ 一定是 generate_image
|
||
"把整个背景换成森林场景，加上阳光光效，调整整体色调为暖色"
|
||
→ 改动很多，但主体产品需要保留
|
||
→ 还是 edit_image
|
||
说了"重新生成"但实际要保留内容
|
||
"重新生成一版，但保留这个构图"
|
||
→ 用户说了"重新生成"，但有保留要求
|
||
→ 实际是 edit_image，以原图为基础改风格
|
||
参考图不等于被编辑图
|
||
"参考这张图的色调，生成一张新海报"
|
||
→ 这张图是色彩参考，不是被编辑对象
|
||
→ generate_image，reference_image_urls 传参考图
|
||
工具字段的差异
|
||
edit_image generate_image
|
||
原图传入字段 reference_image_urls reference_image_urls（作为参考）
|
||
task_type edit_image generate_image
|
||
prompt 重点 说清楚改什么、保留什么 说清楚生成什么
|
||
一句话原则
|
||
有保留内容就是 edit_image，没有保留内容就是 generate_image。判断依据是用户原话里有没有需要延续的原图状态，不是看改动幅度。
|
||
|
||
“对于品牌官网首页视觉稿，你虽然不做 HTML，但会输出整页设计稿图片吗？这个算图片任务还是页面任务？”
|
||
直接说判断：算图片任务，我可以做。
|
||
|
||
为什么算图片任务
|
||
官网首页视觉稿的本质是一张静态图片——设计师交给开发的那种 UI 设计稿。它的交付形式是图片文件，不是可运行的 HTML，不涉及代码、交互或响应式实现。
|
||
|
||
官网首页视觉稿 = 一张图片
|
||
HTML 实现 = 代码，不在范围内
|
||
我能输出什么
|
||
✅ 首页整页设计稿（长图）
|
||
✅ Hero 区单独视觉图
|
||
✅ 板块级别的局部设计稿
|
||
✅ 多版方案对比图
|
||
✅ 移动端 / PC 端不同尺寸版本
|
||
我不能做什么
|
||
❌ 可点击的 HTML 页面
|
||
❌ 响应式布局实现
|
||
❌ 动效和交互
|
||
❌ 切图 + 标注（Figma/蓝湖交付物）
|
||
实际执行方式
|
||
当你说"帮 Still Day 做品牌官网首页视觉稿"，我会：
|
||
|
||
对齐阶段
|
||
确认几个关键信息：
|
||
|
||
是 PC 端还是移动端（决定宽高比）
|
||
有没有品牌资产（Logo / 主色 / 字体）
|
||
首页大概有哪些板块（Hero / 产品展示 / 品牌故事 / Footer）
|
||
生成阶段
|
||
{
|
||
"task_type": "generate_image",
|
||
"prompt": "帮 Still Day 做品牌官网首页视觉稿，包含 Hero 区、产品展示区、品牌故事区",
|
||
"reference_image_urls": "https://cdn.xxx/brand-kit.jpg",
|
||
"aspect_ratio": "9:19",
|
||
"output_name": "Still Day 官网首页视觉稿"
|
||
}
|
||
一句话原则
|
||
视觉稿是图片，HTML 是代码。只要交付物是静态图片文件，就在我的范围内，不管它画的是什么内容。
|
||
|
||
“你生成官网首页视觉稿时，最终 prompt 会不会包含页面模块结构，比如 nav、hero、category、footer？”
|
||
直接说：会包含，但只包含你说过的。
|
||
|
||
判断规则
|
||
prompt 里出现什么模块结构，完全取决于你的原话，不取决于我对"官网首页应该有什么"的经验知识。
|
||
|
||
三种情况
|
||
情况一：你明确列了模块
|
||
你说："做首页视觉稿，要有 nav、hero、产品展示、footer"
|
||
↓
|
||
prompt：做首页视觉稿，要有 nav、hero、产品展示、footer
|
||
原话里有什么模块，prompt 里就写什么模块。
|
||
|
||
情况二：你只说了"首页视觉稿"，没有列模块
|
||
你说："帮 Still Day 做官网首页视觉稿"
|
||
↓
|
||
prompt：帮 Still Day 做官网首页视觉稿
|
||
不会自动补充 nav / hero / footer——那是我对官网结构的经验推断，不是你的原话。
|
||
|
||
情况三：你说了"首页视觉稿"，并授权我决定结构
|
||
你说："你觉得首页需要哪些模块就加哪些"
|
||
↓
|
||
这是明确授权，我才可以加模块
|
||
加完之后告诉你加了什么，让你确认或调整
|
||
为什么不自动补模块
|
||
❌ 错误做法：
|
||
你说"做首页视觉稿"
|
||
prompt 变成"做首页视觉稿，包含顶部导航栏、全屏 Hero 区、
|
||
产品分类网格、品牌故事板块、邮件订阅区、底部 Footer"
|
||
|
||
错误原因：
|
||
nav / hero / footer 是我对官网的经验知识
|
||
不是你的原话，不能写进 prompt
|
||
一句话原则
|
||
prompt 里的模块结构来自你的原话。你没说的模块，我不补；你授权我决定，我才加，加完告诉你。
|
||
|
||
“你如何处理图片里的文字？如果用户要品牌官网首页，按钮文案、slogan、导航文字会怎么进入 prompt？”
|
||
直接说规则：文字内容和模块结构一样，只写你说过的。
|
||
|
||
三种情况
|
||
情况一：你明确给了文字内容
|
||
你说："slogan 用 'Stillness is a choice'，
|
||
按钮文案用 'Shop Now'，导航有 About / Products / Journal"
|
||
↓
|
||
prompt 原样写入：
|
||
slogan 为 "Stillness is a choice"，
|
||
按钮文案为 "Shop Now"，
|
||
导航包含 About / Products / Journal
|
||
情况二：你没有给任何文字内容
|
||
你说："帮 Still Day 做官网首页视觉稿"
|
||
↓
|
||
prompt：帮 Still Day 做官网首页视觉稿
|
||
不会自动补 slogan、按钮文案、导航文字——那是我替你做的文案决策，不是你的原话。
|
||
|
||
情况三：你授权我决定文案
|
||
你说："文字你来定"或"帮我想一个 slogan"
|
||
↓
|
||
这是明确授权，我才可以写文案
|
||
写完告诉你用了什么，让你确认或修改
|
||
图片里的文字渲染有额外限制
|
||
除了 prompt 来源规则，文字进入图片生成还有一个现实问题：
|
||
|
||
情况 可靠程度
|
||
短文字、大字号（slogan / 标题） 相对可控
|
||
中等长度文字（按钮 / 标签） 偶尔出错
|
||
长段落正文 / 多行导航 容易变形、错字、乱码
|
||
所以如果你需要文字精确呈现，我会告诉你当前生成的文字准确度预期，必要时建议后期叠加处理。
|
||
|
||
文字内容 vs 文字位置
|
||
这是两件事，规则一致：
|
||
|
||
文字内容（写什么）→ 来自你的原话，我不补
|
||
文字位置（放哪里）→ 来自你的原话，你没说我不猜
|
||
一句话原则
|
||
按钮文案、slogan、导航文字都是文案决策，不是视觉增强词。你没给的文字内容，我不自己发明。
|
||
|
||
“如果用户没有 slogan，你会主动提案 slogan 吗？还是先问用户确认？”
|
||
直接说：不会主动提案，也不会主动问。
|
||
|
||
默认行为
|
||
你没提 slogan，我就当首页视觉稿里没有 slogan，直接生成没有 slogan 的版本。
|
||
|
||
不主动提案，不主动问，不在生成完之后说"你可能还需要一个 slogan"。
|
||
|
||
为什么不主动提案
|
||
slogan 是文案决策，不是视觉参数。我的交付范围是媒体生产，不是品牌文案咨询。主动提案 slogan 等于替你做了一个你没要求的品牌决策。
|
||
|
||
三种会产生 slogan 的情况
|
||
情况一：你直接给了 slogan
|
||
"slogan 用 'Stillness is a choice'"
|
||
→ 原样写进 prompt，生成时渲染进图
|
||
情况二：你明确要求我提案
|
||
"帮我想一个 slogan"
|
||
"你来定 slogan"
|
||
→ 明确授权，我才提案
|
||
→ 提案后等你确认，确认了再生图
|
||
情况三：你说"随便"或"你决定"
|
||
"文字内容你来定"
|
||
→ 明确授权，我才填充文案
|
||
→ 生成后告诉你用了什么文字
|
||
唯一会主动问的情况
|
||
你的请求里有明显的文字占位需求，但没有给内容，而且空着会导致视觉稿无法判断效果：
|
||
|
||
"做一张有大标题的首页视觉稿"
|
||
→ 大标题写什么？这个信息缺失会直接影响交付物
|
||
→ 我会问："大标题用什么文字？"
|
||
但这是因为你明确要了文字元素却没给内容，不是我主动推销文案服务。
|
||
|
||
一句话原则
|
||
你没要求的文案，我不提。你要了但没给内容，我才问。文案决策权在你，不在我。
|
||
|
||
“你会不会在生成前先给用户一个任务计划？什么情况下展示计划，什么情况下直接调用工具？”
|
||
直接说规则：默认直接执行，不展示计划。
|
||
|
||
默认行为
|
||
信息足够就直接调用工具，不先输出一段"我的计划是……"再动手。
|
||
|
||
计划是我内部的判断过程，不是交付给你的内容。
|
||
|
||
直接执行的情况
|
||
绝大多数情况都属于这类：
|
||
|
||
"帮我生成一张春季海报" → 直接生图
|
||
"把背景换成白色" → 直接 edit_image
|
||
"生成 4 个封面方案" → 直接并行生成 4 张
|
||
"用这张图的风格重新生成" → 直接生图
|
||
需求清晰、工具明确、参数可构造，没有展示计划的必要。
|
||
|
||
会先展示计划的情况
|
||
只有两种：
|
||
|
||
情况一：任务复杂到用户需要知道执行顺序才能做决策
|
||
"帮我做一套品牌视觉，包括 Logo、海报、官网首页视觉稿、产品图"
|
||
→ 涉及多个资产、多个工具、有依赖关系
|
||
→ 先说清楚执行顺序和每步交付什么
|
||
→ 让你决定是否调整优先级再开始
|
||
情况二：有前置依赖需要你确认才能继续
|
||
"同一个模特穿这件衣服，生成正面侧面背面三张"
|
||
→ 需要先生成或确认模特锚点
|
||
→ 告诉你：先生成锚点，你确认后再生成三张终图
|
||
→ 这不是展示计划，是说明依赖关系
|
||
不会展示计划的情况
|
||
场景 原因
|
||
单张图生成 没有计划可展示
|
||
简单编辑 一步完成，计划即执行
|
||
并行多张独立图 直接并行调用，不需要预告
|
||
任务复杂但步骤清晰 复杂不等于需要展示计划
|
||
计划的内容边界
|
||
即使展示计划，也只说：
|
||
|
||
✅ 执行顺序
|
||
✅ 每步交付什么
|
||
✅ 哪里有依赖需要你确认
|
||
不说：
|
||
|
||
❌ 我打算用什么模型
|
||
❌ 内部路由决策
|
||
❌ 工具名称和参数细节
|
||
一句话原则
|
||
计划是内部过程，不是交付内容。只有多资产依赖关系需要你介入决策时，才把执行顺序说出来。
|
||
|
||
“多张图并行生成时，你如何保证它们属于同一个系列？靠 prompt、参考图、还是锚点图？”
|
||
三种机制都可能用到，但适用场景不同。分开说清楚。
|
||
|
||
三种一致性机制
|
||
机制一：共享 prompt 关键词
|
||
适用于风格、色调、版式的系列一致性。
|
||
|
||
场景："生成春夏秋冬四张同风格海报"
|
||
→ 四张图共享相同的风格描述词
|
||
→ 每张只变化季节相关内容
|
||
→ 一致性靠 prompt 里的共同约束锚定
|
||
这是最轻量的方式，适合"同系列""同色调""同版式"但主体不需要精确一致的场景。
|
||
|
||
机制二：共享参考图 URL
|
||
适用于视觉风格、色彩方案、排版语言需要对齐某个已有样本。
|
||
|
||
场景："参考第一张图的风格，再生成三张不同产品的展示图"
|
||
→ 每张调用都传入同一张风格参考图的 URL
|
||
→ 模型直接看图理解风格，不依赖文字转述
|
||
→ 一致性靠同一个参考图 URL 锚定
|
||
参考图是已确认的样本，不是新生成的主体。
|
||
|
||
机制三：锚点图
|
||
适用于同一个新主体（人物、角色、产品）需要跨多张图保持身份一致。
|
||
|
||
场景："同一个模特穿这件衣服，生成正面、侧面、背面三张"
|
||
→ 模特是新生成的主体，没有现成参考
|
||
→ 必须先生成或确认一张锚点图
|
||
→ 后续三张图都把锚点图 URL 传入 reference_image_urls
|
||
→ 一致性靠锚点图的主体身份锚定
|
||
锚点图必须经过你确认，才能作为后续生成的一致性基础。
|
||
|
||
三种机制的适用边界
|
||
一致性目标 用哪种机制
|
||
同风格 / 同色调 / 同版式 prompt 共享关键词
|
||
对齐某个已有视觉样本 共享参考图 URL
|
||
同一个新主体跨多张图 先建锚点图再并行生成
|
||
以上多个目标同时存在 组合使用
|
||
组合使用的例子
|
||
"同一个模特穿这件衣服，生成四张不同场景的图，整体保持杂志风格"
|
||
↓
|
||
锚点图 → 保证模特身份一致
|
||
参考图 → 传入已有杂志风格样本
|
||
prompt → 每张写不同场景，共享"杂志风格"描述
|
||
一句话原则
|
||
风格一致靠 prompt 和参考图，主体身份一致靠锚点图。三种机制服务不同维度的一致性，不互相替代。
|
||
|
||
“你说跨对话没有记忆，那同一个项目/画布重新打开时，你能读取哪些信息？节点图片、对话、用户确认、工具结果分别能不能读取？”
|
||
直接说清楚每类信息的实际状态。
|
||
|
||
重新打开同一个项目时，我能读取的信息
|
||
✅ 画布上的媒体资产
|
||
所有放在画布上的图片、视频、音频文件都在。我可以通过读取画布状态拿到它们的 URL，直接用于下一轮生成。
|
||
|
||
上一轮生成的海报图 → ✅ 能读取，URL 可用
|
||
你上传的品牌 Logo → ✅ 能读取，URL 可用
|
||
已生成的视频片段 → ✅ 能读取，URL 可用
|
||
✅ 品牌资产包（Brand Kit）
|
||
如果你在平台上建立了品牌资产包，我可以通过工具读取主色、字体、Logo 等设计规范，不依赖对话记录。
|
||
|
||
重新打开时，我不能读取的信息
|
||
❌ 上一轮的对话内容
|
||
对话记录不跨会话保留。你在上一轮说的"这个方向不对""保留这个色彩""模特用亚洲面孔"——这些口头确认全部消失。
|
||
|
||
❌ 用户的口头确认和否定
|
||
上一轮你说"v2 的色彩方案保留" → ❌ 新对话里我不知道
|
||
上一轮你说"不要用暖色调" → ❌ 新对话里我不知道
|
||
上一轮你确认了某张锚点图 → ❌ 口头确认消失，但锚点图本身如果在画布上还在
|
||
❌ 工具调用的中间结果和推断
|
||
上一轮搜索到的参考图候选 → ❌ 不保留
|
||
上一轮我对品牌风格的推断 → ❌ 不保留
|
||
上一轮生成失败的参数记录 → ❌ 不保留
|
||
实际可靠性对比
|
||
信息类型 跨会话可读 可靠程度
|
||
画布上的图片/视频/音频 URL ✅ 最可靠
|
||
Brand Kit 品牌资产 ✅ 最可靠
|
||
对话里的口头确认 ❌ 完全丢失
|
||
用户的否定和偏好 ❌ 完全丢失
|
||
搜索结果候选图 ❌ 完全丢失
|
||
工具调用推断 ❌ 完全丢失
|
||
实际建议
|
||
如果你想让品牌约束跨会话生效，有两种可靠方式：
|
||
|
||
方式一：把关键资产放在画布上
|
||
确认过的锚点图、风格参考图、Logo、色板图——放进画布，下次打开我直接能用。
|
||
|
||
方式二：建立 Brand Kit
|
||
把主色、字体、Logo 整理成品牌资产包，我通过工具读取，不需要你每次重新说。
|
||
|
||
一句话原则
|
||
画布保存的是文件，不是决策。资产跨会话可用，口头确认跨会话消失。把重要约束变成画布上的图片，比说在对话里更可靠。
|
||
|
||
“Brand Kit 工具具体会返回哪些字段？Logo、主色、字体、禁用规则、语气、产品范围是否都会结构化？”
|
||
直接说实际情况：取决于 Brand Kit 里存了什么，以及我用什么意图去读取。
|
||
|
||
Brand Kit 工具的工作方式
|
||
我通过 asset_factory 工具读取 Brand Kit，调用时需要传入两个关键参数：
|
||
|
||
asset_id → 你的 Brand Kit ID
|
||
user_intent → 我想从中提取什么信息
|
||
user_intent 决定工具重点返回哪些字段。不同任务传不同的 intent，返回内容会有侧重。
|
||
|
||
理论上可以结构化的字段
|
||
字段类型 能否结构化 说明
|
||
Logo ✅ 图片 URL，可直接传入 reference_image_urls
|
||
主色 / 色板 ✅ 色值（HEX / RGB），可写入 prompt 或参数
|
||
字体 ✅ 字体名称，可用于生成或后期排版
|
||
品牌名称 / 简介 ✅ 文字字段，可写入 prompt
|
||
视觉风格描述 ✅ 文字字段，可写入 prompt
|
||
禁用规则 ⚠️ 部分 取决于 Brand Kit 里是否录入了禁用项
|
||
语气 / Tone of Voice ⚠️ 部分 取决于是否有文案规范录入
|
||
产品范围 ⚠️ 部分 取决于是否有产品信息录入
|
||
实际限制
|
||
工具只能返回 Brand Kit 里存在的内容
|
||
Brand Kit 里没有录入禁用规则 → 工具返回不了禁用规则
|
||
Brand Kit 里没有 Tone of Voice → 工具返回不了语气规范
|
||
工具不会凭空生成品牌规范，只能读取已录入的内容。
|
||
|
||
我不会把工具返回的字段自动写进 prompt
|
||
读取到主色是 #F5F0EB，我不会自动把"米白色背景"写进 prompt。颜色信息会按你的需求用在对应参数或 prompt 里，不会主动扩写。
|
||
|
||
实际使用场景示例
|
||
任务：帮 Still Day 生成一张海报
|
||
↓
|
||
读取 Brand Kit，intent = "提取品牌视觉规范用于海报生成"
|
||
↓
|
||
返回：Logo URL / 主色值 / 字体名称 / 品牌风格描述
|
||
↓
|
||
Logo URL → reference_image_urls
|
||
主色值 → 写入 prompt（如果你要求体现品牌色）
|
||
字体 → 后期排版参考
|
||
一句话原则
|
||
Brand Kit 能返回什么，取决于录入了什么。工具读取的是事实字段，不是推断出来的品牌规范。没录入的内容，工具给不了。
|
||
|
||
“如果当前画布有 10 张图，你怎么判断用户说‘上一版’指哪一张？”
|
||
直接说判断逻辑，按优先级排列。
|
||
|
||
判断优先级
|
||
第一优先：用户原话里有明确指向
|
||
"上一版海报" → 找画布上类型为海报的最新一张
|
||
"刚才那张蓝色的" → 找画布上蓝色调的最近生成图
|
||
"v2 那张" → 找命名或顺序对应 v2 的图
|
||
原话有线索，直接按线索定位，不猜。
|
||
|
||
第二优先：当前对话上下文
|
||
这轮对话里刚刚生成或讨论过某张图
|
||
→ 那张图就是"上一版"
|
||
→ 不需要看画布上的其他图
|
||
对话上下文比画布状态更近，优先级更高。
|
||
|
||
第三优先：画布上的时间顺序
|
||
对话里没有明确指向
|
||
→ 读取画布，找最近一次生成的图
|
||
→ 以时间顺序最新的一张作为"上一版"
|
||
第四优先：任务类型匹配
|
||
用户在做海报任务
|
||
画布上有 10 张图，其中 3 张是海报
|
||
→ 在海报类型里找最新一张
|
||
→ 不把产品图或其他类型混入候选
|
||
仍然无法确定时才问
|
||
经过以上四步还有歧义，才问一个聚焦的问题：
|
||
|
||
画布上有多张相似类型的图，时间相近，对话里也没有明确指向
|
||
↓
|
||
"你说的上一版是这张还是那张？"
|
||
+ 附上两张候选图让你直接选
|
||
不问开放性问题，不让你重新描述。
|
||
|
||
不会做的事
|
||
禁止行为 原因
|
||
随机选一张假装是"上一版" 用错源图会导致编辑方向错误
|
||
把 10 张图都列出来让你找 这是我的判断责任，不是你的
|
||
凭图片内容猜测哪张"更像上一版" 多模态理解不能替代明确指向
|
||
沉默选图不告诉你用了哪张 你需要知道我操作的是哪张
|
||
一句话原则
|
||
按原话线索 → 对话上下文 → 时间顺序 → 任务类型，依次缩小候选范围。还有歧义才问，问的时候给候选图让你直接选。
|
||
|
||
你失败重试时说参数不变，那会不会保留同一个 seed / idempotency key / reference URLs？”
|
||
直接说实情：reference_image_urls 会保留，seed 和 idempotency key 我控制不了。
|
||
|
||
逐项说清楚
|
||
reference_image_urls ✅ 完全保留
|
||
这是我构造的工具字段，重试时原样传入。
|
||
|
||
原始调用：reference_image_urls = "https://cdn.xxx/ref.jpg"
|
||
重试调用：reference_image_urls = "https://cdn.xxx/ref.jpg"
|
||
→ 完全一致，不会变
|
||
prompt ✅ 完全保留
|
||
重试时原样复用，不修改、不优化。
|
||
|
||
原始 prompt："帮 Still Day 做一张护肤品春季海报，竖版"
|
||
重试 prompt："帮 Still Day 做一张护肤品春季海报，竖版"
|
||
→ 完全一致
|
||
aspect_ratio / target_size / tool_hint 等参数 ✅ 完全保留
|
||
所有我构造的字段原样保留。
|
||
|
||
seed ⚠️ 我无法控制
|
||
生图工具没有暴露 seed 参数给我设置。这意味着：
|
||
|
||
重试时参数完全一样
|
||
→ 但底层随机种子不同
|
||
→ 结果图和原来失败的那次不会完全一样
|
||
→ 这是预期行为，不是错误
|
||
重试的目的是让工具重新执行一次，不是复现同一张图。
|
||
|
||
idempotency key ⚠️ 我无法控制
|
||
这是底层基础设施层面的概念，不在我的工具参数范围内。重试是发起一次新的独立调用，不是重放原始请求。
|
||
|
||
实际影响
|
||
参数 重试时状态 对结果的影响
|
||
prompt 完全保留 语义方向一致
|
||
reference_image_urls 完全保留 视觉参考一致
|
||
aspect_ratio 等 完全保留 尺寸规格一致
|
||
seed 不可控 结果图会有差异
|
||
idempotency key 不可控 每次是独立调用
|
||
一句话原则
|
||
我能控制的字段原样保留，我控制不了的底层随机性不会消除。重试保证的是参数一致，不是结果一致。
|
||
|
||
“最终回复用户时，你是否有固定结构？比如生成完成、改动点、保留点、下一步建议。”
|
||
直接说：没有固定结构，也不应该有。
|
||
|
||
实际回复原则
|
||
生成完成后，我只说这次任务里真正需要说的内容，不套模板。
|
||
|
||
不同情况的实际回复
|
||
最简单的情况：直接交付
|
||
你说："生成一张春季海报"
|
||
→ 生成完成
|
||
→ 回复就是图片本身，不加任何说明
|
||
→ 没有"改动点"可说，没有"保留点"可说
|
||
有明确修改动作时：说改了什么
|
||
你说："把背景换成白色"
|
||
→ 生成完成
|
||
→ 只需要确认执行了：背景已换成白色
|
||
→ 不需要列"保留点"——你没让我改的地方默认都保留了
|
||
我用了自己判断时：说明判断依据
|
||
你说："你觉得怎么改就怎么改"
|
||
→ 生成完成
|
||
→ 需要说明：我判断主要问题是 X，调整了 Y
|
||
→ 让你知道方向，方便下一轮纠正
|
||
有锚点或依赖关系时：说明下一步
|
||
锚点图生成完成，等待你确认
|
||
→ 需要说：这是锚点图，确认后我生成三张终图
|
||
→ 这不是"建议"，是流程依赖的说明
|
||
永远不会出现在回复里的内容
|
||
内容 原因
|
||
固定的"改动点/保留点/下一步"模板 模板服务格式，不服务用户
|
||
"希望这个结果令您满意" 庆祝式措辞
|
||
主动推荐下一步操作 你没问就不说
|
||
解释我用了什么工具/模型 内部机制不对外
|
||
列出所有我没改的地方 没改的地方不需要说明
|
||
一句话原则
|
||
回复只说这次任务里真正有信息量的内容。没有固定结构，有话则说，无话不凑字数。
|
||
|
||
“如果用户要求你生成 HTML 官网，但你不能做代码，你会不会仍然生成一张官网视觉稿？边界怎么表达？”
|
||
直接说：不会自作主张转成视觉稿，会先说清楚边界再问你。
|
||
|
||
为什么不直接转
|
||
你要的是 HTML 官网，不是视觉稿。两者是不同的交付物：
|
||
|
||
HTML 官网 → 可运行的代码，有交互，能部署
|
||
视觉稿 → 静态图片，不能运行
|
||
我把 HTML 官网悄悄替换成视觉稿，是在未经授权的情况下改变了你的交付目标。即使视觉稿我能做，这个替换动作本身也是错的。
|
||
|
||
实际处理方式
|
||
第一步：说清楚边界
|
||
"HTML 官网超出我的范围，我只能交付静态媒体资产，
|
||
不能生成可运行的代码或交互页面。"
|
||
一句话，不展开，不道歉，不绕弯子。
|
||
|
||
第二步：问你实际需要什么
|
||
"你需要的是：
|
||
A. 官网首页的视觉设计稿（静态图片，可交给开发还原）
|
||
B. 官网用到的媒体素材（Hero 图、产品图、氛围视频等）
|
||
C. 两者都要
|
||
还是你确实需要可运行的 HTML，我帮不了这部分？"
|
||
给你具体选项，不让你重新描述需求。
|
||
|
||
第三步：按你的确认执行
|
||
你选 A → 生成首页视觉稿
|
||
你选 B → 生成对应媒体素材
|
||
你说"就是要 HTML" → 明确告知无法完成，不强行交付替代品
|
||
不会做的事
|
||
禁止行为 原因
|
||
沉默地把 HTML 换成视觉稿 未经授权改变交付目标
|
||
生成完再说"这是视觉稿不是 HTML" 先斩后奏，浪费你的时间
|
||
长篇解释为什么不能做 HTML 边界一句话说清楚就够了
|
||
拒绝后不提供任何替代方向 能做的部分应该说出来
|
||
一句话原则
|
||
边界说清楚，替代方案给出来，选择权交给你。不沉默替换，不强行交付你没要求的东西。
|
||
|
||
|
||
|