企业官网建设流程全解析

这项由宾夕法尼亚大学（University of Pennsylvania）开展的研究，以预印本形式发布于arXiv平台，编号为arXiv:2501.18916v2，最新版本更新于2026年6月23日。感兴趣的读者可通过该编号在arXiv数据库中检索完整论文。

程序员们有一个共同的烦恼：写出来的代码能跑，但跑得慢。就像一道菜做出来能吃，但味道和效率都还不够好。专业的大厨会用多年积累的经验和技巧，一步步把菜肴打磨到极致。那么，能不能让AI也学会这种"精益求精"的本领，把一段普通代码反复打磨成高效程序？

这正是这项研究要解决的核心问题。研究团队发现，现有的大型语言模型（就是ChatGPT这类AI）其实并不擅长优化程序——因为训练数据中几乎没有"程序跑得快慢"这类信息，AI从来没学过这个。所以光靠AI直接改代码，效果非常有限。

为了突破这个瓶颈，研究团队提出了两套新方法：一套叫做"检索增强搜索"（RAS），另一套叫做"原子编辑引导搜索"（AEGIS）。这两套方法配合使用，让AI在优化代码时的平均速度提升幅度达到了人类程序员水平的两倍多，甚至在某些测试中超越了人类选手的优化成果。

一、问题出在哪里：AI改代码为何总差点意思

要理解这项研究的价值，得先搞清楚"程序优化"到底是怎么回事。假设你写了一段代码，功能正确，但运行起来很慢——就像你找到了正确的路，但走的是羊肠小道而不是高速公路。程序优化的任务，就是在不改变代码功能的前提下，帮它找到那条"高速公路"。

现代编译器（把人写的代码翻译成机器能执行的语言的工具）会做一些自动优化，但这些优化都是"低层次"的，就像帮你把鞋带系得更紧，却没办法告诉你换一双跑鞋。真正高水平的优化，往往需要改变算法本身——比如把一个每次都从头搜索的笨方法，换成一个能记住中间结果的聪明方法。这种级别的优化，需要深刻理解程序在做什么。

此前，宾夕法尼亚大学的团队已经建立了一个名为PIE（Performance Improving Edits，性能提升编辑）的基准测试集，专门用来衡量各种AI方法在C++程序优化上的表现。他们发现，当时效果最好的"黑盒"方法（不调整AI权重、只靠提示词驱动的方法）叫做"动态代码检索"——它的做法是在一个由"慢程序-快程序"配对组成的训练数据库中，根据代码相似度找几个相关案例，然后把这些案例喂给AI，让AI学着照葫芦画瓢地改写当前程序。

这个方法已经比什么都不做强很多，但研究团队觉得还不够好。问题在于：仅仅"找代码长得像的例子"，并不能保证找到的例子真的用了相同的算法思路。两段代码可能都用了大量的循环和数组操作，表面上看很像，但一个在解决"最短路径"问题，另一个在处理"字符串匹配"——优化策略完全不同，找这种"形似神不似"的例子帮不上什么忙。

此外，原来的方法是"一锤子买卖"——给AI一组例子，让它一次性生成改好的代码，不管结果好不好都不再继续打磨。这就像请一个厨师来改良菜谱，但只让他尝一口就提交最终版本，不给他反复试验的机会。

二、RAS的核心创意：先描述算法，再按算法找例子

新方法RAS的第一个关键改进，是改变了"找相似案例"的方式——从"看代码长什么样"变成"看代码在做什么"。

具体做法是这样的：当AI拿到一段待优化的程序时，先不急着去翻数据库找类似代码，而是让AI先"读懂"这段程序，用一句自然语言描述它的核心算法。比如，一段代码可能被描述为"使用带记忆化的动态规划，寻找从第一个元素到最后一个元素的最小跳跃代价，代价定义为相邻元素的绝对差值之和"。

有了这段文字描述之后，再把这段描述转换成一个数学向量（可以理解为一串数字，代表这段话的语义），然后去数据库里找语义最相近的案例——也就是那些同样使用了类似算法思路的"慢程序-快程序"配对。

这种方式的妙处在于，两段写法完全不同的程序，只要它们用的是同一种算法，就能被正确地匹配在一起。反过来，两段看起来很像的程序，如果算法本质不同，也不会被错误地匹配。这就像在图书馆找书，与其按封面设计找，不如按内容主题找，找到的书才真正有参考价值。

为了实现这个"先描述后检索"的过程，研究团队预先对训练数据库里的每一对慢-快程序都生成了自然语言描述，并存储好对应的语义向量。这样在实际使用时，只需要给当前待优化程序生成一次描述，就可以快速检索到最相关的案例，不会产生太大的额外计算开销。

三、RAS的第二个创意：反复打磨，而不是一次了事

RAS的第二个改进是引入了"束搜索"（beam search）机制。这个名字听起来很学术，但背后的道理非常直观。

回到厨师改良菜谱的比喻：与其让厨师尝一口就定稿，不如让他做出几个改良版本，挑出其中最好的一个，然后以这个版本为基础再做新一轮改良，如此往复几轮，最终得到一道真正经过反复打磨的菜。

RAS的工作流程正是如此。从原始的"慢程序"出发，第一步：检索相关案例，让AI生成若干个优化版本，从中挑出跑得最快且结果正确的那一个。第二步：把上一步选出的最优程序作为新起点，再次检索相关案例（注意，这次检索的是基于已经优化了一轮的新程序的描述，所以找到的案例也会更相关），再生成若干个新版本，再挑最优。如此循环，论文中默认进行四轮。

每一轮中，AI只使用一个检索到的案例（一对慢-快程序）作为参考，而不是像之前的方法那样把多个案例一股脑全塞进提示词。这样做的好处是，每一步的优化方向更清晰、更聚焦，不会让AI陷入"同时学太多技巧、反而不知所措"的困境。

在整个搜索过程中，有一个重要的细节保证了效率：每一轮检索时，算法会刻意避免使用之前已经用过的案例，确保每一步都能引入新的优化思路，而不是原地踏步。

四、实验数据：RAS到底比之前好多少

研究团队在两个基准测试集上验证了RAS的效果。

在C++程序优化方面，使用了PIE基准测试集，包含973个待优化的测试程序。衡量指标是"平均最佳加速比"——也就是经过优化后，程序平均能跑得多快。

使用GPT-4o作为底层AI时，RAS达到了8.03倍的平均加速比，而原来最好的"动态代码检索"方法只有4.43倍。使用更新的Qwen3-Coder模型时，RAS达到8.70倍，动态检索只有4.23倍。使用DeepSeek 3.2时，RAS达到9.18倍，动态检索为7.03倍。

另外还有一个"优化成功率"指标（% Optimized），衡量有多少比例的程序被成功提速超过10%。RAS在GPT-4o下达到96.92%，在Qwen3-Coder下达到98.56%，在DeepSeek 3.2下达到99.08%，而人类程序员的成功率是98.87%。也就是说，RAS在优化成功率上已经与人类程序员不相上下，甚至在某些模型下小幅超越。

研究团队还设计了一个"去掉上下文检索、只保留迭代搜索"的对照实验（称为"No Contextual"），结果显示它的性能明显低于完整的RAS，介于动态检索和RAS之间。这说明"基于算法描述的检索"和"迭代搜索"这两个创新各自都贡献了显著的性能提升，缺一不可。

在Python程序优化方面，研究团队使用了Mercury基准测试集（包含256个LeetCode题目的Python解法）。核心指标是"Beyond@1"，代表程序在所有提交中的运行时间百分位。使用Qwen2.5-7B-Instruct这个相对较小的模型，原始未优化程序的均值是58.66，而RAS将其提升到87.85，提升幅度超过10个百分点，显著缩小了小模型与大模型之间的性能差距。

五、AEGIS：像编译器一样，把大改动拆成小步骤

RAS虽然效果很好，但它每一步的改动幅度往往很大——就像一个厨师直接把菜谱改得面目全非，你很难搞清楚哪一步改动起了关键作用。这对于需要理解和审查优化过程的程序员来说，不够透明。

受现代编译器设计思路的启发，研究团队提出了AEGIS（原子编辑引导搜索）。现代编译器做优化时，不是一次性大改，而是经过一系列"编译器趟次"（compiler passes），每一趟只做一种特定类型的微小改动，比如"消除重复计算"、"把递归改成循环"、"优化内存访问顺序"等。AEGIS就是要让AI也学会这种"小步快跑"的优化方式。

AEGIS的核心是一个"预处理"步骤：在正式优化任何程序之前，先对训练数据库里的每一对慢-快程序进行"拆解"。具体过程可以分为三个阶段。

第一阶段是"分解"：让AI看一对慢程序和快程序，然后用自然语言描述出这两者之间的差异，把它们拆解成一个有序的改动列表。比如"第一步：把cin/cout替换成scanf/printf以加快输入输出；第二步：把不必要的变量声明移到循环外面；第三步：把递归改成迭代"等。

第二阶段是"重建"：按照这个改动列表，从原始慢程序出发，一步一步地应用每个改动，生成一系列中间程序。比如第一步改动之后得到程序1，第二步改动之后得到程序2，以此类推。这样就把一对慢-快程序变成了一条"程序演化链"，链上的每一步只有一个微小改动。

第三阶段是"泛化"：每一个微小改动都有对应的自然语言描述，但这些描述是针对特定训练程序的，比如"把这个函数里的递归改成循环"。为了让AI能把这个改动应用到其他程序上，需要让AI把描述改写成更通用的表达，比如"对于使用递归且存在重叠子问题的动态规划算法，将其改写为自底向上的迭代实现，以消除函数调用开销"。这种更通用的描述就是"原子编辑"。

经过这个预处理步骤，原来的训练数据库从"慢-快程序对"变成了"原子编辑+程序示例对"的数据库，里面包含了大量细粒度的、可泛化的优化技巧。

在实际优化一个新程序时，AEGIS仍然使用RAS的迭代搜索框架，但每次检索的不再是整体的慢-快程序对，而是最相关的"原子编辑"。找到相关的原子编辑后，AI被要求把这个具体的优化技巧应用到当前程序上，同时参考数据库中该原子编辑对应的程序示例。

六、AEGIS的实验结果：更小的步子，更容易理解的过程

AEGIS在性能上略低于RAS，但仍然显著优于所有基线方法。使用GPT-4o时，AEGIS达到6.08倍平均加速比；使用Qwen3-Coder时为5.37倍；使用DeepSeek 3.2时为6.48倍。这些数字都远高于动态代码检索的4.43倍/4.23倍/7.03倍，也超过了"无上下文"对照实验的3.86倍/2.76倍/5.87倍。

研究团队分析了AEGIS性能略低于RAS的两个可能原因：一是AI分解生成的中间程序，不能保证每一步都有实质性的性能提升，可能有些"原子编辑"其实没什么用；二是同一对原始训练数据可能产生多个原子编辑，在检索时这些相关编辑可能被重复选取，降低了搜索过程的多样性。

但AEGIS真正的优势体现在"可解释性"上。研究团队用"字符级编辑距离"来衡量每一步改动的幅度（编辑距离越小，说明改动越小、越容易理解）。结果显示，AEGIS的平均编辑距离明显低于RAS：使用GPT-4o时，AEGIS为213.05，RAS为257.77；使用Qwen3-Coder时，AEGIS为194.05，RAS为259.87；使用DeepSeek 3.2时，AEGIS为263.24，RAS为296.41。

更值得关注的是第一步的改动幅度对比：RAS在第一步往往会做出极大的改动（编辑距离约500-600），之后的步骤改动相对较小；而AEGIS第一步的改动就已经被控制在250-400的范围内，全程改动更为均匀分散。这对于需要理解和审查优化过程的程序员来说，更加友好。

七、AI改的代码，准确率有多高

任何代码优化方法都必须回答一个关键问题：改完之后，代码还是正确的吗？功能被改坏的"优化"不是优化，而是引入了新bug。

研究团队对这个问题做了仔细检验。在GPT-4o实验中，他们模拟了"如果只追求速度、不管正确性"的场景，看看AI是否会选择错误的程序。结果是：RAS在全部973个测试案例中，只有5个会选到错误程序，准确率99.5%；AEGIS则完全没有选到错误程序，准确率100%。

为了更严格地验证，研究团队还用了一个叫做CBMC（C语言有界模型检查器）的专业工具，对DeepSeek 3.2生成的10个程序对进行形式化的等价性验证——也就是用数学方法证明优化前后的程序在所有可能的输入下都会产生相同的输出。结果是10个程序对中有8个被证明完全等价，剩余2个存在微小差异（一个程序多输出了几个换行符），核心逻辑完全正确。

八、失败案例分析：哪类问题让AI犯难

研究团队还仔细分析了哪些程序没能被成功优化，从中发现了一些规律。

对于AEGIS，"未优化"程序集合中有12.09%涉及二分搜索，而整个测试集中只有4.32%的程序涉及二分搜索——说明AEGIS对二分搜索类程序的优化能力相对薄弱，失败率比平均水平高出接近三倍。此外，AEGIS未优化集合中有45.05%是动态规划问题，整体比例为51.59%，这个差距不算特别显著。

对于RAS，整体失败率更低（只有3.08%的程序未被成功优化）。但有意思的是，涉及Kruskal算法（一种用于求解最小生成树的图论算法）的程序，在全体测试集中只占1.03%，却在RAS的失败案例中占到了20%，是个明显的薄弱点。相比之下，AEGIS在Kruskal算法上的失败率反而更低一些。

这种分析有很实际的价值：通过识别两种方法各自的弱点，可以有针对性地在训练数据库中补充相关类型的优化案例，从而进一步提升性能。

九、代码嵌入模型的对比实验

研究团队还专门检验了"用专门针对代码训练的嵌入模型，能不能缩小代码检索与上下文检索的差距"这个问题。他们用Codestral-Embed-2505（一个专为代码设计的语义向量模型）替换了默认的通用文本嵌入模型，在DeepSeek 3.2的第一轮搜索中进行对比。

结果显示：RAS（上下文检索）在第一轮达到8.03倍加速、96.30%优化成功率；代码嵌入（Codestral）达到6.57倍、88.39%；通用文本嵌入（无上下文）达到5.92倍、87.26%。专用代码嵌入模型确实比通用文本嵌入略好一些，但与上下文检索的差距仍然很明显。

研究团队解释了这个现象背后的原因：竞赛程序员写代码时常常使用相似的变量名和操作模式，导致表面上很像的代码实际上在解决完全不同的问题，代码嵌入会被这些表面相似性误导。而上下文检索通过算法描述抽象掉了这些表面差异，找到的是真正在算法层面相似的案例，自然效果更好。

十、研究的局限性与未来方向

研究团队坦诚地讨论了两个主要局限性。第一，RAS和AEGIS都需要对每个程序进行多轮优化-评估循环，计算开销比一次性生成要大，在实际大规模部署时需要考虑成本。AEGIS还有额外的预处理开销，需要提前对整个训练数据库进行拆解和重建。

第二，这套方法目前主要在相对简单、独立的程序（如竞赛编程题目的解法）上验证，对于由多个模块组成的大型工业代码库，可能需要先解决"找到哪些代码片段值得优化"的问题，才能套用这套框架。

尽管如此，研究团队认为这套方法为将AI应用于实际代码优化提供了一条可行的路径。事实上，相关技术已经开始在工业界落地，宾夕法尼亚大学的相关研究人员此前发表的研究中提到了将高层代码优化应用于仓储系统性能提升的实践。

归根结底，这项研究做了一件很有趣的事：它教会AI"先理解程序在做什么，再去找相似的优化案例"，同时让AI养成了"反复打磨、每次只做一个改动"的好习惯。这两个改变加在一起，让AI的代码优化能力产生了质的飞跃。

对普通人来说，这意味着未来我们使用的各种软件、APP、在线服务，有可能在不改变功能的前提下跑得更快、耗电更少——因为背后的代码经过了AI的精心打磨。对程序员来说，这套方法提供了一个有力的辅助工具，尤其是AEGIS的"小步改动"模式，让程序员能清楚地看到每一步优化在做什么、为什么要这样做，而不是面对一段突然变成另一段的神秘代码。

当然，正如研究团队自己指出的，AI优化的结果仍然需要程序员来验证正确性。这套工具还没有强大到完全自主运作的程度，更像是一个博学的助手，帮你提出优化建议，最终决定权仍在人的手中。有兴趣进一步了解技术细节的读者，可以在arXiv上通过编号arXiv:2501.18916查阅完整论文。

Q&A

Q1：RAS（检索增强搜索）和普通的AI代码优化有什么区别？

A：普通AI代码优化通常是"一次性"的，直接让AI改写程序。RAS的不同之处有两点：一是检索时先让AI用自然语言描述程序用的算法，再找算法相似的参考案例，而不是找代码写法相似的；二是会反复迭代多轮，每轮选出最优结果再继续改进，而不是生成一次就结束。这两个改进使平均加速效果比此前最好的方法高出约两倍。

Q2：AEGIS生成的原子编辑数据库是怎么来的？

A：AEGIS通过三个步骤构建原子编辑数据库。首先让AI对训练集中每对慢-快程序进行差异分解，用自然语言描述出若干个具体的改动步骤。然后按步骤逐一应用这些改动，生成一系列中间程序。最后让AI把每个改动的描述从"针对特定程序"改写成"适用于更多程序"的通用表达。这样训练集中的每对程序都会产生多个"原子编辑+示例程序对"，汇总形成数据库。

Q3：RAS优化后的程序准确率怎么保证？

A：RAS在每一步搜索中只保留通过所有测试用例的程序，不正确的直接排除。实验中GPT-4o版RAS在973个测试案例上的准确率为99.5%，AEGIS为100%。此外研究团队还用形式化验证工具CBMC对10个DeepSeek生成的程序进行了数学等价性证明，8个完全等价，另2个只有输出格式的微小差异，核心逻辑完全正确。