介于剧透与猜测之间：避免编码基准里的过度规格化

介于剧透与猜测之间：避免编码基准里的过度规格化

Yuanzhe Liu†、Bastian Lipka、Avraham Shinnar、Jatin Ganhotra、Yao Ma、Martin Hirzel

作者分别来自伦斯勒理工学院与国际商业机器公司。

† 译注：原文脚注为 Work was done while the first author interned at IBM。第一作者在 IBM 实习期间完成这项工作。

1 Rensselaer Polytechnic Institute　2 IBM

{liuy72, may13}@rpi.edu

Lipka.Bastian@ibm.com

{shinnar, jatinganhotra, hirzel}@us.ibm.com

摘要

基准推动人工智能进展，但受任务规格不足和规格过度的拖累。任务规格不足会造成猜测：解答不得不凭空补上缺失部分，更糟的时候会诉诸污染或奖励破解。任务规格过度会造成剧透：解答可以绕过基准本来要测量的一些更难步骤。面向未来的基准应当有难度，规格过度会缩短基准被社区采用的保质期。仓库级编码基准帮助这个领域取得进展，但也因规格过度和规格不足而经历不必要的更替。例如，SWE-bench Pro、FEA-bench、Doc2Feat-bench 和 Multi-SWE-bench 都用从标准答案导出的提示来补任务陈述，以应对规格不足。我们表明，把标准答案信息泄漏进任务陈述，会在其中一些基准里造成规格过度。我们试验了多种规格程度，试图在剧透和猜测之间找到那根针。基于这些结果，我们建议如何导出节制的提示。我们将发布这些提示，使社区能从流行基准得到更可靠的信号。

1 引言

仓库级编码基准通过把智能体提出的补丁放到留出的测试上执行，推动了编码智能体的大幅进展（Jimenez 等人，2024）。若这些评测要测量的是实现能力，任务描述和可用仓库就必须把测试所强制的要求传达出来。做到这种对齐已被证明很难。OpenAI 引入 SWE-bench Verified，以减少规格不足和不公平测试（OpenAI，2024）。它后来在发现 Verified 存在测试缺陷和污染之后，转而推荐 SWE-bench Pro（OpenAI，2026c），随后又在发现 Pro 的提示规格不足、测试过于严格之后撤回该推荐（OpenAI，2026b）。这种更替同时说明这个问题既重要又困难。一种错位来自测试要求某个新的函数、类、文件或属性名，而智能体无法从任务描述或仓库推断出来。这个问题对功能新增类基准尤其突出（Li 等人，2025；Deng 等人，2025a），因为新名字可能在现有仓库里完全不存在。智能体于是可以正确实现所要求的行为，却仅仅因为选了另一个名字而失败。把这些未言明的接口选择找回来，会把猜测引进一次本来要测量软件实现能力的评测。

为减少这种猜测，若干基准用来自参考实现和测试补丁的信息来增补任务描述（Deng 等人，2025a；Li 等人，2025；Deng 等人，2025b；Badertdinov 等人，2026）。我们把这些增补称为提示。图 2 概述了提示如何在仓库级编码基准中生成并使用。智能体收到任务描述 $d_{\mathrm{issue}}$ 以及已有代码和测试 $(c_{\mathrm{old}},t_{\mathrm{old}})$，产出代码 $c_{\mathrm{gen}}$，再对照留出测试 $t_{\mathrm{new}}$ 评分。提示生成器额外访问参考代码 $c_{\mathrm{new}}$ 和留出测试，产出 $d_{\mathrm{hints}}$，作为给智能体的额外输入。提示可以暴露智能体为通过评测所需要的细节，但参考实现也包含基准可能希望智能体独立作出的设计决定。披露这些决定就会引入剧透，也就是供给了部分正在被评测的实现工作的信息。已有工作记录，问题报告和评论泄漏解答，是 SWE-bench 的一个主要问题（Aleithan 等人，2024）。因此，标识符提示的构造面临一种张力：规格不足让智能体去猜隐藏约束，规格过度则泄漏解答的一部分。更高的解决率本身无法区分「消除了猜测」和「供给了剧透」。我们的目标是研究这样的标识符提示构造：说清测试所要求的接口，同时把实现选择留给智能体。

图 1：要提示（或许会剧透）还是不提示（就会猜测）：这是仓库级编码基准的问题。

图 2：DefUse 提示生成流程。

#### 提示的设计空间。

我们通过两个设计决定来考虑提示构造：标识符选择和标识符投影。选择决定披露哪些程序实体，例如文件变更、函数编辑等。标识符投影问的是，对每个被选中的实体揭示多少。例如，若选中一个函数标识符，则它的名字、签名、位置或语义描述都是可以考虑披露的信息。现有提示方案沿这两个维度组合了不同选择（Deng 等人，2025a；Li 等人，2025；Deng 等人，2025b），因此在比较完整方案时，很难把性能差异归因于其中某一个选择。把选择和投影分开，使我们能通过受控比较来检查这些选择。

在这一区分的引导下，本文提出用 DefUse 做标识符选择，用 Declaration 做标识符投影。DefUse 针对实现与其测试发生交互所经由的那些标识符。Declaration 揭示接口属性，同时省略语义描述和实现指导。合在一起，这些策略旨在减少关于所需标识符的猜测，同时限制关于如何实现的剧透。

我们在五个仓库级编码基准上比较选择策略和投影策略，这些基准覆盖 Python 和 Java。我们用提示属性消融，以及在 SWE-bench Pro 上基于大语言模型的评估，来补充这些比较，同时检查任务解决和参考解答信息的披露。我们的发现表明，性能增益可以伴随对实现选择的更多披露，因此评测不能只看解决率。这些发现共同促使把 DefUse 选择与 Declaration 投影结合起来，以减少关于所需接口的猜测，同时限制关于实现选择的剧透。

我们的提示生成流程源代码以及由此得到的提示以开源形式提供：https://github.com/IBM/swe-hints/。

#### 贡献。

本文有三项贡献：

• 它通过选择和投影来刻画标识符提示，为比较现有基准策略提供一个共同框架。
• 它引入 DefUse 和 Declaration，两项旨在暴露面向测试的接口、同时限制额外的参考派生信息的策略。
• 它报告跨五个基准和三个语言模型的受控比较与属性消融，检查提示构造如何影响测得的任务解决。此外，它采用一个大语言模型评判器，评估信息必要性、解答披露和行为指导。

就基准推动人工智能进展而言，我们希望，在编码基准里找到剧透与猜测之间的恰当平衡，最终有助于更可靠的编码助手。

2 相关工作

表 1：每种提示方案究竟披露什么。勾选表示披露，横线表示不披露。DefUse 是我们对 Doc2Feat 的改进。Doc2Feat 指 Doc2Feat 基准所用的标识符提示抽取。FEA-Bench 给出两种提示选择：简略和详细。在 SWE Bench Pro 中，作者把 “Requirements” 定为必要提示，并把 “Interface” 设为可选。

#### 基准有效性。

对 SWE-bench 和 SWE-bench Pro 的审计记录了规格不足的任务，以及强制未言明实现细节的测试（OpenAI，2024；OpenAI，2026b；OpenAI，2026c）。SWE-Bench+ 识别出问题报告或评论中披露的解答，以及不充分的测试（Aleithan 等人，2024）。差分测试和人工分析进一步表明，通过基准测试并不保证补丁正确（Wang 等人，2026）。记忆的证据引起对训练数据污染的担忧（Liang 等人，2026），LiveCodeBench 和 SWE-rebench 试图通过收集新任务来缓解（Jain 等人，2025；Badertdinov 等人，2026）。我们的研究补充这些审计：考察从参考解答导出的提示如何影响评测时智能体可获得的信息。

#### 任务规格与提示。

Khatib 等人（2026）考察缺陷报告内容如何影响修复成功，包括对基准添加的需求和接口做受控消融。Ganhotra（2026）识别出隐藏的命名契约：测试要求参考解答里的标识符，而这些标识符既不在问题中，也不在基础仓库中。基准用从参考解答导出的名字、声明或需求来处理这种含糊（Deng 等人，2025a；Li 等人，2025；Deng 等人，2025b）。在智能体工作流内部，SpecRover 推断代码意图（Ruan 等人，2025），REAgent 精炼需求（Kuang 等人，2026），HULA 把开发者反馈纳入计划和代码（Takerngsaksiri 等人，2025）。交互式方法通过澄清来处理缺失需求：Ambig-SWE 评测智能体发现规格不足并引出缺失信息的能力（Vijayvargiya 等人，2026）。LHAW 系统地去掉任务信息，并通过智能体试验测量其影响（Pu 等人，2026）。我们的研究把标识符选择与标识符投影分开，以考察哪些基准披露减少了关于所需接口的猜测，哪些供给了关于实现选择的剧透。

3 方法

我们通过两个决定来刻画标识符提示：标识符选择，决定披露哪些程序实体；标识符投影，决定对每个被选实体揭示哪些属性。表 1 沿这些维度整理现有提示方案，并把我们提出的选择策略 DefUse 放进这个设计空间。这种分解支持对选择策略（在固定投影下）和投影策略（在固定选择下）做受控比较。

3.1 标识符选择：DefUse

当前仓库级编码基准里存在多种标识符选择流程。SWE-Bench Pro 的作者雇用人类工程师来构造需求和接口，而 FEA-Bench 纳入提交之间新文件中出现的全部新组件（Deng 等人，2025b；Li 等人，2025）。Doc2Feat 流程先抽取在新代码补丁和新测试补丁之后出现的标识符，再从代码补丁与测试补丁所抽实体的交集中选择标识符（Deng 等人，2025a）。尽管在现有流程中 Doc2Feat 的标识符选择最严，但「两边变更里都出现」并不能区分一个标识符是在何处定义、又在何处被使用，因而会纳入字段访问和一般导入这类无关信息。

因此我们提出 DefUse：被选中的标识符是被定义并且被使用的那些。图 2 用图示说明 DefUse。它首先使用新旧之间的差异（即补丁）来找出新引入的名字：$c_{\textrm{new}}-c_{\textrm{old}}$ 以及 $t_{\textrm{new}}-t_{\textrm{old}}$。然后，DefUse 只保留那些在代码与测试之间承载一次通信的名字，方向有两种：

1. $\textrm{def}(c_{\textrm{new}}-c_{\textrm{old}})\cap\textrm{use}(t_{\textrm{new}}-t_{\textrm{old}})$：代码定义该名字，测试使用它；$\cup$
2. $\textrm{def}(t_{\textrm{new}}-t_{\textrm{old}})\cap\textrm{use}(c_{\textrm{new}}-c_{\textrm{old}})$：测试定义该名字，代码使用它。

译注：原文句首作 If first uses，按上下文理解为 It first uses。

这些就是解答与其测试借以通信的名字。留出测试已经承诺使用它们，智能体无法仅从问题中把它们恢复出来。

#### 为什么必须既被定义又被使用？

这一准则来自留出测试实际能观察到什么。测试拒绝一个功能正确的补丁，只能通过它在该补丁中引用的标识符：它导入并调用的函数、它实例化的类、它检查的属性和返回结构。由此得到 DefUse 的一个必要性论证和一个充分性论证。

#### 必要性。

若测试补丁读取一个由代码补丁定义的标识符（情形 1），则该标识符的名字是参考作者未经强制的设计选择，测试却把它当作硬约束。每一个这样的标识符都是潜在的虚假失败：智能体可以完美实现所要求的行为，仍会在与一个任意标签的精确匹配比较上失败。因此这些标识符必须被披露，否则基准给猜测打分，而不是给能力打分。对称方向（情形 2）在同样的意义上是一份契约：测试构造了代码必须消费的输入，代码一侧的名字同样不可恢复，同样承受载荷。

#### 充分性。

反过来，一个并非在一个补丁中定义、又在另一个补丁中被使用的标识符，从不跨越代码与测试的边界。智能体可以自由地命名它、放置它或去掉它，而不影响任何测试结果。披露它并不能修补含糊，却可能泄漏参考作者的内部设计决定，而这正是我们要避免的剧透。因此 DefUse 是去掉名字不匹配伪影的最小选择。每一个被选中的标识符，若被藏起来，都可能造成一次假失败；每一个被丢弃的标识符都不能。

标识符提示的目标是处理当前编码任务中的含糊。我们希望给智能体尽可能少的提示，以避免不必要的信息泄漏，因为暴露过多信息会使题目失去评测编码智能体真实能力的功能。DefUse 遵循这一原则：它披露完整的接口契约，除此之外什么也不披露。

3.2 标识符投影：Declaration

Declaration 对每个被选标识符只揭示其声明行所陈述的内容，而不更多：它的名字；它的种类（函数、类、变量或文件）；声明它所在文件的路径；该文件是否为新添加；以及对可调用对象，它的签名。原则是，一条提示应当复现同事能从头部或存根上读到的东西，即身份、种类、位置和调用方式，并在实现开始的地方停下来。例如，对 SWE-bench Pro 里为 Ansible 增加区域设置检测的那项任务，新函数的 Declaration 条目写成

### ‘get_best_parsable_locale‘ (function)
    -- ‘lib/ansible/module_utils/common/locale.py‘ [new file]
Signature: ‘get_best_parsable_locale(module, preferences=None)‘

它固定了隐藏测试所导入的名字、它必须位于何处、以及它如何被调用，并把其余一切留给智能体。

Declaration 有意省略更丰富的方案附加到每个实体上的语义属性：一行关于该实体做什么的摘要，以及一段描述如何做的文字。对同一个函数，完整提示会继续写出要运行的 shell 命令（locale -a）、要优先的区域设置（C.utf8、en_US.utf8），以及要抛出的异常；这项任务的完整提示长度达到 Declaration 提示的十三倍。这些描述由一个看过参考补丁的语言模型产生，因此按构造就是从解答导出的；尚未回答的问题是，有多少解答留进了文本。我们在第 4.6 节用一个语言模型评判器来回答：结构属性不携带解答内容，而语义属性描述行为和机制。第 4.5 节的消融表明，结构属性在零披露下带来解决率增益，而来自语义属性的进一步增益是用被披露的解答内容换来的。因此 Declaration 是我们能够论证为「去掉猜测而不供给剧透」的最大投影。

4 实验

我们的实验考察提示构造如何影响任务解决，以及它揭示了参考解答的哪些信息。我们先通过只改变其中一个、固定另一个，来分离标识符选择和投影的效应（RQ1 与 RQ2）。然后，我们通过消融和基于大语言模型的评估，考察这些策略背后的属性（RQ3 与 RQ4）。这些实验合在一起，评估把 DefUse 选择与 Declaration 投影结合起来的理由。我们还在 Java 上重复选择比较和投影比较，以验证在 Python 上观察到的模式是否延伸到第二种语言。

• RQ1（选择，第 4.3 节）：提示应当对哪些标识符暴露信息？
• RQ2（投影，第 4.4 节）：对每个标识符，提示应当暴露什么信息？
• RQ3（消融，第 4.5 节）：提示的哪些属性承载它对任务解决的效应？
• RQ4（评判，第 4.6 节）：提示的哪些属性揭示参考解答？

4.1 实现细节

我们的流程对每个实例抽取参考补丁和测试补丁所引入或触及的标识符及其属性，并按一条选择规则和一种投影渲染出提示。为验证抽取，我们重新实现了 Doc2Feat-bench（Deng 等人，2025a）和 FEA-Bench（Li 等人，2025）已发表的提示流程，并复现了它们发布的提示，附带少量缺陷修复。我们也实现了自己版本的 SWE-Bench Pro 提示流程：先抽取期望的接口，再用 Claude Haiku 4.5（Anthropic，2025）生成需求和接口描述。细节见附录 A。

4.2 实验设置

#### 基准、评测子集与选择统计。

我们使用四个 Python 基准：Doc2Feat-bench（Deng 等人，2025a）、FEA-Bench（Li 等人，2025）、SWE-bench Pro（表中记为 Pro）（Deng 等人，2025b）和 SWE-rebench（Badertdinov 等人，2026）。我们另外评测来自 Multi-SWE-bench 的 Java 任务（记为 MSB Java）（Zan 等人，2026）。对选择比较（RQ1），我们保留 Doc2Feat 与 FEA-Bench Brief 两种选择策略都能产出非空标识符集合的实例。所有选择策略都在这个共享子集上评测，分别包含来自四个 Python 基准的 $31$、$40$、$131$ 和 $26$ 个实例，以及 $40$ 个 Java 实例。对投影比较（RQ2），我们保留 DefUse 产出非空标识符集合的实例。这些子集分别包含来自四个 Python 基准的 $21$、$44$、$68$ 和 $14$ 个实例，以及 $29$ 个 Java 实例。属性消融（RQ3）和基于大语言模型的评估（RQ4）集中在同一个 68 个实例的 SWE-bench Pro 子集上。表 2 汇总每种选择策略所披露的标识符数量。在全部五个基准上，DefUse 每个实例披露的标识符最少，而 Pro 最多。表中合计是全部实例的标识符总数，均值是平均到每个实例。

表 2：每种选择方法所披露的标识符数量，在与选择表相同的实例上、于 Declaration 投影下计数。Total 是全部实例上的标识符数，Mean 是每个实例的数量。DefUse 在测试不引用任何新标识符的实例上为空：它在 20/31、44/142、66/131、9/26 和 29/40 个实例上非空，非空实例上分别有 3.2、1.8、2.4、2.0 和 6.7 个标识符。其他选择在每个实例上都非空。

#### 模型与智能体。

我们让三个语言模型走同一套支架：DeepSeek V4 Flash（0431）、MiniMax M2.5 和 GPT 5.6 Luna（Xu 等人，2026；MiniMax，2026；OpenAI，2026a）。所有模型使用温度 $1.0$，DeepSeek 和 MiniMax 使用最大推理力度，GPT 5.6 Luna 使用高推理力度。我们使用 mini-SWE-agent（Yang 等人，2024），它每回合发出一条 shell 命令，每条轨迹最多 250 步。由于预算限制，每种配置对每个实例只跑一条轨迹。

#### 提示属性。

我们解析每个补丁以抽取结构属性，即名字、种类、路径、是否新文件以及签名。两个语义属性对应 SWE-bench Pro 的人工撰写字段：弱语义对应其接口下的描述，强语义对应其需求。两者都由 Claude Haiku 4.5（Anthropic，2025）在给定参考补丁的条件下生成，并且都只出现在 Pro 投影中。

#### 评测与指标。

我们用各基准的官方评测器在 Docker 容器中评测。一个实例只有在它的全部 fail-to-pass 和 pass-to-pass 测试都通过时才算解决，我们报告解决率，即已解决实例的百分比。

4.3 标识符提示的选择

RQ1 考察提示应当披露哪些标识符。我们在两种固定投影下比较四种选择策略：Declaration（表 3），暴露结构接口属性；以及 Name Only（附录 B，表 9），只暴露标识符名字。因为 DefUse 把选择限制在实现与测试借以通信的标识符上（第 3.1 节），这些比较检验披露更多标识符是否提高任务解决。

各选择策略在披露多少标识符上差别很大（表 2）。在 SWE-bench Pro 上，DefUse 平均每个实例揭示 1.2 个标识符，Doc2Feat 为 4.8，FEA 为 7.7，Pro 为 17.2。对 GPT 5.6 Luna，披露上的这一巨大差别只对应解决上相对较小的差别：DefUse 解决 131 个实例中的 91 个（69.5%），更宽的选择为 92–95 个（70.2–72.5%）。因此，对这个模型和这个基准，更窄的选择大幅减少披露，而观察到的解决只小幅下降。

更窄披露的性能代价，对 SWE-bench Pro 上的开源模型更大。DeepSeek 用 DefUse 解决 17 个实例，更宽的选择策略为 26–29 个；MiniMax 解决 20 个，相比为 21–29 个。这些增益分别达到多 12 个和多 9 个实例，而 GPT 5.6 Luna 至多只多 4 个。然而，额外标识符的好处因基准而异。在 FEA-Bench 上，DeepSeek 用 DefUse 解决 16 个实例，更宽的策略为 13–14 个；MiniMax 解决 14 个，相比为 13–15 个。在 Multi-SWE-bench Java 上，DeepSeek 在 Declaration 下用 DefUse 解决 40 个实例中的 13 个，其他策略为 12–15 个（表 5）。

译注：原文作 40u instances，与表中 40 个实例一致，u 为排版残留。

Doc2Feat-bench 对两个开源模型仍然很难：DeepSeek 在每种策略下解决 0–2 个实例，MiniMax 每种策略下解决 1 个。这些结果合在一起表明，更宽披露的好处同时取决于模型和基准。

因此，更宽的选择可以提高测得的解决，但它对智能体有用，并不能确立这些额外标识符对规定测试所要求的接口是必要的。我们提出 DefUse 的动机，是暴露那些面向测试的标识符，同时限制对参考实现特有选择的披露。表中已解决列是通过全部测试的实例数，准确率是该数除以列标题里的实例数。这一比较把投影固定为 Declaration，因此行与行的差别来自选择了哪些标识符，而不是来自对每个标识符多说了什么。空选择一行不给任何标识符。更宽的选择披露更多名字，但这些名字不一定是测试一定会检查的接口。

表 3：模型在各基准和各选择方法上的表现。我们把 Declaration 投影固定为给定不同标识符时的投影。

表 4：DeepSeek V4 Flash 在 Declaration 投影下，于 Multi-SWE-bench Java 上跨选择策略的表现。

表 5：在 DefUse 选择下，DeepSeek V4 Flash 于 SWE-bench Pro（68 个实例）上的提示属性消融。

4.4 标识符提示的投影

RQ2 考察关于每个被选标识符，提示应当披露什么信息。我们把选择固定为 DefUse，并把五种投影与空基线比较（表 6）。这一比较考察结构接口属性和额外的语义描述如何影响任务解决。

结果表明，结构接口信息可以帮助智能体解决任务。在 SWE-bench Pro 上，Declaration 相对空基线把解决率从 DeepSeek 的 10.3% 提高到 29.4%，从 MiniMax 的 2.9% 提高到 14.7%，从 GPT 5.6 Luna 的 55.9% 提高到 73.5%。它在这个基准上对三个模型也都优于 Name Only，说明名字之外的属性贡献了有用的接口信息。这些改进发生时并没有 Pro 投影所包含的语义描述。Java 结果提供支持证据：Declaration 把 DeepSeek 的已解决实例从 29 个中的 5 个提高到 10 个（表 7）。

加入语义描述的效应因模型而异。在 SWE-bench Pro 上，MiniMax 用 Pro 解决 16 个实例，Declaration 下为 10 个。DeepSeek 用 Pro 解决 19 个，用 Declaration 解决 20 个；GPT 5.6 Luna 分别为 39 个和 50 个。因此，额外的、从参考解答导出的描述可以提高解决，但其好处在模型之间并不一致。单凭这些比较并不能确立这些描述是靠澄清需求来帮忙，还是靠供给实现指导来帮忙。鉴于每个实例只有一条轨迹，且部分评测子集规模有限，我们也谨慎解释小的差异。

这些观察合在一起，支持把 Declaration 作为标识符提示的一种合理投影：它提供可以改善任务解决的接口信息，同时省略从参考解答导出的语义描述。属性消融和基于大语言模型的评估（第 4.5 节和第 4.6 节）进一步考察各个属性的贡献，以及它们所披露的解答信息。表中各行在同一批 DefUse 标识符上比较投影，空行不提供任何提示，作为对照。已解决数与准确率的算法与选择表相同，列标题中的数字是该子集的实例数。语义描述只出现在部分投影里，结构属性则从名字一直加到签名和路径。

表 6：模型在各基准和各投影方法上的表现。我们把 DefUse 选择固定为给定不同投影时的选择。Declaration+Doc 在 Declaration 之上为每个标识符加一句描述。

表 7：模型在各投影方法下于 Multi-SWE-bench Java 上的表现。我们把 DefUse 选择固定为给定不同投影时的选择。Declaration+Doc 在 Declaration 之上为每个标识符加一句描述。模型：DeepSeek V4 Flash。

4.5 提示属性消融

RQ3 考察不同提示属性如何贡献于任务解决。我们把选择固定为 DefUse，并在 SWE-bench Pro 子集上评测 DeepSeek V4 Flash（表 5）。直到 Declaration 的各行依次加入结构属性。Name Only and Semantics 把名字与两种语义描述组合起来，而 All Hints 把 Declaration 与两种描述都组合起来。

名字相对空基线提高了解决，Declaration 提供进一步增益。只在名字上加入实体类型，没有观察到改进，说明结构属性的贡献并不相同。语义描述在这些运行中产生更大增益：把它们与 Declaration 组合，把解决率从 29.4% 提高到 72.1%。这一组合也优于「名字加语义描述」，说明结构信息与语义信息可以提供互补的好处。

这些结果把提示属性的有用性与它们是否适合用于评测区分开来。接口属性可以帮助智能体满足面向测试的契约，而语义描述也可能供给实现指导。第 4.6 节考察这一区分。每种配置对每个实例只用一条轨迹，运行之间记录到的变异限制了把观察到的差异只归因于提示内容。语义配置所用的渲染也与 RQ2 中的 Pro 不同，因此它们的绝对比率不应与表 6 直接比较。

4.6 提示泄漏评判

RQ4 考察提示属性披露什么信息，作为对任务解决实验的补充。遵循先前关于基于大语言模型的评测的工作（Zheng 等人，2023；Liu 等人，2023），我们使用推理力度为 medium 的 GPT 5.6 Luna，在 SWE-bench Pro 上评估属性。量规给必要性 $N$（没有参考解答时的不可恢复性）、披露 $D$（解答内容）和指导 $G$（对智能体动作的引导）打分。我们用启发式的提示价值边际 $\mathrm{HVM}=N-\max(D,G)$ 汇总这些有序分数。量规和评估程序见附录 C。

表 8 显示，结构属性与语义属性的平均必要性分数相近，但语义描述的披露和指导更高。名字和签名得到最高的边际，而语义属性的边际接近零。强语义的披露和指导分数高于弱语义，这与「描述传达实现机制」一致。

与投影比较和属性消融（第 4.4 节和第 4.5 节）合在一起，这一评估支持把 Declaration 作为标识符提示的一种合理投影。实验表明，结构接口属性可以在没有语义描述的情况下改善任务解决，而评判器把那些描述与更大的解答披露和实现指导联系在一起。因此 Declaration 为提示构造提供一条有原则的边界。它澄清面向测试的接口，同时限制可能供给部分被评测实现的、额外的参考派生信息。

表 8：在 DefUse 选择下，SWE-bench Pro 上的提示属性分数。$N$：必要性；$D$：披露；$G$：指导；$\mathrm{HVM}=N-\max(D,G)$。∗ 标记与零不可区分的边际。$\mathrm{HVM}$：提示价值边际。评判细节见附录 C。

5 结论与局限

我们通过选择和投影来研究标识符提示，表明提示策略既影响测得的任务解决，也影响智能体可获得的、从参考解答导出的信息。我们的发现促使把 DefUse 选择与 Declaration 投影结合起来，以澄清面向测试的接口，同时限制实现指导。更广泛地说，基准设计者评估提示时，既要看它们带来的性能增益，也要看它们披露了什么。

#### 局限。

预算限制使每种所报告的配置对每个实例只有一条轨迹，因而小的差异对随机变异敏感。所记录的实验大约相当于 2300 美元的推理价值，其中包括按公开 API 价格计价、但未计费的 MiniMax 用量。较小的基准子集和单一智能体支架限制了可推广性，而服务变异和依赖量规的大语言模型判断引入额外的不确定性。

参考文献

Aleithan 等人（2024）R. Aleithan、H. Xue、M. M. Mohajer、E. Nnorom、G. Uddin 与 S. Wang。SWE-Bench+：面向大语言模型的增强编码基准。arXiv 预印本 arXiv:2410.06992。 人名与文献编号保留原文。

Anthropic（2025）Anthropic。介绍 Claude Haiku 4.5。外部链接：Link。 人名与文献编号保留原文。

Badertdinov 等人（2026）I. Badertdinov、A. Golubev、M. Nekrashevich、A. Shevtsov、S. Karasik、A. Andriushchenko、M. Trofimova、D. Litvintseva 与 B. Yangel。SWE-rebench：用于任务收集和对软件工程智能体去污染评测的自动流程。Advances in Neural Information Processing Systems 38。 人名与文献编号保留原文。

Deng 等人（2025a）L. Deng、Z. Jiang、J. Cao、M. Pradel 与 Z. Liu。Nocode-bench：评测自然语言驱动的功能新增的基准。arXiv 预印本 arXiv:2507.18130。 人名与文献编号保留原文。

Deng 等人（2025b）X. Deng、J. Da、E. Pan、Y. Y. He、C. Ide、K. Garg、N. Lauffer、A. Park、N. Pasari、C. Rane 等人。SWE-bench Pro：人工智能智能体能解决长程软件工程任务吗？arXiv 预印本 arXiv:2509.16941。 人名与文献编号保留原文。

Ganhotra（2026）J. Ganhotra。SWE-agent 基准中的隐藏命名契约。外部链接：Link。 人名与文献编号保留原文。

Jain 等人（2025）N. Jain、A. Gu、W. Li、F. Yan、T. Zhang、S. Wang、A. Solar-Lezama、K. Sen 与 I. Stoica。LiveCodeBench：对大语言模型代码能力的整体且无污染评测。载于 International Conference on Learning Representations，第 2025 卷，第 58791–58831 页。 人名与文献编号保留原文。

Jimenez 等人（2024）C. E. Jimenez、J. Yang、A. Wettig、S. Yao、K. Pei、O. Press 与 K. Narasimhan。SWE-bench：语言模型能解决真实的 Github 问题吗？载于 International Conference on Learning Representations，第 2024 卷，第 54107–54157 页。 人名与文献编号保留原文。

Khatib 等人（2026）L. Khatib、N. S. Mathews、M. Nagappan、P. Nie 与 T. Zimmermann。对人工智能智能体来说，什么样的缺陷报告才算好？arXiv 预印本 arXiv:2607.07593。 人名与文献编号保留原文。

Kuang 等人（2026）S. Kuang、Z. Tian、K. Lin、C. Tao、S. Wang、H. Bai、L. Shang 与 J. Chen。REAgent：面向软件问题求解的需求驱动大语言模型智能体。arXiv 预印本 arXiv:2604.06861。 人名与文献编号保留原文。

Li 等人（2025）W. Li、X. Zhang、Z. Guo、S. Mao、W. Luo、G. Peng、Y. Huang、H. Wang 与 S. Li。FEA-Bench：评测面向功能实现的仓库级代码生成的基准。载于 Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics（第 1 卷：长文），第 17160–17176 页。 人名与文献编号保留原文。

Liang 等人（2026）S. Liang、S. Garg 与 R. Z. Moghaddam。SWE-bench 幻觉：当最先进的大语言模型是在记忆而不是在推理。载于 Proceedings of the IEEE/ACM 48th International Conference on Software Engineering: Software Engineering in Practice，第 395–405 页。 人名与文献编号保留原文。

Liu 等人（2023）Y. Liu、D. Iter、Y. Xu、S. Wang、R. Xu 与 C. Zhu。G-Eval：用与人类更对齐的 GPT-4 做自然语言生成评测。载于 Proceedings of the 2023 conference on empirical methods in natural language processing，第 2511–2522 页。 人名与文献编号保留原文。

MiniMax（2026）MiniMax。MiniMax M2.5：为真实世界的生产率而造。外部链接：Link。 人名与文献编号保留原文。

OpenAI（2024）OpenAI。介绍 SWE-bench Verified。外部链接：Link。 人名与文献编号保留原文。

OpenAI（2026a）OpenAI。GPT-5.6 Luna：随你的雄心扩展的前沿智能。外部链接：Link。 人名与文献编号保留原文。

OpenAI（2026b）OpenAI。把编码评测里的信号和噪声分开。外部链接：Link。 人名与文献编号保留原文。

OpenAI（2026c）OpenAI。为什么 SWE-bench Verified 不再度量前沿编码能力。外部链接：Link。 人名与文献编号保留原文。

Pu 等人（2026）G. Pu、M. S. Lee、U. M. Sehwag、D. J. Lee、B. Zhu、Y. Maurya、M. Raghavendra、Y. Xue 与 S. M. Denton。LHAW：面向长程任务的可控规格不足。arXiv 预印本 arXiv:2602.10525。 人名与文献编号保留原文。

Ruan 等人（2025）H. Ruan、Y. Zhang 与 A. Roychoudhury。SpecRover：经由大语言模型抽取代码意图。载于 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE)，第 963–974 页。 人名与文献编号保留原文。

Takerngsaksiri 等人（2025）W. Takerngsaksiri、J. Pasuksmit、P. Thongtanunam、C. Tantithamthavorn、R. Zhang、F. Jiang、J. Li、E. Cook、K. Chen 与 M. Wu。人在回路中的软件开发智能体。载于 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)，第 342–352 页。 人名与文献编号保留原文。

Vijayvargiya 等人（2026）S. Vijayvargiya、X. Zhou、A. Yerukola、M. Sap 与 G. Neubig。Ambig-SWE：用交互式智能体克服软件工程中的规格不足。载于 International Conference on Learning Representations，第 2026 卷，第 146716–146737 页。 人名与文献编号保留原文。

Wang 等人（2026）Y. Wang、M. Pradel 与 Z. Liu。SWE-bench 里的「已解决的问题」真的被正确解决了吗？一项实证研究。载于 Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering，第 169–181 页。 人名与文献编号保留原文。

Xu 等人（2026）A. Xu、B. Lin、B. Xue、B. Wang、B. Xu、B. Wu、B. Zhang、C. Lin、C. Dong、C. Ling 等人。Deepseek-v4：通向高效的百万词元上下文智能。arXiv 预印本 arXiv:2606.19348。 人名与文献编号保留原文。

Yang 等人（2024）J. Yang、C. Jimenez、A. Wettig、K. Lieret、S. Yao、K. Narasimhan 与 O. Press。Swe-agent：智能体—计算机接口使自动化软件工程成为可能。Advances in Neural Information Processing Systems 37，第 50528–50652 页。 人名与文献编号保留原文。

Zan 等人（2026）D. Zan、Z. Huang、W. Liu、H. Chen、S. Xin、L. Zhang、Q. Liu、L. Aoyan、L. Chen、X. Zhong 等人。Multi-SWE-bench：面向问题求解的多语言基准。Advances in Neural Information Processing Systems 38。 人名与文献编号保留原文。

Zhang 等人（2025）Y. Zhang、M. Li、D. Long、X. Zhang、H. Lin、B. Yang、P. Xie、A. Yang、D. Liu、J. Lin、F. Huang 与 J. Zhou。Qwen3 embedding：通过基础模型推进文本嵌入与重排序。arXiv 预印本 arXiv:2506.05176。 人名与文献编号保留原文。

Zheng 等人（2023）L. Zheng、W. Chiang、Y. Sheng、S. Zhuang、Z. Wu、Y. Zhuang、Z. Lin、Z. Li、D. Li、E. Xing 等人。用 MT-Bench 和 Chatbot Arena 评判「以大语言模型为评判器」。Advances in neural information processing systems 36，第 46595–46623 页。 人名与文献编号保留原文。页码亦保留。

附录 A 实现细节：基线

A.1 选择

对 Doc2Feat 和 FEA Bench Brief 的提示生成，我们改写了原始代码，使流程能在多种基准上抽取提示。对 SWE Bench Pro 的提示生成，由于他们雇用人类工程师来构造提示，不可能完全复现 Pro 的流程。因此我们用一个大语言模型来近似人类工程师在提供详细提示文本上的作用。我们先找出旧代码与新代码补丁之间不同的标识符，抽取关于标识符的信息，再用 Claude Haiku 4.5 以少样本提示生成接口描述和需求。把生成的接口描述和需求与 SWE Bench Pro 的 Python 子集（266 个实例）中的原文比较，生成结果的余弦相似度分别为 $0.8978$ 和 $0.8405$，嵌入模型为 Qwen3-0.6-Embedding（Zhang 等人，2025）。

译注：原文作 new cold patches 与 consine similarity，分别按 new code patches 与 cosine similarity 译出。

A.2 投影

为实现可控投影，我们先有一条完整流程，从代码补丁和测试补丁两边抽取所有可能的标识符。对每个标识符，我们通过检查其抽象语法树来抽取相关信息，得到的不只是标识符名字。然后，我们通过代码补丁与测试补丁之间的通信来选择 DefUse，并采用 Claude Haiku 4.5 来丰富语义：弱语义对应 SWE Bench Pro 的接口描述，强语义对应需求。然后：

• Doc2Feat：每个标识符的名字和实体类型，渲染成扁平列表；没有路径、签名或描述。
• Declaration：名字、实体类型、文件路径、新文件标志和签名；类成员嵌套在其类之下。没有自然语言文本。
• Declaration+Doc：Declaration 加上弱语义，即至多 20 个词的一句话，描述该实体是什么、做什么。它对应 FEA-Bench 详细提示所加的 docstring，但不含它们的代码；FEA-Bench 的简略提示不带描述，并与 Declaration 重合。
• Pro：Declaration+Doc 加上强语义，即两到四句关于行为、边界情况和测试所隐含约束的段落。两种描述都由 Claude Haiku 4.5 根据参考补丁写成，因此这个大语言模型充当 SWE-bench Pro 的人类标注者所担任的抽取者。

附录 B 仅名字投影下的标识符选择

我们把投影固定为 Name Only，重复标识符选择比较。每条提示只揭示被选标识符的名字，使我们能在不披露额外属性的情况下考察选择策略。表 9 和表 10 分别报告 Python 和 Java 的结果。

即使提示只含名字，选择的效应仍因模型和基准而异。在 SWE-bench Pro 上，Pro 和 FEA 对三个模型都优于 DefUse，而在 FEA-Bench 上，DefUse 在提示选择中领先于 DeepSeek。Java 结果提供又一个例子：DefUse 和 Pro 各解决 40 个实例中的 9 个，Doc2Feat 和 FEA 为 6 个。因此，更宽的选择可以有帮助，但披露更多名字并不一致地提高解决。与 Declaration 比较一样，鉴于评测子集有限且每个实例只有一条轨迹，小的差异应当谨慎解释。表 9 与表 10 的已解决列和准确率列含义与前文相同：只换选择策略，投影固定为只给出名字。更宽的名字集合有时提高解决，有时并不提高，因此不能把更高的解决率直接当成接口被说清楚了。只披露名字时，选择策略仍然会改变智能体看见的标识符集合，但不再告诉它签名、路径或种类。因此附录里的高低分不能单独用来决定该选哪一种标识符集合。

表 9：模型在各基准和各选择方法上的表现。我们把 NameOnly Bench 投影固定为给定不同标识符时的投影。

表 10：在 Name Only 投影下，DeepSeek V4 Flash 于 Multi-SWE-bench Java 上跨选择策略的表现。

附录 C 提示泄漏评判的细节

#### 量规。

每个属性在三个有序量表上评估。必要性 $N$ 度量其取值在没有参考解答时有多可恢复：0 表示写在问题里，1 表示能在仓库里找到，2 表示受惯例约束，3 表示由参考作者自由选定。披露 $D$ 度量解答内容：0 为身份与寻址，1 为可观察契约，2 为实现机制，3 为逐字转写。指导 $G$ 度量对智能体动作的引导：0 为陈述性信息，1 为定向，2 为程序性指导，3 为处方式指令。披露与指导是不同的：一条文件路径可以给智能体定向，而不描述一种实现。启发式边际 $\mathrm{HVM}=N-\max(D,G)$ 把这些判断合在一起；它不是对信息量的校准度量。

#### 评估程序。

我们评估 787 个标识符—属性对，来自 DefUse 在 68 个 SWE-bench Pro 实例上选出的 160 个标识符。必要性使用问题来评估，不展示参考补丁或测试补丁；披露和指导在两份补丁都可用时评估。每次调用展示一个标识符的全部属性，并指定一个目标属性，因此必要性判断以其他可见属性为条件。评判器是推理力度为 medium 的 GPT 5.6 Luna。它返回一个类别标签、一段证据和一句理由。我们把标签映射为整数，并取温度 1 下三次抽样的中位数。我们用按实例聚类的自助法估计不确定性，并用三次抽样的全体一致来度量一致性。

#### 验证与局限。

我们用基线提交上的 git grep，对一部分标识符名字检查仓库成员资格。在提供这一证据时，评判器对所检查的全部 31 个标识符都复现了仓库成员资格的区分，而不提供时为 18 个。这一检查只验证必要性评估的一个有限方面；它并不验证完整量规。一致率也因属性而异：三次抽样的全体一致对签名为 94%，对语义描述为 41–42%。这些差异表明，对语义内容的判断不确定性更大，应当与汇总分数一并考虑。

#### 量规与提示。

下面三块逐字复现评判器实现中的量规，以及表 8 每一列背后的提示骨架。必要性是对每个（实例，标识符，属性）三元组的一次调用，它看到问题但看不到任何补丁；披露和指导在第二次调用中一起评定，该调用还看到参考补丁和测试补丁。尖括号字段按每次调用填充。评判器只返回类别标签；表中的整数在代码里赋值（REDUNDANT 对应 0，……，LOAD-BEARING 对应 3，另外两个量表同样处理）。三次调用共享第一块顶部所示的系统提示。

[system]
你是一名严格的研究助手，正在为软件工程基准评估提示质量。你按字面、一致地应用量规。你不因为取值详细或有用而给它加分；你只按所述准则对它们分类。你始终只回答一个 JSON 对象，除此之外什么都不要。

[user]
评定 NECESSITY：一名合格的工程师能否在不看参考解答的情况下得到这个属性的取值？

  0 REDUNDANT      - 该取值就写在问题陈述本身里。
  1 SEARCH-SAVING  - 没有写出，但一名持有当前提交处仓库的工程师会通过正常调查到达它（该实体已经存在；grep 或阅读能找到它）。提示节省的是力气，不是信息。
  2 DISAMBIGUATING - 没有写出，也尚未存在，但被仓库惯例强烈约束（例如新测试文件的位置遵循明显的既有布局）。工程师很可能会猜到它。
  3 LOAD-BEARING   - 编码了解答作者作出的、无法从问题陈述或现有代码库恢复的自由选择（例如一个尚不存在的函数的名字）。没有这条提示，工程师会选别的东西。

只评判目标属性的取值。不要管这个取值看起来重不重要；必要性关乎的是可恢复性，不是重要性。

## 测得的仓库事实            （仅当目标是 `name` 时出现）
标识符 `<name>` 在智能体出发的那个提交处，出现在本仓库的 <k> 个文件中。
<k > 0：「因此工程师可以通过搜索现有代码找到它。」
 k = 0：「它在目录树里尚不存在于任何地方，所以无法靠搜索找到；任何工程师都不得不自己选一个名字。」>

## 仓库
<owner/repo>

## 问题陈述（这是告诉智能体的全部内容）
<问题文本，前 6000 个字符>

## 供上下文使用的标识符
  name: <...>
  entity_type: <...>
  path: <...>                 <<< TARGET      （有一个属性被标出）
  is_new_file: <...>
  signature: <...>
  weak_semantics: <...>
  strong_semantics: <...>

## 你正在评定的取值
attribute : `<目标属性>`
value     : ```
<仅目标属性的取值>

你评定的是上面这段文本，不是它所指的实体，也不是为上下文列出的其他属性。问的是：这段文本本身告诉读者什么。

你的任务

评定 NECESSITY。

严格按下面这个 JSON 对象回答： {"label": "<REDUNDANT|SEARCH-SAVING|DISAMBIGUATING|LOAD-BEARING>", "evidence": "<从问题陈述中逐字引用的、能证明你的评分的短句，若陈述没有相关内容则为空字符串>", "rationale": "<一句话>", "confidence": <0.0-1.0>}

请只输出这一个对象，不要附加解释。 标签必须取自给定集合。

评定 DISCLOSURE：这个取值携带了多少参考解答的内容？

0 INTERFACE - 只有身份和寻址：它叫什么、住在哪里、如何被调用。这是基准本身向智能体公布的那一行，因此不算泄漏。 1 CONTRACT - 可观察行为：它做什么，它的输入和输出意味着什么。一份可以用许多方式实现的规格。 2 MECHANISM - 它如何做到：控制流、算法、操作顺序，或它在内部调用的具体辅助函数或 API 的名字。 3 TRANSCRIPTION - 对解答的复述已经近到，代码几乎可以不经独立思考就从文本转写出来。

2 的例子：「overrides add_job to check the hostname against allowed hosts using fnmatch patterns」——点出了方法和匹配库。 1 的例子：「A set of exact key names that should not be sanitized even if they contain sensitive substrings」——陈述契约，而不给出机制。

评定 BEHAVIOURAL GUIDANCE：这个取值在多大程度上指挥智能体的动作，而不是仅仅陈述一个它必须据以行动的事实？

0 DECLARATIVE - 陈述某物存在，或它叫什么。不隐含动作。 1 ORIENTING - 缩小该看哪里或该碰什么，但不说该做什么。 2 PROCEDURAL - 隐含一串步骤或一种要采取的具体做法。 3 PRESCRIPTIVE - 读起来像智能体可以直接遵循的指令；这段文本可以代替一份计划。

这与披露相互独立。一个行号范围披露很多（改动恰好落在哪里），但什么也不指导（它不说要做什么）。一段算法描述则两者都做。请分开打分。

[D/G 调用的用户消息：先是 DISCLOSURE 量规，然后是 GUIDANCE 量规，然后是下面的内容]

问题陈述

<问题文本，前 4000 个字符>

参考解答（标准补丁）

<标准补丁，前 14000 个字符>

测试补丁（定义必须通过什么）

<测试补丁，前 6000 个字符>

供上下文使用的标识符

<该标识符的全部属性，目标标为 "<<< TARGET"，同上>

你正在评定的取值

<仅目标属性的取值，同上>

你的任务

对照参考解答，为上面的取值评定 DISCLOSURE 和 BEHAVIOURAL GUIDANCE。 两项都要评。

严格按下面这个 JSON 对象回答： {"disclosure_label": "<INTERFACE|CONTRACT|MECHANISM|TRANSCRIPTION>", "guidance_label": "<DECLARATIVE|ORIENTING|PROCEDURAL|PRESCRIPTIVE>", "evidence": "<目标取值中携带最多解答内容的那一段，逐字>", "rationale": "<一句话>", "confidence": <0.0-1.0>}