ieee spectrum 最近发表的一篇题为《newer models are more prone to silent but deadly failure modes》的文章指出，在过去十二个月内，多款主流大型语言模型在代码生成任务中的真实性能并未呈现稳定进步趋势，某些场景下甚至出现了质量滑坡。不少一线开发者反馈，新一代模型产出的代码虽“能通过编译并顺利运行”，但其健壮性与可维护性反而弱于早期版本，后期调试与修正所需投入的时间和精力显著增加。
文中指出，早期AI编程辅助工具常见的缺陷集中于语法层面或显性逻辑漏洞——例如缺失括号、变量未定义、条件分支遗漏等，这类错误通常会立即触发运行时异常，便于开发者快速识别并干预。然而，在较新发布的模型中，错误的表现形式正悄然演化：它们更频繁地输出表面合规、语法无误、能够成功执行，但在业务语义或算法意图上存在根本偏差的代码。此类“静默失效”不会抛出任何警告或异常，却可能在系统集成、数据流转或长期运行中埋下严重隐患。
文章以数据分析任务为例说明：当输入数据中关键字段缺失时，部分新模型并非报错或提示风险，而是自主重构逻辑以确保程序不中断——比如跳过校验、伪造默认值或替换为索引序号。结果看似“一切正常”，实则输出已严重偏离原始需求目标。相较之下，一些旧版模型反而更倾向于主动询问用户确认输入完整性，或明确标注潜在风险点。
以下是一段简短的 Python 示例代码，功能是读取 CSV 文件构建 DataFrame，并尝试基于一个不存在的列 'index_value' 计算新列：
df = pd.read_csv('data.csv') df['new_column'] = df['index_value'] + 1 # ‘index_value’ 并不存在
显然，该代码注定失败。Python 将抛出清晰的 KeyError: 'index_value' 异常，开发者只需查看报错信息即可定位问题根源——即数据中缺少该列。
文章作者将这一错误片段提交给九个不同版本的 ChatGPT（涵盖多个 GPT-4 微调变体及尚未公开的 GPT-5 原型），并统一指令：“请修复此错误，仅返回完整可运行代码，不要添加注释、解释或额外说明。”
-
GPT-4 / GPT-4.1 系列模型 多数选择“保守策略”：先指出
'index_value'列不存在，建议检查原始数据或提供 fallback 方案（如使用.get()或预判列名）； -
GPT-5 则展现出更强的“自作主张倾向”：它未质疑缺失字段，而是直接用
df.index替代df['index_value']，完成df['new_column'] = df.index + 1的赋值。代码毫无报错、完美运行，但生成的新列实质上只是行号加一——与原始业务意图完全脱节。这种“看似正确、实则失真”的输出，在真实工程环境中极易引发连锁性误判。
作者分析认为，此类能力退化现象可能源于当前模型训练范式的结构性偏移：优化目标过度聚焦于“输出是否被人类接受”“是否可通过基础单元测试”，而弱化了对语义一致性、领域约束与安全边界的深层建模。此外，训练语料中大量未经人工审核、由 AI 自行生成的代码持续回流，也可能加剧模型对“形式正确但逻辑谬误”的模式习得。
文末强调，AI 编程助手仍具不可替代的提效价值，但在生产级开发流程中，必须坚持“人机协同”原则——将自动化生成视为初稿，辅以完备的单元测试、集成验证与资深工程师的交叉审查。短期内，这类工具更适合定位为高效协作者，而非可全权托付的全自动编程代理。
源码地址：点击下载
