11个主流AI模型面对同一道SQL聚合查询时，出现了清晰的执行断层。8个模型输出可运行的代码，得分60；Claude Sonnet 4.6、Claude Opus 4.7和GPT-o3三款模型直接返回0分，问题集中在日期区间语法与MySQL方言的兼容性上。
正确答案的共同特征
得分60的模型普遍采用了两种可执行写法。第一种是MySQL原生DATE_SUB函数，例如豆包Pro、文心一言4.5和Grok 4均使用：
created_at >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)这种写法在MySQL 5.7/8.0环境下可直接执行，无需额外转换。第二种是部分模型采用的CURRENT_DATE - INTERVAL '90' DAY形式，但需去除引号或调整方言才能通过。
0分模型的致命错误
三款0分模型的SQL在日期处理上出现系统性偏差。Claude Sonnet 4.6和Claude Opus 4.7均写成：
created_at >= CURRENT_DATE - INTERVAL '90 days'单引号包裹的'90 days'在MySQL中属于非法语法，执行时直接报错。GPT-o3则使用了CURRENT_DATE - INTERVAL '90 days'，同样无法在标准MySQL环境中运行。
这些模型忽略了题目隐含的MySQL语境（表结构与字段命名风格常见于MySQL示例），把PostgreSQL或Oracle的日期写法直接带入，导致执行阶段完全失败。
执行维度真实差异
从代码执行角度看，60分模型不仅语法正确，还满足了全部约束条件：过滤amount IS NOT NULL、status='paid'、按total_amount降序+user_id升序、LIMIT 10。0分模型即使逻辑思路相似，也因无法执行而失去所有分数。
值得注意的是，Gemini 2.5 Pro和Gemini 3.1 Pro虽然得分相同，但Gemini 3.1 Pro使用了CURDATE()，与MySQL兼容性更高，实际部署时更稳健。
模型能力边界判断
Claude系列在自然语言理解上通常领先，但在需要精确方言匹配的工程代码任务中出现明显短板。GPT-o3作为最新迭代，同样在这一SQL边界题上翻车，说明其代码执行训练仍存在方言盲区。
相比之下，Qwen3 Max、DeepSeek V4 Pro、GPT-5.5等模型在SQL方言适配上更务实，输出结果可直接投入生产环境。
在代码执行维度，语法兼容性比“看起来正确”更重要。
本次测试再次证明，AI模型的工程价值最终由能否在目标数据库中真正运行来决定。日期函数的细微差异，直接决定了0分与60分的差距。
未来模型若想在工程场景站稳，必须把主流数据库方言的边界案例纳入核心训练，而非仅依赖自然语言描述。
数据来源：赢政指数 (YZ Index) | Run #122 | 查看原始数据
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接