1. 项目背景与核心问题先把话说在前面这个项目表面上是个“Java 17 调用 Responses 图像输入”的接口联调活儿但真正让我下定决心写这篇文章的是后半句——“商品问答与结果边界”。做电商场景的应该都懂商品问答和纯文本问答完全是两码事。文本问答你看的是语义商品问答你看的是“这个答案到底有没有超出商品本身的边界”。比如用户拿着一张商品图问“这个能装多少升水”模型如果回答“这款保温杯容量 500ml适合户外携带”那没问题但如果模型顺着图片里的场景发挥回答了“户外活动建议搭配防晒霜”这种话那这条回答就算“越界”了——它靠谱但它不是用户要的也不是商品关联的答案。我们接入视觉输入能力的核心诉求是让模型既能“看懂图”又不会“看图说话说到天边去”。这个项目的技术栈并不复杂核心就是 Java 17 外部图像的响应式输入再叠加一层我们自己设计的商品问答链路。我之所以想分享这个项目是因为它踩中了两个很多人容易忽略的坑一个是 Java 17 在调用图像响应式接口时的语法和类型适配问题另一个是图像输入比纯文本更容易出现“回答越界”必须用工程手段把边界约束做进链路里而不是指望模型自觉。文章适合这几类人看正在用 Java 17 做 AI 接口对接的开发者、电商平台做商品咨询问答的工程师、以及所有被“模型回答不受控”折磨过的同学。基础部分我会讲得比较细因为我在实际联调中发现不少问题出在对 Java 17 特性不熟而不是出在接口本身。2. 整体设计与思路拆解2.1 为什么选 Java 17 做这个链路先说结论Java 17 不是“新炫技”的选择而是“够用且稳”的选择。当时团队里其实有争议有人想用 Java 11 省事有人想直接上 Java 21 尝鲜。最终定 Java 17 有三个原因第一Java 17 是 LTS 版本生命周期长生产环境的兼容性和安全更新有保障。我们这是电商场景线上系统稳定性优先级最高不可能为了一个问答模块去赌一个非 LTS 版本的长期维护。第二Java 17 的语法特性确实能优化这类对接代码。比如var关键字在解析外部 API 返回的复杂 JSON 结构时能让代码短一大截record类型非常适合用来定义不可变的请求/响应体图像输入这种场景就是一个典型的只读数据模型图片内容、MIME 类型、附加属性、关联商品ID天然就是一条 record。第三外部接口的 Java SDK 已经基准适配到 Java 17与其在 Java 11 上升级各种依赖、做兼容补丁不如直接用 Java 17 站在 SDK 的默认支持范围内。说白了选型不一定要选最新的但要选“团队现有能力 依赖生态 运行稳定性”三者交集最大的那个。2.2 商品问答的链路结构整个系统的核心链路可以拆成五段用户上传商品图片系统预处理并提取图片基础信息尺寸、格式、清晰度。将图片和用户问题封装成请求体统一走 Java 17 编写的 Gateway 服务。Gateway 调用外部 Responses 接口拿到模型返回的原始内容。对原始内容做商品边界校验识别商品主体、校验回答相关度、过滤越界内容。将合规的回答内容返回给前端展示同时把越界信息记录到日志供后续优化。这五段里最容易翻车的不是调用本身而是第 4 步的“边界校验”。图片输入和文本输入有一个本质区别图片包含的信息密度高但语义边界模糊。文本里“商品名”“属性名”是显式的但图片里什么都有——背景、标签、水印、拍摄环境、其他物品。模型读取图片时往往会“读太多”。我见过最典型的案例一张保温杯的商品图背景里有一本书用户问“这个杯子容量多大”模型居然回答里带了一句“日常阅读时放在桌边很合适”。这句话是合理的联想但作为商品问答它就是越界了——因为用户没问书商品链路也不负责推荐阅读场景。边界校验要做的事情就是把这些“合理但无关”的内容拦下来。2.3 为什么不能用“后置过滤”一刀切很多团队做这个需求时第一反应是“模型答完用关键词黑名单过滤一遍”。我承认这能解决一部分问题但远远不够。原因有三黑名单只能处理已知的越界词处理不了“全新表述的越界内容”。比如黑名单里有“书本”“阅读”模型换个说法说“搭配桌面的绿植很协调”黑名单就失灵了。部分越界内容不是靠单个词体现的而是靠整句话的语义。比如模型回答“这款包容量很大能装下 15 英寸笔记本出行方便”这句话本身的每个词都在商品属性范围内但“出行方便”如果超出了商家对该商品的定位描述它就是隐性越界。一刀切的后置过滤容易误伤正常回答。商品问答里经常出现“可以放在办公室使用”这种话这到底算越界还是正常属性黑名单的逻辑很难给出稳定判断。所以我们的方案是“前置约束 后置校验”双管齐下在前置请求的提示词里明确边界指令在后置校验里做商品关联度和语义相关性判断。后文会详细讲这两部分的具体实现。3. 核心细节解析与实操要点3.1 图像输入的请求体设计先看请求体的设计。这一步看似简单但我在联调中见过不少人因为请求体格式不规范被外部接口返回 400 搞到心态爆炸。图像输入的核心字段通常包括图像数据base64 或二进制流、图像 MIME 类型、附加的业务字段商品ID、场景ID等。我们用的是 Java 17 的record来定义请求体代码如下public record ImageRequest( String imageBase64, String mimeType, String prompt, Long productId, String sceneId ) {}这里有几个细节值得展开imageBase64是 base64 编码后的图像数据字符串。网上很多人直接把整个文件读成 byte[] 然后塞进 JSON结果外面还要再套一层编码容易搞出双重编码的 bug。所以规范做法是文件读字节 → base64 编码 → 放进 JSON 字符串字段不要自己发明格式。mimeType一定要填对。JPEG 就是image/jpegPNG 就是image/png。别小看这个字段有些接口会用它判断图像解码方式填错了轻则图片解析失败重则拿到的模型回答完全牛头不对马嘴。prompt是用户的问题文本和图像一起发送。在商品问答场景这个 prompt 通常不是裸的用户输入而是经过一层模板拼装的。我会在后面“边界约束”小节专门讲。productId和sceneId是业务字段。前者用于关联商品库后者用于标识问答场景比如“商品详情页问答”和“售后咨询问答”边界规则不同。3.2 Java 17 调用 Responses 接口的代码骨架外部 Responses 接口的调用本质是一次 HTTP 请求。我们用 Java 17 自带的HttpClient就够了不需要额外引入 OkHttp 或 Apache HttpClient。Java 11 之后内置的HttpClient已经非常好用Java 17 更是稳定得一批。下面这段是我在实际项目中抽出来的调用骨架HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); String requestJson objectMapper.writeValueAsString(imageRequest); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(url)) .timeout(Duration.ofSeconds(30)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(BodyPublishers.ofString(requestJson)) .build(); HttpResponseString response client.send(request, BodyHandlers.ofString());这段代码里有三个值得注意的点第一超时设置不能省。图片输入比纯文本输入慢很多一张 2MB 的图片从上传到模型返回往往需要 10 秒到 30 秒。如果你不给HttpClient设置timeout默认情况下连接阶段可能挂在那边很久生产环境很容易拖垮线程池。第二BodyHandlers.ofString()是最稳妥的选择。有人为了省内存用BodyHandlers.ofInputStream()流式读取但对这个场景来说模型返回的 JSON 响应体本身不会特别大直接读成字符串处理最方便。真要优化内存应该优化图片的 base64 编码大小而不是优化响应读取方式。第三token 鉴权头要统一封装。我在项目中写了一个AuthHeaderUtil的工具类统一从配置中心读取密钥并拼接Bearer前缀避免每个调用方各写各的鉴权逻辑将来换密钥时到处漏改。3.3 响应解析与 record 类型的使用响应体解析是很多人写得最乱的地方。标准做法是定义对应的响应 recordpublic record ImageResponse( String content, ListContentItem contentList, int statusCode, String requestId ) { public record ContentItem(String type, String text) {} }实际解析时要先判断状态码再去拿 content。我见过有同事跳过状态码检查直接response.body()往里塞结果返回了一个错误信息 JSON反序列化直接报错还以为是 SDK bug。正常流程是这样的if (response.statusCode() 200) { ImageResponse resp objectMapper.readValue(response.body(), ImageResponse.class); String answerText extractMainContent(resp); // 进入边界校验流程 } else { log.error(接口调用失败, 状态码{}, 响应{}, response.statusCode(), response.body()); throw new ImageApiException(图像接口调用异常: response.statusCode()); }extractMainContent这个方法也很讲究。模型返回的内容可能是一大段带格式的文本也可能包含多段内容。在商品问答场景我们只取第一段核心回答作为展示内容后面的附加内容一律丢弃避免出现“答完正题又补一句无关话”的情况。3.4 图片压缩与格式归一化的坑这个环节我踩过很深的坑单独拎出来说。外部 Responses 接口对图片大小通常有上限有些是 5MB有些是 10MB。电商场景用户上传的商品图动不动就 8MB、10MB裸传必然翻车。而且图片过大还会拖慢模型响应速度接口耗时直线上升。我的做法是在上传前做一次图片预处理读取原图获取宽高和格式信息。如果长边超过 2048px等比缩放到 2048px 以内。如果文件大小超过 3MB把 JPEG 质量压缩到 80%。统一转换为 JPEG 格式输出。Java 17 里用ImageIO就能完成这些操作。但注意一个坑ImageIO默认读取某些 PNG 或 WebP 格式可能返回 null需要额外处理。我们的方案是统一让前端上传时先转成 JPEG 或 PNG后端再做二次兜底处理双保险。图片压缩还有一个隐藏收益base64 编码后的字符串长度直接决定请求体大小。base64 会让原始数据膨胀约 33%一张 3MB 的图片转成 base64 就是 4MB 的字符串JSON 请求体再塞点业务字段就直接接近 5MB 了。所以压缩到 3MB 以下不仅是为了过接口限制也是为了让请求体小一点减少网络传输时间。4. 边界约束与合规校验的实现4.1 提示词层面的前置约束我一直强调不要指望模型自觉但一定要给模型明确的边界指令。前置约束做得好后置校验的压力会小一半。在商品问答场景我们的 prompt 模板是这样的你是电商平台商品问答助手。请仅基于用户提供的商品图片回答与商品相关的问题。 回答范围限制为商品的外观、材质、尺寸、容量、功能、使用场景、保养方式。 禁止回答与图片中商品无关的信息。禁止推测商品品牌真伪、产地、价格历史。 如果图片中商品不明确或与问题无关请直接回复无法回答该问题。注意这几点限制范围是“允许的类型”而不是“禁止的类型”。实践证明告诉模型“你可以说什么”比“你不能说什么”更有效。因为“不能”的列表无法穷尽而“可以”的范围一旦明确模型会在范围内组织语言。明说“如果图片中商品不明确直接回复无法回答”。这是给模型留一条“安全退路”避免模型在不确定的情况下强行编造。业务场景不同模板必须不同。商品详情页问答和售后咨询问答的边界不一样前者可以介绍使用场景后者应该聚焦退换货和保修政策。模板要支持配置化不能写死在代码里。4.2 后置校验商品关联度判断后置校验是边界约束的第二道防线。我用两层判断第一层是“关键词属性匹配”。从商品库中取出该商品的属性标签比如“容量”“材质”“颜色”“尺寸”然后检查模型回答中是否出现了这些属性词。如果回答里一个属性词都没有说明模型很可能在泛泛而谈甚至答非所问。但这层判断只能排除最明显的问题。真正有效的是第二层“语义相关性”判断——用模型自己来做裁判。思路是把模型回答再喂给模型让它判断“这句话是否在描述该商品”输出一个 0 到 1 的相关度分数。低于阈值的直接拦截。这里有人会问这不是多了一次模型调用吗成本怎么算答案是拦截率是设计的核心权衡。我们把第二次校验用的 prompt 设计得很轻模型只需要输出一个分数不需要生成完整回答token 消耗远低于第一次调用。同时只有第一次回答通过关键词初筛的才进入二次校验大部分明显越界的回答在初筛就被挡住了二次校验调用量并不大。4.3 越界回答的兜底策略即使做了两道防线仍然会有漏网之鱼。这时候不能把越界内容直接返回给用户兜底策略是将越界内容替换为模板兜底回答“抱歉我无法回答该问题请补充商品相关信息。”将越界原文写进日志记录商品ID、用户问题、模型回答、校验分数形成一条“越界案例库”。周期性地把越界案例库拿去优化 prompt 模板加新的边界示例。这个“越界案例库”的积累才是长期价值。我跑了一个月之后发现高频越界类型集中在“使用场景过度扩展”和“搭配推荐”两类于是我们专门在 prompt 里加了一条规则“禁止推荐与该商品无直接关系的搭配物品或使用场景。” 加了这条之后越界率肉眼可见地下降。4.4 边界参数怎么调才算“过了”最后聊聊“边界”该怎么量化评估。你得把“模型回答是否越界”变成一个可量化的指标否则开发自测没法收口。我们定义了三个指标越界率 判定为越界的回答数 / 总回答数。目标控制在 3% 以下。误杀率 被判定为越界但人工复核属于正常回答的数量 / 总回答数。目标控制在 1% 以下。可用率 通过校验并最终展示给用户的回答数 / 总请求数。目标不低于 90%。这三个指标必须一起看。如果你只看越界率把阈值调得很严误杀率会飙升用户问“这个杯子能放微波炉吗”模型答“不能”结果被拦了用户体验极差。阈值调优的过程就是在越界率和误杀率之间找平衡点我建议每周抽样 200 条人工复核根据复核结果动态调阈值。5. Java 17 联调中的常见问题与排查实录5.1 JSON 反序列化失败record 与 Jackson 的坑这个问题排在我的踩坑清单第一位。Java 17 的record用起来很爽但和 Jackson 的默认反序列化配置有兼容性问题。如果你用的是旧版本 Jackson2.12 之前直接反序列化 record 大概率会报InvalidDefinitionException因为旧版 Jackson 不认识 record 的规范构造器。解决方案有两个升级 Jackson 到 2.12 以上版本这是最省事的方案。我们是通过 Maven 统一管理依赖版本解决的。如果因为历史原因不能升级就只能靠JsonProperty标注每个字段。我这里贴一下 Maven 依赖的关键配置jackson.version2.15.2/jackson.version dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version${jackson.version}/version /dependency升级 Jackson 后record 反序列化就正常了。顺带说一句所有外部接口的返回模型我都用 record 定义因为不可变性在跨系统数据传输时真的能避免一堆“不小心改了字段值”的诡异 bug。5.2 图像接口超时重试到底该不该重试图片输入接口的超时问题比文本接口严重得多。文本接口一般 5 秒内能响应但图片输入经常 20 秒、30 秒才返回。超时一多大家第一反应就是加重试。但我必须说图像接口的幂等性要慎重判断重试策略不能一刀切。如果外部接口在超时之后实际上已经处理完请求只是网络回包慢那重试就会导致同一个请求被处理两次。对于商品问答场景这还算好大不了用户看到两条相同回答。但如果是扣费类接口重试可能就是实打实的成本浪费。我的建议是只有在“明确收到连接异常”时才重试比如HttpTimeoutException或ConnectException。如果收到了 HTTP 状态码哪怕是 500、502不要盲目重试先记录日志查清原因。重试次数最多 1 次且要加退避策略至少等待 1 秒再试。代码片段参考private HttpResponseString sendWithRetry(HttpRequest request, int maxRetries) throws Exception { int attempt 0; while (attempt maxRetries) { try { return client.send(request, BodyHandlers.ofString()); } catch (HttpTimeoutException e) { attempt; if (attempt maxRetries) { throw e; } Thread.sleep(1000L * attempt); } } throw new IllegalStateException(不可达); }注意这个重试只在连接阶段异常时生效HTTP 调用返回了任何状态码都不会走到 catch 里。5.3 HTTP 413 Request Entity Too Large这个问题我在图片上传场景里至少遇到过三次。现象图片明明压到 3MB 以下了但后端调用外部接口时仍然返回 413。排查下来发现不是外部接口的问题而是我们自己的 Nginx 网关配了client_max_body_size限制。外部接口接收的虽然是大 JSON但请求先从 Nginx 走Nginx 一看 body 太大直接给拒了。解法和排查路径先确认请求链路中所有中转层是否都配了大 body 限制。Nginx 默认是 1MB必坑。把client_max_body_size调整到 10MB 或按需调整。调整后一定要在测试环境完整走一遍因为有些服务间的内部调用还有一层额外的网关限制。这条经验看起来有点“低级”但实际发生的时候日志里的错误信息会误导你你会怀疑是外部接口限制会怀疑是图片压缩没生效排查一圈才发现是中间层的锅。5.4 base64 编码后换行符引发的解析错误这个坑有点冷门但遇到一次就够记一辈子。Java 的Base64.getEncoder().encodeToString(byte[])默认输出不带换行符但如果你用了MimeType那套编码器或者在某些框架的序列化组件里输出的 base64 字符串可能会被插入\n换行符。JSON 里出现裸换行符直接导致整个请求体解析失败外部接口返回 400。排查这种问题的办法很直接把发出请求前的 JSON 打到日志里用肉眼或文本工具看一下 base64 字段里有没有换行。我们项目里有位同事踩了这个坑日志里看了半天没看出来最后把 JSON 复制到编辑器里才看到 base64 中间夹着一个\n。解决方案就是把编码器统一替换为Base64.getEncoder()并且在序列化后做一次replaceAll(\\n, )双保险。5.5 模型返回内容偶尔带有 Markdown 格式怎么处理图像输入接口返回的内容和纯文本接口一样偶尔会带 Markdown 格式比如**加粗**、- 列表等。商品问答场景里前端展示要的是干净文本不能把 Markdown 原文直接糊上去。我们做了两层处理后端在返回给前端之前用Jsoup或简单的正则把 Markdown 标记剥掉保留纯文本。前端展示组件再做一层兜底遇到未识别的标记直接按纯文本显示。这里有个细节剥离 Markdown 时不要把所有*都删光因为商品名称里可能有星号用法。更好的做法是识别成对出现的标记符号比如**text**配对剥离而不是无脑 remove。6. 商品问答场景的边界案例复盘6.1 案例一商品图背景杂物引发的越界真实场景一张空气炸锅的商品图拍摄背景是厨房台面台面上放了一瓶酱油。用户问“这款空气炸锅容量多大”模型回答“5L 容量适合 3-4 人家庭使用。台面上搭配酱油瓶显得厨房很有烟火气。”前半句完美后半句彻底跑偏。这就是“图像背景信息污染”的典型——模型读图时把背景里的酱油瓶也当成了可讨论对象。我们把这类问题分类为“背景越界”在 prompt 里加入了“仅关注图片中的主要商品主体忽略背景中的其他物品”的指令。同时在后置校验里增加了一条规则回答内容中出现“搭配”“背景”“旁边”等引导词时重点审查后续内容。6.2 案例二用户问题本身超出商品边界有些越界不是模型的问题而是用户问题一开始就越界了。比如用户拿一张连衣裙的图片问“这衣服什么牌子的”。如果模型从图片里认出了品牌标志它是可以回答的但如果没认出模型很可能会编造一个品牌名——这就是最危险的“幻觉”。对这类情况我们建立了“问题分类”前置模块在请求进入模型之前先用一个轻量分类器判断用户问题的类型。如果问题属于“品牌真伪”“价格走势”“历史价格”等敏感或超边界类别直接返回预设回复不进入模型调用。这个前置拦截的效果非常好一是避免了模型编造二是省掉了模型调用的成本。6.3 案例三合法但不符合商家预期的回答这类最尴尬。模型回答没有越界确实是描述商品但商家不爱听。比如商家主打“高端保温杯”模型却回答“这款杯子使用的塑料材质轻盈便携”。“塑料材质”这个词在商家的话术体系里就是减分项尽管它是事实。这种情况不属于技术上的越界但属于业务上的边界。我们做了“商家自定义规则”的配置项允许商家配置“禁用语”和“偏好用语”。模型回答命中禁用语的走人工审核池不直接展示。这个功能上线后商家满意度提升明显。做技术的人容易陷入“模型说得对就行”的思维但电商场景里“对”和“合适”是两回事。6.4 越界案例库的价值边界是“养”出来的做了三个月的商品问答之后我最深的一个体会是边界不是设计出来的是养出来的。刚开始我们觉得把 prompt 写清楚就够了实际一跑各种神仙越界五花八门。今天客户问“这帐篷能住几个人”模型回答里能扯到“适合亲子露营时给孩子讲睡前故事方便”明天用户问“这个锅多重”模型能答出“和一本 300 页的书差不多重”。你永远列举不完所有越界姿势只能靠案例库不断喂养规则。我现在每天做的事就是把当天的越界案例分类、打标签、更新规则。做了三个月后越界率从最初的 11% 降到了 2.4%误杀率稳定在 0.8% 左右。这个成绩不是靠一个“完美 prompt”拿到的是靠持续迭代拿到的。所以有条件的团队我强烈建议从第一天就建立越界案例库哪怕最初只有十条也要坚持记录。它是整个边界体系最有价值的部分。7. 性能、成本与监控指标7.1 接口耗时的分布与瓶颈图像输入接口的耗时我实测下来的分布大致是图片预处理 base64 编码约 200~500ms。HTTP 传输3MB 图片约 800~2000ms取决于网络环境。模型推理生成核心耗时约 8000~20000ms。边界校验关键词初筛 语义二次校验约 500~1500ms。整整 90% 以上的时间都花在模型推理上。作为对比纯文本问答的模型推理通常只要 2000~5000ms图片输入整整慢了一个数量级。这就是为什么“图片问答”在架构上要注意异步化——同步等待 20 秒的体验确实不好。我们的方案是对耗时超过 15 秒的请求做异步回调前端先返回“图片分析中”等回调结果出来再推送展示。这个改造在用户体验上的提升非常明显。7.2 成本控制图片压缩就是省钱模型接口通常按 token 计费而图片输入按像素或按图片尺寸计费。图片压缩不仅能通过接口限制还能直接省成本。以我们的实际数据为例未压缩的 8MB 原图单次调用成本比压缩后的 2MB 图片高出约 60%。一个月跑下来因为压缩和格式归一化省下的费用足够覆盖团队一个月的内部测试 token 消耗。我强烈建议所有接图像接口的团队把“上传前压缩”做成强制链路而不是可选优化。7.3 监控指标别只看成功率监控这块我踩过的坑是光看调用成功率看着挺高实际上用户体验一塌糊涂。后来我们加了一组指标平均首字延迟从发起请求到收到第一个可用 token 的时间。完整响应时间分位数P50、P95、P99只看平均会骗人。边界拦截率被边界校验拦下的回答占比这个指标突然飙升时通常不是模型抽风就是商品库数据有问题。用户反馈率展示“无法回答该问题”之后用户是否继续追问。追问率高说明兜底话术不够友好或者前置分类误伤太多。这几项指标结合起来才能真正反映“这个问答模块到底好不好用”。7.4 线上故障的两个真实案例第一个故障图片全部解析失败。现象是某天早上 10 点开始所有带图片的问答请求全部返回 400。排查发现是图片压缩服务的内存溢出导致图片数据被截断base64 字符串长度不完整。根源是ImageIO.read()在高并发下对超大 PNG 解析时内存飙升最终 OOM。修复方案是给图片压缩服务单独扩容 限制单张图片最大像素数超过 6000 万像素直接拒绝处理。第二个故障边界校验误杀率飙到 15%。现象是某商品类目下的正常问答大量被拦截。排查发现是商品库的某个字段被运营改成了“套装含 1 个主机 2 个滤芯”而我们的关键词初筛逻辑把“套装”识别成了越界信号直接把模型回答拦了。修复方案是关键词匹配只做“白名单加权”不做“黑名单一票否决”越界判断必须交给语义层。这两个案例告诉我们监控指标不能只是规划得好看必须真正在线上盯紧并且要有快速定位根因的日志分析能力。8. 最终建议与后续扩展说点项目之外的话。做这个项目最大的收获不是“接好了接口”而是意识到一个问题当模型能力越来越强工程的核心价值就越来越偏向“约束”而不是“激发”。以后再做类似“Java 17 调用 Responses 图像输入”的项目我建议你从一开始就把边界校验设计成独立模块而不是在调用代码里零零散散地加 if 判断。独立模块的好处是可以单独扩展规则、可以单独压测、可以单独升级不用牵连主链路。我们最初把边界校验写在 Gateway 服务里后来拆成独立的BoundaryValidator服务扩展规则时优雅多了。后续我们还在计划做几件事给同样方向的朋友一个参考基于越界案例库做“规则自动生成”让模型定期分析积累的越界案例自动生成新的 prompt 规则建议。引入多模态 embedding把商品图特征也纳入相关性校验。不只看文字是否相关还看图片本身和回答的嵌入距离是否合理。把边界校验服务开放给内部其他团队复用。商品问答只是第一个基于图像输入的场景后续还有“商品对比”“穿搭推荐”“装修风格判定”等场景边界规则各不相同但校验框架是可以共用的。最后分享一个小技巧测试图像问答时一定要用“真实用户原图”别只拿干净的商品白底图测试。白底图测试通过率像天堂一上真实场景立刻原形毕露。我们内部有个测试集叫“群魔乱舞”里面全是各种背景复杂的真实商品图——乱糟糟的桌面、脏兮兮的厨房、光线昏暗的卧室。每次调整边界规则先跑一遍这个测试集不掉连锁不改上线。