本地LLM修复Java项目：三个关键教训

用本地大模型自动修复Java构建错误，听起来是个优雅的闭环：编译失败→模型生成补丁→应用补丁→重新编译。但CompileLoop项目的开发者LambdaJedi在实现这个流程后发现，真正困难的部分不是让模型写出代码，而是确保模型输出能被可靠地验证和应用。

CompileLoop是一个开源Java工具，它接收一个Maven构建失败的项目，将编译错误发送给本地代码模型，获取修复建议，在临时副本中应用补丁并重新构建验证。原始源码始终保持不变，只有通过验证的补丁才会呈现给开发者审查。

这个项目最有价值的产出不是工具本身，而是开发者在构建过程中踩过的坑——它们揭示了AI辅助软件开发中一些容易被忽视的系统性问题。

模型修复正确，格式却可能出错

第一个问题出在unified diff格式上。

在一个基准测试用例中，Java编译器报告缺少分号。模型准确识别了需要修改的位置，生成了正确的修复内容——在return a + b后面加上分号。但问题在于，diff头部的行数计数是错的。

unified diff的头部包含变更前后的行数信息，补丁工具依赖这些数字来确定应用范围。CompileLoop最初的实现会在计数不匹配时直接拒绝补丁。于是出现了一个尴尬的局面：模型给出了完全正确的修复，工具却因为格式细节而拒绝执行。

这种情况反复出现。开发者最终意识到，与其让模型每次重新生成，不如像git apply --recount那样，从diff正文重新计算行数。关键在于，这不是放松对实际变更的验证，而是用确定性代码修正一个可以确定性计算的字段。

并非所有问题都需要让AI重试。有时候，更好的方案是识别出哪些输出部分可以由普通代码安全地修正。

这个教训指向一个更广泛的原则：AI生成的输出中，有些部分需要智能判断，有些部分则是机械性的格式要求。把后者交给确定性代码处理，既提高了成功率，也减少了不必要的模型调用。

unified diff 是 Unix 系统中 diff -u 命令输出的一种补丁格式，也是 git diff、patch、git apply 等工具通用的交换格式。它的核心结构是：以 ---/+++ 两行标明变更前后的文件名，随后是若干个「hunk」（变更块），每个 hunk 以 @@ -旧起点,旧行数 +新起点,新行数 @@ 的头部开始。补丁工具在应用 hunk 时，默认会严格核对旧文件对应位置的内容以及头部声明的行数；一旦计数不匹配，patch 会直接报错，而 git apply 则提供了 --recount 选项，允许它忽略头部计数、仅根据行首的 +/-/空格 前缀重新推断行数。CompileLoop 正是借用这一思路，把 diff 头部这类纯粹机械、可确定性计算的字段交由代码而非模型负责，从而避免因格式瑕疵丢掉语义正确的补丁。

模型说修好了，不等于真的修好了

第二个问题更加微妙。

有一个Java方法声明返回int，实际却返回了字符串"x"。编译器正确报错。模型返回的摘要说它会将方法返回类型改为int——但方法声明本来就是int。模型实际修改的是方法体，把return "x"改成了return a + b。

补丁本身是正确的，但解释文本是错的。

表面上看，代码修好了就行，摘要不准确似乎无关紧要。但如果工具的设计依赖于模型的解释来做决策——比如根据摘要判断修改了哪些文件——就会做出错误判断。CompileLoop的做法是：验证补丁本身，并通过运行构建来确认结果。模型摘要只是参考上下文，不构成修复成功的证据。

这个设计选择反映了一个核心原则：AI可以提出方案，但证据必须来自实际代码和测试结果。在AI辅助开发工具中，区分“模型声称做了什么”和“模型实际做了什么”，是一个基础性的架构问题。

在 AI 编码工具链中，模型通常会产生两类输出：一是可执行的产物（补丁、命令、文件内容），二是自然语言的解释（摘要、理由、修改说明）。解释文本由模型的同一轮生成过程顺带产出，它描述的是模型「以为」自己做了什么，而非实际 diff 的内容，二者可能因为模型对上下文的误读而出现偏差。工程上可靠的判定链应当以产物为准：先对 diff 做静态校验（能否干净应用、是否触碰受保护路径），再通过真实的编译或测试运行得到客观信号。解释文本适合作为人类审查者的辅助上下文，但不应被工具逻辑当成事实来源，否则会在「改动了哪些文件」「是否引入了新依赖」这类判断上被误导。

知道什么时候该停止求助AI

第三个问题涉及资源浪费。

模型有时会反复生成完全相同的错误补丁。第一次失败，工具反馈错误信息，模型返回第二个补丁——和第一个一模一样。第三次也可能相同。工具确实有最大尝试次数限制，最终会停止，但每次尝试都意味着一次模型调用和一次Maven构建。

开发者添加了两个提前终止条件：

• 重复补丁检测：如果模型生成的补丁已经被尝试过，循环直接停止。补丁指纹使用Java的String.hashCode()，因为指纹仅用于同一进程内的补丁比较，碰撞只会导致提前停止，不会让不安全的补丁通过。
• 错误未变化检测：如果连续两次尝试因相同的诊断信息失败，说明没有取得进展。

在基准测试的60次运行中，这些停止条件被触发了27次，其中包括21次检测到缺乏进展和6次模型提供者不可用。这说明提前停止不是一个理论上的优化，而是实际运行中频繁生效的机制。

AI修复循环需要的不仅仅是最大尝试次数，还需要一种能力来识别下一次尝试是否可能有用。

不同模型的实际表现差异

开发者用20个包含故意缺陷的Maven项目测试了三个本地代码模型，每个模型每个用例尝试三次：

模型	成功修复	修复率	平均延迟
Qwen2.5-Coder 7B	9/20	45%	29秒
Qwen2.5-Coder 1.5B	4/20	20%	12秒
DeepSeek广告-Coder 6.7B	1/20	5%	39秒

Qwen2.5-Coder 7B表现最好。但真正值得关注的是DeepSeek-Coder 6.7B的表现——它经常在摘要中正确识别修复方案，但生成的diff包含与源文件不匹配的上下文行，导致补丁无法安全应用而被拒绝。

这个结果说明，选择模型不只看参数规模或解释质量，还要看它能否以系统要求的精确格式输出。一个能“理解”问题但无法生成可应用补丁的模型，在实际工具链中价值有限。

开发者还注意到Qwen2.5-Coder 7B在测试失败类用例上的表现优于编译失败类用例，但测试样本只有5个，这个观察需要更大规模的基准测试来验证。

代码大模型的「格式合规性」与「语义正确性」是两个相对独立的能力维度。语义正确性指模型是否理解错误原因并给出正确的代码修改；格式合规性指它能否把修改准确表达成目标工具能消费的格式，对 CompileLoop 而言就是 unified diff 的上下文行必须与源文件逐字符匹配。上下文行不匹配会让补丁工具直接拒绝应用，即便改动本身完全正确，也就无从验证。参数规模、训练语料中 diff 和 commit 数据的占比、后训练阶段是否针对补丁格式做过对齐，都会影响这一维度。因此选型时不能只看 HumanEval 之类的通过率，还需要针对实际输出通道（diff、patch、结构化 JSON 等）做端到端的可应用率评估。

工程化才是真正的挑战

CompileLoop项目中最耗时的部分不是AI集成，而是模型周围的工程基础设施：

• 执行Maven的进程运行器，需要处理输出缓冲避免死锁、实施超时控制、必要时终止进程树
• 将Maven输出解析为结构化编译错误和测试失败的解析器
• 拒绝危险变更的补丁验证器，包括路径遍历、符号链接逃逸和意外文件操作
• 在临时工作区中应用和测试补丁，不修改原始项目
• 记录尝试、检查修复效果、检测进展停滞的修复引擎

项目目前有233个测试，CI在Ubuntu和Windows上运行。测试套件使用模拟的Ollama服务器和脚本化模型响应，不需要下载本地模型就能运行。

开发者明确记录了当前的局限：临时副本不是安全沙箱，构建脚本可以执行任意命令，容器隔离是重要的下一步。回归检测也是待改进项——修复一个失败的测试不应意外破坏另一个。

「临时副本不是安全沙箱」是这类工具普遍存在的隐患。Maven 构建会依次执行 pom.xml 中声明的各类插件，包括 exec-maven-plugin、注解处理器、测试阶段的任意 Java 代码，甚至通过 maven-antrun-plugin 直接调用 shell。也就是说，只要接受了一个恶意或被污染的补丁，构建过程本身就等价于在宿主上执行任意命令。进程级的临时目录隔离只能防止污染原始源码，无法限制文件系统访问、网络请求或子进程创建。真正的隔离需要借助容器（Docker/Podman）、gVisor 或轻量虚拟机，把构建进程连同其文件写入、网络出口一并约束在白名单内，这也是 CompileLoop 把「容器隔离」列为下一步的原因。

构建AI工具仍然是工程

开发者在项目中使用了Claude进行架构讨论和代码审查，但强调使用AI辅助构建项目并不能免除理解你所构建之物的责任。

需要理解为什么重新计算diff计数是安全的、为什么补丁本身比模型摘要更重要、为什么停止重复尝试优于盲目继续——这些决策需要被解释和辩护，而不仅仅是让代码通过编译。

CompileLoop探索的方向或许比工具本身更有意义：不是让模型写代码，而是构建能够验证模型工作、处理模型错误的系统。模型提出修复方案，工具检查方案，开发者审查结果——如果模型持续出错，工具应该知道何时停止。

源码、基准测试用例和结果已在GitHub上开源，可以通过Ollama拉取Qwen2.5-Coder 7B模型复现基准测试。