最近接手了一个比较老的 Spring MVC + Spring 项目，我还是像平时一样让 Codex 先扫描项目，再辅助我修改和新增功能。
这次用的还是 GPT-5.6 Codex，没有用最新的 GPT-6 Astra。
但实际用下来，我发现维护这种老项目和在结构比较清晰的项目里使用 Codex，完全是两回事。
老项目本身就很难理解
这个项目最大的问题不是技术老，而是很多业务信息已经丢失了。
代码基本没什么有效注释，有些注释甚至和实际逻辑对不上。数据库很多字段也没有注释，命名更是比较混乱。
比如一个叫 houseSize 的字段，实际表达的却是屋顶类型。
另外项目里还有大量三四百行的 SQL，查询过程中直接夹杂各种业务逻辑。
这种情况下，即使 Codex 能把代码扫描一遍，它知道的也只是“代码现在是怎么运行的”，却不一定知道“业务为什么要这么运行”。
Codex 很容易加入不必要的兼容
这几天让我感受比较明显的是，Codex 经常会主动考虑各种异常情况。
比如一个确定格式的字符串：
按照现有业务约定，XXX 后面一定有空格。
如果让我自己写，判断不为空以后，按照空格切分拿到需要的内容就可以了。
但 Codex 会继续考虑没有空格怎么办、格式不完整怎么办，然后增加额外的保护和兼容逻辑。
单独看一次好像没什么问题，甚至显得代码更加“健壮”。
问题是老项目本身已经很复杂了。如果每次修改都增加一些实际上并不存在的兼容场景，代码只会越来越难理解。
甚至以后再看到这些判断，我自己都会怀疑：这里专门处理这种情况，是不是历史上真的存在什么特殊业务？
原来的混乱也可能被继续放大
日期处理也是一个让我比较头疼的地方。
项目本身就存在不同的日期处理方式，Codex 修改代码以后，有时候用这个方法，有时候又用另外一个方法。
最后看下来，会发现很多代码长得非常像，但某些地方又有一点区别。
我甚至会产生一种感觉：明明已经有类似的代码了，为什么这里又重新写了一套？
我已经在 AGENTS.md 里明确要求不要过度兼容，也尝试过先使用 Plan 模式分析再修改，但在这种项目里效果依然没有想象中那么好。
最后还是得自己理解业务
这次最大的感受是：AI 可以降低阅读和修改老代码的成本，但它解决不了业务上下文缺失的问题。
如果项目命名清晰、文档完整、业务边界明确，Codex 可以很快帮助完成很多工作。
但如果字段名字本身就是错的，注释不可信，几百行 SQL 里面又塞着大量业务规则，那么 Codex 很多时候也只能根据现有代码去猜。
现在我还是会继续用 Codex，它在查调用链、理解代码和辅助修改方面依然能帮我节省不少时间。
但对于这种老项目，我已经不太敢直接让它扫描完项目以后，就按照一个需求自己一路改下去了。
最后还是得自己把业务流程搞清楚。
否则如果连我自己都不知道这段业务为什么这么运行，让 AI 不断在原有代码上增加新的逻辑，可能短期功能确实做出来了，但改到最后，连我自己都不敢再动这套代码。