GPT-5.6 Terra SonarSource 4,444 Java 任务代码质量与安全复测

一句话结论

在同一组 4,444 个 Java 任务和 medium 推理配置下，Terra 生成的代码更短、缺失完成更少，但认知复杂度、bug/vulnerability 和 code smell 密度更高，必须接入静态分析与测试。

测试环境

• 模型：GPT-5.6 Sol、GPT-5.6 Terra、GPT-5.5。

• 语言：Java。

• 任务数：4,444；来源为 HumanEval、MBPP、ComplexCodeEval。

• 推理设置：三种模型均为 medium。

• 分析器：SonarQube algorithmic code analysis。

• 指标单位：complexity/code smell 按 kLOC；bug/vulnerability 和分类明细按 mLOC。

输入/配置

SonarSource 说明三种模型使用同一任务、同一质量分析和同一推理档位，并把 GPT-5.5 重新跑在同一框架中。文章没有公开每题 prompt、快照、采样参数、完整生成输出或任务级失败清单。

结果数据

补充数据：Terra 输出约 8.37M tokens、推理 tokens 约 3.66M；输入约 1.32M tokens。Terra 的 blocker-level smell 为 62/mLOC，低于 Sol 的 72 和 GPT-5.5 的 78，但 collection/generics 类问题升至 11,843/mLOC。并发/线程 bug 是 Terra 最大 bug 类别，约 350/mLOC。

结论

• Terra 的 79.96% pass rate 略高于 GPT-5.5，但低于 Sol 的 81.99%；不能只按模型价格判断生产可靠性。

• Terra 以 617,132 行代码完成同一任务，代码量显著少于 GPT-5.5 和 Sol；这有利于减少审阅体积，但每 kLOC 的问题密度更高。

• 认知复杂度 161.53/kLOC、bug 763/mLOC、漏洞 203/mLOC 和 smell 23.31/kLOC，说明“短”不等于“更易维护”。

• 并发/线程、密码学配置和资源处理是应优先自动化检查的风险面；人工通读不应是唯一门禁。

局限

• 任务全部为 Java 合成/标准化任务，不能代表多语言真实仓库。

• SonarQube 静态分析反映可检测的代码问题，不等于真实线上缺陷率，也不能衡量完整系统的业务正确性。

• 同一 medium 设置有利于受控比较，但没有告诉我们 Terra 在 low/high/max 下的质量-成本曲线。

• 文章由 SonarSource 发布，分析器和指标定义由其控制；应保留原始输出并用第二种测试框架交叉验证。

复现步骤

1. 固定 Java 版本、HumanEval/MBPP/ComplexCodeEval 任务版本、模型别名和 medium 推理档位。

2. 对每题保存 prompt、响应、编译/测试日志、生成代码行数和 tokens；不要只保存总分。

3. 用同一 SonarQube 版本和规则集分析三组输出，按文章的 kLOC/mLOC 单位计算密度。

4. 把 pass rate、missing completion、bug/vulnerability/smell 分开报告，并按严重级别展开。

5. 对并发、密码学和资源处理问题做人工抽样复核，确认静态规则命中是否构成真实缺陷。

来源摘录或观察（仅做合规短引）

作者对 Terra 的概括是 “Terra is the concise one”，但同一段数据同时显示其 cognitive complexity 和问题密度最高。