企业官网建设流程全解析

我最近在做的电商智能客服项目里，遇到一个很典型的场景：用户上传一张商品图，问“这件衣服什么材质”“这双鞋码数偏不偏”“这款包有没有黑色”。系统需要把图片送给大模型，再回传一个可靠、有边界感的答案。我用的技术栈是Java 17，调用的是Responses接口，输入部分直接携带图像。整个过程中最让我花心思的并不是怎么把图传上去，而是怎么让模型“只回答它该回答的”——这就是标题里说的“结果边界”。这篇文章会从方案选型、代码实现到踩坑排查，完整地复述一遍，给准备用Java 17接多模态问答的后端同学一个参考。如果你正在做类似的事情，先记住一句话：图像输入不难，难的是让模型不乱说话。

1. 项目背景与方案选型：为什么是Java 17加Responses

1.1 商品问答这个场景到底要解决什么问题

电商客服场景里，用户不会像文档一样规范提问。他们可能发来一张包装盒正面照片，然后问“这个生产日期在哪”；可能发来一件衣服穿在模特身上的图，然后问“衣长多少”。这些问题的共同点是，答案必须从图片里来，而且不能超出图片信息。我们要做的不是让模型自由发挥，而是限制它的回答域。商品问答的“结果边界”所要求的，就是三个“只”：只聊和图片商品相关的内容，只依据图片中可见的证据，只用前端能直接展示的稳定格式。项目一开始，我就把这些约束写进了需求文档，后面所有的技术细节都是围绕它们展开的。如果没有边界，模型很容易被用户带着跑，比如用户问“你猜我买这个合适吗”，模型就会开始分析穿搭、预算、使用场景，整个系统很快就失控。

1.2 从Chat Completions到Responses：为什么值得迁移

更早的时候，这类需求通常用Chat Completions接口实现。它也能传图片，但需要把图片base64放在messages数组里，再加上一堆系统提示词。接口本身并不区分“文本输入”和“图像输入”，导致代码里要写很多类型判断。Responses接口重新设计了输入和输出：输入统一为input数组，每个content项可以是input_text、input_image等；输出也从choices数组变成了一个更规整的output_text字段。这个变化让Java侧的定义变得清晰很多。

我整理了一张对比表，方便你看清楚区别：

当然，这张表只是概括，不代表所有版本都一模一样。但迁移的核心原因是一样的：把多模态输入和结构化管理做成一等公民，减少应用层的胶水代码。如果你是从零开始做，我建议直接选Responses，没必要在旧接口上再搭一套包装。迁移时最需要注意的其实是响应的解析逻辑。旧接口的choices结构五花八门，有的SDK还会把工具调用、内容过滤塞进message里，解析代码写得很痛苦。Responses这边把最终文本集中在output_text，遇到多输出项时按顺序遍历即可，逻辑简单很多。

1.3 Java 17在其中的实际价值

接下来说Java 17的价值。第一是record，这是最直接的收益。我要定义请求体、图片项、响应体，以前写一坨类，现在用三行record搞定。第二是var，解析响应时不用反复写很长的类型声明，代码读起来更轻松。第三是不可变集合和Optional，处理可能缺省的业务字段时，不容易出现空指针。第四是java.net.http.HttpClient，它本身就是从Java 11开始提供HTTP/2支持，到了Java 17已经非常稳定。我们只需要一个HttpClient实例，不需要引第三方OkHttp或者Apache HttpClient，少一个依赖就少一份兼容烦恼。

Java 17的switch表达式也很适合处理响应里的结束原因。模型返回的finish_reason无非是stop、length、content_filter这几类，用传统if-else写很长，用switch表达式就能写成一行赋值：

String reasonText = switch (finishReason) { case "stop" -> "正常结束"; case "length" -> "达到输出上限"; case "content_filter" -> "命中内容过滤"; default -> "其他"; };

有人可能会说，Java 8也够用。但对这种需要频繁和JSON打交道的AI应用来说，record带来的代码量减少不是一点半点。而且Java 17作为LTS版本，接下来几年都会持续获得安全更新，选它比选Java 11或Java 21更符合多数企业的保守策略。Java 21的虚拟线程确实更强，但很多公司的基础设施和依赖库还没完全兼容，Java 17是新项目里最稳妥的平衡点。

2. 图像输入的数据预处理与API请求组装

2.1 商品图像的常见形态与处理策略

用户上传的商品图，远比我们想象的复杂。常见的有白底商品主图、带模特的上身图、包装盒多角度图、以及用户随手拍的买家秀。这些图的尺寸差异非常大，有人直接上传原图能到5MB，有的则是60KB不到的缩略图。模型服务商对图片有大小限制，如果不管三七二十一直接传，很容易被拒。我的建议是，在进入业务逻辑前，先把所有图统一转成JPEG格式，并限制最长边不超过1280像素。JPEG在兼容性和体积上最平衡，PNG虽然无损，但同样尺寸的文件体积可能是JPEG的好几倍，base64编码后更吓人。

压缩这一步用Java的ImageIO就能做。读取原图，按比例缩放，再设置JPEG质量：

BufferedImage original = ImageIO.read(inputStream); int targetLongestEdge = 1280; int width = original.getWidth(); int height = original.getHeight(); double scale = width >= height ? (double) targetLongestEdge / width : (double) targetLongestEdge / height; int scaledW = (int) Math.round(width * scale); int scaledH = (int) Math.round(height * scale); BufferedImage scaled = new BufferedImage(scaledW, scaledH, BufferedImage.TYPE_INT_RGB); Graphics2D g = scaled.createGraphics(); g.drawImage(original, 0, 0, scaledW, scaledH, null); g.dispose(); ImageIO.write(scaled, "jpg", outputStream);

实测下来，一张3MB的RGB图片压缩到最长边1280、质量0.8，基本能降到200KB以内。这个大小对base64编码来说非常友好，模型服务端的响应速度也能快不少。还要特别检查图片方向，手机拍的图经常带EXIF旋转信息，直接用ImageIO读出来可能是横的，需要先做旋转转正，不然模型看到的内容是侧着的，回答自然不准。

2.2 用Java 17实现图像编码与请求体构建

图像统一处理完之后，就是编码和组包。Responses接口支持两种传图方式：公网URL和base64 data URL。电商场景里，用户图片往往只存在我们的内部存储里，没有公网地址，所以base64是更稳妥的选择。下面这段代码就是我在项目里用到的工具方法，把图片文件转成base64字符串：

public static String encodeImageToBase64(BufferedImage image, String format) throws IOException { ByteArrayOutputStream baos = new ByteArrayOutputStream(); ImageIO.write(image, format, baos); byte[] bytes = baos.toByteArray(); return Base64.getEncoder().encodeToString(bytes); }

注意图片格式最好传"jpg"，并在拼接data URL时确保前缀是data:image/jpeg;base64,。有的服务端文档支持PNG，但PNG体积更大，我统一用JPEG主要是为了控制体积。组装请求时，我习惯把所有图像都放进一个list，因为用户可能上传多张角度图。循环处理即可，但要注意多张图会显著增加token消耗和响应延迟，实际产品里一般限制最多3张。

紧接着，我用Java 17的record定义请求体。这里只展示最小化的结构，实际还有temperature、max_output_tokens等字段：

public record InputContent(String type, String text, String imageUrl) { public static InputContent ofText(String text) { return new InputContent("input_text", text, null); } public static InputContent ofImage(String base64) { return new InputContent("input_image", null, "data:image/jpeg;base64," + base64); } } public record UserInput(List<InputContent> content) {} public record ApiRequest(String model, List<UserInput> input, String instructions, double temperature) {}

组装时，把问题放进input_text，把编码后的图片放进input_image。这里有一个经验：instructions要放在顶层，不要混在user消息里。因为从测试结果看，顶层instructions对全轮对话的约束更强，模型会更认真地把它当作系统级规则来遵循。

2.3 使用HttpClient发送异步请求与响应解析

请求体准备好后，用Java 17的HttpClient发出去。Responses接口通常对图像请求的耗时更长，所以我在代码里把单一请求的超时放宽到45秒，同时用sendAsync避免阻塞tomcat线程。

HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://api.openai.com/v1/responses")) .header("Authorization", "Bearer " + apiKey) .header("Content-Type", "application/json") .POST(BodyPublishers.ofString(mapper.writeValueAsString(apiRequest))) .timeout(Duration.ofSeconds(45)) .build(); CompletableFuture<HttpResponse<String>> future = client.sendAsync(request, HttpResponse.BodyHandlers.ofString());

拿到响应后，我需要从JSON里抽取output_text。我习惯先用ObjectMapper把它读成JsonNode，再遍历输出数组，收集所有type为output_text的节点。为了复用，我定义了一个record来装最终结果：

public record ApiResponse( String requestId, String outputText, String finishReason, int promptTokens, int completionTokens ) {}

这个record正好利用Java 17的紧凑构造器和访问器，后面在日志里也能直接打出来，调试非常方便。如果你用的是Spring Boot，可以把ObjectMapper注入为Bean，避免重复创建。封装一层图片问答客户端后，Controller只需要一行代码调用，业务代码会清爽很多。

3. 结果边界的三层防线：提示、参数与校验

3.1 边界定义：内容、依据、格式

我在做这个项目时，把结果边界当作一个可测试的产品需求来对待。第一层内容边界：回答必须紧扣商品。用户问“这件衣服怎么洗”，模型可以答图片里是否有洗涤标签；但用户问“你喜欢这件衣服吗”，模型必须拒绝。第二层依据边界：回答必须能从图片中找到对应信息。如果图片是一个椅子，用户问“承重多少公斤”，图片没有标注就不许编，必须说“无法从图片中确认”。第三层格式边界：同一个字段的返回格式要保持一致。比如“是否有库存”这类问题，我要求模型必须返回“有库存”或“无库存”，不允许出现“这个不确定”“大概有货”这种模糊表达。

这三层边界不是各自独立的，它们会互相影响。如果内容边界被突破，后面的依据和格式自然失效。所以在设计阶段，我就把边界校验放在prompt和代码两侧，前端拿到的每一个答案都会经过一次格式校验，不满足就改用兜底文案。实际开发中，边界定义最忌讳的是模糊，比如“不要回答无关内容”这种措辞，模型很难精确执行。把三类边界都细化成可判断的规则，再落到代码里，才不会出现“每个版本模型表现都不一样”的情况。

3.2 System Prompt与few-shot让模型“守规矩”

在prompt设计上，我只做加减法，不搞玄学。System Prompt写清楚了最终要求，再给一两个例子，模型基本能稳定进入“商品信息查询器”模式。以下是我使用的System Prompt精简版：

你是一个电商商品信息问答助手。你只能根据用户提供的商品图片和问题作答。 规则： - 如果问题与图片中的商品无关，回答：抱歉，我只能回答图片商品的相关问题。 - 如果图片中看不到问题所涉及的信息，回答：图片中无法确认该信息，请补充图片。 - 不要推测，不要联想，不要使用图片中不存在的细节。 - 回答不超过50字，用中文。

只写规则还不够，尤其当用户问题比较复杂时，模型会倾向用自己的语言习惯绕开规则。我在System Prompt的末尾追加了few-shot示例：

示例1： 问题：这个杯子是陶瓷的吗？ 图片：图中有一个红色陶瓷杯。 回答：是陶瓷材质，图中为红色陶瓷杯。 示例2： 问题：这个杯子容量是多少？ 图片：图中只有杯子外观，没有容量标识。 回答：图片中无法确认该信息，请补充包装或标签图片。

这两个示例不长，但能让模型更快掌握“答什么、不答什么”的尺度。我的感受是，示例的价值在于给模型一个模仿对象，比单纯堆砌“不要瞎猜”这种否定句更有效。

3.3 采样参数和后处理校验兜底

参数是第二道防线。我习惯把temperature设置为0.2，让模型输出尽量确定。max_output_tokens控制在200以内，如果回答内容本身很短，没必要给模型太多发挥空间。还有一个容易被忽视的参数是top_p，不要和temperature一起调，我默认保留默认值。为了避免用户等待太久，我还会在后端对响应时间做监控，超过10秒就计入慢请求，逐渐形成不同图像类型的耗时画像。

但提示和参数都不是万能的。模型在收到“这个包会不会很容易脏”这类问题时，仍有可能给主观建议。我在Java侧加了一层校验器，核心思路是维护一个“越界词表”，扫描模型输出的文本。出现“我觉得”“可能”“建议”等相关词，直接替换为固定的兜底文案。

public static String enforceBoundary(String modelAnswer) { List<String> riskWords = List.of( "可能", "应该", "建议", "我觉得", "推测", "大概", "品质好", "性价比高" ); for (String word : riskWords) { if (modelAnswer.contains(word)) { return "该问题涉及主观判断或图片中无法确认的信息，请以商品实物为准。"; } } return modelAnswer; }

这个方法简单粗暴，但在商品问答场景里非常管用。它不解决所有边界问题，但能把最明显的越界答案拦截下来。我的经验是，前后端宁可牺牲一点灵活性，也要保证回复稳定。词表不能随便拍脑袋写，最有效的来源是线上日志。每出现一个越界回答，就把它里的主观词加入词表，这样边界会越收越紧。第一次上线后我记得大概迭代了两周，风险词的命中率才降到比较理想的水平。

4. 实战问题排查：从图像报错到边界失控

4.1 图像文件过大、格式不支持、URL失效

项目刚开始，我收到最多的错误就是“Bad request”。翻开日志，常常是图片解码失败或请求体超限。其中WebP格式在Java原生ImageIO里不支持，如果没做格式转换，会直接抛异常。我的做法是在上传入口就统一检查图片格式，不是JPEG/PNG就先用ImageIO尝试转换；如果转换失败，就直接提示用户更换图片，不把问题留给模型。另一个容易踩的坑是base64字符串里包含换行符，一些库在读取多行base64时不规范，在线生成时用Base64.getEncoder()保证不会断行就好。

请求体大小也要提前估算。一个200KB的图片转成base64后约270KB，加上JSON结构和其他字段，总请求体大概在300KB左右，这个量级还能接受。但如果用户上传5MB原图，base64后接近7MB，服务商会直接拒绝。我宁愿在预处理阶段多花几毫秒压缩，也不愿在请求阶段被拒后给用户报错。

URL失效这个问题也值得说。如果用户上传到第三方图床，图片链接可能带签名，几小时就过期。我在测试时用临时URL传图，模型服务端后来就取不到图了，返回了“图片不存在”。从那以后，我就不再依赖外部URL，所有用户上传图都先拉到本地上传到对象存储，再转成base64随请求发出。

4.2 模型把背景文字也当成商品信息

视觉模型读取图片时会把所有视觉元素都当作线索。有次用户上传一张产品包装盒图，上面除了产品名，还有厂家地址、二维码和一句广告语。用户问“这里面含不含防腐剂”，模型看到了包装上“不添加任何防腐剂”的广告语，就直接回答了。这个答案本身没问题，但换一张包装上印着“赠品”或“限量版”的图，模型就容易把这些促销信息和商品属性混在一起，回答“这款商品是赠品”之类很荒谬的话。

我的对策是在System Prompt里明确加一条“优先关注商品本身的属性信息，例如材质、颜色、尺寸、容量，忽略促销文案和装饰性文字”。同时在代码层面对“促销”“限量”“赠品”这类词做敏感检测，如果答案里出现这些词，就再让模型重新生成一次。如果重生成还是出现，就返回“图片信息不足，请补充更清晰的商品图”。这样既降低了误判率，也不会因为一次异常结果卡住整个流程。

4.3 面对与商品无关的刁钻问题怎么挡

网上总有人喜欢拿机器人开涮，生产环境里也免不了被问“你怎么看现在的物价”这类问题。模型一旦没有边界，就会和用户聊起来。我在请求组装前增加了一道“领域前置判断”。维护一个商品属性关键词表，包括材质、颜色、尺寸、容量、重量、价格、品牌、型号、是否有货等。如果用户问题里一个关键词都命中不了，就直接返回“抱歉，我只能回答商品相关问题”，不浪费一次模型调用。这一步在业务量上来之后也能省掉不少token成本，属于越早做越好的事。

如果问题命中关键词又带有明显主观色彩，例如“这个价格值不值”，我会把问题改写成“请根据商品图片回答：这张图片中能否找到判断价格是否合理的依据？”，让模型输出“能”或“不能”。这个改写的本质是把主观问题变成可查询的事实问题，和结果边界的原则不谋而合。如果输出“能”，再继续让模型基于图片给出价格依据；如果输出“不能”，就用兜底文案拒绝。虽然多了一次模型调用，但回答质量提升非常明显。

4.4 服务端超时与异步改造

图像输入模型响应时间普遍比文本慢。刚开始我用同步调用，网关5秒超时，线上用户经常看到“系统繁忙”。后来我把调用链路改成异步：Controller先发起CompletableFuture，业务线程池负责等待模型响应，同时把timeout设置成45秒，前端通过轮询或WebSocket获取最终答案。Java 17虽然还没有虚拟线程，但只要用公共线程池而不是每次请求新建线程，性能就完全够用。

我在改造时还加了一个 traceId，从请求进来就注入到日志里。每次调用模型前记一条“图片大小=xxKB，token估算=xx”，响应回来再记一条“耗时=xxms，输出长度=xx”。排查问题时，只要根据traceId查日志，就能快速定位是图像处理瓶颈、网络延迟还是模型生成过长。这套日志方案对商业项目的稳定运行帮助特别大，强烈建议保留。异步改造时还要注意连接池管理，HttpClient的线程池和业务线程池要考虑各自的容量，避免高峰期互相挤占。

最后再补充一个我个人的体会：如果你也准备做类似的项目，我想说，结果边界不是一句提示词就能搞定的，它更像一条链路。Prompt给方向，参数给约束，图像预处理和后处理给兜底，每一层都在压缩模型的“自由发挥空间”。产品若希望机器人少说错话，那就得接受它有时候会给不出答案。我在实际项目里已经多次为了“不越界”而主动返回“无法确认”，虽然响应速度可能没有那些张口就答的模型那么爽快，但用户投诉率反而下降了。毕竟，在商品问答这种场景里，用户要的不是一个会聊天的机器人，而是一个不会说错的导购。