1. 论文基本信息

1.1. 标题

利用大语言模型实现工业过程自动化：一个修改 RAPID 程序的案例研究 (Utilizing LLMs for Industrial Process Automation: A Case Study on Modifying RAPID Programs)

论文的核心主题是探索如何在工业过程自动化领域，特别是针对专有且小众的编程语言（如 ABB 机器人的 RAPID 语言），利用现有的大语言模型 (LLMs) 来辅助软件工程任务。研究聚焦于不经过昂贵的模型训练，仅通过提示工程 (prompt engineering) 来完成对已有代码的修改。

1.2. 作者

• Salim Fares: 德国帕绍大学 (University of Passau) 的研究人员。

• Steffen Herbold: 德国帕绍大学的研究人员。

  他们的隶属机构是德国的学术研究单位，这篇论文是他们与一家工业企业 AKE Technologies 合作的成果，体现了产学研结合的特点。

1.3. 发表期刊/会议

该论文目前作为一篇预印本 (preprint) 发布在 arXiv.org 上。arXiv 是一个开放获取的电子预印本平台，广泛用于物理学、数学、计算机科学等领域的研究人员在正式同行评审前分享其研究成果。虽然未经正式同行评审，但它是学术界快速交流最新进展的重要渠道。

1.4. 发表年份

根据元数据，论文发布于 2025 年 11 月 14 日。这表明它是一篇提前发布的预印本。

1.5. 摘要

近年来，关于如何将大语言模型 (LLMs) 用于软件工程的研究层出不穷，但大部分工作集中在广泛使用的通用编程语言上。LLMs 在工业过程自动化领域的应用，特别是那些在专有环境中使用的、高度专业化的语言，仍未得到充分探索。本文研究了企业如何在不投入大量精力训练特定领域语言模型的情况下，利用现有 LLMs。研究表明，对于一个 LLM 本来不支持的语言，少样本提示 (few-shot prompting) 的方法足以解决简单问题，并且这种方法可以在本地部署 (on-premise)，从而确保公司敏感数据的安全。

1.6. 原文链接

• 原文链接: https://arxiv.org/abs/2511.11125v1

• PDF 链接: https://arxiv.org/pdf/2511.11125v1.pdf

• 发布状态: 预印本 (Preprint)。

  ---

2. 整体概括

2.1. 研究背景与动机

• 核心问题: 当前大语言模型 (LLMs) 在软件工程领域的应用研究主要集中在 Python、Java 等拥有海量开源数据的通用编程语言 (General Purpose Programming Languages) 上。然而，在工业过程自动化 (industrial process automation) 领域，广泛使用的是领域特定语言 (Domain-Specific Languages, DSLs)，例如 ABB 机器人使用的 RAPID 语言。这些语言通常是专有的，公开代码稀少，导致通用 LLMs 对它们的支持非常有限。
• 研究空白 (Gap):
  1. 数据稀缺性: 像 RAPID 这样的语言，其代码通常是企业的商业机密，不会公开发布。这使得通过在大量数据上训练模型来支持这些语言变得非常困难。
  2. 成本与可行性: 像西门子、ABB 这样的大公司虽然可以开发自己的专用 LLM，但中小型企业 (SMEs) 难以承担训练或微调 (fine-tuning) 模型的巨大成本。
  3. 数据安全: 即便使用云端的商业 LLM 服务（如 GPT-4），企业也因担心泄露敏感的生产流程代码而犹豫不决。
• 创新切入点: 论文没有走“训练专用模型”的老路，而是探索了一条更具经济效益和现实意义的路径：一个中小型企业能否在不进行任何模型训练的情况下，仅通过巧妙的提示工程 (prompt engineering)，利用一个现有的、可本地部署的通用 LLM 来辅助其日常的编程任务？ 这项研究直接解决了中小企业在应用 AI 技术时面临的成本、数据和安全三重困境。

2.2. 核心贡献/主要发现

• 核心贡献:

  1. 可行性验证: 论文首次系统性地证明，仅通过少样本提示 (few-shot prompting)，一个通用的、未经 RAPID 语言专门训练的 LLM (Llama 3.1 70B) 就能在工业机器人编程语言 RAPID 上完成具体的代码修改任务，无需昂贵的模型再训练。
  2. 复杂度与性能关系分析: 通过对三种不同复杂度的任务（参数修改、添加指令、逻辑反转）进行评估，论文揭示了 LLM 在处理这类任务时的能力边界：对于简单的语法级替换，模型表现近乎完美；但随着任务涉及结构性修改和逻辑重写，错误率随之上升。
  3. 实用解决方案对比: 论文将 LLM 解决方案与传统的非 AI 自动化方案（如基于静态分析的规则引擎）进行了比较，分析了各自的优缺点，为企业技术选型提供了宝贵参考。

• 主要发现:

  1. 简单任务表现优异: 对于低复杂度的任务，如修改程序中的参数，LLM 的准确率接近 99%。这表明 LLM 在识别和替换代码模式方面非常可靠。

  2. 中等任务需多次尝试: 对于需要添加新代码行的中等复杂度任务，LLM 仍能达到约 91% 的高准确率，但这通常需要多次生成尝试并结合验证器来筛选出正确结果。

  3. 复杂任务挑战较大: 对于需要重写整个逻辑流的高复杂度任务（如反转运动程序），LLM 的准确率下降至 77%-83% 之间，表明其在深层逻辑推理方面能力有限。

  4. 提示语言的影响: 使用英语提示的效果普遍优于德语提示，尤其是在处理复杂任务时，这与现有研究结论一致。

  5. 本地化部署的价值: 整个方案可以基于一个可在本地服务器上运行的开源模型实现，完全打消了企业对数据泄露的顾虑。

     ---

3. 预备知识与相关工作

3.1. 基础概念

• 大语言模型 (Large Language Models, LLMs): 指的是在海量文本和代码数据上进行预训练 (pre-training) 的深度学习模型，如 GPT-4 或 Llama 3。它们能够理解和生成类似人类的语言，并被广泛应用于代码生成、问答、翻译等任务。
• 工业过程自动化 (Industrial Process Automation): 指利用控制系统（如计算机或机器人）来操作和控制工业流程和机械设备，以替代人力。这在制造业、装配线等领域非常普遍。
• 领域特定语言 (Domain-Specific Language, DSL): 是一种为解决特定领域问题而设计的计算机语言，与通用编程语言 (GPL) 相对。例如，SQL 是用于数据库查询的 DSL，而 RAPID 是专门用于控制 ABB 机器人的 DSL。
• RAPID 编程语言: 是由 ABB 公司开发的、用于控制其工业机器人的专有编程语言。它的语法和结构专为定义机器人运动、操作工具和处理 I/O 信号而设计。
• 可编程逻辑控制器 (Programmable Logic Controller, PLC): 一种坚固耐用的工业数字计算机，专门设计用于自动化控制，如装配线上的机器控制。论文中提到它是工业控制领域的另一个重要组成部分。
• 少样本提示 (Few-Shot Prompting): 这是一种与 LLM 交互的技术，即在向模型提出问题（即“提示”）时，不仅给出任务描述，还提供几个完整的“输入-输出”范例。这能帮助模型更好地理解任务要求和输出格式，而无需对模型本身进行任何参数更新或训练。
• 本地部署 (On-Premise Deployment): 指将软件或模型部署在组织自己的本地服务器和基础设施上，而不是使用第三方的云服务。对于处理敏感数据的企业来说，这是保障数据隐私和安全的关键措施。

3.2. 前人工作

论文回顾了将 LLM 应用于机器人和工业控制领域的几项关键工作：

• LLM4PLC [7]: 该工作使用 LLM 为 PLC 生成代码。与本文不同的是，它采用了用户引导的迭代流程，并使用了一种名为低秩自适应 (Low-Rank Adaptation, LoRA) 的微调技术来提升模型性能。这是一种需要额外训练成本的方法。
• Antero et al. [4]: 该研究提出了一种生成器-监督器 (generator-supervisor) 架构。一个 LLM（生成器）使用预定义的人类编写的软件模块来生成任务计划，另一个 LLM（监督器）负责审查和修正。这种方法更侧重于高层任务规划，而非直接生成底层的可执行代码。
• Morano-Okuno et al. [15]: 此工作结合了数字孪生 (digital twins) 和 AI 推理，让非专业用户在模拟环境中交互式地训练协作机器人。其重点在于简化人机交互和任务规划，完全不涉及生成代码。
• Instruct2Act [9]: 这项工作展示了 LLM 将自然语言指令转换为可执行的 Python 代码来控制机器人。这是一个重要的相关工作，但其核心区别在于：
  • 语言不同: Instruct2Act 生成的是通用的 Python 代码，而本文研究的是专有的、语法更严格的 RAPID 语言。
  • 生态不同: Python 拥有丰富的库和高级 API，而 RAPID 的编程环境和约束更为严格。

3.3. 技术演进

该领域的技术演进可以看作是从通用走向特定、从云端走向本地、从高成本走向低成本的过程：

1. 早期/通用阶段: 研究主要集中在利用 LLM 生成 Python 等通用语言的机器人控制代码，这些研究通常依赖于丰富的开源数据和库。
2. 专用/高成本阶段: 工业巨头（如西门子）开始开发针对其生态系统的专用 LLM，但这需要巨大的投入，并且同样面临客户数据难以获取的问题。
3. 务实/低成本阶段 (本文所在位置): 随着强大的开源 LLM (如 Llama 系列) 的出现，研究开始转向探索如何在不进行昂贵训练的前提下，通过轻量级技术（如提示工程）赋能中小型企业，解决其在特定、小众领域的编程需求，并确保数据安全。

3.4. 差异化分析

本文与相关工作的核心区别和创新点在于其高度的实用主义和针对性：

• 目标语言的特殊性: 聚焦于一个数据稀少、专有且在工业界广泛使用的 DSL (RAPID)，这正是大多数现有研究回避的难题。

• 方法的经济性: 坚持仅使用提示工程，不进行任何形式的模型微调或再训练。这为资源有限的中小型企业提供了一条极具吸引力的技术路径。

• 部署的安全性: 明确选择可在本地部署的开源模型，直接解决了工业领域最关心的数据隐私和商业机密保护问题。

• 问题的具体性: 研究的任务（修改参数、添加偏移、反转程序）非常具体，直接来源于合作企业的真实痛点，使得研究成果具有直接的应用价值。

  ---

4. 方法论

4.1. 方法原理

本文方法的核心思想是：利用一个大型的、通用的预训练语言模型（Llama 3.1 70B）所具备的强大模式识别、语言理解和上下文推理能力，通过在提示中提供清晰的规则和少量高质量的示例（即少样本提示），引导模型在它并不“精通”的 RAPID 语言上，完成高度结构化的代码修改任务。

这种方法的直觉是，尽管 LLM 可能没有见过大量 RAPID 代码，但它在预训练过程中学习了数百种编程语言的通用语法结构和逻辑范式（如过程定义、参数传递、指令序列等）。RAPID 语言虽然是专有的，但其结构与其他过程式语言（如 Pascal）有相似之处。因此，通过提供几个具体的“改造前”和“改造后”的例子，LLM 能够快速“领悟”出需要执行的转换规则，并将其泛化到新的代码片段上。

4.2. 核心方法详解 (逐层深入)

4.2.1. 模型选择

研究选择了 Llama 3.1 70B 模型。选择该模型主要基于以下考量：

• 强大的性能: 700 亿（70B）参数的规模使其具备了强大的语言建模和代码理解能力，这是成功处理复杂任务的基础。
• 可本地部署: 作为一个开源（权重公开）模型，企业可以将其下载并部署在自己的服务器上（例如，一台配备 A100 GPU 的服务器就足够进行推理）。这完美地解决了使用云服务可能导致敏感工业数据泄露的风险。
• 泛化潜力: 尽管 RAPID 不在主流的训练数据集中，但 Llama 3.1 接触过的广泛编程语言使其可能对 RAPID 这种结构化语言展现出一定的泛化能力。

4.2.2. 任务定义

为了系统性地评估 LLM 的能力，研究设计了三个复杂度递增的代码修改任务，这些任务均源于合作企业 AKE Technologies 的日常开发需求。

• 任务 1: 修改程序参数 (Modifying routine arguments) - 低复杂度

  • 描述: 更改一个已有程序中所有指令的某个特定参数。例如，将程序中所有的速度参数 $velocity_1$ 统一修改为 $velocity_2$。
  • 核心挑战: 本质上是模式识别和文本替换。模型需要准确找到所有目标参数并进行修改，同时保持程序的其他部分不变。

• 任务 2: 添加偏移指令 (Add an Offset instruction) - 中等复杂度

  • 描述: 在现有程序中的特定位置添加一条新的指令，该指令对某个位置坐标应用一个偏移量。
  • 核心挑战: 不仅是修改，还需要结构性地插入新代码。模型必须理解指令的正确插入位置、新指令的语法格式以及如何从用户提示和现有代码中获取新指令所需的参数。

• 任务 3: 反转程序 (Reversing a routine) - 高复杂度

  • 描述: 将一个给定的运动程序（如从位置 A 到 B）生成其逆过程（从位置 B 到 A）。
  • 核心挑战: 这是对程序逻辑的重写。模型需要：
    1. 反转所有指令的执行顺序。
    2. 修改程序的头部定义和注释，以反映新的起点和终点。
    3. 处理复杂的特殊逻辑，例如，根据 AKE Technologies 的规定，在某些情况下（如离开 HOME 位置）需要添加或删除特定的中间指令。这要求模型具备更深层次的逻辑推理能力。

4.2.3. 提示设计 (Prompt Engineering)

为每个任务都设计了精心构造的提示，由系统提示 (System Prompt) 和用户提示 (User Prompt) 两部分组成。

• 系统提示 (System Prompt):

  • 目的: 为 LLM 设定一个“专家”角色，并提供通用的、必须遵守的规则和编程指南。这些规则直接来自于合作企业 AKE Technologies 的编码规范。
  • 内容: 系统提示通常包含：

    1. 角色扮演: “你是一名机器人编程专家。”

    2. 输出格式约束: “只给出输出代码，不要任何额外的解释。”

    3. 语法和格式规则: 提供 RAPID 指令的正确格式，并附带一个例子。

    4. 特殊条件处理: 描述在特定条件下需要如何修改代码，例如当运动类型是 Machine_Tending 时，指令格式会有所不同。

    5. 少样本示例 ([EXAMPLES]): 提供一到两个完整的输入-输出对，向模型直观地展示如何完成任务。这是少样本提示的核心。

       下面是论文中给出的“修改参数”任务的系统提示片段（原文 Listing 3）：

  $$- You are an expert in robot programming. - Give only the OuTPut, no further explanations. - This is how to formulate a movement instruction: MoVement_TYPE TARGET_POSITION, VELOCITY, ZONE, TOOL\WObj:=WORK_OBJECT; EXAMPLE: MoveJ pR7_400,vR7_rapid,z50,toR7_active\WObj :=woR7_Base; - Do not add any additional instructions. - If the movement type is Machine_Tending, you must add Machine_Tending_ID as follows: Movement_TYPE ID,TARGET_POSITION, VELOCITY, ZONE, TOOL\WObj: = WORK_OBJECT; EXAMPLE: MT_MoveJ 400, pR7_400,vR7_rapid,z50, toR7_active\WObj: = woR7_Base; - The first movement instruction in a movement routine always has rapid velocity, active tool , and base wObj. [EXAMPLES]$$ 这里的 [EXAMPLES] 部分代表了具体的输入-输出示例，因数据敏感性未在论文中完全展示。

• 用户提示 (User Prompt):

  • 目的: 提供本次具体任务的输入数据和指令。
  • 内容:
    • 对于任务 1，用户提示包含原始的 RAPID 程序和要修改的内容，例如：“Use velocity velocity_2.”。
    • 对于任务 2，用户提示包含原始程序和添加偏移指令的具体要求。
    • 对于任务 3，用户提示包含需要被反转的原始 RAPID 程序。

4.2.4. 输出验证 (Output Validation)

这是该方法论中至关重要的一个环节，它确保了生成代码的质量，并为实验评估提供了客观标准。

• 目的: 自动检查 LLM 生成的代码是否正确，是否遵循了所有的编码规范。
• 实现: 开发了一个自定义的基于规则的验证器 (custom rule-based validator)。这个验证器是根据 AKE Technologies 的严格编码指南和开发人员的反馈构建的。
• 检查内容: 验证器可以检测多种错误，详细信息在论文的 Table 5 中列出。主要检查类别包括：
  • 任务特定错误:
    • 参数修改: 检查指定的参数是否被正确修改，以及其他部分是否未被错误地改动。
    • 添加偏移: 检查偏移指令是否已添加、位置是否正确、使用的函数（Offs() 或 RelTool()）是否正确。
    • 反转程序: 检查指令顺序是否反转、程序头是否更新、以及针对 HOME 位置的特殊逻辑是否被正确处理。
  • 通用错误 (适用于所有任务):

    • 结构完整性: 检查是否有指令被错误地添加或删除。

    • 标识符格式: 检查所有标识符（如变量名）是否符合公司的命名规范。

    • 默认值: 检查修改后的程序是否依然遵循某些默认值规则（如第一条指令的参数）。

      这个验证器不仅用于评估模型的准确率，在实际应用中，它还可以与 LLM 结合形成一个“生成-验证”循环：如果第一次生成的代码未通过验证，系统可以自动让 LLM 重新生成，直到产出正确的代码为止。

---

5. 实验设置

5.1. 数据集

• 数据来源: 实验数据直接来源于工业合作伙伴 AKE Technologies 的真实项目。具体来说，是 75 个已完成项目的 466 个项目备份文件。这种来自真实工业场景的数据极大地增强了研究的现实意义。

• 数据特点:

  • 模块化结构: 每个项目包含多个任务（对应不同的机械臂），每个任务由多个模块组成（如变量、函数、运动程序）。
  • 混合语言: RAPID 程序的关键字是英语，但代码中的注释是德语。这为实验提供了一个测试多语言提示效果的自然场景。
  • 标准化: 由于 AKE Technologies 实行标准化开发，许多程序（特别是简单运动程序）遵循一致的结构模式，这为数据提取和验证器开发提供了便利。

• 数据筛选与划分:

  • 研究人员从备份文件中提取了 18995 个程序，并将其分为简单运动程序 (simple movement routines) 和复杂运动程序 (complex movement routines)。
  • 本文重点分析简单运动程序，因为它们结构统一、数量众多，易于构建自动验证器。具体来说，研究聚焦于两个“通过位置 (Pre-Position)”之间的运动，共筛选出 1731 个此类程序样本。
  • 在这些样本中，11 个用作提示中的示例，其余 1720 个用于测试。

• 数据集样本示例:

  • 简单运动程序示例 (原文 Listing 1): 展示了从一个起点到一个终点的标准两步移动。

    PROC mvid1_id2()
    !From: Start Position
    !To: End Position
    MoveJ id1,positionl,velocity,zone,tool\wObj:=world_object\NoMove;
    MoveJ id2,position2,velocity,zone,tool\wObj:=world_object;
    ENDPROC
    

  • 复杂运动程序示例 (原文 Listing 2): 展示了一个包含多个位置和偏移操作的复杂路径。

    PROC special_case_routine()
    MoveJ Offs(position1,0,0,100), velocity, zone, tool;
    MoveL position1, velocity, zone, tool;
    Stop;
    MoveL Offs(position1,0,0,50), velocity, zone, tool;
    MoveJ Offs(position2,0,0,50), velocity, zone, tool;
    MoveL position2, velocity, zone, tool;
    Stop;
    MoveL Offs(position2,0,0,50), velocity, zone, tool;
    MoveJ Offs(position3,0,0,50), velocity, zone, tool;
    MoveL position3, velocity, zone, tool;
    Stop;
    MoveL Offs(position3,0,0,50), velocity, zone, tool;
    MoveJ Offs(position4,0,0,50), velocity, zone, tool;
    MoveL position4, velocity, zone, tool;
    ENDPROC
    

  • 任务输入输出示例 (原文 Table 2, 3, 4):

    • 任务1: 修改参数 (原文 Table 2)

      用户提示: "Use velocity velocity_2."
      Input	Output
      PROC mvid1_id2() !From: Start Position !To: End Position MoveJ id1,position1,velocity_1,zone,tool\WObj :=world_object\NoMove; MoveJ id2,position2,velocity_1,zone,tool\wObj :=world_object; ENDPROC	PROC mvid1_id2() !From: Start Position !To: End Position MoveJ id1,position1,velocity_2,zone,tool\wObj :=world_object\NoMove; MoveJ id2,position2,velocity_2,zone,tool\wObj :=world_object; ENDPROC

      * 任务2: 添加偏移 (原文 Table 3)

              <div class="table-wrapper"><table>
              <tr><td colspan="2">用户提示: "Addanintermediatemovement using Relative Tool after he start position, with 200 n theAxis" (原文此处有拼写错误)</td></tr>
              <tr><td><b>Input</b></td><td><b>Output</b></td></tr>
              <tr><td><pre><code>PROC mvid1_id2()
      

      !From: Start Position !To: End Position MoveJ id1,position1,velocity,zone,tool\wObj:=world_object\NoMove; MoveJ id2,position2,velocity,zone,tool\wObj:=world_object; ENDPROC

      PROC mvid1_id2()
      !From: Start Position
      !To:    End Position
      MoveJ id1,positionl,velocity,zone,tool\wObj:=world_object\NoMove;
      MoveJ id_intermediate,RelTool(position1,0,100,0=),velocity,zone,tool\wObj:=world_object\NoMove;
      MoveJ id2,position2,velocity,zone,tool\wObj:=world_object;
      ENDPROC

      * 任务3: 反转程序 (原文 Table 4)

              <div class="table-wrapper"><table>
              <tr><td><b>Input</b></td><td><b>Output</b></td></tr>
              <tr><td><pre><code>PROC mvidf1_idf2()
      

      !From: Start Position !To: End Position MoveJ id1,position1,velocity,zone,tool\wObj:= world_object\NoMove; MoveJ id2,position2,velocity,zone,tool\wObj:= world_object; ENDPROC

      PROC mvid2_id1()
      !From: End Position
      !To: Start Position
      MoveJ id2,position2,velocity,zone,tool\wObj:= world_object\NoMove;
      MoveJ id1,position1,velocity,zone,tool\wObj:= world_object;
      ENDPROC

      5.2. 评估指标

      论文使用了两个自定义的指标来衡量模型性能，这两个指标都考虑了 LLM 输出的随机性。实验中，对于每一个输入样本，模型都会生成 10 次输出。

      1. 成功率 (SuccessRate(i))

         • 概念定义 (Conceptual Definition): 该指标衡量对于单个输入样本 $i$，在 $k$ 次（本文中 $k$=10）生成尝试中，有多少次产出了完全正确的、能通过验证器的输出。它反映了模型在单次尝试中生成正确代码的可靠性。成功率为 100% 意味着模型每次都能给出正确答案，而 0% 则意味着 10 次尝试全部失败。
         • 数学公式 (Mathematical Formula): $$\mathrm{SuccessRate}(i) = \frac{|\text{Correct outputs for input } i|}{|\text{All outputs for input } i|} \times 100\%$$
         • 符号解释 (Symbol Explanation):
           • $i$: 特定的一个输入样本。
           • $|\text{Correct outputs for input } i|$: 针对输入 $i$ 生成的并通过验证器的输出数量。
           • $|\text{All outputs for input } i|$: 针对输入 $i$ 生成的总输出数量（在这里是 10）。

      2. 准确率 (Accuracy)

         • 概念定义 (Conceptual Definition): 该指标衡量在所有测试样本中，有多大比例的样本至少有一次生成了正确的输出。这个指标非常实用，因为它模拟了一个“重试”场景：只要在有限次尝试内（本文为 10 次）能得到一个正确结果，这个任务就被认为是“成功解决”了。它评估的是模型解决问题的最终能力，而非单次尝试的稳定性。
         • 数学公式 (Mathematical Formula): $$\mathrm{Accuracy} = \frac{|\{i \in \mathrm{Inputs} | \mathrm{SuccessRate}(i) > 0\}|}{|\mathrm{Inputs}|} \times 100\%$$
         • 符号解释 (Symbol Explanation):
           • $\mathrm{Inputs}$: 所有测试输入样本的集合。
           • $|\{i \in \mathrm{Inputs} | \mathrm{SuccessRate}(i) > 0\}|$: 成功率大于 0 的输入样本的数量，即至少成功生成一次正确输出的样本数量。
           • $|\mathrm{Inputs}|$: 测试输入样本的总数。

      5.3. 对比基线

      本文没有设置传统的模型作为基线 (Baselines) 进行直接比较。其核心对比在于：

      • 不同提示语言的对比: 实验的主要比较维度是使用英语提示与德语提示时的性能差异。考虑到代码本身是英语关键字和德语注释的混合体，这是一个非常有意义的对比。

      • 不同任务复杂度的对比: 通过比较模型在三个不同复杂度任务上的表现，自身形成了一种内部的、梯度性的评估。

      • 与非 AI 方法的 conceptual 对比: 在讨论部分，论文将 LLM 方法与一个概念上的基线——基于静态代码分析的规则引擎——进行了深入的优劣势分析，但这并未在实验中进行量化比较。

        ---

      6. 实验结果与分析

      6.1. 核心结果分析

      实验结果清晰地展示了 LLM 在处理这种专有语言代码修改任务时的能力和局限。

      • 任务复杂度是决定性能的关键因素:

        • 在参数修改（低复杂度）任务上，模型表现出色，使用德语和英语提示的准确率 (Accuracy) 分别高达 99.71% 和 99.36%。这说明对于简单的模式匹配和替换任务，LLM 非常可靠。
        • 在添加偏移指令（中等复杂度）任务上，准确率有所下降，但依然维持在 91.86% (德语) 和 91.97% (英语) 的高水平。这表明即使需要进行结构性修改，只要规则清晰，LLM 在多次尝试后大概率能成功。
        • 在反转程序（高复杂度）任务上，性能出现明显下滑，准确率降至 77.27% (德语) 和 83.72% (英语)。这说明当任务涉及深层逻辑重写和处理复杂特例时，LLM 的能力会受到限制。

      • 英语提示优于德语提示:

        • 虽然在简单和中等复杂度的任务上，两种语言的提示效果相差无几，但在最复杂的反转程序任务上，英语提示的准确率（83.72%）显著高于德语提示（77.27%）。
        • 从 Figure 2 的成功率分布来看，使用英语提示时，模型能为更多比例的样本达到 100% 的成功率（即一次性或非常稳定地成功），尤其是在中等和高复杂度任务上。这印证了现有研究的普遍结论：即便是多语言 LLM，使用英语作为指令语言通常能获得最佳性能。

      • 多次尝试和验证器的必要性:

        • Figure 2 的结果极具启发性。例如，在“添加偏移”任务中（使用英语提示），只有约 40% 的输入样本达到了 100% 的成功率（即 10 次尝试全对）。然而，总准确率却高达 92%。这说明有超过 50% 的成功案例是依赖于多次尝试才成功的。
        • 这强调了在实际应用中，一个“LLM 生成 + 规则验证器”的闭环系统是必不可少的。单靠 LLM 的单次输出是不可靠的，但通过多次生成并用验证器过滤，可以极大地提高最终解决问题的成功率。

      6.2. 数据呈现 (表格)

      以下是原文 Table 6 的结果，展示了各项任务在不同语言提示下的最终准确率 (Accuracy)：

      Task	Accuracy
      	German prompts	English prompts
      Arguments Modification	99.71%	99.36%
      Adding an Offset	91.86%	91.97%
      Reversing	77.27%	83.72%

      6.3. 错误分析

      论文通过自定义的验证器对失败的案例进行了细致的错误分析，下图（原文 Figure 1）展示了在完全失败（成功率为0）的样本中检测到的主要错误类型。

      该图像是图表，展示了每个任务中通过定制验证器检测到的错误类型与数量，包括参数修改、添加偏移和反转操作中的各种错误。不同语言（德语与英语）的错误数量进行了比较。

      • 参数修改任务: 错误非常少。少数的错误发生在位置名称特别长的情况下，模型可能会错误地修改其他参数（如速度）以“匹配”长名称，这是一种过度泛化。

      • 添加偏移任务: 主要错误有两种：1) 错误地修改了原始指令中的某些参数；2) 在输出中添加了不必要的额外指令。这表明模型在进行结构性插入时，有时会难以精确地保持其余部分不变。

      • 反转程序任务: 主要错误集中在对 HOME 位置的特殊逻辑处理上。根据 AKE 的标准，离开 HOME 位置和返回 HOME 位置的程序逻辑是不同的（一个需要中间指令，一个不需要）。模型在处理这种不对称的、需要深层理解的规则时，表现出了明显的困难。这再次证明了 LLM 在处理纯语法转换时表现良好，但在需要更高层次的程序逻辑推理时能力有限。

        下图（原文 Figure 2）则直观对比了两种语言提示下的成功率分布，突显了英语在复杂任务上的优势以及多次尝试的价值。

        该图像是图表，展示了在三项任务中，德语和英语的成功率比较。任务包括参数修改（a）、添加偏移（b）和逆转（c），策略随成功率的变化而变化，整体表现显示在不同成功率下的计数分布。

      ---

      7. 总结与思考

      7.1. 结论总结

      这篇论文通过一个在真实工业环境中的案例研究，得出了清晰且具有实践指导意义的结论：

      1. RQ1: 通用 LLM 能否仅通过提示工程生成有效的 RAPID 代码？
         • 答案是肯定的。 研究表明，即使没有针对 RAPID 语言进行专门训练，一个大型通用 LLM（Llama 3.1 70B）也能够通过精心设计的少样本提示，成功地执行对 RAPID 代码的修改任务。
      2. RQ2: 模型能否遵守提示中提供的格式和编程指南？

         • 答案是“在很大程度上可以，但能力随任务复杂度下降”。 对于简单的规则和格式，模型能很好地遵守。但对于复杂的、涉及深层程序逻辑的规则（如反转程序中的特殊情况），模型的遵循能力会下降，导致错误率增加。

           核心意义: 本文最重要的贡献在于，它为广大中小型企业展示了一条在预算和技术能力有限的情况下，安全、低成本地利用前沿 AI 技术来提升软件开发效率的可行路径。它证明了“本地化部署的通用 LLM + 精巧的提示工程 + 自动验证器”这一组合拳，足以解决特定领域中一部分重复性高、复杂度可控的编程任务。

      7.2. 局限性与未来工作

      论文作者清醒地认识到了当前工作的局限性，并指明了未来的研究方向：

      • 局限性:

        • 泛化性有限: 研究结果仅在 RAPID 语言和三种特定任务上得到验证，能否推广到其他 DSL 或更复杂的编程任务尚不确定。
        • 缺乏效率评估: 论文验证了技术上的可行性，但并未衡量这种自动化方法是否真的比人工操作更有效率。开发者使用该工具所需的时间、LLM 生成和验证所需的时间等，都有待量化分析。
        • 编码规范依赖: 整个方法很大程度上依赖于合作企业严格的编码规范，这使得开发自动验证器成为可能。在编码风格混乱的环境中，该方法可能难以奏效。

      • 未来工作:

        • 集成与效率测量: 下一步计划将该自动化工具直接集成到 AKE Technologies 的开发流程中，并在真实场景下测量其对开发效率的实际影响。
        • 扩展应用场景: 作者设想了一个更宏大的应用场景——让 LLM 不仅处理代码，还能理解开发前期的生产计划表（通常是自然语言和表格的混合体）。通过分析这些计划，LLM 或许能自动识别出需要进行哪些代码修改，从而实现更高层次的自动化，这将是未来研究的重点。

      7.3. 个人启发与批判

      • 启发:

        1. 实用主义的胜利: 这篇论文是 AI 应用落地的一个绝佳范例。它没有追求最酷炫的技术或最高的 SOTA 分数，而是从一个真实、具体、甚至有些“枯燥”的工业问题出发，用最务实、最低成本的方案解决了它。这种解决实际问题的研究思路非常值得借鉴。
        2. “LLM + 验证器”的黄金组合: 论文清晰地表明，在严肃的应用场景（如工业控制），不能盲目信任 LLM 的单次输出。一个强大的验证器是保证系统可靠性的“安全网”，而 LLM 的多次生成能力则提供了足够的“候选解”。这个“生成-验证”的闭环模式在许多要求高精度的领域都具有推广价值。
        3. 静态分析与 LLM 的权衡: 论文中关于 LLM 与传统静态分析方法优劣的讨论非常深刻。LLM 的优势在于灵活性和对非标准“角落案例”的容错性，以及更低的工程实现门槛（写提示 vs. 写复杂的 AST 转换规则）；而静态分析的优势在于确定性和可靠性。这提醒我们在做技术选型时，需要根据具体场景的特点（如代码规范程度、任务复杂度、团队技术栈）来权衡。

      • 批判性思考:

        • “准确率”定义的乐观性: 论文将“10 次尝试中至少成功 1 次”定义为准确，这对于一个有人监督的辅助工具来说是合理的，但对于一个全自动流程来说，这个指标可能过于乐观。在实际应用中，多次失败的尝试会消耗计算资源和时间，其综合成本需要被更仔细地评估。
        • 对简单任务的过度设计？ 对于“修改参数”这类简单的任务，一个精心设计的正则表达式或者 IDE 的“查找-替换”功能可能已经足够高效且 100% 可靠。LLM 在此处的优势可能更多体现在它作为一种“统一解决方案”的潜力上，即用一套框架处理从简单到复杂的多种任务，而不是在单个简单任务上效率最高。
        • 真正的瓶颈在代码之外: 正如作者在未来工作中提到的，真正的效率提升可能来自于更高层次的自动化，即让 LLM 理解需求文档、生产计划等非代码信息。当前的工作可以看作是实现这一宏大目标的“第一块积木”，其本身对开发流程的颠覆性可能有限，但其探索意义重大。