对于大模型来说，擅长的是本地化编码任务。
但如果任务跨越了多个相互依赖的文件，LLM却无法解决。
对此，微软研究人员设计了一个任务无关的神经网络框架，名为CodePlan。
图片
论文地址：https://arxiv.org/pdf/2309.12499.pdf
论文中，CodePlan综合了多步骤编辑链（chain-of-edits），是一种将程序分析、规划和LLM结合在一起的新方法。
一起来具体看看，CodePlan是如何设计的？
CodePlan：大模型+规划
软件工程活动中，例如软件包迁移、修复静态分析或测试的错误报告，以及向代码库添加类型提示或其他规范，涉及到对整个代码存储库的普遍编辑。
研究人员将这些活动规划，为「存储库级别的编码任务」。
随着编码工具如GitHub Copilot、Code Whisperer得到了大模型能力加持，已经为码农在本地化编码问题提供了解决方案。
然而，现实是，「存储库级别的编码任务」更加复杂，不能直接通过LLM解决，因为存储库中的代码是相互依赖的，整个存储库可能太大而无法纳入提示。
这项研究中，微软团队将库级编码框架作为一个规划问题，并提出了一个任务不可知的框架，称为CodePlan。
CodePlan综合了一个多步骤的编辑链（计划） ，其中每一步都会调用代码位置上的LLM。该代码位置上的上下文来自整个存储库、以前的代码更改和特定于任务的指令。
CodePlan是基于增量依赖分析、变更可能影响分析和自适应规划算法的新型组合。
图片
如下图，展示了复数库API的变化，微软研究人员的任务是根据这一变化迁移代码库。
图片
图3左侧显示了代码库中使用复数库的相关部分。
具体来说，Create.cs文件中的方法func，调用了库中的create_complex方法，Process.cs文件中的方法Process.cs调用了func。
图片
研究人员将图1中的任务描述和func主体传递给LLM，以生成修改后的func代码，如图3右侧所示。
可以看到，LLM已经正确地编辑了对create_complex API的调用，以便它返回一个Complex类型的对象，而不是两个浮点值的元组。
注意，这个编辑导致了方法func的签名发生了变化——它现在返回了一个Complex类型的对象。
这就需要修改方法func的调用者，比如Process.cs中的process方法，如图3左下角所示。如果不对process方法的主体进行适当的修改，代码就不能构建！
图3右下方显示了对process方法的适当修改，它能使版本库达到一致的状态，从而在编译时不会出错。
对于研究人员来说，最主要的是构建一个「存储库级别的编码系统」，能自动生成编辑所需的派生规范。
LLM驱动的库级编码任务定义如下:
图片
CodePlan整体框架中，输入是一个存储库、一个通过自然语言指令或一组初始代码编辑表达种子规范的任务，一个正确性oracle和一个 LLM。
CodePlan构建了一个计划图，图中的每个节点都标识 LLM需要履行的代码编辑义务，而边则表示目标节点需要在源节点之后履行。
CodePlan监控代码编辑，并自适应地扩展计划图。
一旦计划中的所有步骤都已完成，存储库将由oracle进行分析。如果oracle验证了资源库，则任务完成。如果发现错误，错误报告将作为下一轮计划生成和执行的种子规范。
图片
此外，CodePlan算法还维护了一个依赖关系图，图4说明了依赖关系图的结构。
图片
刷新SOTA
研究人员评估了CodePlan在两个存储库级任务上的有效性: 包迁移 （C#）和时态代码编辑（Python）。
每个任务在多个代码库上进行评估，每个代码库都需要对多个文件（2-97个文件）进行相互依赖的更改。
图片
这种复杂程度的编码任务，以前从未使用过LLM自动完成。
研究结果表明，与基线相比，CodePlan更符合基本事实，能够让5/6个存储库通过有效性检查，比如，无差错构建和正确的代码编辑。
总之，CodePlan为自动化复杂的库级编码任务提供了一种有前途的方法，既提高了生产率，又提高了准确性。
它成功应对了许多挑战，为高效可靠的软件工程实践开辟了新的可能性。
参考资料：https://twitter.com/adityakanade0/status/1706291449674039711
