《IEEE Software》：Getting Acquainted with Your LLMs: Are They Aware of Smelly Code?
编辑推荐：
生成式人工智能（AI）正成为软件开发的新角色，辅助人类进行设计、编码和评审。然而，大语言模型（LLM）也会犯错，且常表现得过于自信。本文聚焦于LLM在处理“代码异味”这一问题上的表现。受数据驱动方法和可观测软件工程理念启发，研究提供了补充证据与实践要点，帮助从业者更好地了解和运用其LLM。核心结论是：管理你的上下文，记录AI使用痕迹，并为LLM设计观测手段——因为软件质量很少不言自明。
在生成式人工智能（Generative AI）浪潮的推动下，大语言模型（Large Language Models, LLMs）正以前所未有的深度介入软件开发流程，扮演起“AI结对程序员”、“代码补全助手”乃至“自动评审员”的角色。它们承诺能提升开发效率，协助设计架构，甚至能发现代码中的潜在缺陷。然而，一个日益凸显的隐忧在于，这些“自信满满”的AI助手，其产出真的可靠吗？特别是在识别那些预示着更深层次设计问题，但代码本身仍能运行的“代码异味”（Code Smells）时，LLMs的表现究竟如何？它们是真知灼见，还是盲目自信？这正是《IEEE Software》上发表的这项研究所要深入探究的核心问题。
当前，尽管LLMs在代码生成任务上展现了强大能力，但其“幻觉”问题、对上下文理解的局限性，以及输出结果难以追溯和验证的特性，给其在关键软件开发场景中的应用蒙上了阴影。研究指出，LLMs不仅会犯错，而且常常是“自信地犯错”，这可能导致开发者引入隐藏的缺陷或不良设计。因此，仅仅评估LLMs生成代码的正确性已远远不够，更需要评估它们对软件质量，尤其是那些微妙质量属性的理解和诊断能力。本研究正是从“代码异味”这一经典的质量信号切入，旨在通过系统性的实证考察，揭示LLMs在理解复杂软件工程概念时的真实能力边界，从而为“如何更安全、更有效地在开发流程中集成AI”这一迫切问题提供证据。
为回答上述问题，研究人员并未采用传统的基准测试，而是受“数据驱动”与“可观测软件工程”理念的启发，设计了一套贴近真实开发场景的考察方法。研究的关键技术方法主要包括：1) 构建涵盖多种经典代码异味（如Long Method, God Class等）的代码场景作为评估基础；2) 设计特定的提示（Prompts）来引导LLMs执行代码审查和异味识别任务；3) 系统性地记录和分析LLM的完整交互过程与输出轨迹，而不仅仅是最终答案的正确性；4) 通过设计可控的上下文（Context）变化，观察LLM判断的一致性与稳定性。这些方法的核心在于，不仅仅将LLM视为一个黑盒，而是试图通过工程化的观测手段，使其决策过程变得部分可追溯、可分析。
研究结果
LLMs对代码异味的识别能力参差不齐
研究通过设置不同的代码示例和提示词，测试了多个LLM对常见代码异味的识别情况。结果表明，LLMs在某些明显的异味模式上表现尚可，但在处理需要深层设计逻辑理解或上下文依赖的复杂异味时，准确率显著下降。更重要的是，模型经常对错误的判断表现出高置信度，这比单纯的错误更具误导性。
上下文管理是影响LLM表现的关键变量
研究人员通过精心操控输入给模型的上下文信息（如 surrounding code, 注释说明等），发现LLM的输出对上下文极其敏感。微小的上下文变动可能导致模型对同一段代码是否“有异味”给出截然相反的结论。这揭示了当前基于LLM的辅助工具一个重大风险：其判断缺乏稳定性，严重依赖于开发者提供的、可能并不完整的上下文片段。
AI使用痕迹的缺失使问题难以追溯与复盘
在常规使用中，开发者与LLM的交互往往是一次性的、无记录的。研究强调，这种交互“痕迹”的缺失使得当出现问题代码时，开发者难以复盘AI当初的决策依据，也无法对模型进行有效的反馈训练。研究通过模拟案例展示了记录完整交互链（包括初始提示、模型中间输出、最终决策）对于后续分析和问责的重要性。
“为观察而设计”是有效运用LLM的必要理念
基于上述发现，研究提出了核心建议：要想可靠地使用LLM进行代码质量评估，必须主动“为观察而设计”。这意味着不能被动接受模型的输出，而应通过工程化手段，如设计结构化提示、强制模型输出推理链、在流水线中自动记录所有AI交互日志等，主动创造可观测性，使LLM的“思考”过程变得更透明。
结论与讨论
本研究的结论清晰而具有实践意义：当前的大语言模型并非可靠的“代码异味嗅觉专家”。它们在该任务上的能力是有限且不稳定的，严重受制于上下文，并伴有自信幻觉。因此，盲目信任LLM的代码质量判断是危险的。
研究的意义远不止于指出问题，更在于为软件工程社区指明了应对路径。它倡导从“可观测软件工程”的视角来审视AI的集成。具体而言，首先，必须“管理你的上下文”，意识到提供给模型的上下文是决定其输出质量的关键输入，需要像管理代码依赖一样审慎管理。其次，务必“记录AI使用痕迹”，将这些交互日志作为软件开发过程资产的一部分，用于调试、审计和持续改进。最后，核心在于“为LLM设计观测”，即通过工具和流程创新，将LLM的黑盒行为转化为可分析、可监控的明盒组件。
这项研究最终提醒从业者：软件质量不会自我言说，而LLM的“断言”也需要被置于可观测、可验证的工程框架之下。在拥抱AI生产力的同时，构建对其输出进行系统性观察、质疑和验证的能力，是将AI转化为可靠工程伙伴的必由之路。论文为如何在软件开发中负责任且有效地利用生成式AI提供了重要的实证补充和切实可行的工程实践指导。
