学习提交：通过在线仓库记忆生成有机的Pull Request Learning to Commit: Generating Organic Pull Requests via Online Repository Memory
通过对比反思历史提交积累仓库特定技能，生成符合项目风格的代码
前置知识
LLM编码智能体
基于大语言模型的代码生成系统，能够理解自然语言描述的任务，自主探索代码库（读取文件、搜索代码、编辑文件），并生成代码补丁来解决问题。这类系统通常具备工具调用能力，可以在代码库中进行多步推理和操作，类似于SWE-bench等基准测试中评估的智能体。
本文的核心研究对象就是这类智能体，理解其工作方式是理解本文问题动机和解决方案的基础
有机性（Organicity）
本文提出的一个核心概念，指AI生成的代码与仓库原有代码在风格、架构、API使用等方面的一致性程度。有机的代码不是仅仅功能正确，而是看起来像是由熟悉该项目的开发者自然地从项目演化中生长出来的，而不是由一个从未读过项目的外部人员编写的。
这是本文的核心评估维度，区别于传统的仅关注功能正确性的评估方式
在线仓库记忆（Online Repository Memory）
本文提出的核心机制，是一个不断增长和更新的技能文档。智能体通过对比自己对历史提交的预测与真实专家提交之间的差距，将仓库特定的编码风格、内部API用法、架构约束等模式提取为可复用的技能条目。这个记忆文档通过显式的CRUD操作（创建、修订、弃用）持续更新。
这是本文方法的核心创新，实现了智能体对仓库的主动学习和适应
监督对比反思（Supervised Contrastive Reflection）
本文提出的学习方法，智能体首先盲目尝试解决历史提交对应的问题，生成自己的代码补丁，然后与专家的真实提交进行对比，识别在文件定位、实现逻辑、API使用和编码风格等方面的差异。这种对比产生的差距信号作为密集的监督信号，指导智能体提取仓库特定的开发模式。
这是本文方法的技术核心，区别于无监督的自我反思，通过专家监督避免错误累积
时间分割评估
一种严格的评估协议，将仓库的提交历史按时间严格分为学习集和测试集。学习集中的所有提交都早于测试集中的提交，确保智能体在技能构建阶段无法看到评估任务，从而完全防止信息泄漏。这与SWE-bench等基准测试按时间乱序评估形成对比。
这是本文评估设计的关键，确保了零数据泄漏和真实的泛化能力评估
研究动机
尽管基于大语言模型的编码智能体在SWE-bench等基准测试上取得了令人印象深刻的成绩，但专业维护者仍然谨慎对待AI生成的代码。核心问题不在于功能正确性，而在于缺乏有机性。具体表现为三个方面：首先，生成的代码风格与项目不一致，像是由从未读过项目的人编写的；其次，智能体会重复实现仓库中已存在的工具函数、包装器或控制流模式，导致代码膨胀；第三，违反项目多年积累的隐式架构约束。例如，在SWE-bench等基准测试中，智能体只需通过测试即可成功，不携带任何积累的知识向前推进。这种评估方式将软件工程视为孤立的一次性任务序列，忽略了仓库及其约定如何随时间自然演化。实验数据显示，在没有技能文档的情况下，基线智能体的代码行偏差率高达1.59，表明存在严重的补丁膨胀问题。
本文的目标是本文的目标是让AI编码智能体能够生成真正有机的Pull Request，即不仅功能正确，而且风格一致、架构协调、内部API复用率高的代码。具体来说，框架需要实现三个目标：第一，通过在线学习机制让智能体主动适应演化的代码库；第二，建立严格的评估范式，超越功能测试通过率，从代码风格一致性、内部API复用率、修改区域合理性等多维度评估有机性；第三，确保零数据泄漏，通过严格的时间分割评估验证智能体的真实泛化能力。
与已有工作不同的是，现有工作存在三个关键空白。首先，SWE-bench等基准测试将软件工程视为孤立任务，智能体不携带任何积累知识，而人类工程师加入成熟项目时会先阅读历史提交、学习模块边界、发现惯用的内部工具。其次，SWE-Bench-CL等工作虽然引入了持续学习，但依赖无监督的自我反思，容易出现垃圾进垃圾出的问题，当早期尝试失败时会导致自我强化的错误。第三，现有评估几乎完全依赖功能测试通过率，缺乏多维度的有机性评估。本文的独特切入角度是将仓库特定的入职过程形式化，通过监督对比反思让智能体从历史提交中学习项目特有的开发模式，并将这些模式积累为可复用的技能文档。
核心方法
本文提出Learning to Commit框架，核心思想是有机性可以从提交历史中学习，因为提交历史记录了项目选择如何演化。整体方法分为两个阶段：第一阶段是仓库入职（学习阶段），智能体在历史提交上进行监督对比反思，构建一个不断增长的技能文档；第二阶段是技能条件化求解（解决阶段），当新的PR描述到来时，智能体基于积累的技能文档生成代码补丁。直觉上，这模仿了人类开发者加入新项目的过程：不是被动阅读文档，而是通过主动尝试任务并从自己的输出与专家实践之间的差距中学习。技术路线上，智能体首先盲目尝试每个历史提交，然后与专家的真实提交进行对比，将差距提炼为抽象的、可复用的开发技能，这些技能涵盖编码风格、内部API用法、架构约束和维护者偏好等模式。
本文的核心创新是监督对比反思机制，这与已有方法存在本质区别。现有方法如SWE-Bench-CL依赖无监督的自我反思，智能体只能从自己的尝试中学习，容易出现错误累积。而本文方法让智能体先盲目尝试历史提交，然后揭示专家的真实提交作为密集监督信号。通过对比自己的预测与专家答案之间的差距，智能体能够精确校准提取的模式与自身能力缺口的关系。这种监督信号的价值在于：差距越大，学习信号越丰富。与静态RAG检索提交历史不同，这种在线学习循环确保提取的模式精确针对智能体会犯的错误。另一个关键区别是技能文档的显式CRUD操作：创建新条目记录未知模式，修订部分正确的条目，弃用被专家证据否定的条目，这比隐式的权重更新更可解释和可控。
方法步骤详情
方法分为三个主要步骤。第一步是仓库入职，给定一个带严格时间分割的仓库，学习集 $C^- = \{c_t : t \leq T^*\}$，技能文档初始化为空 $M^{(0)} = \emptyset$。对于每个学习提交 $c_t \in C^-$，智能体执行三步循环：（1）盲目尝试，智能体接收仓库快照 $S_t$、合成问题描述 $d_t$ 和当前技能文档 $M^{(t-1)}$，自主探索代码库并生成候选补丁 $\hat{\Delta}_t$；（2）Oracle揭示与对比反思，揭示真实专家提交 $\Delta_t$，智能体对比自己的尝试与专家答案，识别文件定位、实现逻辑、API使用和编码风格等方面的差异；（3）技能更新，基于对比反思通过CRUD操作更新技能文档：$M^{(t)} = \text{UPDATE}(M^{(t-1)}, \hat{\Delta}_t, \Delta_t, d_t)$。第二步是技能条件化求解，当未来任务 $d_k \in C^+$ 到来时，智能体接收仓库快照 $S_k$、任务描述 $d_k$ 和完整的技能文档 $M$，自主解决任务。第三步是评估，使用代码度量和LLM评判器评估生成的补丁。
技术新颖性
本文的技术新颖性体现在多个方面。首先，将仓库特定的入职过程形式化为一个可计算的在线学习问题，这是首次将人类开发者的学习过程转化为算法框架。其次，提出了监督对比反思机制，通过专家监督避免了无监督学习的错误累积问题。第三，设计了显式的技能文档更新机制，通过CRUD操作实现可解释的技能管理，而非隐式的神经网络权重更新。第四，建立了多维度的有机性评估体系，超越了传统的功能测试通过率，包括文件IoU（定位精度）、轨迹步数（求解效率）、行偏差率（补丁膨胀）和LLM评判器的四维度评分（范围对齐、逻辑相似性、冗余减少、代码风格）。第五，严格的时间分割评估协议确保了零数据泄漏，这是对现有基准测试的重要改进。
实验结果
实验在一个内部专家维护的强化学习训练仓库上进行，该仓库包含智能体环境、评判器评估和编排子系统。从2738个非合并提交开始，经过过滤和LLM评估后得到386个高质量提交（77.2%适用率），分布在7个核心开发类别中。严格时间分割后，构建了24个历史学习提交和7个未来测试任务的平衡课程。主要发现包括：第一，技能条件化智能体在4个实验设置中的3个实现了更高的文件IoU，其中seq-all设置下提升最大，从61%提升到80%，提升19个百分点；第二，在相同设置下，技能智能体使用更少的工具调用（56.8步 vs 71.9步），减少21%，表明积累的技能帮助智能体更高效地导航代码库；第三，行偏差率在3个设置中更低，表明补丁大小更接近专家提交；第四，多维度LLM评判器显示技能智能体在par-bycat设置下胜率分别为54%和57%（Claude和Gemini评判器），在seq-all设置下为55%和58%；第五，技能的优势主要集中在逻辑相似性（50% vs 25%）和冗余减少（54% vs 41%）两个维度，而范围对齐和代码风格维度基线略占优势。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 文件定位精度（File IoU） | Jaccard相似度 | seq-all: 80%, par-bycat: 80%, par-all: 81%, seq-bycat: 71% | seq-all: 61%, par-bycat: 68%, par-all: 72%, seq-bycat: 71% | seq-all: +19%, par-bycat: +12%, par-all: +9%, seq-bycat: 0% |
| 求解效率（轨迹步数） | 工具调用次数 | seq-all: 56.8, par-bycat: 62.7, par-all: 67.7, seq-bycat: 75.0 | seq-all: 71.9, par-bycat: 62.7, par-all: 68.3, seq-bycat: 76.4 | seq-all: -21%, par-bycat: 0%, par-all: -1%, seq-bycat: -2% |
| 补丁膨胀（行偏差率） | 偏差比率 | seq-all: 0.69, par-bycat: 0.62, par-all: 0.80, seq-bycat: 1.22 | seq-all: 1.59, par-bycat: 0.88, par-all: 1.06, seq-bycat: 1.13 | seq-all: -57%, par-bycat: -30%, par-all: -25%, seq-bycat: +8% |
| LLM评判器总体胜率 | 胜率百分比 | par-bycat: 54%/57%, seq-all: 55%/58%, par-all: 46%/54%, seq-bycat: 26%/46% | 对应基线胜率 | par-bycat: +4%/+7%, seq-all: +5%/+8%, par-all: -4%/+4%, seq-bycat: -24%/-4% |
局限与改进
本文存在几个重要局限性。首先，实验仅在一个内部专家维护的强化学习训练仓库上进行，该仓库虽然包含2738个提交，但缺乏在多样化公开GitHub仓库上的验证，泛化性有待进一步确认。其次，数据集规模相对较小，仅包含24个学习提交和7个测试任务，这限制了统计显著性和结论的可靠性。第三，多维度LLM评判器虽然提供了细粒度评估，但依赖LLM作为评判器本身存在潜在偏差和不准确性，需要更稳健、可验证的评估指标。第四，技能文档的表示方式相对简单，仅通过文本形式存储，可能无法捕获复杂的架构模式和跨文件依赖关系。第五，学习过程是离线的，技能文档在构建后不再更新，无法适应仓库的持续演化。第六，作者承认在代码风格维度（Q4）上技能智能体没有明显优势，表明当前的技能表示可能不足以捕获细粒度的风格模式。
独立分析的弱点
本文存在几个可改进的弱点。首先，数据集规模过小，24个学习提交和7个测试任务的设置难以支撑统计显著的结论，建议扩大到数百个学习提交和数十个测试任务。其次，仅在一个内部仓库上验证，缺乏在多样化公开仓库上的实验，建议选择不同语言、不同规模、不同领域的开源项目进行验证。第三，技能文档的表示方式过于简单，仅使用文本形式，可能无法有效编码复杂的架构约束和跨文件依赖，建议引入图结构或向量表示来捕获更丰富的语义信息。第四，学习过程是离线的，技能文档在构建后不再更新，无法适应仓库的持续演化，建议引入在线增量学习机制。第五，评估维度中代码风格（Q4）的改善不明显，说明当前技能表示不足以捕获细粒度风格模式，建议引入专门的风格编码器或对比学习目标。第六，实验中使用的LLM是Claude Opus 4.6，缺乏对不同规模和能力模型的消融实验。
未来方向
作者提出了几个重要的未来研究方向。首先，将数据整理和评估管道扩展到多样化、高质量的公开GitHub仓库，验证框架的泛化性，这是最关键的下一步。其次，探索更稳健、可验证的有机性评估指标，减少对LLM评判器的依赖，可能包括基于规则的风格检查器、API使用模式匹配器等。第三，研究仓库特定技能是否能迁移到更广泛的编码任务和现有评估设置中，明确历史适应的范围和限制。基于本文成果，还可以延伸出几个方向：一是将框架扩展到多仓库学习，让智能体从多个相关项目中积累通用的软件工程技能；二是引入强化学习机制，让智能体从维护者的反馈中持续优化技能文档；三是将技能文档与代码嵌入空间结合，实现更精准的技能检索和应用；四是探索技能文档的可解释性，让开发者能够理解和验证智能体学到的模式。
复现评估
本文的复现性存在一些挑战。首先，实验使用的是内部仓库，未公开数据集和代码，这限制了其他研究者的复现能力。虽然作者提到计划在未来工作中标度到公开GitHub仓库，但目前缺乏可公开访问的基准。其次，实验依赖Claude Opus 4.6这样的商业API，成本较高，24个学习提交的技能构建过程需要大量API调用。第三，数据整理管道虽然描述清晰，但包含多个LLM评估步骤（提交质量评估、类别聚类、类别标签、查询生成），每个步骤都引入了不确定性。第四，评估协议使用两个独立的LLM评判器，但评判提示词和具体实现细节未完全公开。建议作者开源数据集、评估代码和技能文档示例，并提供更详细的实验配置，以促进社区复现和改进。
论文图表
该表格报告了par-bycat设置下四个评估维度的详细胜率：范围对齐（Q1：技能25% vs 基线41%）、逻辑相似性（Q2：技能50% vs 基线25%）、冗余和幻觉（Q3：技能54% vs 基线41%）、代码风格（Q4：技能27% vs 基线38%）。
这个表格揭示了技能文档在不同维度上的不对称价值，逻辑相似性和冗余减少是主要优势，而范围对齐和代码风格改进不明显。