企业官网建设流程全解析

1. 先说结论：Java工程做AI落地，不是转型，是扩展

前几天有个做了六年后端的哥们问我：现在到处都在讲AI，Python写模型、写Agent，Java是不是要被晾在一边了？我没直接回答，反手给他看了我们最近做的一个多商户商城系统——Spring Boot 3 + MyBatis，里面接了三个大模型接口，做了智能客服、商品摘要、异常订单识别。线上跑了四个月，日均请求量二十多万，吞吐、事务、权限隔离一点没乱。他看完就沉默了。

这事我得先说透：AI落地在企业级场景里，真正值钱的从来不是“训一个模型”，而是把模型稳定、安全、高效地嵌进现有业务系统。而绝大多数企业现存的核心系统恰恰是Java写的，尤其是电商、金融、供应链、企业管理这类重业务、重事务、重权限的领域。你让Python工程师去处理多商户数据隔离、分布式事务、审计日志、灰度发布，他大概率要头大。而这些恰恰是Java工程师每天在干的事。所以Java不但没被AI抛弃，反而站在了“AI落地”的最前端，缺的不是技术，是方法。

这篇文章我一不想讲太虚的“AI思维”，二不想晒一堆PPT截图。我就用咱们Java工程师习惯的拆解方式，把“Java工程到AI落地”这件事分成五个部分：你的工程凭什么能做AI、API怎么接才能稳、业务场景怎么选、坑在哪里、你自己怎么涨本事。保证每一步都是可以直接抄的。

2. 落地第一层：API接入不复杂，但工程化很复杂

2.1 别一上来就训模型，先把你手里的接口吃透

很多Java工程师一开始接触AI，脑子里想的还是“我要训练一个模型”“我要搞GPU推理”。这就是第一个认知误区。企业级AI落地，绝大多数走的是“API调用模式”——你调用现成的模型服务，把业务数据喂进去，拿回结构化结果。这个模式和调一个RESET接口没有任何本质区别，只是更强调几个工程维度：超时、重试、限流、熔断、Token预算、响应解析、审计。

我们用得最多的是Spring AI这个框架，它把OpenAI、阿里云、百度等模型服务都抽象成了统一的ChatClient接口。如果你不想引入额外框架，用Spring Boot自带的WebClient也行。但我的建议是：哪怕团队只有两三个人，也用Spring AI做统一封装。原因很实际——Spring Boot的自动配置、属性绑定、智能提示都成熟得不能再熟了，新同事上手快，后期维护成本低。先建一个最简单的调用工程：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-openai</artifactId> </dependency>

然后你在application.yml里配置key和base-url，写一个Controller直接请求“帮我写一段商品描述”，响应就回来了。这一步三小时就能跑通。但请注意，跑通只是开始，真正的工程化在后面。

2.2 Prompt的温度、Token和成本预算：这三个数必须算明白

调模型接口和调普通接口最大的不同，是它的响应是不确定的、耗时有波动的、且按Token计费的。我建议每个Java开发者在初学阶段就养成算账的习惯。比如我们常用的大模型接口，价格大概是输入Token每百万几十到几百元不等，输出Token更贵。一次调用如果让模型生成300个Token，实际成本可能只有几分钱，但如果你写了个笨重的循环，在用户每次点击时都把几千行的历史聊天记录重新塞给模型，那成本就会呈指数膨胀。

更关键的是项目的“温度”参数，它控制输出的随机性。客服回复这种业务场景，温度要调低，比如0.2，保证每次回复的口径基本一致；文案生成这种创意场景，温度可以拉到0.8。我见过有人把所有接口都用一个默认温度，结果智能客服同一个问题回了三种答案，用户投诉“机器人精神分裂了”。这真不是段子，是线上事故。

另外，所有调用都建议加上超时和重试。网上文章常推荐超时30秒、重试3次，但粗放的重试会害死人——如果模型那边响应超时，真正原因是服务端过载，你立刻重试只会加重灾难。我们的标准做法是：第一次超时2.5秒，单个请求最多重试1次，重试间隔至少1.5秒，并且一旦触发熔断，后续请求直接降级到默认回复。配合Hystrix或Resilience4j，这部分代码量不大，但能把故障面切得非常小。

2.3 从Java Bean到Prompt再回到Java对象：数据管道要闭环

处理AI响应时，我强烈建议采用“结构化输出”模式。什么叫结构化？不是让模型给你一段废话，而是让它给你可解析的JSON。我们一般让模型输出这样的格式：“{"sentiment":"positive","summary":"这里放摘要"}”，然后直接用Jackson解析成Java记录类。Spring AI也提供了很便捷的实体映射能力，你只需要定义一个record，框架会自动把模型输出映射进去。

这里我要专门提醒一个问题：Java 21的Record类型很适合干这个事。它天然是值对象，不可变，自带头部读取，用来做AI响应的POJO比之前那套Lombok@Data + 一堆Setter的类清爽得多。我们的工程里，凡是涉及模型输入输出的类，全部重构成了Record。你管理起“这个字段是模型生成的头像地址”“那个字段是模型返回的置信度”这类东西，会感觉极其顺手。

输入侧也有一个工程化习惯：所有发给模型的数据必须经过清洗。最常见的坑是直接把数据库里的用户留言原封不动塞给模型，里面如果带有SQL注入、HTML片段或者恶意超长文本，轻则让模型输出错乱，重则诱发“提示词注入”。我们的做法是写一个统一的PromptTemplate工具类，用FastJson或Hutool做字段截断、非法字符过滤，再拼装成模板。这些代码不炫技，但能保命。

3. 落地第二层：多商户权限与AI的典型结合

3.1 行级权限：AI功能最大的拦路虎

我在文章开头提到的多商户商城，是典型的“Java工程+AI落地”实战场景。你以为最难的AI部分是什么？是推荐算法？是智能客服？都不是。最难的是——这个商户的AI助手怎么保证只看到这个商户的数据。很多AI功能是“让AI分析最近三十天的订单数据”，如果你直接把一个商户的订单表发给模型，没关系；但如果查询条件写漏了一个tenant_id，那所有商户的订单就全被AI“看光”了。这在电商、金融、医美这类行业，是要出合规事故的。

所以第一个要解决的是行级权限。我们用两种方式双保险。第一种，基于MyBatis拦截器自动拼接租户条件。因为我们的Mapper SQL全是手写的XML，为了不影响原来SQL的可读性，写了一个自定义Interceptor，在Executor执行前把SQL改写，强制加上“tenant_id = 当前上下文里的值”。

@Intercepts({ @Signature(type = Executor.class, method = "query", args = {Statement.class, Object.class, RowBounds.class, ResultHandler.class}) }) public class TenantInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { // 从ThreadLocal获取当前租户ID Long tenantId = TenantContextHolder.get(); if (tenantId != null) { // 改写SQL：在from后插入where条件 String sql = (String) invocation.getArgs()[1]; String newSql = injectTenantCondition(sql, tenantId); invocation.getArgs()[1] = newSql; } return invocation.proceed(); } }

第二种，AOP拦截Service层。拦截器管SQL可靠性，AOP管业务语义。比如“分析销售趋势”这个功能，AOP会把当前登录账号所管辖的商户ID列表传给一个PromptBuilder，生成到系统提示词里。这样做的好处是：即便SQL层面漏掉了某个条件，语义层也能兜底。两个机制互为补丁，线上运行半年没出过越权。

3.2 数据脱敏再喂大模型：这个步骤不能省

电商系统的订单里，往往带真实的用户手机号、详细收货地址。这些信息直接塞给大模型，即便模型服务商说数据不做训练，企业内部合规章也过不去。我们的规定是：凡是出网的业务数据，必须过一遍脱敏组件。手机号只保留前3后4，地址只保留到城市级别，身份证号直接用正则替换为星号。这一层是硬校验，在AOP里做，谁都不能绕过。

除了用户隐私，还有商户隐私。多商户平台的财务数据、折扣策略对AI模型来说没有限制，但对其他商户来说就是敏感数据。因此我们的提示词模板里，从不直接出现“某商户的利润率是45%”这种信息，而是让模型基于模型已知的行业常识给出分析方向，再由Java层自己计算利润率和趋势。也就是说：模型做的是“语义加工”，精确数字永远留在Java侧。这也是一条特别值得写进面试经验里的原则——AI替你思考，但别让AI替你算数。

3.3 一个完整的AI功能：评论摘要与情感分析

我们实际做的一个小功能是“商品评论摘要”。用户进到商品页，看到几千条评论，体验很差。传统方案是统计好评率，但那不解决问题。我们的方案是：每天凌晨用批处理把当天新增评论抽出，调模型生成三条摘要关键词，同时打上情感标签，写入一张独立的结果表。

具体流程是：定时任务读取未处理的评论，每条评论控制在200字以内，拼到一个Prompt里，“请从这些评论中提取他们最关心的三个点，用短句表达，并给出整体情感是正面、负面还是中性”。在Java代码里，我们用Stream API把这些评论做分组聚合，按“商品ID+日期”维度打包，再发给模型。为什么按天打包？因为模型上下文长度有限，评论太多会截断，太少则摘要不稳定。我们最开始按SKU维度打包，发现某些爆款一天几千条评论，直接塞满了上下文窗口，后来改成“每个商品每天最多取前100条评论”，效果反而更稳定。这类细节，就是靠踩坑踩出来的。

模型返回的JSON再转换成Record，插入结果表。用户在App端只看到这个摘要，加载速度快、体验干净。整个链路跑下来，模型调用成本每天约几十元，但差评处理率降了三成。

4. 落地第三层：避坑指南，性能、安全、评测全实录

4.1 性能吞吐：别让一次AI调用拖垮你的接口

很多团队接入AI后遇到一个尴尬场景：AI功能在测试环境挺好，一上线业务接口的P99延迟从80ms涨到1300ms。原因很简单——你就在用户请求线程里同步调大模型，大模型的生成速度再快也要几百毫秒到一两秒。我们的处理方式分四档：

第一档，只把“非关键路径”交给AI。比如商品详情页主接口不放AI调用，而是先返回缓存的基础数据，AI生成的摘要异步推送给客户端。第二档，用CompletableFuture做并发的多源调用。比如同时调情感分析、关键词提取、违规检测，三个AI请求并行，总耗时约等于最慢的那个，而不是三个相加。第三档，引入本地缓存。AI生成结果先放Redis，有效期72小时，同类需求直接命中缓存。第四档，做降级策略。AI服务不可用时，返回预置的默认文案或摘要。我们把这四档做成一个“AI能力路由配置”，每条业务线自己定夺，既灵活又能兜底。

4.2 内容安全：这条红线不能碰

我必须专门讲这你条，因为太容易被忽视了。AI生成内容如果没有任何拦截，负面内容、隐私内容、诱导性话术都可能跑到前台展示。我们做了两层过滤：输入侧，用户给AI的提问要过关键词净化和长度限制；输出侧，模型返回的文本要再过一次敏感词列表和正则匹配。这两步都在Java侧完成，不把希望全压在模型自身上。

这里要特别强调一个原则：不做“无限制”“无审核”的AI。你接的免费模型、开源模型，能力越开放，越要加过滤层。企业级系统如果因为AI生成内容被处罚，损失的绝对不是一点点。我们的经验是，ES索引中专门建了一个“有害词库”字典，每两个小时同步一次新词，过滤逻辑写在AOP切面里，谁调AI都必须过这个切面。虽然加了一句“若命中违规词，直接返回纯提示文案”，但它比大多数模型自身的对齐更稳。后台审计日志记下每一次调用的输入输出，万一有问题能够秒级溯源。

4.3 质量评测：没有评测体系的AI上线，就是裸奔

传统接口你写个单元测试，断言返回值是不是对。AI接口没法做断言“答案是否正确”，但不代表不能测。我们做得比较笨但有成效：一是准备一批“金标准案例”，比如“如果客户问退款多久到账，期望回答不超过40字且包含退款周期”；二是建立一套自动评测脚本，跑完调用各类模型，比对维度包括“是否包含关键词”“长度是否符合”“有没有违规词”等，输出评分。这个脚本挂在CI流水线里，每次改动Prompt模板都会强制跑一遍。

第二类是线上动态监控。我们记录每个AI调用的上下文长度、Token数、耗时、返回状态、用户是否点了“有用”。特征数据汇聚到Prometheus，用Grafana看板检视。初始阶段，我们盯着一个关键指标“AI回复被复制率”——如果用户愿意把AI回的内容复制走，说明它具备实用价值。这个数字从8%涨到21%的过程中，我们迭代了十几版Prompt，把“高冷风”改成“接地气风”，效果完全不一样。没有数据，你根本无从判断哪里要改。

5. 面试与进阶：Java工程师如何准备AI方向

5.1 面试官真正想考你什么

最近“Java+AI”相关的面试题特别多，但大部分是换汤不换药。我以面试官视角整理了一下考法。首先是基础串讲：JVM内存区域有什么用——实际上在问你怎么分析AI服务的GC压力；并发集合差异——实际上在问CompletableFuture怎么编排多个AI请求；Spring Boot自动装配原理——实际上在问Spring AI的Starter怎么生效。给我感觉，面试官并不在意你背了几道Transformer面试题，而是看你能不能把Java老底子嫁接到AI工程上。因此我的建议是，先把并发、JVM、Spring、MyBatis这些老知识重新刷一遍，比啃“提示词工程”有用十倍。

第二类考法是场景设计：“如果让AI总结一份长文档，但它的长度超限，你怎么办？”答案是分块、摘要再聚合。不能只答“把文档切碎”，要说清楚用什么切、切多大、切了以后怎么合并摘要、遇到交叉信息怎么去重。这些细节实践逻辑都来自我们的真实业务。所以简历里但凡写“做过AI功能”，就该把这些场景细节嚼碎，经得起追问。

5.2 学习路线：别想一口吃成AI大模型专家

很多Java工程师拿到一堆网课和书，第一反应是去补线性代数、补Python、补Transformer数学原理。我不反对，但要分清主次。我身边从Java转“AI落地工程师”的人，几乎清一色是走“应用—框架—原理”这条路：先熟练调用模型API，把Prompt模板做到精熟；再研究Spring AI、LangChain4j这类Java侧的Agent编排框架；最后才去读一些关于Token注意力机制的基础读物。因为AI落地岗位大部分时间在做工程、做数据、做评测，而不是训练模型。

在实践层面，最建议把老项目翻新。找一个你曾经做过的、哪怕是个学生管理系统，给它加两个AI功能：用大模型做自然语言查询语法转发，用RAG检索库做问答。只要真刀真枪跑起来，你在面试里的说服力远超背一百个理论名词。我见过最离谱的简历写着“熟悉大模型微调”，一问LoRA跟全量微调的区别，答不出来。这就是典型的思维错位。

5.3 几个可以复制的实践项目方向

结合Java技术栈，我特别推荐三个项目方向。第一个：电商导购Agent。基于Spring Boot实现，接收用户描述，解析意图（售前、售后、物流），调用商品服务做条件筛选，再用大模型生成推荐理由。这个项目能覆盖RAG、Prompt模板、多轮对话、结果缓存，所有核心技能点都练到了。第二个：代码评审助手。用Java解析Git提交的diff，调大模型分析有没有明显的空指针、事务失效、权限绕过风险。这个项目跟Java本身强相关，最能体现Java工程师的判别能力。第三个：Data Chat——让业务人员用自然语言查数据库。Java侧把自然语言转成查询语句，用行级权限约束到当前用户的数据范围。这个项目一旦做出来，就是面试中的会议终结者。

6. 结尾：我踩过坑之后的真心话

如果你看到这里，说明你是真想好好做Java+AI的结合，而不是来凑热闹。我在自己项目的早期，也走过弯路：以为把模型API接进来就完事，结果上线当天就被用户投诉回答文不对题；以为模型能替我做运营，结果一台服务器因为频繁调用差点被打满；为图省事没做权限隔离，差点害得一个商户看到另一个商户的数据。这些经验教训，系统性地写在上面五个章节里了，但愿能帮你把这块绊脚石搬开。

我个人现在的体会是：Java工程师做AI落地，最大的优势不是会写Spring Boot，而是天然具备工程化素养。AI给了我们一个更强的“语义大脑”，但Java帮我们保证了这个大脑被关在专业的护栏里。你不需要成为大模型算法专家，只需要学会把模型的输出当作一种特殊的、不可靠的外部依赖来管理。这个思路转过来以后，你会发现自己已经从“Java开发”悄悄进化成“AI落地工程师”了。

最后再送一个小技巧：在开始项目前，先拿出一小时把上面说的“权限隔离、输出过滤、成本预算、效果评测”四件事写进技术设计文档。不用详细，每项两百字就够。等项目上线，你会发现这四个方案为你省掉的返工时间，是项目总时的三分之一。这是真的。