最近拿一个偶发的并发问题同时问了几个模型，答案看起来都挺像回事，真正能跑通的却只有一个。回头复盘，差别不在“会不会写代码”，而在它有没有抓到日志里的时间顺序、有没有追问运行环境，以及是否愿意承认信息不够。
我现在测试代码能力会固定提供最小复现、依赖版本和期望行为，再看模型能否先定位问题而不是直接重写。只比较最终代码，很容易把碰巧跑通当成能力强。
大家平时怎么比较代码模型？有没有一套自己反复使用的测试题？
这次最有意思的是，答对的那个模型并没有给最长的代码。它先指出两条日志的线程编号不同，又让我补一段锁的生命周期，最后只改了六行。另两个方案都引入了新队列，表面更“完整”，却把原来的超时语义改掉了。以后我会把“是否保持原行为”单独列为评分项，也会记录它提出了哪些必要问题。
我准备固定下来的测试办法
第一轮只给问题描述、最小复现和版本，不透露我已经找到的原因。看模型会不会先运行已有测试、确认现象和提出必要问题。第二轮补充关键日志，观察它是否修正假设，而不是为了维护原答案继续圆。最后才让它给补丁，并要求解释改动影响到哪些调用方。
评分也不只看“测试过了”。我要检查有没有顺手改公开接口、有没有吞掉异常、是否引入不必要依赖、代码风格是否和仓库一致，以及新测试能否在旧代码上稳定失败。有些答案通过了当前用例，却用一个更大的锁遮住竞态，性能和可维护性都变差，这不能算真正修好。
为了减少模型记过公开题目的影响，测试最好来自自己遇到过并已修复的问题，删掉业务信息后再使用。保留当时的错误补丁也很有用：如果模型重复给出同样方案，可以直接验证它是否识别到已知副作用。这样几个月后换新版本，仍能用同一把尺子比较。