在大型游戏中调试中介系统：我的 LLM 对比与思考
最近，我在一个下载量超过 200 万 的游戏项目中，肩负起构建与调试一套复杂 中介（mediation）系统 的重任。
因为这套系统直接与广告变现挂钩，微小的代码改动也可能引发严重的连锁反应，影响整体货币化表现。面对这种高风险、高复杂度的场景，我尝试用各种 LLM 来辅助问题定位，得到了一些颇有启发的结果。
Claude：速度惊人、但深度欠缺
Claude 在处理任务时往往反应极快：几秒钟内就能输出数百行 diff、更替代码、给出重构建议。表面看起来效率极高，像是“眨眼就能写完”的那种魔术。但深入审查后我发现：
- 它常常只扫描了两三个文件，粗略抓取方法调用与命名线索，就试图构建整体逻辑。
- 它生成的重构或修复建议中，经常存在 边界条件遗漏、异常流程没覆盖、变量状态转移不严谨 等缺陷。
- 在跨模块调用、大型调用图这种结构复杂的系统里，Claude 提出的修正往往是局部的、碎片化的，难以覆盖全局一致性。
所以，在这种高复杂度的工程场景里，Claude 的快写能力反而可能带来误导：看起来重构“很快有着落”，但潜在的逻辑漏洞可能反而更多。
Codex：慢一点，但像资深工程师在旁
相比之下，Codex 的处理方式给我留下了更深的印象：
- 它会花 20–30 分钟构建方法调用链、追踪模块之间的依赖关系、分析异常路径与变量流动。
- 它能指出我之前没察觉的逻辑盲区、边界条件、状态不一致的问题。
- 它的建议更像是 “从整体架构视角” 给出的改进方向，而不仅仅是“哪里出错，怎么改一改”那种局部 fix。
虽然速度不如 Claude，但在这个场景下，更注重“准”、“稳”的能力才是我真正需要的。对于一个运行在百万用户规模、每次 bug 或逻辑失控都可能造成经济损失的中介系统，我宁可等待更可靠的分析，也不愿用“快速但浅显”的方案冒险。
一些反思与期望
- Claude 曾经是代码生成领域的佼佼者，但如今在工程级复杂场景下显得有些力不从心。它的“聊天体”风格、过多注释、冗长表达，有时候反而让人觉得它不够“干练”。
- Codex 在深度分析、跨模块挖掘、洞察边界条件方面展现出了更强的稳定性和可靠性。
- 我衷心希望未来 Claude 能重返巅峰，恢复那种既敏捷又能深入思考的强大能力。但在此之前，我更愿意投入到 Codex 所带来的“慢工但明智”的体验中。
快速体验推荐
如果你也在寻找一款能真正辅助工程级代码落地、提升代码分析深度的模型工具，不妨从这里尝试：
👉 点击体验 Codex 工具