很抱歉，您提供的信息不完整，我无法直接给出答案。请您提供更具体的问题或信息，这样我才能更好地帮助您。

介绍 (1) 发表 2024-07 ISSTA'24 (2) 背景 对于某些较为复杂的 bug，需要强大的代码理解和推理能力才能解决 方法 (1) 收集阶段 prompt 准备：角色描述+任务描述+思维链启示 思维链收集：prompt 给 LLM 生成思维链，这里的输出是样本的集合，其中样本包括 buggy 函数、修复函数和思维链 功能验证：为了获得有效的样本，过滤低质量样本的思维过程。ThinkRepair 运行一个测试套件来测试上一步中 LLM 输出中提取的修复函数，仅保留成功通过整个测试套件的修复函数（这里为每个 bug 执行最多 25 次尝试） (2) 修复阶段 Few-shot 选择：从收集阶段得到的知识库中选择最有益的示例。ThinkRepair根据语义相似性将这些示例聚集在知识库中，已挑选不同的示例 自动化修复：根据选定的示例和目标 buggy 函数来构建一个 prompt，最后得到输出 交互验证：通过运行测试套件验证所有候选修复函数，对于测试失败的用例，收集失败信息（① 编译失败 ② 超时 ③ 语法错误 ④ 测试失败）。然后 ThinkRepair 重建 prompt，并把失败信息附加到原始 prompt 的后面，最后生成新的修复函数。此迭代过程一直持续，直到获得固定函数（即成功通过整个测试套件）或最大交互次数超过。 总结 这篇工作借鉴了 slow thinking 的方法，通过反复自生成 COT 的方式增强 LLM 的推理能力，从而提升 APR 的性能