企业官网建设流程全解析

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应用的标配。模型生成一个字就推一个字，用户能实时看到内容蹦出来，体验好很多。技术上通常用SSE（Server-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(); HttpResponse<InputStream> 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，再决定要不要上更复杂的策略。不要一上来就搞向量检索，那是给自己找麻烦。

具体实现上，你可以用一个List<Message>来存对话历史，每个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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-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是会话ID，value是消息列表。但要清楚这只是临时方案，重启就没了，生产环境要换成Redis或者数据库。

下面是一个简化的Service方法结构：

public void streamChat(String sessionId, String userInput, SseEmitter emitter) { List<Message> history = sessionStore.get(sessionId); history.add(new Message("user", userInput)); List<Message> 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 流式输出常见故障速查

流式输出是第三天最容易出问题的地方，我把遇到过的情况整理成一张表，方便对照排查。

这张表里的每一条我几乎都踩过。印象最深的是“内容一次性全部出现”，当时排查了半天代码，最后发现是请求参数里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都重要。

最后分享一个我一直在用的小技巧：每次调完模型，把请求和响应完整地存一份到本地文件或者数据库里，标注上时间、场景、效果评价。积累一段时间后，这就是你自己的“案例库”。优化提示词、排查问题、给团队做分享，都靠它。第三天就开始攒，等到第三十天，你会感谢自己。