别压缩，把整个文件给它
代码智能体都在同一个难题下干活：仓库比上下文窗口大得多。主流解法有两个流派。压缩派：把塞进上下文的代码做 token 剪枝，留下「重要」的，删掉冗余的。检索派：按与问题的相似度检索代码块，把最像的塞进去。两派都假设：上下文是个装东西的袋子，装得越准越好。
别压缩，把整个文件给它
代码智能体都在同一个难题下干活：仓库比上下文窗口大得多。主流解法有两个流派。压缩派：把塞进上下文的代码做 token 剪枝，留下「重要」的，删掉冗余的。检索派：按与问题的相似度检索代码块，把最像的塞进去。两派都假设：上下文是个装东西的袋子，装得越准越好。
伊利诺伊大学香槟分校上周的论文先问了一个更根本的问题：修一个 bug，上下文到底需要什么？答案是两样东西，缺一不可。第一，要改的那些文件得在上下文里。第二，这些文件的代码必须一字不差——因为模型生成补丁时，得原样复现它要编辑的那些行。
按这个标准看，两派主流方案各有各的病。检索器按「跟 issue 像不像」排序，而不是按「需不需要改」排序——错得离谱的文件可能跟问题描述高度相似，真要改的文件可能一处关键词都没有。压缩器保住了文件，但把代码原文改了——模型补丁里写的那行代码，在真实文件里不存在，补丁落不了地。
数字说这病不轻：压缩方案产出的补丁，相当一部分根本无法直接应用。
一套极简的对照
论文的方法朴素到让人怀疑这是不是一篇论文：CQ2-CARE。给模型看仓库的文件路径清单，让模型独立两次预测「哪些文件必须改」，取两个列表的交集——两次都点名的文件，大概率真要改。交集里的文件，整个原文放进上下文，一字不动。模型再指定几个 grep，把依赖的函数定义、调用点以短片段补进来。不做任何 token 级裁剪。
对照实验做得扎实：300 个 SWE-rebench 真实开源 issue，一个仓库一个，每家的上下文严格对齐到同一 token 预算，补丁用基准自带的测试评分。对比阵容：三种提示压缩方案、三种检索方案、两种专门为代码智能体训练过的优化方案。
结果：GPT-5.6 上 CQ2-CARE 解决 43.7% 的 issue，比最好的压缩方案高 6.3 个点，比最好的 BM25 块检索高 9.3 个点；Claude Opus 5 上 46.7%，比压缩高 6.3、比检索高 12.7。甚至专门训练过的选手也被比下去：SweRank 低 0.7 和 1.7 个点，SWE-Pruner 低 2.0 和 7.3。
零训练、零额外模型、纯提示工程，赢了所有专门优化过的方案。
两个数拆开看
这篇论文真正的方法论贡献是把「上下文质量」拆成了两个可量化的数：黄金文件召回率（该改的文件有多少真的在上下文里）和原文行占比（上下文里有多少代码行是原封不动的）。任何上下文构建方案，都能在这两个数构成的平面上找到位置。
然后是论文最锋利的那个发现：控制变量实验显示，原文占比比召回率更值钱。哪怕牺牲一些文件召回，只要放进来的文件是完整原文，修 bug 效果就远好于高召回但原文被破坏的方案。
换句话说：装错一点不要紧，装进来的是赝品才致命。模型对着被压缩器改写过的代码行打补丁，就像对着一张修过的照片临摹——笔笔都在努力，落款处写了个不存在的字。
这个结论有个大得多的回响。过去两年「上下文工程」的主流叙事是压缩、摘要、剪枝——把上下文当信息，信息论说有损就有一点损。这篇论文说：对代码这件事，上下文不是信息，是接口——模型要逐字对齐它，任何转写都是把接口弄脏。压缩省下的 token，全都赔给了补丁报废。
边界与瑕疵
照例说清楚边界。实验是单轮补丁：模型读一个固定上下文、写一个补丁，不是能自己翻文件、跑测试的完整智能体——多轮场景里，模型自己也会翻文件，上下文方案的作用会变。只测了 Python。预算对齐到 CQ2-CARE 自己的运行点上，论文承认这个对照位置的选择有讨论空间。代码未公开。
还有个小发现值得记：两次独立预测取交集这个技巧，文件级 F1 远高于单次采样——但把单次采样裁到同样的文件数，解决率差不多。两次采样赢在「选得少而准」，不在「选得对得多」。少而准，恰恰是整篇文章的主题。
*信源：arXiv 2610.21073（2026-10-15），Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files；伊利诺伊大学香槟分校，Xiaocong Yang、Rishit Chatterjee 共同一作，Himanshu Udupi、Vikram Ramavarapu、翟成祥在列；数据 SWE-rebench 300 issue（一仓库一题）；模型 GPT-5.6 与 Claude Opus 5；对比 LLMLingua 系压缩、BM25/稠密检索、SweRank、SWE-Pruner。*