一次典型的多文件修改实验为了摸清 Codex 在多文件联动修改中的真实表现我设计了一个贴近日常开发的需求在电商订单模块中新增批量取消订单功能。这个需求天然涉及五个文件的联动调整——Controller 层新增接口入口、Service 层实现批量业务逻辑、Mapper 层扩展数据库操作、实体类补充状态枚举以及一个独立的工具类用于参数校验。需求描述我刻意保持口语化在订单模块加个批量取消的功能前端传订单 ID 列表和取消原因后端校验权限、更新状态、记日志返回成功和失败的明细。 没有给出任何文件路径提示想看看 Codex 能否自主识别出需要改动的范围。任务拆解文件识别的第一道关卡Codex 的响应速度比预期快。大约十秒后它给出了任务规划识别到OrderController.java需要新增 POST 接口推断OrderService.java需添加批量处理方法定位OrderMapper.java需扩展批量更新 SQL发现OrderStatus.java枚举缺少 CANCELLED 状态额外创建BatchCancelValidator.java做参数校验这个识别结果让我有点意外——它多识别了一个文件。原项目中并不存在BatchCancelValidator.javaCodex 主动提议新建。这种过度规划在后续实验中反复出现大约 30% 的情况下它会建议创建并非必需的辅助类比如独立的常量类或配置类。开发者需要判断这是锦上添花还是过度设计。更隐蔽的问题在于文件遗漏。当项目存在同名或相似命名的历史遗留文件时Codex 有概率选中错误的基类。我在另一次实验中发现它修改了一个名为OrderServiceImplV2.java的废弃文件而非当前活跃的OrderServiceImpl.java。这种错误不会导致编译失败但会让新功能幽灵般地无法生效。实际修改编译通过只是起点Codex 完成修改后我执行了编译。五次独立实验中编译通过率如下实验次数涉及文件数编译通过主要失败原因第 1 次5 个✅—第 2 次5 个❌Mapper XML 中参数类型引用错误第 3 次6 个❌新建 Validator 与现有校验工具类冲突第 4 次5 个✅—第 5 次5 个❌Service 层遗漏事务注解编译通过的三次实验中我进一步做了接口测试。结果并不乐观仅第 1 次完全通过业务逻辑校验第 4 次虽然编译成功但出现了典型的静默错误——批量取消时只处理了列表中的第一个订单原因是循环体内部的break误写为return而单元测试恰好只覆盖了两条数据的场景。这种逻辑一致性缺陷比编译错误更难发现。Codex 在单文件内的代码生成质量较高但跨文件的状态流转容易出问题。比如 Service 层设置了cancelTime字段Mapper 层的 SQL 却未更新该字段或者 Controller 返回的 JSON 结构与前端约定的字段命名存在下划线/驼峰不一致。自我修正有限但值得关注的尝试我在第 2 次实验中故意没有立即修复编译错误而是把报错信息原样抛回给 Codex。它的表现分为两个阶段第一阶段前两次交互能够定位到具体的错误文件和行号比如 OrderMapper.xml 第 23 行 parameterType 应为 java.util.List 而非 java.util.ArrayList。修复后编译通过。第二阶段第三次交互及以后当错误涉及跨文件引用时修正开始打乒乓球。比如它修复了 Mapper 的参数类型却导致 Service 层的调用方类型不匹配再修复 Service又可能引发 Controller 的返回值处理问题。三次以上的循环修正后我通常选择人工介入因为继续交互的时间成本已经高于直接修改。一个有趣的发现是当错误信息包含明确的文件路径和行号时Codex 的自我修正成功率显著高于模糊的描述。如果只说报错了它倾向于重新生成大段代码而非精准修复。AGENTS.md 的杠杆效应实验中我设置了对照组一组在项目中放置了规范的AGENTS.md文件另一组没有。AGENTS.md的内容并不复杂主要是项目结构说明、编码规范和关键类的职责描述## 项目规范 - Controller 层统一返回 ResultT 包装对象 - Service 层方法需标注 Transactional(rollbackFor Exception.class) - 状态枚举定义在 com.example.enums 包下禁止硬编码 - Mapper 接口与 XML 文件命名需完全一致区分大小写结果差异明显。有AGENTS.md的组文件识别准确率从约 70% 提升至 90%事务注解遗漏问题完全消失枚举类命名风格与现有代码保持一致但过度创建辅助类的问题依旧存在没有上下文的组更容易出现各写各的现象——单个文件的代码质量合格但组合在一起风格迥异比如一处用Optional做空判断另一处用if-null传统写法。不过AGENTS.md也有副作用。当规范描述过于详细时Codex 会机械套用哪怕某些场景并不适用。我在规范中写了所有接口需记录操作日志结果它在批量取消的循环体内部每次迭代都插入日志记录导致性能骤降。这提示我们规范需要留白而非穷尽列举。量化复盘一次完整交互的真实成本以第一次完全成功的实验为例完整交互数据如下Codex 主动修改文件数5 个Controller、Service、ServiceImpl、Mapper、实体类人工返工1 处——调整批量操作的批次大小参数原值 1000 对于该业务场景过大交互轮次3 轮需求描述 → 代码生成 → 微调确认总耗时约 12 分钟含等待生成和本地验证而失败案例的典型模式是Codex 修改 5-6 个文件编译或测试发现问题经过 2-3 轮自我修正后仍有缺陷最终人工介入修改 2-3 个文件总耗时反而超过纯手写。综合来看一次交互中完全无需人工干预的比例大约在 20%-30%主要集中在新增接口与现有代码风格一致、业务逻辑线性的场景。涉及状态机流转、分布式事务或复杂查询条件时人工返工几乎不可避免。给实践者的几点建议基于这些实验我逐渐形成了一些使用习惯。对于多文件修改任务现在会先手动梳理最小修改集——明确告诉 Codex 只需要改这三个文件不要新建其他类。这比放任它自由发挥更可控。遇到跨文件错误时与其反复投喂报错信息不如直接给出错误文件的具体位置和期望修改方向。比如OrderService.java 第 45 行cancelTime 字段需要赋值请同步修改 OrderMapper.xml 的 update 语句。AGENTS.md我会持续维护但控制在 200 行以内重点描述项目特有的约束而非通用最佳实践。通用规范 Codex 本身已有训练过度强调反而干扰判断。最后再高效的 AI 协作也替代不了本地构建和测试。Codex 生成代码后我养成了立即执行编译 核心路径单元测试的习惯——这个机械动作帮我拦截了至少一半的表面成功、实则埋雷的情况。 
长河君 · 2026/8/25 19:59:18 · 阅读 1.2k Codex处理多文件修改，一次能改准几个文件
一次典型的多文件修改实验为了摸清 Codex 在多文件联动修改中的真实表现我设计了一个贴近日常开发的需求在电商订单模块中新增批量取消订单功能。这个需求天然涉及五个文件的联动调整——Controller 层新增接口入口、Service 层实现批量业务逻辑、Mapper 层扩展数据库操作、实体类补充状态枚举以及一个独立的工具类用于参数校验。需求描述我刻意保持口语化在订单模块加个批量取消的功能前端传订单 ID 列表和取消原因后端校验权限、更新状态、记日志返回成功和失败的明细。 没有给出任何文件路径提示想看看 Codex 能否自主识别出需要改动的范围。任务拆解文件识别的第一道关卡Codex 的响应速度比预期快。大约十秒后它给出了任务规划识别到OrderController.java需要新增 POST 接口推断OrderService.java需添加批量处理方法定位OrderMapper.java需扩展批量更新 SQL发现OrderStatus.java枚举缺少 CANCELLED 状态额外创建BatchCancelValidator.java做参数校验这个识别结果让我有点意外——它多识别了一个文件。原项目中并不存在BatchCancelValidator.javaCodex 主动提议新建。这种过度规划在后续实验中反复出现大约 30% 的情况下它会建议创建并非必需的辅助类比如独立的常量类或配置类。开发者需要判断这是锦上添花还是过度设计。更隐蔽的问题在于文件遗漏。当项目存在同名或相似命名的历史遗留文件时Codex 有概率选中错误的基类。我在另一次实验中发现它修改了一个名为OrderServiceImplV2.java的废弃文件而非当前活跃的OrderServiceImpl.java。这种错误不会导致编译失败但会让新功能幽灵般地无法生效。实际修改编译通过只是起点Codex 完成修改后我执行了编译。五次独立实验中编译通过率如下实验次数涉及文件数编译通过主要失败原因第 1 次5 个✅—第 2 次5 个❌Mapper XML 中参数类型引用错误第 3 次6 个❌新建 Validator 与现有校验工具类冲突第 4 次5 个✅—第 5 次5 个❌Service 层遗漏事务注解编译通过的三次实验中我进一步做了接口测试。结果并不乐观仅第 1 次完全通过业务逻辑校验第 4 次虽然编译成功但出现了典型的静默错误——批量取消时只处理了列表中的第一个订单原因是循环体内部的break误写为return而单元测试恰好只覆盖了两条数据的场景。这种逻辑一致性缺陷比编译错误更难发现。Codex 在单文件内的代码生成质量较高但跨文件的状态流转容易出问题。比如 Service 层设置了cancelTime字段Mapper 层的 SQL 却未更新该字段或者 Controller 返回的 JSON 结构与前端约定的字段命名存在下划线/驼峰不一致。自我修正有限但值得关注的尝试我在第 2 次实验中故意没有立即修复编译错误而是把报错信息原样抛回给 Codex。它的表现分为两个阶段第一阶段前两次交互能够定位到具体的错误文件和行号比如 OrderMapper.xml 第 23 行 parameterType 应为 java.util.List 而非 java.util.ArrayList。修复后编译通过。第二阶段第三次交互及以后当错误涉及跨文件引用时修正开始打乒乓球。比如它修复了 Mapper 的参数类型却导致 Service 层的调用方类型不匹配再修复 Service又可能引发 Controller 的返回值处理问题。三次以上的循环修正后我通常选择人工介入因为继续交互的时间成本已经高于直接修改。一个有趣的发现是当错误信息包含明确的文件路径和行号时Codex 的自我修正成功率显著高于模糊的描述。如果只说报错了它倾向于重新生成大段代码而非精准修复。AGENTS.md 的杠杆效应实验中我设置了对照组一组在项目中放置了规范的AGENTS.md文件另一组没有。AGENTS.md的内容并不复杂主要是项目结构说明、编码规范和关键类的职责描述## 项目规范 - Controller 层统一返回 ResultT 包装对象 - Service 层方法需标注 Transactional(rollbackFor Exception.class) - 状态枚举定义在 com.example.enums 包下禁止硬编码 - Mapper 接口与 XML 文件命名需完全一致区分大小写结果差异明显。有AGENTS.md的组文件识别准确率从约 70% 提升至 90%事务注解遗漏问题完全消失枚举类命名风格与现有代码保持一致但过度创建辅助类的问题依旧存在没有上下文的组更容易出现各写各的现象——单个文件的代码质量合格但组合在一起风格迥异比如一处用Optional做空判断另一处用if-null传统写法。不过AGENTS.md也有副作用。当规范描述过于详细时Codex 会机械套用哪怕某些场景并不适用。我在规范中写了所有接口需记录操作日志结果它在批量取消的循环体内部每次迭代都插入日志记录导致性能骤降。这提示我们规范需要留白而非穷尽列举。量化复盘一次完整交互的真实成本以第一次完全成功的实验为例完整交互数据如下Codex 主动修改文件数5 个Controller、Service、ServiceImpl、Mapper、实体类人工返工1 处——调整批量操作的批次大小参数原值 1000 对于该业务场景过大交互轮次3 轮需求描述 → 代码生成 → 微调确认总耗时约 12 分钟含等待生成和本地验证而失败案例的典型模式是Codex 修改 5-6 个文件编译或测试发现问题经过 2-3 轮自我修正后仍有缺陷最终人工介入修改 2-3 个文件总耗时反而超过纯手写。综合来看一次交互中完全无需人工干预的比例大约在 20%-30%主要集中在新增接口与现有代码风格一致、业务逻辑线性的场景。涉及状态机流转、分布式事务或复杂查询条件时人工返工几乎不可避免。给实践者的几点建议基于这些实验我逐渐形成了一些使用习惯。对于多文件修改任务现在会先手动梳理最小修改集——明确告诉 Codex 只需要改这三个文件不要新建其他类。这比放任它自由发挥更可控。遇到跨文件错误时与其反复投喂报错信息不如直接给出错误文件的具体位置和期望修改方向。比如OrderService.java 第 45 行cancelTime 字段需要赋值请同步修改 OrderMapper.xml 的 update 语句。AGENTS.md我会持续维护但控制在 200 行以内重点描述项目特有的约束而非通用最佳实践。通用规范 Codex 本身已有训练过度强调反而干扰判断。最后再高效的 AI 协作也替代不了本地构建和测试。Codex 生成代码后我养成了立即执行编译 核心路径单元测试的习惯——这个机械动作帮我拦截了至少一半的表面成功、实则埋雷的情况。