1. 为什么我会想到让 Codex 来当反方重试这件事写过分布式系统的人都不陌生。接口超时了要重试消息投递失败了要重试模型输出中断了要重试。几乎每个线上系统里都埋着几处重试逻辑但真正让我睡不踏实的是这些重试到底安不安全我自己说了不算。我最近在做一套基于 Codex 的自动化代码审查流程核心场景是让模型对提交的代码做对抗性审查adversarial-review。这个流程本身就要调用外部接口接口会超时、会限流、会返回半截结果所以重试是绕不开的。问题在于我写重试逻辑的时候脑子里默认重试是幂等的但这个假设从来没被真正验证过。直到有一次线上出现重复扣减我才意识到重试的风险不是会不会重试而是重试之后世界变成什么样。于是我做了一个有点反直觉的决定不再自己拍脑袋判断重试安不安全而是把 Codex 拉进来当反方让它专门挑重试逻辑的毛病把每一个风险点问到可以验证的程度。这个思路借鉴了对抗性审查的理念——与其让写代码的人自证清白不如让一个独立的审查者带着我要找出你哪里会炸的心态来提问。这篇文章就是这套方法的完整复盘。我会讲清楚为什么选 Codex 当反方、怎么设计提问让它问出真问题、幂等性到底该怎么验证、沙箱在其中扮演什么角色以及我踩过的那些坑。如果你也在写带重试的接口、也在纠结幂等性用数据库还是缓存实现这篇应该能给你一些直接能抄的东西。2. 把重试安全拆成可验证的问题2.1 重试风险的本质是状态漂移先说一个我反复跟团队强调的观点重试本身不可怕可怕的是重试前后系统状态不一致。一次请求失败你重发一次如果两次执行对最终状态的影响完全相同那这个操作就是幂等的重试随便加如果两次执行会叠加效果那重试就是在制造脏数据。举个生活化的例子。你去便利店买水付了钱但机器没出小票店员说我再给你打一张。如果只是补打小票打十次都没关系这就是幂等。但如果店员理解成再卖你一瓶那每重试一次你就多花一笔钱这就是非幂等。接口重试的风险本质上就是补打小票和再卖一瓶之间的区别而很多代码在写的时候根本没想清楚自己属于哪一种。状态漂移通常发生在几个地方数据库写入没有唯一约束、缓存扣减没有原子性、外部调用没有去重键、消息投递没有消费位点记录。这些点单独看都不复杂但组合起来就会形成看起来幂等、实际不幂等的陷阱。我见过最隐蔽的一个案例是接口用订单号做了去重但去重记录写在了缓存里且设置了过期时间缓存一过期重试就穿透了。2.2 为什么人工审查容易漏掉重试问题我自己审过不少重试代码也被人审过坦白说人工审查在这个场景下效率很低。原因有三个。第一重试路径是异常路径正常流程走不到审查的人容易顺着 happy path 看下去忽略掉 catch 块里的逻辑。第二幂等性依赖上下文一个函数单独看是幂等的但放在事务里、放在并发场景下就不一定了审查者需要脑补整个调用链。第三人会有确认偏误写代码的人倾向于相信自己的实现是对的审查的人如果没有明确的攻击目标也容易走过场。这就是我引入 Codex 当反方的直接动机。模型没有我写的代码应该没问题这种心理包袱你让它找问题它就真的去找问题。而且它可以不知疲倦地对同一个逻辑反复追问直到把假设逼到墙角。2.3 对抗性审查的提问框架让 Codex 当反方关键不在于让它审查而在于怎么问。我试过直接说帮我看看这段重试逻辑有没有问题得到的回答往往是泛泛而谈的建议加幂等键注意并发。这种回答没有验证价值。后来我改成了一套结构化的提问框架效果立刻不一样。核心是三类问题反例追问要求模型构造一个具体的执行序列让重试产生错误结果。比如请给出两次请求的执行顺序使得最终余额比预期多扣一次。边界逼问把参数推到极端问会发生什么。比如如果第一次请求已经写库成功但响应超时第二次请求进来时唯一键冲突会怎么处理。验证设计要求模型给出可执行的验证方案而不是结论。比如设计一个测试用例能证明这个接口在并发重试下是幂等的。这三类问题的共同点是它们都要求产出可验证的东西要么是可复现的反例要么是可执行的测试。模型没法用一般来说没问题糊弄过去。2.4 沙箱是让反方敢说话的前提这里必须提沙箱。让 Codex 审查代码、甚至让它生成验证脚本前提是这些操作不能碰到真实环境。我的做法是把待审查的代码、依赖、测试数据全部放进一个隔离的代码沙箱里模型在这个沙箱里可以自由地跑测试、构造并发、模拟超时跑出来的任何结果都不会污染线上。沙箱的价值不只是安全更重要的是它让验证变得可重复。同一个反例今天跑和明天跑结果一致团队里任何人都能复现。这比我本地试了一下好像有问题有说服力得多。我用的沙箱方案是容器化的每次审查任务启动一个干净实例跑完即销毁模型生成的验证脚本也随实例一起清理不留残留。3. 幂等性验证的实操设计3.1 幂等键到底该放在哪一层幂等性实现的第一道选择题是幂等键放在哪一层。常见的有三个位置——网关层、业务层、存储层。我的经验是存储层兜底业务层做语义网关层只做粗过滤。网关层做幂等优点是拦截早、成本低缺点是它只能看到请求级别的信息比如请求 ID、用户 ID、接口路径看不到业务语义。如果两个请求业务上等价但请求 ID 不同网关拦不住。业务层做幂等能理解这两笔操作其实是同一件事但需要业务代码显式处理容易漏。存储层做幂等靠唯一约束或条件更新是最可靠的兜底但它是最后一道防线前面漏了它才生效报错信息对用户不友好。我的实际做法是三层配合网关层用请求指纹做快速去重业务层用业务幂等键比如订单号加操作类型做语义判断存储层用唯一索引做最终保证。任何一层拦住了都算成功三层都没拦住才说明设计有洞。3.2 数据库实现和缓存实现的取舍幂等性检查用 DB 实现好还是 Redis 实现好这个问题我被问过很多次热词里也反复出现。我的答案从来不是二选一而是看你要保证的是不重复还是不重复且不丢。数据库实现的核心优势是持久性和事务性。你把幂等键写进一张带唯一索引的表插入成功代表首次执行插入冲突代表重复请求这个判断和业务写入可以在同一个事务里完成要么都成功要么都失败不存在中间态。缺点是每次幂等检查都要落盘QPS 高的时候数据库压力大。缓存实现的核心优势是快。用 SETNX 或者带 NX 参数的 SET 命令一次内存操作就能判断是否首次性能比数据库高一个数量级。缺点是缓存可能丢、可能过期、可能因为主从切换出现短暂不一致。如果你的幂等键在缓存里丢了重试就会穿透重复执行。我的取舍标准是这样的场景推荐方案理由涉及资金、库存等强一致数据库唯一索引不能容忍丢失性能可以让位高频读、低频写、可容忍极小概率重复缓存 SETNX性能优先重复影响可控既要快又要稳缓存前置 数据库兜底缓存拦大部分数据库保最终跨服务、跨机房数据库或分布式协调缓存跨机房同步有延迟实际项目里我绝大多数时候用的是第三种——缓存做第一道快速拦截数据库唯一索引做最终保证。缓存命中直接返回缓存未命中或缓存异常时走数据库数据库冲突就说明是重复。这样既拿到了缓存的性能又保住了数据库的可靠性。3.3 用 Codex 生成反例的具体提问模板回到让 Codex 当反方这件事。我整理了几个实际用下来效果最好的提问模板你可以直接拿去改。第一个模板针对重试导致重复写入下面这段代码在请求超时后会被重试。请构造一个具体的执行序列包含两次请求各自的执行时机和数据库状态使得重试后数据库中出现两条本应只有一条的记录。给出每一步的状态变化。第二个模板针对并发重试假设两个相同的请求几乎同时到达都通过了前置的幂等检查。请分析在数据库唯一索引、缓存 SETNX、以及两者组合三种方案下分别会发生什么哪种方案能保证最终只有一条记录。第三个模板针对验证方案设计请为这个接口设计一组测试用例要求覆盖首次请求成功、首次请求超时后重试、两次请求并发、缓存失效后重试。每个用例说明输入、预期状态、以及如何断言幂等性成立。这三个模板的共同点是强制模型输出状态序列和断言而不是给结论。我实测下来用模板问出来的问题质量比自由提问高出一大截。3.4 沙箱里跑验证脚本的完整流程光有反例还不够得能跑起来验证。我的流程是这样的把待审查的接口代码、数据库 schema、缓存配置打包进沙箱镜像。让 Codex 基于反例生成验证脚本脚本里包含并发模拟、超时注入、状态断言。在沙箱里执行脚本收集结果。如果脚本复现了问题把执行日志和状态快照一起交给 Codex让它分析根因。修复后重新跑同一套脚本确认问题消失。这个流程里最关键的是第 2 步和第 5 步。第 2 步要求模型生成的是可执行脚本而不是伪代码我一般会明确要求用具体的测试框架和断言库。第 5 步是回归验证同一套脚本修复前后各跑一次结果对比一目了然。提示沙箱里的数据库和缓存要用真实组件不要用内存 mock。很多幂等性问题恰恰出在真实组件的并发行为和事务隔离级别上mock 会把这些细节抹掉验证就失去意义了。4. 让 Codex 审查重试逻辑的完整实操4.1 准备阶段把代码和上下文喂给模型Codex 再强你给的信息不全它也审不出东西。我准备上下文的时候会包含这几样接口的完整实现代码、涉及的数据库表结构和索引、缓存的使用方式、调用方的重试策略重试几次、间隔多久、什么条件下重试、以及这个接口的业务语义说明。业务语义说明经常被忽略但它特别重要。模型需要知道这个操作重复执行一次会造成什么后果才能判断幂等性要求有多高。比如发送通知重复一次可能只是用户收到两条消息而扣减库存重复一次就是实打实的损失。我会用一两句话把这个说清楚模型的判断会准很多。4.2 提问阶段三类问题的实际效果对比我把前面提到的三类问题在实际项目里都试了一遍效果差异很明显。反例追问类问题模型给出的回答最有价值。有一次我让它构造重试导致重复扣减的执行序列它给出了一个我完全没想到的路径第一次请求在扣减库存后、写订单前崩溃重试时因为订单还没写幂等检查查不到记录于是又扣了一次。这个路径我人工审查时压根没考虑到因为我的注意力都在扣减那一步忽略了扣减和写订单之间不是原子的。边界逼问类问题适合发现参数和配置层面的问题。比如我问如果重试间隔小于数据库主从同步延迟会怎样模型分析出从库可能读到旧数据导致幂等检查误判。这类问题人工也能想到但模型能更快地穷举各种边界组合。验证设计类问题产出的是可以直接用的测试用例。我一般会让模型生成 pytest 或 JUnit 的测试代码稍微改改就能进 CI。这类问题的回答质量取决于你给的上下文是否完整上下文越全生成的测试越贴合实际。4.3 验证阶段把反例变成可执行的测试模型给的反例是文字描述要变成可执行的测试还得加工。我的做法是让模型把反例直接翻译成测试代码然后我在沙箱里跑。翻译的时候要特别注意两点时序控制和状态断言。时序控制是指反例里第一次请求超时这种条件在测试里要用可控的方式模拟比如注入一个会抛超时的桩或者用延迟队列精确控制两次请求的先后。状态断言是指测试不能只断言接口返回成功还要断言数据库里的记录数、缓存里的键值、以及业务状态字段。只有状态断言才能证明幂等性成立。我踩过的一个坑是早期测试只断言了接口返回值结果接口返回成功但数据库里写了两条测试照样通过。后来我把断言改成查询数据库记录数等于 1才暴露出问题。这个教训让我明白幂等性测试的断言必须落在状态上不能落在返回值上。4.4 修复阶段根据审查结果调整实现Codex 审查出来的问题修复方式无非几种加唯一索引、改条件更新、调整事务边界、补幂等键。我按出现频率排了个序。最高频的是缺唯一索引。很多表设计的时候只考虑了主键没考虑业务唯一键导致重试时插入了重复记录。修复很简单加一个业务唯一索引插入冲突时捕获异常返回已有记录。第二高频的是检查和使用之间有间隙。典型的写法是先查有没有记录没有就插入这两步之间没有锁也没有唯一约束并发下两个请求都会查到没有然后都插入。修复方式是把这个查-插合并成一个原子操作要么用 INSERT ... ON CONFLICT要么用带条件的 UPDATE。第三高频的是事务边界不对。扣减和记录不在同一个事务里中间崩溃就会不一致。修复是把它们放进同一个事务或者用补偿机制保证最终一致。4.5 回归阶段确认修复真的有效修复完不能就算完得用同一套验证脚本再跑一遍。我一般会跑三轮单次请求、串行重试、并发重试。三轮都通过才认为修复有效。这里有个细节回归测试要在和首次验证相同的沙箱环境里跑。环境不一致结果就没有可比性。我会把沙箱镜像打个 tag首次验证和回归验证用同一个 tag确保依赖版本、数据库配置、缓存参数完全一致。5. 常见问题与排查技巧实录5.1 重试相关的高频问题速查现象可能原因排查方向解决思路重试后出现重复记录缺业务唯一索引查表结构是否有唯一约束加唯一索引冲突时返回已有记录并发下幂等失效查-插之间有间隙看是否有原子操作用 ON CONFLICT 或条件更新缓存失效后重复执行幂等键只存在缓存检查缓存过期策略缓存加数据库双保险重试后状态不一致事务边界不对看扣减和记录是否同事务合并事务或加补偿从库读到旧数据主从延迟检查读的是主库还是从库幂等检查走主库重试次数过多打爆下游没有退避策略看重试间隔配置加指数退避和熔断这张表是我从实际排查记录里整理出来的基本覆盖了八成以上的重试幂等问题。遇到问题先对号入座能省不少时间。5.2 让 Codex 审查时容易踩的坑第一个坑是上下文给太多。我一开始把整个仓库都塞给模型结果它抓不住重点审查意见很散。后来我改成只给相关文件加必要的调用链审查质量明显提升。模型和人一样信息过载反而影响判断。第二个坑是问题太开放。问这段代码有什么问题得到的回答往往很泛。问这段代码在什么情况下重试会产生重复扣减回答就具体得多。问题越聚焦产出越有价值。第三个坑是不验证就信。模型给的反例有时候是错的它可能假设了一个不存在的执行顺序。所以反例必须拿到沙箱里跑一遍跑通了才算数。我现在的习惯是模型说的任何结论都要有可执行的验证支撑否则只当参考。5.3 沙箱使用的注意事项沙箱虽然隔离但也有几个要注意的地方。资源限制要设好模型生成的验证脚本可能写出死循环或者疯狂创建连接不限制的话会把沙箱打爆。我一般会限制 CPU、内存、以及脚本的最长执行时间。网络要隔离沙箱里的代码不应该能访问外部服务否则验证结果会受外部因素干扰也可能带来安全风险。我的沙箱默认禁网需要的外部依赖全部用本地桩替代。数据要清理每次验证任务结束后沙箱里的数据库、缓存、临时文件都要清干净避免影响下一次验证。我用的是用完即销毁的容器天然满足这一点。5.4 幂等性设计的几条经验法则最后分享几条我总结的经验法则都是踩坑踩出来的。法则一幂等键要能唯一标识一次业务意图。请求 ID 不行因为同一个业务意图可能对应多个请求 ID。订单号加操作类型可以因为它唯一标识了对某个订单做某类操作这件事。法则二幂等检查要尽量靠近写入。检查和使用之间的间隙越小出问题的概率越低。最理想的是把检查和写入合并成一个原子操作。法则三幂等性要有兜底。不管前面做了多少层检查存储层的唯一约束不能省。它是最后一道防线前面都漏了它还能拦住。法则四幂等性要可验证。设计的时候就要想好怎么测测不了的设计等于没设计。这也是我坚持让 Codex 生成验证脚本的原因——验证方案和实现方案一样重要。法则五重试策略要和幂等性匹配。非幂等的操作不能盲目重试要么改成幂等要么用补偿机制。我见过太多为了可用性加重试结果制造了数据问题的案例。我个人在实际操作中的体会是让 Codex 当反方这件事价值不在于它比人聪明而在于它没有心理包袱、不知疲倦、且能产出可验证的东西。人审查代码会累、会走神、会自我说服模型不会。但模型也会犯错所以它的每一个结论都要落到沙箱里跑一遍。这套模型提问、沙箱验证、人工决策的组合是我目前找到的对付重试风险最靠谱的方式。后续我打算把这套流程固化进 CI每次提交带重试逻辑的代码自动触发一轮对抗性审查和沙箱验证把问题拦在合并之前。