--- title: Claude Code 接入第三方模型实战：JVM 智能诊断与慢查询治理 description: 通过 Claude Code 接入 GLM-5.1 模型，完成 JVM 智能诊断助手从零搭建和百万级数据量慢查询治理两个实战任务，分享 AI 辅助编程的工作方法与踩坑经验。 category: AI 编程实战 head: - - meta - name: keywords content: Claude Code,AI编程,GLM-5.1,JVM诊断,慢查询优化,AI辅助开发,Arthas,Agent,Spring AI --- 大家好，我是 Guide。前面分享过 [IDEA 搭配 Qoder 插件的实战](./idea-qoder-plugin.md)和 [Trae 接入大模型的实战](./trae-m2.7.md)，分别覆盖了 JetBrains 体系和 VS Code 体系下的 AI 辅助编码。这篇换个角度，聊聊 **Claude Code 接入第三方模型** 的实战体验。 Claude Code 本身是 Anthropic 官方的 CLI 编码工具，但它支持通过环境变量切换底层模型。这意味着你不必局限于 Claude 系列，完全可以接入其他模型来使用。本文以 GLM-5.1 作为示例，但接入方式是通用的——换成其他兼容模型，流程基本一致。 我选了两个比较有代表性的复杂场景来验证： - **场景一**：从零搭建一个基于 Arthas 的 JVM 智能诊断 Agent，涵盖技术选型、架构设计、编码落地的完整流程 - **场景二**：在百万级数据量的既有订单系统中定位并治理慢查询，考验 AI 对现有代码库的理解和增量优化能力 一个是从零开始的工程交付，另一个是面对既有系统的性能治理，正好覆盖 AI 辅助编程的两种典型工作模式。 ## 环境准备：Claude Code 接入第三方模型 在正式开始之前，需要完成 Claude Code 与第三方模型的对接。整个配置过程分三步： **第一步**：安装 Claude Code ```bash npm i -g @anthropic-ai/claude-code@latest ``` **第二步**：安装 cc-switch 完成模型切换（macOS 用户可通过 homebrew 安装，详情参考 cc-switch 官方文档：） **第三步**：按照模型提供方的说明，完成 Claude Code 内部模型环境变量与目标模型的对应关系配置。以 GLM-5.1 为例，参考： 配置过程截图如下： 点击加号添加模型： ![点击添加模型](https://oss.javaguide.cn/ai/coding/glm5.1-cc/add-model-entry.png) 选择对应的模型： ![选择模型](https://oss.javaguide.cn/ai/coding/glm5.1-cc/select-model.png) 配置参数： ![配置参数](https://oss.javaguide.cn/ai/coding/glm5.1-cc/config-params.png) Claude Code 内部模型环境变量与目标模型对应关系的 JSON 配置： ![Claude Code 内部模型环境变量与模型对应关系 JSON 配置](https://oss.javaguide.cn/ai/coding/glm5.1-cc/model-env-json-config.png) 如果你更偏向页面开发，推荐通过 VSCode + Claude Code for VS Code 方式进行交互和编码验收。完成插件安装之后，可以直接在 IDE 中与模型对话和代码审查，相对于 CLI 界面会更直观一些： ![VSCode + Claude Code for VS Code](https://oss.javaguide.cn/ai/coding/glm5.1-cc/vscode-claude-code.png) ## 场景一：从零搭建 JVM 智能诊断 Agent ### 为什么需要 JVM 智能诊断助手？ JVM 线上诊断一直以来都是 Java 开发最棘手的问题。在传统开发模式下，面对性能瓶颈或线上故障，研发人员的排查路径基本固定： 1. 查看 Grafana 监控面板，初步定位异常方向 2. 登录线上服务器，排查 CPU、内存、GC 等各项指标 3. 明确 Java 应用层面的问题后，启动 Arthas 执行一系列诊断指令，逐步缩小问题范围 4. 定位到具体代码段，分析根因并制定修复方案 在 AI 出现以前，这套流程虽然繁琐，但确实是最直接有效的手段。但随着业务越来越复杂，故障响应时效要求也越来越高，传统模式的弊端越来越明显： - **监控指标过于主观**：面对 CPU 飙升、内存泄漏、OOM 等千奇百怪的问题，监控面板上的指标繁多，研发人员往往依赖经验做主观推断，缺乏系统化的诊断方法论 - **诊断链路过于冗长**：从 Grafana 面板到线上服务器再到 Arthas 诊断，整个排查链路涉及多个工具的切换和衔接，不仅耗时，对于紧急的线上故障止血来说显得非常低效 - **高度依赖工程师经验**：Arthas 确实是一款强大的 JVM 诊断利器，内置各种增强指令可以深入字节码查看运行时细节。但代价是开发人员必须熟悉各种指令参数和推理路径，才能准确完成问题定位 随着 AI 技术的演进，特别是 Agent 和 Skill 等概念的成熟，笔者就有了一个工程化的构想：能否借助 AI 将诊断经验沉淀复用，让 AI 根据既有经验构建明确的决策路径？同时结合它的决策方案赋予对应的工具，使其基于用户给定的服务名和故障表象，自动化连接线上服务器完成诊断，定位具体代码段，最终输出问题根因和解决方案。 ### 需求交付与架构设计 有了构想之后，接下来就是技术选型和方案落地。笔者将完整的需求描述交给 AI： ```bash 研发一款基于Arthas的智能体诊断工具，该工具需实现以下核心功能： 1. 当用户输入线上故障服务名称及具体故障现象后，系统能够自动定位至目标故障服务器，主动对目标服务进行实时监控与深度分析。 2. 通过集成Arthas的反编译功能，精准定位到引发故障的具体代码段 3. 基于分析结果生成包含问题根因、代码修复建议及实施步骤的完整解决思路。 请提供该工具的技术选型方案，包括但不限于开发语言（优先考虑Java技术栈）、核心框架、数据库表设计、部署架构等，并设计详细的系统实现方案，涵盖功能模块划分、数据流程设计、关键技术难点及解决方案等内容。 ``` AI 收到需求后，没有立刻开始写代码，而是先结合项目上下文（完全空的文件夹）进行推理分析，自主完成了一份包含十几个阶段的完整技术方案。”给一个目标，AI 自己拆出整条路径”——这是 AI 辅助编程的一大优势，你可以把精力放在需求描述和方案评审上，让 AI 负责路径规划。 ![AI 自主完成技术方案规划](https://oss.javaguide.cn/ai/coding/glm5.1-cc/ai-tech-plan.png) AI 结合需求，针对 Agent 拆解出技术选型和 Arthas 集成方案的检索。从检索关键字可以看出，它在方案选取上优先考虑成熟稳定的解决方案： ![AI 检索 Agent 技术选型和 Arthas 集成方案](https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-arthas-integration-research.png) AI 检索了大量资料和 Arthas 官方文档后，输出了下面这份系统架构设计图。从上到下分三层：用户层输入服务名和故障现象，Agent 层由 Skill 引擎、Arthas HTTP Client 和 AI 分析引擎三大核心模块协同工作，最底层通过 Arthas 内置 HTTP API 对接多个目标服务实例。架构的模块划分和职责边界清晰，从故障输入到定位代码再到生成报告的完整链路设计到位： ![AI 输出的系统架构设计图](https://oss.javaguide.cn/ai/coding/glm5.1-cc/system-architecture-design.png) AI 给出了架构图之后，还进一步拆解了 6 个核心组件的职责分工——从 AI Agent Server 的流程编排，到 Arthas HTTP Client 的会话管理，到 Skill 引擎的诊断步骤链定义，再到 AI 分析引擎的报告生成，每个组件的边界和协作关系都交代得比较清楚： ![AI 输出的核心角色分工表](https://oss.javaguide.cn/ai/coding/glm5.1-cc/core-component-roles.png) 最后来看最重要的数据流设计。架构设计明确之后，只要数据流链路完整清晰，基本就可以着手开发了。AI 结合一个常见的 RT 超时场景，给出了完整的诊断链路——从 Skill 匹配、诊断步骤执行、问题追踪、根因定位，到 Arthas 反编译和最终的诊断报告输出。AI 针对 Arthas HTTP API 设计了完整的会话模式交互流程（init_session → async_exec → pull_results → interrupt_job → close_session），连`watch`、`trace`这类持续监听型命令的异步轮询机制都考虑到了。这一点在评审时需要重点关注——如果 AI 对底层工具的通信模型理解有偏差，后续编码阶段就会出现问题： ![AI 输出的数据流设计](https://oss.javaguide.cn/ai/coding/glm5.1-cc/data-flow-design.png) 其他细节就不多做赘述了。整体来说，架构和数据流链路都比较到位。AI 不仅针对既有需求给出了方案，还主动输出了 6 个后续扩展方向——WebSocket 实时推送、诊断知识库向量化存储、已知 Pattern 的自动修复补丁、告警联动自动触发诊断、自定义 Skill 市场、多语言支持。这些扩展方向都紧扣当前架构的技术延伸：知识库基于现有的诊断报告数据，自动修复基于已有的 Skill 引擎，告警联动基于现有的服务实例查询机制。 ![AI 给出的后续扩展建议](https://oss.javaguide.cn/ai/coding/glm5.1-cc/extension-suggestions.png) ### 编码交付与工程结构 确认方案没有问题后，笔者直接下达开发指令： ```bash 整体方案没有问题，请完成开发工作吧 ``` AI 收到指令后，开始自主编码。按照之前的架构设计，逐模块推进——从父 POM 和 Maven 多模块骨架搭建，到通用工具类、数据模型、数据访问层、Arthas 客户端封装、Skill 引擎、AI 分析引擎、业务逻辑层、Web 控制器，直到启动模块和部署配置，11 个子步骤全部完成： ![AI 自主编码过程](https://oss.javaguide.cn/ai/coding/glm5.1-cc/ai-coding-process.png) 片刻之后，AI 完成了全部编码工作，并输出了一份详细的交付清单。9 个模块、46 个文件全部到位——从通用工具类到 7 个内置诊断 Skill，从 Arthas HTTP API 的 exec+session 双模式封装到 Spring AI Alibaba 诊断分析器，一个不少： ![AI 完成编码后输出的交付清单](https://oss.javaguide.cn/ai/coding/glm5.1-cc/delivery-checklist.png) 先看整体模块结构，AI 按照 Java 多模块的标准规范完成了工程划分，从上到下严格遵循 common→model→dal→client→skill→ai→service→web→bootstrap 的依赖层级，命名规范统一。 agent-skill 模块值得关注，AI 设计了 Skill 引擎的抽象接口，并内置了 7 个覆盖常见 JVM 故障场景的诊断技能（CPU 飙高、OOM、死锁、慢接口、GC 异常、线程泄漏、类找不到），每个 Skill 都定义了完整的诊断步骤链。这种”框架 + 内置实现”的设计思路，扩展性不错： ```bash jvm-ai-agent/ ├── jvm-ai-agent-server/ # 智能体服务端（核心） │ ├── agent-common/ # 通用模块：工具类、常量、DTO │ ├── agent-model/ # 数据模型：实体、数据库映射 │ ├── agent-dal/ # 数据访问层：Mapper、Repository │ ├── agent-arthas-client/ # Arthas HTTP API 客户端封装 │ ├── agent-skill/ # Skill 引擎（诊断方法论） │ ├── agent-ai/ # AI 分析引擎 │ ├── agent-service/ # 业务逻辑层（含服务实例查询） │ ├── agent-web/ # Web 层：REST API、WebSocket │ └── agent-server-bootstrap/ # 启动模块 │ └── pom.xml # 父 POM ``` 再看诊断核心逻辑，AI 严格按照架构设计中定义的数据流完成了完整的诊断业务链开发。整个 `executeDiagnosis` 方法按照 Skill 匹配、实例定位、诊断链执行、动态命令解析、AI 分析、报告生成的流程推进，异常处理也考虑到了非关键步骤失败时继续执行的容错策略： 1. **Skill 匹配**：通过`DefaultSkillMatcher`根据故障现象关键词匹配最佳诊断技能 2. **实例定位**：通过`ServiceInstanceLocator`根据服务名解析目标实例 IP 和 Arthas 端口 3. **诊断链执行**：遍历 Skill 定义的诊断步骤链，依次执行 Arthas 命令并收集结果 4. **动态命令解析**：从 Arthas 输出中提取类名、方法名等上下文变量，注入后续步骤的动态命令模板 5. **AI 分析报告**：将全部诊断数据交给 AI 分析引擎，生成包含根因、修复建议、严重程度的结构化报告 ```java private void executeDiagnosis(DiagnosisRecord record, DiagnosisRequest request) { try { // 1. 匹配 Skill Optional skillOpt = skillMatcher.findBestMatch(request.getSymptom()); if (skillOpt.isEmpty()) { failDiagnosis(record, "无法匹配到合适的诊断技能"); return; } SkillDefinition skill = skillOpt.get(); // ...... // 2. 定位目标实例 ServiceRegistry instance = instanceLocator.resolveInstance( request.getServiceName(), request.getInstanceIp()); // ...... // 3. 执行诊断步骤链 List chain = skill.getDiagnosticChain(); StringBuilder allDiagnosticData = new StringBuilder(); String decompiledCode = ""; Map contextVars = new HashMap<>(); for (int i = 0; i < chain.size(); i++) { DiagnosticStep step = chain.get(i); // ...... 初始化步骤实体 try { // 解析动态命令（支持上下文变量注入） String command = resolveCommand(step, contextVars); // ...... // 执行Arthas命令并记录耗时 String result = executeStep(host, port, step, command); // 如果是 jad 结果，记录为反编译代码 if ("jad".equals(step.getResultType())) { decompiledCode = result; } // 从结果中提取上下文变量供后续步骤使用 extractContextVars(result, contextVars); } catch (Exception e) { // 非关键步骤失败时继续执行 // ...... } } // 4. AI 分析 String report = diagnosisAnalyzer.analyze( request.getSymptom(), allDiagnosticData.toString(), decompiledCode, skill); // 5. 保存报告（从Markdown报告中提取根因、严重程度等结构化字段） // ...... // 6. 更新诊断记录状态 record.setStatus(DiagnosisStatus.COMPLETED.getCode()); // ...... } catch (Exception e) { failDiagnosis(record, e.getMessage()); } } ``` ### Agent 交互页面集成 在 AI 编码期间，笔者查阅了 Spring AI Alibaba 的官方文档，发现它提供了现成的 Agent Chat UI。与其让 AI 从头生成前端页面，不如直接集成这个交互组件，实现 SSE 流式输出的诊断体验。于是笔者给了一条简短的指令： ```bash 根据Spring AI Alibaba官方文档（参考链接https://java2ai.com/docs/frameworks/studio/quick-start：），实现agent智能体交互页面开发工作 ``` 只给了一个文档链接和一句话，AI 就自己去读官方文档、理解集成步骤、完成了页面开发。这也是使用 AI 辅助编程的一个实用技巧：当你只需要集成某个现成组件时，直接给出文档链接往往比详细描述需求更高效。 ![AI 完成 Agent Chat UI 页面集成](https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-chat-ui-integration.png) 到这里，一个完整的智能诊断 Agent 就构建完成了。为了验收功能，笔者在本地起了一个 CPU 飙升的测试接口： ```java @Slf4j @RestController public class TestController { @RequestMapping("cpu-100") public void cpu() { while (true){ } } } ``` 启动 Agent 服务，访问 `http://localhost:{应用端口}/chatui/index.html`，在聊天框输入：`order-service 程序CPU飙升,请协助排查`。Agent 在收到故障表象后，完成了完整的诊断链路——先通过 Dashboard 获取概览定位到 CPU 占用最高的线程 ID，再基于线程栈帧信息定位到问题代码段，最后通过 Arthas 反编译（jad）输出热点代码并生成包含根因分析和修复建议的完整诊断报告。整个过程 Agent 全程自主完成，SSE 流式输出让每一步诊断进度都清晰可见： ![Agent 诊断效果演示](https://oss.javaguide.cn/ai/coding/glm5.1-cc/agent-diagnosis-demo.png) ## 场景二：百万级数据量下的慢查询治理 场景一验证的是 AI”从 0 到 1 的规划与交付能力”，那场景二要验证的就是另一个维度：**在一个已有一定复杂度的代码库中，AI 能否准确理解既有架构、定位问题、并完成增量优化。** ### 问题定位：搜索接口耗时 18 秒 这是一个基于 Spring Boot + MyBatis 的订单查询服务（glm-testing-service），核心业务围绕订单的查询和分析展开，包含四个接口： | 接口 | 路径 | 说明 | | ------------ | ------------------------------ | ------------------------------------ | | 用户订单查询 | POST /api/orders/user | 按用户 ID 查询订单列表，支持状态筛选 | | 订单搜索 | POST /api/orders/search | 按时间区间+金额+商品关键词搜索订单 | | 品类销售统计 | GET /api/orders/category-stats | 按订单状态统计各品类销售汇总 | | 组合条件筛选 | POST /api/orders/filter | 按用户+多状态+多品类组合筛选 | 数据库中灌入了百万级测试数据，对应的表结构如下： ```sql CREATE TABLE `orders` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_no` VARCHAR(64) NOT NULL, `user_id` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 0, `total_amount` DECIMAL(10,2) NOT NULL, `product_name` VARCHAR(256) NOT NULL, `category` VARCHAR(64) NOT NULL, `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_status` (`status`), KEY `idx_category` (`category`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; ``` 项目通过 AOP 切面自动记录每个接口的执行耗时，用于快速定位性能瓶颈： ```java @Around("controllerPointcut()") public Object printExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable { long startTime = System.currentTimeMillis(); Object result = joinPoint.proceed(); long costTime = System.currentTimeMillis() - startTime; log.info("[{}] {}.{} 耗时: {}ms", Thread.currentThread().getName(), className, methodName, costTime); return result; } ``` 向数据库灌入百万级测试数据后，对搜索订单接口进行压测。该接口涉及关键词模糊匹配+时间区间+金额过滤的组合查询，例如下面这个搜索请求： ```bash curl -X POST http://localhost:8080/api/orders/search \ -H "Content-Type: application/json" \ -d '{"startTime": "2025-01-01", "endTime": "2026-12-31", "minAmount": 500, "productName": "蓝牙", "pageNum": 1, "pageSize": 10}' ``` 系统日志直接输出了刺眼的慢查询告警： ```bash [http-nio-8080-exec-1] OrderController.searchOrders 耗时: 18375ms ``` `LIKE '%蓝牙%'`的全表扫描导致接口耗时近 18 秒，当前业务接口的实现性能完全无法满足线上要求： ![搜索接口耗时 18 秒的调测结果](https://oss.javaguide.cn/ai/coding/glm5.1-cc/search-api-18s-result.png) ### 分析与优化方案设计 笔者直接将系统日志中的慢查询告警丢给 AI，让其结合项目既有代码完成推理分析和优化方案设计： ```bash 针对系统日志中记录的"[http-nio-8080-exec-1] OrderController.searchOrders 耗时: 18375ms"这一慢查询接口问题，对订单业务进行全面梳理分析并提供优化建议。 ``` AI 定位到目标业务代码，结合 SQL 和表结构，从索引设计维度给出了系统性的解决方案： ![AI 给出的慢查询解决方案](https://oss.javaguide.cn/ai/coding/glm5.1-cc/slow-query-solution.png) 同时给出了分阶段优化建议和预期效果： ![AI 给出的分阶段优化建议](https://oss.javaguide.cn/ai/coding/glm5.1-cc/phased-optimization-suggestions.png) 确认方向没问题后，笔者给出最终优化指令： ```bash 请结合项目现有技术栈，对慢查询模块进行系统性优化 ``` AI 逐个梳理了每个接口的业务逻辑和查询细节。优化步骤自底向上，从数据库层面推进到应用层面，方案涵盖以下几个关键点： **数据库层面**——新增 5 个精准索引： - 全文索引`ft_product_name`（ngram 解析器，支持中文分词）替代`LIKE '%xxx%'`全表扫描 - 复合索引`idx_create_time_amount`覆盖时间+金额的 WHERE 和 ORDER BY，避免 filesort - 覆盖索引`idx_search_covering`让 COUNT 查询不回表 - 组合索引`idx_user_status_category`优化多条件筛选 - 覆盖索引`idx_status_category_amount`优化品类聚合统计 ```sql ALTER TABLE `orders` ADD FULLTEXT INDEX `ft_product_name` (`product_name`) WITH PARSER ngram; ALTER TABLE `orders` ADD INDEX `idx_create_time_amount` (`create_time` DESC, `total_amount`); ALTER TABLE `orders` ADD INDEX `idx_search_covering` (`create_time`, `total_amount`, `product_name`); ALTER TABLE `orders` ADD INDEX `idx_user_status_category` (`user_id`, `status`, `category`); ALTER TABLE `orders` ADD INDEX `idx_status_category_amount` (`status`, `category`, `total_amount`); ``` **应用层面**——SQL 和 Service 层同步优化： - `LIKE '%xxx%'`替换为`MATCH ... AGAINST`全文检索 - 深分页场景自动切换延迟关联（Deferred Join），通过覆盖索引子查询先定位主键再回表 - 按需 COUNT：默认不查总数，仅前端显式传`needTotal=true`时才执行 下面是 AI 输出的索引优化方案，5 条 DDL 语句全部给出，且每个索引的设计都有明确的优化目标： ![AI 输出的索引优化 SQL 脚本](https://oss.javaguide.cn/ai/coding/glm5.1-cc/index-optimization-sql.png) 从代码 diff 可以直观地看到，AI 在既有代码中进行增量迭代，将`LIKE`模糊查询替换为全文检索，同时保留原有业务逻辑不变： ![AI 在既有代码中完成增量优化](https://oss.javaguide.cn/ai/coding/glm5.1-cc/incremental-code-optimization.png) 对于深分页的问题，AI 结合当前百万级数据量给出了具体的分页阈值——当 offset 超过 1000 时自动切换为延迟关联查询（Deferred Join），浅分页走普通查询，深分页走覆盖索引子查询先定位主键再回表： ```java /** 深分页阈值：offset 超过此值时自动切换为延迟关联查询 */ private static final int DEEP_PAGE_THRESHOLD = 1000; // 深分页（offset > 1000）走延迟关联，浅分页走普通查询 boolean isDeepPage = offset > DEEP_PAGE_THRESHOLD; List orders; if (isDeepPage) { orders = orderMapper.searchOrdersDeepPage(...); } else { orders = orderMapper.searchOrders(...); } ``` AI 在这个方案中结合具体数据量给出了阈值策略。在评审这类方案时，建议关注阈值的合理性——1000 这个值在百万级数据量下是合理的，但如果你的数据量是千万级或十万级，可能需要调整。 ![AI 针对深分页场景基于阈值自动切换查询策略的代码实现](https://oss.javaguide.cn/ai/coding/glm5.1-cc/deep-pagination-threshold-code.png) 全部优化完成后，AI 输出了最终的优化效果总结，涵盖各接口的优化前后对比： ![AI 输出的最终优化效果总结](https://oss.javaguide.cn/ai/coding/glm5.1-cc/optimization-summary.png) ### 优化效果验证 完成改造后再次对接口进行压测，效果如下。接口经过预热后耗时稳定控制在 300ms 以内，**从 18375ms 降至 300ms 以内，性能提升超过 60 倍。** 整个过程中，笔者做的事情就三件：给出问题、评审方案、验收结果。 ![优化后接口耗时降至 300ms 以内](https://oss.javaguide.cn/ai/coding/glm5.1-cc/optimized-api-300ms.png) ## 实战总结 通过两个场景的实战，总结一下 Claude Code + 第三方模型辅助编程的经验和思考。 ### AI 辅助编程能做什么 | 能力维度 | 场景表现 | 说明 | | ---------------- | --------------------------------------------------- | ---------------------------------------- | | 需求到架构的规划 | 场景一：给出需求描述，AI 自主完成技术选型和架构设计 | 适合快速验证构想，但方案仍需人工评审 | | 端到端编码交付 | 场景一：9 个模块 46 个文件自主交付 | 从骨架搭建到业务逻辑，减少重复编码工作量 | | 既有代码增量优化 | 场景二：在百万级数据量的项目中定位慢查询并优化 | 能结合表结构和 SQL 给出分阶段优化方案 | | 数据量感知决策 | 场景二：结合具体数据量给出分页阈值策略 | 基于业务体量做判断，而非通用方案 | ### 实战中需要注意的地方 **做得好的地方**： - **快速验证架构构想**：场景一中，从需求描述到完整的技术方案和架构设计，整个过程不到 10 分钟，对快速验证技术可行性很有帮助 - **多层级方案输出**：慢查询场景中，数据库层面的索引优化和应用层面的 SQL 重构同步推进，覆盖比较全面 - **结合数据量做决策**：场景二中针对百万级数据量给出了深分页阈值，而不是简单套用通用方案 **需要注意的地方**： - **架构方案需要人工评审**：AI 给出的架构设计和数据流看似完整，但细节上可能存在问题。比如场景一中 Arthas HTTP API 的会话模式设计，需要你理解 Arthas 的通信模型才能判断其合理性 - **长链路执行中偶尔断链**：在复杂的持续编码任务中，AI 有时会在后半程遗忘前面的设计约束。建议将复杂任务拆分成明确的阶段，每个阶段独立确认 - **代码风格与工程规范**：生成的代码结构合理，但与个人/团队既有规范的契合度需要磨合。场景一中有部分命名和文件组织就需要手动调整 - **方案选择的权衡**：AI 会给出多个方案，但不会替你做权衡。比如场景二中全文索引 vs ES 的选择、延迟关联 vs 游标分页的取舍，这些需要根据业务场景判断 ### 使用 Claude Code + 第三方模型的一些建议 1. **需求描述要具体**：场景一中完整的需求 prompt 直接决定了架构方案的质量，模糊的需求只会得到模糊的方案 2. **分阶段确认**：复杂项目不要一次性让 AI 从头到尾生成，技术选型 → 架构设计 → 编码实现，每个阶段独立评审 3. **关键决策人工把控**：架构层面的选择（如缓存策略、分页方案）需要根据业务场景判断，AI 无法替你做 4. **善用文档链接**：当需要集成某个现成组件时（如场景一的 Spring AI Alibaba），直接给出文档链接比详细描述需求更高效 ## 写在最后 Claude Code 接入第三方模型后，在 Agent 模式下的上下文理解、任务拆解、代码生成形成了比较完整的工作流。两个场景跑下来，AI 辅助编程确实能缩短”从想法到代码”的时间。 但工具终究只是工具。回顾本文的两个场景： - **场景一中的 JVM 智能诊断 Agent**，需要对 Arthas 的通信模型、JVM 诊断方法论有清晰认知，才能评审 AI 给出的架构方案是否合理——Arthas HTTP API 的会话生命周期管理、Skill 引擎的诊断步骤链设计，这些都需要你来把关。 - **场景二中的慢查询治理**，需要对 MySQL 索引原理、全文检索机制、深分页优化策略有深入理解，才能判断 AI 给出的优化方案是否适用于你的业务场景——比如全文索引在写入频繁的场景下可能带来性能损耗，延迟关联的阈值需要根据实际数据量调整。 AI 编程工具正在改变开发者的工作方式——从”写代码的人”变成”评审代码的人”。用好 AI 的前提，是比 AI 更懂你在做什么。 ## 参考 - GLM-5.1 Coding Plan 上线公告： - Claude Code 安装指南： - cc-switch 模型切换工具： - Spring AI Alibaba 官方文档： - Arthas 官方文档：