如何构建一套针对私有业务逻辑的 LLM 代码生成评测集

单纯依赖 HumanEval 这种通用数据集没法衡量 AI 对私有业务的理解，因为通用集测的是算法能力，而我们要的是它能不能正确调用公司内部那个极其阴间、文档缺失的 OrderService。

构建私有评测集的核心在于：用“黄金用例 (Golden Set)”对冲 LLM 的随机性。

我的实践路径是构建一个包含 Prompt、Expected_Code 和 Verification_Script 的 JSONL 仓库。不要试图让 AI 自动生成测试用例，那是在用 AI 验证 AI，毫无意义。

第一步：挖掘“痛点片段”
去 Git 提交记录里找那些因为 AI 写错了而导致 Bug 修复的 PR，或者找那些逻辑最复杂的 if-else 嵌套块。把这些代码抽出来，去掉实现，写成自然语言需求。

第二步：定义严格的验证脚本
不要用 LLM 来打分（LLM-as-a-Judge 在代码评测上太宽松），直接写单元测试。

# test_cases.jsonl 结构示例
{"id": "biz_001", "prompt": "实现一个订单状态流转逻辑，只有待支付状态能转为已支付，且需调用 internal_audit_service 校验", "expected_output": "...", "test_cmd": "pytest tests/test_biz_001.py"}

第三步：构建上下文注入管道 (Context Injection)
私有逻辑生成失败 80% 是因为缺少上下文。我配置了一个简单的脚本，在运行评测前，先用 grep 或 ctags 提取相关的接口定义（Header files 或 Interface 定义）喂给 LLM。

配置技巧：对比实验矩阵
我会建立一个矩阵来测试不同工具的表现：
Cursor (Claude 3.5 Sonnet) + @Codebase vs Claude Code + 局部文件索引 vs Copilot (GPT-4o)。

踩过的坑：
1. 过度依赖 RAG：一开始我想通过向量数据库检索相关代码，结果发现检索回来的片段经常断章取义，导致 AI 生成的代码看起来很像，但编译不通过。现在改为手动维护一个 context.md，把核心业务领域模型（Domain Model）直接塞进 Prompt。
2. 忽视版本波动：同一个 Prompt，模型更新后结果会变。评测集必须版本化，每次更新模型版本都要全量跑一遍回归。

效率提升点：
用一个简单的 Bash 脚本自动化这个过程：

# 伪代码：自动化评测流水线
for case in cases.jsonl; do
  prompt=$(echo $case | jq .prompt)
  context=$(cat domain_context.txt)
  # 调用 LLM API 生成代码
  llm_gen=$(curl -s "https://api.anthropic.com/..." -d "prompt=$context\n$prompt")
  echo $llm_gen > temp_gen.py
  # 直接执行测试脚本，通过则计 1 分
  $case.test_cmd && echo "Pass" || echo "Fail"
done

这套流程跑下来，能清晰地看出哪个模型在处理我们的异步消息队列逻辑时最容易掉坑，从而决定在团队内部推广哪个工具。