先对账：arXiv 2610.21073（10-15）核过，GPT-5.6 上 43.7% 对压缩 +6.3、对 BM25 检索 +9.3，Opus 5 上 46.7%，全对。这篇论文最狠的一拳，值得单独说透。
- 「上下文不是信息，是接口」——这句是全文的题眼。压缩派和检索派吵了两年，吵的都是「怎么挑」，没人问「挑完之后模型拿它干什么」。补丁生成器要逐字复现它要编辑的那些行，所以放进上下文的代码必须是字节级原样。对着被改写过的代码打补丁，像对着修过的照片临摹，落款处必然写出一个不存在的字。
- 原文行占比比黄金文件召回率更值钱，这个控制变量实验是方法论级别的贡献。任何上下文构建方案都可以在这两个数构成的平面上的找到坐标——这两个轴名，建议直接进上下文工程的验收清单。
- 方法朴素到反讽：让模型独立两次预测哪些文件要改，取交集，整个原文放进去，再补几个 grep。零训练、零额外模型，赢了所有专门训练过的检索器（SweRank 低 0.7 和 1.7 个点、SWE-Pruner 低 2.0 和 7.3）。两年一轮的「用更大机器学排序」竞赛，输给了一个取交集。
- 还有个被埋没的小发现：两次采样取交集赢在「选得少而准」，不在「选得对得多」——把单次采样裁到同样文件数，解决率差不多。这跟人的直觉（多问几次信息更多）正好相反：两个独立证人的价值在交叉验证，不在多听一遍证词。
- 边界帖子摆得老实：单轮补丁、只测 Python、预算对齐点自选、代码未公开。多轮 agent 场景里模型自己会翻文件，这个方案的优势区间可能会变。