你的AI编程助手知道哪些代码不重要——你只是没让它说

你有没有遇到过这种情况——

你让AI帮你修一个Bug，它先读了你整个项目里的十几个文件，跑了测试输出了一个900行的错误堆栈，然后又用grep搜了一遍全仓库。

到第三轮，上下文窗口已经塞满了。每轮对话越来越慢，成本疯狂上涨。

更要命的是，它开始"忘了"前面看到的关键线索。一个本来五分钟能修好的Bug，硬是绕了半小时。

你可能会想：是不是该换个更大的模型？或者抱怨这个AI编程助手不够聪明？

但你有没有想过另一个可能性——你的AI助手其实知道哪些代码不重要。它每读完一个文件，每看完一次命令输出，脑子里已经默默标注了"这几行有用"、"那几百行是废话"。

只是你从来没让它说出来。

论文地址：https://arxiv.org/abs/2607.18213^[1] GitHub：https://github.com/Ayanami1314/swe-pruner-pro^[2] 该论文于2026年7月20日提交至ArXiv，尚未经过同行评审。

你把答案扔掉了

先看一个对比。

最早解决这个问题的思路很朴素：给AI配一个"外挂"。SWE-Pruner（前作）就是这么干的——它在模型外面挂了一个0.6B的小型分类器，AI每次调用工具（比如grep、cat），写好一句"我当前在找错误处理相关的代码"作为提示，分类器就根据这个提示帮忙判断哪些行该留着。

这个方案省了40%左右的Token，效果不错。

但这里有一个被所有人忽略的问题：

那台"外挂分类器"做的事情，模型自己其实已经在做了。

SWE-Pruner Pro的团队做了一个直接的实验。他们在模型的隐藏层状态上跑了一个最简单的线性分类器——就是最原始的逻辑回归——去判断"这行代码应该保留还是丢掉"。

结果呢？

AUC 0.83，F1 0.63。

一个简单到不能更简单的分类器，就能从模型的内部表示中准确读出"这行重要、那行不重要"的信号。

这说明了一件事：你对AI说了一句话，然后它读了一个文件。在它读文件的那一瞬间，它对文件的每一行都有了判断——哪些是答案，哪些是噪声。但这个判断被锁在了它的"脑子里"，你从来没问过它。

SWE-Pruner Pro做的事情本质上很简单：在模型读完工具输出之后、生成下一个回复之前，插一个"小探针"。

这个小探针读取模型的内部状态，对每一行工具输出做一个"留/扔"的判断。只把判定为"有用"的行传给下一轮。

你不再需要一个外挂模型来做这件事。你也不需要AI自己写"我现在要找什么"。AI已经在读文件的过程中完成了这个判断——你只需要把它读出来。

这张图把两种思路的差别画得很清楚。左边是旧方案——你需要单独训练一个分类器，AI还要写一句"我现在的目标是找什么"作为提示给它。右边是新方案——AI读完文件那一刻，内部状态里就已经有"这行有用、那行是废话"的判断，你只需要在它头顶插一个小的探针，把这个判断读出来。

从"AI告诉分类器它要什么"到"问AI它认为什么是垃圾"，这是从指挥一个被动工具到理解一个已经有判断的主体。

这不是删减，是帮AI清除噪声

你可能会想：剪掉一些内容，AI不会漏掉关键信息吗？

这是绝大多数人的直觉反应。但SWE-Pruner Pro的实验数据恰好反直觉。

在MiMo-V2-Flash上，不仅省了39%的Token，SWE-Bench Verified的解决率反而不降反升了3.8个百分点。

剪掉了39%的内容，反而解题率更高了。

为什么？

因为那些被剪掉的是噪声。一个900行的错误堆栈里，真正有用的可能只有12行。剩下的888行就像一间嘈杂的办公室——你的AI同事需要从中分辨出哪句话是重点。

你剪掉噪声，不是让AI变笨了，是让它终于能专心了。

这个设计还有一个非常聪明的细节：长度感知嵌入（length-aware embedding）。

工具输出的行数从2行到200+行差别巨大。一个2行的ls命令输出和200行以上的grep结果，同样"保留50%"含义完全不同。SWE-Pruner Pro把输出按行数分成了8个桶（0-2行、3-5行、6-10行……200+行），每个桶有独立的修剪参数。

就像你面对一个2行的回复和一个200页的文档，你读的方式是不一样的。AI也一样。

图里那根蓝色柱状线告诉你"剪了多少Token"——可以看到，每加一个组件（从随机剪枝 → 静态规则 → 外部分类器 → 内部探针 → 长度感知），Token节省率在37%到40.5%之间。绿色柱状线告诉你"任务质量"——注意看，外部分类器（+Ext. Classifier）让质量回到了99%（几乎无损耗），而加上内部探针（+Internal Probe）之后质量反而开始上升，最终SWE-Pruner Pro达到103.8%——比不剪还好。

这是这张图最反直觉的发现：内化之后，剪枝不光是省钱，还在帮忙。

但你用Claude Code就用不了它——以及你其实用得了

这就是"理论的优雅"和"工程的现实"之间那道缝。

SWE-Pruner Pro的技术方案需要直接访问模型的隐藏层状态。如果你在用Claude Code、Codex、Cursor这些托管服务，你拿不到模型的内部activations。API只给你输入和输出，中间发生了什么，你不知道。

这就意味着SWE-Pruner Pro的精确方案，目前只能在开源模型的自建部署上跑。

但这里有一个更重要的启示——

你不需要复制它的技术方案。你只需要复制它的设计思路。

思路很简单：每次AI调用工具之后，不要一股脑把工具输出的全部内容塞回下一轮上下文。而是——

1. 原始工具输出保存在外面（类似文件系统或数据库），不要进上下文。
2. 只传一个精简的工作视图进下一轮提示。
3. 保留引用关系——AI可以说"我要看完整版"，你帮它调出来。
4. 记录每次的"剪了什么"，方便回溯。

这就像你开会：你不是把所有邮件和文档都带进会议室，你只带会议有关的几页纸。但你知道其他文件在哪里，需要的时候顺手就能拿到。

这才是SWE-Pruner Pro给所有AI编程产品带来的真正启发：不是"做一个更聪明的摘要"，而是"改变上下文管理的架构"。

上下文不应该是AI做过的一切事的流水账。上下文应该是经过一道"留/扔"判断的精选笔记。

你会听到一个新的工种：AI的图书管理员

SWE-Pruner Pro这种"内部探针"思路的真正放大，是Agent的运行时（runtime）会被重新设计。

过去我们以为AI编程助手的瓶颈是"模型能力"，所以一窝蜂在卷更大的模型、更长的上下文。但SWE-Pruner Pro告诉我们：模型本身已经有判断力，缺的是一个"读出判断"的机制。

这意味着Agent的下一个战场，是"理解AI已经知道什么"。

拿编程Agent举例。SWE-Pruner Pro的探针目前是"哪种行有用/没用"。但如果你把这个思路推到底——

为什么不让AI对每个工具输出都打一个"用途标签"？比如"这5行是错误堆栈的关键行"或者"这200行是测试日志的setup部分"？这不需要等SWE-Pruner Pro的开源实现，你今天用一个普通的logit probe就能做到。

更进一步，Agent的运行时（runtime）会需要一个"AI的图书管理员"角色：

• 谁来决定哪些上下文进、哪些不进？
• 什么时候回看原始工具输出？
• 怎么记录"我决定丢弃这些"以便后续审计？

这些问题过去没人问，是因为过去大家默认"上下文 = 完整历史"。SWE-Pruner Pro打破了这个默认假设。

它打开了一扇门："上下文"不应该是一个被动的存储，它应该是一个被主动管理的资源。

你现在就能做的事

第一件事：观察你的AI编程助手的上下文在膨胀什么。

下一次用Claude Code或Cursor做一个多轮任务时，看看每轮对话之间的上下文。哪些内容是重复的？哪些是没被AI引用过的命令输出？你会惊讶地发现，至少一半的内容从来没被看过第二眼。

第二件事：如果你的团队在构建基于开源模型的编程Agent，去看SWE-Pruner Pro的GitHub仓库。

它是一个在SGLang上打的补丁——在推理引擎层面插了一个FastAPI修剪服务。不是概念验证，是可以跑起来的东西。虽然有些artifact还在pending，但设计思路已经足够清晰。

第三件事：把这个思路用在任何一个用到AI工具调用的场景里。

不只是编程。数据分析Agent的SQL查询结果、客服Agent的知识库检索结果、运维Agent的日志搜索结果——所有工具输出在被塞回下一轮上下文之前，都应该被审视。

问AI一句"你看到了什么，哪些有用"——这个问题的答案其实已经在它的隐藏层里了。你只是需要一个探针把它读出来。

下一个十年最被低估的AI产品方向，不是更大的模型，而是更聪明的运行时。

论文地址：https://arxiv.org/abs/2607.18213^[3]

GitHub: https://github.com/Ayanami1314/swe-pruner-pro^[4]

注：该论文于2026年7月20日提交至ArXiv，尚未经过同行评审。

引用链接