AI改造老系统：数据迁移避坑指南
Anthropic 近期披露了一项内部数据：约95%的业务分析查询已由Claude自动处理，整体准确率同样维持在95%左右。
这一数据让许多人首先联想到：Claude的SQL编写能力出色，模型性能令人惊叹。
然而，若仔细解读Anthropic的官方表述，你会发现他们并未强调模型本身有多强大，而是揭示了一个更本质的问题——数据并非软件。
这一判断恰好也解答了另一个普遍困境：为何众多团队在利用AI改造遗留系统时，产出的成果看似完善，一经上线便漏洞百出。
两个场景实则陷入了同一个误区。
代码Agent与数据Agent的风险结构存在本质差异
先来探讨“数据不是软件”的深层原因。
编码本身是一个开放的解空间。一个功能可以通过多种方式实现，只要接口一致、测试通过、运行结果符合预期，代码即可被接受。况且软件世界拥有多重容错机制——语法错误会报错、类型不匹配会报错、单元测试失败会暴露、CI流程会拦截。这些机制虽非万能，但至少构建了层层防护。
数据分析则截然不同。
许多业务问题最终只存在一个正确答案，且仅有一个可靠来源。更棘手的是，往往缺乏一种确定性手段能立即验证答案的正确性。
SQL语句可以语法完全正确，查询顺利执行，返回的数字表面合理。但如果它采用了错误的口径、错误的数据源、过时的字段、遗漏了排除条件，那么答案本身就是错误的。
这类错误通常不会触发任何报错。
举一个典型场景。你向Agent提问：“上个月利润是多少？”
它编写了一段SQL，从收入表减去成本表，跑出一个数值。语法无误、执行正常、结果看起来也很专业。
但如果它使用的是运营口径而非财务口径，如果没有扣掉退款和折扣，如果引用了上月已废弃的成本字段，如果没有排除内部测试订单——这个利润数字就完全不能用于决策。
问题不在SQL本身，而在于SQL背后的业务语义。
Anthropic 将这一点总结得十分精准：分析准确率本质上是上下文与验证的问题，而非代码生成问题。模型会写SQL，只是入场券。
三类失败，指向同一个根源
Anthropic 把他们遇到的大多数不准确回答，归纳为三种主要失败模式。
第一类：概念和实体的歧义。
用户提到“活跃用户”，数据系统中对应的是成百上千张表、字段、派生指标和历史版本。如果Agent不知道哪个字段最能回答问题，就会进行猜测。猜出的结果通常不会显得离谱——它会找一张看似相关的表，写一段看似合理的SQL，给出一个看似可信的答案。这反而更为棘手，因为错误的隐匿性更高。
第二类：数据过期。
企业数据始终在变化。口径会调整，Schema会变动，数据源会迁移。一张表可能被替换，一个字段可能被废弃，一个指标可能变更了计算方式。如果Agent仍依赖旧知识作答，它不一定会报错，但可能返回一个细微却致命的错误答案。
这好比拿着上个月的地铁图，在今天的城市里导航。线路看着完整，站名也像模像样，但某个站已经改名，某段线路已经调整——按图索骥，未必能立即发现问题。
第三类：检索失败。
正确信息可能就在数据模型里，字段注释有注明，文档里也有提及。但搜索空间过于庞大，Agent无法定位。企业数据系统不是一本保存完好的手册，更像一座堆满档案的仓库。答案确实存在于某处，但如果索引不佳、命名混乱、相关文档过多，Agent就很可能拿不到最需要的那一页。
更危险的是，它找不到正确答案时，会找一个相似答案顶替。
这三类失败摆在一起，你会发现它们都不是单纯的SQL生成问题。
历史系统AI改造，掉进的是同一个坑
现在我们来看历史系统。
许多团队在用AI改造老系统时，思路相似：让AI读取一遍旧代码，然后重写。听起来合理——用新架构重写旧代码，性能更好，维护更方便。
但这里隐藏着一个前提：旧代码本身是正确的。
现实世界中，老系统的代码里充满了“历史遗留”——那些因临时bug打的补丁、因已离职同事写的workaround、因旧系统缺陷做的补偿逻辑。这些代码能跑，但并不意味着它们正确。它们只是“在那个时间点、那个上下文里能解决问题”。
如果让AI读取这些代码并生成新代码，AI会将这些历史债务原封不动地继承下来。
而且，与数据Agent的情况完全一样——AI生成的新代码语法不会错，结构可能更优雅，测试也能通过。但业务逻辑可能就是错的。
举个例子。一个老系统里有一段if分支，注释写着“临时修复线上问题，后续需要优化”。五年过去，没人知道那个问题的来龙去脉，也没人敢删除。新工程师让AI重写这个模块，AI读了旧代码，把这段逻辑原封不动地搬到了新系统里。新系统运行飞快，但那个本不该存在的分支，现在变成了新系统的“祖传代码”。
再比如，一个字段名为status，在v1版本表示“用户状态（启用/禁用）”，v2版本改为“审核状态（待审/通过/驳回）”，v3版本又叠加了一层含义。三套逻辑共用一个字段，靠上下文区分。AI读代码时，会按照当前的代码逻辑去理解这个字段，但它不知道这段演变历史。如果它重写时选择了“最简洁”的实现方式，很可能就把那些依赖上下文区分的边界情况丢掉了。
与数据Agent的三类失败相对照：
- 概念歧义 → 老系统里“这个模块到底干什么的”，与新系统里“这个模块应该干什么”，可能根本不是同一回事
- 数据过期 → 旧代码里能跑的逻辑，放到新环境、新数据源里，可能已经失效
- 检索失败 → 文档散落在各处——需求文档、技术方案、群聊记录、离职同事的交接邮件——正确答案存在，但AI无法触及
这些都是同一个根源：AI容易生成“看起来对”的东西，但“看起来对”与“实际上对”之间，隔着整个组织的上下文。
所以，难的不是写，是知道哪个是对的
无论是在构建数据Agent还是进行历史系统AI改造，最容易犯的错误就是：把问题简化为“生成能力够不够强”。
数据团队说：“让Claude直接写SQL查数，不就自助分析了吗？”
开发团队说：“让AI读一遍旧代码直接重写，不就完成改造了吗？”
这两种思路共享同一个幻觉：把上下文问题当成了生成问题。
代码Agent能成功，是因为软件工程经过几十年发展，已经建立了一套完整的验证体系——测试、CI、类型系统、代码审查。这些机制让AI的“猜测”有了纠错空间。
数据分析和老系统改造缺少这样的体系。数据对不对，没有编译期检查；老系统的业务逻辑对不对，没有回归测试覆盖所有历史场景。AI的“猜测”一旦出错，没有第二道防线兜底。
所以Anthropic那句“数据不是软件”，对历史系统改造同样成立。
代码是写出来的，上下文是攒出来的。AI能写好代码，但上下文需要人来搭好。
如果你正在进行数据Agent的构建，不要只盯着SQL生成能力，先问自己：Agent知不知道哪一个数才是公司当前承认的答案？
如果你正在用AI改造老系统，不要只盯着代码生成能力，先问自己：AI知不知道那段看似多余的if分支，当年是谁、为什么写在那里的？
真正难的不是生成。是分辨“哪个是对的”。
而这件事，目前还没有编译器能帮你完成。