代码迁移 Prompt：从 X 语言迁移到 Y 语言

用法

粘贴源语言代码，指定目标语言。适合单文件/单模块迁移，大项目请分批处理。

Prompt

你是一个精通多种编程语言的资深工程师。请把以下代码从 {{源语言}} 迁移到 {{目标语言}}。

## 源代码

{{粘贴代码}}

## 迁移要求

1. **逻辑等价**：保留原始逻辑，不要"优化"或"改进"——除非目标语言必须如此
2. **惯用写法**：用目标语言的惯用风格，不要写出"翻译腔"代码
3. **类型系统**：如果目标语言有类型系统（TypeScript/Rust/Go），补全类型标注
4. **错误处理**：适配目标语言的错误处理方式（try-catch / Result / panic）
5. **标准库**：用目标语言的标准库替代源语言的依赖

## 输出格式

### 迁移后代码
```{{目标语言}}
// 迁移后的代码
```

### 差异说明
| 源语言写法 | 目标语言写法 | 原因 |
|---|---|---|

### 需手动调整
- {{列出 AI 无法自动迁移、需要人工处理的点}}

### 依赖映射
| 源语言依赖 | 目标语言替代 | 说明 |
|---|---|---|

### 注意事项
- {{迁移后可能的行为差异}}
- {{需要更新的测试}}

常见迁移场景

• Python → Go（API 服务重写）
• JavaScript → TypeScript（加类型）
• Java → Kotlin（Android 开发）
• PHP → Python（后端迁移）
• Vue 2 → Vue 3（Composition API）
• REST API → GraphQL

迁移最容易翻车的地方

语言迁移真正的坑不在语法，而在运行时语义差异，这也是"需手动调整"那一栏的价值所在：

• Python → Go：Python 的 dict 有序、Go 的 map 无序。依赖遍历顺序的代码迁过去会出诡异 bug。
• JS → TS：JS 里 == 的隐式类型转换，TS 不会替你修语义，只是加了类型标注——"1" == 1 的逻辑得人工审。
• 同步 → 异步：PHP/Python 同步代码迁到 Node/Go，IO 全变异步，调用链得重排，AI 常漏掉某处忘了 await。
• 整数除法：Python3 / 是浮点除、// 才是整除；迁到 Go/Java 的 / 对整数是整除——边界处算错不报错。

所以这条 prompt 强制要求"差异说明表"和"需手动调整"两栏——别指望 AI 一次迁干净，把它不确定的地方逼出来人工复核。迁移后必须跑目标语言的测试，语法过编译 ≠ 行为等价。

为什么有效

• 先要影响分析再要代码：直接让 AI 翻译，它会「看起来对但边界丢了」；先列行为差异能把这些提前暴露。
• 指定目标语言的惯用法：不加约束时 AI 会把源语言的写法直译过去（比如把 Python 的 list comprehension 写成一坨 Java stream），可读性崩坏。
• 要求给迁移后的验证方式：没有验证步骤的迁移等于没迁移，这一步是防止「编译通过但行为变了」的唯一保险。

进阶（自动化）

大仓迁移请按目录切片跑，不要一次喂整个仓库：

# 按目录分批迁移，每批单独 commit，便于二分定位回归
for d in src/api src/service src/dao; do
  ai-migrate "$d" > "/tmp/$(basename $d).patch" && git apply "/tmp/$(basename $d).patch" \
    && pnpm test "$d" && git commit -am "migrate: $d"
done

每批跑测试再 commit，出问题能二分定位；这也是大规模重构 Playbook 里的同一条纪律。

反例（AI 默认会写的烂版本）

默认输出：把 JS 的 async/await 直译成 Python 的 asyncio，但顺手丢了 try/except，异常直接冒泡把服务打挂。

加了 prompt 之后：先列出「源语言的哪些语义在目标语言没有直接对应（错误传播、并发模型、数值精度）」，再给迁移代码，并补一组对照测试证明行为一致。

什么时候用 / 别用

适合用：同一种业务逻辑换语言或换框架重写（JS → Python、Vue 2 → Vue 3、Express → Fastify）；有存量测试可以当验收基准的迁移；纯机械的 API 重命名与模块拆分。

不适合用：

• 并发模型不同的迁移（如 Node 单线程事件循环 → Go goroutine / Python asyncio）。这不是语法翻译问题，是执行模型问题，AI 直译出来的代码能跑但语义已经变了。
• 数值精度与序列化约定不同的场景（JS Number → Python Decimal、时间与时区处理）。
• 没有任何测试、也没有验收标准的存量模块。此时 AI 会把现状（含 bug）原样翻译成另一种语言，bug 一并迁移，且更难被发现。

验收判据

1. 先列「语义不对应清单」再动手：错误传播机制、并发模型、数值精度、字符编码、时间与时区——这五类在语言间几乎没有一一对应，必须在写代码之前显式列出并逐条给方案。
2. 对照测试（golden test）：迁移前后用同一组输入跑，比对输出。这是唯一能证明「行为等价」而非「看起来对」的手段。
3. 分批提交：每批跑测试再 commit——出问题能二分定位，与 大型重构 Playbook 同一条纪律。
4. 人工过一遍「AI 说不用改」的地方：迁移里最危险的往往不是改错，而是悄悄丢掉了某个副作用（日志、埋点、缓存失效、事务边界）。

更新说明

• 2026-10-17：补充「什么时候用 / 别用」与「验收判据」两节。本篇的差异化价值在验收，不在模板——迁移类 prompt 最常见的失败是「翻译完了但语义变了」。

延伸阅读

• 安全重构 Prompt · 测试生成 Prompt — 迁移后补测试验证等价性
• 大型重构的 AI Agent 工作流 — 大项目分批迁移的流程