type
Post
status
Published
date
Jan 14, 2026
slug
claude-code-compact-4l19du
summary
📌 来自：faafospecialist.substack.com (Substack) | 💡 别让 /compact 删掉你的核心代码逻辑，像 Cursor 一样管理 AI 上下文。
本文探讨了 Claude Code 中 `/compact`（压缩）命令存在的严重缺陷：由于在服务端进行且不可逆，它会永久删除大量关键的工具执行结果。作者通过数据分析发现，上下文窗口中 68% 的内容是可重复获取的工具结果，并借鉴 Cursor 的动态上下文管理方案，提出了一个将原始内容备份至本地并实现按需恢复的优化方案，能有效减少 80% 左右的 Token 占用。 | 🔑 关键词：Substack、faafospecialist.substack.com、FA&FO | 🤖 由Gemini 3 Flash (Google API)分析生成
tags
Substack
faafospecialist.substack.com
FA&FO
category
Substack文章
icon
📰
password
本文是对 faafospecialist.substack.com (Substack) 的学习笔记。所有观点归原作者所有，建议阅读原文获取完整内容。
💡 别让 /compact 删掉你的核心代码逻辑，像 Cursor 一样管理 AI 上下文。
本文探讨了 Claude Code 中 `/compact`（压缩）命令存在的严重缺陷：由于在服务端进行且不可逆，它会永久删除大量关键的工具执行结果。作者通过数据分析发现，上下文窗口中 68% 的内容是可重复获取的工具结果，并借鉴 Cursor 的动态上下文管理方案，提出了一个将原始内容备份至本地并实现按需恢复的优化方案，能有效减少 80% 左右的 Token 占用。
我已经使用 Claude Code 大约 7 个月了，处理了一些相当复杂的项目。`/compact`（压缩）命令有时候真的让我抓狂——为了节省 Context Space（上下文空间），我点击了它，但 30 分钟后我才意识到，我需要引用一些已经被总结掉的内容。
当前 /compact 命令存在的问题
目前的 `/compact` 机制存在以下几个痛点：
它发生在 Server-side（服务端），本地没有被总结内容的备份。
在总结时，它对所有内容的权重一视同仁。
原始内容会 Permanently lost（永久丢失）。
之后无法有选择性地恢复特定的工具执行结果。
但核心问题在于：Tool results（工具执行结果）大多是可以重新获取的，文件可以重新读取，Grep（文本搜索）可以重新运行，为什么要在总结过程中永久地丢弃它们呢？
研究与分析
我花了一些时间分析在长时间的会话中，究竟是什么填满了 Context window（上下文窗口）：
68% 是 Tool results（工具结果，如文件读取、grep 输出等）。
23% 是 Tool use inputs（工具使用输入）。
6% 是 User messages（用户消息）。
3% 是 Assistant responses（助手回复）。
事实是，大部分工具结果都是可以重新获取的。但一旦运行了 `/compact`，它们就会从上下文中永久消失。这时候我才意识到，`/compact` 命令是在服务端完成的。我原本以为它会把压缩后的对话写入 JSONL logs（JSONL 格式日志），但事实并非如此。
借鉴 Cursor 的方案
Cursor 最近发布了他们的 Dynamic context discovery（动态上下文发现）方案，处理方式完全不同。他们不再是简单地截断长工具响应，而是将其写入文件，并让 Agent（智能体）在需要时自行获取。
这启发了我——如果 `/compact` 也能以类似的方式工作呢？
在压缩前，将原始内容写入本地文件。
用“摘要 + 文件引用”的方式替换上下文。
增加命令，以便在需要时选择性地恢复特定消息。
原型测试与结果
我基于本地的 JSONL logs 构建了一个快速原型来测试这个想法：
一个 4.6MB 的会话： 从 277k **Tokens** 减少到 46k **Tokens**（缩减了 83%）。
一个 900KB 的会话： 从 47k **Tokens** 减少到 9.6k **Tokens**（缩减了 79%）。
我认为这个方案是可行的。因此，我在 GitHub 上提交了一个包含完整提案的功能请求。
总结与建议
我很想知道其他人是否也遇到了同样的困扰，还是说我使用 Claude Code 的方式不对。如果你觉得这个建议有帮助，请去支持一下，引起 Anthropic 工程师的注意。
另外，我也完全清楚 Claude Code 现有的 Context editing（上下文编辑）功能。但我相信，借鉴 Cursor 的方法可以作为 `/compact` 命令的一种增强方案。如果能实现这一点，我们将能在 Context engineering（上下文工程）方面拥有更多控制权，并帮助 Claude Code 更好地处理长时间运行的任务。
📌 关键收获
对 Grace 的启示
**关注上下文工程 (Context Engineering)**： 在开发独立站或使用 AI 写代码时，Token 消耗极快。学会手动管理上下文（如及时清理无用输出）比单纯依赖自动压缩更能保证 AI 的逻辑准确性。
**工具组合使用**： 虽然 Claude Code 命令行很酷，但在处理需要长路径记忆的复杂任务时，Cursor 的动态上下文管理目前更胜一筹。建议在复杂逻辑构建阶段使用 Cursor，在快速迭代和终端操作时使用 Claude Code。
**备份意识**： 在执行任何具有“总结”或“压缩”性质的 AI 操作前，养成手动备份关键代码段或提示词的习惯，避免像视频作者一样在 30 分钟后追悔莫及。
大多数工具执行结果都是可以重新获取的，为什么要通过总结把它们永久丢弃呢？
想了解更多细节？ 查看原文 →
- Author:EcomGrace
- URL:http://ecomgrace.com/article/claude-code-compact-4l19du
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
