重构的目标是改变代码结构，同时保住已经承诺的行为。任务开始前，把“行为不变”写成能执行的检查。只写“整理一下代码”，Codex 很难判断哪些接口、错误信息和性能特征必须留下。
先保存行为基线
记录当前分支、工作树状态和基础分支。运行现有测试、类型检查和生产构建，保存失败项。已经失败的检查要单独注明，不能等重构结束后再把旧失败算到新改动头上。
测试较少时，先补特征测试。它记录当前公开行为，包括输入输出、异常类型、序列化格式、排序规则或关键副作用。这个测试不替旧实现辩护，它只是给重构画出边界。随后列出允许变化的内部结构和禁止变化的外部契约。
每一步只移动一个边界
把重构切成能独立验证的小步。可以先提取纯函数，再替换调用点，最后删除旧路径。每一步都运行最接近改动的测试，并查看差异里是否混入命名之外的业务变化。公共接口需要调整时，把它拆成单独任务，补迁移说明和调用方修改。
小提交能让审查者看清意图，也便于在某一步失败时撤回。多个 Codex 窗口并行工作时，每个窗口应使用独立分支和工作树，避免一边移动文件，另一边还在修改旧位置。
用完整结果收尾
所有切片完成以后，重新运行完整测试、类型检查和构建。性能敏感路径要用同一输入与环境比较基线，不能只凭代码更短判断更快。再用 Codex /review 按基础分支检查整条差异，重点看遗漏调用点、错误处理、并发状态和无用兼容代码。
GitHub 的分支保护可以要求批准审查、状态检查和对话解决后再合并。仓库是否启用这些规则取决于套餐、仓库类型和管理员设置。没有远端规则时，也应保留同样的本地验收清单。
处理暂时不能一次搬完的接口
跨模块重构常需要过渡层。先保留旧入口，让它调用新实现，并为旧入口补弃用说明。调用方逐个迁移，每迁一处就运行对应测试和类型检查。搜索仓库里的导入、字符串路由、配置键与动态加载位置，静态类型检查不会覆盖所有间接引用。
过渡层要有删除条件。可以记录剩余调用点数量、目标版本和负责提交，确认归零以后再单独删除。新旧实现长期并存会让行为差异越来越难查，临时兼容代码也会被误当成正式接口。
涉及缓存、事务或并发时，再增加一组同输入基线。比较结果、错误和关键副作用，必要时测量响应时间与资源使用。一次测量波动不支持性能结论，环境、输入和运行次数应当保持一致。
一份可靠交付会说明保留了哪些行为，移动了哪些结构，测试怎样证明两者接得上。重构完成只到本地通过时，就明确写本地已验证；推送、合并和上线仍是后续阶段。