人工智能在软件开发中扮演重要角色，但需谨慎使用。应采取“信任并验证”的方法，评估代码的安全性、可靠性和可维护性。不同模型有不同“编码个性”，需理解其弱点。模型越强大，风险可能越高。需审查和分析每一段代码，确保安全和质量。
译自：AI Code Generation: Trust and Verify, Always
作者：Prasenjit A. Sarkar
我们正处于软件开发新时代的开端。人工智能不再仅仅是一个工具；它正在成为编写代码的创造性过程中的真正协作者。这种转变有望释放前所未有的生产力和创新。然而，像任何强大的新工具一样，这种人工智能协作者需要一种新的管理理念。为了真正发挥其潜力，而不继承其缺陷，我们必须采取一项严格的原则：信任并验证。
这并非为了扼杀创新，而是为了负责任地促成创新。随着我们将人工智能更深入地整合到软件开发生命周期中，我们必须超越令人印象深刻的基准分数，直接评估其产生的代码的安全性、可靠性和可维护性。
超越“它能用吗？”
大型语言模型 (LLM) 最直接的吸引力在于它们生成功能正确的代码的惊人能力。顶级模型可以解决复杂的算法问题，并以高成功率生成符合语法的有效代码。这种熟练程度正在推动它们的快速采用。但是对于任何专业的开发团队来说，关键问题不仅仅是“它能用吗？”，而是“它是否已准备好投入生产？”
在这里，热情必须以谨慎来缓和。虽然 LLM 擅长解决封闭的问题，但它们通常缺乏对大局的把握，从而导致严重的隐藏风险。
最紧迫的问题之一是安全性。事实上，Sonar 的一项新研究分析了来自 OpenAI、Anthropic 和 Meta 等提供商的知名模型生成的人工智能代码，结果表明，当今的 LLM 在这方面存在严重的盲点。例如，对于像 GPT-4o 和 Llama 3.2 90B 这样的领先 LLM，我们发现它们引入的安全漏洞中，高达 60% 到 70% 都是“BLOCKER”严重级别（可能的最高评级）。这不是偶尔出错的问题，而是根植于其基础设计和训练的结构性弱点。
同样关键的是代码库的长期健康状况。人工智能模型天生倾向于产生“混乱”的代码，从而造成技术债务。我们的研究还表明，在所有评估的模型中，代码异味占发现的所有问题的 90% 以上。虽然代码今天可能可以运行，但这种结构性问题的积累将不可避免地导致代码库难以维护且维护成本高昂。
单一人工智能的神话
将“人工智能”视为一个单一实体是错误的。正如每个人类开发人员都有独特的风格一样，不同的 LLM 也具有独特的“编码个性”。理解这些细微差别是有效使用它们的关键。
例如，我们的分析确定了明确的原型。一种模型，“高级架构师”（Claude Sonnet 4），编写冗长、复杂、企业级的代码。但这种复杂性是有代价的：它很容易引入难以诊断的错误，例如资源管理泄漏和并发问题。相比之下，“快速原型设计师”（OpenCoder-8B）非常简洁，以最少的代码获得功能性结果。缺点是什么？它会造成相当数量的技术债务，表现出我们测试过的所有模型中最高的问题密度，并将项目埋在长期的可维护性问题中。
选择模型不仅仅是选择基准分数最高的模型。而是要理解其固有的风格，并弥补其特定的弱点。
进步的悖论：越智能可能意味着风险越高
对于该领域的任何领导者来说，也许最关键的见解是一个违反直觉的悖论：随着模型变得越来越强大，它们也可能变得更加鲁莽。允许较新的模型解决更复杂问题的雄心壮志可能会导致它产生更严重的失败。
当我们将一个模型与其直接后继者进行比较时，我们清楚地看到了这一点。虽然较新模型的基准性能提高了 6.3%，但它也使高危漏洞增加了 93%。这一个数据点有力地反驳了仅仅依赖性能分数的观点。一个在纸面上看起来“更好”的模型可能会给你的应用程序带来更高的风险。
智能监督的新要求
软件开发的未来是人机协作的未来。为了使这种伙伴关系取得成功，我们必须采取“信任并验证”的方法。这意味着实施一个一致的审查和分析每一段代码的流程，无论其来源如何。它规定，强大的安全性、可靠性和可维护性治理不是建议，而是要求。
在“氛围编程”时代尤其如此，其目标是快速获得功能原型。我们的研究表明，在最初的“氛围”之后，必须采取严格的“验证”步骤，以管理这些模型可能产生的重大安全障碍和技术债务。这种验证不是瓶颈；它是将有希望的原型转化为可用于生产的软件的过程。
通过扩展我们对性能的看法，并致力于更深层次的验证，我们可以负责任地利用人工智能的强大力量。这就是我们将构建下一代软件的方式。不仅更快，而且更好、更安全、更具弹性。
