💻 computer science

Prefactory: Automated Discovery and Application of Library-Adoption Refactorings

本文介绍了 Prefactory，这是一个利用大语言模型（LLM）合成可执行搜索启发式算法的自动化系统，旨在高效检测并应用 Python 代码中的库采用重构，在包含真实世界项目的全新基准测试中，其检测率和验证率均显著高于现有基准。

原作者： Islem Bouzenia, Michael Pradel

发布于 2026-07-21

📖 1 分钟阅读☕ 轻松阅读

原作者： Islem Bouzenia, Michael Pradel

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是一位图书管理员，负责整理一座规模宏大且混乱的图书馆，那里的每一本书都由不同的作者撰写，并使用各自独特的风格。有些作者在“重新发明轮子”，为一些在图书馆后勤室里已经有了完美现成工具的事物，编写冗长且复杂的说明书。在计算机编程的世界里，这被称为“重构”（refactoring）。它是清理杂乱的手写代码，并将其替换为对现有、经过充分测试的库（library）的简洁、高效调用的艺术。你可以把它想象成意识到你原本可以去商店买一件完美的毛衣，却一直在亲手织一件毛衣。问题在于，寻找这些机会就像在大海捞针，尤其是当这根针看起来一点也不像针的时候。手写的代码甚至可能根本没有提到那个库的名字，它只是以一种笨拙的方式实现了同样的功能。多年来，计算机一直难以发现这些隐藏的升级机会，因为它们过于僵化，而要求一个超级智能的 AI 去阅读项目中的每一个文件又太昂用且太慢。

Prefactory 诞生了，这是一个旨在解决这个谜题的新工具。Prefactory 并不是要求超级智能的 AI 每次都从头开始阅读整个代码库（这就像雇佣一名侦探去把图书馆里的每一本书都读一遍），而是教 AI 先构建一套定制的“金属探测器”。这些探测器就像是专门针对特定形状和声音的埋藏宝藏而调校过的专业金属探测器。一旦 AI 构建了这些探测器，它们就能在眨眼之间扫描整个代码库，找到与库函数模式相匹配的那些杂乱的手写代码。当发现匹配项时，AI 会最后介入一次，执行替换操作，并仔细检查新代码的功能是否与旧代码完全一致。

研究人员在包含 100 个真实世界案例的大规模集合上测试了这个想法，在这些案例中，开发者已经成功地将手写代码替换为了库调用。他们发现 Prefactory 在识别这些机会方面表现得极其出色。它在 100 个案例中的 75 个案例里成功识别出了正确的代码文件，并在 56 个案例中精准定位到了需要修复的函数。相比之下，次优的方法（即依赖标准 AI 代理阅读代码的方法）仅在 35 个案例中找到了正确的文件，在 32 个案例中找到了正确的函数。更棒的是，Prefactory 成功生成了 40 个经过完整验证、通过所有安全性测试的、可运行的重构结果。

这种方法之所以如此特别，是因为它节省了金钱和时间。使用 Prefactory 扫描一个项目平均仅需 1.3 秒，且寻找并修复一个实例的成本不到 0.05 美元。相比之下，标准 AI 代理方法的方法成本大约是其三倍，而且由于每次都必须“思考”整个项目，耗时也更长。论文指出，通过将 AI 的知识转化为可重用的、可执行的探测器，我们可以让代码清理变得快速、廉价且可靠。然而，作者也指出该系统目前并不完美；在面对那些“手写”代码与库的标准模式差异极大的超大型、复杂库时，它有时会感到吃力，并且它无法修复涉及复杂多文件架构变更的代码。但对于绝大多数日常的代码清理任务，这种全新的“构建探测器”的方法似乎是一个游戏规则的改变者。

技术摘要：Prefactory —— 自动化发现与应用库采用型重构

问题陈述

库采用型重构（Library-adoption refactoring）涉及将手写的代码实现替换为对现有库 API 的调用。这种实践可以减少代码规模、提高代码的惯用性（idiomatic quality），并利用经过充分测试的实现。然而，实现这一过程具有挑战性，原因如下：

缺乏显式线索： 原始的手写代码通常不会提及目标库或具体的 API，这使得依赖导入语句或直接引用的工具难以发现改进机会。
语法多样性： 开发者以多种方式实现相同的功能（不同的变量名、控制流或辅助函数），这意味着固定的语法模式或 Linter 规则往往难以泛化。
现有方法的局限性：
- 静态工具： Linter 和现代化工具（如 Ruff、Pylint）仅对手动指定的精确模式有效。
- LLM Agent（大模型智能体）： 虽然大语言模型（LLM）可以泛化到多样的模式，但通过重复提示词来扫描整个代码库是非常昂贵、难以复现且难以在大规模范围内进行系统化控制的。

核心瓶颈在于检测：如何在没有显式库提及的情况下找到相关的代码区域，并超越固定模板进行泛化，随后生成保持行为一致性的替换代码。

方法论：Prefactory 流水线

Prefactory 是一个自动化的四阶段流水线，旨在将 LLM 的语义知识转化为确定性的、可重用的搜索机制。它针对目标项目和目标库名称运行。

第一阶段：检测器生成

Prefactory 并不直接提示 LLM 去扫描代码，而是使用 LLM 来合成可执行的检测器。

输入： 目标库元数据（来自 PyPI、文档以及挖掘出的过往重构案例）和项目词汇表（来自目标项目的频繁出现的名称）。
输出： 两类检测器家族：
1. 词法检测器（Lexical Detectors）： 匹配领域术语、API 相关名称以及与手写实现相关的文本模式的正则表达式。
2. 结构检测器（Structural Detectors）： AST（抽象语法树）匹配器，用于识别算法形状（例如：对值的循环、算术索引计算、向数据结构中的累加操作），而无需关注具体的变量名。
验证： 生成的检测器经过过滤，以确保它们能够编译、不会崩溃，并且不会产生过于广泛的匹配（例如：匹配超过 20% 的文件）。

第二阶段：项目扫描

此阶段是确定性的且无需 LLM。

Prefactory 过滤掉非源文件（例如：供应商代码、测试、文档）。
经过验证的词法和结构检测器在剩余的源文件上执行。
匹配结果被记录下来，识别出候选文件和函数，以及触发该标记的具体检测器匹配项。

第三阶段：候选对象排序与过滤

为了管理 LLM 的成本，Prefactory 对候选对象进行排序并选择一小部分用于重写。

排序指标： 为每个候选对象 $c$ $c$ 计算一个元组 $(D(c), B(c), -S(c))$ $(D (c), B (c), - S (c))$ ：
- $D(c)$ ：检测器匹配强度（匹配项的加权和，优先考虑结构化匹配）。
- $B(c)$ ：基础 Python 实现模式（循环、算术、分支）的密度，指示手写逻辑。
- $S(c)$ ：候选对象大小（越小越好）。
选择： 选择前 5 个文件，并在这些文件中选择前 10 个函数进入下一阶段。

第四阶段：重构生成与验证

生成： 将候选函数、周围上下文、目标库 API 提示以及特定的检测器匹配项一起提示给 LLM。它尝试使用目标库重写该函数。
相关性过滤： 基于 AST 的检查确保编辑确实调用了目标库，而非仅仅是外观上的改动。
验证：
1. 差异化测试（Differential Tests）： LLM 生成一个独立的测试脚本，在生成的输入上比较原始函数和重构后的函数（使用原始函数作为 Oracle/基准）。如果测试失败，则要求 LLM 修复编辑内容（最多尝试 3 次）。
2. 项目测试： 如果差异化测试通过，则将重构后的代码在项目的现有测试套件中运行，以确保没有回归问题。

核心贡献

PrefactoryBench： 一个包含 100 个真实世界库采用型重构案例的基准测试，涵盖 61 个开源 Python 项目和 18 个库。它包括参考执行环境、项目测试以及用于评估检测和转换能力的留出测试（held-out tests）。
Prefactory 系统： 一种自动化的方法，通过合成可重用的、可执行的检测器（词法和结构检测器）来利用 LLM 知识，从而实现高效、确定性的扫描，而无需在搜索阶段进行重复的 LLM 调用。
实证证据： 通过受控对比证明，检测器合成在检测准确性和成本效率方面均优于直接的 LLM 提示、智能体搜索（Agentic Search）和基于规则的工具。

结果

在 PrefactoryBench 上进行评估，Prefactory 实现了以下目标：

检测： 在文件层面检测到 75 个实例，在函数层面检测到 56 个实例。
重构： 产生了 40 个经过验证的重构（通过了差异化测试和项目测试），这些重构源自检测到的 56 个函数。
对比： 优于最强的基准模型 Codex CLI（后者检测到 35 个文件和 32 个函数，并产生了 22 个验证后的重构），也优于 Linter、原生 LLM 提示以及 Semgrep+LLM。
效率：
- 扫描时间： 每个项目平均 1.3 秒（无需 LLM）。
- 成本： 端到端成本低于每实例 0.05 美元，约为 Codex CLI 基准成本的三分之一。
- 可重用性： 检测器在每个“项目-库”对中生成一次并重复用于扫描，使得重复扫描变得非常廉价。
实际应用： 在对五个基准项目的当前版本进行的调研中，Prefactory 发现了可操作的机会，其中两个提交的 Pull Request 被维护者接受。

重要性与主张

论文声称，**检测器合成（Detector Synthesis）**是一种实用且可扩展的库采用型重构工作流。通过将 LLM 的语义知识转化为确定性的搜索机制，Prefactory 避免了直接进行智能体搜索时的高昂成本和可复现性问题。

作者指出，当库的改进机会同时展现出词汇特征和可识别的实现结构时，该方法最为有效。对于大型、异构的库（例如 numpy、pandas，其机会跨越多个 API 家族），或者涉及复杂 I/O 或分布式行为的代码（此类情况下的差异化验证较难），仍存在局限性。这项工作证明，将 LLM 知识捕捉到可重用的、可执行的检测器中，比通过重复的、广泛的查询来应用 LLM 推理更加有效且更具成本效益。