Claude Code 压缩摘要不好用？试试这个 916 星的插件
Claude Code 自动压缩会丢上下文，这个开源插件用一次请求为每条工具记录打分，保留有用的、裁掉失效的，让上下文干净。
适合：跑 Claude Code 多步长任务、经常被自动压缩坑掉关键上下文的开发者。
先说结论
Claude Code 默认的压缩摘要，是在上下文快爆的时候把整段对话压成一段话。问题是，工具调用里那些参数、报错、文件路径，往往正是后面还要用到的证据。一刀切下去，证据没了，模型接下来就开始瞎猜。
tamaratran/fast-jev-compaction 这周刚开源就拿了 916 颗星，思路就一句话：别压缩原文，给每条工具记录打个分，留下有用的，扔掉失效的。
真正的问题
用过 Claude Code 处理多步任务的人都知道，长跑任务跑到一半，最容易出事的不是模型不行，是上下文失忆。
默认行为是先让模型自己写一段压缩摘要。听起来很美，实际有三个坑：
第一，模型不是历史学家，它只会复述自己记得的部分。早期那条 curl 命令返回了 401，关键参数在第十行之后的某个角落，模型在压缩时大概率不会保留。
第二，压缩这一步自己就要占上下文窗口。等压缩完了，留给后面继续干活的空间已经被吃掉一截。
第三，写出来的摘要本质上是对话内容，而真正需要保留的是结构化的事实：命令、路径、报错码、关键返回值。摘要反而把这些压平了。
所以问题不是“模型会不会写摘要”，而是：当上下文撑不住时，哪些工具记录才是接下来真正需要的？
怎么做更省力
这个插件的工作流和默认路径完全相反。它不写摘要，而是对每一条工具调用 + 返回结果单独打分，只做一次轻量请求。
| 维度 | 默认压缩 | fast-jev-compaction |
|---|---|---|
| 处理对象 | 整段对话 | 每条工具记录 |
| 保留形式 | 重写为摘要 | 原样保留 |
| 淘汰逻辑 | 一刀切 | 按分数丢弃或裁切 |
| 模型调用 | 通常多次 | 一次 |
| 失真风险 | 高 | 低 |
打分结果会触发三种动作：保留原样、直接丢掉、把过长的结果截断到最近几行。换句话说，留下的都是证据链上的关键节点。
另一个值得注意的点是“fast”。插件名字里这个词不是白叫的。打分只在压缩发生的那一轮执行一次，不是每条消息都跑模型。延迟和成本都压得住。
哪些坑要避开
第一，它不是总结器。它解决的是工具记录的取舍，不负责把用户的自然语言提问也重写一遍。如果你想要的是“读完像会议纪要”的体验，这个插件给不了。
第二，打分的依据来自模型判断，不是规则引擎。极少数情况下，模型可能误判某条记录“有价值”，导致它本来该被裁掉却留了下来。所以关键任务里，建议在压缩前后做一次对照，确认关键证据是否还在。
第三，它解决的是上下文容量问题，不是模型能力问题。如果你发现压缩后模型还是答不好，多半是任务本身需要拆，而不是继续把上下文堆满。
第四，安装路径要认准。这是 Claude Code 的插件，不是独立 CLI，也不是给 Cursor、Windsurf 用的。装错地方不会有任何效果。
现在就能动手
如果你已经在用 Claude Code 跑长任务（多文件重构、跨服务调试、长流程数据处理），这个插件值得现在就装上试一次。
最省事的接入路径：
1。 打开 Claude Code，进入插件市场或本地配置目录，按仓库名 tamaratran/fast-jev-compaction 搜索安装。 2。 在 settings.json 或对应的插件配置里启用 compact 钩子，让它在上下文压缩时自动接管。 3。 跑一段你以前常“压完就翻车”的任务，对比压缩前后的工具记录清单：关键命令、报错码、文件路径是否还在。 4。 如果发现某类工具记录总被误判（比如 git diff 长输出），在仓库 issue 里反馈，这是项目早期最需要的信号。
不用等官方动手，这一周 916 颗星已经说明社区在投真金白银的票。先用起来，再决定要不要长期留。