💻 computer science

Code Reasoning for Software Engineering Tasks: A Survey and A Call to Action

本文综述了大型语言模型在软件工程领域的测试时推理技术，证明了利用代码特定信号（如结构和执行反馈）能显著提升其在复杂任务上的性能，并概述了面向代码中心化推理的未来研究方向。

原作者： Saurabh Pujar, Ira Ceka, Irene Manotas, Gail Kaiser, Baishakhi Ray, Shyam Ramji

发布于 2026-06-30

📖 1 分钟阅读☕ 轻松阅读

原作者： Saurabh Pujar, Ira Ceka, Irene Manotas, Gail Kaiser, Baishakhi Ray, Shyam Ramji

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

想象一下，你有一个非常聪明、博学多才的助手（一个大语言模型，简称 LLM），它非常擅长写故事，但有时在被要求编写计算机代码时会显得有些吃力。代码非常棘手，因为它不像故事那样可以灵活处理，它必须完美运行，否则就会出错。

这篇论文是一篇综述（一次大规模回顾），探讨了研究人员如何教这些 AI 助手在编写代码之前更好地“思考”。来自 IBM 和哥伦比亚大学的作者们研究了数十种新方法，以观察哪些方法能真正帮助 AI 解决软件工程问题，例如修复漏洞或构建新功能。

以下是他们研究结果的详细拆解，使用了简单的类比：

1. 问题所在：“初稿”陷阱

通常情况下，当你要求 AI 编写代码时，它的表现就像一个正在参加考试的学生：它读完题目后，立即写下它的第一个答案。如果这个答案错了，任务就结束了。

论文的洞察： 最好的结果来自于我们强制 AI 在编写最终代码之前停下来思考。这被称为“推理时推理”（test-time reasoning）。这就像是要求学生在给出答案之前先展示其解题过程，而不是仅仅靠猜想得出答案。

2. 工具箱：让 AI 思考的四种方式

作者将所有这些新方法归纳为四个主要类别，他们称之为“推理工具箱”：

思维链 (Chain-of-Thought, CoT)： “步进式规划者”
- 类比： AI 不再直接跳向解决方案，而是被要求先写一份计划。
- 转折点： 论文发现，基于结构的计划比模糊的计划效果更好。
- 示例： 一个模糊的计划会说：“盖一座房子。”而一个基于结构的计划会说：“首先，打好地基（混凝土），然后搭建框架（木材），最后安装屋顶。”因为代码有着严格的规则（就像一座房子），所以以代码结构（循环、函数）来进行思考，比仅仅写一段关于代码的故事对 AI 更有帮助。
自我修正 (Self-Refinement)： “编辑与调试员”
- 类比： AI 写出一个草稿，运行它看看是否崩溃，阅读错误信息，然后修复自己的作品。
- 结果： 这是一个巨大的赢家。论文发现，让 AI “运行”其代码并修复自身的错误（自我修正），通常比仅仅制定一个更好的计划更有效。这就像一个作家写完一段话后，读出声来，意识到听起来很怪，然后立即重写。
推理缩放 (Inference Scaling)： “尝试多种路径”策略
- 类比： AI 不只生成一个答案，而是生成十个不同版本的代码，运行它们，并挑选出效果最好的那一个。
- 结果： 这就像一名侦探尝试十种不同的理论来破解犯罪案件。论文发现，生成许多选项并从中搜索最佳方案，往往比试图第一次就做对要得到更好的结果。
软件工程智能体 (SWE Agents)： “项目经理”
- 类比： 这是最先进的方法。AI 不仅仅是一个作家，它是一个项目经理。它有计划、写代码、运行测试、修复漏洞，并使用工具（如计算机终端）来检查自己的工作。
- 结果： 这些“智能体”目前是冠军。通过结合规划、自我纠错和工具使用，它们比任何单一方法都能更好地解决最困难的问题（如修复现实世界的软件漏洞）。

3. 什么最有效？（“黄金法则”）

作者在许多不同的测试中比较了这些方法，并发现了明确的赢家：

代码结构胜出： 将代码视为一个建筑（具有循环和函数等特定部分）进行思考，比将其视为一个故事效果更好。
测试胜出： 那些实际运行代码以检查错误的方法（自我修正）比仅仅思考代码更强大。
组合胜出： 最好的系统并不只是使用一种技巧，而是将它们全部结合起来（计划 + 运行 + 修复 + 搜索）。

4. 缺失了什么？（“行动呼吁”）

论文指出，虽然我们在让 AI 编写代码方面取得了进步，但我们仍然缺少一些重要的部分：

测试过多，多样性不足： 大多数研究人员仅在简单的“代码生成”任务（编写一个小函数）上测试这些 AI 工具。我们需要更多的测试来检查 AI 是否能够处理复杂的、现实世界的软件工程工作，例如修复庞大且混乱的代码库中的漏洞。
错误恢复： 我们还没有好的方法来测试 AI 是否能在犯错时恢复。我们需要专门测试 AI 在失败后能否“重新站起来”的基准测试。
超越单元测试： 目前，AI 主要通过简单的“单元测试”（检查一个微小的部分）来检查代码是否有效。论文建议我们需要教 AI 检查其他方面，比如安全性、速度以及不同代码部分之间的协作能力。

总结

简而言之，这篇论文表示：要让 AI 擅长编程，不要只要求它编写，要要求它规划、运行、测试和修复。 当今最成功的 AI “程序员”是那些表现得像工程师团队一样的系统——进行仔细的规划、检查工作并尝试多种解决方案——而不是仅仅作为一个只会吐出第一个念头的机器。作者希望通过这篇综述，能帮助其他研究人员在未来构建出更聪明、更可靠的编程助手。

技术摘要：代码推理在软件工程任务中的应用：综述与行动呼吁

问题陈述

尽管大语言模型（LLMs）在自然语言任务和软件工程（SWE）任务（如代码生成、问题解决）中展现出了显著的能力，但它们在处理复杂的现实世界软件工程问题时表现仍然有限。近期，“大型推理模型”和 SWE 智能体（Agents）的进展通过引入测试时计算（test-time compute）和推理时推理技术，提升了任务结果。然而，关于代码推理的文献是碎片化的，具有术语不一致和评估协议异构化的特征。至关重要的是，目前缺乏系统性的探索来研究特定的推理技术——特别是那些利用代码特定信号（如结构和执行反馈）的技术——如何影响 SWE 任务。现有的综述通常侧重于通用推理或广泛的 SWE 应用，缺乏针对以代码为中心的推理策略的专门分类法，也缺乏对其在常见基准测试中有效性的对比分析。

研究方法

作者通过对 arXiv 和 Google Scholar 进行结构化文献检索，涵盖了 2022 年至 2025 年的出版物（并包含 2021 年起的基准测试记录）。搜索使用了结合了“代码推理”、“推理缩放（inference scaling）”、“反思（reflection）”和“软件工程智能体”等术语的查询语句。

纳入标准： 如果论文使用测试时（推理时）推理或智能体支架（agentic scaffolding）来评估代码/SWE 任务，则予以纳入。纯粹的训练时技术除非利用了模型生成的测试时推理数据（例如 CoT 轨迹），否则予以排除。
分类法构建： 作者根据两个维度将调查的工作组织进一个分类法中（图 3）：技术（激发/增强推理的方法）和任务（用于评估的基准测试）。
比较合成： 为了解决缺乏受控比较的问题，作者对原始论文中报告的结果进行了合成，并在相同的底层 LLM 和基准测试条件下进行对比。这种跨论文分析旨在识别不同推理范式下性能的一致趋势。

核心贡献

本文做出了四个主要贡献：

首个专门综述： 提供了首个专门针对 SWE 任务推理技术的全面综述，区分了宏观策略、混合方法和智能体方法。
分类法与基准测试： 作者提出了推理时技术的分类法（Code CoT、自我修正、推理缩放、SWE 智能体），并整理了一套具有高度 SWE 评估潜力的、尚未被充分探索的基准测试。
对比分析： 本文展示了针对常用模型和基准测试的推理设计模式的对比分析，强调了不同技术相对重要性。
识别差距与未来方向： 综合了当前方法和评估实践中的差距，识别了研究不足的领域，并提出了具体的“行动呼吁”（CTAs）以指导未来研究。

关键发现与结果

对比分析（第 6 节）揭示了不同推理策略在代码生成和问题解决基准测试上的有效性趋势：

代码结构 vs. 规划： 在代码生成基准测试中，结构感知型思维链（CoT）技术（如 SCoT、CGO）往往优于基于规划的 CoT 方法（如 Self-Planning）。模块化 CoT 技术（如 MoT、CodeChain）则进一步优于通用的结构感知方法。
执行反馈： 利用代码执行反馈的自我修正策略（如 Self-Debugging、 $\mu$ Fix）通常优于基于 CoT 的方法。代码执行的确定性允许过滤掉错误的推理链。
推理缩放： 集成推理缩放的方法（通过生成多个候选方案并通过搜索或采样选择最优方案，例如 CodeTree、ORPS）通常优于以 CoT 为主导的策略。
智能体支架： 编排多种推理技术（规划、工具使用、执行、修订）的 SWE 智能体，与单一策略方法（仅 CoT 或自我修正）相比，展现出了更卓越的性能。
混合方法： 最先进的结果是通过在智能体框架内集成推理缩放（如 SWE-Search、CodeTree）实现的，这些方法同时利用了搜索能力和迭代修正。

意义与行动呼吁

本文认为，由于代码具有可执行性和结构化特性，代码推理有别于自然语言推理。作者认为，利用这些属性（语法、执行反馈）的技术对于推进 SWE 自动化至关重要。

文章最后提出了一套**行动呼吁（CTAs）**以指导未来研究：

CTA-1 & 2： 深化研究代码结构（原语、模块化）如何影响 CoT 的有效性，并探索考虑多样化编程范式的 Code CoT 方法。
CTA-3： 探索将推理缩放与基于代码结构的 CoT 方法相结合。
CTA-4 & 5： 研究将执行作为一种确定性检查，以减轻模型的僵化性，并将自我修正从单元测试扩展到包括软件质量指标（效率、安全性、可维护性）和集成测试。
CTA-6 & 7： 为智能体开发结构化错误分析，并创建专门用于评估智能体错误恢复能力的基准测试。
CTA-8： 解决针对 SWE 智能体的工具使用基准测试缺失的问题，特别针对复杂的系统编排挑战和关键决策组件。

作者强调，尽管进展迅速，但该领域需要更真实、更全面的基准测试，以及更深入地理解如何利用编程语言的形式属性来构建更强大、更可靠的 AI 软件工程工具。