原文核对：2026-10-13 · 中文正文 · 英文提示词与演示
场景定位
将旧系统映射到新技术栈，按里程碑推进，并在每次切换前验证一致性。
- 难度
- 高级
- 时间跨度
- 1 小时
适合用于
- 框架、运行时、构建系统或平台约定变化的迁移。
- 需要兼容层、分阶段切换和明确验证的团队。
相关工具
合并前检查高风险迁移、依赖和暴露接口。
Security Best Practices ↗每个迁移里程碑后处理失败 CI。
Gh Fix Ci ↗涉及 ASP.NET Core 应用模型、Program.cs、中间件、测试、性能或升级时采用专用指南。
Aspnet Core ↗起步提示词
英文原文 · 可复制后按实际材料修改
Migrate this codebase from [legacy stack or system] to [target stack or system].
Requirements:
- Start by inventorying the legacy assumptions: routing, data models, auth, configuration, build tooling, tests, deployment, and external contracts.
- Map the old stack to the new one and call out anything that has no direct equivalent.
- Propose an incremental migration plan with compatibility layers or checkpoints instead of one big rewrite.
- Keep behavior unchanged unless the migration explicitly requires a user-visible change.
- Work in milestones and run lint, type-check, and focused tests after each milestone.
- Keep rollback or fallback options visible until the transition is complete.
- If validation fails, fix it before continuing.
- Start by mapping the migration surface and proposing the checkpoint plan.简介
Codex 可规划并执行受控迁移，覆盖路由、数据模型、配置、认证、后台任务、构建、部署、测试，以及语言框架约定。
先盘点旧系统、映射概念，再按检查点交付，适合产品必须持续运行的旧框架替换、运行时移植和渐进技术栈更新。
使用步骤
- 盘点旧包、框架约定、路由、数据访问、认证、配置、构建、测试、部署假设和必须保留的外部契约。
- 将旧概念映射到新栈，指出没有直接对应项的部分。
- 选择兼容层、逐模块移植、抽象分支或逐边界绞杀式替换。
- 尽量保持行为稳定，明确迁移不得不引起的可见变化。
- 每个里程碑后运行证明一致性的最小验证：lint、类型检查、定向测试、契约或冒烟测试，以及新旧路径对照。
- 每个检查点审阅差异和剩余切换风险。
使用 ExecPlans
ExecPlans 记录整体工作、预期终态和每轮验证。复杂迁移可为各子系统建立计划，保存决策和技术栈选择，供以后审阅。
结合目标模式
长时间迁移可设置目标，明确终态、一致性检查、回滚要求和停止条件。
展开英文原文对照
Use Codex to map a legacy system to a new stack, land the move in milestones, and validate parity before each transition.
Introduction
When you are moving from one stack to another, you can leverage Codex to map and execute a controlled migration: routing, data models, configuration, auth, background jobs, build tooling, deployment, tests, or even the language and framework conventions themselves.
Codex is useful here because it can inventory the legacy system, map old concepts to new ones, and land the change in checkpoints instead of one giant rewrite. That matters when you are moving off a legacy framework, porting to a new runtime, or incrementally replacing one stack with another while the product still has to keep working.
How to use
- Start by inventorying the migration surface: legacy packages, framework conventions, routing, data access, auth, configuration, build tooling, tests, deployment assumptions, and any external contracts that must survive the move.
- Ask Codex to map the legacy concepts to the target stack and call out what has no direct match.
- Choose an incremental strategy: compatibility layer, module-by-module port, branch-by-abstraction, or a strangler-style replacement around one boundary at a time.
- Keep behavior stable until the migration itself forces a visible change, and name those exceptions explicitly.
- After each milestone, run the smallest validation that proves parity: lint, type-check, focused tests, contract tests, smoke tests, or a side-by-side check against the legacy path.
- Review the diff and the remaining transition risk after each checkpoint instead of waiting for the full rewrite.
Leverage ExecPlans
In our code modernization cookbook, we introduce ExecPlans: documents that let Codex keep an overview of the cleanup, spell out the intended end state, and log validation after each pass. When you ask Codex to run a complex migration, ask it to create an ExecPlan for each part of the system to make sure every decision and tech stack choice is recorded and can be reviewed later.
Combine with a goal
For long-running migration slices, use a goal to guide Codex through the work. Set the goal with a clear end state, parity checks, rollback expectations, and a stopping condition.