LLM-Based Static Verification of Code Against Natural-Language Requirements: An Industrial Experience Report
本文报告了一项工业实践经验，介绍了一种基于大语言模型的两阶段工作流，该工作流从自然语言需求中提取可验证规则，并据此对代码进行审计，以在智能汽车网络安全领域静态验证实现正确性，从而在不依赖运行时执行的情况下，解决了传统静态分析的局限性和测试预言问题。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在建造一辆高科技汽车，手中有一本用通俗英语写成的庞大说明书，明确告知工程师汽车的安全系统应如何运作。问题在于，工程师依据这些说明编写实际的计算机代码，而有时，即使代码本身看起来完美无缺，他们却可能误解了其中的含义。
本文介绍了一种新方法，利用一种称为大型语言模型（LLM）的特殊人工智能（AI），在汽车尚未建造之前就能捕捉到这些“含义错误”。
以下是该流程的分解步骤：
问题： “错误的数学”错误
将标准代码检查器（如 Coverity 或 SonarQube）想象成计算机代码的拼写检查器。它非常擅长发现拼写错误、缺失的逗号或危险的安全漏洞。但它无法判断你是否写错了整个故事。
类比：想象一份食谱写着：“制作蛋糕时，你必须将鸡蛋乘以面粉。”如果厨师不小心编写了将鸡蛋和面粉相加的代码，拼写检查器将无法发现。语法完美无缺，食材也安全，但蛋糕将会是一场灾难。本文旨在发现软件逻辑中的这类“错误的数学”错误。
解决方案：两步式 AI 侦探团队
与其让一个庞大的 AI 一次性阅读整本手册并检查所有代码（这可能导致混淆或“幻觉”），作者创建了一个两步走的团队。
第一步：“规则挖掘者”（翻译者）
首先，一个 AI 代理阅读自然语言需求（即手册）。它的角色是充当一位严格的编辑。
- 它做什么：它将模糊的英语句子转化为严格的“可验证规则”列表。
- 关键点：如果手册中的内容令人困惑、自相矛盾或无法检查（例如，要求“使密码变强”却未定义“强”的含义），该 AI 不会猜测。相反，它会将其标记为“问题备注”。
- 比喻：将此 AI 想象为一位拒绝翻译毫无意义句子的翻译员。他们不会编造含义，而是在页边写下备注：“翻译员注：此句自相矛盾。请澄清。”
- 技巧：为确保 AI 的一致性，研究人员在不同设置下多次运行它，并合并结果，以确保不遗漏任何规则。
第二步：“代码审计员”（检查员）
一旦规则被清理完毕，第二个 AI 代理便会检查实际的计算机代码。
- 它做什么：它检查代码是否遵循第一步中创建的严格规则列表。它不仅仅寻找关键词，而是审视逻辑。
- 比喻：这就像一位建筑检查员，检查房屋是否按照蓝图建造。如果蓝图规定“门必须向内开”，而代码构建的门却向外开，即使门是由优质木材制成，检查员也能发现这一问题。
- 结果：它会生成一份报告，指出“此部分代码符合规则”或“此部分违反规则”。
他们的发现（案例研究）
该团队在一个真实世界的项目中测试了此方法：汽车 Wi-Fi 的安全系统。
- 在手册方面：他们发现原始需求中存在隐藏的矛盾。例如，一条规则要求密码包含特定字符，但给出的示例却不包含这些字符。AI 立即发现了这一矛盾，而人类则超过一年未能察觉。
- 在代码方面：他们在代码中发现了一个高优先级的漏洞，系统根据错误的条件关闭了 Wi-Fi 热点（它检查的是设备是否空闲，而规则要求检查的是整个系统是否空闲）。
- 成功率：他们能够利用此方法验证超过**50%**的需求。这些通常是必须运行软件并测试数天才能发现的问题。而该方法仅通过阅读文本和代码就发现了它们。
为何这很重要
- 左移：它将“检查”阶段移至项目的最开端（在时间轴上“左移”）。你无需编译代码或运行汽车即可发现这些错误。
- “预言机”问题：在测试中，“预言机”是指一种判断结果是否正确的方法。通常，很难知道正确的答案应该是什么。此 AI 通过推理需求的意图而非仅仅关注输出，充当了一个智能的预言机。
- 并非替代：作者明确表示：这不会取代人工测试。它是一个辅助工具，能够捕捉标准工具遗漏的棘手逻辑错误，从而节省时间和金钱。
简而言之：本文表明，通过利用 AI 先将模糊的指令转化为严格的规则，再根据这些规则检查代码，我们可以比以往更早、更有效地捕捉软件中的“逻辑错误”。这就像拥有一位超级聪明的编辑和一位超级聪明的检查员协同工作，确保故事与剧本相符。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。