# 一个老开发者的AI工具使用心得
## 前言
去年开始组里推AI辅助开发，我从最开始的抵触到现在离不开，前后心态变化挺大的。今天不聊那些虚的，就说说我在实际工作中是怎么用这些AI工具的，以及踩过的一些坑。
## 我的工作环境
先交代一下背景，避免有人说“你的情况跟我不一样”。我目前用的开发机是ThinkPad P15v，32GB内存，Intel i7-12700H处理器，显卡是RTX A2000。公司项目主要是Java后端配合Vue前端，偶尔用Python写点脚本处理数据。技术栈比较传统，Spring Boot、MySQL、Redis、ElasticSearch这些。
## 日常问题查询：豆包
我日常查技术问题用得最多的是豆包。上周遇到一个Spring Security的问题，OAuth2资源服务器配置一直报错，错误信息是”Unable to resolve configuration property”。我把错误堆栈贴给豆包，它很快定位到是application.yml里缺少issuer-uri配置，然后给了我一个完整的配置示例。
这个场景下豆包有几个优点：响应速度快，解释问题清晰，对国内技术社区的关注点把握得比较准。我问它”Java 21的新特性有没有企业级应用案例”，它能提到一些国内公司的实践，而不仅仅是翻译官方文档。
但豆包在代码场景的表现就比较一般。让它帮我写一个基于Redisson的分布式锁工具类，生成的代码逻辑对，但实现方式偏保守，用的是官方标准写法，没有做什么性能优化。如果我需要那种很“邪门”的优化技巧，就得换工具。
## 代码编写：DeepSeek
DeepSeek是我写代码的主力工具。上个月重构一个老订单模块，要把同步调用改成异步处理。我让DeepSeek帮我设计整体架构，它给了我一套基于CompletableFuture的方案，还主动考虑了线程池隔离、超时控制、异常处理这些我本来打算后面再补的东西。
具体到代码质量，DeepSeek生成的代码有几个特点：注释写得很详细，基本不用我再补；异常处理比较完善；变量命名清晰。不过它有个问题，有时候生成的代码会过于“教科书”，一个简单的CRUD方法能写出一堆校验逻辑，代码行数比预期多不少。我后来养成习惯，会在prompt里加一句“代码简洁优先，非必要不加校验”。
## 实际工作场景举例
**场景一：排查一个奇怪的NPE**
线上有个接口偶尔会抛NullPointerException，日志显示是在UserService的getUserInfo方法里。但看代码，那个地方明明已经做了null判断。我把相关代码和日志贴给DeepSeek，它看了几秒就指出问题：多线程场景下，user对象在判断和使用的间隙被其他线程置为null了。
这个分析让我醍醐灌顶。确实，这个方法是在一个Spring的@Async方法里被调用的，而user对象是从一个成员变量里取出来的。代码逻辑是这样的：先判断user不为null，然后调用user.getName()。问题在于，判断和使用之间没有任何同步保护，如果有另一个线程修改了user变量，就会出现NPE。
我后来用ThreadLocal解决了这个问题：每个线程存自己的user对象，避免竞态。这个问题前后折腾了一周，DeepSeek几分钟就点破了，效率差很多。
**场景二：写一个数据同步脚本**
需要从MongoDB同步数据到MySQL，数据量大概200万条。我先让豆包帮我解释MongoDB的聚合管道语法，确认了一些我不熟悉的操作符用法。然后让DeepSeek帮我写同步脚本的核心逻辑，它给我提供了一个基于MongoDB Change Streams的方案，支持增量同步，不需要全量跑。
实际跑下来，脚本单线程处理速度大概是每秒3000条记录。我发现瓶颈主要在MySQL的批量插入上，就让DeepSeek帮我优化。它建议用rewriteBatchedStatements=true参数，配合PreparedStatement批量提交。改完这一版，单线程速度提升到每秒8000条左右。
后来我又改成多线程并行处理，8个线程同时跑，速度提到每秒12000条。200万数据大概跑了3分钟，比之前用定时任务跑一晚上快太多了。
**场景三：设计一个接口防刷方案**
“双十一”前产品提了一个需求，说接口被刷得太厉害，想做个限流。我把现有系统的架构和流量特征描述了一下：峰值QPS大概2万，后端服务有5台机器，目前用的是单机限流。
DeepSeek给了两套方案：
**方案一是基于Lua脚本的分布式限流**，把限流逻辑放在Redis里做。具体实现是用Redis的计数器配合滑动窗口算法，每个用户或IP有一个独立的key，过期时间设为1分钟。每当一个请求过来，先获取当前窗口内的请求数，如果超过阈值就拒绝。这套方案的优点是实现简单，对现有代码零侵入，只需要在网关层统一加一个拦截器就行。缺点是精度稍差，窗口边界可能会有请求“突刺”。
**方案二是基于Sentinel的限流**，在Spring Boot里引入Sentinel的依赖，然后给需要限流的接口加上@SentinelResource注解。它支持多种流控效果：直接拒绝、排队等待、冷启动等。Sentinel还支持按来源限流，可以针对不同用户群体设置不同阈值。这套方案的优点是精度高，配置灵活，还能看到详细的监控数据。缺点是需要引入新依赖，对代码有一定侵入性，而且学习曲线比方案一陡峭一些。
我问了两个关键问题：方案一在高并发下会不会有精度问题？方案二对业务代码侵入大不大？它分别做了解释：
关于方案一的精度问题，它说在极端情况下（比如Redis集群的主从切换间隙）可能会有少量请求被漏计数，但这个概率非常低，对于普通业务场景完全可以接受。如果对精度要求极高，可以考虑用Redis的RedLock或者Redisson的信号量，但实现复杂度会上升很多。
关于方案二对代码的侵入性，它说最新版本的Sentinel支持注解方式，对业务方法的改动很小，只需要在接口方法上加一个注解就行。如果用的是Spring Cloud Gateway或者Zuul，也有对应的过滤器可以统一配置，不需要每个接口都手动加。
最后我选的是Lua+Redis方案，因为实现简单，对现有代码零侵入，只需要加一个网关层的拦截器，而且“双十一”时间紧迫，没那么多时间改代码。
实际效果：当天系统扛住了预估流量的1.8倍，限流组件正常生效，拦截了大概15%的异常流量，没有误伤正常用户。峰值期间Redis的CPU使用率大概在40%左右，完全在可接受范围内。事后复盘，如果当时用Sentinel方案，可能能拦截更多恶意流量，但实现周期要长一倍不止，可能赶不上“双十一”上线。
## 个人使用感受和建议
用了一年半下来，我的体会是：AI工具确实能提升效率，但别把它当成银弹。它更适合做这些事：
– 帮你快速入门一个不熟悉的技术领域
– 帮你debug，尤其是那些你想不到的可能性
– 帮你写一些重复性的代码，让你专注在业务逻辑上
不太适合的场景也有：复杂架构设计需要你自己拿主意，AI给的方案听起来很有道理但可能忽略了你独有的约束条件，还有一些边界情况它确实考虑不到。
我的建议是，把AI当作一个经验丰富的同事，有问题就问，但最终决策自己做。它最大的价值不是给你一个完美答案，而是帮你打开思路，减少你查文档的时间。至于怎么用好，还是得自己在实践中摸索。