arXiv 每日速递 2026-04-08

今日总结

今天的论文呈现出一条清晰的主线：LLM 正在从"写代码"走向"做软件工程"。我们看到 LLM 不仅能生成代码，还能做数值稳定性分析（传统编译器优化领域）、充当微服务测试中的运行时 mock（替代传统 record-replay）、通过 RL 训练成为 ML 工程师 agent、以及在迭代式 build-test-patch 循环中展现出工程治理能力。这些工作共同指向一个趋势：LLM 的 SE 能力正在从单点代码生成扩展到全生命周期的软件工程活动。

今日全览

论文	方向	核心贡献	与我们的相关度
Assessing LLMs for Stabilizing Numerical Expression	LLM + Code Analysis	LLM 在数值稳定化上超越传统方法，但在控制流推理上仍有短板	⭐⭐⭐
MIRAGE: Online LLM Simulation for Microservice Testing	LLM + Software Testing	用 LLM 实时模拟微服务依赖，99% 状态码保真度	⭐⭐⭐
SandMLE: Synthetic Sandbox for Training ML Engineering Agents	LLM Agent + RL Training	合成微型环境实现 on-policy RL 训练 MLE agent，执行时间降 13x	⭐⭐⭐
SysTradeBench: Iterative Build-Test-Patch Benchmark	LLM + Code Generation Benchmark	迭代式 build-test-patch 基准，揭示 LLM 迭代中的代码趋同现象	⭐⭐

今日主题：LLM 的软件工程能力正在全栈化

今天这四篇论文揭示了一个令人兴奋的趋势：LLM 在软件工程中的角色正从"代码生成器"向"全栈软件工程师"演进。

第一层是代码分析能力的深化。LLM 不仅能写代码，还能理解代码的数值语义——Nguyen et al. 的工作表明 LLM 在数值稳定化上甚至超越了专门的静态分析工具。这意味着 LLM 对代码的理解已经超越了语法层面，开始触及程序语义。但有趣的是，LLM 在符号表达式上表现优异，却在涉及控制流和高精度数值字面量时失败，这暗示了 LLM 代码理解的一个根本性边界：它擅长模式匹配式的代码变换，但不擅长需要精确数值推理的场景。

第二层是运行时交互能力。MIRAGE 展示了一种全新的测试范式——LLM 不再只是生成静态 mock，而是在测试运行时实时扮演依赖服务。这要求 LLM 具备跨请求的状态维护能力和对服务行为的深度理解。99% 的保真度证明这不是 toy demo。

第三层是工程流程自动化。SandMLE 和 SysTradeBench 分别从训练和评估两个角度推进了 LLM agent 的工程能力。SandMLE 巧妙地用合成微型环境解决了 MLE agent 训练的计算瓶颈，而 SysTradeBench 则揭示了一个值得警惕的现象：LLM 在迭代修补中会趋向代码趋同，这对"LLM 能否替代工程师"的讨论提供了重要的反面证据。

---

Assessing Large Language Models for Stabilizing Numerical Expression in Scientific Software

推荐理由：直接评估 LLM 的代码分析与变换能力，与我们在 LLM for Code Analysis 方向的研究高度相关

📌 论文信息：Tien Nguyen, Muhammad Ali Gulzar, Kirshanthan Sundararajah | arXiv:2604.04854 | cs.SE

TL;DR

LLM 在检测和修复科学软件中数值不稳定表达式上的表现与传统最优方法持平，且在传统方法失败的 17.4% 案例中，LLM 成功修复了 97.9%——但 LLM 在控制流和高精度数值字面量场景下仍然系统性失败。

问题是什么？

科学软件严重依赖高精度计算，但有限的浮点数表示会引入精度误差，在安全关键领域中，这些误差的传播可能导致灾难性后果（想象一下火箭轨道计算中的浮点溢出）。传统方法（如 Herbie 等工具）通过规则驱动的表达式重写来提升数值稳定性，但它们的覆盖面有限——遇到复杂的嵌套条件分支或多变量算术时往往束手无策。

关键问题在于：LLM 是否能理解浮点算术的语义，并进行有意义的数值稳定化？这不是简单的代码翻译，而是需要理解数学恒等式、精度损失模式、以及表达式等价变换——这对 LLM 的"数学推理"能力是一次严肃的考验。

他们怎么做的？

核心 Insight：将数值稳定化拆分为两个独立任务——检测（生成能触发精度误差的输入）和修复（重写表达式以提升稳定性），分别评估 LLM 的能力边界。

具体方法流程：

1. 检测任务：给定一个数值表达式，要求 LLM 生成能触发数值不稳定的输入。这测试的是 LLM 能否理解浮点运算的陷阱（如灾难性相消、溢出边界）
2. 修复任务：给定不稳定表达式，要求 LLM 重写为数值等价但更稳定的形式。这测试的是 LLM 能否进行保语义的代码变换
3. 大规模评估：6 个 LLM，近 2,470 个数值结构，包括嵌套条件、高精度字面量、多变量算术等多种模式

跟之前方法的本质区别：传统方法（如 Herbie）是基于规则的表达式重写引擎，有固定的重写策略库。LLM 则通过对代码模式的学习，能"发明"不在规则库中的变换——这就是它在传统方法失败案例上表现优异的原因。

关键结果

评估维度	LLM	传统 Baseline	对比
整体稳定化有效性	等效	等效	持平
Baseline 失败案例（431个）	修复 422 个 (97.9%)	0	LLM 大幅领先
全部表达式中优于 Baseline	65.4% (1,615个)	34.6%	LLM 占优
控制流表达式	系统性失败	可处理	Baseline 占优
高精度字面量	倾向删除而非推理	规则保留	Baseline 占优

结果解读：最有趣的发现不是 LLM 在哪里赢了，而是它在哪里输了。LLM 面对控制流时，倾向于删除条件分支而不是推理其数值含义——这说明 LLM 把控制流当成了"冗余代码"来处理，而不是理解它的数值保护作用。面对高精度字面量（如 3.141592653589793238），LLM 同样倾向于简化或删除，因为训练数据中很少出现需要精确保留这些数值的场景。

这个失败模式非常有启发性：LLM 的代码变换能力本质上是基于统计模式的，而非基于语义推理的。在纯符号表达式上，模式匹配就足够了；但涉及精确数值或控制流语义时，模式匹配会产生系统性错误。

局限性与开放问题

• 局限 1：论文没有报告具体使用了哪 6 个 LLM，也没有按模型分别报告结果。不同模型在数值推理上的能力差异可能很大（reasoning model vs. non-reasoning model）
• 局限 2：评估仅限于表达式级别的稳定化。现实中，数值不稳定往往涉及跨函数的误差传播，需要过程间分析——这远超当前评估的范围
• 局限 3：论文的 benchmark 来源未详细说明。如果这些 benchmark 的表达式在 LLM 训练数据中有大量相似样本，那高成功率可能部分来自记忆而非推理
• 开放问题：LLM 在控制流上的系统性失败是否可以通过 fine-tuning 或 chain-of-thought prompting 来改善？如果不能，这是否意味着 LLM 代码分析能力有一个根本性的天花板？

💡 对我们的启发

1. 直接可用的技术点：我们在做 automated program repair 时，可以考虑将数值稳定性检查作为 patch validation 的一个维度。如果 LLM 生成的 patch 修改了数值计算表达式，可以用类似 Herbie 的工具做一次稳定性回归检测——这篇论文证明了 LLM 确实可能在"修复 bug"的同时引入数值不稳定性

2. 具体实验想法：可以设计一个实验——给 LLM 一段有数值 bug 的科学计算代码（如精度损失导致的错误结果），看 LLM 能否同时定位 bug 和进行数值稳定化。输入：包含数值 bug 的 Python/C++ 函数 + 失败的测试用例；做什么：让 LLM 生成 patch 并用 MPFR 高精度库验证；预期观察：LLM 可能修复了功能 bug 但未改善数值稳定性，或者反过来

3. 研究趋势判断：这篇论文开辟了"LLM 代码分析能力的边界探测"这个方向。未来我们可能会看到更多类似的工作——不是问"LLM 能做什么"，而是精确地刻画"LLM 不能做什么以及为什么"。这对于设计 human-AI 协作的 SE 工具至关重要

---

MIRAGE: Online LLM Simulation for Microservice Dependency Testing

推荐理由：提出了 LLM 在软件测试中的全新范式（运行时模拟），与我们在 LLM for SE 方向的研究直接相关

📌 论文信息：XinRan Zhang | arXiv:2604.04806 | cs.SE

TL;DR

MIRAGE 让 LLM 在测试执行过程中实时充当微服务依赖的模拟器，不需要预先生成 mock 规范。在白盒模式下达到 99% 的状态码保真度和 99% 的响应结构保真度，远超传统 record-replay 的 62%/16%。

问题是什么？

微服务架构中，测试一个服务往往需要它的依赖服务也在线——但在 CI/CD 环境中启动整个依赖链既昂贵又脆弱。传统解决方案分三种：record-replay（录制真实请求回放）、pattern-mining（从日志挖掘模式）、specification-driven stubs（基于 API 规范生成桩）。但这三种方法都是静态的：它们在测试执行前生成固定的 mock artifact，无法处理测试过程中的动态状态变化。

举个具体例子：一个购物车服务的测试需要先"添加商品"再"结算"。record-replay 只能回放录制时的固定响应，如果测试改了商品数量，replay 的结果就对不上了。specification-driven stubs 能处理格式但不理解业务逻辑。本质上，现有方法缺乏对被模拟服务的行为理解能力。

他们怎么做的？

核心 Insight：让 LLM 阅读依赖服务的源代码、调用代码和生产 traces，然后在测试运行时实时回答每个请求——不是生成静态 mock，而是"扮演"那个服务。

具体方法流程：

1. 上下文构建：将依赖服务的源代码、调用方代码、生产环境请求 traces 作为 LLM 的输入上下文。LLM 通过这些信息理解服务应该"怎么表现"
2. 运行时模拟：当测试执行时，每个发往依赖服务的请求被拦截并转发给 LLM。LLM 根据请求内容、上下文和之前的交互历史，实时生成响应
3. 跨请求状态维护：LLM 在整个测试场景中维护状态——如果前一个请求"创建了用户"，后续请求查询该用户时 LLM 能返回一致的结果

跟之前方法的本质区别：传统方法是"提前生成答案库"，MIRAGE 是"实时理解问题并回答"。这类似于考试中的"开卷"和"闭卷"之分——MIRAGE 让 LLM 带着源代码"开卷"做测试模拟。

关键结果

评估维度	MIRAGE (白盒)	Record-Replay	差距
状态码保真度	99% (109/110)	62%	+37%
响应结构保真度	99%	16%	+83%
端到端 pass/fail 一致性	8/8 (100%)	-	完美
无源码时状态码保真度	94%	-	仍然很高
无源码时响应结构保真度	75%	-	显著下降
跨 LLM 家族稳定性	±3%	-	高度稳定
每个依赖的成本	$0.16-$0.82	~$0	有成本

结果解读：最引人注目的是 signal ablation 实验。依赖源代码单独使用时就能达到 100% 保真度，说明源代码是 LLM 理解服务行为的最关键信号——甚至比生产 traces 还重要。这与我们的直觉一致：代码是行为的最精确规范。

但当使用 typed intermediate representation 约束 LLM 输出时，复杂有状态服务的保真度降到 55%。这揭示了一个有趣的权衡：结构化约束提高了简单 API 的可靠性，但限制了 LLM 处理复杂状态的灵活性。

局限性与开放问题

• 局限 1：$0.16-$0.82 per dependency 的成本在大规模 CI/CD 中可能不可忽略。如果一个微服务系统有 50 个依赖，每次测试运行的 LLM 成本可能达到几十美元
• 局限 2：110 个测试场景、3 个微服务系统的规模仍然较小。论文选用的 Google Online Boutique 和 Sock Shop 都是经典的教学级微服务系统，真实生产系统的复杂度远高于此
• 局限 3：论文没有讨论延迟问题。LLM 推理延迟（通常数百毫秒到数秒）对于需要低延迟响应的微服务测试可能是个问题，特别是在测试超时敏感的场景
• 开放问题：LLM 的"幻觉"在这种场景下的影响是什么？如果 LLM 模拟了一个不存在的 API 行为，测试可能会通过但实际部署会失败——这比传统 mock 的失败模式更隐蔽

💡 对我们的启发

1. 直接可用的技术点：这种"LLM 作为运行时 oracle"的思路可以迁移到我们的 program repair 工作中。在 patch validation 阶段，我们常常缺少完整的测试环境。可以用 LLM 模拟缺失的依赖，从而在不完整环境中进行 patch 验证——这比 mock everything 更真实

2. 具体实验想法：设计一个对比实验——在一组有外部依赖的 bug fix 任务中，分别用传统 mock、MIRAGE 式 LLM 模拟、和真实依赖进行 patch validation。输入：Defects4J 或类似 benchmark 中依赖外部服务的 bug；做什么：比较三种环境下 patch 验证的准确率（正确 patch 通过 + 错误 patch 失败）；预期观察：LLM 模拟可能在 false positive 上优于传统 mock（因为能检测到语义不匹配的 patch），但在 false negative 上可能更差（因为 LLM 幻觉可能让错误 patch 通过）

3. 研究趋势判断：这篇论文代表了"LLM as runtime component"的趋势——LLM 不再只是离线的代码生成工具，而是成为软件系统运行时的一个活跃组件。这可能是 AI4SE 从"辅助开发"到"深度集成"的转折点

---

Synthetic Sandbox for Training Machine Learning Engineering Agents

推荐理由：解决了 LLM coding agent 用 RL 训练的关键瓶颈，其合成环境策略对我们训练 SE agent 有直接启发

📌 论文信息：Yuhang Zhou, Lizhu Zhang, Yifan Wu, Jiayi Liu, Xiangjun Fan | arXiv:2604.04872 | cs.CL, cs.LG

TL;DR

SandMLE 通过生成微型合成 ML 环境（每个任务仅 50-200 训练样本），将 MLE agent 的 on-policy RL 训练执行时间降低 13 倍以上，在 MLE-bench-lite 上相比 SFT baseline 实现了 20.3%-66.9% 的 medal rate 相对提升。

问题是什么？

训练 LLM agent 做机器学习工程（MLE）任务面临一个独特的计算瓶颈：与 SWE 任务不同（可以通过快速执行的单元测试验证），MLE 任务的验证需要运行完整的 ML 流水线——数据预处理、模型训练、指标评估——这在每个 rollout 步骤都极其耗时。

这导致了一个悖论：我们知道 on-policy RL 比 SFT 或 offline RL 效果更好（因为它允许探索和自我纠正），但 on-policy RL 需要大量的环境交互，而每次交互都要运行一个 ML 实验——这在实际中几乎不可行。现有方法只能退而求其次使用 SFT 或 offline proxy reward，牺牲了 RL 的核心优势。

他们怎么做的？

核心 Insight：ML 实验之所以慢，根本原因是数据集太大——如果能把数据集缩小到 50-200 个样本，同时保留任务的结构复杂性和技术挑战，就能让 on-policy RL 变得可行。

具体方法流程：

1. 多 Agent 合成框架：从少量种子任务出发，用多个 agent 协作生成多样化的合成 MLE 环境。每个环境包含：微型数据集（50-200 样本）、任务描述、评估标准
2. 保持复杂性：合成环境虽然数据量小，但保留了真实 MLE 任务的结构复杂性——特征工程、模型选择、超参数调优、pipeline 构建等挑战都在
3. On-policy RL 训练：在这些微型环境中进行 trajectory-wise on-policy RL。每个 rollout 只需秒级到分钟级（而非小时级），使得大规模 RL 训练首次在 MLE 领域变得可行

跟之前方法的本质区别：之前的方法要么用真实环境做 SFT（有数据但没有探索），要么用 proxy reward 做 offline RL（有探索但 reward 不准）。SandMLE 的巧妙之处在于不改变训练算法，而是改变训练环境——通过环境压缩使原本不可行的 on-policy RL 变得可行。

关键结果

Benchmark	模型	SandMLE (RL)	SFT Baseline	相对提升
MLE-bench-lite	Qwen3-8B	显著提升	Baseline	+66.9%
MLE-bench-lite	Qwen3-14B	显著提升	Baseline	+34.2%
MLE-bench-lite	Qwen3-30B-A3B	显著提升	Baseline	+20.3%
MLE-Dojo (HumanRank)	跨 scaffold	最优	Baseline	+32.4%

结果解读：几个值得注意的点：

• 小模型收益更大：8B 模型的提升（66.9%）远大于 30B 模型（20.3%），这说明 on-policy RL 对小模型的探索能力提升更为关键——大模型可能已经通过预训练获得了足够的先验知识
• 跨 scaffold 泛化：训练时用一种 agentic scaffold，测试时换另一种，依然有效。这说明 SandMLE 训练的是通用的 MLE 推理能力，而非对特定 scaffold 的过拟合
• 执行时间降低 13x：这不是一个增量优化，而是量级级别的突破。它使得原本需要 GPU 集群跑数周的训练降低到可在合理时间内完成

局限性与开放问题

• 局限 1：合成微型数据集是否真的能代表真实大数据集的挑战？某些 MLE 任务的难点恰恰在于数据规模（如分布式训练、内存管理），微型数据集上学到的策略可能无法迁移
• 局限 2：论文主要在 Kaggle 风格的 MLE 任务上评估。真实的 ML 工程还包括部署、监控、数据管道维护等，这些很难用合成环境模拟
• 局限 3：合成环境的多样性取决于种子任务和生成 agent 的能力。如果种子任务覆盖面不够，生成的合成环境可能存在系统性偏差
• 开放问题：这种"环境压缩"策略是否可以推广到其他需要昂贵验证的 agent 训练场景（如 hardware design、scientific simulation）？

💡 对我们的启发

1. 直接可用的技术点：我们在训练 program repair agent 时面临类似的瓶颈——每次 patch 验证都需要编译和运行测试套件。可以借鉴 SandMLE 的思路，构建微型 repair 环境：保留 bug pattern 的结构复杂性，但用极小的代码库和快速测试来加速 RL 训练

2. 具体实验想法：构建一个"MicroDefects"数据集——将 Defects4J 中的经典 bug 模式提取出来，嵌入到 50-100 行的微型程序中，配上 2-3 个快速测试。用这个数据集做 on-policy RL 训练 repair agent，然后在完整的 Defects4J 上测试泛化能力。输入：Defects4J bug pattern 分类 + 微型程序模板；做什么：生成 500+ 微型 repair 任务，RL 训练 Qwen3-8B；预期观察：微型环境训练的 agent 可能在 pattern matching 类 bug 上泛化良好，但在需要理解大规模代码上下文的 bug 上可能不行

3. 研究趋势判断：这篇论文代表了"training environment engineering"这个正在兴起的方向。以前我们关注训练数据和训练算法，现在训练环境本身也成为可以被优化的对象。对于 SE agent 的训练，如何设计既高效又保真的训练环境将成为一个核心研究问题

---

SysTradeBench: An Iterative Build-Test-Patch Benchmark for Strategy-to-Code Trading Systems with Drift-Aware Diagnostics

推荐理由：提出了迭代式 build-test-patch 评估框架，揭示了 LLM 代码生成在迭代中的代码趋同现象，对理解 LLM 编程能力边界有价值

📌 论文信息：Yuchen Cao, Hanlin Zhang, Jacky Wai Keung, Yang Chen, Linqi Song | arXiv:2604.04812 | cs.SE

TL;DR

SysTradeBench 提出了首个评估 LLM 将自然语言策略规范转化为可执行交易代码的迭代式 benchmark。17 个模型的评估揭示了一个重要现象：虽然顶级模型达到 91.7% 以上的有效性，但证据驱动的迭代修补在第 2 轮就导致代码趋同。

问题是什么？

LLM 越来越多地被用作量化研究的 copilot，将自然语言的策略描述翻译成可执行的交易代码。但现有评估要么只关注静态金融知识，要么用单一的盈利指标来衡量，忽略了把策略转代码当作一个需要治理和审计的软件工程过程。

核心挑战在于：当 LLM 将策略文档转化为代码时，它需要保证：(1) 代码忠实于策略规范（spec fidelity），(2) 风险控制符合要求，(3) 代码可确定性执行（无泄露未来数据），(4) 在样本外保持鲁棒性。这是一个典型的"规范 → 代码 → 验证 → 修补"的 SE 循环，需要多维度评估。

他们怎么做的？

核心 Insight：将 LLM 代码生成评估从"一次性生成"升级为"迭代式 build-test-patch"循环，在每轮迭代中检测规则漂移（rule drift），确保修补不会偏离原始策略。

具体方法流程：

1. 标准化输入：每个任务包含一个 Base Strategy Doc（冻结语义）和标准化的市场数据
2. 多 artifact 输出：LLM 需要生成策略卡片、可执行代码、以及审计日志——不只是代码，还包括可解释性文档
3. 沙盒验证：自动化 harness 执行确定性检查、anti-leakage 检查、跨迭代规则漂移检测
4. 多维度评分：spec fidelity、risk discipline、reliability、out-of-sample robustness、cost-effectiveness

跟之前方法的本质区别：HumanEval/MBPP 等 benchmark 只测"能不能生成正确代码"。SysTradeBench 测的是"能不能在迭代修补中保持代码与规范的一致性"——这更接近真实 SE 中的需求。

关键结果

评估维度	顶级模型	发现
代码有效性	>91.7%	首轮生成质量已经很高
迭代修补	Iter2 趋同	证据驱动迭代导致代码趋同
规则漂移	存在	修补过程中策略语义发生偏移
多样性	下降	不同模型的解决方案在迭代后趋于相似

结果解读：最核心的发现是代码趋同现象（code convergence）：当给 LLM 提供测试反馈并让它迭代修补时，不同模型的代码在第 2 轮迭代后变得越来越相似。这意味着：

• LLM 的迭代修补策略是"向测试信号收敛"而非"探索多样解法"
• 在需要解法多样性的场景（如集成策略、ensemble robustness），LLM 迭代修补反而是有害的
• 人类量化研究员的不可替代性在于提供"不同的视角"，而非"更快的修补"

这个发现对 program repair 领域也极具警示意义：如果 LLM 在迭代 repair 中也存在 patch 趋同，那意味着 generate-and-validate 范式可能有一个内在的多样性瓶颈。

局限性与开放问题

• 局限 1：量化交易是一个非常特殊的领域，策略规范的形式化程度较高。在规范更模糊的 SE 任务中，迭代修补的表现可能完全不同
• 局限 2：12 个策略的规模较小，且策略复杂度未充分分层。简单策略（如移动平均线交叉）和复杂策略（如多因子组合）的表现可能有质的差异
• 开放问题：代码趋同是因为 LLM 的"模式塌缩"，还是因为测试反馈本身就在引导趋同？如果是后者，如何设计"鼓励多样性"的反馈信号？

💡 对我们的启发

1. 直接可用的技术点：SysTradeBench 的规则漂移检测（drift-aware diagnostics）可以直接应用到我们的 program repair 流程中。在 LLM 迭代修复 bug 时，我们可以检测 patch 是否偏离了原始代码的设计意图——这比单纯的测试通过/失败提供了更丰富的质量信号

2. 具体实验想法：在 program repair 场景中复现代码趋同实验。选取 20 个 Defects4J bug，用 5 个不同的 LLM 各迭代修补 3 轮（使用测试反馈），测量不同模型生成的 patch 之间的代码相似度（tree-edit distance 或 token-level similarity）。输入：bug + 测试反馈循环；做什么：记录每轮 patch 的多样性指标；预期观察：如果也存在 patch 趋同，我们就需要重新思考 iterative repair 中的 diversity preservation 策略

3. 研究趋势判断：这篇论文提出了一个重要的反思：迭代不等于改进。在 LLM for SE 的研究中，我们通常假设给 LLM 更多反馈就能得到更好的结果，但代码趋同现象说明反馈也可能是一把双刃剑。这可能催生"controlled iteration"或"diversity-preserving feedback"等新的研究方向

---

方法对比

维度	MIRAGE (LLM 模拟测试)	SandMLE (合成环境训练)
核心方法	LLM 运行时模拟微服务行为	合成微型 ML 环境加速 RL
LLM 角色	运行时组件（在线推理）	训练对象（被优化的 agent）
数据需求	依赖源码 + traces（无需标注）	种子任务 + agent 生成
计算开销	$0.16-$0.82/依赖（推理成本）	执行时间降 13x（训练成本）
适用场景	微服务集成测试	MLE agent 训练
主要局限	幻觉风险、延迟开销	微型环境保真度存疑

维度	数值稳定化 (LLM vs. 传统工具)	SysTradeBench (迭代评估)
核心方法	LLM 做表达式重写	迭代 build-test-patch 循环
评估焦点	LLM 代码变换的边界	迭代修补中的代码趋同
关键发现	LLM 在控制流推理上系统性失败	迭代反馈导致解法多样性丧失
启示	LLM 代码理解基于模式而非语义	迭代不等于改进
对 APR 的意义	patch 可能引入数值不稳定	iterative repair 需要 diversity preservation