企业官网建设流程全解析

Aider 的 SWE Bench Lite 评测全解析：26.3% pass@1 背后的仓库地图与可靠代码编辑（基于 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

本篇文章以 2024-05-22-swe-bench-lite.md 为核心骨架，结合仓库内完整保留的 Aider 源码（qwencoder-eval/instruct/aider/aider/）与基准测试工具（qwencoder-eval/instruct/aider/benchmark/），系统拆解 Aider 在 SWE Bench Lite 上取得 26.3% pass@1（unhinted）成绩的评测方法论、核心技术路径与工程实现，帮助读者理解"如何用交互式结对编程工具，而非重 agentic 框架，在真实代码库上解决 GitHub Issue"，并掌握仓库地图、静态检查、测试驱动修复等可直接复用的实战能力。

一、评测背景与核心结果

2024 年 5 月 22 日发布的结果显示，Aider 在 SWE Bench Lite 基准上取得了26.3%的成绩，成为当时该榜单的新 SOTA。此前榜单最高记录为 Amazon Q Developer Agent 的20.3%。

需要特别强调的评测口径（这也是该成绩可复现、可比较的前提）：

• 所有结果均为 pass@1 结果，即每个问题只提交一个候选补丁（model_patch）参与验收测试，内部多次尝试只用于挑选这一个候选；
• 全程未使用 SWE Bench 的hints_text（官方榜单只接受不带 hint 的 pass@1 结果）；
• 对比图表在 5/30 做过修正，改为对等的 pass@1、unhinted 数据。

在这一口径下，文章还报告了两个重要子结果：

• 仅用 Aider + GPT-4o 单跑即可达到25.0%，本身已与当时 SOTA 持平；
• Aider + GPT-4o 与 Opus 交替后达到26.3%。

这些数字是文档发布当时的记录，且全部建立在"基准测试 harness 与 Aider 只能访问每个问题仓库中已有的测试"这一前提下，held-out 的验收测试仅在评分阶段使用。

二、交互式而非 Agentic：Aider 的设计哲学

Aider 取得该成绩并非依靠更强的 agent 行为，恰恰相反，它刻意保持了相当有限且克制的 agentic 行为，以避免长延迟、高 token 成本以及用户反复审查错误方案的开销。

从源码结构可以印证这一设计取向：aider 主目录 中的核心模块是args.py（参数解析）、coders/（对话编码器）、repomap.py（仓库地图）、linter.py（静态检查）、repo.py（git 集成）等——它首先是一个供工程师在真实代码库中通过聊天界面完成实际工作的交互式工具，而不是一个自主决策的 agent 框架。

该评测发布时 Aider 并未使用 RAG、向量检索、工具调用，也不允许 LLM 联网搜索或单方面执行代码。它的工作方式是：

1. 用户在聊天界面提出修改请求；
2. 用户实时看到代码编辑被执行；
3. Aider 提供额外辅助（修复 lint / 测试错误）；
4. 用户始终处于完整的交互控制中，可以随时把误解拉回正轨，避免浪费时间和 token。

这也是 Aider 在基准测试外被设计为交互使用的原因——任何 AI agent 在无人监督下运行于真实代码库都是不明智或至少是低效的。

三、基准测试方法：harness 如何驱动 Aider

3.1 运行方式

在评测中，Aider 在每个问题的 git 仓库内被启动，问题陈述作为开场聊天消息提交。之后 Aider 正常运行，仅做了以下修改：

• Aider 的建议始终被接受，无需用户批准；
• 一个简单的 harness 用于在 Aider 产出非"合理正确"（plausibly correct）代码时重试该问题；
• 若未找到合理方案，harness 会从头重启 Aider 再次尝试，在 GPT-4o 与 Opus 之间交替；
• 六次尝试后仍无合理方案，则选择编辑/lint/测试问题最少的方案。

"合理正确"（plausibly correct）的定义是：Aider 报告它已成功编辑仓库，且没有引入语法错误、没有破坏任何预先存在的测试。

3.2 与真实开发流程的对应关系

评测过程与开发者用 Aider 解决 GitHub Issue 的方式高度一致：

• 用如下命令启动 Aider，表示接受所有建议、并用 pytest 跑测试：

  aider --yes --test-cmd pytest

• 把 GitHub Issue 的 URL 或文本粘贴进聊天即可开始；
• 若 Aider 产出的代码不能通过 lint 与测试，开发者可以回退更改后用另一个 LLM 重试——Aider 与 git 深度集成，随时可以轻松回退不理想的 AI 改动。

这一点在仓库参数解析中可以得到印证：args.py 中定义了--yes、--test-cmd（指定运行测试的命令）、--auto-lint（修改后自动 lint，默认 True）、--auto-test（修改后自动测试，默认 False）、--test（运行测试并修复发现的问题）等参数，与评测描述一一对应。

四、结果数据：两次模型的逐轮尝试分解

4.1 按尝试轮次分解（300 个问题）

harness 按固定顺序交替运行，总是先用 GPT-4o，再与 Opus 交替，直到每个问题找到合理方案。下表完整列出 300 个问题中按尝试轮次找到的合理方案，以及最终被验收测试确认正确解决了 Issue 的数量：

值得注意的观察点：

• 仅第一次尝试（Aider + GPT-4o）就解决了 20.3% 的问题，与当时官方榜单第一的 Amazon Q Developer Agent 持平；
• 包含第二次尝试后得分为 23.6%，前两次尝试获得了约75% 的合理方案与约90% 的正确解决方案；
• 存在一条长尾：两个模型持续在后续尝试中找到方案，甚至有一个问题是在该问题的第六次（最后一次）尝试中才被正确解决。

4.2 按模型拆分

若仅按模型拆分方案，可看到 Aider + GPT-4o 优于 Opus——但这不是公平的直接对比，因为 GPT-4o 总是先手，抢先拿到了所有"最容易"的问题；Opus 只见到 GPT-4o 首次尝试未找到合理方案的问题：

五、核心能力一：仓库地图（Repository Map），而非 RAG

解决 SWE Bench 问题的关键第一步，是判断仓库的哪些部分相关、需要编辑哪些文件。多数编码 agent 使用 RAG、向量检索，或给 LLM 提供交互式探索代码库的工具。

Aider 的替代方案是 仓库地图：通过代码 AST（抽象语法树）与调用图的静态分析，生成整个代码库紧凑而强大的摘要；地图会随着对话状态持续定制，只展示与当前聊天相关的仓库上下文，其实现方式是对代码调用图做图优化。

5.1 源码实现证据

从 repomap.py 可以看到：

• 基于 tree-sitter 对每个文件抽取 tags（get_tags_raw，见 repomap.py#L202），区分def（定义）与ref（引用）；
• get_ranked_tags（见 repomap.py#L278）使用networkx.MultiDiGraph构建符号定义-引用图，并借助PageRank 个性化（personalization）让图排序向"当前聊天文件中涉及的符号、用户提到的文件与标识符"倾斜；
• 生成的 ranked tags 再被组织成层级树（to_tree，见 repomap.py#L595），按预算 token 数量裁剪后作为地图上下文注入；
• 仓库地图结果缓存在.aider.tags.cache.v{N}（TAGS_CACHE_DIR，见 repomap.py#L32），大仓库的首次扫描较慢但只发生一次。

5.2 工作流：LLM 提名文件，用户确认入聊

当用户请求修改代码时，LLM 可以借助仓库地图决定编辑哪些文件，并直接返回普通文本解释。Aider 注意到 LLM 提到仓库中的文件名时，会询问用户是否加入聊天；加入后 LLM 才能看到该文件全文并编辑它。原文给出了一个典型会话：

#### Please add a new /factorial/N endpoint. To add a new /factorial/N endpoint, the most likely file that needs to be edited is app.py. Please add app.py to the chat so I can proceed with the changes. > app.py > Add these files to the chat? yes

这一自然流畅的交互流程在 SWE Bench 问题上表现良好：Aider 在 70.3% 的基准任务中正确识别出了应编辑的文件。该统计是利用每个任务关联的 "gold" patch（人类开发者写的参考补丁）在评测过程之外计算的——Aider 在求解时完全看不到 gold patch 或其包含的文件名。

六、核心能力二：可靠的代码编辑（Reliable Code Editing）

选定文件后，下一步自然是从源码层面把问题修好。Aider 在保证 LLM 不仅能"写代码"、更能"可靠地编辑代码"上投入了大量工作：

• 拥有一系列提示策略与代码编辑后端（edit 格式），这些能力通过 benchmark 目录 中的代码编辑基准持续打磨（该目录基于 Exercism 练习构造端到端评测，见 benchmark/README.md）；
• 仓库地图在此同样发挥作用，确保 LLM 能看到整个仓库相关的类、函数与变量，使新增代码尊重项目既有 API 与约定；
• 即使如此，仍存在 LLM 未遵守编辑指令（system prompt 中的编辑格式约束）而无法干净完成编辑的情况。此时 Aider 完成时会返回一个编辑结果状态（editing outcome），指示是否成功应用了全部编辑——基准 harness 正是把它作为判断"合理方案"的标准之一。

七、核心能力三：Lint 与自动修复

"合理方案"的另一关键标准是通过基础 lint（无语法错误或其它致命错误）。Aider 在每次 LLM 编辑后都会 lint 代码，并提供自动修复。

7.1 tree-sitter 内置 linter

源码层面，linter.py 实现了完整链路：

• 内置基于 tree-sitter 的 linter（from tree_sitter_languages import get_parser），支持大多数主流语言；
• basic_lint（见 linter.py#L195）用 tree-sitter 查找语法错误，并结合 AST 展示带上下文（tree context）的错误；
• Python 场景还叠加compile检查与 flake8（py_lint，见 linter.py#L112）；
• lint 结果通过tree_context以新颖的格式回传给 LLM——用 AST 展示每个错误相关的代码上下文，帮助 LLM 理解问题并做出正确修改。

7.2 错误反馈会话示例

app.py:23:36: F821 undefined name 'num' app.py: ...⋮... 6│class LongNum: ...⋮... 19│ def expound(self, threshold): 20│ number = self.basis 21│ while number < threshold: 22│ number *= self.factor 23█ return num 24│ 25│ ...⋮... > Attempt to fix lint errors? yes

在基准测试中，这些 lint 修复建议总是被接受。完成后 Aider 报告 lint outcome，指示是否产出了无未解决 lint 错误的代码；harness 同样以该状态作为"合理方案"的判定标准之一。

八、核心能力四：测试与修复

"合理方案"的最后一个标准是所有测试通过。Aider 可配置仓库的测试运行命令，并自动尝试修复测试失败。

Python 项目的典型启动方式：

aider --test-cmd pytest

评测中，Aider 被配置为运行每个问题仓库中已存在的测试。SWE Bench 问题来自拥有大量现有测试套件的开源项目，因此：Aider 若破坏了任何既有测试、或新建的测试未通过，测试环节都会失败。

与编辑、lint 一样，Aider 会报告 testing outcome，指示完成时是否还有未通过的测试；harness 以此作为"合理方案"的判定标准。

需要再次澄清：Aider 无法运行、甚至无法看到被 hold out 的"验收测试"——那些测试只在评分阶段、在 Aider 与 harness 之外运行。

九、寻找合理方案（Plausible Solution）的完整流程

每次 Aider 执行都会报告编辑、lint、测试三个环节的结果，每个环节可能成功或存在未解决问题。harness 据此判定：

1. 若 Aider 返回"已编辑仓库且无未解决的编辑/lint/测试错误"，则该方案为合理方案，其改动被记录为 SWE Bench 的model_patch，留待验收测试评估；
2. 若非合理，则从头重启 Aider再次求解同一问题，GPT-4o 与 Opus 交替，各三次，共六次尝试；
3. 一旦找到合理方案立即接受，进入下一个实例；
4. 若仓库本身在 Aider 编辑前就存在 lint/测试错误（无论由谁引入），六次尝试后仍可能找不到合理方案。

六次全失败时，harness 选择"最佳"可用方案作为model_patch——忽略测试结果，按以下优先级排序：

• 优先选择"编辑完成且 lint 成功"的方案；
• 其次"编辑至少部分成功且 lint 成功"；
• 再次"编辑成功"；
• 最后"编辑至少部分成功"。

十、计算基准得分：79/300 = 26.3%

harness 为全部 300 个 SWE Bench Lite 实例产出了合理方案并保存为model_patch。随后使用独立的评测脚本，用**完整测试套件（含 held-out 验收测试）**逐个测试这些方案：

• 验收测试前，Aider 对测试文件所做的任何编辑都会被丢弃，确保使用正确、未修改的测试套件；
• 评测脚本将候选方案与人类开发的 gold patch的测试结果对比，匹配即视为正确解决；
• 这些验收测试只在 Aider 与 harness 之外运行，且仅用于计算正确解决数，求解过程中从未运行、使用甚至可见。

最终：300 个实例中正确解决 79 个，即 26.3%。

十一、pass@1 口径与结果可比性说明

文中所有 Aider 结果都是 pass@1、且未使用hints_text的结果。"Aider agent"内部虽然会做多次"尝试"，但只挑选并返回一个候选方案，且只有这一个候选被验收测试评估并计入得分——因此是严格的 pass@1。

与之相对的是 pass@N（N>1）：对同一问题做 N 次尝试并把 N 个方案全部交给验收测试，任一通过即算成功。两者不可直接比较。

文档发布时图中对比的其他 pass@1、unhinted 结果（数据以原文报告为准，仅作当时横向参照）：

原文也说明了图表在 5/30 的两次修正：AutoCodeRover 改用其平均 pass@1 结果（此前展示的是不可比较的 pass@3）；OpenDevin 改用未使用 hints 的最佳结果（此前展示的是带 hint 的结果）。

十二、仓库中的复现与可视化工具

虽然运行 SWE Bench Lite 的专用 harness 是独立于本仓库的外部工程，但本仓库保留了可辅助理解与复现评测生态的配套工具：

• benchmark/README.md：Aider 自身的代码编辑基准测试 harness使用说明——基于 Exercism 练习做端到端评估（不仅测 LLM 编码能力，还测其编辑既有代码与格式化编辑的能力）；建议在 docker 容器内运行以避免执行未经人工审查的 LLM 代码；核心参数包括--model、--edit-format（推荐从whole起步）、--threads（可并行跑多个练习）、--num-tests、--keywords（类似pytest -k过滤）、--tries，以及用--stats生成 yaml 格式统计报告（含pass_rate_1、pass_rate_2、edit_format、commit_hash等字段）；
• benchmark/swe_bench.py：SWE Bench 结果绘图脚本，输入文本数据文件即可输出柱状图（is_lite = "lite" in fname自动区分 SWE Bench Lite 与完整 SWE Bench），Aider 的条柱以高亮色区分（Lite 版为绿色），并标注每个模型对应的实例数与 pass@1 百分比；
• 仓库中另有 tally_output.txt 与 tally_results.txt，可看到基准运行的汇总输出样例。

十三、总结

Aider 在 SWE Bench Lite 上的 26.3% pass@1（unhinted）成绩，是一套"非 agentic"技术路线的有力证明：仓库地图（AST + 调用图 + PageRank 个性化）解决"编辑哪里"、可靠的代码编辑后端解决"怎么改"、tree-sitter lint 与测试驱动修复解决"改得对不对"，而交互式 UX 保证用户始终掌握方向盘。对于希望在自己的代码库中复现"用 AI 结对解决 GitHub Issue"的团队，Aider 提供的启示是：先把"定位相关代码"与"可靠落盘编辑"这两个基础设施做好，往往比堆叠更多自主 agent 能力更高效、更省 token、也更可控。

【免费下载链接】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