1. 从“能跑通”到“能落地”AI应用开发第三天的核心跨越走到AI应用开发的第三天很多人会卡在一个微妙的位置上。第一天你跑通了第一个大模型接口调用看着控制台里蹦出来的回复心里挺兴奋第二天你试着调了调参数换了几个提示词模板感觉好像摸到了点门道。但到了第三天当你真正想把一个AI功能塞进一个Java后端项目里让它像个正经业务模块一样工作时问题就全冒出来了——接口超时怎么处理流式输出怎么接多轮对话的上下文怎么管成本怎么控这些才是从“玩具”走向“工具”的分水岭。我自己带过不少做Java后端转AI应用开发的朋友也看过很多训练营里学员的实操记录。Day03这个节点通常对应的就是大模型开发入门之后的第一道实战坎把大模型能力真正接入一个可运行的应用骨架里。这个阶段的核心关键词是“集成”和“工程化”而不是“调参”和“炼丹”。你不需要去训练模型也不需要懂Transformer的注意力机制怎么算但你必须清楚一次完整的AI请求在系统里是怎么流转的哪些环节会出问题出了问题怎么定位。这篇文章就是围绕这个节点展开的。我会把AI应用开发第三天最该掌握的东西拆开讲透从整体架构怎么设计到核心的流式接口怎么接再到Java生态里常用的几种集成方式怎么选最后把我自己踩过的坑和排查问题的思路一并倒出来。不管你是刚跑通第一个Demo的新手还是已经写过几个接口但总觉得不够稳的开发者这里的内容都能直接拿去对照着用。文章里涉及的技术选型和参数配置都是基于当前主流实践给出的参考方案你可以根据自己的项目情况做调整。2. 第三天该想清楚的事AI应用的整体架构与选型逻辑2.1 为什么第三天必须停下来想架构很多人在学习AI应用开发时有个惯性第一天调通接口第二天就想赶紧写业务逻辑第三天恨不得直接上线。结果就是代码越写越乱一个Controller里塞了几百行提示词硬编码在方法里模型返回的异常和业务异常混在一起最后连自己都改不动。我见过最夸张的一个例子一个学员把大模型的调用直接写在了Spring的拦截器里每次请求都同步等模型返回结果整个系统的响应时间从200毫秒涨到了8秒还以为是模型太慢其实是架构没设计好。第三天最该做的事不是继续堆功能而是把AI能力当成一个独立的、可替换的、可观测的基础设施来对待。这意味着你要在脑子里画出一张清晰的架构图请求从哪进来经过哪些处理在哪里调用模型返回结果怎么组装异常怎么兜底。这张图想清楚了后面写代码就是填空想不清楚后面就是无休止的重构。从工程角度看一个典型的AI应用后端至少包含这几层接入层负责接收用户请求和参数校验编排层负责组装提示词、管理对话上下文、决定调用哪个模型模型调用层负责和模型服务通信处理超时、重试、流式解析后处理层负责对模型输出做格式化、敏感词过滤、结构化解析持久层负责存对话历史、调用日志、Token消耗记录。第三天你不需要把每一层都做到完美但必须知道每一层存在并且知道哪些层是当前阶段必须有的。2.2 模型调用方式怎么选同步、异步还是流式这是第三天最容易纠结的问题。我直接给结论面向用户的对话场景优先用流式后台批处理任务用同步或异步需要严格顺序和事务的场景老老实实同步。同步调用最简单发一个HTTP请求等模型返回完整结果再往下走。优点是代码直观异常处理简单适合那种“用户提交一个任务等几秒拿结果”的场景比如文本分类、摘要生成、代码审查。缺点是用户等待时间长体验差而且一旦模型响应慢你的线程就被占着并发一高就容易雪崩。异步调用是把请求丢给模型后立刻返回一个任务ID后台慢慢处理用户过一会儿再来查结果。适合耗时长的任务比如生成长文档、批量处理数据。实现上可以用线程池加Future也可以上消息队列。但异步的复杂度在于状态管理和结果回调第三天如果项目不复杂不建议一上来就搞异步。流式调用是当前对话类AI应用的标配。模型生成一个字就推一个字用户能实时看到内容蹦出来体验好很多。技术上通常用SSEServer-Sent Events或者WebSocket来实现。SSE更轻量基于HTTP浏览器原生支持适合单向的服务器推送WebSocket是全双工适合需要频繁双向交互的场景。对于大多数AI对话应用SSE足够了。这里有个关键点很多人会忽略流式接口的异常处理比同步复杂得多。同步调用时模型报错就是一个异常你catch住返回错误码就行。但流式调用中连接已经建立数据已经开始推送这时候模型突然报错你没法再改HTTP状态码了只能在流里发一个错误事件让前端去处理。这个细节如果第三天没想清楚后面上线一定会被用户投诉。2.3 Java生态里集成大模型的几种常见路径Java开发者做AI应用绕不开一个问题用什么库去调模型。目前主流的有三条路。第一条是直接用HTTP客户端手写调用。用OkHttp、Apache HttpClient或者Java 11自带的HttpClient自己拼JSON、发请求、解析响应。这种方式最灵活不依赖任何第三方SDK模型服务商换了你也只需要改请求地址和参数格式。缺点是重复代码多流式解析要自己处理容易出错。适合想彻底搞懂底层细节的学习者或者对依赖控制极严的项目。第二条是用官方或社区提供的SDK。很多模型服务商都提供了Java SDK封装了鉴权、请求构造、流式解析等逻辑。用SDK的好处是上手快代码简洁官方通常会跟进最新的API变化。缺点是版本更新可能带来兼容性问题而且不同服务商的SDK风格不统一换模型时迁移成本不低。第三条是用Spring AI这类框架。Spring AI是Spring生态里专门做AI集成的项目提供了统一的抽象接口支持多种模型服务商还能和Spring Boot的自动配置、依赖注入无缝结合。如果你本身就在用Spring Boot这条路最省心。它的ChatClient、EmbeddingClient等抽象让代码很干净流式返回也有现成的Flux支持。不过要注意版本迭代较快生产使用前要锁定版本并做好测试。我的建议是学习阶段先用手写HTTP的方式跑通一遍理解请求和响应的完整结构实际项目里根据团队技术栈选SDK或Spring AI。第三天你至少应该把第一种方式走通这样后面用任何框架你都知道它背后在干什么。3. 核心细节拆解流式输出、上下文管理与提示词工程3.1 流式输出到底是怎么实现的流式输出听起来玄乎其实原理很简单。普通的HTTP请求是“请求-响应”一次完成服务器把完整结果算好后一次性返回。流式输出则是服务器保持连接不关闭把结果切成一小块一小块地推给客户端客户端收到一块就渲染一块。在模型服务这一侧返回的数据通常是一行一行的JSON每行包含一个增量片段。这种格式一般叫SSE格式每行以data:开头最后以一个特殊的结束标记收尾。你的Java代码要做的事情就是建立一个HTTP连接读取响应流按行解析把每个片段里的文本内容提取出来再通过SSE推给你的前端。这里有几个实操要点。第一读取流的时候要用缓冲读取按行处理不要一次性read到字节数组里那样就失去流式的意义了。第二要处理空行和心跳有些服务会定期发空行或注释行保持连接你的解析逻辑要能跳过它们。第三要设置合理的超时流式连接可能持续几十秒甚至几分钟连接超时和读取超时要分开设置读取超时应该设得比较长但也不能无限等。第四客户端断开时要及时释放资源否则连接池会被占满。下面是一个用Java HttpClient做流式读取的核心逻辑示意你可以对照着理解HttpClient client HttpClient.newHttpClient(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(模型服务地址)) .header(Content-Type, application/json) .header(Authorization, Bearer apiKey) .POST(HttpRequest.BodyPublishers.ofString(requestBody)) .build(); HttpResponseInputStream response client.send(request, HttpResponse.BodyHandlers.ofInputStream()); try (BufferedReader reader new BufferedReader(new InputStreamReader(response.body(), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { if (line.startsWith(data:)) { String data line.substring(5).trim(); if ([DONE].equals(data)) { break; } // 解析data中的JSON提取增量文本 // 推送给前端 } } }这段代码不长但每一行都有讲究。BodyHandlers.ofInputStream()是关键它让响应体以流的方式返回而不是等全部接收完。BufferedReader按行读取配合startsWith(data:)过滤有效数据。[DONE]是常见的结束标记不同服务商可能不一样要按实际文档来。3.2 多轮对话的上下文怎么管才不爆多轮对话是AI应用的常见需求但上下文管理是个技术活。模型本身是无状态的它不记得你上一句说了什么。所谓“多轮对话”其实是每次请求时把之前的对话历史一起发给模型让它“看到”上下文再回答。这就带来一个问题上下文会越来越长。模型的输入长度是有上限的超过上限要么报错要么被截断。而且上下文越长调用成本越高响应也越慢。第三天你必须想清楚你的上下文管理策略。常见的策略有三种。第一种是滑动窗口只保留最近N轮对话超出的丢掉。简单粗暴但可能丢失重要信息。第二种是摘要压缩把早期的对话用模型总结成一段简短摘要和最近的对话一起发过去。效果好但多了一次模型调用增加成本和延迟。第三种是向量检索把历史对话存进向量库每次根据当前问题检索最相关的几条历史记录拼进上下文。适合长对话和知识库场景但实现复杂度最高。我的经验是第三天先用滑动窗口把功能跑通同时把每轮对话的Token数记录下来。等你有了真实数据知道平均对话多少轮、每轮多少Token再决定要不要上更复杂的策略。不要一上来就搞向量检索那是给自己找麻烦。具体实现上你可以用一个ListMessage来存对话历史每个Message包含角色user/assistant/system和内容。每次请求前从这个列表里按策略选取要发送的消息组装成模型要求的格式。注意system消息通常要放在最前面而且不参与滑动窗口的裁剪。3.3 提示词工程在代码里怎么落地提示词工程不是让你在代码里写一大段话就完事了。第三天你要考虑的是提示词怎么组织、怎么复用、怎么版本管理。最忌讳的做法是把提示词硬编码在Java方法里用字符串拼接。今天改一版明天改一版改到最后没人知道线上跑的是哪个版本。正确的做法是把提示词抽出来放在配置文件或者数据库里代码通过模板引擎去渲染。模板引擎可以用简单的占位符替换比如{user_input}、{context}也可以用Freemarker、Velocity这类成熟的模板引擎。如果提示词逻辑复杂涉及条件判断和循环用模板引擎会清晰很多。另外提示词要有版本号。每次修改提示词记录版本、修改人、修改原因、效果对比。这个习惯在第三天就要养成否则后面做A/B测试和效果回溯时会非常痛苦。你可以简单地在数据库里建一张提示词表字段包括名称、版本、内容、创建时间、备注。代码里根据名称和版本号去取。还有一个细节提示词里的变量要做转义和长度限制。用户输入的内容直接拼进提示词如果包含特殊字符或者超长文本可能破坏提示词结构甚至引发注入问题。虽然大模型不像SQL那样有严格的注入概念但用户输入“忽略以上指令”这类内容确实可能影响模型行为。基本的防护是把用户输入用明确的分隔符包起来并限制最大长度。4. 实操过程从零搭一个可运行的AI对话模块4.1 项目骨架与依赖准备假设你用的是Spring Boot项目第三天要做的就是加一个AI对话模块。先看依赖。如果你选择手写HTTP调用只需要加Web依赖和一个JSON库如果用Spring AI就加对应的starter。我以手写HTTP加Jackson为例pom里需要这些dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId /dependency配置方面把模型服务的地址、API Key、默认模型名称、超时时间都放到application.yml里不要写死在代码中。API Key尤其要注意绝对不能提交到代码仓库用环境变量或者配置中心注入。ai: base-url: https://api.example.com/v1 api-key: ${AI_API_KEY} model: default-model connect-timeout: 5000 read-timeout: 60000这里read-timeout设成60秒是因为流式对话可能持续较长时间。connect-timeout5秒足够连不上就快速失败。4.2 对话接口的完整实现步骤第一步定义请求和响应的数据结构。请求体包含用户输入、会话ID、可选的模型参数响应体如果是流式就用SSE推送。第二步写一个ChatService核心方法是streamChat。它接收用户输入和会话ID从会话存储里取出历史消息组装成模型要求的格式然后发起流式请求。第三步处理流式响应。每收到一个片段就通过SSE推给前端同时把片段追加到当前回复的缓冲区里。等流结束后把完整的用户消息和助手回复一起存入会话历史。第四步异常处理。连接失败、超时、模型返回错误、解析失败每种情况都要有对应的处理。流式场景下错误要通过SSE的error事件推给前端而不是抛异常。第五步会话存储。第三天可以用内存的ConcurrentHashMap先顶着key是会话IDvalue是消息列表。但要清楚这只是临时方案重启就没了生产环境要换成Redis或者数据库。下面是一个简化的Service方法结构public void streamChat(String sessionId, String userInput, SseEmitter emitter) { ListMessage history sessionStore.get(sessionId); history.add(new Message(user, userInput)); ListMessage context contextManager.buildContext(history); StringBuilder fullReply new StringBuilder(); try { modelClient.streamCall(context, chunk - { fullReply.append(chunk); emitter.send(SseEmitter.event().data(chunk)); }); history.add(new Message(assistant, fullReply.toString())); emitter.complete(); } catch (Exception e) { emitter.send(SseEmitter.event().name(error).data(生成失败请重试)); emitter.completeWithError(e); } }这段代码看着简单但每个环节都有坑。比如history的并发修改问题同一个会话如果同时有两个请求进来列表会被改乱。第三天至少要用synchronized或者按会话ID加锁来保证串行。再比如emitter.send可能抛IOException如果客户端提前断开这个异常要单独处理不能让它影响后续逻辑。4.3 参数选择与成本控制的实操计算模型调用是要花钱的第三天就要有成本意识。成本主要看两个指标输入Token数和输出Token数。不同模型单价不同但计算逻辑一样。假设你用的模型输入价格是每百万Token 10元输出是每百万Token 30元。一次对话系统提示词200 Token历史对话平均1000 Token用户输入50 Token模型输出300 Token。那么这次调用的成本是输入(200 1000 50) / 1,000,000 × 10 0.0125元输出300 / 1,000,000 × 30 0.009元合计约0.0215元看起来不多但如果你的应用每天有1万次对话一天就是215元一个月六千多。所以上下文管理不是可选项是必须做的成本控制手段。把历史对话从平均1000 Token压到500 Token成本直接降三分之一。参数方面temperature控制随机性对话场景一般0.7左右需要确定性输出时调到0.2以下。max_tokens限制输出长度一定要设否则模型可能生成超长内容既慢又贵。top_p和temperature通常只调一个不要同时大改。我建议第三天就在代码里加一个Token计数和成本记录的切面每次调用后把消耗记下来。不用做得很复杂打日志或者存数据库都行。有了数据你才知道优化从哪里下手。5. 常见问题与排查技巧实录5.1 流式输出常见故障速查流式输出是第三天最容易出问题的地方我把遇到过的情况整理成一张表方便对照排查。现象可能原因排查方法解决思路前端一直转圈没有内容响应没有flush数据被缓冲检查是否用了缓冲流且未flush每次send后调用flush或配置不缓冲内容一次性全部出现用了同步调用而非流式检查请求参数是否开启了stream确认请求体里stream参数为true中途断开报连接重置读取超时设置过短查看日志中的超时异常调大read-timeout检查网络稳定性中文乱码字符集不一致检查请求和响应的编码统一用UTF-8收到重复内容解析逻辑把非增量字段也拼进去了打印原始响应行只取delta字段忽略其他结束标记识别不到不同服务商结束标记不同查看官方文档按实际标记判断做好兼容这张表里的每一条我几乎都踩过。印象最深的是“内容一次性全部出现”当时排查了半天代码最后发现是请求参数里stream写成了字符串true而不是布尔值true服务端当成了false。这种低级错误在第三天特别常见因为大家对参数格式还不熟。5.2 上下文丢失与串话的排查思路多轮对话里另一个高频问题是“串话”——A用户的对话内容出现在了B用户的会话里或者同一用户的新会话带出了旧会话的内容。这基本都是会话ID管理的问题。排查步骤很简单第一步在每次请求入口打印会话ID和用户标识第二步在组装上下文时打印实际取到的历史消息条数和第一条内容第三步对比两次请求的会话ID是否一致。多数情况下问题出在前端没有正确传递会话ID或者后端生成会话ID的逻辑有并发问题。还有一种情况是会话ID复用了。比如用用户ID当会话ID那同一个用户开两个窗口就会互相干扰。正确的做法是每次新对话生成一个独立的UUID作为会话ID前端负责保存并在后续请求中带上。5.3 我踩过的三个坑和对应的经验第一个坑是在流式回调里做耗时操作。我一开始在收到每个片段时都去写数据库结果数据库压力巨大而且因为回调是同步的整个流式输出被拖慢。后来改成先在内存里累积流结束后一次性写入性能好了很多。经验是流式回调里只做最轻量的操作重活放到流结束后做。第二个坑是忽略客户端断开。用户关掉页面后后端还在傻傻地等模型返回连接一直占着。后来加了检查在每次send时捕获IOException一旦发现客户端断开就主动取消模型请求释放资源。这个细节不做并发一高连接池就爆了。第三个坑是提示词里的变量没做长度限制。有次用户粘贴了一篇几万字的文章进来提示词直接超长模型报错前端显示“系统异常”。后来加了输入长度校验超过阈值就提示用户精简同时在服务端做截断兜底。经验是永远不要相信用户输入的长度服务端必须有自己的限制。5.4 性能与稳定性的几个实用技巧连接池要配好。如果用HttpClient默认连接池可能不够用流式连接占用时间长池子小了会排队。根据你的并发量估算每个流式连接占一个连接池子大小至少是预期并发数的1.5倍。超时要分层设置。连接超时短一点快速失败读取超时长一点给模型生成留足时间但整体请求也要有个上限防止极端情况下的无限等待。日志要打全。每次模型调用的请求ID、会话ID、输入Token数、输出Token数、耗时、是否成功这些都要记。出了问题这些日志就是你的救命稻草。第三天就把日志规范定下来后面省大事。降级方案要有。模型服务不可能100%可用要有兜底策略。简单的做法是准备一个备用模型主模型失败时自动切换或者返回一个预设的友好提示而不是直接报错。用户体验的底线是不能白屏。6. 第三天之后的路把模块变成能力走到这里一个能跑、能看、能排查的AI对话模块基本成型了。但我想说的是第三天真正的收获不是这几百行代码而是你脑子里那张架构图和对工程细节的敏感度。模型会换框架会更新但“请求怎么流转、异常怎么兜底、成本怎么控制、体验怎么保障”这些问题的答案是跨模型、跨框架通用的。接下来你可以往几个方向继续深入。一是把会话存储换成Redis加上过期策略让服务可以水平扩展。二是引入向量数据库把简单的滑动窗口升级成检索增强让AI能“记住”更久远的信息。三是加上监控和告警Token消耗异常、错误率飙升时能第一时间知道。四是做提示词的A/B测试框架用数据驱动提示词优化而不是凭感觉改。我在实际项目里的体会是AI应用开发和传统后端开发最大的区别不在于技术栈而在于思维方式。传统开发里输入和输出是确定的你写if-else覆盖所有分支就行。但AI应用里模型的输出是不确定的你永远无法穷举所有情况。所以你要做的不是“控制”模型而是“引导”和“兜底”——用好的提示词引导它用健壮的工程兜住它。这个思维转变比学会任何一个API都重要。最后分享一个我一直在用的小技巧每次调完模型把请求和响应完整地存一份到本地文件或者数据库里标注上时间、场景、效果评价。积累一段时间后这就是你自己的“案例库”。优化提示词、排查问题、给团队做分享都靠它。第三天就开始攒等到第三十天你会感谢自己。