一、把并发问题写成可验证的约束
比较推理模型，不要从“找出这段代码的问题”开始。先交代共享状态、执行环境和正确性约束。例如，两个任务同时扣减库存，每笔订单只能扣减一次，库存不能为负。要求模型解释哪些执行顺序可能破坏这些约束，而不是仅凭“异步”“共享变量”等词判断存在竞态。
先定义正确，再讨论缺陷。如果模型连应当保持什么都说不清，后续补丁很可能只是让代码看起来更安全。
二、用同一组材料建立公平比较
给每个候选模型提供完全相同的代码、依赖版本、错误现象和已有测试。明确哪些组件允许修改，哪些接口必须保留。首次回答前不要透露标准答案，也不要把另一个模型的分析转交过去。
任务集应同时包含存在缺陷和没有缺陷的案例。否则，模型可能靠“每段代码都有问题”的猜测获得好评。把未知条件写清楚，允许模型指出证据不足，而不是奖励武断结论。
三、要求模型展开导致错误的交错顺序
以丢失更新为例，要求模型逐步描述：甲读取库存，乙读取相同库存，甲写回扣减结果，乙再写回自己的结果。检查每一步是否符合代码实际允许的执行方式，是否真的存在让出执行权的位置。
能讲出竞态故事，不等于证明竞态存在。如果模型假设了实际不会发生的线程切换，或者忽略事务隔离与已有锁，它的分析就不能作为修复依据。
四、把偶发故障改造成受控复现
接着要求模型设计测试，让两个任务在目标读取之后等待，再按指定顺序继续。优先使用屏障、事件或可控制的测试替身协调执行，不要只靠延长等待时间碰运气。
测试必须检查业务约束，例如成功订单数量是否与库存减少量一致。还要检查测试自身有没有意外串行化操作。能够稳定制造目标交错，比反复运行后偶尔看到失败更有诊断价值。
五、比较补丁覆盖范围和新增风险
要求模型提交最小补丁，并说明保护了哪个共享状态、临界区从哪里开始、在哪里结束。单进程中的锁不一定能保护多个服务实例；数据库事务也不能自动覆盖事务之外的外部操作。
- 处理丢失更新，检查读取与写入是否形成不可分割的操作。
- 处理死锁，检查锁获取顺序以及异常路径上的释放。
- 处理重复执行，检查幂等标识的记录与业务变更是否一致。
不要因为补丁加入了锁就直接判定通过。范围过大可能阻塞无关操作，范围过小则可能留下原有缺口。
六、用反例和回归测试检验修复
修复后继续追问：任务取消、操作超时、写入失败或请求重试时会发生什么？保留原有复现测试，并补充与补丁直接相关的异常路径。对于死锁案例，还应验证相反的调用顺序。
记录每个模型是否主动修正错误假设，是否给出能执行的测试，以及测试是否真正覆盖修复点。没有运行过的补丁应标记为待验证，不能因为解释完整就当作已经解决。
七、按证据记录结果并复用比较流程
分别记录缺陷定位、交错推演、复现质量、补丁正确性和回归覆盖，不要把所有表现压成一个印象分。保留原始提示、模型标识和测试结果；遇到判断分歧，以代码行为和测试证据为准。
需要在同一接入方式下切换候选模型时，可以考虑 SwiftRelay，按实际词元用量结算，便于把任务材料与调用记录统一管理。欢迎注册，用同一组并发案例开始比较。最终应选择能提出可验证解释、承认边界并经受反例检验的模型，而不是措辞最自信的模型。