1. 逻辑漏洞自愈不是玄学：Codex CLI 在真实项目里修了哪些 BUG？
我上周在给一个金融风控规则引擎做灰度发布时，发现一个埋了三个月的边界条件漏洞：当用户授信额度恰好等于阈值时，系统会跳过所有风险校验直接放行。人工排查花了 47 分钟——从日志定位到模块，再翻 Git 历史确认是某次“快速修复”时删错了 else 分支。而用 Codex CLI 的--fix模式跑了一次，它在 8.3 秒内输出了带完整单元测试补丁的 PR 描述，且修复逻辑与我们最终人工确认的完全一致。
这不是个例。过去三个月，我在三个不同技术栈（Python + FastAPI、TypeScript + NestJS、Java + Spring Boot）的线上项目中，把 Codex CLI 集成进 CI 流水线后，逻辑类 BUG 的平均修复耗时从 32 分钟降至 6.5 分钟，人工介入率下降 68%。但必须立刻说清楚：它不是万能胶水。我试过让它修复一个涉及 Redis 分布式锁+MySQL 事务嵌套的死锁场景，它生成的代码在本地跑通，一上预发就触发了 100% 的超时熔断——因为没理解我们自研锁服务的重试语义。
真正能稳定落地的，是四类有清晰上下文边界的逻辑漏洞：状态机跳转遗漏、边界值判断缺失、空值/异常流处理空缺、以及简单条件组合错误。这四类占我们日常线上逻辑 BUG 的 73%（统计自近 90 天 Sentry 报告）。本文不讲“AI 编程多厉害”，只讲：Codex CLI 在什么条件下能可靠自愈、怎么把它塞进你现有的工程流水线、以及为什么你配置文件里那行max_context_tokens: 2048实际上正在悄悄拖慢修复速
