把老项目的代码迁移和语言转换交给 AI 之后，我总结了三个它最容易埋雷的地方

去年我们有一坨跑了八年的老服务，技术栈早就不合时宜，老板终于点头让它"换身衣服接着跑"。我图省事，把模块按文件拆开丢给 AI，让它"把这段从旧语言翻译成新的，保持逻辑一致"。前两个模块改完我 diff 了一下，语法干净、命名规范，甚至顺手补了类型注解，我就有点放心了，后面干脆让它批量跑。上线第三周，一个从来没碰过的支付回调接口开始偶发返回错误状态，查了两天才发现是迁移埋的雷。

踩完这一轮，我换了个更稳的姿势：AI 只负责出初稿，每个模块我都要做三件它做不到的事——第一，逐条核"语言惯用法差异"带来的行为变化，而不是只看编译过没过；第二，把老代码依赖的"运行契约"（中间件、环境变量、框架默认行为）单独列一张清单，确认迁过去了；第三，把测试当一等公民跟着迁，且我会故意改坏一处验证测试真的会红。

三个它最容易埋雷的地方，我记下来了。

第一，它把"语法翻译对了"当成"逻辑等价"。旧语言里取一个不存在的 key 默认返回空，新语言里是零值，下游一段"为空就跳过"的判断整反了；还有并发模型不一样，旧的是协程，新的是线程池，一个没加锁的共享计数器在压测时直接算错账。这类坑编译全绿、单测全过，只有真实流量能逼出来。

第二，它只翻译函数体，不带走"运行契约"。老代码靠一个全局中间件在请求头里注入租户 ID，AI 改出来的新模块完全没提这茬，因为那行逻辑不在它看到的文件里。上线后部分请求拿不到租户上下文，静默走了默认分支，直到对账才发现少算了一大片。

第三，它迁过来的测试是"假绿"。AI 生成的用例只覆盖它能看见的分支，对异常路径、超时、空输入几乎不碰，覆盖率面板看着从 40% 涨到 75%，其实是在裸奔。我后来养成一个习惯：迁完必留一个"故意改坏"的自检用例，确认红线真能拦得住，否则那 75% 就是数字安慰。

我现在的结论是，AI 做代码迁移最适合干"体力活"（样板代码、类型对齐、机械转换），但"这段在另一种语言里还等价吗"这件事它判断不了——因为它读不到你整套系统的隐含约定。所以这个我建议先收藏，手边有迁移任务的对着自己老代码先列一张契约清单再动。你觉得到底是让它全量先跑、人工后核更省时间，还是小步切、每步都核更稳？我站后者，但见过有人用前者把半年工期压到六周。