大部分迁移失败，是因为它写出来像一张甘特图，而不是一套策略。好的迁移 Prompt 会逼 AI 先选定模式（strangler fig、shadow 还是双写），在每个阶段都点名回滚方案，给阶段出口定下可度量的标准，并且把”不迁移的部分”当一等公民对待。下面 12 个模板做的就是这件事。复制一个，填好方括号里的变量，你就能得到一份在评审会上站得住脚的计划。
太长不看
- 这些 Prompt 把”我们该迁移了”变成一份切好片、可回滚、带终止条件的计划。
- 每个 Prompt 都强制四件事：共存的接缝、低风险的第一刀、每阶段的回滚、双写时的漂移检查。
- 跑在 100 万 token 上下文的模型上（截至 2026 年 6 月：Claude Opus 4.7、Sonnet 4.6 或 Gemini 3.1 Pro），让它在完整的依赖图上推理，而不是在被切碎的片段上。
- 凡是有官方 codemod 的场景，先跑 codemod（比如 Next.js 的
npx @next/codemod@canary upgrade latest），让 AI 只去规划人工部分，机械活交给工具。
适合哪些人
估算框架 / 数据库迁移的 tech lead、考虑换 auth 提供商的创业者、卡在三年老代码里、要边发功能边搬家的 staff 工程师。
什么时候别用这些 Prompt
全新项目别用——那是新建项目，不是迁移，这些 Prompt 只会跟你对着干。“我们该迁移了”还没论证清楚前别用——产出会去美化一个糟糕决策，而不是质疑它。先想清楚为什么要迁，再用这里的模板去规划怎么迁。
用哪个模型跑
迁移推理的成败，取决于模型能不能一次性把完整依赖图装进脑子里。把代码库切块，恰好会把计划最依赖的跨文件关系切断，所以 100 万 token 上下文在这里是必需品，不是加分项。下面三个旗舰模型截至 2026 年 6 月都已是 100 万 token 上下文。
| 模型 | 上下文 | SWE-bench Verified | 最适合的迁移工作 |
|---|---|---|---|
| Claude Opus 4.7 | 100 万 token | 87.6% | 最深的跨文件重构推理；切换与数据一致性规划 |
| Claude Sonnet 4.6 | 100 万 token | — | 日常主力；在大仓库上做更便宜的多轮扫描（API：每百万 token $3/$15） |
| Gemini 3.1 Pro | 100 万 token | 80.6% | 把整个 monorepo 加文档一次性塞进单个 Prompt（API：每百万 token $2/$12） |
重型规划 Prompt（模板 1、2、4、5）用 Opus 4.7；机械转换（7、10）这种官方 codemod 已经干掉大半的场景，Sonnet 4.6 或 Gemini 3.1 Pro 就够用。要选默认模型可以看ChatGPT、Claude 与 Gemini 对比。
Prompt 结构
下面每个迁移计划 Prompt 都带这六个要素。如果你自己写的 Prompt 产出一团糊，几乎总是少了其中一个：
- 角色：让 AI 扮演谁（Release Captain、SRE、staff 工程师）。
- 上下文：仓库、框架、运行时版本、分支、diff 或失败日志。
- 目标：一个具体可交付物（分阶段计划、风险登记表、切换 checklist）。
- 限制：AI 不能做什么（不许一刀切、不许瞎猜版本号、不许自动落盘改动）。
- 输出格式：编号的阶段、markdown 表格，或 JSON 风险登记表。
- 信号：一条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 大版本框架升级（Next.js Pages Router → App Router，或 14 → 16）
- 数据库引擎切换（MySQL → Postgres）
- Auth 提供商迁移（自研 → Auth0 / Clerk / WorkOS）
- 某个 bounded context 从 monolith 拆成独立服务
- monorepo 工具迁移（lerna → turborepo / nx / pnpm workspaces）
12 个可直接复制的 Prompt 模板
变量写成 [likeThis] 这种形式。发送前把方括号里的内容替换成你真实的系统名。
1. strangler fig 计划
Design a strangler-fig migration from [oldSystem] to [newSystem].
Identify: (1) the seam (router / facade / proxy) where old and new run
side by side, (2) the first slice to migrate — low-risk, high-learning,
(3) the sequence of next slices, (4) the rollback at each slice. Use the
four phases: identify, transform, co-exist, eliminate. Stop at the seam;
do NOT propose a big-bang rewrite.替换： oldSystem、newSystem
2. 数据库双写计划
Plan a dual-write migration from [oldDb] to [newDb]. Phases:
(1) write to both, read from old, (2) read from new but compare with old
to measure drift, (3) read from new only, (4) stop writing to old. For
each phase give: duration target, drift tolerance (as a %), and rollback.
Include a spec for the consistency-check job, and name the columns most
likely to drift (timestamps, JSON blobs, generated IDs).替换： oldDb、newDb
3. Next.js Pages Router → App Router 迁移
Plan an incremental Next.js Pages → App Router migration. Don't propose a
single rewrite. Order: (1) layout + leaf marketing pages, (2) data-fetch
utilities to the RSC pattern, (3) auth-gated pages, (4) dynamic routes
last. For each: which behaviors need a recheck (caching, headers,
redirects, async cookies()/headers()). Scope what the official
@next/codemod can do automatically vs what must be hand-migrated.先跑官方 codemod，让 AI 只规划剩下的人工部分。截至 2026 年 6 月，App Router 迁移工具已通过 npx @next/codemod@canary upgrade latest 自动化，它会升级 Next.js、React、React DOM 并跑内置 codemod（加 --dry 可先预览）。从 Next.js 16.1 起，直接用包管理器的 next upgrade 即可。其中最关键的是异步 API codemod：cookies()、headers()、draftMode() 现在都是异步的，必须 await。详见 Next.js 官方 App Router 迁移指南。
4. 鉴权提供商切换
Plan a migration from [oldAuth] to [newAuth]: (1) user-table mapping
(id, email, hashed pw, sessions, MFA factors), (2) migration mode —
hard cutover vs gradual (verify against old on sign-in, then sync to new),
(3) session and refresh-token preservation, (4) rollback to old auth,
(5) user comms if a password reset or re-consent is needed. Flag every
place a token is read, minted, or verified.替换： oldAuth、newAuth
5. monolith 抽出服务
Extract [boundedContext] from a monolith into its own service. Plan:
(1) identify the schema tables owned by this context, (2) build an API in
the monolith for outside callers, (3) mirror to the new service,
(4) move callers, (5) remove monolith code last. For each step: data
ownership, transactional boundaries that break across the network, and
rollback. Call out any cross-context foreign key or join.替换： boundedContext，例如 billing / search / notifications
6. ORM 迁移
Migrate from [oldOrm] to [newOrm]. Don't rewrite all models at once.
Plan: (1) read-only models first, (2) new writes use the new ORM, old
writes keep the old, (3) convert by domain, not file order. List the 5
most-used queries likely to behave differently between the two ORMs
(N+1 defaults, lazy vs eager loading, transaction semantics, raw SQL
escape hatches).替换： oldOrm、newOrm，例如 sequelize → prisma
7. JS → TS 迁移
Plan a JS → TS migration: (1) add a tsconfig with allowJs: true,
(2) migrate files leaf-first (utilities before app code), (3) add real
per-file types — don't blanket-cast to any, (4) turn on strict
incrementally, one directory at a time. Don't propose a single rewrite.
Include a CI gate that fails the build on any new `any`.8. 前端状态库切换
Migrate from [oldState] to [newState]. Phases: (1) co-exist — new store
used only for new features, (2) move read-heavy slices, (3) move
write-heavy slices, (4) remove old. For each: how to keep the two stores
in sync during co-existence, and how to roll back per slice.替换： oldState、newState，例如 redux → zustand
9. 云厂商 lift-and-shift
Plan a migration of [service] from [oldCloud] to [newCloud]. Phases:
(1) replicate infra in the new cloud with IaC, (2) mirror traffic at 1%
to compare, (3) cut DNS over in a low-traffic window, (4) decommission
old. List the parity checks: p99 latency, monthly cost, data residency,
secrets, and IAM role mapping.替换： service、oldCloud、newCloud
10. monorepo 工具迁移
Migrate from [oldTool] to [newTool] (e.g., lerna → turborepo). Phases:
(1) run side by side — CI runs both, (2) migrate package by package,
(3) move root scripts last, (4) remove old. For each package: dependency
graph audit, cache keys, and build-script differences.替换： oldTool、newTool
11. 任意迁移的风险登记表
For this migration plan, build a risk register: each row = (risk,
probability L/M/H, impact L/M/H, owner, mitigation). Top risks must
include: data loss, downtime, performance regression, a security gap
during the transition, and stakeholder fatigue. Don't list trivial risks.
Output as a markdown table.12. 迁移终止条件
Define KILL CRITERIA for this migration before we start: under what
conditions do we revert and call the migration unsuccessful? Examples:
(1) a phase takes more than 2x its budget, (2) drift exceeds 0.1% during
dual-write, (3) error rate stays more than +5% above baseline for 24h.
Name who has the authority to call it.容易踩的坑
- 一刀切迁移。 线上一条 bug 就要全量回滚。strangler fig 是每切一刀就交付一份价值。
- 阶段之间没回滚。 走得越深，越退不回来。
- 双写没漂移检查。 两份存储悄悄分叉，最后是客户先发现。
- 最难的部分先迁。 团队被熬干，还没有一个能拿出来说的早期赢局。
- 没有终止条件。 沉没成本让一个注定失败的迁移一直撑下去，远过它本该被叫停的点。
- 关键数据跳过 shadow 阶段。 没拿到新系统和旧系统一致的证据就盲目相信它。
- 迁移和新功能挤在同一个 sprint。 两边都做不完。
如何把结果推得更远
- 默认 strangler fig，除非有证据证明非重写不可。
- 第一刀切低风险、高学习：营销页、只读模型、低流量接口。
- 把双写理解为”两边都写 再加上 一个漂移检查 job”，绝不只是”两边都写”。
- 阶段出口写成可度量的标准，不是”看着可以”。
- 回滚代码和迁移代码放进同一个 PR，让回退只需一键。
- 把计划当活文档，每个阶段后更新。
- 过度沟通。干系人会把”没消息”理解成”卡住了”。
FAQ
- 一次迁移要多久？: 5 万行级别的应用，按切片规划 2–4 个季度。只有范围真的很窄（单个 bounded context 或一次框架版本号升级）才更快。
- 迁移期间要停掉功能开发吗？: 别停。产品一停就掉用户。把迁移切成功能仍能照常上线的切片。
- 什么时候 rewrite 比 strangler fig 更合适？: 几乎从不。诚实的场景是：系统已事实弃用、没有活跃用户、且能接受停服。
- AI 能直接写迁移代码吗？: 机械转换可以（多数框架升级有 codemod 兜底）；切换决策和数据一致性逻辑不行，这些留给人来做。
- 计划本身用哪个 AI 模型最好？: 用 100 万 token 上下文的，让它看到完整依赖图。截至 2026 年 6 月，最难的跨文件推理用 Claude Opus 4.7，更便宜的多轮扫描用 Sonnet 4.6 或 Gemini 3.1 Pro。
- 最常见的单一失败模式是什么？: 没有阶段出口、没有终止条件，于是沉没成本把一个注定失败的迁移推着往前走。这两样都要在第一阶段前定好。