我刚开始接触“代码修复模型”这个词的时候，脑子里浮现的画面其实很简单：给模型一段有 bug 的代码，它吐出修正后的代码，再跑一下单元测试，过了就算它赢。后来真正把评测做进真实项目里，我才意识到事情远比这个画面复杂。代码片段修复和代码仓库级修复，差的不只是几行代码，而是整个软件工程环境。
1.1 从代码片段修复到仓库级修复：任务边界、评测对象与核心问题
我一直觉得，理解仓库级修复评测的第一步，是先把“任务边界”划清楚。代码片段修复往往给定一个孤立函数、一段明确的错误描述，模型只需要关注这一小段逻辑。仓库级修复面对的是一个真实的项目：几十上百个文件、层层依赖、暗含的编码约定、散落在各处的测试。模型拿到的可能只是一个 issue 描述或一条报错日志，它得自己在仓库里找线索。
这种差异直接改变了评测对象。片段级评测关心的是“这段代码改对了吗”，仓库级评测关心的是“这个补丁放到整个仓库里，能不能让项目重新健康起来”。我心里有个很朴素的判断标准：一个补丁在单独运行某个测试时通过，却在完整测试套件里引发三处回归失败，那它就不算真正修好了问题。核心问题也就从“生成能力”转向了“在约束条件下生成可用补丁的能力”。
我见过不少团队在这件事上栽跟头。他们用片段级的思路去做仓库级评测，结果模型在基准上分数漂亮，一上线就被真实仓库的各种边角情况打回原形。任务边界没划清楚，评测对象就会错位，后面的指标设计、数据构建全都要跟着返工。这种返工成本，比一开始多花几天想清楚要贵得多。
1.2 代码仓库修复模型的能力维度：缺陷定位、上下文理解、补丁生成、测试验证与回归控制
我习惯把仓库级修复能力拆成几个维度来看，这样分析模型表现时不会一团乱麻。缺陷定位是起点，模型得先知道问题大概在哪个文件、哪个函数，甚至哪一行附近。这件事听起来简单，做起来很难，尤其是在大型仓库里，报错堆栈和真正的根因经常隔了好几层调用。
上下文理解紧跟在定位之后。模型定位到文件还不够，它得读懂这个文件在项目里的角色、相关的接口约定、调用方和被调用方的期望。补丁生成是这个链条上最显眼的一环，也是最容易被过度关注的一环。我个人的看法是，生成只是中间产物，真正决定成败的是后面的测试验证。
测试验证和回归控制这两块，常常被一起谈论，我认为它们值得分开看。测试验证回答的是“这个补丁有没有解决目标问题”，回归控制回答的是“它有没有弄坏别的东西”。一个模型能生成语法正确的补丁，却频繁在回归测试上翻车，说明它缺乏对仓库整体行为的敬畏。这几个维度不是简单的加减关系，它们之间相互制约，评测设计时需要让每个维度都能被单独观察，也能被组合评估。
1.3 评测目标与设计原则：真实性、可复现性、公平性、可扩展性与工程可用性
做评测久了，我越来越看重“真实性”这个原则。真实性不是说数据一定要多大规模，而是任务实例要尽量贴近开发者真实面对的修复场景。真实提交里挖出来的 bug、真实的测试失败、真实的依赖环境，这些东西拼在一起，评测结果才有说服力。用人工构造的玩具仓库做评测，分数再高我心里也没底。
可复现性是另一条我死守的底线。同一个模型、同一份数据、同一套环境，今天跑出 42% 的修复率，下周跑出 38%，这种评测就没法用来做决策。仓库快照要固定，依赖版本要锁定，随机种子要记录，测试执行环境要容器化。这些工作很琐碎，不做的话，后面的所有分析都建立在流沙上。
公平性和可扩展性更像是一对需要平衡的伙伴。公平性要求不同模型拿到相同的信息、相同的预算、相同的评估机会，不能有的模型能访问完整测试套件、有的只能看到部分。可扩展性则要求评测流程能随着仓库数量、任务数量的增长而平稳运行。工程可用性是我后来才真正重视的，一个评测框架如果只有作者自己能跑起来，那它对社区的价值会大打折扣。设计原则之间会有张力，我的经验是先把真实性和可复现性做扎实，其他原则在这个基础上逐步打磨。
1.4 总体评测流程：仓库快照构建—任务实例生成—模型运行—补丁应用—测试验证—结果统计
整条评测流程我脑子里有一张比较清晰的图。起点是仓库快照构建，选定一个仓库的某个提交，把当时的代码状态、依赖清单、构建配置完整地冻结下来。这个快照是后面所有工作的地基，地基不稳，后面全是空中楼阁。接着是任务实例生成，从真实提交、缺陷注入或者 issue 关联中整理出“问题描述 + 期望修复”的样本。
模型运行环节听起来最直接，实际上要考虑提示构造、上下文窗口、是否允许检索、采样次数这些配置。补丁应用是个容易被低估的步骤，模型输出的补丁格式可能不规范，可能和当前代码有冲突，需要有稳健的解析和合并机制。测试验证环节要把目标测试和回归测试分开跑，记录每个测试的通过、失败、超时、跳过状态。
结果统计不是简单地算个百分比。我通常会按缺陷类型、仓库规模、难度分层去看修复率的分布，同时统计回归失败率、平均执行时间、补丁被拒绝的原因。整条流程走下来，任何一个环节的疏漏都会污染最终结论。我的做法是给每个环节都留下可检查的中间产物，出问题时能快速定位是哪一步偏了。
1.5 常见评测风险与误区：数据泄漏、仓库快照偏差、测试依赖差异、过拟合基准与结果误读
数据泄漏是我最警惕的风险，没有之一。训练数据里如果混进了评测集对应的修复提交，模型看起来就像“记住了答案”。这种泄漏有时候很隐蔽，比如同一个 issue 在多个数据集里重复出现，或者提交时间切分没做好，测试集的修复模式在训练集里已经出现过。我现在的习惯是做完切分后再做一轮泄漏检测，宁可多花时间。
仓库快照偏差也很常见。开发者本地跑测试时环境是热的，缓存、工具链、环境变量都齐全，而评测环境是冷的、干净的。这种差异会让一些模型补丁在评测里莫名其妙失败，也会让另一些补丁侥幸通过。测试依赖差异同理，某个测试依赖外部服务或者特定版本的编译器，评测环境没配好，结果就不可信。
过拟合基准和结果误读是一对孪生问题。模型在公开基准上刷出高分，团队就以为它能在自家仓库里大杀四方，实际一测发现差距巨大。我见过把修复率当成唯一指标的报告，忽略了回归失败和补丁质量，结论下得过于乐观。评测结果需要带着上下文去读：在什么仓库上、什么难度下、用什么配置跑出来的。把数字从语境里抽离出来，误读几乎是必然的。
上一章我们把评测的整体框架捋了一遍，这一章我想聊聊更具体的东西：基准怎么设计、数据集怎么来、指标怎么算。这三件事是我在实际评测里花时间最多的地方。框架是骨架，基准、数据和指标才是血肉。
2.1 代码仓库自动修复模型评测基准设计：仓库级场景、缺陷类型、任务难度分层与跨仓库泛化
我对“基准”这个概念有个比较朴素的看法：它不是一堆题目的集合，而是一套能反映真实修复难度的场景体系。仓库级场景首先要多样，小型工具库和大型单体应用面对的修复问题完全不同。小仓库里一个函数报错，上下文就那么点；大仓库里同样的报错，根因可能藏在另一个模块的配置里。基准如果不覆盖这个跨度，评测出来的分数就没什么参考价值。
缺陷类型也需要仔细挑选。语法错误和静态检查告警容易修，运行时崩溃、并发问题、边界条件缺失就难得多。我倾向于在基准里给不同缺陷类型打上标签，让评测结果能按类型拆开看。一个模型修简单语法错误成功率 90%，修并发问题时掉到 20%，这个分布比一个笼统的总体修复率有用得多。
任务难度分层是我后来才重视的。早期我把所有任务混在一起算平均分，结果模型之间的差异被稀释了。现在我会按涉及文件数、需要修改的代码行数、依赖的测试数量、上下文跨度来分层。跨仓库泛化是另一个关键维度，模型在 A 仓库训练或调优，到 B 仓库还能不能修，这才是工程上真正关心的问题。基准设计时留出跨仓库的测试集，能暴露出很多在单一仓库上看不出的问题。
2.2 代码修复模型评测数据集构建：真实提交挖掘、缺陷注入、仓库快照、测试用例筛选与标注规范
数据集构建这件事，我走过不少弯路。最开始的思路是从真实提交里挖 bug 修复对，具体做法是找那些“修了 bug 还带了测试”的 commit。真实提交的好处是场景可信，坏处是很多提交混着重构、格式化、功能新增，真正的修复信号被噪声淹没。我现在的做法是加几层过滤：看提交信息里有没有修复类关键词，看 diff 是否集中，看有没有相关联的 issue 或测试变更。
缺陷注入是另一条路。往健康代码里人为引入 bug，好处是知道正确答案，坏处是注入的 bug 往往太“人造”，和真实的开发者失误差别很大。我对注入缺陷的使用比较克制，更多拿它来做补充，尤其是某些缺陷类型在真实提交里样本太少的时候。
仓库快照的构建细节前面提过，这里想强调一句：快照要包含完整的测试执行环境。很多数据集只存了代码，测试依赖没锁定，拿到手跑不起来。测试用例筛选也很讲究，目标测试要能稳定复现失败，回归测试要能覆盖相关模块。标注规范上我坚持几条：每条样本要有清晰的问题描述、修复位置标注、目标测试列表、以及修复前的完整快照。标注质量比数量重要，一条标注混乱的样本对评测的伤害远超它带来的那点数据量。
2.3 数据集质量与划分策略：训练/验证/测试隔离、时间切分、泄漏检测、许可证合规与版本化管理
数据集的划分策略，我的态度是一开始就做严格。训练集、验证集、测试集之间的隔离要在仓库级别做，不能只在样本级别随机切。同一个仓库的不同提交分散在训练和测试里，模型很容易学到这个仓库的特定模式和代码风格，测试分数虚高。
时间切分是我更推荐的方式。用较早的提交做训练，较晚的提交做测试，模拟的是模型面对未来代码的场景，这比随机切分更接近真实使用。时间切分做起来麻烦一些，需要仔细核对每个样本对应提交的时间戳，还得保证仓库历史足够长。
泄漏检测我一般做两轮。一轮是文本相似度检测，看测试样本的修复代码有没有在训练集里近似出现；另一轮是 commit 级别检测，看同一个 issue 或同一个 PR 关联的提交有没有跨集分布。许可证合规经常被忽视，尤其是从开源仓库挖数据的时候。我现在的习惯是记录每个仓库的许可证类型，对许可证限制较严的仓库谨慎使用或者干脆排除。版本化管理也重要，数据集本身要有版本号，每次更新记录变更内容，不然过几个月自己都说不清评测用的是哪一版。
2.4 代码修复模型评测指标：修复成功率、补丁正确性、测试通过率、回归失败率、缺陷定位准确率与执行效率
指标这块，我见过太多报告只盯着一个修复成功率。修复成功率确实是最直观的指标，补丁应用成功并且目标测试通过就算修好。问题是这个指标太粗，它掩盖了补丁是怎么修好的、修得干不干净。
补丁正确性我会单独看，它和修复成功率有重叠但视角不同。正确性关注补丁的语义是否真的对准了缺陷根因，而不是碰巧让测试变绿。测试通过率需要拆开算，目标测试通过率和全量测试通过率要分开报告。我见过模型目标测试全过、全量测试挂掉一片的情况，只报前者等于自欺欺人。
回归失败率是我特别看重的指标，它直接反映补丁的副作用。缺陷定位准确率回答的是“模型找对地方了吗”，这个指标对分析失败原因很有帮助，定位错了后面的生成再漂亮也没用。执行效率包括模型生成时间、补丁应用时间和测试执行时间，大规模评测时这个指标会直接影响可操作性。这些指标之间不是并列关系，它们构成一条判断链：定位准不准、补丁对不对、目标测试过不过、回归有没有崩。
2.5 指标扩展与综合评价：补丁最小性、可维护性、可读性、安全性、人工评审与多维度加权
基础指标之外，我越来越觉得补丁质量需要更细的刻画。补丁最小性指的是改动行数和涉及文件数是否克制，一个能让测试通过的补丁如果删了半个文件、加了一堆防御性代码，工程上未必能接受。可维护性和可读性听起来主观，其实可以用一些代理指标来量化，比如新增代码的复杂度、命名规范符合度、注释密度变化。
安全性这块现在越来越重要。模型生成的补丁可能引入命令注入、路径穿越、不安全的反序列化之类的问题。我会用静态安全扫描工具过一遍补丁，把安全告警作为质量维度之一。人工评审是所有这些自动化指标之外的兜底，抽样一部分补丁让工程师从实际维护的角度打分。人工评审成本高，不能全量做，抽样的策略和评审标准要固定下来。
多维度加权综合评价是个容易吵架的地方。权重怎么设、不同维度怎么归一化、加权后的总分怎么解释，每个团队都有自己的偏好。我的做法是不追求一个万能总分，而是给出一个指标面板，让使用者根据自己的场景选择关注哪些维度，同时提供一个默认权重作为参考。这样既保留了综合视角，又不强迫所有人接受同一种价值判断。
2.6 实验协议与基线设置：模型配置、提示策略、检索增强、多次采样、置信区间与消融实验
实验协议是评测可信度的保障。模型配置要写清楚版本、参数规模、推理参数，温度、top-p、最大生成长度这些看似琐碎的设置对结果影响很大。提示策略同样关键，零样本、少样本、思维链、结构化输出格式，不同策略下同一个模型的表现可能差出一大截。我要求在报告里把提示模板完整附上，不然别人没法复现。
检索增强现在几乎是仓库级修复的标配，但检索什么、怎么检索、检索结果怎么塞进上下文，这些选择需要明确记录。多次采样能估计模型输出的稳定性，单次采样偶然性太大。我会对每个任务跑多次，报告通过率的分布，同时给出置信区间。置信区间这东西在样本量不大的时候尤其重要，两个模型分数差 3 个百分点，如果置信区间大幅重叠，这个差异未必有意义。
消融实验是为了搞清楚哪个环节在起作用。去掉检索、去掉上下文扩增、换一种提示策略，看指标怎么变化。基线设置要公平，所有模型用相同的任务集、相同的环境、相同的评估脚本。我见过拿自己精心调优的模型和别人默认配置的模型比，这种比较没有意义。
2.7 结果报告与错误分析规范：可复现元数据、失败案例分类、补丁质量分析、排行榜透明度与复现包
结果报告这件事，我的原则是“让别人能重跑一遍”。可复现元数据包括仓库快照版本、数据集版本、模型版本、运行配置、随机种子、硬件环境，缺一项都可能让别人复现失败。失败案例要做分类，是定位失败、生成失败、补丁应用失败、目标测试失败、回归失败还是环境问题，每类的占比和典型案例都要列出来。
补丁质量分析不能只看通过率，还要看补丁长什么样。我会收集那些“测试通过了但补丁很糟糕”的案例，这类案例最能说明指标设计的盲区。排行榜透明度指的是排名规则、评测时间、参与模型配置都要公开，不能只放一个分数。复现包我建议包含评测脚本、数据加载代码、环境配置文件和一键运行说明。做一个能被别人独立运行的复现包，比自己刷出多高的分数更能推动这个领域往前走。
这一章写下来，我感觉基准、数据和指标这三件事是互相咬合的。基准定义了考什么，数据决定了用什么考，指标决定了怎么判卷。任何一环设计得草率，评测结论都会打折扣。下一章我会聊这些设计怎么落到真实研发流程里，以及落地过程中会遇到哪些麻烦。
上一章聊完基准、数据和指标的设计，这一章我想把视角拉到真实的研发环境里。评测在实验室里跑出分数是一回事，放到团队日常开发流程里能不能用、好不好用，是另一回事。我在好几个团队推进过这件事，踩的坑比预想的多得多。
3.1 面向研发流程的评测落地：CI集成、离线基准测试、在线A/B验证与持续回归监测
我最开始做评测落地的时候犯了个错误，把评测当成一个独立的离线任务，隔一段时间跑一次，出一份报告。这种方式的问题是反馈太慢，模型迭代节奏一快，评测报告就跟不上趟了。后来我把评测往 CI 里塞，每次模型版本更新自动触发一轮基准测试，结果直接贴在 PR 评论里或者推到内部看板上。CI 集成的好处是强制性的，不需要谁记得去跑评测，流水线会替你记住。
CI 里跑的是离线基准测试，用的是固定版本的仓库快照和任务集。这部分我要求严格可复现，每次跑的配置、数据版本、模型参数都锁定，任何变量变动都要显式声明。离线基准测试的局限也很明显，它反映的是模型在“过去某个时刻的代码”上的表现，跟线上真实场景有差距。在线 A/B 验证是我用来补这个缺口的。在真实的修复请求里分流一小部分给新模型，对比修复成功率、用户采纳率、回滚率这些线上指标。线上指标比离线指标嘈杂得多，干扰因素多，但它是唯一能反映真实使用情况的手段。
持续回归监测是这两者的粘合剂。离线基准测试定期跑，线上指标持续看，两者之间做关联分析。我看到过模型离线分数涨了但线上采纳率没动的案例，后来查出来是基准里的缺陷类型分布跟线上真实请求分布偏差太大。这种问题不靠持续监测根本发现不了。
3.2 典型评测结果解读：不同模型在仓库级修复中的能力差异、瓶颈定位与场景适配性
不同模型在仓库级修复上的能力差异，比我在代码片段级评测里看到的要大得多。有些模型在单文件片段修复上表现很好，一到仓库级场景就掉得厉害，尤其是需要跨文件推理的时候。我分析下来，差距主要出在上下文获取和长距离依赖处理上。仓库级修复要求模型能定位到分散在不同目录里的相关代码，还要理解模块之间的调用关系，这个能力跟模型规模、训练数据里仓库级任务的占比都有关系。
瓶颈定位方面，我观察到一个比较普遍的现象：很多模型的瓶颈不在补丁生成，而在缺陷定位。给它一个明确的缺陷描述和位置提示，生成补丁的成功率不低；把定位这个环节也交给模型，成功率就明显下滑。这个发现影响了我对评测任务的设计，现在我会把定位阶段和生成阶段拆开评，分别给出指标，这样能更清楚地看到模型到底卡在哪一步。
场景适配性也是我特别关注的一个角度。有些模型在 Python 仓库上表现好，换到 Java 或 Go 仓库就明显变差，这跟训练数据的语言分布高度相关。我建议评测时按语言、按仓库规模、按缺陷类型做交叉分析，不要只看一个总分。一个模型总分排中间，但在某几个特定场景下表现突出，这种信息对工程选型非常有价值。
3.3 工程化挑战与应对：环境构建、依赖安装、测试不稳定、执行成本与大规模并行评测
仓库级评测的工程复杂度，比我最初预估的高出一个数量级。环境构建是第一道坎。每个仓库有自己的依赖体系，Python 的虚拟环境、Node 的 node_modules、Java 的 Maven 依赖，版本冲突、系统库缺失、编译工具链不匹配，这些问题能在评测开始前耗掉大半时间。我现在的做法是给每个仓库维护一个容器化快照，把依赖预先装好、编译预先跑一遍，评测时直接拉镜像启动，省去重复安装的时间。
测试不稳定是另一个让人头疼的问题。flaky test 在真实仓库里相当常见，网络依赖、时间敏感、并发竞争、外部服务调用，各种原因都可能导致同一个测试有时过有时不过。我的应对策略是评测前先做稳定性筛选，同一个测试在快照上跑多遍，标记出那些结果不一致的用例，在评测里排除或者单独标注。这一步很繁琐，但不做的话评测结果的噪声会大到无法解读。
执行成本是我在大规模评测里最现实的约束。一次全量评测跑下来，算力成本、存储成本、时间成本都不低。并行化是必须的，但并行度上去之后，环境隔离、资源竞争、结果汇总又会带来新问题。我现在的做法是按仓库和任务类型分片，每个分片独立跑、独立出报告，最后汇总。这样单点故障不会拖垮整个评测，也方便按需重跑某个分片。成本控制上我会设置预算上限，超出预算的任务自动降级采样率，用统计方法估计总体指标。
3.4 公平性与安全性评估：数据污染防控、许可证合规、补丁安全风险、滥用防护与审计机制
公平性这件事在仓库级评测里比片段级更敏感。数据污染是首要风险。模型训练数据里如果包含了评测用的仓库或提交，分数会虚高得离谱。我做污染检测的时候不只看文本相似度，还会检查模型是否能“背出”测试用例的精确内容，以及模型在完全没见过的仓库上的表现是否显著低于见过的仓库。这两条能筛出大部分污染问题。
许可证合规是另一个容易被忽略的点。从开源仓库挖数据做评测集，不同许可证对衍生使用的限制不一样。GPL 类许可证的仓库，评测数据的分发和再使用需要格外小心。我的习惯是给每个仓库标注许可证类型，对限制较严的仓库只做内部评测不对外发布数据，或者干脆从数据集中排除。这件事做在前面，能省掉后面很多法律上的麻烦。
补丁安全风险我单独拿出来说，是因为模型生成的补丁可能引入新的漏洞。命令注入、路径穿越、不安全的反序列化、硬编码密钥，这些问题在自动生成的补丁里都出现过。我在评测流水线里集成了静态安全扫描，每个补丁应用前先过一遍扫描器，有高危告警的补丁直接标记为不合格。滥用防护和审计机制也得有，模型修复能力被恶意利用来生成攻击代码的风险虽然不高，但评测平台需要记录每次调用的输入输出，保留审计日志，这是底线要求。
3.5 从静态评测到持续评测：动态基准、版本化仓库、反馈闭环与模型迭代评估
静态基准有个根本问题：它会过时。模型在固定数据集上刷到高分之后，这个数据集的区分度就下降了。我现在的做法是往动态基准方向走。动态基准不是说数据集每天变，而是建立一套从真实仓库持续采样的机制，定期把新的修复提交纳入评测集，同时把那些已经被现有模型普遍解决的简单任务降权或移出。
版本化仓库的管理是动态基准的基础。每个评测任务都要绑定明确的仓库快照版本和提交时间，仓库本身在演进，评测集也要跟着走。我会维护一个仓库池，定期同步上游更新，按时间窗口切分训练、验证、测试区间。这个机制让评测结果具有时间上的可比性，不同模型在不同时间点的评测是在同一套演进逻辑下进行的。
反馈闭环是我认为最有价值的长期投入。评测结果回流到模型迭代，模型迭代产生新版本再进入评测，这个循环要转起来。具体做法是把评测失败案例分类整理，高频失败模式反馈给模型团队做针对性优化，优化后的模型在相同任务集上重测，看改进是否真实有效。这个闭环转得越快，模型能力的提升节奏就越稳。模型迭代评估不能只看单次分数变化，还要看多次迭代之间的方差和趋势，避免被单次波动误导。
3.6 未来演进方向：智能体式修复评测、多文件协同修复、人机协同评审与标准化评测报告
智能体式修复是我最近在关注的方向。现在的评测大多针对单轮补丁生成，模型拿到任务描述直接输出补丁。智能体式修复不一样，模型可以主动探索仓库、运行测试、根据失败反馈调整策略，多轮交互之后才给出补丁。这种模式更接近人类开发者的修复过程，评测设计也需要跟着变。任务不再是“生成一个补丁”，而是“在限定步数和资源预算内完成修复”，评测指标要加入步骤效率、工具调用合理性、探索策略质量这些维度。
多文件协同修复是另一个明显的趋势。真实仓库里的缺陷经常涉及多个文件的联动修改，单文件补丁往往修不彻底。我看到的模型在这方面的能力还比较弱，尤其是需要同时修改接口定义和调用方的时候。评测集需要专门设计这类任务，指标上要考察补丁的跨文件一致性，比如改了函数签名有没有同步更新所有调用点。
人机协同评审我越来越觉得是绕不开的环节。全自动指标能筛掉明显不合格的补丁，但工程上真正关心的是“这个补丁一个工程师愿不愿意合并”。我现在在评测流程里加入了人工评审抽样环节，评审员从可维护性、代码风格一致性、变更范围合理性几个角度打分。这个环节成本高，但它提供的信息是自动化指标给不了的。标准化评测报告是我对未来的一个期望，希望社区能形成一套通用的报告模板，包含哪些元数据、哪些指标、失败案例怎么呈现，大家按同一套格式出报告，跨模型跨团队的比较才有意义。这件事靠单个团队推不动，需要社区协作，但方向是明确的。
