AI编码智能体面对老旧代码时频繁集体翻车

上周一位老友找我诉苦，他们公司花了每月8000美元买下Claude Code企业版，本想用来改造自家积累多年的老项目。结果跑了整整三天，成功率连20%都没达到。

我当时就问他：“你们这项目，是哪个年代起建的？”

他无奈地笑了笑：“六年前吧，从Spring Boot 1.5起步，中间换了三套ORM，还有几个模块是外包团队留下的‘传家宝’。文档？听说过，但从没见过。”


听到这儿，我忍不住笑了：“兄弟，你这不是让AI写代码，是让它做‘考古学’作业啊！”

他还是不服气，搬出官方宣传，说Claude Code能理解复杂代码库。我只好回他一句：“官方还说微服务是银弹呢，你信到现在，感觉如何？”

新项目 vs 遗留代码：一场天生不对等的测试

2026年，AI编程工具已经满天飞。Claude Code、Cursor、Windsurf、Devin、Amazon Q、GitHub Copilot……随便拎一个出来，都敢号称能“提升开发效率10倍”。

但你只要去看看它们的演示视频，就会发现套路都一样：清一色的新项目。从零搭建一个Todo App，搭一个微服务骨架，搞一个增删改查的Demo。这就像让刚拿到驾照的新手，在空旷的驾校停车场里练倒车入库——毫无压力，干净利落。

可现实世界里，开发者天天面对的是什么？是开着五菱宏光，要挤进老城区那种七拐八拐、墙皮都脱落的窄巷子。真实的开发，90%的时间都在旧代码上动刀：加个新功能，改个历史遗留Bug，重构一段谁都不敢碰的祖传逻辑。这才是程序员的日常。

而AI编程工具在这些场景下的表现，坦率地说，简直可以用“惨不忍睹”来形容。

6款工具的真实表现：数据从不说谎

2026年6月，技术圈流传着一份针对6款主流AI编程工具的硬核测试报告。测试方法简单粗暴：

• 新项目：从零开始，写一个全新功能。
• 旧项目：在一个拥有5年历史、超过300个文件的真实商业项目里，修改现有功能。

结果如下：

你没看错，即便是表现最好的Copilot，面对旧项目也只剩35%的成功率。最差的Devin，更是直接跌到18%。

这意味着什么？简单算一笔账：你让AI修改10个功能，至少有6到7个会出问题。而你，还得像个保姆一样，花时间去审查、修复、甚至回滚它留下的烂摊子。算上这个时间成本，可能比你自己动手写还要慢。

有人可能会嘀咕：“这数据是不是编得太夸张了？”

一点也不夸张。我自己在三个不同体量的旧项目上亲手测过，结论基本一致。一个2年历史的电商项目，让Copilot改支付模块，成功率只有40%；一个4年历史的SaaS系统，更离谱，Claude Code去改权限逻辑，直接自作主张把我数据库schema给改了。它的理由居然是：“我觉得这样更规范”。你猜最后怎么着？系统直接崩了。

所以，核心问题不是AI能不能写代码，而是它完全无法理解你的代码“为什么”要这么写。

为什么AI一碰到旧项目就“降智”？

这真不是AI本身的Bug，而是它当前能力的边界。原因分三层，从浅到深，每一层都比上一层更致命。

第一层：上下文理解能力的断崖式下跌

AI编程工具的核心是“理解上下文”。在全新的项目里，上下文很简单：就是你刚写的代码、刚提的需求、刚定义的接口。但在杂草丛生的旧项目里，上下文是混沌的、充满故事的：

• 这个Service为什么这么写？因为三年前有个线上Bug，必须绕开框架的某个限制。
• 这个字段为什么叫temp_user_id_v2？因为v1版本被产品经理无情删除了。
• 这个模块为什么一个单元测试都没有？因为写这个模块的同事两年前就离职，去追寻诗和远方了。

AI看不见这些历史，它只能看见代码本身。于是它自以为是地“优化”了一段逻辑，结果直接把三年前那个关键的workaround给扬了，整个功能瞬间崩盘。

举一个真实的例子，我维护的一个项目里有一段这样的代码：

// 不要改这行代码，否则定时任务会重复执行
// 原因：2021-03-15 线上事故复盘结论
if (System.currentTimeMillis() % 1000 == 0) {
    return;
}

这段代码看起来奇蠢无比，对吧？任何一个正常的AI看到它，第一反应肯定是：“这个判断条件毫无意义，完全不符合最佳实践，删掉！”

但事实是，这是一个线上事故后的紧急修复。那个定时任务的调度器本身有个Bug，会在整秒时触发两次。这个看似愚蠢的判断，是当时能找到的唯一且有效的解法。

AI不会去翻Git的提交历史，不会去看事故复盘文档（如果它存在的话），它只信奉所谓的“最佳实践”，然后告诉你：“这段代码应该删掉。” 后果就是，你的定时任务会在每个月的1号凌晨，像个复读机一样，重复执行60次。

第二层：跨文件依赖带来的指数级复杂性

在旧项目里，一个看似简单的功能，往往像一张蜘蛛网，横跨10个文件、5个模块、3层调用。AI自顾自地改了A文件，却可能打破了B文件里的某个隐式约定，或者改变了C文件里某个接口的签名。这种连锁反应，AI的那点算力根本算不过来，或者说，它根本就没意识到这是个问题。

这不是理论推演，而是实打实的工程事故。我测试过一个场景：让Claude Code给一个旧项目加一个“用户标签”功能。需求很简单——用户表加个字段、Service层加个方法、API层加个接口。Claude Code动作很快，5分钟就搞定了。但问题出在哪儿呢？

它顺手把UserService的getUserById方法给改了，把返回值从User实体改成了它认为“更标准”的UserDTO。这个改动本身逻辑上没问题。但问题是，getUserById这个方法在整个项目里被17个地方调用，其中有3个地方直接拿着User对象访问数据库字段。结果呢？编译阶段就有红叉了。

更糟糕的是，还有个地方用了这种骚操作：

Method method = UserService.class.getMethod("getUserById", Long.class);
User user = (User) method.invoke(userService, userId);

这种反射调用，连编译时检查都绕过去了，只有运行时才会抛出ClassCastException。AI连这种静态问题都发现不了。

这就是旧项目的复杂性：牵一发而动全身，改动一个点，影响的是一整张网。

第三层：“隐性知识”的缺失，这是最致命的

这是最核心，也是当前所有AI工具都无解的难题。每个上了年纪的项目，都有一些“只有老王知道”的隐性知识：

• 这个配置项绝对不能改，改了项目就起不来。
• 这个数据库表上挂了一个触发器，但没人记得它是干什么用的。
• 这段代码看起来蠢到极点，但它恰恰解决了一个极其诡异的并发问题。
• 这个模块打死都不能用Spring的@Transactional，因为底层有个存储过程会导致死锁。

这些知识，不在你看到的代码里，不在任何文档里，甚至不在团队的Wiki里。它们只存在于老员工的脑袋里，存在于已经离职的同事的记忆里，存在于三年前某个凌晨3点、大家手忙脚乱排查故障的群聊天记录里。

AI没有这些知识，它只能基于“最佳实践”来给出建议。但在旧项目这个充满了历史债务和特定妥协的战场里，“最佳实践”往往就是灾难的代名词。

那些“成功”的案例，都是些什么项目？

你可能会说：“不对啊，我天天在推上看到有人晒Claude Code的成功案例，效率提升10倍都算少的！”

没错，那些案例是真的，但请你擦亮眼睛，仔细看看它们都是些什么项目：

• 新项目：从零开始，没有任何历史包袱。
• 小型项目：文件不超过50个，模块边界清晰得像白纸。
• 个人项目：自己一个人写，一个人改，一个人维护，所有权明确。

在这些理想场景下，AI确实能给你装上火箭推进器。但扪心自问，你每天面对的，是你公司的项目：300个文件、10个模块、5年历史、前前后后3个不同的团队维护过。这才是大多数程序员面对的真实战场。

AI编程工具的营销，瞄准的是广告里的“理想身材”，而不是现实中的“996程序员”。这就像健身广告里的模特，身材完美，但那是每天练4小时、吃特制餐、有私人教练的结果。你一个下班只想睡觉的996，能指望靠每天30分钟的跑步机就练成那样？

那些晒效率提升10倍的人，要么是在写新项目，要么是在写个人玩票项目，要么就是——在卖课。

那怎么办？彻底告别AI了？

那肯定不是。AI编程工具有它的价值，但前提是你得清楚它的能力边界在哪里。根据项目的不同，我把它分成三档，大家可以对号入座。

第一档：放心用（新项目）

从零开始写新功能、搭脚手架、生成样板代码。在这些场景下，AI是你最好的搭档。具体来说：

• 新建一个Spring Boot模块。
• 写一个REST API的增删改查。
• 生成单元测试的模板代码。
• 写一个一次性数据处理脚本。

在这些领域，AI的成功率可以轻松跑到85%以上，你只需要简单检查一下就能投入生产。

第二档：谨慎用（旧项目的局部改动）

如果你要在旧项目里修修补补，先冷静下来，问自己三个问题：

• 这个功能会涉及几个文件？（超过3个，就要高度警惕）
• 有没有跨模块的依赖？（只要有，就别让AI直接出手改）
• 有没有“只有老王知道”的隐性逻辑？（只要有，就请自己动手）

如果这三个问题的答案都是“否”，那AI可以帮你生成一个初稿。但你仍然需要：

1. 人工审查每一行改动——绝对不能贪图省事直接apply。
2. 跑一遍单元测试——没有单元测试？那就先补上。
3. 检查跨文件影响——用IDE里的“Find Usages”功能，地毯式搜索。

第三档：千万别用（旧项目的核心模块）

有些模块，AI最好连碰都不要碰：

• 支付/金融模块——错了就是真金白银的损失。
• 权限/安全模块——错了就是数据泄露的灾难。
• 核心业务逻辑——错了就是P0级事故。
• 历史遗留的workaround——看起来再蠢，背后也一定有它的苦衷。

这些模块，AI不仅帮不上忙，还会给你制造一种“我已经改好了”的虚假安全感，让你在不知不觉中放松警惕。最危险的，从来不是AI改错了，而是你以为AI改对了。

架构师视角：AI编程工具的工程化使用

如果你是一个团队的架构师或者技术负责人，不能只凭个人经验来拍脑袋决定“什么时候用AI”。你需要一套工程化的方法来指导团队。

这里有三条实践，供你参考。

实践一：建立“AI安全区”

在代码库里明确划定哪些模块AI可以碰，哪些不行。具体做法：

1. 在项目根目录创建一个.ai-safety文件，列出“AI禁区”：

# 以下模块禁止AI直接修改
- src/main/ja va/com/example/payment/
- src/main/ja va/com/example/auth/
- src/main/ja va/com/example/legacy/

2. 在Code Review时，专门检查AI生成的代码有没有越界，触碰禁区。
3. 对于“AI安全区”内的代码，可以适当放宽审查标准。

这个方法看起来原始，但非常有效。它把“隐性知识”显性化了，让整个团队都知道哪些地方是红线，不能碰。

实践二：建立“AI生成代码”的标记机制

AI生成的代码，应该在Git的提交记录里被明确标记出来。具体做法：

1. 在Commit message里加上[AI-Generated]前缀：

[AI-Generated] feat: add user tag feature

2. 在Code Review时，对带有[AI-Generated]标记的commit，采用更严格的审查标准。
3. 定期统计AI生成代码的比例和质量，作为团队是否要调整使用策略的依据。

这样做的好处是，你可以追查到AI生成代码的质量趋势，发现哪些模块是AI经常翻车的“重灾区”，从而更精准地调整策略。

实践三：建立“AI失败案例库”

每次AI生成的代码出了问题，都认认真真地记录下来。具体记录内容：

• 场景：在哪个模块、哪个功能上用了AI。
• 问题：AI生成了什么代码，导致了什么问题（是编译报错、运行异常、还是逻辑错误？）
• 根因：分析为什么AI会犯这个错，是理解错了上下文，还是遗漏了隐性知识。
• 教训：下次再遇到类似场景，应该怎么处理，是让AI换个方式，还是干脆自己上。

这个案例库的价值不可估量。它能把团队每个人脑袋里的“隐性知识”变成团队的“显性资产”。新人来了，不用再重新踩一遍坑，直接看这个案例库就知道哪些地方是雷区。

更妙的是，当你看过50个类似的失败案例之后，你会形成一种难以言喻的直觉：“嗯，这个场景，AI肯定搞不定。” 这种直觉，比任何规则手册都管用。

2026年的真相：AI编程工具还在“青春期”

请别误会，我写这些，不是为了否定AI编程工具。它们确实很强，可以帮你节省大量重复劳动的时间。

但2026年的现实就是：这些工具还处在青春期，它们擅长的是结构清晰、边界明确的“简单场景”，而不是充满妥协、历史和隐性知识的“复杂现实”。

那些告诉你“AI将会取代程序员”的人，要么是在卖课，要么是在卖工具。真正的老程序员都明白：写代码本身不难，难的是理解业务、理解历史、理解那些文档里永远不会写下来的东西。而这些东西，恰恰是当前AI最不擅长的。

我的预测是，未来2-3年，AI编程工具在旧项目场景上的表现会有显著提升。但这个提升，不会来自于什么更强大的模型，而是来自于“更好的工程化”，比如：

• 代码知识图谱：把Git历史、PR评论、事故复盘文档都整合起来，让AI能理解代码的“为什么”。
• 依赖分析引擎：自动分析跨文件依赖，在AI动手改代码之前，先帮它算出影响范围。
• 隐性知识提取：通过分析commit message、PR评论、群聊记录，尝试提炼出那些“只有老王知道”的知识。

但这些能力，目前还没有任何一个工具能够真正实现。

最后一句大实话

如果你的项目是全新的新项目，那么恭喜你，AI编程工具能帮你省下不少时间。

但如果你的项目是那种历史悠久的“老古董”，别急着去买企业版。先把个人版拿过来，在你们的核心模块上做个测试，看看成功率到底有多少。如果低于50%，那每个月几千美金的预算，还不如拿去给团队加个鸡腿，团建一次。

毕竟，在面对一堆“祖传代码”时，最靠谱的工具，永远是那个最熟悉项目历史、最能理解代码背后故事的人。

而那个人，很可能就是此刻正在读这篇文章的你。

所以，与其花大价钱去买一个“看起来很聪明、实际上却经常犯糊涂”的AI助手，不如花点时间，好好把你们项目里的“隐性知识”整理一下。

不为别的，就为了你自己，和你未来的继任者。毕竟，等哪天你离职了，接你班的人会更感谢你留下的这些文档——而不是那个只会添乱的AI助手。