周五下午四点，一个 Java 8 + Spring Boot 3 老项目报错。日志指向三年前写下的工具类方法，注释只有几行，调用链绕了好几层。没人想在周末前手动翻完这段历史包袱，于是团队把代码分别交给 Cursor 3、Claude Code 和 GitHub Copilot。
这类场景很适合检验 AI 编程助手。不是写一个新页面，也不是补一个标准 API，而是在一堆旧依赖、旧约定、旧补丁里改一行看似简单的代码。
最后，代码本身没有最先失控。先动摇的是团队对工具的信任。
Cursor 3 很快，也很敢改
Cursor 3 给答案的速度最快。
它在几秒内给出重构方案：修掉报错方法，顺手整理工具类，还把部分写法迁到更新的响应式风格。看 diff 的第一眼，代码确实清爽了不少。变量名更规整，分支也更少，像是有人终于愿意替这个老模块打扫卫生。
问题出在提交之后。CI 红了。
原因不在报错方法本身，而在另一个微服务。那个微服务还依赖老模块的接口契约，Cursor 3 改动时把局部问题当成了全局优化机会。它理解了代码表面的“脏”，却没摸清这段脏代码为什么还能活到今天。
这不是 Cursor 单独的问题。老项目里的很多写法，看起来像坏味道，实际可能是为了绕开某个旧版本依赖、线上兼容逻辑，或者历史接口承诺。AI 编程助手如果只按“更现代”“更优雅”去改，很容易把技术债当成可清理垃圾。
《麻省理工科技评论》曾提到，GitHub Copilot 已支持接入 Anthropic、谷歌和 OpenAI 的多个模型，开发者可以在 VS Code 中选择 Claude 3.5，后续还会支持 Gemini 1.5 Pro。模型选择变多了，但在私有代码库里，真正难的仍是读懂意图：哪些代码该改，哪些代码只能碰一下。
Claude Code 像在做代码考古
同一段代码交给 Claude Code，节奏完全不同。
它没有马上动手改结构，而是先写了一段分析，指出工具类里几个历史遗留的逻辑漏洞，也解释了为什么当年的开发者可能会保留那种冗余实现。这个过程有点慢，但对维护老项目的人来说，慢不一定是坏事。
它最后给出的修复很克制：只改报错相关的一行，保留原来的异常处理结构。测试通过，也没有牵出新的副作用。
这类表现容易让人产生依赖感。Claude Code 更像是在问：这段代码为什么长成这样？而不是直接判断：这段代码应该被改成什么样。
但代价也明显。按原测试记录，这次简单修复消耗了约 15 万 Context Tokens，单次会话成本超过 0.5 美元。对偶尔排查一次问题的团队来说，这笔钱不夸张；对一个每天都在查旧 Bug、补旧接口、回滚旧逻辑的团队来说，账单会很快变成管理问题。
它像请来一位很认真、很贵的顾问。顾问说得对，也真的帮你避坑。但你不会希望每次换灯泡，都先让他检查一遍整栋楼。
Copilot 的无聊，反而让人安心
GitHub Copilot 在这次试用里最不“惊艳”。
它没有大段解释，也没有主动重构模块，只给出几个相近的代码片段。开发者还得自己挑、自己拼、自己跑测试。过程不快，甚至有点笨。
但最后合进去的代码最稳。
这种稳来自边界感。Copilot 没有试图接管整个修复流程，也没有把一个局部 Bug 升级成架构整理。对新项目来说，这可能显得不够聪明；对老项目来说，少做一步有时就是减少一次事故。
GitHub Copilot 早在 2021 年推出。按《麻省理工科技评论》的说法，它已经拥有超过 100 万付费用户。这个体量说明，很多开发者真正需要的未必是一个“替我重写项目”的工具，而是一个在编辑器旁边稳定补全、提醒、提供参考的人。
在老代码里，这种保守有价值。
老项目怕的不是慢，是误判
AI 编程助手在规范的新项目里很容易显得强大。目录清楚，测试完整，接口边界明确，生成代码的风险也更可控。
老项目完全不同。文档可能过期，测试覆盖不够，某些异常处理看起来多余，其实是线上踩坑后的补丁。一个工具如果分不清“历史遗留问题”和“业务兼容要求”，就会把修复做成破坏。
Limboy 在一篇关于 AI 辅助编程的文章里提到，他曾在一个基于 Tauri 2 的 Mac App 项目中使用 GitHub Copilot，粗略估计大约一半代码由 AI 辅助生成；他也写到，早期试用 Cursor 时觉得它“存在感太强”。这个感受放到老项目里会被放大：存在感越强，越需要团队有能力判断它什么时候越界。
所以，选 AI 编程助手时，不能只看谁补全更快、谁上下文窗口更大、谁基准测试分数更好。老项目真正考验的是不确定性管理：工具能不能承认自己不知道，能不能少改一点，能不能把风险暴露给开发者，而不是包装成一个漂亮的重构提交。
Cursor 3 的问题是太想把事情做好；Claude Code 的问题是成本和上下文消耗；Copilot 的问题是慢，也不够主动。
如果项目测试薄、文档旧、接口关系复杂，最安全的选择往往不是最聪明的那个，而是最少自作主张的那个。先让 AI 做建议，再让人决定边界。对老项目来说，这个顺序不能反过来。