无文档项目的快速摸底接手一个没有任何文档的老项目往往是开发者最头疼的开局。Codex 在这类场景里能扮演一个「快速翻译官」的角色。你把项目根目录丢给它让它生成一份项目介绍文档它能在几分钟内梳理出模块划分、依赖关系和核心入口。这比人工逐行啃代码快得多尤其是面对几千个文件时Codex 的批量阅读能力可以迅速帮你建立全局视图。不过这里有个关键前提Codex 的「理解」本质上是基于代码结构和命名推断的它并不真正「懂」业务。比如一个名为OrderProcessService的类它能猜出和订单处理相关但如果业务里藏着「订单状态机有七种特殊流转规则」这种潜规则Codex 大概率是看不出来的。所以它的摸底价值在于快速建立技术地图而非还原业务真相。实际使用中建议让 Codex 生成文档后再针对性地追问几个核心流程的调用链。比如「从用户下单到支付完成的完整调用路径是什么」通过多轮追问把平面文档立体化。这个过程中你会发现Codex 对显式调用链路方法 A 调方法 B的追踪还算准确但一旦涉及事件驱动、反射注入这类隐式机制就容易断链或误判。古早语言迁移的准确度Codex 在遗留系统改造中最吸睛的能力莫过于把 FORTRAN、COBOL 这类「上古语言」往 Python、Java 等现代语言迁移。从实际案例来看它对语法层面的转换确实有一套。比如 FORTRAN 里的数组操作Codex 能比较准确地映射到 NumPy 的向量化计算循环结构、条件判断这类基础控制流转换成功率也相当高。但迁移的坑往往不在语法而在运行时的语义差异。举个例子FORTRAN 的数组索引默认从 1 开始而 Python 从 0 开始Codex 有时会漏掉这种边界偏移的修正。再比如老语言里常见的固定格式文件读写迁移后如果直接套用现代语言的流式处理可能会因为字节对齐问题导致数据解析错误。我的建议是把 Codex 的迁移结果当作「初稿」而非「终稿」。对于核心算法模块务必准备一组原始语言的输入输出用例在迁移后的代码上跑一遍对照验证。Codex 擅长的是消除「机械性翻译」的工作量但那些依赖特定语言运行时特性的细节仍然需要人工具备双语能力来兜底。复杂业务逻辑的还原瓶颈如果说语法迁移是 Codex 的舒适区那么复杂业务逻辑的还原就是它的天花板。老代码里那些长达上千行的「面条方法」往往糅杂了业务规则、技术债和临时补丁Codex 在重构时很容易「肢解过度」或「理解偏题」。一个典型场景是某段代码里有段看似冗余的循环实际上是三年前为了规避某个特定并发问题而加的补丁。Codex 在优化时可能会把它简化掉因为单从代码静态分析看这段循环确实没有显式作用。这种「隐性知识」的丢失是 AI 改造遗留系统时最危险的地方。应对这个问题核心策略是控制单次改造的范围。不要一次性让 Codex 重构整个模块而是先让它把大段代码拆成小块每块附上原始注释和修改理由人工确认业务语义没有漂移后再进入下一步。这个过程看似慢实则比事后排查 Bug 要快得多。人工校验的关键节点既然 Codex 的理解存在边界那么在整个改造流程中设置人工校验节点就尤为关键。根据实践以下四个环节必须介入人工审查第一是依赖变更审查。Codex 在迁移过程中可能会引入新的第三方库或者把原有依赖替换成它认为更「现代」的方案。这时候需要检查新依赖的许可证是否合规版本兼容性如何团队是否有维护经验第二是接口契约校验。老系统的接口往往和多个下游系统耦合Codex 重构后即使单元测试通过也可能因为字段顺序、默认值、编码格式等细节变化导致联调失败。建议用原始接口的抓包数据作为基准对重构后的接口做回归比对。第三是性能基线对比。老代码虽然丑但可能经过长期调优在某些特定场景下有稳定的性能表现。Codex 生成的「优雅代码」反而可能因为过度抽象或不当的数据结构选择导致性能退化。改造前后跑一遍压测把关键接口的延迟和吞吐量数据记录下来对比是避免「越重构越慢」的必要手段。第四是安全扫描。遗留代码里可能埋着硬编码密钥、SQL 拼接、路径遍历等历史遗留漏洞Codex 在迁移时未必能识别这些风险甚至可能把漏洞原样复制到新代码里。接入静态安全扫描工具做全量检查是上线前不可省略的一步。用 AGENTS.md 提升历史学习效率Codex 的AGENTS.md机制是提升其对项目历史学习效率的一大利器。简单来说这是一个放在项目根目录的记忆文件你可以把项目的架构约定、编码规范、常见陷阱、甚至「这段代码为什么不能动」的背景信息写进去。Codex 在处理任务前会自动读取这个文件相当于给它提前灌输了项目上下文。实际使用中建议在改造初期就维护好这个文件。比如记录「支付模块的幂等性校验在PaymentService第 147 行不要和订单模块的重复提交逻辑混淆」或者「库存扣减采用乐观锁对应数据库字段是version」。这些信息对 Codex 的后续操作有显著的纠偏作用。更进一步可以把改造过程中发现的 Codex 常见误判模式也沉淀到AGENTS.md里形成「人机协同」的迭代优化。比如发现它经常混淆两个相似命名的服务类就明确标注两者的职责边界。随着文件内容的丰富Codex 对项目历史的「学习曲线」会明显缩短后续迭代的准确率也会随之提升。说到底Codex 在遗留系统改造中的角色更像是一个「高效但偶尔冒失的助手」。它能大幅压缩机械性工作的时间但关键决策和质量兜底仍然需要开发者保持清醒的判断。把它的能力边界摸清楚在合适的环节放手、在危险的环节收紧才是让 AI 真正服务于老代码维护的正确姿势。