大部分迁移失败是因为它们是甘特图，不是策略。好的迁移 Prompt 必须强制分阶段（strangler？shadow？双写？），在每个阶段都定义回滚，并且把”不迁移的部分”当一等公民对待。
适合哪些场景
估算框架 / DB 迁移的 tech lead、考虑换 auth 提供商的创业者、卡在三年老代码里要边发功能边搬家的 staff 工程师。
什么时候不建议这样写 Prompt
别用来规划全新项目——那是新项目不是迁移。“是否要迁移”还没充分论证前别用——产出会美化糟糕决策。
Prompt 结构公式
每个迁移计划 Prompt 都要带这六个要素：
- 角色：让 AI 扮演谁（Release Captain / QA Lead / SRE / staff 工程师）。
- 上下文：仓库 / 框架 / 运行时 / 分支 / diff / 失败日志。
- 目标：一个具体可交付物——checklist、计划、测试文件、review 笔记、根因、ticket 列表。
- 限制：AI 不能做什么（别自动修、别静默改写、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON schema、unified diff、可直接运行的代码。
- 示例 / 信号：1-2 条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 大版本框架升级（Next 12 → 14）
- DB 引擎切换（MySQL → Postgres）
- Auth 提供商切换（自研 → Auth0 / Clerk）
- 某个 bounded context 从 monolith 拆出来
- monorepo 工具迁移（lerna → turbo / nx / pnpm）
12 个可直接复制的 Prompt 模板
1. strangler 模式计划
Design a strangler-pattern migration from `{oldSystem}` to `{newSystem}`. Identify (1) the seam (router / facade / proxy) where old and new live side by side, (2) the first slice to migrate (low-risk, high-learning), (3) sequence of next slices, (4) rollback at each slice. Stop at the seam — don't propose big-bang.可替换变量： oldSystem, newSystem
2. DB 双写计划
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 for drift, (3) Read from new only, (4) Stop writing to old. For each phase: duration target, drift tolerance, rollback. Include consistency-check job spec.可替换变量： oldDb, newDb
3. Next.js Pages → App Router
Plan an incremental Next.js Pages → App Router migration. Don't propose a single rewrite. Order: (1) Convert layout + leaf marketing pages, (2) Move data-fetch utilities to RSC pattern, (3) Migrate auth-gated pages, (4) Migrate dynamic routes last. For each: which features need recheck (caching, headers, redirects).4. 鉴权提供商切换
Plan a migration from `{oldAuth}` to `{newAuth}`: (1) User-table mapping (id, email, hashed pw, sessions), (2) Migration mode: hard cutover vs gradual (sign-in with old, sync to new), (3) Session preservation, (4) Rollback to old auth, (5) Comms to users (if email needed). Flag every place tokens are read.可替换变量： oldAuth, newAuth
5. monolith 抽服务
Extract `{boundedContext}` from a monolith into its own service. Plan: (1) Identify schema rows owned by this context, (2) Build an API in the monolith for outside callers, (3) Mirror to new service, (4) Move callers, (5) Remove monolith code last. For each: data ownership, transactional boundaries, rollback.可替换变量： 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 new ORM, old writes keep old, (3) Convert by domain, not file order. List the 5 most-used queries that are likely to behave differently between ORMs.可替换变量： oldOrm, newOrm，例如 sequelize → prisma
7. JS → TS
Plan a JS → TS migration: (1) Add tsconfig with `allowJs: true`, (2) Migrate files leaf-first (utilities), (3) Add per-file types, don't make everything `any`, (4) Turn on `strict` incrementally per directory. Don't propose a single rewrite. Include CI gates for "no new `any`".8. 前端状态库切换
Migrate from `{oldState}` to `{newState}`. Phases: (1) Co-exist, new state used only for new features, (2) Move read-heavy slices, (3) Move write-heavy slices, (4) Remove old. For each: how to keep them in sync, 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 new cloud with IaC, (2) Mirror traffic at 1% to compare, (3) Cut over DNS at low-traffic window, (4) Decommission old. List parity checks: latency, costs, data residency, secrets, IAM 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, 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 should include: data loss, downtime, performance regression, security gap during transition, stakeholder fatigue. Don't list trivial risks.12. 终止条件
Define KILL CRITERIA for this migration before starting: under what conditions do we revert and consider the migration unsuccessful? Examples: (1) Phase X takes > 2x budget, (2) Drift > 0.1% in dual-write, (3) Error rate sustained > +5%. Document who has authority to call it.容易踩的坑
- 一刀切迁移——线上一条 bug 就要全回滚。
- 阶段之间没回滚——走得越深越难回头。
- 双写没漂移检查——悄悄分叉。
- 最难的部分先迁——团队疲惫、没有早期赢局。
- 没有终止条件——沉没成本让失败的迁移继续撑。
- 关键数据没 shadow 阶段——盲目相信新系统。
- 迁移和新功能同一个 sprint——两边都做不完。
优化技巧
- 默认 strangler，除非被证明不可行。
- 第一刀切低风险、高学习——营销页 / 只读模型 / 低流量接口。
- 双写要配漂移检查 job，不只是”两边都写”。
- 阶段出口要可度量，不是”看着可以”。
- 回滚代码和迁移代码同一个 PR 写完。
- 迁移计划是活文档，每个阶段后更新。
- 高频沟通——干系人把”没消息”理解为”出问题”。
FAQ
- 迁移要多久？: 5 万行级别应用：2-4 个季度的切片。范围更窄才更快。
- 迁移期间要停掉功能开发吗？: 别——停了产品就掉用户。把迁移切成功能仍能上线的切片。
- 什么时候 rewrite 比 strangler 更合适？: 几乎从不。除非老系统已经事实弃用且能停服。
- AI 能写迁移代码吗？: 样板转换可以；切换决策和数据一致性代码必须人类。
- 怎么知道迁完了？: 事先定义出口准则。常见：14 天内线上读不再走旧系统。
- 迁移最常见的失败模式？: 没阶段出口、没终止条件、沉没成本继续。