在很长一段时间里，我们都把系统迁移当成一种“必要但痛苦的事情”。
不是不会做，而是不想做。
一、为什么我们又一次走上了迁移这条路
事情的起点很普通：
- 老系统运行多年，依赖版本逐渐老化
- 新成员上手成本越来越高，涉及多语言、多框架
- 每一次改动，都要反复确认“会不会影响旧逻辑”，维护成本高
最典型的状态是：系统还能跑，但没人敢大改。
继续堆功能，技术债只会越来越重；推倒重来，又意味着一次不可控的工程风险。
最终我们达成共识：
迁移不是为了追新技术，而是为了让系统重新“可维护”。
二、迁移真正消耗人的地方，从来不是技术难度
真正开始拆解任务后，我们发现一个很现实的问题：迁移里 80% 的工作，几乎没有技术含量。
包括但不限于：
- 接口层的批量改写
- DTO / Model 的结构调整
- 错误处理、日志规范的统一
- 配置文件、命名风格的机械性修改
这些事情的特点非常一致：
- 规则明确
- 重复度极高
- 极其消耗专注力
- 非常容易出低级错误
而真正需要工程师思考的部分——架构边界、业务语义、数据一致性，反而只占很小一部分。
问题在于：人被大量“脏活累活”拖住了。
三、传统迁移方式，为什么总是效率低
在使用新的工具之前，我们几乎把能试的方法都试过了：
- 手写迁移脚本
- 正则 + 搜索替换
- 临时小工具拼规则
它们并非没用，但局限非常明显：
- 只能处理“格式”，很难处理“语义”
- 一旦规则复杂，维护成本直线上升
- 跨语言、跨框架时几乎全部失效
迁移做到后期，经常出现一种状态：人不是在写代码，而是在对付代码。
四、我们是如何把 Codex 引入迁移流程的
我们并不是抱着“让 AI 自动完成迁移”的期待去用 Codex 的。
目标非常明确：让它接管那些规则明确、重复度高、不值得人反复消耗精力的工作。
在实际使用前，我们先做了清晰的边界划分。
适合交给 Codex 的事情
- 接口层 / DTO 的批量迁移
- 代码结构、命名风格的统一
- 框架层面的固定模式改写
- 明确规则下的重构工作
- 接口业务逻辑梳理
坚决不交给 Codex 的事情
- 架构设计与拆分决策
- 性能、安全关键路径
- 任何“改错一次代价很大”的代码
一句话总结：让它做执行者，而不是决策者。
五、Codex 在迁移中是如何发挥作用的
典型流程大致是：
- 提供旧代码
- 明确目标框架或规范
- 清晰描述迁移规则
- 明确哪些部分“禁止改动”
在这种前提下，接口层迁移、结构性重构、重复代码替换，大约有 70%–80% 的结果可以直接使用。
剩下的工作变成了：人工 Review、小范围调整、补充测试。
迁移的工作性质发生了明显变化：从“连续高强度编码”，变成了“规则制定 + 校验”。
六、迁移实战演示（节选）
老项目和新项目放置同一目录，这样做可以方便 Codex 读取项目代码：
tree -L 1 -d
.
├── each-oms-main：老项目
├── each_hwd：新项目
├── eachfans-main：老项目
└── starsback-manager-master：老项目
撰写一份 README，用于介绍项目、划分 Codex 边界、定义规则，然后与 Codex 进行多轮对话迭代，直至某个功能迁移完成。
七、效率变化，比想象中更明显
我们没有做特别夸张的数据统计，但体感非常一致：
- 编码时间显著下降
- Review 更聚焦在“逻辑正确性”而不是格式
- 人的疲劳感明显降低
最重要的一点是：迁移不再让人抗拒。
八、Codex 能做的，其实远不止迁移
在迁移之外，它同样适合：
- 代码规范与风格的长期对齐
- 批量重构与技术债清理
- 新老系统之间的临时适配层
- 把工程经验固化成可重复执行的流程
从这个角度看，它更像是工程团队经验的放大器，而不是替代者。
九、当迁移不再痛苦，技术演进才真正开始
回头看这次迁移，最大的变化并不是“快了多少”，而是心理负担明显降低了。
当迁移不再意味着长期加班、大规模返工、不可控风险，技术团队才真正有勇气去持续演进系统。
最后，用一句很工程师的话来总结：
迁移本身不是问题，让人长期做低价值重复劳动，才是问题。