代码修复基准的数据泄漏，不只是模型提前见过标准补丁，也包括智能体在测试时通过仓库历史、任务线索、外部网络或反复试跑间接获得答案。只要评测材料暴露了缺陷的修复方式，最终分数就可能衡量“认出了答案”，而不是能否独立定位并修复问题。
首要措施是把任务快照与答案材料隔离。基准应从缺陷版本建立干净工作区，移除原补丁、提交记录及可能指向修复位置的线索，并确认分支、标签和其他文件没有保留答案。任务描述应提供复现现象和必要上下文，但不透露实现位置或修复方案。仓库提交、依赖和环境也要固定，否则测评差异可能来自输入不一致，而非能力差异。
其次，要控制评测期间的外部信息与反馈。联网、安装依赖和执行额外命令等权限应预先统一并记录；若允许访问外部资源，就需要评估修复内容是否可能被检索到。验收测试宜与任务提示及智能体可见的信息分开管理，尤其要避免把标准答案或隐藏测试反馈逐步泄露给模型。失败后反复提示、重置再测，也可能让后续尝试利用前一次反馈，因此每次运行应从干净状态开始，并保留完整记录。
基准还需防范长期污染：公开过的任务可能进入模型训练资料，也可能被智能体的记忆或团队内部文档复用。对关键评测，应保留不公开的任务集，限制答案材料的访问，并记录任务何时、以何种形式对外开放。若无法确认某项任务是否已暴露，就应谨慎解释其成绩，必要时从主要评测中剔除，而不是把分数当作独立能力证据。
防泄漏的核心不是把所有内容藏起来，而是明确划分模型可见输入、可执行操作和评测方保留的信息，并让每次运行可追溯。只有任务、权限、测试与历史记录都受到控制，基准结果才更接近真实修复能力，而不是对已泄露答案的复现。