企业官网建设流程全解析

Schrödinger’s Code Repository: Have LLMs Learned SWE-bench or Memorized It?

作者：Silin Chen, Yufei Yang, Xiaodong Gu, Yuling Shi, Chengcheng Wan, Haibing Guan
核心发表机构：Shanghai Jiao Tong University、Xi’an Jiaotong University、East China Normal University、Shanghai Innovation Institute
论文链接：arXiv:2609.27891v1
发布于：arXiv 预印本（cs.SE）

|—😐—😐—😐
| GPT-5.4-mini | 46.8% | 35.6% | −11.2% |
| DeepSeek-v4-Flash | 72.8% | 66.8% | −6.0% |
| GPT 5.1 | 44.6% | 36.2% | −8.4% |
| Gemini-3.1-Flash-Lite | 56.7% | 42.3% | −14.4% |

作者强调，由于底层 issue、执行环境与测试定义的正确性判据都未改变，性能下降不能由任务语义变化解释，而更可能说明规范 SWE-bench 表现部分受益于对规范仓库表示的熟悉，当前智能体对训练中遇到的仓库侧线索是敏感的。交互成本的上升同样普遍：平均动作数与 token 消耗均明显增加，受影响最强的配置中输入 token 使用量增加超过2.5 倍。例如 GPT 5.1 的动作数增加61.5 % 61.5\%61.5%、输入 token 增加161.3 % 161.3\%161.3%、输出 token 增加68.6 % 68.6\%68.6%；GPT-5.4-mini 的动作数增加76.2 % 76.2\%76.2%、输入 token 增加255.4 % 255.4\%255.4%、输出 token 增加86.4 % 86.4\%86.4%；DeepSeek-v4-Flash 的动作数增加116.0 % 116.0\%116.0%、输入 token 增加253.6 % 253.6\%253.6%、输出 token 增加81.6 % 81.6\%81.6%；Gemini-3.1-Flash-Lite 的动作数增加81.09 % 81.09\%81.09%、输入 token 增加136.06 % 136.06\%136.06%、输出 token 增加67.66 % 67.66\%67.66%。

RQ2：侵蚀熟悉的仓库侧表面线索如何影响智能体？该问题通过细粒度动作分类法分析轨迹，观察额外动作在六类动作中的分配：navigate、search、read、probe、edit、test。

结果显示，SchrodingerRepo 带来的主要行为成本不是编辑或测试努力增加，而是动作系统性重新分配到仓库探索。对 DeepSeek-v4-Flash，83.6%的额外动作属于navigate、search、read、probe，仅16.5%属于edit和test；其中probe占 31.4%，read占 19.4%，search占 17.9%。对 GPT-5.4-mini，81.6%的额外动作集中在探索导向行为上，其中read占 41.8%、search占 33.1%、probe仅占 3.7%。GPT 5.1 的动作分布与 GPT-5.4-mini 高度相似，同样以read和search为主、probe很少。由此可以读出一个探索策略差异：DeepSeek-v4-Flash 更倾向于运行时轻量执行与主动探测，在 baseline 中动作数就已经更多，在变换视图下进一步增加探索，因而保留了更大比例的 Pass@1，但交互开销与 token 消耗显著更高；GPT-5.4-mini 更保守，主要依赖静态检查与文本检索，探索动作更少，但在熟悉仓库线索被侵蚀后相对性能退化更大。换言之，存在探索强度与鲁棒性之间的权衡：更探索性的智能体更能恢复缺失的仓库上下文，而更保守的智能体对表示偏移更敏感。总体而言，当熟悉线索被移除后，智能体必须通过导航、搜索、阅读与探测来重建仓库理解，而不是直接执行修复。

RQ3：SchrodingerRepo 能否迁移到其他仓库级任务？在 SWE-QA 上，变换后的仓库视图同样造成答案质量下降与交互成本上升：

细分来看，最大影响仍来自Level 2（命名空间映射）：GPT-5.4-mini 在该层下降 3.95 分，DeepSeek-v4-Flash 下降 0.45 分；Level 1 几乎无影响；Level 3 与 Level 4 仅造成较小答案质量变化。这说明仓库自有名称即使对 QA 任务也是主导性的仓库侧线索。交互成本方面，GPT-5.4-mini 的平均动作从 6.28 增至 7.42（+ 18.15 % +18.15\%+18.15%），输入 token 增加34.65 % 34.65\%34.65%，输出 token 增加21.32 % 21.32\%21.32%；DeepSeek-v4-Flash 的动作从 24.49 增至 35.02（+ 43.02 % +43.02\%+43.02%），输入 token 增加59.10 % 59.10\%59.10%，输出 token 增加32.07 % 32.07\%32.07%。作者解释，与 issue resolution 相比，Level 3 与 Level 4 在 QA 上影响更小，因为 QA 主要需要定位和理解仓库上下文，并不涉及完整的故障定位、修改、测试执行与迭代验证工作流。两个模型的鲁棒性剖面与 RQ2 一致：DeepSeek-v4-Flash 更探索性，能在替代视图下重建足够上下文因而基本保持 QA 性能，但交互成本高；GPT-5.4-mini 更高效，但在规范表示下更敏感，替代实例下交互成本增加且答案质量下降。因此，SchrodingerRepo 引起的行为与效率变化可以泛化到仓库级问答，说明其影响不局限于 issue resolution。

RQ4：SchrodingerRepo 是否使 issue 解决实例本身变得更难？这是排除替代解释的关键实验，仅在时间上留出的 SWE-rebench 实例上进行，共 110 个实例，均创建于 GPT-5.4-mini 发布之后，使直接暴露于被评估实例的可能性很低。

与 SWE-bench Verified 不同，GPT-5.4-mini 在完整 SchrodingerRepo 下 Pass@1保持不变，仍为 17.27%，但交互成本明显增加：平均动作从 15.82 到 17.11，输入 token 增加22.01 % 22.01\%22.01%，输出 token 增加15.58 % 15.58\%15.58%。这表明 SchrodingerRepo没有使底层 issue-resolution 任务在可解性上变得更难，而只是改变了智能体与仓库的交互过程，导致更高的探索成本，同时保持最终结果。作者进一步指出，交互成本的增加在广泛使用、长期存在的仓库中更为明显——这些仓库更可能在预训练或开发中遇到过——这从侧面支持了"规范 SWE-bench 实例可能部分受益于智能体对仓库特定表面表示的熟悉"这一解释。其结论是：SchrodingerRepo 移除的主要是对熟悉仓库侧线索的依赖，而非增加任务难度。

4.3 消融实验 / Ablation Study

Level-wise 消融把四层变换逐层拆开，以识别鲁棒性差距的来源。

Level 1（问题陈述重构）对 Pass@1 影响很小。GPT 5.1 与 GPT-5.4-mini 的 Pass@1 完全不变；DeepSeek-v4-Flash 下降2.0 2.02.0个百分点。这说明仅改写问题陈述不足以移除熟悉仓库表示带来的优势。不过值得注意的是，DeepSeek-v4-Flash 在 Level 1 下的行为已经发生变化：动作数增加33.2 % 33.2\%33.2%、输入 token 增加42.8 % 42.8\%42.8%，而输出 token 反而下降6.4 % 6.4\%6.4%，与 GPT 系列在 Level 1 下的近乎"无效"形成对比。在 SWE-QA 上，Level 1 同样几乎不产生影响（GPT-5.4-mini −0.03 分，DeepSeek-v4-Flash +0.08 分）。

Level 2（命名空间映射）是单项退化最大的层级。GPT 5.1、GPT-5.4-mini、DeepSeek-v4-Flash 分别下降7.4、6.4、6.0 个百分点，所有设置统计显著（p < 0.01 p<0.01p<0.01）。交互成本的增加幅度也是各层中最高的：三个模型的平均动作数分别增加63.3%、32.6%、112.4%，输入 token 分别增加162.3%、108.2%、218.3%。以 DeepSeek-v4-Flash 为例，Level 2 下 Pass@1 为 66.8%（p < 0.01 p<0.01p<0.01），平均动作 98.13（+ 112.4 % +112.4\%+112.4%，p < 0.01 p<0.01p<0.01），输入 token 3,332,478（+ 218.3 % +218.3\%+218.3%，p < 0.01 p<0.01p<0.01），输出 token 22,549（+ 55.5 % +55.5\%+55.5%，p < 0.01 p<0.01p<0.01）。这一结果与动机实验相互印证：仓库内部的命名与符号系统是最具辨识度的记忆线索。

Level 3（文件内布局重排）与 Level 4（保功能代码重写）造成中等幅度下降。跨模型来看，Level 3 的 Pass@1 变化范围在0.8 0.80.8–3.4 3.43.4个百分点之间，Level 4 在1.2 1.21.2–2.8 2.82.8个百分点之间，影响较为温和，但仍伴随交互成本上升。以 DeepSeek-v4-Flash 为例，Level 3 下 Pass@1 为 72.0%（− 0.8 % -0.8\%−0.8%），平均动作 47.52（+ 2.9 % +2.9\%+2.9%），输入 token 增加5.0 % 5.0\%5.0%，输出 token 增加2.5 % 2.5\%2.5%；Level 4 下 Pass@1 为 70.0%（− 2.8 % -2.8\%−2.8%，p < 0.05 p<0.05p<0.05），平均动作 48.88（+ 5.8 % +5.8\%+5.8%），输入 token 增加17.2 % 17.2\%17.2%，输出 token 增加16.2 % 16.2\%16.2%（p < 0.05 p<0.05p<0.05）。

完整 SchrodingerRepo 产生最大总体退化。GPT 5.1 从 44.6% 降至 36.2%（− 8.4 % -8.4\%−8.4%），GPT-5.4-mini 从 46.8% 降至 35.6%（− 11.2 % -11.2\%−11.2%），DeepSeek-v4-Flash 从 72.8% 降至 66.8%（− 6.0 % -6.0\%−6.0%），均达到或超过单层中退化最大的 Level 2。交互成本方面，DeepSeek-v4-Flash 在完整设置下平均动作达到 99.78（+ 116.0 % +116.0\%+116.0%，p < 0.01 p<0.01p<0.01），输入 token 达到 3,702,241（+ 253.6 % +253.6\%+253.6%，p < 0.01 p<0.01p<0.01），输出 token 达到 26,347（+ 81.6 % +81.6\%+81.6%，p < 0.01 p<0.01p<0.01）。这一"联合大于单层"的模式说明，对规范仓库表示的熟悉分布在多个呈现层级上，而非仅集中在命名结构。

4.4 案例研究：熟悉与不熟悉仓库视图下的轨迹对比

作者以django__django-11999为例做定性的轨迹对比。该实例的问题是：用户定义的get_FOO_display()方法被 Django 生成的 display 方法覆盖。

在原始仓库视图下，智能体快速跟随 issue 中熟悉的 Django 术语行动：列出仓库后，直接在django/db/models/下搜索get_.*_display，立即返回django/db/models/fields/__init__.py与django/db/models/base.py；打开字段文件附近的匹配行，观察到get_%s_display通过setattr被无条件安装；简要检查base.py中的 backing implementation 后，就已定位错误代码并识别出修复方案——用存在性检查保护生成方法的安装。

在SchrodingerRepo 转换视图下，同一个 issue 通过变换后的仓库视图暴露，智能体不能再依赖原始的 Django 路径与类名。轨迹随即转向更广泛的仓库探索：列出当前目录、枚举 Python 文件、检查顶层working_repository/树、在源文件与测试文件中搜索 display 相关方法；之后打开转换后的实现文件working_repository/storage_engine/object_models/entries/__init__.py与相关 backing-method 文件working_repository/storage_engine/object_models/anchor.py。即使找到了类似render_%s_label的生成逻辑，智能体仍继续检查周围字段注册逻辑、测试、配置文件、最小复现设置，以确认转换后的名称确实对应原始 display 方法的行为。最终，转换运行需要更多交互步骤：从 37 个 action 增至 217 个 action，但仍收敛到相同的提交补丁。这一对比直观地说明：SchrodingerRepo 改变的是交互过程，而非修复的本质。

五、相关工作 / Related Work

SWE-bench 及其变体。SWE-bench 把真实 GitHub issue 转化为可执行的补丁生成任务；SWE-bench Verified 通过人工验证提高可靠性，成为前沿编码智能体的标准基准；SWE-Bench+ 改进基准实例质量与 metadata 覆盖；SWE-bench Live 与 SWE-rebench 强调时间新鲜度，加入新发布或 post-release 任务以减少直接污染；SWE-Bench Pro 转向更复杂、长程、活跃维护仓库中的 issue；SWE-bench Multimodal 扩展到混合文本与视觉输入；SPICE 自动标注 issue clarity、test coverage 与 effort；SWE-Effi 在资源约束下重新评估有效性；Repo2Run 与 R2E-Gym 关注可扩展可执行环境与程序化训练/评估；SWE-Bench++ 研究从开源项目可扩展生成仓库级基准实例。本文指出，这些变体共同面临覆盖度与新鲜度的权衡：优先新引入或人工精选实例可提高评估干净度，但常因丢弃大型成熟仓库中的长尾案例而降低仓库级错误模式的多样性，没有单一变体能够完全捕获真实世界软件工程失败模式的广度。SchrodingerRepo 的差异化路线是保留现有基准的覆盖度，同时在评估时系统性地变化仓库呈现，从而在不牺牲实例多样性的前提下实现鲁棒性评估。

静态基准扰动。近期工作开始研究 SWE-bench 上的强性能究竟反映真实仓库级推理还是对固定 benchmark artifacts 的敏感性。SWE-Bench Illusion 显示模型可以利用 issue 描述与仓库位置之间的稳定关联，性能可能部分依赖静态评估设置中的学习相关性；LastingBench 研究防御知识泄漏的基准构建策略；Wang et al. 重新审视已解决的 SWE-bench issue，质疑被接受的 patch 是否语义正确；Ahmed et al. 分析 test overfitting 导致的基准性能膨胀；UTBoost 与 SWE-ABS 通过更严格或对抗性的测试加强评估；Saving SWE-Bench 变异基准实例以创建更现实的 agent 评测设置；PoorCodeSumEval 引入受控代码混淆，修改标识符并降低可读性同时保留程序行为，测试对表面词汇线索的鲁棒性；RepoMirage 对 SWE-bench 实例应用仓库级扰动，在改变结构呈现下增加表观难度。本文承认这些方法共同表明"修改静态基准呈现可以暴露对评估工件表面规律性的敏感性"，但同时指出它们的共同局限：转换后的实例一旦构建就固定，仍可能被纳入未来的训练或评估语料，从而限制其防止重复暴露于特定表示的能力。

由此可以清晰界定 SchrodingerRepo 的位置：它把仓库表示实例化为潜在的、评估时的变量，生成新鲜的、种子条件化的仓库视图，在每次评估运行时才被实例化，同时保留完整的执行语义与正确性判据。它要确保的是智能体真正从实现的仓库结构出发解决底层问题，而非依赖对规范仓库呈现的先前熟悉。这也解释了本文的自我定位：既有的缓解路线是"更换实例"（换新题），本文的路线是"同一实例、动态更换表示"，是一个可逐层解耦、定量归因的实验工具，而非单纯新增一个静态基准。

六、局限性与展望 / Limitations & Future Work

外部效度。评测在 SWE-bench Verified 与 SWE-QA 上进行，这些基准主要由 Python 开源仓库组成。虽然它们提供了现实感较强的仓库级软件工程任务，但仍可能反映特定生态的特征与 SWE-bench 式的交互模式。观察到的鲁棒性差距与行为变化能否泛化到其他编程语言、其他仓库生态、不同结构约定与开发实践，仍是一个开放问题。

内部效度与工具接口。当前实现主要针对命令行式的仓库交互。这覆盖了被评测智能体的绝大多数操作，但配备更丰富仓库感知工具的智能体可能需要额外适配，例如 IDE APIs、language-server 查询以及 AST 级导航；必须确保变换后的仓库表示在所有这些工具接口中都保持一致。把 SchrodingerRepo 扩展到支持此类工具接口被列为明确的未来工作。

变换范围的规模约束。由于仓库级全量变换在 SWE-bench Verified 规模下计算上不可行，Level 3 仅在 golden-patch 相关文件内重排，Level 4 仅对 golden-patch 相关代码区域重写。这一取舍让评测可行，但也意味着变换的作用面限定在"与目标 issue 最相关"的局部，更广泛的仓库级布局与实现模式变化未被覆盖——这部分影响是否与局部变换同阶，资料未给出结论。

验证流程的人工依赖。Level 1 的重建需要人类工程师终审；每个变换层级还需人类审查者额外检查 100 个随机抽样实例，以确认变换版与原版指向同一底层任务。动机实验同样依赖人类专家逐轮判断模型输出中是否包含尚未出现在 prompt 中的任务特定内容。这类人工环节保证了有效性，但也限制了框架在超大规模基准上的吞吐。

评估成本的传导。由于每个 benchmark instance、每个变换级别都要生成 3 个随机种子视图并独立评估后取平均，总评估成本相对静态基准被放大约一个数量级；而被评估的某些模型本身在变换视图下的交互成本已急剧上升（例如 DeepSeek-v4-Flash 在完整设置下平均动作数增加116.0 % 116.0\%116.0%、输入 token 增加253.6 % 253.6\%253.6%）。这构成一种现实约束：表示鲁棒性评估在提高诊断力的同时，显著提高了评测的算力门槛。

七、总结 / Conclusion

本文针对仓库级编码基准的内生数据泄漏问题提出了一条不同于"更换实例"的技术路线。作者先通过人类专家逐轮揭示问题陈述的动机实验，量化地证明被评估模型在接触仓库之前就已在超过 65% 的实例上表现出任务特定记忆、在超过 18% 的实例上能在 patch/test 层面召回修复内容，从而为"记忆而非推理"这一质疑提供了直接证据。随后提出 SchrodingerRepo，把测试仓库建模为评估时潜变量，通过问题陈述重建、命名空间映射、文件内布局重排与保功能代码重写四个语义保持的变换层级，在保留原始可执行行为与测试判据的前提下侵蚀命名约定、文件布局与实现模式；带种子、可逆的映射与基于仓库状态的补丁恢复机制则保证评估仍然锚定在原始 SWE-bench 坐标之上。

实验给出了相互支撑的三条证据链。其一，在 SWE-bench Verified 上，完整变换使 Pass@1 下降6.0 6.06.0–14.4 14.414.4个百分点（p < 0.05 p<0.05p<0.05），其中命名空间映射贡献最大；其二，轨迹分析显示81.6 % 81.6\%81.6%–83.6 % 83.6\%83.6%的额外动作花在仓库探索与定位上，而非编辑或测试，说明成本来自重建仓库理解；其三，效果可迁移到 SWE-QA（答案质量最多下降4.64 4.644.64分，动作数增加18.15 % 18.15\%18.15%–43.02 % 43.02\%43.02%），而在时间上留出的 SWE-rebench 实例上 Pass@1 保持17.27 % 17.27\%17.27%不变、仅交互成本上升（动作+ 8.15 % +8.15\%+8.15%、输入 token+ 22.01 % +22.01\%+22.01%），从而排除了"变换只是把任务变得更难"这一替代解释。案例研究进一步从定性角度展示了同一修复任务在熟悉与不熟悉仓库视图下 37 步与 217 步的轨迹差异，却收敛到同一补丁。

综合来看，论文的结论是：当前编码智能体的强表现部分反映的是对表层仓库线索的记忆，而非完全的仓库级推理能力。这一发现的方法论意义在于，仓库表示应被视为评估编码智能体时的显式实验变量——评估范式应从"在单一可能已被熟悉的表示上测性能"转向"在语义等价的多种仓库实现上测鲁棒性"。作者也明确指出，这一框架仍受限于 Python 生态与命令行式交互；未来工作需要在多语言、多生态以及 IDE APIs、language-server 查询等更丰富的仓库感知工具接口下，保持表示鲁棒评估的一致性。

原文摘要:Repository-level coding benchmarks have become the standard for evaluating coding agents, yet they inherently suffer from data leakage because they are built upon popular open-source repositories repeatedly used for training. Consequently, strong performance may reflect memorization of canonical repository cues rather than robust repository reasoning. We propose SchrodingerRepo (Schrödinger’s Repository), an evaluation framework for testing coding agents under dynamically instantiated repository representations. Instead of repeatedly using a static representation of the test repository, SchrodingerRepo treats the test repository as an evaluation-time latent variable that is dynamically instantiated only when the agent enters the evaluation environment. The instantiated repository preserves the original executable behavior while eroding familiar cues such as naming conventions, file layouts, and implementation patterns through four transformation levels: problem statement reconstruction, namespace remapping, intra-file layout reordering, and functionality-preserving code rewriting. We evaluate popular LLMs on SWE-bench Verified and SWE-QA. Results show that removing familiar repository cues consistently degrades agent performance and substantially increases interaction costs across models. Further analysis reveals that the additional cost is primarily caused by increased difficulty in repository exploration and localization. These findings suggest that current coding agents may partially rely on memorized repository-side cues, highlighting the need for evaluation under dynamically instantiated repository representations.

PDF链接:https://arxiv.org/pdf/2609.27891v1

部分平台可能图片显示异常，请以我的博客内容为准