题解评测集的数据与指标定义
评测集应覆盖题型、难度、语言和边界条件，并与模型训练或提示词样本隔离。每条任务保留题目版本、期望行为和测试集来源，避免旧题目或泄漏答案造成虚高结果。
Pass@1 可以衡量首次候选通过率，但不代表解释质量、安全性或复杂度正确。还可记录解析成功率、编译率、测试率、成本与人工修复时间；每项需要说明分母和失败如何计数。
type Metrics struct { Total, Parsed, Compiled, Passed int } func (m Metrics) PassAt1() float64 { if m.Total == 0 { return 0 } return float64(m.Passed) / float64(m.Total) }随机测试保存种子和失败输入；沙盒、编译器、模型版本也要进入报告。结果按题型分组，比单一总分更能指出弱点。没有同样条件下的对照，就不要宣称某个工具更好。
让分数能被复算
评测最容易出错的地方是分母。比如解析失败的候选是否计入 Pass@1、编译超时算失败还是缺失、同一道题的多个语言版本是否分别计数，都要在报告中说明。否则两个团队都说“通过率”，实际计算的并不是同一件事。
还要防止数据泄漏。若题目、标准答案或人工修复内容曾进入提示词示例、检索库或训练样本，结果会失真。发现疑似泄漏时，应将该题从对比集剔除并记录原因，而不是保留高分。最后抽取一部分通过样本人工检查解释和复杂度约束，验证自动测试没有漏掉关键问题。评测集不是一次性排行榜，而是可持续的回归基线。
让样本和指标对应同一个问题
准备数据前先写清任务边界：输入来自哪里，允许怎样处理，什么结果算完成，哪些请求本来就应拒绝。样本要覆盖日常路径、边界条件和受控失败，训练或提示词中出现过的内容不能悄悄进入评测集。涉及用户或业务数据时，优先使用脱敏、授权且可追溯的材料；无法确认来源的样本宁可不用。
指标名称必须附带计算口径。成功率要说明分母是否包含超时和取消，耗时要区分排队与真正处理，质量判断要说明由规则、测试还是人工复核得出。单一平均值往往会遮住某类输入的失败，结果应按场景、版本或错误类型分组查看。评测脚本、依赖版本和随机种子应随结果保存，使别人能复算同一批数据。若样本量或覆盖面有限，结论就限定在这批输入，不把局部结果写成普遍能力。
回到代码生成与算法工具的实际约束
讨论“题解评测集的数据与指标定义”时，容易混在一起的是题目输入、候选代码、沙箱验证和评测口径。可以先画出一条真实操作的状态变化，标出每一步由哪段代码或哪个团队负责，再检查失败会停在哪里。让每个结论都能由测试或基准复算。示例里的参数只能说明写法，接入项目后仍要依据当前依赖、设备或数据重新测量。
验证时保留一份最小输入，并准备与它对应的失败输入。正常路径确认结果能被下一环节消费，失败路径确认提示、日志和恢复动作一致。若现有材料不足以支持某个性能或效果结论，就保留限制条件，等有可复现记录后再判断。这样写出的方案不会显得花哨，却能让接手的人知道从哪里开始、在哪里停下，以及怎样确认修改没有越过原来的边界。
