代码修复Bug Fixing：一间“代码检修车间”的验收标准

可视化演示

演示代码修复能力评测：缺陷注入生成缺陷样本、模型定位缺陷生成修复补丁、多层次验证正确性，并计算修复通过率与pass@k指标。

缺陷注入方法：考卷上的“标准次品”从哪来

软件检修厂要考核徒弟，师傅第一步是准备“标准考件”。怎么准备？要么在好零件上故意做手脚——划几道痕、剪断一根线，难度可控、想考什么就考什么；要么直接从仓库里挑出顾客退货的真坏件，毛病千奇百怪但绝对真实。两种办法各有拥趸，质量好的考件体系往往两者都要。

代码修复评测的第一步，就是“缺陷注入”——为模型准备带bug的代码任务。人工标注缺陷指研究者手工修改代码制造bug，比如从 HumanEval 里挑一个正常函数，故意改错边界条件，难度可以分层设计；自然缺陷采集指从真实 GitHub 仓库的历史提交中，找出“修复了一个bug”的 commit，把修复前版本当作缺陷版本。前者像标准题型卷，后者像真题卷。

不过，注入缺陷不能随心所欲。一个“坏件”必须能被质检工序抓出来，否则模型修不修，分数都毫无差别。因此每个注入缺陷都要做有效性过滤：在缺陷版本上跑一遍原有测试，确认至少有一个用例失败。这条规则用公式表达就是：

回到检修车间：每道送进考场的“次品题”都得盖一个“可检出”的章。如果划的那道痕根本不影响零件工作，质检员测不出来，这道题就是废题。评测基准同样要淘汰这类无效缺陷，只保留能被测试抓住的真bug。

修复正确性验证：质检员凭什么说“修好了”

徒弟把修好的零件交回来，质检员不会听口头汇报。他要把整套工序重新走一遍：先针对这次故障做专门的检测，再把原本的全部检测项目重跑一次，最后还要对照原厂图纸，确认内部结构没被改得面目全非。

在评测中，模型生成修复补丁后，“对错”由测试集来裁决。基准会为每个任务准备两组测试：新测试（针对这个bug新写的断言，专门检验“故障现象消失”）和回归测试（原本就有的测试，检验“其他功能没被弄坏”）。模型补丁必须同时通过这两组测试，才被判定为修复正确。

但这还不够严谨。测试总有覆盖不到的地方——比如模型把某个函数的逻辑整体重写了一遍，恰好蒙混过关。于是基准还需要语义等价校验：用静态分析或差异化测试，检查补丁后的代码行为是否与“真修复”等价；对于高风险补丁，还会引入人工确认机制，由专家抽查。三者叠加，才是完整的正确性验证：

质检员的逻辑从来都是“双向确认”：专门的故障检验证明了病根已除，全面复检证明了身体无恙。代码修复评测同样如此——只过新测试，可能是把整个功能删了来逃避检查；只过旧测试，则是bug根本没修干净。

回归测试设计：防止“拆东墙补西墙”的复查工序

维修厂老师傅总念叨一句话：“修一个地方，可能带坏三个地方。”拧紧螺丝可能压断线路，换掉齿轮可能卡住轴承。所以真正的复查，一定不是只查修过的那一处，而是把整条流水线的关键节点全部重新测一遍。

代码修复中的“拆东墙补西墙”极为常见：模型为了让新测试通过，可能直接把有bug的函数体清空，或者加上一堆硬编码的if分支来“骗过”断言。回归测试设计就是为了防住这些花招。它的第一条原则是高覆盖测试集——测试要尽量执行到被修复函数的每一条代码路径，让“删代码”这种取巧行为立刻暴露；第二条是新增边界用例——针对bug的性质补上极端输入，比如空列表、负数、超大整数，让修得不够本质的补丁现形；第三条是防伪修复检测——通过断言“修复后代码仍保留正常功能”来识别假装修复的伪补丁。

这些原则背后最常用的量化工具是覆盖率：

回到复查工序的比喻：覆盖率就是“这段零件被质检探针扫过的比例”。探针没扫到的地方，偷工减料就能藏身。当然，覆盖率也不是越高越好，追求100%行覆盖可能带来冗余测试和巨大算力消耗，评测基准需要在“体检彻底”与“成本可控”之间找平衡。

评测基准设计：官方技能大赛的考卷从哪来

车间要办一年一度的维修技能大赛，最头疼的就是出卷。出卷人有两条路线：从真实客户故障记录里挑典型案例改造成考题，或者请专家按知识点人工编题。前者真实但难控制难度，后者标准但可能脱离实际。[SWE-bench](0) 就是前者的代表作——它从真实 GitHub 仓库中收集了大量 issue 与对应修复 PR，把“问题描述、原始代码、真实测试”打包成任务；[HumanEvalFix](1) 则属于后者，在 HumanEval 函数集上人工注入bug，覆盖简单、中等、困难三档难度。

无论是真题卷还是标准卷，好的基准都要贴近真实项目场景：任务不能只是孤立的小函数，最好带上项目上下文、依赖关系和真实的失败测试信息。唯有如此，模型在大模型基准上练出的修复能力，才能迁移到工程师日常面对的复杂代码库中。

设计考卷时还有一个关键步骤——计算基线通过率。所谓基线，就是用一个非常朴素的修复器（比如直接返回原代码、或早期弱模型）先跑一遍基准，看看“瞎蒙”能得多少分。如果基线通过率太高，说明考卷太简单、区分度差；太低则说明任务难到没有区分意义。基线通过率的定义是：

官方大赛的每一套考卷，都得先让“普通人”试做一遍，才能确定难度星级。评测基准同理——基线通过率就是考卷上的“难度提示”，告诉使用者这套题是入门级还是挑战级，也为后续对比模型分数提供了参照系。

评分标准体系：记分牌上的PASS@K

维修技能大赛现场，最激动人心的环节是记分。最简单的记分方式自然是“一题一分，全过才算对”——这就是端到端通过率：每个任务只有“全部测试通过”和“没通过”两种结果，按任务数求平均。它的优点是干净明确，缺点是太苛刻：模型明明产生了高分补丁，只因为测试环境一点抖动就判零分，浪费了信息。

于是比赛升级了规则：每位选手可以交K份答案，只要其中有一份全对，这题就给你算通过。 这就是 PASS@K 的思想。它来自 Codex 论文提出的无偏估计：假设模型对一道题采样了 n 个候选补丁，其中 c 个通过全部测试，随机从 n 个中抽取 k 个，至少有一个成功的概率。公式如下：

除了正确率，记分牌还有“效率栏”：修复效率度量会关注补丁是否最小改动、修复耗时多长、消耗了多少token。两位师傅都修好了同一个零件，一位换了整块变速箱，另一位只换了一个垫圈——谁的工艺更好？不言自明。

基准局限性：任何考卷都有盲区

再严谨的考卷也有三个绕不开的盲区。第一个是数据污染：竞赛题目如果提前泄露给了考生，分数就失去意义。代码修复基准同样如此——如果模型的训练语料里恰好包含了 SWE-bench 中的 issue 原文、修复 commit 甚至测试代码，那它“修复”问题时很可能只是把背过的答案默写出来，分数虚高却不代表真实能力。

第二个盲区是领域覆盖有限。SWE-bench 偏向 Python 仓库，HumanEvalFix 偏向函数级小任务，它们无法覆盖大型系统的架构级缺陷、多文件联动故障、或是编译期才能暴露的类型错误。在真实项目里修 bug，面对的挑战远比一张考卷复杂。第三个盲区是复现成本代价：跑全量测试验证补丁需要大量算力，尤其当测试集庞大时，一次评测可能消耗数小时GPU时间，这让小团队复现基准结果变得困难。

当任务数量有限时，分数本身也有统计波动。假设观测通过率为 p，任务数为 N，模型真实能力的置信区间可以近似表达为：

回到车间：一套考卷如果每年都泄题、只考车床不考焊工、而且考场租金贵到只有少数人考得起，那么即使它是官方认证，大家也要保持警惕。看懂基准的局限性，比记住排行榜名次更重要。

AI 应用场景

Python 演示

"""Mini benchmark for code repair: inject bug, verify patches, compute PASS@K."""import math  def flawed_mean(values):    """Original buggy version: raises ZeroDivisionError on empty list."""    return sum(values) / len(values)  def candidate_1(values):    """Patch that returns 0.0 for empty list and keeps normal math."""    return sum(values) / len(values) if values else 0.0  def rounded_mean(values):    return round(sum(values) / len(values), 2) if values else 0.0  def candidate_2(values):    """Patch using rounding, still handles empty list."""    return rounded_mean(values)  def candidate_3(values):    """Fake fix: drops negative numbers, hidden bug remains."""    positive = [v for v in values if v > 0]    return sum(positive) / len(positive) if positive else 0.0  TEST_CASES = [    ("empty list", [], 0.0),    ("all positive", [1, 2, 3], 2.0),    ("with negative", [1, -2, 3], 0.6667),    ("all negative", [-1, -2, -3], -2.0),    ("single item", [42], 42.0),]  def run_all(func):    """Run the full regression suite, return True only if all pass."""    for name, values, expected in TEST_CASES:        try:            got = func(values)        except Exception:            return False        if abs(got - expected) > 0.01:            return False    return True  def comb(n, k):    """Binomial coefficient, returns 0 when k is out of range."""    if k < 0 or k > n:        return 0    return math.comb(n, k)  def pass_at_k(n, c, k):    """Probability that at least one of k sampled patches succeeds."""    return 1 - comb(n - c, k) / comb(n, k) if n >= k else 0.0  def main():    candidates = [candidate_1, candidate_2, candidate_3]    results = [run_all(f) for f in candidates]    n = len(candidates)    c = sum(results)    for i, (func, ok) in enumerate(zip(candidates, results)):        print("candidate %d: %s" % (i + 1, "PASS" if ok else "FAIL"))    print("success count: %d / %d" % (c, n))    for k in (1, 3):        score = pass_at_k(n, c, k)        print("PASS@%d = %.3f" % (k, score))  if __name__ == "__main__":    main()

1. def flawed_mean(values):这是“缺陷注入”环节：一个故意写错的函数，空列表时抛出除零异常。
2. def candidate_1(values):模拟模型生成的第一个修复候选，正确处理空列表边界。
3. def candidate_3(values):一个“伪修复”候选：丢弃负数，表面不报错但行为错误。
4. TEST_CASES = [回归测试集，包含空列表、负数等边界用例，相当于质检工序表。
5. def run_all(func):验证环节：跑全部测试，任何用例失败或异常都返回 False。
6. if abs(got - expected) > 0.01:浮点比较必须带容差，不能直接用相等判断。
7. def pass_at_k(n, c, k):PASS@K 核心公式的无偏估计实现。
8. return 1 - comb(n - c, k) / comb(n, k) if n >= k else 0.0用“全是失败”的概率取反，得到“至少一次成功”的概率。

常见误区

面试题