解读 Aider LLM Leaderboards用代码编辑与重构基准量化 LLM 能力Qwen3-Coder 评测仓库实战指南【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder本指南基于 Qwen3-Coder 评测仓库随附的 Aider 官方排行榜文档leaderboards/index.md及配套榜单数据系统讲解 Aider 如何通过代码编辑基准与代码重构基准两套量化评测衡量一个 LLM 在真实 AI 结对编程场景中编辑既有代码而非单纯生成新代码的能力。读完本文你将掌握两大基准的任务构成、核心指标口径、whole/diff/udiff 等编辑格式的取舍原理、榜单数据文件的字段语义以及如何在本地复跑这套评测并贡献结果。Aider 是一款命令行 AI 结对编程工具其工作方式是让 LLM 以编辑格式返回对本地文件的修改。因此擅长写代码的模型未必擅长编辑代码——后者要求模型能持续遵循系统提示中的编辑协议、把改动准确落到既有源码文件中。Leaderboards 页面正是围绕这一核心命题展开用两套可复现的基准把编辑能力变成可比较的百分比数字。为什么需要代码编辑排行榜Aider 可以连接几乎所有 LLM参见 llms.md但文档明确指出Aider 与擅长编辑代码的模型配合最佳而非仅仅擅长生成代码。为了量化评估一个模型的编辑技能Aider 使用了一对基准benchmark专门考察模型能否始终如一地遵循系统提示system prompt中的编辑协议成功把意图中的代码改动以指定格式输出让这些改动能够被 Aider 识别、应用并保存到源码文件整个过程无需人工干预。Leaderboards 页面展示了大量流行 LLM 在上述基准上的结果用于指导用户该为 Aider 选哪个模型。原文档更新于 2024 年 9 月 5 日榜单数据文件随评测持续演进。基准一代码编辑基准Code Editing Benchmark任务构成133 个 Exercism Python 练习Aider 的代码编辑基准取材于 Exercism 社区的开源 Python 练习题集共133 个小练习详见 benchmarks.md。每个练习包含三部分InstructionsMarkdown 格式的题目说明描述要实现的函数/类行为Stub python code一个实现文件预先给出需要填充的函数或类骨架Unit tests独立的 Python 单元测试文件。模型的任务是读懂题目说明 → 在既有实现文件骨架中完成编码 → 让全部单元测试通过。这同时测了两件事模型的编码能力以及它能否写出能融入既有代码结构的新代码。评测流程两轮机会与错误回传基准运行流程是端到端的关键步骤为Aider 向模型发送实现文件的初始内容、Exercism 题目说明以及一条固定的最终指令Use the above instructions to modify the supplied files: implementation file Keep and implement the existing function or class stubs, they will be called from unit tests. Only use standard python libraries, dont suggest installing any packages.Aider 根据模型回复更新实现文件并运行单元测试。全部通过则该练习判为完成记录pass_rate_1若部分测试失败Aider 会向模型发送第二条消息附上测试错误输出的前 50 行避免撑爆小模型上下文窗口并附固定指令See the testing errors above. The tests are correct. Fix the code in implementation file to resolve the errors.这一二次机会机制是基准的重要设计它进一步施压模型的编辑技能依据失败反馈修正既有代码也给了模型在题目说明与单元测试要求存在歧义时自我修正的余地。最终结果记为pass_rate_2即两轮尝试后的最终完成率。值得注意的是整个评测过程中模型永远看不到单元测试源码只能看到失败时的错误输出。一个练习判为通过意味着模型做到了写出正确代码可能借助测试错误反馈并且把改动正确封装进编辑格式、让 Aider 能解析并保存反之任一环节断裂都会导致失败——写错代码、或编辑格式不合规导致改动未被正确落盘都会判失败。榜单数据编辑能力得分一览代码编辑排行榜数据存放在 edit_leaderboard.yml页面表格按pass_rate_2两轮尝试后的最终完成率降序渲染。下表节选数据文件中具有代表性的记录均为该数据文件记载的历史结果不代表模型当前最新版本表现ModelPercent completed correctly (pass_rate_2)Edit format对应启动命令claude-3.5-sonnet77.4%diffaider --sonnetgpt-4o-2024-05-1372.9%diffaiderDeepSeek Coder V2 072472.9%diffaider --model deepseek/deepseek-coderDeepSeek Chat V2.572.2%diffaider --deepseekgpt-4o-2024-08-0671.4%diffaider --model openai/gpt-4o-2024-08-06claude-3-opus-2024022968.4%diffaider --opusgpt-4-061367.7%diffaider -4llama-3.1-405b-instruct (whole)66.2%wholeaider --model openrouter/meta-llama/llama-3.1-405b-instructgpt-4-1106-preview65.4%udiffaider --model gpt-4-1106-previewQwen2 72B Instruct55.6%wholeaider --model together_ai/qwen/Qwen2-72B-Instructgpt-4o-mini55.6%wholeaider --model gpt-4o-miniYi Coder 9B Chat54.1%wholeaider --model openai/hf:01-ai/Yi-Coder-9B-Chatqwen2:72b-instruct-q8_0 (Ollama)49.6%wholeaider --model ollama/qwen2:72b-instruct-q8_0qwen1.5-110b-chat37.6%wholeaider --model together_ai/qwen/qwen1.5-110b-chatcodeqwen:7b-chat-v1.5-q8_0 (Ollama)34.6%wholeaider --model ollama/codeqwen:7b-chat-v1.5-q8_0从数据文件可观察到榜单中 Qwen 系列模型均以whole编辑格式参评且数据记录了每次运行的完整副产物如syntax_errors、indentation_errors、lazy_comments、user_asks、seconds_per_case、total_cost等便于还原每次评测的细节同时command字段记录了模型接入 Aider 的完整启动方式可直接复现。基准二代码重构基准Code Refactoring Benchmark设计动机激发并量化懒惰编码代码编辑基准的 133 个练习多为几十行的小问题不足以暴露大模型的懒惰编码lazy coding恶习——即模型在长代码上偷懒输出类似...add logic here...或...include original method body...的占位注释。为此 Aider 设计了更严苛的重构基准动机与细节见 unified-diffs.md从大型 Python 类中重构 89 个大型方法强制模型输出长段完整代码任何省略段落或制造错误都会失败。任务筛选与正确性校验从源码结构看重构任务是这样构造的用 Python 标准库ast模块分析 9 个流行的开源 Python 仓库筛选满足以下条件的重构对象源文件中包含实现体达100–250 个 AST 节点的非平凡方法该方法所属的类体量至少是该方法的 2 倍确保是从大 class中拆方法方法不使用self参数因而可以平凡地重构为顶层函数。随后把每个源文件包装为一个任务例如把CsrfViewMiddleware类中的_set_csrf_cookie方法重构为同名顶层函数并更新所有self._set_csrf_cookie调用。任务完成后基准通过四条启发式规则做基础校验更新后的源文件必须能被解析为合法 Python捕获错误应用的编辑目标方法必须已作为顶层函数存在于文件中新顶层函数的 AST 节点数应与原类方法大致相当防止模型省略代码、用注释充数原类必须仍存在且体量缩减量与移除方法的节点数大致吻合确认方法确被移出。这套校验并非严格的正确性证明但足以作为重构基本以剪切-粘贴完成、无代码被省略为注释的合理性检查且与lazy_comments等懒惰指标高度相关。重构任务依赖大上下文窗口处理大型源文件因此可参评模型较少数据见 refactor_leaderboard.yml该表按pass_rate_1排序ModelPercent completed correctly (pass_rate_1)Edit formatclaude-3-opus-2024022972.3%diffclaude-3.5-sonnet64.0%diffgpt-4o62.9%diffgpt-4-1106-preview50.6%udiffgpt-4o-2024-08-0649.4%diffgemini-1.5-pro-latest49.4%diff-fencedgpt-4-turbo-2024-04-09 (udiff)34.1%udiffDeepSeek Coder V2 072432.6%diffDeepSeek Chat V2.531.5%diff值得说明的是重构基准在diff格式下曾把 GPT-4 Turbo 的得分从基线 20% 提升到 61%懒惰注释从 12 个任务降到 4 个成为推动 Aider 采用 unified diff 编辑格式的关键实验证据。核心指标口径解读排行榜两个核心列的含义见原文档 Notes on benchmarking results 一节Percent completed correctly正确完成百分比模型成功完成编码任务的百分比。判为完成须同时满足解决编程题本身且以编辑格式正确输出改动使 Aider 能落盘实现。Percent using correct edit format使用正确编辑格式的百分比模型遵从系统提示中编辑格式的比例。若模型编辑输出有误Aider 会反馈错误并请求修正后的编辑头部模型能零差错稳定贴合格式。两条指标共同说明一个事实复杂编辑格式往往双重打击模型——既让模型写出更差的代码又降低其对输出格式的遵从度该结论在 benchmarks.md 的早期函数调用实验中有详细数据佐证。编辑格式体系从 whole 到 diff 的原理与源码印证四种主流格式Aider 通过不同编辑格式向不同 LLM 收集代码改动原文档将其归纳为两类whole整文件格式要求模型返回整个文件的更新副本用 Markdown 三反引号代码块包裹并在代码块前标注文件名。这是对模型最友好的格式但 token 开销大且会限制可编辑文件的大小。示例源自 benchmarks.mdHere is the updated copy of your file demo.py: demo.py python def main(): print(goodbye) diffSEARCH/REPLACE 块格式要求模型在响应中给出每个文件的 ORIGINAL 与 UPDATED 代码块只改动必要行。示例Here are the changes you requested to demo.py: python demo.py ORIGINAL print(hello) print(goodbye) UPDATED udiffunified diff格式采用类git diff的 hunk 结构但Aider 明确要求模型省略行号 ... 把每个 hunk 当作一次搜索-替换操作来解释。由于 unified diff 是git diff的默认输出模型在训练数据中见过大量范例更容易稳定生成。设计原则可归纳为四个词熟悉FAMILIAR、简单SIMPLE、高层HIGH LEVEL、灵活FLEXIBLE。diff-fenced 格式diff 的变体将编辑块用带标记的围栏分隔如 Gemini 系列模型使用。格式选择策略与源码对应从 Aider 源码模块结构看每种格式都有对应的 coder 实现编辑格式对应源码模块wholewholefile_coder.py、wholefile_prompts.pydiffSEARCH/REPLACEeditblock_coder.py、editblock_prompts.pyudiffudiff_coder.py、udiff_prompts.pydiff-fencededitblock_fenced_coder.py函数调用类历史上评测过的方案wholefile_func_coder.py、editblock_func_coder.py策略上Aider 对主流 OpenAI、Anthropic 模型及 llms.md 推荐的模型自动配置最优格式对知名度较低的模型则默认回退到whole对模型最容易。早期基准实验benchmarks.md还发现基于函数调用 API 的编辑格式表现更差——把源码塞进 JSON 的转义问题频发GPT-3.5 尤其容易输出语义非法的function_call片段。应用编辑时的灵活修补策略模型产出的 diff 往往不完美遗漏注释、忘记前缀、整体缩进偏移、未开新 hunk 就跳跃编辑等。为此 Aider 在应用 diff 时采用层层递进的容错策略详见 unified-diffs.md将 hunk 的-/空格行与空格/行分别视为两个版本做一次真实的 unified diff 归一化通过把-/空格行与原始文件反查 diff找回模型忘记标记的新增行支持相对前导空白匹配容忍 hunk 被整体缩进或反缩进把大 hunk 拆成只含单段/-连续行的重叠子 hunk逐段独立尝试应用变化用于定位编辑位置的上下文窗口空格行的大小与偏移组合以上机制逐步放宽匹配条件。这一灵活修补层是 Aider 编辑能力的基石实验显示在 Exercism 基准上禁用灵活修补会使编辑错误增加 9 倍。榜单数据文件与页面渲染机制排行榜页面leaderboards/index.md本身是 Jekyll 站点页面榜单表格并非硬编码而是通过 Liquid 模板从数据文件动态生成{% assign edit_sorted site.data.edit_leaderboard | sort: pass_rate_2 | reverse %}编辑榜按pass_rate_2降序{% assign refac_sorted site.data.refactor_leaderboard | sort: pass_rate_1 | reverse %}重构榜按pass_rate_1降序。页面同时内嵌 Chart.js 交互柱状图支持点击表格行筛选对比。数据文件每条记录除模型名、得分、格式、命令外还沉淀了完整评测元数据字段语义如下字段含义model/released模型名与其发布时间edit_format评测所用编辑格式whole / diff / udiff / diff-fencedpass_rate_1第一轮尝试后的完成率pass_rate_2含测试错误反馈后的最终完成率编辑榜主排序指标percent_cases_well_formed编辑格式合规率error_outputs/num_malformed_responses错误输出数 / 畸形响应数user_asks需要向用户提问的次数lazy_comments懒惰注释出现次数syntax_errors/indentation_errors语法错误 / 缩进错误次数exhausted_context_windows/test_timeouts上下文窗口耗尽 / 测试超时次数seconds_per_case/total_cost单例平均耗时 / 总成本美元command复现该结果的完整 Aider 启动命令versions/date/commit_hash评测所用 Aider 版本、日期与代码提交其中error_outputs的统计口径是需要向模型反馈并请求修正编辑的次数因此它与percent_cases_well_formed共同刻画了模型产出编辑的一次成型率。此外原文档还提供LLM code editing skill by model release date按模型发布日期的编辑技能散点图models-over-time.svg用于观察模型迭代对编辑能力的影响趋势。本地复现与贡献排行榜结果原文档明确欢迎社区贡献基准结果。完整运行流程记录在 benchmark/README.md要点如下安全前提基准会执行 LLM 生成的 Python 代码且无人审查必须在 Docker 容器内运行以隔离风险。准备工作包括克隆 Exercism Python 仓库、把 practice 练习复制到tmp.benchmarks/exercism-python、执行./benchmark/docker_build.sh构建镜像。运行基准进入容器后以开发模式安装 aider然后执行./benchmark/benchmark.py a-helpful-name-for-this-run \ --model gpt-3.5-turbo \ --edit-format whole \ --threads 10常用参数说明--model模型名与直接传给 Aider 的写法一致--edit-format编辑格式名评测实验性模型时建议从whole起步--threads并行跑的练习数调试新模型时先用单线程稳定后可加大对 OpenAI API 10 线程效果良好--num-tests提前终止——只跑前 N 个练习便于小规模调试--keywords按名称过滤练习类似pytest -k xxxx。运行结果落在tmp.benchmarks/YYYY-MM-DD-HH-MM-SS--名称/目录。生成报告./benchmark/benchmark.py --stats tmp.benchmarks/...可对任意含进行中的评测目录生成统计此步无需 Docker只统计、不执行不安全代码。提交结果将新结果整理进website/_data/下的edit_leaderboard.yml或refactor_leaderboard.yml通过 PR 合入即可更新排行榜页面。在 Qwen3-Coder 评测仓库中的定位与使用方式在本仓库中Aider 评测位于qwencoder-eval/instruct/aider/是 instruct指令遵循/对话式评测体系的一环随附了完整源码、基准工具benchmark、tests与官网文档website/docs。对于希望评估代码模型编辑/重构能力的团队可参照上文流程用同一套基准对模型包括 Qwen 系列模型进行横向对比。需要强调的适用前提与边界榜单数据文件中的结果是特定时间点、特定模型版本、特定编辑格式下的记录模型发布后能力可能已变化引用时不应视为当前最新表现whole格式得分与diff格式得分不宜直接跨格式比较不同格式对模型难度与 token 成本差异显著重构基准只做合理性检查可解析、AST 节点数、类体量缩减并非严格的功能等价验证OpenAI 系 API 即使在temperature0下也存在少量随机性同一请求通常产生 5–10 种变体个别临界练习的结果可能受 API 负载均衡影响133 个练习的规模本身已提供一定鲁棒性。结语Aider LLM Leaderboards 的价值在于把代码编辑能力这一模糊概念操作化为两个可复现的量化基准133 个 Exercism 练习度量融入既有代码的编辑能力89 个大型方法重构任务度量长代码不偷懒的重构能力而 whole/diff/udiff 等编辑格式与灵活修补策略则构成了 Aider 与模型协作的技术底座。对任何评估或使用代码模型的人来说这套基准、数据文件与复现工具均在当前仓库内都是一份可直接上手、可交叉验证的完整参照系。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 解读 Aider LLM Leaderboards：用代码编辑与重构基准量化 LLM 能力（Qwen3-Coder 评测仓库实战指南）
解读 Aider LLM Leaderboards用代码编辑与重构基准量化 LLM 能力Qwen3-Coder 评测仓库实战指南【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder本指南基于 Qwen3-Coder 评测仓库随附的 Aider 官方排行榜文档leaderboards/index.md及配套榜单数据系统讲解 Aider 如何通过代码编辑基准与代码重构基准两套量化评测衡量一个 LLM 在真实 AI 结对编程场景中编辑既有代码而非单纯生成新代码的能力。读完本文你将掌握两大基准的任务构成、核心指标口径、whole/diff/udiff 等编辑格式的取舍原理、榜单数据文件的字段语义以及如何在本地复跑这套评测并贡献结果。Aider 是一款命令行 AI 结对编程工具其工作方式是让 LLM 以编辑格式返回对本地文件的修改。因此擅长写代码的模型未必擅长编辑代码——后者要求模型能持续遵循系统提示中的编辑协议、把改动准确落到既有源码文件中。Leaderboards 页面正是围绕这一核心命题展开用两套可复现的基准把编辑能力变成可比较的百分比数字。为什么需要代码编辑排行榜Aider 可以连接几乎所有 LLM参见 llms.md但文档明确指出Aider 与擅长编辑代码的模型配合最佳而非仅仅擅长生成代码。为了量化评估一个模型的编辑技能Aider 使用了一对基准benchmark专门考察模型能否始终如一地遵循系统提示system prompt中的编辑协议成功把意图中的代码改动以指定格式输出让这些改动能够被 Aider 识别、应用并保存到源码文件整个过程无需人工干预。Leaderboards 页面展示了大量流行 LLM 在上述基准上的结果用于指导用户该为 Aider 选哪个模型。原文档更新于 2024 年 9 月 5 日榜单数据文件随评测持续演进。基准一代码编辑基准Code Editing Benchmark任务构成133 个 Exercism Python 练习Aider 的代码编辑基准取材于 Exercism 社区的开源 Python 练习题集共133 个小练习详见 benchmarks.md。每个练习包含三部分InstructionsMarkdown 格式的题目说明描述要实现的函数/类行为Stub python code一个实现文件预先给出需要填充的函数或类骨架Unit tests独立的 Python 单元测试文件。模型的任务是读懂题目说明 → 在既有实现文件骨架中完成编码 → 让全部单元测试通过。这同时测了两件事模型的编码能力以及它能否写出能融入既有代码结构的新代码。评测流程两轮机会与错误回传基准运行流程是端到端的关键步骤为Aider 向模型发送实现文件的初始内容、Exercism 题目说明以及一条固定的最终指令Use the above instructions to modify the supplied files: implementation file Keep and implement the existing function or class stubs, they will be called from unit tests. Only use standard python libraries, dont suggest installing any packages.Aider 根据模型回复更新实现文件并运行单元测试。全部通过则该练习判为完成记录pass_rate_1若部分测试失败Aider 会向模型发送第二条消息附上测试错误输出的前 50 行避免撑爆小模型上下文窗口并附固定指令See the testing errors above. The tests are correct. Fix the code in implementation file to resolve the errors.这一二次机会机制是基准的重要设计它进一步施压模型的编辑技能依据失败反馈修正既有代码也给了模型在题目说明与单元测试要求存在歧义时自我修正的余地。最终结果记为pass_rate_2即两轮尝试后的最终完成率。值得注意的是整个评测过程中模型永远看不到单元测试源码只能看到失败时的错误输出。一个练习判为通过意味着模型做到了写出正确代码可能借助测试错误反馈并且把改动正确封装进编辑格式、让 Aider 能解析并保存反之任一环节断裂都会导致失败——写错代码、或编辑格式不合规导致改动未被正确落盘都会判失败。榜单数据编辑能力得分一览代码编辑排行榜数据存放在 edit_leaderboard.yml页面表格按pass_rate_2两轮尝试后的最终完成率降序渲染。下表节选数据文件中具有代表性的记录均为该数据文件记载的历史结果不代表模型当前最新版本表现ModelPercent completed correctly (pass_rate_2)Edit format对应启动命令claude-3.5-sonnet77.4%diffaider --sonnetgpt-4o-2024-05-1372.9%diffaiderDeepSeek Coder V2 072472.9%diffaider --model deepseek/deepseek-coderDeepSeek Chat V2.572.2%diffaider --deepseekgpt-4o-2024-08-0671.4%diffaider --model openai/gpt-4o-2024-08-06claude-3-opus-2024022968.4%diffaider --opusgpt-4-061367.7%diffaider -4llama-3.1-405b-instruct (whole)66.2%wholeaider --model openrouter/meta-llama/llama-3.1-405b-instructgpt-4-1106-preview65.4%udiffaider --model gpt-4-1106-previewQwen2 72B Instruct55.6%wholeaider --model together_ai/qwen/Qwen2-72B-Instructgpt-4o-mini55.6%wholeaider --model gpt-4o-miniYi Coder 9B Chat54.1%wholeaider --model openai/hf:01-ai/Yi-Coder-9B-Chatqwen2:72b-instruct-q8_0 (Ollama)49.6%wholeaider --model ollama/qwen2:72b-instruct-q8_0qwen1.5-110b-chat37.6%wholeaider --model together_ai/qwen/qwen1.5-110b-chatcodeqwen:7b-chat-v1.5-q8_0 (Ollama)34.6%wholeaider --model ollama/codeqwen:7b-chat-v1.5-q8_0从数据文件可观察到榜单中 Qwen 系列模型均以whole编辑格式参评且数据记录了每次运行的完整副产物如syntax_errors、indentation_errors、lazy_comments、user_asks、seconds_per_case、total_cost等便于还原每次评测的细节同时command字段记录了模型接入 Aider 的完整启动方式可直接复现。基准二代码重构基准Code Refactoring Benchmark设计动机激发并量化懒惰编码代码编辑基准的 133 个练习多为几十行的小问题不足以暴露大模型的懒惰编码lazy coding恶习——即模型在长代码上偷懒输出类似...add logic here...或...include original method body...的占位注释。为此 Aider 设计了更严苛的重构基准动机与细节见 unified-diffs.md从大型 Python 类中重构 89 个大型方法强制模型输出长段完整代码任何省略段落或制造错误都会失败。任务筛选与正确性校验从源码结构看重构任务是这样构造的用 Python 标准库ast模块分析 9 个流行的开源 Python 仓库筛选满足以下条件的重构对象源文件中包含实现体达100–250 个 AST 节点的非平凡方法该方法所属的类体量至少是该方法的 2 倍确保是从大 class中拆方法方法不使用self参数因而可以平凡地重构为顶层函数。随后把每个源文件包装为一个任务例如把CsrfViewMiddleware类中的_set_csrf_cookie方法重构为同名顶层函数并更新所有self._set_csrf_cookie调用。任务完成后基准通过四条启发式规则做基础校验更新后的源文件必须能被解析为合法 Python捕获错误应用的编辑目标方法必须已作为顶层函数存在于文件中新顶层函数的 AST 节点数应与原类方法大致相当防止模型省略代码、用注释充数原类必须仍存在且体量缩减量与移除方法的节点数大致吻合确认方法确被移出。这套校验并非严格的正确性证明但足以作为重构基本以剪切-粘贴完成、无代码被省略为注释的合理性检查且与lazy_comments等懒惰指标高度相关。重构任务依赖大上下文窗口处理大型源文件因此可参评模型较少数据见 refactor_leaderboard.yml该表按pass_rate_1排序ModelPercent completed correctly (pass_rate_1)Edit formatclaude-3-opus-2024022972.3%diffclaude-3.5-sonnet64.0%diffgpt-4o62.9%diffgpt-4-1106-preview50.6%udiffgpt-4o-2024-08-0649.4%diffgemini-1.5-pro-latest49.4%diff-fencedgpt-4-turbo-2024-04-09 (udiff)34.1%udiffDeepSeek Coder V2 072432.6%diffDeepSeek Chat V2.531.5%diff值得说明的是重构基准在diff格式下曾把 GPT-4 Turbo 的得分从基线 20% 提升到 61%懒惰注释从 12 个任务降到 4 个成为推动 Aider 采用 unified diff 编辑格式的关键实验证据。核心指标口径解读排行榜两个核心列的含义见原文档 Notes on benchmarking results 一节Percent completed correctly正确完成百分比模型成功完成编码任务的百分比。判为完成须同时满足解决编程题本身且以编辑格式正确输出改动使 Aider 能落盘实现。Percent using correct edit format使用正确编辑格式的百分比模型遵从系统提示中编辑格式的比例。若模型编辑输出有误Aider 会反馈错误并请求修正后的编辑头部模型能零差错稳定贴合格式。两条指标共同说明一个事实复杂编辑格式往往双重打击模型——既让模型写出更差的代码又降低其对输出格式的遵从度该结论在 benchmarks.md 的早期函数调用实验中有详细数据佐证。编辑格式体系从 whole 到 diff 的原理与源码印证四种主流格式Aider 通过不同编辑格式向不同 LLM 收集代码改动原文档将其归纳为两类whole整文件格式要求模型返回整个文件的更新副本用 Markdown 三反引号代码块包裹并在代码块前标注文件名。这是对模型最友好的格式但 token 开销大且会限制可编辑文件的大小。示例源自 benchmarks.mdHere is the updated copy of your file demo.py: demo.py python def main(): print(goodbye) diffSEARCH/REPLACE 块格式要求模型在响应中给出每个文件的 ORIGINAL 与 UPDATED 代码块只改动必要行。示例Here are the changes you requested to demo.py: python demo.py ORIGINAL print(hello) print(goodbye) UPDATED udiffunified diff格式采用类git diff的 hunk 结构但Aider 明确要求模型省略行号 ... 把每个 hunk 当作一次搜索-替换操作来解释。由于 unified diff 是git diff的默认输出模型在训练数据中见过大量范例更容易稳定生成。设计原则可归纳为四个词熟悉FAMILIAR、简单SIMPLE、高层HIGH LEVEL、灵活FLEXIBLE。diff-fenced 格式diff 的变体将编辑块用带标记的围栏分隔如 Gemini 系列模型使用。格式选择策略与源码对应从 Aider 源码模块结构看每种格式都有对应的 coder 实现编辑格式对应源码模块wholewholefile_coder.py、wholefile_prompts.pydiffSEARCH/REPLACEeditblock_coder.py、editblock_prompts.pyudiffudiff_coder.py、udiff_prompts.pydiff-fencededitblock_fenced_coder.py函数调用类历史上评测过的方案wholefile_func_coder.py、editblock_func_coder.py策略上Aider 对主流 OpenAI、Anthropic 模型及 llms.md 推荐的模型自动配置最优格式对知名度较低的模型则默认回退到whole对模型最容易。早期基准实验benchmarks.md还发现基于函数调用 API 的编辑格式表现更差——把源码塞进 JSON 的转义问题频发GPT-3.5 尤其容易输出语义非法的function_call片段。应用编辑时的灵活修补策略模型产出的 diff 往往不完美遗漏注释、忘记前缀、整体缩进偏移、未开新 hunk 就跳跃编辑等。为此 Aider 在应用 diff 时采用层层递进的容错策略详见 unified-diffs.md将 hunk 的-/空格行与空格/行分别视为两个版本做一次真实的 unified diff 归一化通过把-/空格行与原始文件反查 diff找回模型忘记标记的新增行支持相对前导空白匹配容忍 hunk 被整体缩进或反缩进把大 hunk 拆成只含单段/-连续行的重叠子 hunk逐段独立尝试应用变化用于定位编辑位置的上下文窗口空格行的大小与偏移组合以上机制逐步放宽匹配条件。这一灵活修补层是 Aider 编辑能力的基石实验显示在 Exercism 基准上禁用灵活修补会使编辑错误增加 9 倍。榜单数据文件与页面渲染机制排行榜页面leaderboards/index.md本身是 Jekyll 站点页面榜单表格并非硬编码而是通过 Liquid 模板从数据文件动态生成{% assign edit_sorted site.data.edit_leaderboard | sort: pass_rate_2 | reverse %}编辑榜按pass_rate_2降序{% assign refac_sorted site.data.refactor_leaderboard | sort: pass_rate_1 | reverse %}重构榜按pass_rate_1降序。页面同时内嵌 Chart.js 交互柱状图支持点击表格行筛选对比。数据文件每条记录除模型名、得分、格式、命令外还沉淀了完整评测元数据字段语义如下字段含义model/released模型名与其发布时间edit_format评测所用编辑格式whole / diff / udiff / diff-fencedpass_rate_1第一轮尝试后的完成率pass_rate_2含测试错误反馈后的最终完成率编辑榜主排序指标percent_cases_well_formed编辑格式合规率error_outputs/num_malformed_responses错误输出数 / 畸形响应数user_asks需要向用户提问的次数lazy_comments懒惰注释出现次数syntax_errors/indentation_errors语法错误 / 缩进错误次数exhausted_context_windows/test_timeouts上下文窗口耗尽 / 测试超时次数seconds_per_case/total_cost单例平均耗时 / 总成本美元command复现该结果的完整 Aider 启动命令versions/date/commit_hash评测所用 Aider 版本、日期与代码提交其中error_outputs的统计口径是需要向模型反馈并请求修正编辑的次数因此它与percent_cases_well_formed共同刻画了模型产出编辑的一次成型率。此外原文档还提供LLM code editing skill by model release date按模型发布日期的编辑技能散点图models-over-time.svg用于观察模型迭代对编辑能力的影响趋势。本地复现与贡献排行榜结果原文档明确欢迎社区贡献基准结果。完整运行流程记录在 benchmark/README.md要点如下安全前提基准会执行 LLM 生成的 Python 代码且无人审查必须在 Docker 容器内运行以隔离风险。准备工作包括克隆 Exercism Python 仓库、把 practice 练习复制到tmp.benchmarks/exercism-python、执行./benchmark/docker_build.sh构建镜像。运行基准进入容器后以开发模式安装 aider然后执行./benchmark/benchmark.py a-helpful-name-for-this-run \ --model gpt-3.5-turbo \ --edit-format whole \ --threads 10常用参数说明--model模型名与直接传给 Aider 的写法一致--edit-format编辑格式名评测实验性模型时建议从whole起步--threads并行跑的练习数调试新模型时先用单线程稳定后可加大对 OpenAI API 10 线程效果良好--num-tests提前终止——只跑前 N 个练习便于小规模调试--keywords按名称过滤练习类似pytest -k xxxx。运行结果落在tmp.benchmarks/YYYY-MM-DD-HH-MM-SS--名称/目录。生成报告./benchmark/benchmark.py --stats tmp.benchmarks/...可对任意含进行中的评测目录生成统计此步无需 Docker只统计、不执行不安全代码。提交结果将新结果整理进website/_data/下的edit_leaderboard.yml或refactor_leaderboard.yml通过 PR 合入即可更新排行榜页面。在 Qwen3-Coder 评测仓库中的定位与使用方式在本仓库中Aider 评测位于qwencoder-eval/instruct/aider/是 instruct指令遵循/对话式评测体系的一环随附了完整源码、基准工具benchmark、tests与官网文档website/docs。对于希望评估代码模型编辑/重构能力的团队可参照上文流程用同一套基准对模型包括 Qwen 系列模型进行横向对比。需要强调的适用前提与边界榜单数据文件中的结果是特定时间点、特定模型版本、特定编辑格式下的记录模型发布后能力可能已变化引用时不应视为当前最新表现whole格式得分与diff格式得分不宜直接跨格式比较不同格式对模型难度与 token 成本差异显著重构基准只做合理性检查可解析、AST 节点数、类体量缩减并非严格的功能等价验证OpenAI 系 API 即使在temperature0下也存在少量随机性同一请求通常产生 5–10 种变体个别临界练习的结果可能受 API 负载均衡影响133 个练习的规模本身已提供一定鲁棒性。结语Aider LLM Leaderboards 的价值在于把代码编辑能力这一模糊概念操作化为两个可复现的量化基准133 个 Exercism 练习度量融入既有代码的编辑能力89 个大型方法重构任务度量长代码不偷懒的重构能力而 whole/diff/udiff 等编辑格式与灵活修补策略则构成了 Aider 与模型协作的技术底座。对任何评估或使用代码模型的人来说这套基准、数据文件与复现工具均在当前仓库内都是一份可直接上手、可交叉验证的完整参照系。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考