代码生成模型的能力评估长期依赖HumanEval与MBPP两类基准，它们通过给定函数描述或简短问题，要求模型输出完整实现并通过隐藏测试用例。在专项优化中，理解基准本质与补齐工程短板，比单纯追求排行榜分数更有价值。
一、HumanEval与MBPP基准的基本认知
HumanEval由OpenAI发布，包含164个手写编程问题，每个问题提供函数签名与文档字符串，模型需补全函数体，并通过约十来个断言形式的单元测试。它侧重算法与基础数据结构，例如字符串处理、数学计算等，能反映模型对明确意图的翻译能力。
MBPP全称Mostly Basic Python Problems，收集约1000个入门级Python任务，描述更偏向自然语言提问，如“写一个函数返回列表中的偶数”。它测试模型从口语化需求到代码的映射。两者都不覆盖多文件项目或外部依赖，却成为衡量生成质量的门槛指标。
1.1 基准的评分逻辑
评测通常采用pass@k指标，即生成k个候选，只要有一个通过全部测试就算成功。这暗示了采样随机性的作用：即便单次生成弱，多次抽样也能拉高分数。工程上可借此设计并行生成与投票机制。
但要注意，测试集固定导致过拟合风险。一些模型在训练期见过类似题目，分数虚高。因此专项优化应关注泛化，而非仅盯住数字。
二、提示构造层面的优化
直接丢一句“写个排序”给模型，远不如给出结构化签名加示例稳定。在HumanEval风格任务中，保留原签名与docstring，补充一个输入输出现象说明，可显著降低歧义。模型对上下文格式敏感，规范模板能减少废代码。
对于MBPP类自然语言题，先把需求转成“函数名+参数类型+返回类型”的骨架，再让模型填实现。例如用户说“统计一段话单词数”，提示中写明def count_words(text: str) -> int，模型偏离概率变小。还可加入少量思维链，引导其先列边界情况再写主体。
2.1 少样本与零样本的选择
在基准微调环境外，少样本常能提升依从性。放一个同库风格的小例子，模型会模仿缩进与命名。但例子若太复杂，反而挤占上下文。零样本加清晰指令，在强大基座上往往够用。
实验显示，对HumanEval加入一个算法题示范，pass@1平均涨几个点；MBPP因描述直白，零样本已良好。优化时按任务类型切换策略，比统一套模板更省事。
三、采样与后处理校验
利用pass@k特性，实际服务可生成5到10个候选，用轻量解释器本地跑基准测试，筛出全通过的。无全过时，选通过子用例最多者并标记风险。这把基准的测试集思想搬到线上，形成闭环。
后处理还包括去除冗余导入、统一格式。有些模型爱写if __name__ == "__main__"演示，应剥离。再用静态检查抓未定义变量。下表对比两种常用策略：
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 多采样投票 | 生成n个取测试通过最高 | 线上高精度要求 |
| 单采样加校验 | 一次生成即跑用例补修 | 低延迟内部工具 |
3.1 借助本地执行环境
搭一个临时沙箱，装上基准同版Python与依赖，把候选代码和断言送入执行。通过者直接交付，失败者回收错误信息，可作为下一轮提示的调试线索。这步让优化从“猜”变成“证”。
需注意沙箱安全，禁网络与系统调用，防止生成代码误删文件。很多团队用容器限制资源，既快又稳。
四、常见误区与正确路径
误区一是只刷榜不改流程，模型在HumanEval拿九十多分，业务里却因需求模糊翻车。基准仅证明“能写小函数”，不证明“懂你系统”。正确做法是把基准当单元测试集，融入自己用例。
误区二是忽视MBPP里的自然语言偏差，以为模型懂行话。实际要人工校准描述。专项优化核心，是用基准方法论建立可重复评估，再据反馈迭代提示与采样，而不是追一时高分。
代码生成优化的目标，是让模型在真实需求下稳定产出可运行片段，HumanEval与MBPP是指路牌而非终点。