企业官网建设流程全解析

前阵子我们团队做内部实验，两个资深Java工程师同时开发一个订单状态机模块，一个传统手写，一个用AI辅助，结果后者只用了不到一半时间，但代码评审时错误处理几乎全部要返工。这个场景让我彻底想明白一件事：AI落地对Java研发的影响，从来不是"岗位消失"这种粗颗粒度的焦虑，而是每个人在技术栈里的位置正在被重新排列——有人从编码位挪到了编排位，有人从实现位挪到了评审位，也有人没挪动，然后慢慢边缘化。这篇围绕Java研发视角的AI落地实战记录，想分享我在这段时间里验证过的大模型接入、Agent编排、私有化部署、日常研发提效和面试基本功重构的经验，适合正在犹豫"Java还能不能干"的工程师，也适合想在团队里推AI落地的技术负责人。

1. AI时代的座次表：编码体力活与决策活的分界线在哪里

1.1 从"编码效率"到"AI编排效率"的价值迁移

以前Java团队的竞争力是CRUD写得多快、并发压测能扛多高、系统能撑多大流量。现在新项目的设计文档里，已经开始出现"AI Agent 架构图""提示词策略""RAG知识库切片方案"这些节点。变量的名字没变，变量背后的能力要求变了。

我们换个直白的说法：在AI辅助下，把"业务需求翻译成代码"这件事的门槛正在急剧降低。一个实习生用自然语言描述需求，AI能生成80%的Spring Boot接口代码；一个熟练工和AI协作，能把另外20%的错误处理、事务边界、权限校验做好。所以行业里说的"AI替代程序员"，更准确的表述是：AI正在替代"只会把需求翻译成代码"的程序员，而选择性地抬升"能设计系统、能把控质量、能编排AI"的程序员的价值。

从Java技术栈本身来看，这一点更明显。语法、框架、工具链这些曾经需要反复记忆的东西，现在都可以通过对话获得。AI把"知道怎么做"压成了非常低的成本，而"判断该不该这么做"——比如这个接口是该用同步还是异步、这个缓存是该用本地还是分布式、这个事务边界划在哪里——依然是Java工程师的核心判断力，且AI越普及，这种判断力越值钱。

1.2 三类座次：谁在核心区，谁在替补席

结合我最近观察的几个团队，Java研发在新格局下大概分成三类岗位认知：

一个很现实的现象是，AI应用开发工程师这个位置，恰恰是Java后端最容易切入的。为什么？因为绝大部分企业级AI落地场景，不是做一个聊天网页，而是在现有订单系统、客服系统、风控系统、内容审核系统上叠加智能能力。这些系统的底座是Spring Boot、Dubbo、MySQL、MQ，这些都是Java的舒适区。AI应用开发工程师的日常工作，本质上还是Java工程师在做的事，只是多了一个"大模型"这个新依赖。

1.3 一个真实项目里的分工案例

我们团队最近做了一个订单批量导出功能，我刻意记录了这个任务中人机协作的分工情况。

AI负责的部分：生成DTO字段映射、写POI导出的模板代码、写正则表达式解析日期格式、生成状态枚举的转换逻辑、写基本的单元测试骨架。这部分耗时大约40分钟。

人负责的部分：确定导出的权限范围（哪些角色能用、哪些数据不能导出）、决定大数据量下的方案是分批查询还是异步任务、评估导出的内存峰值和GC压力、设计失败后的补偿机制、检查生成代码里潜在的空指针和并发问题、我把AI生成代码里的一个事务注解移到正确层级、补充了导出的审计日志。这部分耗时大约两个半小时。

结论很清楚：AI吃掉了编码里的体力活，人守住了编码里的决策活。这个"决策活"恰恰是Java面试里最常考的东西，也是很多初级工程师最不重视的东西。座次重新排列的底层逻辑就是，AI把体力活的工资打到接近零，而决策活的溢价越来越高。

2. Java工程接入大模型API：从裸调HttpClient到Spring AI

2.1 选型：为什么建议先掌握裸调用，再拥抱框架

现在Java里接入大模型API的方式大体有三种：直接用JDK的HttpClient拼HTTP请求、使用官方SDK、使用Spring AI这种集成框架。我建议初学者和团队技术负责人都不妨按这个顺序去理解，而不是一上来就套Spring AI。

我自己调试过裸调用之后，再看Spring AI里的ChatClient会觉得很多概念都是水到渠成的。更重要的是，裸调用能帮你建立对大模型API的"肌肉记忆"——比如你看到上下文长度参数就知道为什么不能无限制塞文本，看到流式输出就知道为什么长回答必须走流式。

2.2 第一行代码：用Spring AI实现流式对话

Spring AI目前对主流模型厂商都有支持，用起来最大的感受是"它把大模型当成一个数据源来配置"。Maven依赖大致这样：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> <version>最新稳定版</version> </dependency>

配置文件里只需要指定模型网关地址和API Key。这里要特别提醒一个容易被坑的地方：开发环境直接用云端API，生产环境如果走私有化网关，务必把base-url配置和API Key配置用配置中心管理，不要硬编码。

spring: ai: openai: base-url: https://api.example.com/v1 api-key: ${LLM_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7

然后写一个流式对话接口，核心代码非常简单：

@RestController @RequestMapping("/ai/chat") public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient = builder.build(); } @PostMapping(produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<String> chat(@RequestBody String prompt) { return chatClient.prompt() .user(prompt) .stream() .content(); } }

Flux<String>是WebFlux里的流式对象，前端通过Server-Sent Events就能收到逐字返回的效果。可能有读者会问，项目是Spring MVC，为什么还要引入WebFlux？实际上Spring AI的stream()返回的就是响应式流，对于流式输出这个场景，用Flux是性价比最高的选择，不需要整个项目切换成WebFlux。

2.3 生产级可靠性：超时、重试与限流降级

接大模型API和接普通HTTP接口不一样，它有几个很反直觉的坑。我列一下实际遇到的：

第一是超时设置。大模型生成一段长文本可能耗时数十秒，默认的HTTP连接超时5秒必然报错。需要把连接超时设短（3-5秒足够），读超时设得很长（60秒甚至120秒）。如果你用了RestClient或者OkHttp，要分别配置connectTimeout和readTimeout。

第二是重试策略要克制。我之前见过一个同事对每次请求做了3次重试，结果模型网关在高峰期雪崩，重试直接把网关打挂了。正确的做法是：只在网络异常和5xx时重试，4xx一律不重试；重试要带指数退避，并且加一个全局的熔断器。Java生态里Resilience4j是现成方案，按下面这个思路配置比较稳妥：

@Bean public Retry llmRetry() { RetryConfig config = RetryConfig.custom() .maxAttempts(2) .waitDuration(Duration.ofSeconds(1)) .retryExceptions(IOException.class, HttpServerErrorException.class) .ignoreExceptions(HttpClientErrorException.class) .build(); return Retry.of("llmRetry", config); }

第三是限流和降级。云API按token计费且有并发限制，内部系统如果没有限流，一次营销活动就能把月度预算打穿。建议在接入层做两层控制：一层是每秒请求数限流，避免打爆模型网关；另一层是业务降级开关，模型不可用时自动切回原来的规则引擎或人工流程。注意，AI是增强能力，不是核心可用性依赖，这条原则必须写进架构设计。

3. Agent落地：Java里跑通"规划-工具调用-执行"循环

3.1 Agent不是聊天框，是一个可执行的状态机

先纠正一个被各种营销号带偏的概念：Agent不是"更聪明的聊天框"，而是一个能自主完成多步任务的程序。类比一下：你让实习生去整理一份报表，他会先拆解步骤——拉数据、清洗、做透视、写结论——每一步可能需要查资料或问人，最后交付结果。这就是Agent的工作方式。

在Java里落地Agent，通常循着"规划-工具-记忆-执行"四个维度。规划是让大模型决定下一步做什么，工具是让大模型能调用你现有的Java方法，记忆是让大模型记住前面聊了什么、查到了什么，执行是把这些串起来的循环。其中最关键的是工具调用，因为大模型本身不会执行任何Java代码，它只能输出"我想调用某个工具、传什么参数"的结构化指令，真正执行还是你的代码。

3.2 用Function Calling让模型学会调用Java方法

Function Calling（函数调用）是当前Agent里最核心的机制。它的原理是：把Java方法的名称、描述、参数结构告诉模型，模型在回答时如果判断需要这个方法，就返回一个结构化调用请求，你的程序解析后执行并回传结果。

打开内置支持的Function定义，在Spring AI里可以直接用@Tool注解标记Java方法：

@Component public class OrderTool { @Tool(name = "queryOrderStatus", description = "根据订单号查询订单当前状态") public String queryOrderStatus(@ToolParam(description = "订单号") String orderId) { // 调用订单服务查询状态，返回给模型用于组织回答 return orderService.getStatusByOrderId(orderId); } }

然后构建ChatClient时注册这个工具：

this.chatClient = builder .defaultTools(new OrderTool()) .build();

有了这个基础，模型就能回答"帮我查一下订单20240088现在什么状态"这类问题。它内部发生的事情是：模型看到问题后，知道需要调用queryOrderStatus，于是在响应里带上一个结构化工具调用，Spring AI捕获后执行Java方法，把结果继续喂给模型生成最终回答。

这段代码看起来简单，但它开启的能力是质变级的。一旦模型能触发Java方法，你的AI就从"只能聊天"变成了"能操作系统"。查数据库、调第三方接口、发MQ消息，全部可以变成Agent的工具。

3.3 一个订单客服Agent的完整链路设计

以订单客服Agent为例，我设计了一个典型链路：

第一步，意图识别。用户问"我的订单怎么还没到"，模型判断用户意图是查询物流，同时从对话里提取订单号。

第二步，工具编排。Agent调用queryOrderStatus查订单状态，如果状态是已发货，接着调用queryLogisticsInfo查物流轨迹。这两个方法是后端已有的Java服务，通过Function Calling暴露给Agent。

第三步，决策与回复。Agent拿到订单状态和物流轨迹后，结合预设的回复话术，生成一段自然语言回答。如果物流信息显示异常（比如滞留三天未更新），Agent会调用createAfterSaleTicket自动生成售后工单。

第四步，人工兜底。如果用户的情绪词命中投诉等级，或者连续三次无法解决问题，Agent调用transferToHuman接口，把会话转接给人工客服。

这套链路里，Agent的价值不是替代客服，而是把客服从重复查询和简单应答里解放出来。Java工程师在这个项目里的工作，大部分还是传统的服务开发：写工具方法、设计兜底流程、做会话状态管理。唯一的增量是理解模型的行为方式，以及怎么设计工具能让模型更容易调用对。

3.4 知识库检索：embedding向量化的Java实践

企业级Agent绕不开的是私有知识库。模型本身只训练到某个时间点，你的内部制度、产品手册、历史故障记录它都不知道。RAG（检索增强生成）是目前最主流的补知识方案，它把文档先向量化存到向量库，查询时先检索相关内容，再塞给模型做回答。

Java侧的RAG链路通常是：文档解析 -> 切片 -> embedding模型向量化 -> 存入向量库 -> 查询时向量召回 -> 拼装上下文 -> 调用大模型回答。

向量库选型上，我比较过几款：

中小团队我一般推荐先用pgvector，原因是它不引入新的中间件，运维简单。Java里走JDBC就能插入和查询向量，示例大致如下：

// 向量化假设已经通过embedding模型得到 float 数组 float[] embedding = embeddingModel.embed(document.getContent()); // 插入 jdbcTemplate.update( "INSERT INTO knowledge (content, embedding) VALUES (?, ?)", document.getContent(), new PGvector(embedding) ); // 查询相似度前5 jdbcTemplate.query( "SELECT content FROM knowledge ORDER BY embedding <-> ? LIMIT 5", new Object[]{new PGvector(queryEmbedding)} );

这里有个实际经验的提醒：切片大小直接影响检索效果。我测试过512字和1024字两种切片，对于规章制度类文档，512字召回准确率明显更高，因为切片越短语义越聚焦，混杂信息越少。当然这也不是绝对，需要根据你的文档类型多做几组实验。

4. 企业要的不是API调用，是私有化部署的AI底座

4.1 为什么越来越多的企业要求本地化部署

技术圈聊大模型的时候喜欢比参数和效果，但企业里真正拍板的人算的是另一笔账：数据合规、安全边界、长期成本。

很多企业客户的数据是不能出内网的——订单数据、客户信息、财务报表，任何一条泄露都是事故。所以即使云API效果更好，他们也不得不选择私有化部署。这也是为什么很多公司宁愿用效果稍微差一点的本地开源模型，也要把数据留在自己手里。Java后端团队在这个环节反而成了主力，因为部署、监控、高可用、服务治理本来就是Java技术栈最擅长的。

如果你所在团队接到了私有化部署需求，我的建议是先明确三条底线：数据不出域、服务不中断、成本可审计。然后按"小模型先跑通-量化压缩-压测验证-灰度上线"的路径推进。

4.2 选模型：7B/13B/32B到底怎么理解，量化参数别忽视

本地部署第一个问题是选什么模型。7B、13B、32B这组数字指的是模型的参数量，B是billion，十亿。一个粗略的经验是：7B模型适合任务明确、回答可以接受一定模板化的场景；13B能覆盖大部分业务问答；32B以上开始接近云端API的智力水平，但硬件成本直线上升。

显存估算方面，推理一个模型需要的内存大致是参数量乘以精度字节数。以13B模型、4bit量化为例，模型权重约6.5GB，加上KV Cache和中间激活，推荐至少准备16GB显存。下面这个表是我实际测试时用过的参考：

这里的Q4_K_M是GGUF量化格式的一种，核心思路是把模型权重的精度从fp16压缩到4bit，换取成倍的体积和显存缩减。实际测试中，量化后的模型回答质量损失通常可以接受，但推理速度会明显改善。我踩过的坑是，一开始盲目追求原版fp16精度，结果一张A10跑不动，改成量化后不仅跑起来了，速度还提升了两倍。

4.3 Ollama快速拉起一个可用的推理服务

本地推理服务现在最省心的启动工具是Ollama。它把模型下载、运行、API暴露都封装好了，一条命令就能拉起服务。而且真的到了生产环境，它还支持作为OpenAI兼容格式的API被Java调用，迁移成本极低。

启动流程很直观：

# 安装或更新后拉取模型 ollama pull qwen2.5:7b-instruct # 启动服务 ollama serve # 测试一下 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b-instruct", "messages": [{"role": "user", "content": "你好"}]}'

Java侧接入时，和前面Spring AI一致，把base-url指向http://localhost:11434/v1即可。等于你只需要把云API的地址换成Ollama的地址，代码几乎不用改。

需要特别留意的是并发能力。本地模型在单张GPU上的并发吞吐并不像云API那么弹性，多路并发请求如果超过显卡显存，会出现OOM或者请求排队。工程上要在接入层设置信号量控制最大并发数，并给排队请求设置超时时间，避免请求无限堆积。

4.4 先RAG后微调：成本与效果的平衡点

部署完模型之后，很多人会纠结要不要微调。我在这块的态度比较明确：绝大多数场景先RAG，微调只用在少数必备场景。

RAG解决的是知识新鲜度问题，你的内部文档、近期故障记录、最新的业务规则，都可以通过向量检索注入上下文。成本是每次检索和拼接会消耗更多token，但换来的是知识可以随时更新，不用重训模型。

微调解决的是模型行为问题，比如希望它永远用特定格式输出、必须称呼用户为"您"、不能回答某些敏感词以外的内容。这些靠提示词也能管大部分，只有当你发现提示词怎么加都不稳定时，才值得考虑用一批高质量样例做微调。

以我们做的一个内部故障排查助手为例，最初用的就是7B量化模型加RAG，把过去一年的故障文档全部向量化。实测下来，大部分运维问题都能给出正确排查方向，准确率大约82%，足够作为一线运维的辅助工具。后来发现它在某些设备型号的判断上总是混淆，用了几百条标注数据做微调，准确率才提升到90%以上。这就是"先RAG后微调"的实际节奏。

5. 把AI塞进日常开发流程：我实测过的高效姿势

5.1 IDE插件实测：哪些任务值得交给AI

日常开发里，IDE的AI插件（不管是通义灵码、GitHub Copilot还是其他同类产品）已经被我用成了标配。但用了一段时间之后，我发现它不是一个"全部交给它"的工具，而是要做任务区分。

值得交给AI的任务：生成DTO/VO的字段映射和拷贝代码、写重复的CRUD接口骨架、把一长串if-else改写成策略模式、写单元测试的数据准备和断言骨架、把数据库字段翻译成Java实体类、生成正则表达式、解释一段复杂的历史代码逻辑。

不值得交给AI的任务：核心事务边界的判定、资金和权限相关逻辑、需要多人协同的接口契约设计、线上故障修复。这些场景里AI生成的代码风险太高，需要人逐行把关。

一个比较典型的例子是，我让AI把一段300行的订单状态迁移代码改写成状态模式，它生成的方案结构是合理的，但把两个状态之间的前置校验条件丢了。这种问题在Review时能发现，但如果完全信任AI就麻烦了。所以我的原则是：AI参与生成，人负责验收。

5.2 提示词模板：把需求翻译成可执行任务

很多人觉得提示词是文科生的事，但我用过之后认为，Java工程师写提示词比产品经理写提示词效果好一个数量级，因为你能给出更准确的技术约束。下面分享几个我反复在用的模板。

需求拆解模板：

我是一名Java后端工程师，以下是一个需求描述。请帮我拆解为： 1. 涉及的核心实体与字段 2. 需要提供的REST接口与请求/响应结构 3. 潜在的事务和并发问题 4. 建议的技术方案 需求描述：{{在这里粘贴需求}}

代码Review模板：

请作为资深Java架构师Review以下代码，重点检查： 1. 是否存在空指针和资源泄漏风险 2. 是否符合单一职责和开闭原则 3. 是否存在并发安全隐患 4. 是否有更简洁的实现方式 不要直接改写代码，先按点输出问题清单。 代码：{{在这里粘贴代码}}

SQL优化模板：

以下SQL在生产环境执行很慢，请分析执行计划中可能的问题， 给出索引优化建议和改写方案。请先解释你判断的依据，再给出SQL。 SQL：{{在这里粘贴SQL}}

这三个模板的共同点是让AI先解释、再输出方案，而不是直接期望它一步到位。实际测试下来，加上"先解释依据"这个约束后，生成质量明显提升，因为模型被引导去做推理而不是猜答案。

5.3 一个典型报错的排查链路：源发行版 17 需要目标发行版 17

说到日常开发，很多Java开发者在配置JDK 17项目时都遇到过这个报错："警告: 源发行版 17 需要目标发行版 17"。我第一次遇到时直接被搞懵，后来完整梳理过一遍排查链路，值得分享。

先理解根因：这条警告说明javac编译时，-source参数指定了17，但-target参数没有对应指定17，或者根本没有生效。-source规定源码语法版本，-target规定生成字节码的版本，两者如果不匹配，编译器会警告，极端情况下生成的class文件可能无法运行在目标JVM上。

完整的排查步骤：

第一步，确认JDK版本。命令行执行java -version和javac -version，确认当前命令行用的确实是JDK 17。如果IDE里和命令行的JDK版本不一致，后面怎么改都可能无效。

第二步，检查Maven的pom.xml。这是最常出问题的地方。如果maven-compiler-plugin没有显式配置，那么Maven默认只认java.version属性，而这个属性在不同父POM里的key可能不一样。检查以下配置：

<properties> <java.version>17</java.version> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

第三步，检查IDE的Project Structure。IntelliJ IDEA里如果Project SDK选的是17，但Project language level选的还是11，同样会报类似问题。这时候去Project Structure确认三处一致：SDK、Language Level、Java Compiler的target bytecode version。

第四步，统一改成maven.compiler.release。从JDK 9开始，推荐用release属性同时约束source和target，它还会顺带限制API的使用版本，能避免误用了高版本API。配置如下：

<properties> <maven.compiler.release>17</maven.compiler.release> </properties>

最后执行mvn clean compile验证。这个排查链路的启发是，很多Java里的奇怪报错都不是复杂问题，而是"版本不一致"这个元凶。AI在这类问题上的作用非常明显，把报错信息完整贴给AI，它通常能快速命中原因，因为它见过大量类似的问题样本。但如果你对JDK版本机制本身没有概念，AI给的建议也会看不懂，这就是基本功的价值。

5.4 测试场景：AI生成单元测试的正确姿势

AI写单测是提升效率最明显的场景之一，但也是翻车重灾区。我让AI给一段订单服务代码生成单测，它能在几秒钟内生成20个测试方法和Mock数据，看起来覆盖率很高，仔细一看却有个致命风险：AI生成的断言往往是根据它生成的Mock行为来推导的，容易形成"自己证明自己"的循环。比如Mock里过滤掉了空订单，断言就默认订单非空，而真正的Bug恰恰可能发生在空订单分支。

所以我现在用AI生成单测时，会强制加上两个约束：

请为以下方法生成JUnit 5单元测试： 1. 不要修改被测方法，Mock外部依赖请注明理由 2. 至少包含正常路径、边界值、异常入参、并发调用四个维度 3. 每个测试的断言必须来自业务规则，不能来自Mock的默认行为 代码：{{在这里粘贴代码}}

加了这个约束后，生成的测试明显更有业务指向性。但即便如此，我还是会人工补充两个最关键的场景：权限不足的调用和超大数据量下的性能边界。这两个场景AI普遍生成得比较弱，因为它们需要系统层面的理解，而不只是方法层面的逻辑。

6. 面试八股在AI时代变了吗：基本功仍是硬通货

6.1 冒泡排序、AQS、策略模式为什么还在考

最近有个朋友准备Java面试，一边刷题一边吐槽："现在AI这么强，谁还记得冒泡排序怎么写？"我给他的回答是：面试官考的不是你能不能默写，而是你在没有AI辅助的情况下，能不能把问题拆清楚、把边界说清楚、把取舍讲明白。

AQS（AbstractQueuedSynchronizer）这个知识点是最好的例子。AI可以告诉你AQS用了volatile state、CLH队列、CAS这些概念，但面试官真正想听的是：如果你来设计一个同步器，为什么选择用队列而不是自旋锁？公平锁和非公平锁的性能差距在什么场景下可以接受？这些决策能力是AI无法替你表达的，因为你的回答来自真实的项目权衡。

冒泡排序这种基础算法依然有意义，不是因为它有多实用，而是因为它是一把尺子。它能快速测出一个人的代码功底：变量命名是否清晰、边界条件是否考虑、时间复杂度的推导是否自然。AI时代里，八股文的价值已经从"知识储存"变成了"思维建模"——你能否不依赖外脑，把一个复杂问题从头到尾推理一遍。

6.2 Java里最实用的多组合模式：策略模式+枚举+Function

说到策略模式，这是Java面试的常客，也是实际项目中最常用的设计模式之一。我最近强烈推荐的一个组合是：策略模式 + 枚举 + Function接口，它能替代大量难维护的if-else，且没有一个多余的类。

以一个支付风控规则引擎为例，多种规则需要组合判断。传统写法是每个规则一个类，然后再写一个Factory，类数量翻倍。用枚举加Function，可以直接把规则逻辑收敛在枚举里：

public enum RiskRule { AMOUNT_LIMIT("单笔金额限制", ctx -> ctx.amount > 100000), FREQUENCY_LIMIT("频次限制", ctx -> ctx.orderCountPerMinute > 30), DEVICE_LIMIT("设备限制", ctx -> !ctx.isTrustedDevice); private final String desc; private final Function<RiskContext, Boolean> predicate; RiskRule(String desc, Function<RiskContext, Boolean> predicate) { this.desc = desc; this.predicate = predicate; } public boolean evaluate(RiskContext ctx) { return predicate.apply(ctx); } }

使用时可以非常优雅地遍历所有规则：

List<RiskRule> hitRules = Arrays.stream(RiskRule.values()) .filter(rule -> rule.evaluate(ctx)) .collect(Collectors.toList());

如果以后要增加规则，只需要在枚举里加一项，不用动调用方代码，也不违反开闭原则。AI在生成这类代码时表现很好，但前提是你自己先理解了这个模式的含义。你没法让AI帮你设计一个你理解不了的系统，这是AI落地时代最重要的一条经验。

6.3 AI辅助下的源码阅读与架构设计能力怎么训练

AI时代，源码阅读的习惯会被削弱——因为看不懂的类，直接让AI解释就行了。但这里有一个陷阱：AI的解释是"别人的二手理解"，而你实际调试时的断点、调用栈、变量变化，才是你真正消化的过程。

我的训练方法是：让AI充当出题人，而不是讲解员。打开ThreadPoolExecutor源码之前，先让AI给我出几个问题：

请基于ThreadPoolExecutor源码给我出5道理解题，不要给答案。 重点考察：线程池如何避免重复创建线程、队列满了之后的行为差异、shutdown和shutdownNow的区别。

然后我带着问题去读源码，读不懂再向AI提问。这种方式比直接让AI总结"ThreadPoolExecutor的核心原理"要扎实得多，因为问题逼着你主动去源码里找答案，而不是被动接受结论。

架构设计能力的训练也是同样的逻辑。多让AI做"方案对比"，而不是让它"给方案"。比如你可以问："在订单量翻十倍的前提下，分库分表和读写分离两种方案各自的优劣是什么？如果只能选一个，你会怎么选？"AI给出的对比能帮你扩宽视野，但最终的决策必须落在你对业务体量、团队运维能力、技术债务的判断上。

回头看，Java面试八股在AI时代没有被淘汰，它只是从"考记忆力"变成了"考判断力"。AI能告诉你答案是什么，但只有你自己能回答"为什么是这个答案"以及"在你的项目里这个答案成立吗"。这两种能力，恰好就是AI落地背景下，重新排座位时最值钱的两种能力。

最后说一点个人感受。我见过不少Java同事一开始对AI很抵触，觉得它代码写得不够好、提示词太麻烦、私有化部署成本高。但真正用起来之后，大家发现抵触的时间不如去把任务边界拆清楚。AI不是那种"装上就起飞"的工具，它更像一个刚入职的聪明实习生——上限取决于你给它多少上下文、多大权限、多清晰的验收标准。Java研发愿意花时间把系统边界画清楚、把工具设计好、把质量关口守住，AI就能成为这些年最好用的杠杆。