蚂蚁面试官：claude code的-compact到底做了啥- 我说-自动总结-，他说我理解的太肤浅了
公众号名称：算法狗
作者名称：算法狗
发布时间：2026-07-04 17:40
前几天有个粉丝私信我，说他面蚂蚁的时候被问了一道题：你知道 Claude Code 的/compact 功能是怎么工作的吗？
他当时挺自信的，说这不就是”自动总结对话”嘛，把长对话压缩一下省 token。面试官听完笑了笑，问他：那压缩之后，模型是怎么知道之前改过哪些文件的？
他愣了一下，说应该也总结进去了吧。面试官又问：那如果文件内容在压缩之后变了呢？摘要里写的是旧的，模型怎么拿到新的？
他挠挠头，说不太清楚——这个细节他从来没想过。面试官没追问，只是说”你理解的有点浅了，回去研究研究”。
他后来私信我，问我/compact 到底做了什么。我一开始也以为就是个总结功能，仔细研究了一下才发现，这背后的设计比”自动总结”复杂得多。今天把这个说清楚。
✦ ✦ ✦
一、/compact 的时候到底发生了什么
/compact 激活之后会走一个流程，Claude Code 并不是简单地调一个”总结”接口，而是会做这些事情：
-
1.把原始对话（大概 99 条消息、10 万 token）最后拼接一条伪装的 user 消息。
-
2.这条消息用
CRITICAL级别的大写开头，属于强制指令级别的，目的是让模型按照固定模板、不能省略、不能用普通聊天方式去处理。 -
3.然后要求模型把完整对话历史给压缩成一个固定模板的结构化摘要，模板写成了9 个章节。这 9 个章节分别是：
-
1.任务目标
-
2.整体架构
-
3.文件变更
-
4.决策
-
5.已解决的问题
-
6.全部用户指令
-
7.约束
-
8.当前状态
-
9.下一步
这本质上就是一种”让模型自己按照固定模板把长对话压缩成结构化摘要”的策略，通过固定模板加容错模式设计，去保证压缩出来的信息是可复用的、结构化的，而不是一段模型自由发挥的摘要。
✦ ✦ ✦
二、模型内部的”两层皮”设计
模型回复里面会有 3 个部分，属于两层皮设计，每层都有各自的功能定位：
- ◆禁止执行任何工具：禁止模型在”总结”过程中调用 Read、Bash、Edit 这些工具，防止它偷偷替用户去把文件改了。
- ◆强制生成 和：强制模型先做一轮”内部推理/思考”，再去生成摘要，其实就是 Chain of Thought，也就是思维链，确保摘要的准确性。
- ◆把第 6 章”全部用户指令”原封不动保留：防止模型在复述用户历史指令的时候”添油加醋”，丢失关键的原始细节。
- ◆把第 9 章每一步都加一句 direct quote 原文摘录：保证压缩之后还能准确衔接对话的上下文，不会出现”片段”丢失的情况。
你可以看到这些设计策略其实都是有目的的写进 prompt 的，属于对压缩过程中容易出现的信息丢失模式做针对性防御。用工具就会改文件；直接摘要就会丢细节；转述就会丢原意；结尾没有原文就会衔接不上。
✦ ✦ ✦
三、模型写完之后，客户端会做什么
有一个很关键但也容易被忽略的一步。
- ◆模型按照模板去生成 + 这些内容。
- ◆Claude Code 客户端会把 全部丢弃，只保留。核心内容才会进入上下文。
也就是说：
- ◆ 里面是”模型自己打的草稿/思考过程”，这部分不是给用户看的，也不是给未来模型看的，只是用来消耗一部分原始对话的 token（这部分 token 还是挺大的）。
- ◆最后客户端只看得到 这部分。
压缩效果大概是：
- ◆原始对话：大概 10 万 token，99 条消息
- ◆压缩后：只剩 1 万 token，messages 从 99 条变成 4 条
可以说压缩率非常高了，但是这种”高度压缩”本身是抹掉”过程细节”的，留下的只有结构化的最终结论信息。
✦ ✦ ✦
四、压缩后的”4 条消息”到底装了什么
值得注意的是，压缩之后剩下的可不只是那被精简的 4 条消息，还有这些内容：
-
- 里面是 9 章结构化摘要。
- 2.紧接着的一条 assistant 回复（最后一句衔接，确保对话结尾不缺失）。
- 3.5 个文件自动附录：Claude Code 会主动把之前对话里提到过的文件，确保客户端状态是新的，而不是摘要里可能已经过时的片段。
- 4.一些 hook context 和系统注入的辅助信息。
也就是说，“恢复”并不是”总结对话”那么简单，而是要恢复成可继续工作的状态。这里面有摘要、有文件附录、有上下文衔接。换句话说，实际工程里目前的做法其实远没有”一句话总结”那么简单，客户端还得额外做很多事情来保证上下文准确性。
✦ ✦ ✦
五、总结一下（“/compact 是个大补丁”）
我的结论是：/compact 并不能算是一种优雅的”上下文压缩”机制，反而更像是一种工程上的补丁。
-
◆局限性：只靠一个摘要（Summary），模型无法恢复”可继续执行”的工作状态。摘要会丢失细节、缺可执行的计划和可参考的约束。
-
◆客户端的补偿：除了 Summary 以外，还要额外附加：
-
◆最近文件的 Read 结果，确保内容是新的
-
◆
planAttachment，也就是当前任务的规划/计划的附件 -
◆
skillAttachment，技能/指令相关的附件模板 -
◆以及各种其他上下文信息
换句话说，“摘要”只是压缩后的第一步，模型能不能”恢复”到能干活，还得靠摘要之外的一系列围绕文件重读、重新附计划、重新附技能文档等等来做弥补。这也说明在复杂项目/长任务场景下，目前的工程实现其实远没有”一句话总结”那么简单，上下文漂移、状态丢失、连续性断裂这些坑还是需要大量补丁来维持一致性的。
✦ ✦ ✦
六、附上流程图
99条消息 / ～10万token
↓
拼接伪装的 CRITICAL user 消息（强制重写指令）
↓
模型生成
↓
客户端丢弃
↓
客户端组装最终上下文（模板）：
Summary + 紧接着一条assistant回复
+ 5个文件自动附录
+ hook context
+ planAttachment / skillAttachment …
↓
最终模型：4条消息 / <1万token
✦ ✦ ✦
小结
/compact 并不是”总结对话”那么简单一句话能概括的，它是：
- 1.一次结构化的强制重写：用固定模板加容错模式设计，保证压缩过程的稳定性。
- 2.一次客户端的补偿机制：不只是靠模型摘要，还要靠文件重读、重新附计划、重新附技能文档等等来维持一致性。
- 3.一次对客户端资源的重建：摘要加文件附录加各种 attachment，共同拼出一个”压缩后的上下文”，让模型能继续干活。
这种设计的核心矛盾在于：要压缩得足够小以省 token，但压缩过程中位置信息必然丢失。所以客户端必须用多层机制来弥补：摘要加文件重读加重新附计划和技能文档等等，来拼凑出一个”够用”的上下文。这也是为什么在复杂对话/长任务场景下，上下文漂移、状态丢失、连续性断裂这些问题会变得很明显的原因。
你用过/compact 吗？有没有遇到过压缩之后模型”失忆”的情况？评论区聊聊。
内容效果不满意？点此反馈