#代码执行 #材料约束 #括号匹配 #调试对比 #工程实现
11个主流模型面对同一道括号匹配调试题，最终结果呈现明显两极：7个模型得分100，4个模型得分0。核心发现是，原代码真正致命的bug在于函数末尾的裸“return”会返回None，而非明确的True或len(stack)==0。
原代码的真实问题
题目提供的代码在匹配成功后使用三个if-continue结构，最后直接return。这种写法在栈为空时会返回None。Python中None在布尔判断中为False，导致调用方收到非预期结果。豆包Pro、Qwen3 Max、文心一言4.5、Grok 4、DeepSeek V4 Pro、Claude Opus 4.7和GPT-5.5均识别了这一问题，并统一改写为return len(stack)==0。
相比之下，Gemini 2.5 Pro、Claude Sonnet 4.6、Gemini 3.1 Pro和GPT-o3四模型未能在输出中体现对该返回值的修复，或直接未完成有效代码，导致0分。
满分模型的共同做法
7个满分模型均采用字典映射方式重构匹配逻辑：
- 使用mapping = {')':'(', '}':'{', ']':'['}
- 左括号入栈，右括号弹出并比对
- 统一返回len(stack)==0
这种写法把原代码三个重复if简化为一次查表，同时补上了原代码缺失的非括号字符处理。GPT-5.5额外增加了else分支，遇到非法字符直接返回False，代码鲁棒性更强。
零分模型暴露的短板
Claude Sonnet 4.6详细论证了原逻辑“实际上正确”，却未输出修正代码。Gemini系列和GPT-o3则在输出片段中未能完整呈现最终可运行版本。零分模型共同特点是：要么停留在分析阶段，要么修复不彻底，未能同时解决返回None和非法字符两个问题。
工程判断的实际意义
本次测试再次证明，代码执行维度不仅考察能否写出正确结果，更考察能否发现隐蔽的返回类型错误。使用continue跳过return False的写法虽然短期有效，但可维护性差，未来添加逻辑极易引入新bug。满分模型通过映射表一次性判断，显著降低了后续维护风险。
当模型能主动把“能跑”升级为“易维护且边界清晰”，才真正跨越了代码执行的及格线。
本次评测中，7个模型跨越了这条线，4个仍停留在表面分析。稳定性维度后续将追踪同一模型多次回答同类调试题时的分数波动，当前结果已显示出明显分化。
数据来源：赢政指数 (YZ Index) | Run #154 | 查看原始数据
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接
