CangjieBench: Benchmarking LLMs on a Low-Resource General-Purpose Programming Language

本文提出了针对低资源通用编程语言 Cangjie 的无污染基准测试 CangjieBench，通过系统评估多种 LLM 在四种生成模式下的表现，揭示了直接生成效果不佳、语法约束生成性价比最高以及代码到代码翻译存在负迁移等现象。

要点

这篇论文讲述了一个关于**“教大模型学一门新语言”**的有趣故事。

想象一下，现在的 AI（大语言模型）就像是一个精通几十种古老语言的超级翻译官。它精通英语（Python）、法语（C++）等“热门语言”，因为全世界有海量的书籍和资料供它学习。

但是，突然有一天，华为推出了一门全新的编程语言叫**“仓颉”（Cangjie）。这门语言非常现代、强大，专为未来的智能设备设计，但因为太新了，世界上几乎没有现成的教材、代码库或书籍。这就好比让那位超级翻译官去学一门只有几个人会说的、刚发明出来的“外星语”**。

这篇论文就是为了解决这个难题而诞生的。

1. 他们做了什么？（CANGJIEBENCH 基准测试）

为了测试这些 AI 到底能不能学会这门“外星语”，作者们没有去网上乱抓代码（因为网上根本没有），而是想了一个聪明的办法：

• 人工翻译法：他们找来了 AI 已经非常擅长的两道经典编程考题（HumanEval 和 ClassEval，就像小学和中学的数学题），然后人工把这些题目从 Python（热门语言）“翻译”成了仓颉语（冷门语言）。
• 零污染：因为是人类手写的，AI 以前绝对没在训练数据里见过，所以这能真实地测出 AI 是“真的学会了”还是“死记硬背”。
• 双重任务：
  1. 听写（Text-to-Code）：给 AI 一个自然语言描述（比如“写个函数算加法”），看它能不能写出仓颉代码。
  2. 翻译（Code-to-Code）：给 AI 一段 Python 代码，让它直接翻译成仓颉代码。

2. 他们怎么教 AI？（四种策略大比拼）

既然 AI 没学过这门语言，作者们尝试了四种不同的“教学策略”来看看哪种最有效：

• 策略一：直接硬考（Direct Generation）

  • 比喻：把 AI 扔进考场，只给题目，没有任何提示。
  • 结果：惨败。AI 就像个完全不懂外语的人，写出来的代码全是语法错误，连编译器都跑不通。

• 策略二：发小抄（Syntax-Constrained Generation）

  • 比喻：给 AI 一张**“仓颉语速查小抄”**（语法速成表），告诉它：“注意！这里要用 Int64 而不是 int，这里要用 String 而不是 str"。
  • 结果：效果惊艳！ AI 的得分瞬间从 4% 飙升到 50% 以上。这说明 AI 其实逻辑能力很强（知道怎么解题），只是不懂语法格式。只要给点提示，它就能立刻上手。而且这种方法最省钱（消耗的计算资源最少）。

• 策略三：查资料（RAG - 检索增强生成）

  • 比喻：允许 AI 在考试时去查“仓颉语字典”或“官方文档”。
  • 结果：比直接硬考好，但不如“发小抄”好用。因为 AI 有时候不知道查什么关键词，或者查回来的资料太碎，它反而被搞晕了。

• 策略四：派个助手（Agent - 智能体）

  • 比喻：给 AI 配了一个**“私人导师”**。AI 可以主动去查文档、运行代码、发现错误、再查文档、再修改……像人类程序员一样反复折腾。
  • 结果：准确率最高（接近 80%），但代价巨大。它消耗的计算资源是“发小抄”方法的几百倍，就像为了做一道菜，请了个厨师团队还开了个宴会，虽然菜好吃，但太贵了，不实用。

3. 一个意想不到的发现

作者发现了一个有趣的现象：“直接翻译”反而比“听写”更难。

• 比喻：如果你让 AI 看着 Python 代码去写仓颉代码（翻译），它反而容易犯错。
• 原因：AI 太依赖原来的 Python 习惯了。它就像个顽固的翻译官，看到 Python 的写法，就忍不住把仓颉语也写成 Python 的样子（比如动态类型写成了静态类型），导致“负迁移”（越帮越忙）。
• 启示：有时候，忘掉旧语言，直接根据新语言的规则去构思，反而比死板地翻译旧代码更准确。

4. 总结与意义

这篇论文告诉我们：

1. AI 很聪明，但需要“脚手架”：对于全新的编程语言，AI 不需要重新训练（那太贵太慢），只需要给它简洁的语法规则（小抄），它就能迅速掌握。
2. 性价比之王：在“发小抄”和“派助手”之间，**“发小抄”**是性价比最高的方案。既准又快，还省钱。
3. 未来的方向：随着更多新语言（如未来的 AI 专用语言）出现，我们不需要每次都重新训练大模型，而是应该研究如何自动提取并注入这些语言的“核心规则”，让 AI 瞬间学会任何新语言。

一句话总结：
这就好比教一个天才学生学一门刚发明的语言，直接让他死记硬背（直接生成）不行，给他一本厚厚的字典查（RAG）太慢，让他反复试错（Agent）太贵，但如果你给他一张“核心语法速查表”（Syntax-Constrained），他就能立刻成为这门语言的大师！

技术摘要

CANGJIEBENCH 论文技术总结

1. 研究背景与问题定义 (Problem)

背景：
大型语言模型（LLM）在 Python、C++ 等高资源编程语言上表现卓越，但在低资源通用编程语言（Low-Resource General-Purpose Languages）上面临巨大挑战。现有的低资源语言研究多集中于领域特定语言（DSL，如 Verilog、Solidity），这些语言往往与特定领域知识（如硬件逻辑、区块链）强耦合，难以区分模型失败是源于缺乏语法知识还是领域知识。

核心问题：

1. 数据稀缺与泛化能力： 像华为推出的 Cangjie（鸿蒙生态核心语言）这样的现代通用语言，由于发布较晚（2025 年 7 月），缺乏大规模公开语料，导致 LLM 难以生成有效代码。
2. 现有基准的局限性： 缺乏针对低资源通用语言的无污染基准测试。现有基准要么存在数据泄露风险（爬虫获取的旧数据），要么局限于 DSL。
3. 迁移学习挑战： 从“高资源语言”（如 Python）向“低资源语言”（如 Cangjie）进行代码翻译（Code-to-Code）时，模型是否会出现负迁移（Negative Transfer），即过度拟合源语言模式而忽略目标语言语法。

2. 方法论 (Methodology)

2.1 数据集构建：CANGJIEBENCH

为了填补空白，作者构建了 CANGJIEBENCH，这是首个针对 Cangjie 语言的无污染基准测试。

• 构建策略： 采用人工翻译策略，将广泛使用的 Python 基准 HumanEval（函数级）和 ClassEval（类级）翻译为 Cangjie。
• 数据规模： 共包含 248 个高质量样本（164 个来自 HumanEval，84 个来自 ClassEval）。
• 构建原则：
  • 类型适配： 将 Python 基础类型（int, float, str）映射为 Cangjie 对应类型（Int64, Float64, String）。
  • 算法一致性： 严格保留原算法逻辑流。
  • 依赖管理： 剔除依赖第三方库（如 sqlite3, PIL）且 Cangjie 无对应实现的题目，确保测试公平性。
  • 零污染： 由于是人工翻译而非爬虫，彻底避免了训练数据泄露，确保测试的是模型的泛化能力而非记忆能力。
• 任务类型：
  1. Text-to-Code： 根据自然语言描述生成 Cangjie 代码。
  2. Code-to-Code： 将 Python 代码翻译为 Cangjie 代码。

2.2 评估框架

• 环境： 基于 Docker 构建隔离的沙箱，集成 Cangjie 运行时、标准库和测试框架，确保自动化、安全的执行与验证。
• 评估指标： Pass@1（功能正确率）、Compile Rate（编译通过率）、Token 消耗量。

2.3 实验范式

研究对比了四种 LLM 适应新语言的范式（均不涉及微调）：

1. 直接生成 (Direct Generation)： 零样本（Zero-shot）提示，仅依赖预训练权重。
2. 语法约束生成 (Syntax-Constrained Generation)： 在 Prompt 中注入专家整理的精简 Cangjie 语法规则（20 类约束，约 2146 tokens），辅助模型进行上下文学习。
3. 检索增强生成 (RAG)：
   • RAG (Docs): 检索官方文档（通过查询转换优化检索词）。
   • RAG (Code): 检索爬取的 Cangjie 代码片段（基于 BM25）。
4. Agent (智能体)： 基于 CLI 的智能体，模拟开发者主动查阅文档、自我修正的迭代开发过程。

3. 关键贡献 (Key Contributions)

1. 首个 Cangjie 基准： 提出了 CANGJIEBENCH，通过人工翻译确保了数据的零污染和多样性（覆盖函数级到类级难度）。
2. 新研究视角： 将 Cangjie 定义为低资源通用语言，剥离了领域知识干扰，严格评估 LLM 学习新语法的能力。
3. 双重任务设计： 同时支持 Text-to-Code 和 Code-to-Code 任务，模拟了从零开发到迁移现有项目（如迁移至鸿蒙生态）的真实场景。
4. 系统性评估： 全面评估了从简单提示到复杂 Agent 的四种策略，为低资源语言适应提供了坚实的基线。

4. 实验结果 (Results)

4.1 总体性能

• 直接生成表现极差： 大多数模型（包括 GPT-5）的 Pass@1 低于 5%，且编译通过率极低。这表明模型缺乏 Cangjie 的语法知识，生成的代码大多无法通过编译。
• 语法约束效果显著： 注入语法规则后，性能大幅提升。例如，GPT-5 在 Text-to-Code 任务上的 Pass@1 从 4.3% 飙升至 53.8%。这证明 LLM 具备算法逻辑，瓶颈仅在于表层语法。
• Agent 达到 SOTA 但成本高： GPT-5 驱动的 Codex CLI Agent 在 Text-to-Code 上达到 77.6% 的 Pass@1，但 Token 消耗巨大（输入 Token 占比高达 99.1%），效率较低。
• RAG 表现中等： RAG 方法优于直接生成，但通常不如语法约束方法有效。RAG (Code) 难以从碎片化代码中泛化语法，RAG (Docs) 受限于模型生成低质量检索关键词的能力。

4.2 核心发现

1. 语法是主要障碍： 在低资源设置下，生成语法正确的代码比推导算法逻辑更难。
2. 负迁移现象 (Negative Transfer)： 在 Code-to-Code 任务中，模型表现往往不如 Text-to-Code 任务。
   • 原因： 模型在翻译时倾向于逐行模仿 Python 的动态类型和惯用写法，导致生成的 Cangjie 代码不符合其静态语法规范。
   • 数据： GPT-5 在 Syntax-Constrained 下，Text-to-Code 为 53.8%，而 Code-to-Code 降至 38.1%。
3. 性价比权衡： 语法约束生成在准确性和计算成本之间提供了最佳平衡（高准确率，低 Token 消耗）。Agent 虽然准确率最高，但成本过高，不适合大规模应用。

5. 意义与展望 (Significance)

• 理论意义： 揭示了 LLM 在低资源通用语言上的泛化边界，证明了上下文学习（In-Context Learning） 结合结构化语法提示是解决新语言适应问题的高效途径，无需昂贵的微调。
• 实践意义： 为鸿蒙生态（HarmonyOS）的开发者提供了评估工具，并提出了“语法约束优先，Agent 兜底”的实用策略。
• 未来方向：
  • 开发自动化提取和注入语法规则的方法。
  • 研究语义对齐的翻译方法，避免源语言语法的负迁移（例如先转换为中间表示再生成目标代码）。
  • 扩展至仓库级（Repository-level）代码生成，解决多文件依赖和跨文件 API 调用的复杂场景。

总结： CANGJIEBENCH 不仅填补了低资源通用语言基准的空白，还通过严谨的实验证明了在缺乏训练数据的情况下，通过精心设计的提示工程（特别是语法约束）可以显著提升 LLM 对新编程语言的掌握能力，同时指出了代码翻译任务中潜在的负迁移风险。