多语言代码生成基准与编程提示策略

tl;dr

• 主流强模型对多语言编程提示已覆盖较好，语言不是主要瓶颈
• 关键术语强制保留英文（库名、API、算法名），比全量翻译更有效
• 中文需求 + 英文约束锚点的混合策略是实践验证的有效做法
• 用"可验证性"拉代码质量：要求测试、自检、结构化输出

一、问题的起源

在使用 AI 辅助编程时，你可能会产生这个疑问：

"我用中文描述需求，AI 生成的代码质量会不会比用英文差？要不要先把需求翻译成英文？"

这个困惑的背后有一个前提假设：模型在英文上的训练数据更多，因此英文提示可能带来更好的结果。

但事情没那么简单。模型的多语言能力是通过对齐（alignment）阶段培养的，优秀的代码模型会刻意增强多语言理解与生成能力。这时候，我们需要一个关键问题的答案：

不同语言提示下的代码生成能力，差异究竟有多大？

二、HumanEval-X：多语言代码生成基准

为了回答这个问题，我们需要先了解评测多语言代码生成的标准方法。

2.1 传统方法的局限

此前，多语言代码生成能力是基于语义相似度（比如 CodeBLEU）来衡量的。这种方法有明显的缺陷：

2.2 HumanEval-X 的设计

HumanEval-X 是一个专门用于衡量功能正确性的多语言代码生成基准。

覆盖范围：

• 820 个高质量手写样本
• 支持 5 种语言：Python、C++、Java、JavaScript、Go

核心任务：

┌─────────────────────────────────────────────────────────────┐
│  代码生成任务                                                │
│  输入：函数声明 + 文档字符串                                 │
│  输出：函数实现                                             │
├─────────────────────────────────────────────────────────────┤
│  代码翻译任务                                                │
│  输入：两种语言的函数声明 + 源语言实现                        │
│  输出：目标语言实现                                          │
└─────────────────────────────────────────────────────────────┘

评测指标：采用 Codex 的无偏 pass@k

$$\text{pass}@k := \mathbb{E}\left[1-\frac{\binom{n-c}{k}}{\binom{n}{k}}\right]$$

其中 $n=200$，$k \in \{1, 10, 100\}$。

2.3 关键发现

HumanEval-X 的实验结果揭示了一个重要事实：

同一题面换语言后，性能仍可能有差异，但差异幅度取决于模型与任务。

这意味着：

• 语言差异确实存在
• 但不必机械地"先翻英文"
• 更重要的是需求清晰度和约束完整性

三、代码场景下的提示策略

基于多语言基准的研究发现和实践经验，以下是经过验证的提示策略。

3.1 默认策略：直接用中文写需求

┌─────────────────────────────────────────────────────────────┐
│  主流强模型（GPT-4、Claude 3.5/4、DeepSeek）对多语言编程    │
│  提示已覆盖较好。语言不是主要瓶颈，需求清晰度/约束完整度     │
│  更关键。                                                   │
└─────────────────────────────────────────────────────────────┘

示例：

实现一个函数，用于统计字符串中每个字符出现的次数。

要求：

1. 返回一个字典，key 是字符，value 是出现次数
2. 时间复杂度 O(n)
3. 只处理 ASCII 字符

3.2 英文锚定策略：强制保留关键术语

这些内容绝对不要翻译，必须保持英文原样：

提示词模板：

实现 XXX 功能。

注意：以下标识符不要翻译（identifiers must not be translated）：

- 库/框架名：...
- API/类名/函数名：...

3.3 混合策略：英文要点摘要（推荐）

不需要全量翻译，只需 5-10 行英文 bullet points：

## 需求（中文）

实现一个LRU缓存淘汰机制的类。

## 英文约束锚点（Inputs/Outputs/Constraints/Edge cases）

- Inputs: capacity (int), key (str/int), value (any)
- Output: dict with {key: value}
- Constraints: O(1) time for get/set, max capacity limit
- Edge cases: empty input, key not exists, capacity = 0

## 交付物

- LRU Cache 类实现
- 单元测试（pytest）
- 使用示例

为什么有效：

• 减小语言分布差异带来的误解风险
• 英文约束作为"锚点"防止漂移
• 符合多语言对齐研究的发现

3.4 可验证性策略：用测试约束质量

把交付物拆成明确结构：

## 任务：实现排序算法

### 1. 设计思路（可选）

简要说明你的实现思路

### 2. 代码实现

```python
def quicksort(arr):
    # 你的实现
```

3. 单元测试

import pytest

def test_empty():
    assert quicksort([]) == []

def test_single():
    assert quicksort([1]) == [1]

def test_duplicates():
    assert quicksort([3, 1, 2, 1]) == [1, 1, 2, 3]

def test_negative():
    assert quicksort([-2, 3, -1, 0]) == [-2, -1, 0, 3]

4. 用例覆盖说明

• 空数组
• 单元素
• 重复元素
• 负数
• 大数据量（性能测试）

### 3.5 质量约束策略：写死规则而非愿望

**有效的约束写法**：

```markdown
## 质量要求（硬约束）

### 边界处理
- 必须处理空输入（返回空列表/空字典）
- 必须处理异常输入（类型错误、值错误）
- 必须处理超大数据量（考虑内存限制）

### 性能要求
- 时间复杂度不超过 O(n log n)
- 空间复杂度不超过 O(n)

### 库限制
- 禁止使用 itertools、functools（练习基础）
- 必须使用标准库 only

### 输出格式
- 代码必须可直接运行
- 提供 `if __name__ == "__main__":` 示例
- 提供命令行参数解析（如果适用）

无效的写法：

❌ "代码要高效" （太模糊）
❌ "要考虑性能" （无法验证）
❌ "处理各种情况" （无法衡量）

3.6 策略切换准则

如果你观察到中文提示确实更不稳定：

不推荐的做法：

❌ 中文 → 英文 → 中文（来回翻译）
   └── 容易引入术语与语气误差

❌ 全量翻译成英文
   └── 增加 token 成本，效果未必更好

四、可复制的提示骨架

# 需求（中文）

[用中文描述你要解决的问题]

# Inputs / Outputs（英文，可选）

- Input: [参数类型与含义]
- Output: [返回值类型与含义]

# Constraints（英文锚定）

- Time Complexity: O(...)
- Space Complexity: O(...)
- Libraries: [允许/禁止的库]
- Identifiers must not be translated: [API名、库名等]

# Edge Cases（英文）

- Empty input handling
- Invalid input handling
- Boundary conditions

# Deliverables

- [代码实现]
- [单元测试]
- [运行示例 / usage]

# Rules

- Do not translate identifiers / API names
- Code must be runnable directly

五、总结

核心原则：

需求清晰度 > 语言选择 > 翻译技巧

多语言代码生成基准告诉我们：语言差异存在，但不必过度担忧。把精力放在把需求写清楚、约束列完整、用测试验证，比纠结"中翻英"更有价值。

参考资料

• HumanEval-X 多语言代码生成基准
• CodeGeeX 项目
• CodeBLEU: 语义相似度评估方法
• OpenAI Codex 原始论文