简介这份PDF面向希望进阶多模态开发的技术人员与AI应用开发者围绕DeepSeek图像分析与文本生成API的联合调用展开帮助解决单一模态处理能力有限、图像识别与文本生成难以协同的实际问题。文档共21页为单个PDF文件压缩包约1.89MB内容完整、目录与图表显示正常便于按章节查阅。全篇从多模态开发背景讲起依次拆解图像分析API与文本生成API的功能特性、调用步骤与参数说明并重点给出联合调用方案的整体架构、工作流程、异常容错机制与代码实现还涉及异步调用、缓存与资源管理等性能调优思路以及智能电商推荐、智能旅游导览、智能广告创作等落地案例和常见问题排查。目前已有110人学习适合具备一定开发基础、希望系统掌握DeepSeek多模态联合调用方法的读者参考。1. 多模态联合调用为什么单走一路 API 总在真实业务里翻车很多人第一次接 DeepSeek 的图像分析是把它当成一个「图片转文字」的黑匣子丢一张图进去拿一段描述出来任务就算完。真到业务里你会发现图像分析吐出来的东西和文本生成要的东西根本对不上——前者给的是自由描述后者要的是结构化上下文中间缺了一层「谁来把视觉结论翻译成生成指令」的调度逻辑。这就是「联合调用」要解决的问题不是把两个 API 各调一次而是让图像分析的输出成为文本生成的输入约束形成一条可控的链路。这套方案适合三类人做智能客服、内容审核、电商图文生成的工程师手里已经有 DeepSeek API Key、想把它从「聊天玩具」升级成生产管线的人以及被 401、400 这类报错反复折磨、想搞清楚调用边界的人。下面按「先立住原理、再跑通最小链路、最后处理坑」的顺序讲每一步都能照着复现。2. 联合调用的链路设计图像分析结果怎么喂给文本生成2.1 两条 API 的职责边界与数据契约先把职责划清楚否则后面全是玄学。图像分析 API 的职责是「把像素变成可判断的语义标签」它输出的是描述性文本或结构化字段文本生成 API 的职责是「在给定约束下产出目标文案」它需要的是明确的指令和上下文。两者之间必须有一份数据契约也就是你自定义的中间结构。常见做法是定义一个 JSON 中间层字段包括scene场景描述、objects识别到的对象列表、confidence置信度、raw_text原始描述。图像分析返回后你先解析成这个结构再拼成文本生成的 prompt。这样做的好处是图像分析换模型、文本生成换模板中间层不用动。字段来源用途是否必填scene图像分析输出作为生成场景约束是objects图像分析输出生成时列举关键元素是confidence图像分析输出低于阈值时触发人工复核否raw_text图像分析原始返回兜底解析失败时用是这份契约的价值在于可测试你可以单独 mock 图像分析的返回验证文本生成部分是否稳定而不用每次都真调一次视觉接口。2.2 最小可运行链路Python 串起两次调用下面这段代码是能直接跑的最小链路。它做了三件事调图像分析、解析成中间结构、拼 prompt 调文本生成。注意 API Key 从环境变量读不要硬编码。import os import json import requests API_KEY os.environ[DEEPSEEK_API_KEY] BASE_URL https://api.deepseek.com/v1 # 按你实际接入的地址替换 def analyze_image(image_url: str) - dict: 调用图像分析接口返回原始文本 resp requests.post( f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: deepseek-vl, # 视觉模型名按实际可用模型填 messages: [ {role: user, content: [ {type: text, text: 描述这张图的场景和主要对象用JSON返回}, {type: image_url, image_url: {url: image_url}} ]} ], temperature: 0.2 # 分析任务要稳温度压低 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] def build_prompt(analysis_text: str) - str: 把图像分析结果转成文本生成指令 return ( 根据以下图像分析结果生成一段电商商品描述不超过120字\n f{analysis_text}\n 要求突出场景感不要编造图中没有的元素。 ) def generate_text(prompt: str) - str: 调用文本生成接口 resp requests.post( f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.7, # 生成任务要活温度调高 max_tokens: 300 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: raw analyze_image(https://example.com/sample.jpg) print(图像分析原始输出:, raw) result generate_text(build_prompt(raw)) print(生成结果:, result)逻辑说明analyze_image负责视觉侧temperature设 0.2 是为了让描述稳定、可复现generate_text负责文本侧温度 0.7 让文案有变化。两个函数之间只通过字符串传递耦合度低方便替换任意一侧的模型。参数说明timeout必须设视觉接口处理大图时容易超过默认超时max_tokens要按你的业务长度设不设容易被截断model字段一定要用你账号实际可用的模型名填错会直接 400。2.3 同步还是异步批量场景下的调度选择单张图同步调没问题但批量处理时同步会卡死。常见做法是图像分析走并发、文本生成走队列。图像分析可以并发 5 到 10 路因为它是 IO 密集文本生成如果要做长文建议串行或小并发避免触发限流。我一般会用一个简单的生产者-消费者图像分析结果先落本地 JSON 文件文本生成从文件读。这样即使文本生成挂了图像分析的结果不丢重跑时不用再花钱调视觉接口。这个「后悔药」在批量任务里非常值钱。3. 参数与提示词调优让图像分析和文本生成对齐3.1 图像分析侧的三个必调参数图像分析不是调通就行输出质量直接决定文本生成的上限。三个参数必须调temperature、detail如果接口支持、max_tokens。temperature建议 0.1 到 0.3。高于 0.5 时同一张图两次描述可能不一致下游生成就会飘。detail参数控制视觉理解的精细度低精度省 token 但会丢小对象高精度贵但准按业务选。max_tokens要留够图像描述被截断是常见翻车点截断后 JSON 解析直接失败。# 图像分析参数建议 ANALYZE_CONFIG { temperature: 0.2, # 稳定优先 max_tokens: 800, # 留足描述空间防止截断 detail: high # 需要识别小对象时开高精度 }参数说明max_tokens不是越大越好太大浪费额度太小截断。经验值是描述类任务 500 到 1000 之间。detail如果接口不支持就忽略不要硬传导致 400。3.2 文本生成侧的提示词结构文本生成的质量七成靠 prompt 结构。我一般用「角色 任务 约束 输入 输出格式」五段式。角色让模型进入状态任务说清要干什么约束是防止它编造输入就是图像分析结果输出格式保证可解析。PROMPT_TEMPLATE 你是电商文案助手。 任务根据图像分析结果生成商品描述。 约束 1. 只使用分析结果中出现的元素不得编造。 2. 不超过120字。 3. 语气自然不要堆砌形容词。 图像分析结果 {analysis} 输出直接给文案不要解释。逻辑说明约束里明确「不得编造」是关键否则模型会脑补图中没有的东西这在商品场景是事故。输出格式要求「直接给文案」是为了省掉后处理清洗。参数说明{analysis}是占位符用的时候替换成图像分析结果。如果分析结果是 JSON建议先转成自然语言再填模型对 JSON 的理解不如自然语言稳。3.3 用中间层做对齐校验两条链路对齐的难点在于图像分析说「有一只猫」文本生成可能写成「一只可爱的橘猫」。中间层要加校验比如对象列表比对。常见做法是在中间层加一个validate函数检查生成结果里是否出现了分析结果中没有的关键名词。def validate(analysis_objects: list, generated: str) - bool: 检查生成结果是否引入了分析中没有的对象 for obj in [狗, 汽车, 飞机]: # 按业务维护黑名单 if obj in generated and obj not in analysis_objects: return False return True逻辑说明这是轻量校验不追求完美目的是拦住明显编造。黑名单按业务维护比如商品图里不该出现「人」就加进去。参数说明analysis_objects来自中间层的objects字段generated是文本生成结果。校验失败时不要直接丢弃记录日志人工看因为可能是分析漏了而不是生成编了。4. 避坑与排查401、400 和上下文超限的真实处理4.1 401 unauthorizedKey 的三种翻车方式现象请求返回unexpected status 401 unauthorized: incorrect api key provided。原因通常有三种Key 没读到环境变量、Key 带了多余空格、Key 和接入地址不匹配。解决先打印os.environ.get(DEEPSEEK_API_KEY)的前几位确认读到了再用strip()去空格最后确认你用的 BASE_URL 和 Key 是同一平台的。提示Key 不要写进代码提交到仓库用环境变量或密钥管理服务。401 报错里有时会回显 Key 前缀日志里要注意脱敏。4.2 400 上下文超限图像描述太长也会撑爆现象api error: 400 this models maximum context length is ... tokens。原因图像分析返回的描述太长加上 prompt 模板后超过文本生成模型的上下文上限。解决在中间层对raw_text做截断或者让图像分析直接返回结构化短字段而不是长描述。def truncate(text: str, max_chars: int 2000) - str: 按字符粗截断防止上下文超限 return text if len(text) max_chars else text[:max_chars] ...逻辑说明字符截断是粗粒度保护真正精确要按 token 算但字符截断实现简单、够用。参数说明max_chars按模型上下文和 prompt 长度反推留 30% 余量。4.3 图像分析返回不是合法 JSON现象解析中间层时报json.decoder.JSONDecodeError。原因模型返回里带了 markdown 代码块标记或解释性文字。解决解析前先剥离 json 标记解析失败时回退到raw_text字段不要让整条链路挂掉。import re def safe_parse(text: str) - dict: 容错解析失败返回空结构 cleaned re.sub(rjson|, , text).strip() try: return json.loads(cleaned) except json.JSONDecodeError: return {scene: , objects: [], raw_text: text}逻辑说明re.sub去掉代码块标记try/except保证不抛异常。参数说明回退结构里raw_text保留原文下游还能用。4.4 并发调用触发限流现象批量跑时部分请求返回 429 或超时。原因并发数超过账号配额。解决加信号量控制并发失败请求做指数退避重试。import time def retry_call(fn, retries: int 3): 指数退避重试 for i in range(retries): try: return fn() except requests.HTTPError as e: if e.response.status_code 429 and i retries - 1: time.sleep(2 ** i) continue raise逻辑说明只对 429 重试其他错误直接抛。参数说明retries设 3 次够用退避时间 1、2、4 秒避免把限流打成雪崩。4.5 图像 URL 不可访问导致分析失败现象图像分析返回空或报错。原因图片 URL 需要鉴权、已过期、或格式不支持。解决先把图片下载到本地或对象存储用可公开访问的临时地址或者直接用 base64 传图如果接口支持。注意base64 传图会显著增加请求体大小大图慎用容易触发请求体超限。5. 进阶技巧把联合调用做成可观测的管线5.1 给每次调用打上 trace_id联合调用最大的痛点是出问题时不知道是哪一环挂了。我的习惯是给每次请求生成一个trace_id图像分析和文本生成的日志都带上它。这样排查时一条grep就能串起整条链路。import uuid def new_trace(): return uuid.uuid4().hex[:12] # 调用时 tid new_trace() print(f[{tid}] 开始图像分析) # ... 两次调用日志都带上 tid逻辑说明trace_id不需要全局唯一到 UUID4 全量短 ID 够用且好读。参数说明日志里固定格式[trace_id]方便 grep。5.2 用缓存省掉重复的图像分析同一张图重复分析是纯浪费。常见做法是用图片 URL 或文件哈希做 key把图像分析结果缓存到本地或 Redis。文本生成因为 prompt 可能变缓存命中率低可以不做。缓存对象Key存储过期策略图像分析结果图片哈希本地 JSON / Redis7 天文本生成结果prompt 哈希可选1 天逻辑说明图像分析贵且结果稳定缓存收益最大。参数说明过期时间按业务更新频率定商品图变化快就缩短。5.3 用固定样本做回归验证改 prompt 或换模型后怎么知道效果没退化我一般维护一组 10 到 20 张固定样本图每次改动后跑一遍人工看生成结果。这比凭感觉靠谱得多。SAMPLES [s1.jpg, s2.jpg, s3.jpg] # 固定回归样本 def regression_check(): for s in SAMPLES: raw analyze_image(s) out generate_text(build_prompt(raw)) print(f{s}: {out[:50]}...)逻辑说明回归样本要覆盖典型场景和边界场景比如纯色图、多对象图、文字图。参数说明样本不要太多10 到 20 张足够多了人工看不过来。5.4 我踩过最深的坑把分析结果直接当 prompt早期我图省事把图像分析的原始返回直接拼进 prompt结果模型经常把分析里的「这张图展示了…」这种元描述也当成内容生成进去文案里出现「这张图」这种词。后来加了中间层做清洗只提取scene和objects字段问题才消失。教训是两条 API 之间一定要有清洗层不能裸传。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek多模态联合调用：图像分析与文本生成API链路实战
简介这份PDF面向希望进阶多模态开发的技术人员与AI应用开发者围绕DeepSeek图像分析与文本生成API的联合调用展开帮助解决单一模态处理能力有限、图像识别与文本生成难以协同的实际问题。文档共21页为单个PDF文件压缩包约1.89MB内容完整、目录与图表显示正常便于按章节查阅。全篇从多模态开发背景讲起依次拆解图像分析API与文本生成API的功能特性、调用步骤与参数说明并重点给出联合调用方案的整体架构、工作流程、异常容错机制与代码实现还涉及异步调用、缓存与资源管理等性能调优思路以及智能电商推荐、智能旅游导览、智能广告创作等落地案例和常见问题排查。目前已有110人学习适合具备一定开发基础、希望系统掌握DeepSeek多模态联合调用方法的读者参考。1. 多模态联合调用为什么单走一路 API 总在真实业务里翻车很多人第一次接 DeepSeek 的图像分析是把它当成一个「图片转文字」的黑匣子丢一张图进去拿一段描述出来任务就算完。真到业务里你会发现图像分析吐出来的东西和文本生成要的东西根本对不上——前者给的是自由描述后者要的是结构化上下文中间缺了一层「谁来把视觉结论翻译成生成指令」的调度逻辑。这就是「联合调用」要解决的问题不是把两个 API 各调一次而是让图像分析的输出成为文本生成的输入约束形成一条可控的链路。这套方案适合三类人做智能客服、内容审核、电商图文生成的工程师手里已经有 DeepSeek API Key、想把它从「聊天玩具」升级成生产管线的人以及被 401、400 这类报错反复折磨、想搞清楚调用边界的人。下面按「先立住原理、再跑通最小链路、最后处理坑」的顺序讲每一步都能照着复现。2. 联合调用的链路设计图像分析结果怎么喂给文本生成2.1 两条 API 的职责边界与数据契约先把职责划清楚否则后面全是玄学。图像分析 API 的职责是「把像素变成可判断的语义标签」它输出的是描述性文本或结构化字段文本生成 API 的职责是「在给定约束下产出目标文案」它需要的是明确的指令和上下文。两者之间必须有一份数据契约也就是你自定义的中间结构。常见做法是定义一个 JSON 中间层字段包括scene场景描述、objects识别到的对象列表、confidence置信度、raw_text原始描述。图像分析返回后你先解析成这个结构再拼成文本生成的 prompt。这样做的好处是图像分析换模型、文本生成换模板中间层不用动。字段来源用途是否必填scene图像分析输出作为生成场景约束是objects图像分析输出生成时列举关键元素是confidence图像分析输出低于阈值时触发人工复核否raw_text图像分析原始返回兜底解析失败时用是这份契约的价值在于可测试你可以单独 mock 图像分析的返回验证文本生成部分是否稳定而不用每次都真调一次视觉接口。2.2 最小可运行链路Python 串起两次调用下面这段代码是能直接跑的最小链路。它做了三件事调图像分析、解析成中间结构、拼 prompt 调文本生成。注意 API Key 从环境变量读不要硬编码。import os import json import requests API_KEY os.environ[DEEPSEEK_API_KEY] BASE_URL https://api.deepseek.com/v1 # 按你实际接入的地址替换 def analyze_image(image_url: str) - dict: 调用图像分析接口返回原始文本 resp requests.post( f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: deepseek-vl, # 视觉模型名按实际可用模型填 messages: [ {role: user, content: [ {type: text, text: 描述这张图的场景和主要对象用JSON返回}, {type: image_url, image_url: {url: image_url}} ]} ], temperature: 0.2 # 分析任务要稳温度压低 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] def build_prompt(analysis_text: str) - str: 把图像分析结果转成文本生成指令 return ( 根据以下图像分析结果生成一段电商商品描述不超过120字\n f{analysis_text}\n 要求突出场景感不要编造图中没有的元素。 ) def generate_text(prompt: str) - str: 调用文本生成接口 resp requests.post( f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.7, # 生成任务要活温度调高 max_tokens: 300 }, timeout60 ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: raw analyze_image(https://example.com/sample.jpg) print(图像分析原始输出:, raw) result generate_text(build_prompt(raw)) print(生成结果:, result)逻辑说明analyze_image负责视觉侧temperature设 0.2 是为了让描述稳定、可复现generate_text负责文本侧温度 0.7 让文案有变化。两个函数之间只通过字符串传递耦合度低方便替换任意一侧的模型。参数说明timeout必须设视觉接口处理大图时容易超过默认超时max_tokens要按你的业务长度设不设容易被截断model字段一定要用你账号实际可用的模型名填错会直接 400。2.3 同步还是异步批量场景下的调度选择单张图同步调没问题但批量处理时同步会卡死。常见做法是图像分析走并发、文本生成走队列。图像分析可以并发 5 到 10 路因为它是 IO 密集文本生成如果要做长文建议串行或小并发避免触发限流。我一般会用一个简单的生产者-消费者图像分析结果先落本地 JSON 文件文本生成从文件读。这样即使文本生成挂了图像分析的结果不丢重跑时不用再花钱调视觉接口。这个「后悔药」在批量任务里非常值钱。3. 参数与提示词调优让图像分析和文本生成对齐3.1 图像分析侧的三个必调参数图像分析不是调通就行输出质量直接决定文本生成的上限。三个参数必须调temperature、detail如果接口支持、max_tokens。temperature建议 0.1 到 0.3。高于 0.5 时同一张图两次描述可能不一致下游生成就会飘。detail参数控制视觉理解的精细度低精度省 token 但会丢小对象高精度贵但准按业务选。max_tokens要留够图像描述被截断是常见翻车点截断后 JSON 解析直接失败。# 图像分析参数建议 ANALYZE_CONFIG { temperature: 0.2, # 稳定优先 max_tokens: 800, # 留足描述空间防止截断 detail: high # 需要识别小对象时开高精度 }参数说明max_tokens不是越大越好太大浪费额度太小截断。经验值是描述类任务 500 到 1000 之间。detail如果接口不支持就忽略不要硬传导致 400。3.2 文本生成侧的提示词结构文本生成的质量七成靠 prompt 结构。我一般用「角色 任务 约束 输入 输出格式」五段式。角色让模型进入状态任务说清要干什么约束是防止它编造输入就是图像分析结果输出格式保证可解析。PROMPT_TEMPLATE 你是电商文案助手。 任务根据图像分析结果生成商品描述。 约束 1. 只使用分析结果中出现的元素不得编造。 2. 不超过120字。 3. 语气自然不要堆砌形容词。 图像分析结果 {analysis} 输出直接给文案不要解释。逻辑说明约束里明确「不得编造」是关键否则模型会脑补图中没有的东西这在商品场景是事故。输出格式要求「直接给文案」是为了省掉后处理清洗。参数说明{analysis}是占位符用的时候替换成图像分析结果。如果分析结果是 JSON建议先转成自然语言再填模型对 JSON 的理解不如自然语言稳。3.3 用中间层做对齐校验两条链路对齐的难点在于图像分析说「有一只猫」文本生成可能写成「一只可爱的橘猫」。中间层要加校验比如对象列表比对。常见做法是在中间层加一个validate函数检查生成结果里是否出现了分析结果中没有的关键名词。def validate(analysis_objects: list, generated: str) - bool: 检查生成结果是否引入了分析中没有的对象 for obj in [狗, 汽车, 飞机]: # 按业务维护黑名单 if obj in generated and obj not in analysis_objects: return False return True逻辑说明这是轻量校验不追求完美目的是拦住明显编造。黑名单按业务维护比如商品图里不该出现「人」就加进去。参数说明analysis_objects来自中间层的objects字段generated是文本生成结果。校验失败时不要直接丢弃记录日志人工看因为可能是分析漏了而不是生成编了。4. 避坑与排查401、400 和上下文超限的真实处理4.1 401 unauthorizedKey 的三种翻车方式现象请求返回unexpected status 401 unauthorized: incorrect api key provided。原因通常有三种Key 没读到环境变量、Key 带了多余空格、Key 和接入地址不匹配。解决先打印os.environ.get(DEEPSEEK_API_KEY)的前几位确认读到了再用strip()去空格最后确认你用的 BASE_URL 和 Key 是同一平台的。提示Key 不要写进代码提交到仓库用环境变量或密钥管理服务。401 报错里有时会回显 Key 前缀日志里要注意脱敏。4.2 400 上下文超限图像描述太长也会撑爆现象api error: 400 this models maximum context length is ... tokens。原因图像分析返回的描述太长加上 prompt 模板后超过文本生成模型的上下文上限。解决在中间层对raw_text做截断或者让图像分析直接返回结构化短字段而不是长描述。def truncate(text: str, max_chars: int 2000) - str: 按字符粗截断防止上下文超限 return text if len(text) max_chars else text[:max_chars] ...逻辑说明字符截断是粗粒度保护真正精确要按 token 算但字符截断实现简单、够用。参数说明max_chars按模型上下文和 prompt 长度反推留 30% 余量。4.3 图像分析返回不是合法 JSON现象解析中间层时报json.decoder.JSONDecodeError。原因模型返回里带了 markdown 代码块标记或解释性文字。解决解析前先剥离 json 标记解析失败时回退到raw_text字段不要让整条链路挂掉。import re def safe_parse(text: str) - dict: 容错解析失败返回空结构 cleaned re.sub(rjson|, , text).strip() try: return json.loads(cleaned) except json.JSONDecodeError: return {scene: , objects: [], raw_text: text}逻辑说明re.sub去掉代码块标记try/except保证不抛异常。参数说明回退结构里raw_text保留原文下游还能用。4.4 并发调用触发限流现象批量跑时部分请求返回 429 或超时。原因并发数超过账号配额。解决加信号量控制并发失败请求做指数退避重试。import time def retry_call(fn, retries: int 3): 指数退避重试 for i in range(retries): try: return fn() except requests.HTTPError as e: if e.response.status_code 429 and i retries - 1: time.sleep(2 ** i) continue raise逻辑说明只对 429 重试其他错误直接抛。参数说明retries设 3 次够用退避时间 1、2、4 秒避免把限流打成雪崩。4.5 图像 URL 不可访问导致分析失败现象图像分析返回空或报错。原因图片 URL 需要鉴权、已过期、或格式不支持。解决先把图片下载到本地或对象存储用可公开访问的临时地址或者直接用 base64 传图如果接口支持。注意base64 传图会显著增加请求体大小大图慎用容易触发请求体超限。5. 进阶技巧把联合调用做成可观测的管线5.1 给每次调用打上 trace_id联合调用最大的痛点是出问题时不知道是哪一环挂了。我的习惯是给每次请求生成一个trace_id图像分析和文本生成的日志都带上它。这样排查时一条grep就能串起整条链路。import uuid def new_trace(): return uuid.uuid4().hex[:12] # 调用时 tid new_trace() print(f[{tid}] 开始图像分析) # ... 两次调用日志都带上 tid逻辑说明trace_id不需要全局唯一到 UUID4 全量短 ID 够用且好读。参数说明日志里固定格式[trace_id]方便 grep。5.2 用缓存省掉重复的图像分析同一张图重复分析是纯浪费。常见做法是用图片 URL 或文件哈希做 key把图像分析结果缓存到本地或 Redis。文本生成因为 prompt 可能变缓存命中率低可以不做。缓存对象Key存储过期策略图像分析结果图片哈希本地 JSON / Redis7 天文本生成结果prompt 哈希可选1 天逻辑说明图像分析贵且结果稳定缓存收益最大。参数说明过期时间按业务更新频率定商品图变化快就缩短。5.3 用固定样本做回归验证改 prompt 或换模型后怎么知道效果没退化我一般维护一组 10 到 20 张固定样本图每次改动后跑一遍人工看生成结果。这比凭感觉靠谱得多。SAMPLES [s1.jpg, s2.jpg, s3.jpg] # 固定回归样本 def regression_check(): for s in SAMPLES: raw analyze_image(s) out generate_text(build_prompt(raw)) print(f{s}: {out[:50]}...)逻辑说明回归样本要覆盖典型场景和边界场景比如纯色图、多对象图、文字图。参数说明样本不要太多10 到 20 张足够多了人工看不过来。5.4 我踩过最深的坑把分析结果直接当 prompt早期我图省事把图像分析的原始返回直接拼进 prompt结果模型经常把分析里的「这张图展示了…」这种元描述也当成内容生成进去文案里出现「这张图」这种词。后来加了中间层做清洗只提取scene和objects字段问题才消失。教训是两条 API 之间一定要有清洗层不能裸传。希望帮到你。本文还有配套的精品资源点击获取