💻 computer science

TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

本文介绍了 TICoder，一种新颖的仓库级代码生成框架，它通过集成用于行为引导的测试驱动迭代规划机制，以及一种结合双视图相似度与双阶段选择的实现感知重用策略来有效利用现有仓库代码，从而增强了大语言模型的性能，并实现了相比现有最先进方法 11.52% 的平均提升。

原作者： Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

发布于 2026-06-09

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

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

想象一下，你是一位大师级厨师（AI），正试图根据顾客模糊的订单“给我做点带意面（pasta）的东西”来烹饪一道复杂的菜肴。你可以访问一个庞大的食谱库（代码仓库），但你一次只能阅读几页。

大多数目前的 AI 厨师试图通过查找一个听起来与“意面”相似的单一食谱并进行复制来解决这个问题。但这往往会失败，因为顾客可能想要特定类型的意面，或者食谱可能漏掉了关键步骤，比如“先烧开水”。

TICoder 是一种更聪明的方式，可以帮助 AI 厨师烹饪。它就像一位高度组织化的副厨，不仅能帮你找到食谱，还能帮助 AI 规划这一餐，并准确地学习如何正确使用食材。以下是它的工作原理，分为三个简单的部分：

1. “测试驱动型”规划（味觉测试）

问题： 当 AI 试图仅根据顾客模糊的词汇来规划烹饪菜肴的步骤时，它经常会遗漏细节。它可能会忘记检查意面是否是无麸质的，或者酱汁是否需要炖煮一小时。

TICoder 的解决方案： 在 AI 开始烹饪之前，TICoder 会要求进行一次“味觉测试”（测试用例）。这些就像是具体的指令：“酱汁必须是辣的，”或者“意面必须是弹牙的（al dente）。”

工作原理： AI 起草一个计划。然后，一个“评判者” AI 会查看该计划和味觉测试。如果计划与测试不符（例如，“你忘了加辣味！”），评判者就会将其退回进行改进。
结果： AI 会不断循环这个“起草、评判、修正”的过程，直到计划完美符合预期的结果。这确保了 AI 在开始构建之前，确切知道自己要构建什么。

2. “实现感知型”复用（寻找正确的工具）

问题： 一旦 AI 有了计划，它就需要从库中寻找现有的工具（函数）来提供帮助。

旧方法： AI 寻找听起来符合它需求的工具。它可能会找到一个能用的“酱汁制作器”，但它使用的热量不对，或者在不该加盐的时候加了盐。它拿到了工具，却不知道如何正确使用它。
TICoder 解决方案： TICoder 从两个维度看待工具：
1. 功能： 它是否完成了正确的工作？（例如：“是的，它能制作酱汁。”）
2. 实现： 它是否以正确的方式工作？（例如：“是的，它炖煮 20 分钟，正如我们所需要的。”）
结果： 它找到了既匹配工作描述，又匹配特定执行方式的精确工具。

3. “使用模式”选择（从示例中学习）

问题： 即使 AI 找到了完美的工具，它也可能不知道如何将其接入。想象一下你找到了一台复杂的浓缩咖啡机，但不知道按哪个按钮才能做出拿铁而不是卡布奇诺。

TICoder 解决方案： TICoder 不仅仅把工具交给 AI；它还会向 AI 展示其他厨师过去是如何使用这个精确工具的。

它查看食谱库，观察这个工具在真实的食谱中是如何被实际使用的。
它通过筛选数千个示例，找到使用该工具的最佳、最常见的方法（聚类相似方法），并剔除那些令人困惑或古怪的方法。
结果： AI 会得到一份“小抄”，展示使用该工具的前 2 到 3 种最佳方式，从而确保它在组装最终菜肴时不会出错。

最终结果

当你将这三个部分结合在一起时：

规划： AI 确切知道该做什么，因为它通过“味觉测试”检查了自己的工作。
检索： 它找到了既匹配工作又匹配方法的完美工具。
复用： 它知道如何使用这些工具，因为它研究了真实的示例。

成果： 在论文的实验中，这种方法帮助 AI 更好地完成烹饪（生成代码）任务。在不同类型的编码任务和不同的 AI 模型上，它将成功率平均提高了 11.52%。本质上，TICoder 将一个困惑的 AI 变成了一位精准、规划周密且经验丰富的厨师。

技术摘要：TICoder

问题陈述

使用大语言模型（LLM）进行仓库级代码生成面临着由于复杂的代码依赖关系和有限的上下文窗口所带来的显著挑战。虽然现有的方法利用检索增强生成（RAG）和规划机制来复用仓库中的函数，但作者指出了当前最先进（SOTA）方法的两个关键局限性：

缺乏基于测试驱动的行为引导规划： 现有的基于规划的方法直接从自然语言（NL）需求中推导实现步骤。然而，自然语言需求通常是模糊或不完整的，导致生成的计划不可靠。目前的测试驱动生成方法主要在代码生成或生成后阶段应用测试用例，未能充分挖掘其在引导“规划”过程中的潜力。
缺乏代码层面的实现感知复用： 现有的检索策略过度依赖实现步骤与函数描述之间的语义相似性。它们往往忽略了嵌入在代码中的实际实现逻辑。此外，检索到的函数在插入提示词时，往往缺乏对其在仓库中究竟是如何被使用的（使用模式）的理解，从而导致复用效果不佳。

方法论：TICoder 框架

作者提出了 TICoder，一个旨在改进仓库级代码生成中规划和复用阶段的框架。该框架由三个主要阶段组成：

1. 测试驱动的迭代规划

TICoder 不仅仅根据自然语言需求生成计划，而是利用测试用例作为行为规范来细化实现步骤。该阶段采用了一种涉及两个 LLM 角色的“评判与反思”机制：

LLM 作为规划者（LLM-as-a-Planner）： 根据需求和测试用例生成初始的实现步骤序列，并遵循清晰度、边界条件意识和显式依赖等原则。
LLM 作为评判者（LLM-as-a-Judge）： 根据三个维度评估生成的步骤：功能覆盖度/一致性、独立性和粒度。
迭代细化： 如果步骤未达到质量阈值，评判者会提供反馈，由规划者进行细化。此循环持续进行，直到计划令人满意或达到最大迭代限制。

2. 实现感知的代码复用

该阶段侧重于检索相关的被调用函数（callee functions）并确定如何有效地使用它们。

双视图被调用函数检索： 为了检索函数，TICoder 计算了一个结合以下内容的联合相似度得分：
- 功能相似度 ( $Sim_F$ )： 实现步骤与函数描述之间的语义相似度。
- 实现相似度 ( $Sim_I$ )： 实现步骤的代码表示（由 LLM 生成）与实际函数实现代码之间的相似度。
- 最终得分为加权和 ( $Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$ )。
双阶段使用模式选择： 为了确保函数被正确使用，TICoder 从仓库中选择具有代表性的使用模式：
- 基于图的识别： 构建仓库调用图（RCG）以识别检索到的被调用函数的所有调用者（caller）函数。
- 基于结构的聚类： 根据调用函数所调用的函数集合（结构等价性）对调用者函数进行分组。
- 基于困惑度的过滤： 在每个簇内，选择最具代表性的调用者（困惑度最低者）作为中心。随后通过全局过滤器按困惑度对这些中心进行排序，以选择前 $n_p$ 个模式，从而在上下文丰富度与 Token 效率之间取得平衡。

3. 增强的代码生成

最后的代码生成阶段将细化后的实现步骤、检索到的被调用函数、选定的使用模式、测试用例以及原始需求整合到单个提示词中，供 LLM 生成最终代码。

核心贡献

论文声称了三个主要贡献：

TICoder 框架： 一种新型的仓库级代码生成框架，集成了测试驱动的迭代规划和实现感知的代码复用。
实现感知复用策略： 一种双视图检索机制（功能相似度 + 实现相似度）和双阶段选择策略（聚类 + 困惑度过滤），用于精确识别和复用仓库函数。
广泛的实证评估： 全面的实验证明，TICoder 在多个 LLM 和基准测试上均优于 SOTA 基准方法。

实验结果

作者在两个广泛使用的基准测试 CoderEval（Python 和 Java）和 DevEval（Python）上对 TICoder 进行了评估，使用了三个骨干 LLM：GPT-4o-mini、DeepSeek-V3 和 Qwen2.5-Coder-7B。

整体性能： TICoder 一致地优于所有基准方法（包括 SimpleRAG、RepoCoder、AllianceCoder 和 RepoScope）。它比表现最好的基准方法平均提升了 11.52%。
统计显著性： 双尾 t 检验确认了性能提升具有统计学意义（ $p < 0.05$ ）。
消融实验： 移除任何关键组件（规划、测试用例、迭代细化、双视图检索或使用模式）都会导致性能下降，验证了每个模块的必要性。
- 特别是，移除规划模块导致 Pass@1 下降了 6.87%。
- 从生成阶段移除测试用例导致了高达 10.42% 的大幅下降。
超参数敏感性：
- 迭代次数： 性能通常随迭代次数增加而提高，但呈现非单调性；过多的迭代可能会引入噪声。
- 相似度权重： 功能相似度通常更为重要，但实现相似度也提供了显著收益，尤其是在 Java 语言中。
- 使用模式： 中等数量的模式（例如 2 个）能产生最佳结果；模式太少会限制上下文，太多则会引入噪声。

重要性与主张

论文断言，TICoder 通过将测试用例明确纳入规划阶段，并将检索建立在实际代码实现逻辑之上，解决了以往基于规划的 RAG 方法的具体局限性。作者声称，通过通过行为规范（测试）和结构上下文（使用模式）来弥合自然语言需求与可执行代码之间的鸿沟，TICoder 使 LLM 能够在复杂的仓库设置中生成更准确且符合上下文的代码。这项工作强调，成功的仓库级生成不仅需要找到相似的代码，还需要理解这些代码是如何在行为上被规范以及在结构上如何被集成的。