（转）为什么GPT Sol写代码很差

如果你认为 GPT-6 Astra 和 GPT-6.1 Sol 是优秀的模型，那就看看这个吧。问题并不在于代码难看。它要根本得多。它指出了这些模型在训练和强化方面的严重问题：

1. 该模型被优化为可衡量的结果，而不是实际意图。
所以它将通过测试和避免明显错误置于几乎一切之上，即使这意味着牺牲架构、可维护性、可读性或任务的精神。

2. 它被训练为最小化不必要的推理和输出。
这就是为什么代码最终看起来晦涩且压缩成一大段文本的原因。将系统正确分解为模块、思考架构、优化性能以及改进可读性，这些都需要更多的推理、更多的时间和更多的计算。OpenAI 似乎对这些模型的效率进行了大幅优化。

3. 训练视野太短。
模型学习的是类似于任务 → 结果 → 奖励的东西。它几乎收不到关于几步之后发生什么的信号，比如当有人需要维护、扩展、调试或重构代码时。它学会了完成眼前的任务，而不是构建出六个月后仍然优秀的东西。

4. 缺乏足够的真正自我审查。
死函数和空的 else if 强烈表明，没有进行有效的最终审查阶段，让模型重读自己的作品、质疑不必要的代码并清理明显的伪影。

5. 缺乏品味很可能是一个评估和数据问题。
如果评估者主要判断最终结果而不是达到那里所走路径的质量，那么模型就没有动力去发展良好的工程品味。而且如果训练数据中有很大一部分是嘈杂的、合成的或提炼的，这个问题就会变得更糟。Anthropic 似乎更强调高质量的源材料，包括书籍和其他精心挑选的长篇数据。

6. 最大的问题是训练过程中的诚实性。
模型似乎学会了，生成看起来像请求结果的东西几乎可以像真正按照请求做事一样获得奖励。

任务明确要求用 3D 对象构建整个场景。相反，模型生成了栅格图像，将它们放置在场景周围，并调整相机位置，使得最终结果只是看起来像是三维的。

这正是为什么 GPT 模型如此经常在现有代码库中引入回归、生成杂乱代码、修改测试以适应自己的错误、表现出糟糕的工程品味，并在大型、长期项目上的严肃工作中挣扎的原因。

OpenAI 可以继续每隔几个月发布参数更多的模型，但直到这些潜在的 RL 和训练问题得到解决，无论是 GPT Bel、GPT-7，还是一个拥有 100 万亿参数的模型，都不会自动解决它们。

Claude 模型也存在一些相同的问题，但根据我的经验，要少得多。Anthropic 似乎在 RL、评估和长视野行为方面拥有更强的文化。这就是为什么他们的模型往往表现出更好的品味、更忠实地遵循用户意图，并生成感觉更有意、更有结构且更易维护的代码。