记一次用 AI 重构三年前老 Spring Boot 服务的真实经历:爽是真爽,账单也是真疼

记一次用 AI 重构三年前老 Spring Boot 服务的真实经历:爽是真爽,账单也是真疼

先说背景。我们组有个三年前的老 Spring Boot 服务,代码写得比较野------没有统一异常处理、SQL 里硬编码、配置散落在各个 yml 里、单测覆盖率不到 10%。最近业务要加新功能,组长说"趁这次把代码规范一下"。我接了这个活,本来以为要熬两周,结果这周刚好用上了新出的 GPT-6 Sol 和 Claude Opus 5.5,整个过程跟大家聊聊。

为什么选这周动手?因为 AI 工具刚好降价了

不是我赶时髦,是真的算过账。这周 OpenAI 发了 GPT-6 Sol,API 价格直接砍半,2 美金一百万输入 token;Anthropic 同一天上了 Claude Opus 5.5,context window 拉到 1M token。我之前一直用固定订阅的 Copilot 补全,但那种"让 AI 读整个老项目然后帮你重构"的活,固定订阅根本不够用------context 一长就截断,改了东文件忘了西文件。

这次我直接开了按量计费,想着老项目代码量也就几万行,1M context 应该够。

第一阶段:让 AI 读代码,比我自己读快十倍

老项目最头疼的不是写新代码,是搞清楚"这堆老代码到底在干嘛"。我把整个服务的 Java 文件打包喂给 Claude Opus 5.5,让它先输出一份架构梳理:哪些 Controller 暴露了什么接口、Service 层有哪些核心逻辑、DAO 层用了哪些表、配置项都在哪。

十分钟后它给我一份结构化的文档,连"这个定时任务在凌晨 3 点跑、依赖一个已经下线的第三方接口"这种细节都挖出来了。我自己读这些代码,至少得两三天。这一步是真的爽,省下来的时间我直接去跟产品对新需求了。

第二阶段:让 AI 生成重构代码,坑开始出现了

架构梳理完,开始动手。第一步是加统一异常处理。我让 AI 把所有 Controller 里 try-catch 重复的地方抽出来,改成全局异常处理器。

AI 生成的代码看起来很标准------@RestControllerAdvice、@ExceptionHandler、统一返回体。但我一跑测试,发现两个问题:

第一,老项目里有些接口直接返回 void,有些返回 ResponseEntity,AI 统一改成了返回 Result<T>,导致前端对接的几个老接口返回结构变了,直接报错。

第二,有个老接口里 catch 了 Exception 之后还做了日志埋点,AI 重构的时候把埋点逻辑丢了,我差点没发现------这要是上线,数据看板就空了。

这两个坑让我意识到一件事:AI 写的代码"看起来对"和"真的能上线"之间,隔着一个老项目的历史包袱。 它不知道哪个接口是前端在用的、哪个埋点是数据团队盯着的、哪个异常分支是三年前为了救火临时加的。

第三阶段:账单来了,我人傻了

重构到一半,我看了一眼 API 用量,人麻了。

因为我用的是 Claude Opus 5.5 按量计费,每次让它读整个项目上下文、生成重构代码、再跑测试反馈,一轮下来输入 token 就是几十万。三天下来,光这个服务的重构,API 费用干到了 120 多美金。

我想起这周看到的新闻------GitHub Copilot 转按量计费之后,有个开发者月账单从 30 美金涨到 1400 美金。我当时还笑他是不是不会用,现在轮到自己了。

后来我调整了策略:架构梳理和全局设计用贵的长上下文模型(Opus 5.5),具体的代码生成和单测补全用便宜的 GPT-6 Sol(毕竟刚降价),日常补全还是用固定订阅的 Copilot。这么一拆分,后面几天的成本直接降了三分之二。

最后结果:一周干完,两周的活,但踩了三个坑

最终这个老服务重构完了:统一异常处理加上了、SQL 里的硬编码抽到了配置中心、单测覆盖率从不到 10% 拉到了 60%。新功能也顺利加进去了。

但整个过程我踩了三个坑,记下来给大家参考:

第一,老项目重构别让 AI 全自动跑。它不知道历史包袱,你得把大任务拆成小步骤,每步人来 review。我一开始图省事让 agent 自动跑了一轮,结果它把一个已经废弃但还被某个老定时任务引用的接口删了,我回滚了半天才找回来。

第二,按量计费一定要设预算告警。我是看到账单才反应过来的,后来在 OpenAI 和 Anthropic 后台都设了月度预算上限,超过 50 美金自动停。

第三,AI 生成的代码一定要跑全量回归测试。单测过了不代表线上没问题,前端对接、数据埋点、老接口兼容性,这些 AI 帮你测不了。

写在最后

这周 GPT-6 Sol 降价、Claude Opus 5.5 上长上下文,对我们这种天天跟代码打交道的人来说确实是好事。但我最大的感受是:AI 工具越强,你越得知道怎么"管"它------什么时候用贵模型、什么时候用便宜模型、哪些活交给它、哪些活必须自己盯着。

它是个能力很强但不懂你业务的初级同事,你得会分配活、会 review、会算成本。不然它写代码是快,账单教你做人也快。

重构完了,线上跑了两天没出问题,我去喝杯咖啡。

相关推荐
yunwei372 小时前
eBPF 示例教程:使用 XDP 捕获 TCP 信息
linux·后端·性能优化
用户8356290780512 小时前
Python 设置 Excel 单元格边框与样式
后端·python
大勇前进2 小时前
大模型的上下文窗口越大越好吗?长文本模型暗藏哪些缺陷
后端
Bazingga2 小时前
RAG进阶-分块Chunking从原理到企业级实践
后端
回家路上绕了弯2 小时前
智能体编排平台中,工作流与 Agent 如何分工?
后端·ai编程
leeyi2 小时前
erlang_pay 为 Erlang 补上支付这块拼图:一个库接支付宝、微信、Stripe
后端·erlang·支付宝
GoGeekBaird2 小时前
手机远控 DeepSeek Harness?四款 DSH Desktop 测评
后端·github
PC2005_cloud2 小时前
RabbitMQ 在 Spring Boot 中的完整使用
前端·后端
IT枫斗者枫哥2 小时前
Spring Boot导入返回409,为什么第一行还是入库了?
java·spring boot·后端