AI编写软件的质量究竟如何？一位开发者的经验

AI驱动的编程智能体提升了许多开发者的生产力。但这些智能体生成的代码质量高吗？

有人说这并不重要，我们正走向源代码永不接受检查的“黑暗软件工厂”，也许我们应该彻底消除源代码——“源代码是新的汇编代码”。

另一些人持不同观点。人类有时需要调试源代码。源代码可能需要由人类审计以符合合规要求。代码应当足够清晰，让人类能够检查并推理其中的算法和行为。此外，良好的代码质量可以让代码对智能体更易读，并减少不必要的上下文。

对于什么是高质量软件和良好的编码风格，开发团队可能有很多不同的想法。虽然编写代码有许多有效的方式，但对于代码质量的一般原则也存在广泛共识。例如，避免过大的单一函数或模块、避免代码重复、避免无节制的功能蔓延或拼凑式代码，以及避免过深的类层次结构或函数调用链。某些编码风格选择对开发者生产力的影响可以通过实证检验。此外，一些代码复杂度指标可以被客观地、以编程方式计算。

我的经验来自GPT 5.5（Extra High推理）和5.6（Extra High、Max，偶尔用Ultra）。我的大部分经验是对Codex的“开箱即用”使用，配合简单的AGENTS.md文件，不过我正在改进指导文件的工程化，这确实有帮助。我的源代码主要是Python。遗憾的是，很难将任何一组经验普遍推广，因为开发者有不同的代码库、语言、模型、工具链和AGENTS.md文件。一次性生成一个简单的电脑游戏或网站，与在一个新领域开发复杂的研究代码是完全不同的。

乍一看，AI编写的代码并非难以理解。它不会使用“iiii”或“a87275”这样奇怪的变量名，看起来也不像出自混淆代码竞赛。但根据我的经验，生成的代码仍然存在缺陷：

• 智能体倾向于编写远超必要的代码量（通常是2-3倍——另见此处的相关发现）。虽然它能够删除代码，但它的主要冲动似乎是编写更多代码。

• 你可以与智能体一起缩短代码，但这需要费一番功夫。智能体似乎并不擅长找到结构上的简化方案并提取共性。在一次会话中，我花了半小时让智能体编写几百行代码，然后花了4小时让它缩短和简化这些代码。你可以想象这会积累什么样的技术债务。

• 它表现得好像代码简化远比代码生成更难企及。有时它完全无法完成我要求的一些简化任务。

• 它没有在何时将文件拆分为多个文件以获得概念清晰度的直觉，即使文件超过10,000行也是如此。

• 它会在不同的代码模块中重新发明一个相似但略有不同的辅助函数，而不是一次性设计一个简单的可复用函数。

• 它会构造包含10-20个参数的庞大函数参数列表，而不是意识到这些参数可能构成一个连贯的概念，可以用抽象或参数对象来表示。

• 重要的是，它会基于不能很好建模底层领域的抽象来定义函数，这些函数难以解读。当我指出这一点时，它说：“你说得对。代码是在命名实现机制而不是陈述意图……它迫使读者在脑中执行好几层基础设施，才能发现它想表达什么。”

• 它经常发明读者无法立即理解的术语（源代码版的Don't Make Me Think）。

• 它会多次重复同一个表达式，而不是定义一个有意义名称的变量来表示该数量。

• 它会将无法解释的“魔法常量”硬编码到代码中，而不是用有意义的名称来定义它们。

事实上，在被施加压力时，这些模型有时能够做得更好。例如，对于一个困难的设计问题，当我要求5.6 Ultra认真审视问题时，它能够创建出与问题领域很好匹配的优秀对象设计——比不太复杂的模型更好。

我当然期望，通过对智能体指导文件进行更多工程化，这些问题的许多或大部分会得到改善。然而，让编码智能体写出好代码不应该需要极端措施。

我没有比较过其他编码智能体，但如果它们有类似问题，我也不会感到惊讶。理所当然地，编码模型已被优化以提升其软件开发实用性，而这无疑以革命性的方式取得了成功。

似乎还没有一个被广泛接受的代码质量基准，能够像SWE-bench在软件工程能力方面那样为前沿编码模型扮演同样的角色（尽管已有一些努力）。这尤其有趣，因为代码质量的许多方面是可验证的，使得这个问题似乎非常适合在后训练阶段处理。我希望有人能为这个问题构建一个好的基准，也希望前沿实验室能在模型开发中采纳这类评估。