AI代码修复能力评测：从Bug到自动修复

可视化演示

展示AI代码补全的上下文感知生成流程，以及pass@k等评测指标的计算方式和模型对比。

任务定义与Bug分类

想象你是一名主治医师，每天面对的病人千奇百怪：有的头疼发热，有的外伤骨折，有的慢性病缠绵多年。要评估一位实习医生的水平，首先要让他学会区分病种、对症下药。AI代码修复评测也一样——第一步就是把「代码问题」这件事实实在在地定义清楚，否则后面的一切考核都无从谈起。

所谓代码修复任务，就是向AI模型输入一段存在Bug的代码（通常还附带报错信息或失败的测试日志），要求模型输出修复后的正确代码片段。这就像医生拿到病人的化验单和症状描述，需要开出对应的处方。模型不仅要指出问题在哪，还要给出能真正解决问题的「药」——完整的、可运行的修复代码。

实际评测中，Bug类型通常分为三类。第一类是语法错误，代码根本无法编译通过，如同呼吸困难需要急救的病人，虽然看起来吓人但往往最好治；第二类是逻辑错误，代码能跑但计算结果不对，如同潜伏的慢性病，表面正常实则隐患重重；第三类是边界条件错误，只在特定输入下才崩溃，如同只在剧烈运动时发作的心脏病，最难定位也最考验医生的经验。评测时通常分层统计这三类Bug的修复率，因为它们的难度不在一个量级。

一份完整病历要写明主诉、检查结果和处方，标准的代码修复任务也一样：Bug代码、错误线索、修复目标三者缺一不可。任务定义得越清晰，后续的考试才越公平，不同模型之间的比较才站得住脚。

评测数据集构建

医生水平评估不能靠凭空编造病例——你给实习医生看的病例必须真实、典型、有据可查。AI代码修复评测同样如此：一份高质量的「考卷」是整个评估体系的基石。如果考卷本身出题不严谨，AI医生考了满分也不能证明它真的会看病。

评测数据集的构建主要有三条路。第一条是从真实开源项目中挖掘Bug——去GitHub上找那些曾经出过问题的代码提交，同时保留Bug版本和修复版本，这相当于收集真实临床病例，自然且接地气。第二条是人工构造缺陷——在正确的代码里人为埋入错误，这相当于用标准化病人做模拟演练，可控制性强。第三条是混合方式，兼取两者之长。

真实Bug的优点是高度自然、贴近实际开发，但收集成本高、难度分布不均；人工Bug的优点是标注准确、难度可控，但模式往往过于简单，无法覆盖真实场景的复杂性。当前主流基准（如Defects4J、BugsInPy、SWE-bench）大多以真实项目Bug为主。在数据规模上，一个可靠的评测集至少要包含几十到几百个Bug样例——太少则统计结果没有意义，太多则评测成本难以承受。

好医院的病例库一定分门别类、标注清晰、既有疑难杂症也有常见病。好的评测数据集同样要平衡Bug难度和类型，每条数据都带「金标准」修复方案。这样AI医生考完之后，我们才能清楚地知道它擅长什么、不擅长什么，而不是得到一个模糊的总分。

修复正确性判定

病人吃了药，医生不能说「我觉得应该好了」——必须复查血液指标、做影像检查，用数据说话。AI生成了一行修复代码，我们也不能只看它「长得像不像」标准答案，而要实际运行测试来验证它是否真的解决了问题。

修复正确性判定是整个评测中最关键的一环。主流方法是「功能等价测试」：运行一组针对该Bug精心设计的测试用例，如果修复后的代码全部通过，就判定修复成功。这相当于医学上的治愈标准——症状消失、指标正常、且没有新的并发症。注意，判定的是修复后的代码行为，而不是候选代码与参考补丁的文本相似度。

具体的判定有三个层次。第一层是编译/语法检查，代码必须能通过编译，这是最基础的门槛，相当于病人不能下不了手术台。第二层是测试套件执行——运行预定义的「失败用例」和「回归用例」，目标是失败用例转绿、且原有功能不退化。第三层是语义等价判断，通过静态分析或模糊测试来比较修复前后代码的行为一致性，这在测试用例覆盖不充分时尤为关键，能帮助发现「碰巧过测试但逻辑仍错误」的假修复。

出院标准不能只看病人脸色好不好，还要看各项生化指标是否正常。代码修复的「出院标准」同理——不能靠人眼主观判断代码样式，必须让测试用例这个「检验科」出具客观报告。测试覆盖面越全，这份报告的权威性就越高。

评测指标体系

一家医院的治愈率高不高，不能靠个别病人的口碑，而要用统一的统计指标来衡量。AI代码修复评测也有自己的「医院排行榜」指标。最核心的是「修复成功率」，即全部被测Bug中修复成功的比例。但单看这一项不够全面——因为模型每次生成的修复方案可能不同，存在随机性。

因此业界广泛使用 Pass@k 指标：允许模型对每个Bug生成 k 个候选修复方案，只要其中任意一个通过测试，就计为该Bug修复成功。这相当于允许医生做「二次诊断」——给患者提供一套备选治疗方案，其中一套起效就算治愈。k 越大，成功率通常越高，但也就越偏离真实使用场景。

除此之外，还有「多修复率」（要求 k 个候选里至少 m 个都正确才算成功，考察稳定性）、「编译通过率」（生成补丁的语法有效性）、「运行效率」（平均修复耗时与计算成本）。评测实践中的黄金法则是组合使用多类指标：修复成功率管「能不能治好」，Pass@k 管「给几次机会能治好」，运行效率管「治一次花多少钱」。

就像医院季报会同时公布接诊量、治愈率和平均住院天数，AI代码修复评测也一定要多维度呈现。只看一个指标，就像只问患者「过了危险期没」，却不关心他恢复得怎么样、花了多少时间——给出全面的指标组合，模型的真实水平才无所遁形。

主流模型水平对比

医院排行榜一出，各家医生的水平立见高下。目前AI代码修复领域的「医生们」——GPT-4、Claude、开源模型——表现到底如何？这是所有评测者最关心的问题，也是评测结果最有价值的输出。

根据主流基准测试的公开数据，闭源大模型在代码修复任务上整体领先。以SWE-bench为例，最新一代GPT-4类模型能够修复约25%-30%的真实GitHub Issue问题，Claude系列表现相当；优秀的开源模型（如DeepSeek等）能修复约15%-20%。听起来差距只有10个百分点，但这些被选中作为考题的Issue都不是「感冒发烧的小毛病」，每一个都难度极高，10个百分点的差距背后是巨大的工程能力差异。

比总分更重要的是典型失败模式。第一种是「复读机」——模型把Bug描述复述了一遍，但代码没改或只改了无关紧要的地方；第二种是「过度治疗」——模型大改特改，虽然测试碰巧通过，但引入了大量不必要的变更，相当于给病人做了个全器官移植；第三种是「注意力偏航」——模型被大段无关代码干扰，压根没定位到真正的Bug。评测时观察这些失败模式，比只看总分更能指导模型的后续改进方向。

三甲医院与社区医院的差距从来不只体现在个别疑难病例上，而是整体的诊疗深度。目前闭源模型在复杂Bug上的优势明显，但开源模型迭代速度极快，差距正在肉眼可见地缩小。也许过不了多久，这份「AI医生排行榜」就要重新洗牌了。

评测基准演进趋势

医学考试的标准不是一成不变的——几十年前认为正常的生理指标，今天可能被认为异常。AI代码修复评测基准同样经历了从简单到复杂、从静态到动态的演进，理解这段历史能帮我们判断评测结果的时代局限性。

早期的代码修复评测基准以合成Bug为主：研究者人为地在正确代码中埋入错误，测试模型对特定错误模式的修复能力。这类基准相当于「标准化病人」考试，优点是成本低、可重复，缺点是题目模式太规整，与真实Bug的复杂面貌相去甚远——标准化病人背熟了剧本，真实病人却可能同时患有三种合并症。

近年来的现代基准如SWE-bench完成了质变：直接用GitHub真实Issue作为考题，任务从「修复给定的一小段代码」升级为「在完整代码仓库中定位问题并修复」。到了这一代，AI医生面对的已经是真实的「急诊病人」，需要在五花八门的症状中抽丝剥茧。最新的趋势是「动态评测」——为了防止模型在评测数据上「刷题」（训练数据泄漏），评测集持续滚动更新，不断从最新社区Issue中取题。未来的方向包括多语言覆盖、多模态Bug报告理解，以及从「修复是否有效」走向「修复是否优雅」——评估补丁的安全性、性能开销和长期可维护性。

从标准化病人到真实临床轮转，医学生的考试越来越贴近真实的医患环境。AI代码修复评测也正从「人造题库」大步走向「真实战场」，评估标准只会越来越严、越来越专业。因为我们真正想要的不只是一个会做教科书例题的AI，而是一个能在一线代码战场上治病救人的「大医」。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""模拟AI代码修复能力评测流程"""import random SAMPLES = [    "def add(a, b):\n    return a + b",    "def max_val(x, y):\n    return x if x >= y else y",    "def is_even(n):\n    return n % 2 == 0"] TESTS = {    "add": [((1, 2), 3), ((-1, 1), 0), ((0, 5), 5)],    "max_val": [((1, 2), 2), ((5, 5), 5), ((-1, -3), -1)],    "is_even": [(2, True), (3, False), (0, True)]}  def inject_bug(source):    """模拟从真实项目收集Bug，这里用规则替换构造"""    if "a + b" in source:        return source.replace("a + b", "a - b")    if "x >= y" in source:        return source.replace("x >= y", "x > y")    if "n % 2" in source:        return source.replace("n % 2", "n % 3")    return source  def get_func_name(source):    """从代码中提取函数名"""    return source.split("(")[0].replace("def ", "").strip()  def run_tests(source, func_name):    """运行测试用例，全部通过返回True"""    namespace = {}    try:        exec(source, namespace)    except Exception:        return False    func = namespace[func_name]    for args, expected in TESTS[func_name]:        try:            if func(*args) != expected:                return False        except Exception:            return False    return True  def model_repair(buggy_source):    """模拟中等水平模型的修复行为（实际应调用LLM API）"""    rules = {        "a - b": "a + b",        "x > y": "x >= y",        "n % 3": "n % 2"    }    for bug, fix in rules.items():        if bug in buggy_source:            return buggy_source.replace(bug, fix)    return buggy_source  def main():    """主流程：注入Bug -> 模型修复 -> 测试判定 -> 统计修复率"""    random.seed(42)    total = len(SAMPLES)    fixed = 0    for source in SAMPLES:        buggy = inject_bug(source)        repaired = model_repair(buggy)        if run_tests(repaired, get_func_name(source)):            fixed += 1        else:            print(f"修复失败: {buggy.splitlines()[0]}")    print(f"评测完成: {total} 个Bug, 修复成功 {fixed} 个, 修复率 {fixed/total:.0%}")  if __name__ == "__main__":    main()

1. SAMPLES = [...]定义评测数据集，这里是三个正确函数，代表「健康样本」。
2. inject_bug(source)模拟真实世界收集到的Bug版本，对应评测数据集的「有缺陷代码」。
3. TESTS = {...}为每个函数预设测试用例，这就是判卷的「标准答案」。
4. run_tests(source, func_name)在隔离的命名空间中执行修复后代码并运行全部测试，完全等价于正文中的 Correct 判定函数。
5. namespace = {}用独立字典做执行环境，避免修复代码污染主进程，安全且干净。
6. model_repair(buggy_source)模拟模型生成修复补丁；真实项目中应当替换为调用大模型API。
7. fixed += 1每通过一个Bug的测试，计数器加一，最后除以总数得到修复率。

常见误区

面试题