11个AI同解SQL重复支付题：仅4个满分，7个直接0分

同一道SQL题目，11个模型最终得分呈现两极分化：4个100分，7个0分。核心差异集中在自连接去重逻辑、时间差计算函数选择以及status条件的放置位置。

满分答案的共同特征

豆包Pro、Grok 4、Gemini 2.5 Pro和Gemini 3.1 Pro四家正确实现了三点要求：用p1.id < p2.id避免镜像重复、status条件放在JOIN ON中或WHERE中均可、时间差计算准确且方向正确。

豆包Pro使用TIMESTAMPDIFF(SECOND, p1.created_at, p2.created_at) <= 120，兼容MySQL方言；Grok 4同样采用TIMESTAMPDIFF且把所有条件放在ON子句，结构清晰；两款Gemini则用UNIX_TIMESTAMP做差，同样满足120秒限制并保证first_id先于second_id。

0分答案的典型错误

七个0分模型主要犯三类错误：

• 缺少p1.id < p2.id，导致同一对记录输出两次（Qwen3 Max、Claude Sonnet 4.6、DeepSeek V4 Pro、Claude Opus 4.7、GPT-o3、GPT-5.5）；
• 时间函数选用错误或方向反向（文心一言4.5、DeepSeek V4 Pro使用EXTRACT(EPOCH FROM ...)但未处理时区，且部分答案created_at比较方向混乱）；
• 查询不完整或status条件缺失（文心一言4.5直接截断，DeepSeek把status放在WHERE却漏掉created_at方向限制）。

这些错误在真实支付系统中会直接导致重复告警或漏报，属于工程级致命问题。

函数选择背后的方言差异

满分模型明显更懂SQL方言适配。TIMESTAMPDIFF是MySQL标准写法，UNIX_TIMESTAMP同样常见于MySQL环境。而EXTRACT(EPOCH FROM ...)是PostgreSQL语法，在MySQL中会直接报错。七个0分模型中至少四家混用了跨方言函数，说明模型对生产环境SQL方言的敏感度不足。

工程判断的真实差距

这次测试再次证明，单纯“会写SQL”与“能写生产可用SQL”是两回事。正确答案必须同时满足去镜像、精确时间窗口、状态过滤三重约束。多数模型在其中一到两项上翻车，反映出它们在处理多条件自连接时的系统性短板。

4比7的得分悬殊，说明当前大模型在工程SQL生成上仍处于“会写”而非“会写对”的阶段。

未来半年内，若模型在类似多约束自连接任务上仍维持这种高失败率，支付风控、订单去重等核心业务场景将持续依赖人工审核。

数据来源：赢政指数 (YZ Index) | Run #154 | 查看原始数据