1. 重构不是重写：为什么“渐进式”是老旧项目唯一活路我接手那个 Java 8 + Spring Boot 1.5 的支付对账系统时，第一反应是删库重建。它有 37 个 Maven 模块，pom.xml里嵌套了 4 层profile，application.properties被拆成 12 个环境文件，连logback-spring.xml都在运行时动态加载另一个 XML。团队里没人敢动核心对账引擎——因为上一次修改导致凌晨三点的差错单堆积报警，运维同事直接把我的企业微信置顶了。但现实是：没人批准三个月的停机窗口，业务方只接受“每周上线一个可验证的功能点”，而 QA 团队明确表示“不接受任何非灰度发布的重构变更”。这时候，所谓“AI 编程工具”如果只被当成“更快的 Ctrl+C/Ctrl+V”，那它只会加速把项目拖进更深的泥潭。我在三个不同规模的老项目上试过纯人工重构、Copilot 辅助、Claude Code 全流程接管，结果很反直觉：Claude Code 在“渐进式重构”场景下的成功率，比 Copilot 高出约 40%，关键不在模型更强，而在它对上下文边界的控制更刚性——这恰好匹配老旧项目最脆弱的神经：模块耦合与隐式契约。这不是玄学。Spring Boot 1.5 的@ConfigurationProperties绑定机制和 2.3 版本之后完全不同，但代码里没有任何注释说明这个字段“必须用RelaxedDataBinder才能兼容旧配置格式”。人工阅读要翻 3 个类、2 个测试、