最刺眼的不是 GPT-o3 掉了 0 分，而是它在一道基础 Debug 题上从满分直接归零，同时主榜还上涨了 2.1。
这次事故的核心题目是“Debug：矩阵旋转”。上期 GPT-o3 该题得分 100，本期变成 0。题目本身并不偏门：原地将 N×N 矩阵顺时针旋转 90 度，标准解法就是先沿主对角线转置，再反转每一行。GPT-o3 也写出了这条路线，但最后一步没有真正执行。
for i in range(n): matrix[i].reverse
问题就在这里：reverse 少了括号。它只是取到了列表方法对象，没有调用。结果函数只完成了转置，矩阵并没有完成顺时针旋转。对严格题来说，这不是“差一点”，而是功能错误，所以从 100 到 0 是合理判罚。
这不是知识不会，而是执行链断了
更值得注意的是，GPT-o3 的整体数据并没有同步崩盘。v6 主榜从 73.62 升到 75.69，涨了 2.1；材料约束从 66.80 升到 73.10，涨了 6.3；代码执行只从 79.20 降到 77.80，跌 1.4。也就是说，这次事故不是模型全面退化，而是典型的“局部硬失败”：大盘看起来更好，单点却足以让开发者踩坑。
这类失败比“完全不会”更危险。因为模型解释了正确思路，注释也写得像标准答案，读者第一眼会以为它已经完成任务。真正的错误藏在一个括号里。如果没有测试用例，人工审阅很容易漏掉。
主榜上涨掩盖了严格题风险
按照赢政指数 v6，主榜只看代码执行和材料约束两个可审计维度。这次主榜上涨，主要来自材料约束改善：66.80 到 73.10，涨幅 6.3。它说明 GPT-o3 本期更能贴合题面、利用材料，但并不能保证每个代码路径都被正确执行。
代码执行从 79.20 到 77.80，只跌 1.4，看似轻微；可“矩阵旋转”从 100 到 0，说明平均分会稀释事故严重性。对工程团队来说，平均分不是上线保险。一个低级 API 调用错误，就能让看似正确的算法在生产里返回错误结果。
侧榜信号出现分裂
工程判断（侧榜，AI 辅助评估）从 43.50 升到 51.30，涨 7.8；任务表达（侧榜，AI 辅助评估）却从 40.00 降到 30.00，跌 10。这组数据很有意思：它可能更会判断方向，但把任务完整、可验证地交付出来的能力反而变弱。
放到这道题上看，GPT-o3 的判断方向没错：转置加反转行。但交付层面失败：没有调用 reverse()，也没有给出最小测试验证。这正是“看起来懂、跑起来错”的典型事故模式。
稳定性低，不等于正确率低
本期稳定性从 37.4 降到 35.9，继续偏低。但必须强调，稳定性衡量的是回答一致性，基于分数标准差，公式是 max(0, 100-stddev×2)，不是正确率。35.9 的含义是：同类题多次回答时分数波动较大，输出不够一致；不能解读成“正确率 35.9%”。
这对 GPT-o3 的风险画像很关键：它不是不可用。可用性仍是 100.0，说明能正常响应；性价比从 8.5 到 8.4，基本稳定。但在严格代码题里，它会出现“高置信低级错”。这类错不靠更长解释解决，只能靠执行、测试和判题兜底。
结论：GPT-o3 需要被当成候选程序员，而不是终审编译器
这次事故给出的结论很明确：GPT-o3 的材料贴合能力在变好，主榜也在上涨，但代码交付仍存在针尖级断裂。尤其是基础 API 调用这种错误，最能暴露模型没有真正运行代码的短板。
我对它的使用建议很直接：让 GPT-o3 写初稿可以，让它解释思路可以，但凡进入严格逻辑、数组变换、边界条件密集的代码场景，必须配测试。没有测试的模型代码，本质上只是“语法上像答案”的文本。
记住这句话：主榜上涨不等于事故消失；真正的工程风险，常常就藏在少掉的那一对括号里。
数据来源：赢政指数 (YZ Index) | Run #112 | 查看原始数据
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接