前几天有个粉丝私信我，说他面蚂蚁的时候被问了一道题：你知道 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 这些工具，防止它偷偷替用户去把文件改了。
- ◆强制生成
<analysis>和<summary>：强制模型先做一轮"内部推理/思考"，再去生成摘要，其实就是 Chain of Thought，也就是思维链，确保摘要的准确性。 - ◆把第 6 章"全部用户指令"原封不动保留：防止模型在复述用户历史指令的时候"添油加醋"，丢失关键的原始细节。
- ◆把第 9 章每一步都加一句 direct quote 原文摘录：保证压缩之后还能准确衔接对话的上下文，不会出现"片段"丢失的情况。
你可以看到这些设计策略其实都是有目的的写进 prompt 的，属于对压缩过程中容易出现的信息丢失模式做针对性防御。用工具就会改文件；直接摘要就会丢细节；转述就会丢原意；结尾没有原文就会衔接不上。
✦ ✦ ✦
三、模型写完之后，客户端会做什么
有一个很关键但也容易被忽略的一步。
- ◆模型按照模板去生成
<analysis>+<summary>这些内容。 - ◆Claude Code 客户端会把
<analysis>全部丢弃，只保留<summary>。核心内容才会进入上下文。
也就是说：
- ◆
<analysis>里面是"模型自己打的草稿/思考过程"，这部分不是给用户看的，也不是给未来模型看的，只是用来消耗一部分原始对话的 token（这部分 token 还是挺大的）。 - ◆最后客户端只看得到
<summary>这部分。
压缩效果大概是：
- ◆原始对话：大概 10 万 token，99 条消息
- ◆压缩后：只剩 1 万 token，messages 从 99 条变成 4 条
可以说压缩率非常高了，但是这种"高度压缩"本身是抹掉"过程细节"的，留下的只有结构化的最终结论信息。
✦ ✦ ✦
四、压缩后的"4 条消息"到底装了什么
值得注意的是，压缩之后剩下的可不只是那被精简的 4 条消息，还有这些内容：
- 1.
<summary>里面是 9 章结构化摘要。 - 2.紧接着的一条 assistant 回复（最后一句衔接，确保对话结尾不缺失）。
- 3.5 个文件自动附录：Claude Code 会主动把之前对话里提到过的文件，确保客户端状态是新的，而不是摘要里可能已经过时的片段。
- 4.一些 hook context 和系统注入的辅助信息。
也就是说，"恢复"并不是"总结对话"那么简单，而是要恢复成可继续工作的状态。这里面有摘要、有文件附录、有上下文衔接。换句话说，实际工程里目前的做法其实远没有"一句话总结"那么简单，客户端还得额外做很多事情来保证上下文准确性。
✦ ✦ ✦
五、总结一下（“/compact 是个大补丁”）
我的结论是：/compact并不能算是一种优雅的"上下文压缩"机制，反而更像是一种工程上的补丁。
- ◆局限性：只靠一个摘要（Summary），模型无法恢复"可继续执行"的工作状态。摘要会丢失细节、缺可执行的计划和可参考的约束。
- ◆客户端的补偿：除了 Summary 以外，还要额外附加：
- ◆最近文件的 Read 结果，确保内容是新的
- ◆
planAttachment，也就是当前任务的规划/计划的附件 - ◆
skillAttachment，技能/指令相关的附件模板 - ◆以及各种其他上下文信息
换句话说，"摘要"只是压缩后的第一步，模型能不能"恢复"到能干活，还得靠摘要之外的一系列围绕文件重读、重新附计划、重新附技能文档等等来做弥补。这也说明在复杂项目/长任务场景下，目前的工程实现其实远没有"一句话总结"那么简单，上下文漂移、状态丢失、连续性断裂这些坑还是需要大量补丁来维持一致性的。
✦ ✦ ✦
六、附上流程图
99条消息 / ~10万token
↓拼接伪装的 CRITICAL user 消息（强制重写指令）
↓模型生成 + （9章结构化模板）
↓客户端丢弃 ，只保留
↓客户端组装最终上下文（模板）：
Summary + 紧接着一条assistant回复
5个文件自动附录
hook context
planAttachment / skillAttachment …
↓
最终模型：4条消息 / <1万token
✦ ✦ ✦
小结
/compact并不是"总结对话"那么简单一句话能概括的，它是：
- 1.一次结构化的强制重写：用固定模板加容错模式设计，保证压缩过程的稳定性。
- 2.一次客户端的补偿机制：不只是靠模型摘要，还要靠文件重读、重新附计划、重新附技能文档等等来维持一致性。
- 3.一次对客户端资源的重建：摘要加文件附录加各种 attachment，共同拼出一个"压缩后的上下文"，让模型能继续干活。
这种设计的核心矛盾在于：要压缩得足够小以省 token，但压缩过程中位置信息必然丢失。所以客户端必须用多层机制来弥补：摘要加文件重读加重新附计划和技能文档等等，来拼凑出一个"够用"的上下文。这也是为什么在复杂对话/长任务场景下，上下文漂移、状态丢失、连续性断裂这些问题会变得很明显的原因。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
)
)
 agent和组件)