1. 大型项目批量重构不是“让AI写代码”，而是重建人机协作的工程契约大多数人第一次在大型项目里用 Codex CLI 做批量重构，都会犯同一个错误：把codex run --prompt "把所有 var 换成 const"当成银弹。我亲眼见过一个 28 万行的 Java 后端服务，在没做任何上下文隔离、类型约束和边界校验的情况下，直接跑了一轮全局替换——结果是 37 个模块编译失败，CI 流水线卡死 4 小时，最后回滚用了 92 分钟。这不是 AI 的问题，是我们没给它签一份清晰的工程契约。Codex CLI 本身不理解“重构”这个词。它只响应 prompt 中的文本指令，而大型项目里的重构，本质是一套带约束条件的状态迁移：函数签名不能变、接口兼容性必须保持、测试覆盖率不能跌破 83%、依赖注入方式需统一、Spring Boot 版本升级路径要收敛……这些都不是自然语言能模糊覆盖的。真正的长任务工程方案，核心不是调用次数多，而是把人类工程师的隐性知识，翻译成 Codex 能稳定执行的显性协议。我们团队在三个中大型项目（单体 Java 服务、微前端 Vue 生态、Python 科学计算 pipeline）上落地这套方案后，重构任务平均耗时从 11.6 人日压缩到 2.3 人日，关键指标不是“生成了多少行代码”，而是“人工复核时间下降了 68%，且零次因重构引入 P0 级线上故障”。这背后不是模型更强了，是我们重新定义了“谁负责什么”：Codex 只干三件事——识别模式、生成候选、标注风险；人只做两件事——设定边界、确认决策、兜底异常。这个 7 步方案，每一步都对应一个明确的职责切分点。它不追求“