如何构建针对私有代码库的 LLM 代码生成能力评测集

构建私有评测集最快的方法是「基于 Git Diff 的逆向出题」。我写了个简单的 Python 脚本，扫描过去三个月 PR 中变动较大的函数，提取「修改前」和「修改后」的代码块，把修改后的代码作为 Ground Truth，把修改前的上下文作为 Prompt 的输入。

具体构建流程：

1. 样本采集：
利用 git log -p 提取具体的函数变更。重点挑选那些修复 Bug 或实现新功能的 Commit，剔除掉纯格式调整的提交。

2. 构造测试用例：
一个标准的私有评测样本应该包含：
上下文（Context）： 相关的类定义、接口定义（通过 grep 或 LSP 提取）。
任务描述（Task）： 模拟一个需求，例如「在 X 模块中实现 Y 功能」。
预期输出（Reference）： 实际提交的正确代码。

3. 自动化跑分脚本：
不要人工看，直接写脚本调用 LLM API，然后用 diff 或 pytest 验证。

import subprocess

def evaluate_generation(generated_code, reference_code):
    # 将生成的代码写入临时文件，运行单元测试
    with open("temp_test.py", "w") as f:
        f.write(generated_code)
    
    # 运行预设的私有测试用例
    result = subprocess.run(["pytest", "tests/private_suite.py"], capture_output=True)
    return result.returncode == 0

配置技巧与踩坑点：

上下文注入的噪音问题：
起初我尝试把整个文件夹扔给 LLM，结果发现 Token 浪费严重且容易干扰。后来改为「依赖分析法」，只喂入被引用到的 .h 或 .ts 定义文件。建议在 Prompt 中明确告知：

请仅使用提供的上下文 API，严禁臆造不存在的内部方法

过度拟合的陷阱：
如果评测集里的代码和 Prompt 里的上下文太像，AI 只要做简单的文本补全就能拿高分，这测不出逻辑能力。建议在构造 Task 时，故意修改变量名或需求描述，强迫 AI 理解逻辑而非简单的模式匹配。

效率提升：
用 Cursor 的 @Codebase 索引功能快速定位相关依赖，手动校验 20 个核心样本，然后用这些样本作为 Few-shot 引导 LLM 自动生成更多类似的「需求-代码」对，最后人工抽检。这种「种子样本 → 自动扩充 → 人工校验」的链路比纯手动写快得多。