diff --git a/refer/distill/lovart.txt b/refer/distill/lovart.txt
new file mode 100644
index 0000000..e17db65
--- /dev/null
+++ b/refer/distill/lovart.txt
@@ -0,0 +1,1224 @@
+你现在真实能调用哪些创作工具？请区分实际可生成和只能建议的能力。”
+以下是我实际可调用的创作工具，按能力类型分类：
+
+🎨 图片生成与编辑
+实际可生成：
+
+文生图 — 根据文字描述生成图片
+图生图 — 基于参考图转换/重绘
+局部编辑 — 定向修改图片局部区域（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	边界一句话说清楚就够了
+拒绝后不提供任何替代方向	能做的部分应该说出来
+一句话原则
+边界说清楚，替代方案给出来，选择权交给你。不沉默替换，不强行交付你没要求的东西。
+
+
+
diff --git a/server/internal/application/design_service.go b/server/internal/application/design_service.go
index e4d5f53..b466ec8 100644
--- a/server/internal/application/design_service.go
+++ b/server/internal/application/design_service.go
@@ -3612,7 +3612,7 @@ func (s *DesignService) markGenerationFailed(ctx context.Context, projectID stri
 		Role:      "error",
 		Type:      "error",
 		Title:     "图片生成失败",
-		Content:   failure.Error(),
+		Content:   generationFailureMessage(failure, false),
 		ThreadID:  project.LastThreadID,
 		ActionID:  project.LastThreadID,
 		StepID:    newID(),
@@ -3642,7 +3642,7 @@ func (s *DesignService) markAgentGenerationFailed(ctx context.Context, projectID
 		Role:      "error",
 		Type:      "error",
 		Title:     "图片生成失败",
-		Content:   failure.Error(),
+		Content:   generationFailureMessage(failure, false),
 		ThreadID:  threadID,
 		ActionID:  threadID,
 		StepID:    newID(),
@@ -3682,7 +3682,7 @@ func (s *DesignService) markAgentGenerationPartiallyFailed(ctx context.Context,
 		Role:      "error",
 		Type:      "error",
 		Title:     "图片生成部分失败",
-		Content:   failure.Error(),
+		Content:   generationFailureMessage(failure, true),
 		ThreadID:  threadID,
 		ActionID:  threadID,
 		StepID:    newID(),
@@ -3710,7 +3710,7 @@ func (s *DesignService) markNodeActionFailed(ctx context.Context, projectID stri
 		Role:      "error",
 		Type:      "error",
 		Title:     "图片处理失败",
-		Content:   failure.Error(),
+		Content:   imageActionFailureMessage(failure),
 		ThreadID:  threadID,
 		ActionID:  threadID,
 		StepID:    newID(),
@@ -3723,6 +3723,61 @@ func (s *DesignService) markNodeActionFailed(ctx context.Context, projectID stri
 	return s.repo.Save(ctx, project)
 }
 
+func generationFailureMessage(failure error, partial bool) string {
+	if partial {
+		if isTimeoutLikeFailure(failure) {
+			return "部分图片已经生成完成，剩余图片耗时较久没有成功返回。已保留成功结果，你可以只重试失败的部分。"
+		}
+		return "部分图片已经生成完成，剩余图片没有成功生成。已保留成功结果，你可以只重试失败的部分。"
+	}
+	if isTimeoutLikeFailure(failure) {
+		return "图片生成耗时较久，这次没有成功完成。画布内容已保留，你可以直接重试，或先降低图片数量/尺寸后再生成。"
+	}
+	if isTemporaryUpstreamFailure(failure) {
+		return "图片生成服务暂时繁忙，这次没有成功完成。画布内容已保留，请稍后重试。"
+	}
+	return "图片生成没有成功完成。画布内容已保留，你可以重新发起生成。"
+}
+
+func imageActionFailureMessage(failure error) string {
+	if isTimeoutLikeFailure(failure) {
+		return "图片处理耗时较久，这次没有成功完成。原图已保留，你可以稍后重试。"
+	}
+	if isTemporaryUpstreamFailure(failure) {
+		return "图片处理服务暂时繁忙，这次没有成功完成。原图已保留，请稍后重试。"
+	}
+	return "图片处理没有成功完成。原图已保留，你可以重新发起处理。"
+}
+
+func isTimeoutLikeFailure(failure error) bool {
+	if failure == nil {
+		return false
+	}
+	if errors.Is(failure, context.DeadlineExceeded) || errors.Is(failure, context.Canceled) {
+		return true
+	}
+	text := strings.ToLower(failure.Error())
+	return strings.Contains(text, "deadline") ||
+		strings.Contains(text, "timeout") ||
+		strings.Contains(text, "timed out") ||
+		strings.Contains(text, "awaiting headers") ||
+		strings.Contains(text, "lease expired")
+}
+
+func isTemporaryUpstreamFailure(failure error) bool {
+	if failure == nil {
+		return false
+	}
+	text := strings.ToLower(failure.Error())
+	return strings.Contains(text, "overload") ||
+		strings.Contains(text, "too many requests") ||
+		strings.Contains(text, "rate limit") ||
+		strings.Contains(text, "temporar") ||
+		strings.Contains(text, "service unavailable") ||
+		strings.Contains(text, "bad gateway") ||
+		strings.Contains(text, "gateway")
+}
+
 func (s *DesignService) markIsolatedGenerationFailed(ctx context.Context, projectID string, targetNodeID string, _ error) error {
 	project, err := s.repo.Get(ctx, projectID)
 	if err != nil {