前言
上周接手了一个老项目的Spring Boot升级，从2.x迁到3.x。打开项目一看，847个Java文件，javax要改jakarta，JUnit 4要升JUnit 5，十几个配置文件要调整。我盯着屏幕发了一会呆，心里盘算着：这活儿三个人干至少三周。
然后我想起之前在 大模型（01gpt.cn） 上体验过的Claude Code，说是能自动拆分大型工程任务、调度子Agent分模块执行。抱着“死马当活马医”的心态，我决定让它试一把。
结果四个小时之后，我看着全部通过的单测和工整的变更报告，第一次觉得“程序员可能会被AI替代”这句话好像也不是完全没道理。
传统重构 vs 自动编排
先说说以前我们怎么干这种活的。技术负责人花半天时间拆任务，分成二三十个小块，Excel里拉一张依赖关系表，然后分配给三四个人。每个人在自己的分支上改，改完提PR，合并的时候总能撞出几个冲突。一个邮件线程来来回回讨论“这个公共类到底该归谁改”，转眼又是一天。
Claude Code的搞法完全不同。它先花了30秒把整个项目扫了一遍，然后自动生成了一张任务树。这张树长这样：
根任务：Spring Boot 2.x → 3.x 升级
├── [模块1] 订单服务 (31文件)
│ ├── P0 - OrderBaseService.java （高风险，被18个类继承）
│ └── P1 - 其余30个文件 （可完全并行）
├── [模块2] 支付服务 (28文件)
│ ├── P0 - PaymentBaseTest.java （高风险基类）
│ └── P1 - 其余27个文件
...（12个模块，总共247个子任务）
最让我服气的是它自动识别出了“高风险文件”——那些被大量继承的基类、被全局引用的工具类。一个经验丰富的架构师来做这件事也得花一两个小时，它用了30秒。
怎么拆的
整个流程大致分四步：
第一步，扫描。 它把项目里的所有文件都读了一遍，不只看文件名，还解析了AST，搞清楚每个类的继承关系、每个文件的依赖引用。
第二步，分类。 把文件按模块分组，模块之间没依赖的可以完全并行，模块内部再按风险等级排序。高风险的文件（被超过5个类继承或引用）排在前面执行，而且必须人工确认。
第三步，生成规则。 每个子Agent接到任务时会收到一份详细的执行规范，不是简单的“把这个文件改一下”，而是具体到“第12行的import要把javax改成jakarta，第34行的@Test要从JUnit4的包换成JUnit5的包，其他逻辑不许动”。
第四步，执行+监控。 200多个子Agent同时跑起来，主Agent盯着每个任务的执行结果。一旦发现两个Agent改了同一个文件的同一行，立刻标记冲突。大部分冲突它能自己解决，实在搞不定的才会弹出来问我。
效果怎么样
整个重构的执行过程我截了个时间线：
14:02 任务树生成完毕：247个子任务，12个模块
14:03 P0高风险任务开始执行（5个文件，串行，需要我点确认）
14:03 我逐一看完确认，没问题，放行
14:04 P1任务启动，243个文件完全并行
14:05 第一批128个完成
14:06 第二批115个完成
14:06 全量完成，开始全局验证
14:08 检测到2处冲突：
- UserServiceTest和AdminServiceTest改了同一个工具方法
- ProductTest的@Mock注解迁移不正确
14:08 主Agent自动修了1处，另1处弹给我确认
14:09 我点了确认
14:10 迁移完成，变更报告生成
八分钟。然后我花了一个小时Review高风险文件的改动、跑了一遍完整的回归测试。从“开始动手”到“能提交代码”，总共不到一个半小时。
对比一下传统方式的预估：3个人搞3周，也就是45人天。现在是1个人搞1.5小时，不算前期准备的话，折合0.18人天。效率提升了大概250倍。
当然这是理想情况——任务规则明确、机械重复、不需要业务判断。如果换成“把这个模块的业务逻辑重新设计一下”，那还是得人来做。
踩过的坑
第一个坑：基类确认不能偷懒。
P0高风险文件必须逐一看。我一开始想着“AI应该都对的”，差点一键通过，后来发现有一个基类的修改会影响18个子类的方法签名。还好看了一眼，不然后面18个子类的测试全得挂。
第二个坑：依赖版本对齐。
POM文件里的Spring Boot版本从2.7升到3.2之后，有些第三方依赖还没适配。Claude Code能改代码，但不了解公司私有仓库里的内部依赖兼容性。这个只能靠人确认。
第三个坑：测试覆盖率不足的项目慎用。
如果原项目单测覆盖率不到30%，改完你根本不知道有没有引入新Bug。建议先花时间补测试，再考虑全自动重构。
心得
这件事给我的最大触动不是“AI有多强”，而是“程序员的哪些能力真正不可替代”。
八分钟自动改完847个文件，这的确很震撼。但真正重要的决策——升级方案的确认、高风险改动的审核、最终的责任归属——还是落在了我头上。Claude Code像一支执行力拉满的工程团队，但它仍然需要一个知道“该往哪个方向走”的人来做技术决策。
我突然觉得，未来程序员的核心竞争力可能不再是“会写什么框架”“熟记哪个API”，而是——
- 知道什么值得做，什么不值得做
- 能在AI给出的多个方案中选出最好的一版
- 能Review出AI没考虑到的边界场景
这些事，短期内AI还做不了。
结语
这次经历之后，我把Claude Code的自动编排列入了我们团队的标准工具链。下一场技术升级我已经想好了：配置文件迁移、日志框架统一、命名规范对齐——这些规则明确、边界清晰的活，全部交给它。省下来的时间，我想好好看看那本一直没翻开的《领域驱动设计》。毕竟，AI暂时还不会替我思考业务该怎么建模。
如果你也在做类似的技术升级，建议先找一个规则明确、文件数量适中的模块试水，跑通了再看全项目。先建立信任，再逐步放权——这和带新人其实差不多。唯一的区别是，这个“新人”不吃不喝不抱怨，就是偶尔会在你眼皮底下犯点小错。
