我最近一直在写一个追求“一次对话干到底”的独立项目代码量从几百行涨到上千行之后我和 Claude 的对话窗口明显有点跟不上了。每次聊到一半它开始忘记函数签名、忘记刚讨论过的数据结构甚至把上一轮已经改掉的设计又翻了回来。这种情况下最直接的办法就是手动执行一次上下文压缩把那些已经聊透的细节折叠成一份更精炼的摘要然后继续干活。这篇博文我想把“手动执行 Claude 压缩上下文后到底保留了什么”这件事彻底讲清楚。我会拆解压缩的工作原理列出哪些内容会被完整保留、哪些会被丢弃再结合一个真实的 Vibe Coding 案例展示压缩前后对话状态的变化以及怎么压缩才能最大程度保住有效信息。无论你正在做长会话的代码生成、重构、还是多文件项目开发这篇都能给你一套可以直接抄的上下文管理思路。1. 为什么需要手动压缩上下文它到底在解决什么问题Claude 的上下文窗口是有限的这个限制决定了单次对话不可能无限承载所有历史信息。窗口满了之后有两种典型表现一种是 Claude 开始忽略早期消息里的关键约束因为它已经“看”不到那么远另一种是输入成本急剧上升每多传一轮历史模型需要重新处理一遍全部前缀内容延迟和费用都跟着涨。所谓“手动执行压缩上下文”本质上是把一大段历史对话视为原材料提取一份精炼的核心状态然后用这份状态替换掉原始对话继续聊。压缩不是让 Claude 失忆而是让它把注意力重新聚焦在真正重要的事实上。你可以把它理解为开会时整理会议纪要不追求逐字保留每个人说了什么只追求下一个接手的人拿到纪要知道当前结论、待办事项和遗留风险就能无缝继续推进。在 Vibe Coding 场景里这种压缩特别刚需。Vibe Coding 的特点是你在一个节奏里持续提出模糊需求让 AI 不断给出代码、改动、解释会话很容易变成几百轮的长对话。早期聊过的设计决策往往决定了后面每一行代码的走向一旦这些信息被窗口挤掉AI 就会开始频繁“失忆”。手动压缩的意义就在于你主动决定哪些早期信息必须留下而不是被动等着窗口把信息挤走。压缩本身不是 Claude 的隐藏功能它更像是一种使用技巧。你可以选择把当前整段对话复制出来粘贴到一个新对话里也可以使用工具中内置的 summarize 命令或者分块摘要的方式把历史记录浓缩成一段结构化的状态描述。核心动作都一样让 Claude 自己在“读史”之后产出一份摘要然后你们基于这份摘要继续而不是基于原始记录继续。2. 压缩到底保留了什么结构、摘要、系统约束与被忽略的原始消息手动压缩之后对话窗口里余下的元素其实可以拆成几个层次。理解了这些层次你就能判断压缩结果是否真正可用。2.1 系统提示与环境说明是完整保留的无论你怎么压缩历史消息模型基础的系统提示通常不会动。这包括它自身的角色设定、回答规范、安全边界以及某些运行环境注入的上下文。比如你在 Claude 工程环境中执行压缩它会继续知道当前目录结构、可能的工具调用约定、输出格式偏好。这些内容不属于普通对话历史它们更像“永久记忆”压缩掉对话轮次并不会影响这一层。我在实际项目中验证过压缩后它仍然知道当前项目名、仍然会用我习惯的代码风格回答问题这让我确信环境描述在压缩前后是被继承下来的。你需要关心的、真正会被压缩动作影响的其实是那些在一次又一次问答中产生的中间状态。2.2 摘要部分是你手工压缩后唯一需要信任的“记忆”所谓保留了什么核心就是保留了一份放在对话历史最前面的摘要。这份摘要长什么样完全取决于你怎么引导 Claude 生成它。我会在压缩前给出这样的指令“请阅读我们整个对话过程然后用 500 字以内的篇幅总结目前项目的核心架构、已实现功能、当前正在处理的模块、尚未解决的问题、最近几次修改的关键决策以及你建议下一步做的事情。”这种情况下Claude 产出的摘要会非常接近一份项目状态报告。它不再逐字保留某一次对话中某个具体函数的实现细节而是把这些细节浓缩成“支付模块已完成使用策略模式封装了三种支付渠道”。如果摘要里缺少某个信息那这个信息在压缩后的世界里就等于不存在了你需要靠新的提问把它重新补回来。这里有一个容易被忽略的关键点摘要的可靠程度取决于它的生成者和原始信息的距离。如果你在同一个对话里让 Claude 生成摘要它确实读过完整历史所以摘要的信息覆盖范围大概率是够的。但如果你自己手工从聊天记录里复制粘贴、或者用第三方脚本截取上下文则要慎重判断有没有遗漏关键约束。这就是我坚持“在同一个对话会话内执行压缩、而不是另开新对话”的原因。2.3 近期的原始消息通常会以尾部保留的方式继续存在很多上下文压缩方案并不是清空全部历史而是保留窗口结尾最近的一部分原始消息。具体保留多少取决于你用的压缩策略。比如某些工程化方案会保留最近 20 到 30 轮对话原文把更早的部分替换为摘要。这么做的理由是当前正在讨论的话题细节往往集中在尾部如果连尾部都被摘要化AI 就无法基于具体的代码片段进行精确修改。我采用的常见做法是“摘要置顶 尾部截留”手动把摘要插入到对话开头然后从某个时间点开始删除早于该时间点的历史仅保留当前最近的十几轮。这样执行之后再发送新消息Claude 既能看到摘要里的全局状态又能看到最近几轮里贴过的具体报错、代码段和修改意图。2.4 被压缩掉的原始消息与中间细节压缩最直接的代价就是原始消息被丢弃。那些中间过程里讨论过的废弃方案、尝试过但不生效的配置、中间输出的一堆报错堆栈、甚至你自己打了一半的模糊提问这些在压缩之后都不会再被模型看到。有些细节丢掉并不可惜比如反复尝试同一配置的多个版本但有些细节丢掉就很危险比如某个关键的第三方库版本号、某一次运行输出里的精确错误码。这些信息如果在摘要里没有出现那压缩就等于造成了一次信息丢失。因此每次压缩之前我都建议先追问一句摘要里是否需要包含当前使用的依赖版本列表、最近一次失败的具体报错。压缩也不是零成本的。它只是用一个更紧凑的表征替代了原本的全量消息但替代本身可能引入偏差或事实错误。如果摘要生成过程中 Claude 漏掉了某条约束后面它就可能基于错误的前提继续写代码。所以压缩之后的第一件事不是直接提新需求而是先把摘要复述给 Claude 确认一遍“请基于这份摘要列出当前项目状态并指出有哪些不确定项。”3. 手动压缩上下文的完整操作流程逐个环节拆给你看在讲具体案例之前我先把自己常用的压缩流程完整展开。这套流程不依赖特定插件或特殊命令在一普通的聊天会话窗口里就能执行。3.1 第一步确认压缩时机什么时候该压缩我的判断标准是三条。第一当你发现 Claude 开始重复询问已经确认过的问题时第二当你发现自己需要翻很久之前的一条消息去核对某个决策时第三当一次回复的等待时间明显变长、且单次回复的输入 token 已经逼近窗口上限时。这几条里最靠谱的是第二条。如果你本人都需要翻历史说明上下文已经膨胀到无法高效检索的状态了。继续硬撑下去只会让模型输出质量进一步下降因为它的注意力被大量低价值历史分散了。3.2 第二步主动引导生成高质量摘要确认需要压缩后我会直接发送一条消息让 Claude 先产出现状总结。我给它的模板大致是这样的先不要继续写代码。请阅读我们到目前为止的全部对话然后输出一份项目状态总结。总结必须包含 1. 项目目标和核心架构 2. 已完成功能清单 3. 当前正在开发的功能以及进度 4. 最近一次修改涉及的文件和改动内容 5. 当前存在的阻塞问题、未验证的假设 6. 使用的关键技术栈和版本 7. 下一步建议 请控制在 800 字以内用结构化列表输出。这一步非常关键因为摘要的生成发生在完整上下文中质量最高。不要在已经截断历史之后再去生成摘要那时候已经晚了。3.3 第三步冷启动新会话并嵌入摘要如果是在同一个会话里执行压缩需要按照工具规则手动清空历史或调整上下文配置。但更稳妥的做法是把它当成一次“受控交接”直接把生成的摘要复制出来新开一个会话把摘要粘贴为第一轮用户消息然后紧接着发送一句“基于以上项目状态我们继续。首先请指出你认为当前最需要处理的问题。”这种做法的好处是彻底摆脱旧会话里那些压缩后可能残留的尾部消息干扰让新会话的上下文完全从摘要开始构建。代价是你需要自行判断摘要完整度是否足够。实际项目中我会这样做在新会话开头再追问一次“当前项目还缺什么关键信息请在回答前先列出你不知道的部分”如果摘要生成时遗漏了什么这一步通常能暴露出来。3.4 第四步压缩后立即做一次状态校验压缩不是终点校验才是。新会话开始后不要急着让它写新功能先出一份“基于摘要的现状描述”。比如让它重新描述当前项目里某个模块的代码结构、某个函数的输入输出约定然后与真实代码文件对照一下。如果它描述的和你代码里的状态吻合说明摘要质量过关如果已经开始出现偏差就得及时把真实代码贴给它修正基座信息。这步听起来多一次往返但实际上能省下后面大量返工。我试过太多次压缩完直接要求写新功能结果它基于不完整的摘要开始改动旧模块最后甚至把已实现的功能改出了 bug。先校验、再开发这条纪律一定要遵守。4. 一个 Vibe Coding 案例从“聊天写码”到“压缩续写”的完整记录为了把上面的流程落到具体场景里我完整记录一个我最近做的模拟项目 X。这个项目是一个内部工具类的跨平台脚本主要功能是批量读取一批配置文件、执行规则校验、输出统一格式的检查报告。需求是我用聊天方式一点点喂给 Claude 的典型的 Vibe Coding 节奏。4.1 前 40 轮需求逐步细化上下文开始膨胀最开始我给的描述很模糊“写一个能检查配置文件格式的工具。”随后 20 多轮里我逐步补充了支持的字段类型、校验规则、输出格式、错误分类等。过程中 Claude 帮我设计了数据模型写了一个规则引擎模块又增加了对不同操作系统的路径兼容处理。到第 35 轮左右对话已经变得非常长。我说“把错误码改成三段式”它能理解指的是哪个字段但当我继续讨论“再加一个扩展规则”时它开始把新规则塞进旧的错误码体系里明显是已经忘记我之前定义的三段式结构包含哪些段。我意识到上下文窗口已经在挤压早期细节了。4.2 手动压缩执行过程我实际发出的指令与结果我在第 38 轮发出了压缩指令要求它输出结构化摘要。当时我用的指令基本就是第 3 节里的模板额外补了一条“重点标注规则引擎模块的类名和校验入口函数”。因为我知道这两个信息是后续扩展时最容易被忘记的。Claude 输出的摘要包含了一段非常紧凑的架构说明项目的核心入口、校验流程的调用链、四个预设规则类的位置、错误码三段式定义、当前测试未覆盖的两个边界条件以及下一步建议增加的规则类型。这段摘要大概 600 字左右但覆盖度确实很高。然后我新开了一个会话把摘要作为首条消息粘贴进去。紧接着发送了校验指令“请列出规则引擎中三个主要方法的名字以及它们各自接收的参数类型。”实际上它从摘要里无法完整推测出方法签名因为摘要里只写了类名和功能描述。这是预期之中的正好说明压缩后哪些信息缺失了方法签名、参数类型这些细节不会自动出现在摘要里除非你明确要求。4.3 压缩后如何“续写”而不翻车发现签名缺失后我没有直接让 Claude 猜而是把关键的规则引擎文件内容粘贴到新会话里然后说“这是当前规则引擎实现请基于摘要继续设计新增的扩展规则。”这一步非常关键——摘要负责提供全局地图而代码片段负责提供地面细节两者组合之后 Claude 才真正具备继续开发的条件。随后的开发进程非常顺利。我继续以聊天的方式提出新需求例如“再支持一种配置来源”每一步它都能准确回到项目架构的大框架里执行没有再把旧设计推翻。从压缩点之后我们又连续进行了 60 多轮对话整体质量保持稳定。对比压缩前那种频繁上下文错乱的状态这次压缩成功地把项目推进到了完整可用的第一阶段。5. 常见问题与排查技巧实录压缩上下文时的实战避坑表实际操作中我积累了一些常见的坑和对应的处理方式整理成速查表放在这里每一项都来自真实踩踏。5.1 常见问题速查表问题现象根因分析处理建议压缩后模型忘记某个关键配置项摘要未覆盖该配置原始消息已被清空在生成摘要前明确要求包含配置项清单压缩后先校验再继续压缩后模型对代码结构理解偏差摘要描述过于高层未包含模块名和函数签名压缩后主动补充贴出关键源文件以代码为准重新校准压缩后模型建议方案与早期决策矛盾摘要中缺失决策理由生成摘要时追加“记录关键决策及其原因”字段摘要生成时遗漏某条约束导致后续实现跑偏摘要生成器优先关注最新消息早期约束被忽略发送摘要生成指令时把已知的硬约束单独列出要求逐条确认同会话压缩后仍然出现上下文污染尾部原始消息保留过多摘要未能真正主导干脆新开会话只粘贴摘要和必要的近期代码片段压缩过程花费大量 token整体成本没有下降摘要生成需要重新处理全部历史合理评估压缩时机在窗口将满前执行更划算5.2 实操中我最看重的三个心得第一生成摘要时一定要在指令里给出明确的“必含清单”。如果你不说Claude 会倾向于总结那些最近的话题而不是均匀覆盖全部历史。一次好的摘要指令应该像面试官手里的评分表逐项卡点。第二压缩后不要急着继续写功能先做一轮“信息缺口检查”。我的做法是让 Claude 先列出一份“为了继续完成 X 我还需要知道什么”的清单然后逐项喂给它。这个方法本质上是在和摘要的信息丢失风险赛跑把缺口填补在原问题放大之前。第三在 Vibe Coding 长会话里不要把压缩当成补救措施而要当成常规节奏。我现在的习惯是每完成一个功能模块就做一次压缩交接让对话窗口永远保持轻盈。这样做之后Claude 的输出质量明显更稳定单轮回复速度也更快长期体验远超那种硬撑着不压缩的方式。6. 关于压缩边界与摘要质量的进阶思考压缩行为看似简单但边界条件的处理很影响最终效果。我最后想聊几个容易被忽视的进阶问题包括摘要冗余度、压缩指令的措辞、以及多文件项目中如何利用摘要做跨模块导航。6.1 摘要并非越短越好冗余度需要刻意控制如果你要求 Claude 把整个项目状态压缩到一百字以内它往往会丢掉具体模块名和文件路径只留下非常通用的描述。反之如果完全不加字数限制它可能生成上千字的摘要压缩的意义就削弱了。我实际测试下来八百字左右是一个不错的平衡点足够包含架构描述、模块清单、当前焦点、风险项又不至于让新会话在阅读摘要时消耗太多 token。还有一个细节摘要里尽量保留少量的“冗余”信息特别是那些不常用但一旦用到就很关键的内容比如某个全局常量的命名规则、某个配置文件的默认路径。这类信息在长对话早期很容易被遗忘但它们在后期改需求时经常忽然变得重要。6.2 压缩指令的措辞直接影响摘要覆盖方向同样的对话如果你只写“请总结我们讨论过什么”得到的摘要多半是叙事式的流水账。但如果你写“请输出项目当前状态报告侧重于架构、数据流、任务进度、开放问题”得到的摘要就会更偏向工程决策状态。我在第 3 节给的模板里其实已经包含了这种导向但具体措辞还可以进一步定制。比如你正在做调试型会话那摘要应该侧重“最近排查的 bug、已经排除的可能性、尚未验证的假设”如果你正在做功能开发那摘要应该侧重“已完成功能列表、当前模块扩展点、预期改动影响范围”。你要让 Claude 知道你接下来要在什么模式下工作它才能把摘要调到对应的频道上。6.3 多文件项目中的摘要导航价值在多文件项目里手动压缩后一个新会话天然的劣势是它没有真实文件系统的记忆。而摘要可以在某种程度上充当项目地图它告诉你大概有哪些模块分布在什么位置、模块之间如何调用、当前焦点在哪个文件。当你需要让 Claude 理解一个新的改动时你可以基于摘要指路再配合贴出相关代码片段它就能迅速建立上下文。我用一个类比来总结摘要是一条主干道上的路标代码片段是路标指向的具体建筑物。只有路标没有建筑模型知道方向但不知道里面长什么样只有建筑没有路标模型会迷路。手动压缩的真正目的就是让你能随时为新会话构建一套“路标 建筑”的组合。我个人在实际操作中的体会是压缩上下文的能力某种意义上是长对话项目能不能持续做下去的胜负手。Vibe Coding 玩法再舒服如果上下文管理跟不上项目做到后期基本上就是在和模型的失忆作斗争。反过来把压缩动作变成一种习惯性流程你就能以一个非常轻量的方式持续数周推进同一个项目而每轮对话都像刚开始合作那样清晰。希望这篇内容能帮你在自己的项目里少踩点坑。
我最近一直在写一个追求“一次对话干到底”的独立项目代码量从几百行涨到上千行之后我和 Claude 的对话窗口明显有点跟不上了。每次聊到一半它开始忘记函数签名、忘记刚讨论过的数据结构甚至把上一轮已经改掉的设计又翻了回来。这种情况下最直接的办法就是手动执行一次上下文压缩把那些已经聊透的细节折叠成一份更精炼的摘要然后继续干活。这篇博文我想把“手动执行 Claude 压缩上下文后到底保留了什么”这件事彻底讲清楚。我会拆解压缩的工作原理列出哪些内容会被完整保留、哪些会被丢弃再结合一个真实的 Vibe Coding 案例展示压缩前后对话状态的变化以及怎么压缩才能最大程度保住有效信息。无论你正在做长会话的代码生成、重构、还是多文件项目开发这篇都能给你一套可以直接抄的上下文管理思路。1. 为什么需要手动压缩上下文它到底在解决什么问题Claude 的上下文窗口是有限的这个限制决定了单次对话不可能无限承载所有历史信息。窗口满了之后有两种典型表现一种是 Claude 开始忽略早期消息里的关键约束因为它已经“看”不到那么远另一种是输入成本急剧上升每多传一轮历史模型需要重新处理一遍全部前缀内容延迟和费用都跟着涨。所谓“手动执行压缩上下文”本质上是把一大段历史对话视为原材料提取一份精炼的核心状态然后用这份状态替换掉原始对话继续聊。压缩不是让 Claude 失忆而是让它把注意力重新聚焦在真正重要的事实上。你可以把它理解为开会时整理会议纪要不追求逐字保留每个人说了什么只追求下一个接手的人拿到纪要知道当前结论、待办事项和遗留风险就能无缝继续推进。在 Vibe Coding 场景里这种压缩特别刚需。Vibe Coding 的特点是你在一个节奏里持续提出模糊需求让 AI 不断给出代码、改动、解释会话很容易变成几百轮的长对话。早期聊过的设计决策往往决定了后面每一行代码的走向一旦这些信息被窗口挤掉AI 就会开始频繁“失忆”。手动压缩的意义就在于你主动决定哪些早期信息必须留下而不是被动等着窗口把信息挤走。压缩本身不是 Claude 的隐藏功能它更像是一种使用技巧。你可以选择把当前整段对话复制出来粘贴到一个新对话里也可以使用工具中内置的 summarize 命令或者分块摘要的方式把历史记录浓缩成一段结构化的状态描述。核心动作都一样让 Claude 自己在“读史”之后产出一份摘要然后你们基于这份摘要继续而不是基于原始记录继续。2. 压缩到底保留了什么结构、摘要、系统约束与被忽略的原始消息手动压缩之后对话窗口里余下的元素其实可以拆成几个层次。理解了这些层次你就能判断压缩结果是否真正可用。2.1 系统提示与环境说明是完整保留的无论你怎么压缩历史消息模型基础的系统提示通常不会动。这包括它自身的角色设定、回答规范、安全边界以及某些运行环境注入的上下文。比如你在 Claude 工程环境中执行压缩它会继续知道当前目录结构、可能的工具调用约定、输出格式偏好。这些内容不属于普通对话历史它们更像“永久记忆”压缩掉对话轮次并不会影响这一层。我在实际项目中验证过压缩后它仍然知道当前项目名、仍然会用我习惯的代码风格回答问题这让我确信环境描述在压缩前后是被继承下来的。你需要关心的、真正会被压缩动作影响的其实是那些在一次又一次问答中产生的中间状态。2.2 摘要部分是你手工压缩后唯一需要信任的“记忆”所谓保留了什么核心就是保留了一份放在对话历史最前面的摘要。这份摘要长什么样完全取决于你怎么引导 Claude 生成它。我会在压缩前给出这样的指令“请阅读我们整个对话过程然后用 500 字以内的篇幅总结目前项目的核心架构、已实现功能、当前正在处理的模块、尚未解决的问题、最近几次修改的关键决策以及你建议下一步做的事情。”这种情况下Claude 产出的摘要会非常接近一份项目状态报告。它不再逐字保留某一次对话中某个具体函数的实现细节而是把这些细节浓缩成“支付模块已完成使用策略模式封装了三种支付渠道”。如果摘要里缺少某个信息那这个信息在压缩后的世界里就等于不存在了你需要靠新的提问把它重新补回来。这里有一个容易被忽略的关键点摘要的可靠程度取决于它的生成者和原始信息的距离。如果你在同一个对话里让 Claude 生成摘要它确实读过完整历史所以摘要的信息覆盖范围大概率是够的。但如果你自己手工从聊天记录里复制粘贴、或者用第三方脚本截取上下文则要慎重判断有没有遗漏关键约束。这就是我坚持“在同一个对话会话内执行压缩、而不是另开新对话”的原因。2.3 近期的原始消息通常会以尾部保留的方式继续存在很多上下文压缩方案并不是清空全部历史而是保留窗口结尾最近的一部分原始消息。具体保留多少取决于你用的压缩策略。比如某些工程化方案会保留最近 20 到 30 轮对话原文把更早的部分替换为摘要。这么做的理由是当前正在讨论的话题细节往往集中在尾部如果连尾部都被摘要化AI 就无法基于具体的代码片段进行精确修改。我采用的常见做法是“摘要置顶 尾部截留”手动把摘要插入到对话开头然后从某个时间点开始删除早于该时间点的历史仅保留当前最近的十几轮。这样执行之后再发送新消息Claude 既能看到摘要里的全局状态又能看到最近几轮里贴过的具体报错、代码段和修改意图。2.4 被压缩掉的原始消息与中间细节压缩最直接的代价就是原始消息被丢弃。那些中间过程里讨论过的废弃方案、尝试过但不生效的配置、中间输出的一堆报错堆栈、甚至你自己打了一半的模糊提问这些在压缩之后都不会再被模型看到。有些细节丢掉并不可惜比如反复尝试同一配置的多个版本但有些细节丢掉就很危险比如某个关键的第三方库版本号、某一次运行输出里的精确错误码。这些信息如果在摘要里没有出现那压缩就等于造成了一次信息丢失。因此每次压缩之前我都建议先追问一句摘要里是否需要包含当前使用的依赖版本列表、最近一次失败的具体报错。压缩也不是零成本的。它只是用一个更紧凑的表征替代了原本的全量消息但替代本身可能引入偏差或事实错误。如果摘要生成过程中 Claude 漏掉了某条约束后面它就可能基于错误的前提继续写代码。所以压缩之后的第一件事不是直接提新需求而是先把摘要复述给 Claude 确认一遍“请基于这份摘要列出当前项目状态并指出有哪些不确定项。”3. 手动压缩上下文的完整操作流程逐个环节拆给你看在讲具体案例之前我先把自己常用的压缩流程完整展开。这套流程不依赖特定插件或特殊命令在一普通的聊天会话窗口里就能执行。3.1 第一步确认压缩时机什么时候该压缩我的判断标准是三条。第一当你发现 Claude 开始重复询问已经确认过的问题时第二当你发现自己需要翻很久之前的一条消息去核对某个决策时第三当一次回复的等待时间明显变长、且单次回复的输入 token 已经逼近窗口上限时。这几条里最靠谱的是第二条。如果你本人都需要翻历史说明上下文已经膨胀到无法高效检索的状态了。继续硬撑下去只会让模型输出质量进一步下降因为它的注意力被大量低价值历史分散了。3.2 第二步主动引导生成高质量摘要确认需要压缩后我会直接发送一条消息让 Claude 先产出现状总结。我给它的模板大致是这样的先不要继续写代码。请阅读我们到目前为止的全部对话然后输出一份项目状态总结。总结必须包含 1. 项目目标和核心架构 2. 已完成功能清单 3. 当前正在开发的功能以及进度 4. 最近一次修改涉及的文件和改动内容 5. 当前存在的阻塞问题、未验证的假设 6. 使用的关键技术栈和版本 7. 下一步建议 请控制在 800 字以内用结构化列表输出。这一步非常关键因为摘要的生成发生在完整上下文中质量最高。不要在已经截断历史之后再去生成摘要那时候已经晚了。3.3 第三步冷启动新会话并嵌入摘要如果是在同一个会话里执行压缩需要按照工具规则手动清空历史或调整上下文配置。但更稳妥的做法是把它当成一次“受控交接”直接把生成的摘要复制出来新开一个会话把摘要粘贴为第一轮用户消息然后紧接着发送一句“基于以上项目状态我们继续。首先请指出你认为当前最需要处理的问题。”这种做法的好处是彻底摆脱旧会话里那些压缩后可能残留的尾部消息干扰让新会话的上下文完全从摘要开始构建。代价是你需要自行判断摘要完整度是否足够。实际项目中我会这样做在新会话开头再追问一次“当前项目还缺什么关键信息请在回答前先列出你不知道的部分”如果摘要生成时遗漏了什么这一步通常能暴露出来。3.4 第四步压缩后立即做一次状态校验压缩不是终点校验才是。新会话开始后不要急着让它写新功能先出一份“基于摘要的现状描述”。比如让它重新描述当前项目里某个模块的代码结构、某个函数的输入输出约定然后与真实代码文件对照一下。如果它描述的和你代码里的状态吻合说明摘要质量过关如果已经开始出现偏差就得及时把真实代码贴给它修正基座信息。这步听起来多一次往返但实际上能省下后面大量返工。我试过太多次压缩完直接要求写新功能结果它基于不完整的摘要开始改动旧模块最后甚至把已实现的功能改出了 bug。先校验、再开发这条纪律一定要遵守。4. 一个 Vibe Coding 案例从“聊天写码”到“压缩续写”的完整记录为了把上面的流程落到具体场景里我完整记录一个我最近做的模拟项目 X。这个项目是一个内部工具类的跨平台脚本主要功能是批量读取一批配置文件、执行规则校验、输出统一格式的检查报告。需求是我用聊天方式一点点喂给 Claude 的典型的 Vibe Coding 节奏。4.1 前 40 轮需求逐步细化上下文开始膨胀最开始我给的描述很模糊“写一个能检查配置文件格式的工具。”随后 20 多轮里我逐步补充了支持的字段类型、校验规则、输出格式、错误分类等。过程中 Claude 帮我设计了数据模型写了一个规则引擎模块又增加了对不同操作系统的路径兼容处理。到第 35 轮左右对话已经变得非常长。我说“把错误码改成三段式”它能理解指的是哪个字段但当我继续讨论“再加一个扩展规则”时它开始把新规则塞进旧的错误码体系里明显是已经忘记我之前定义的三段式结构包含哪些段。我意识到上下文窗口已经在挤压早期细节了。4.2 手动压缩执行过程我实际发出的指令与结果我在第 38 轮发出了压缩指令要求它输出结构化摘要。当时我用的指令基本就是第 3 节里的模板额外补了一条“重点标注规则引擎模块的类名和校验入口函数”。因为我知道这两个信息是后续扩展时最容易被忘记的。Claude 输出的摘要包含了一段非常紧凑的架构说明项目的核心入口、校验流程的调用链、四个预设规则类的位置、错误码三段式定义、当前测试未覆盖的两个边界条件以及下一步建议增加的规则类型。这段摘要大概 600 字左右但覆盖度确实很高。然后我新开了一个会话把摘要作为首条消息粘贴进去。紧接着发送了校验指令“请列出规则引擎中三个主要方法的名字以及它们各自接收的参数类型。”实际上它从摘要里无法完整推测出方法签名因为摘要里只写了类名和功能描述。这是预期之中的正好说明压缩后哪些信息缺失了方法签名、参数类型这些细节不会自动出现在摘要里除非你明确要求。4.3 压缩后如何“续写”而不翻车发现签名缺失后我没有直接让 Claude 猜而是把关键的规则引擎文件内容粘贴到新会话里然后说“这是当前规则引擎实现请基于摘要继续设计新增的扩展规则。”这一步非常关键——摘要负责提供全局地图而代码片段负责提供地面细节两者组合之后 Claude 才真正具备继续开发的条件。随后的开发进程非常顺利。我继续以聊天的方式提出新需求例如“再支持一种配置来源”每一步它都能准确回到项目架构的大框架里执行没有再把旧设计推翻。从压缩点之后我们又连续进行了 60 多轮对话整体质量保持稳定。对比压缩前那种频繁上下文错乱的状态这次压缩成功地把项目推进到了完整可用的第一阶段。5. 常见问题与排查技巧实录压缩上下文时的实战避坑表实际操作中我积累了一些常见的坑和对应的处理方式整理成速查表放在这里每一项都来自真实踩踏。5.1 常见问题速查表问题现象根因分析处理建议压缩后模型忘记某个关键配置项摘要未覆盖该配置原始消息已被清空在生成摘要前明确要求包含配置项清单压缩后先校验再继续压缩后模型对代码结构理解偏差摘要描述过于高层未包含模块名和函数签名压缩后主动补充贴出关键源文件以代码为准重新校准压缩后模型建议方案与早期决策矛盾摘要中缺失决策理由生成摘要时追加“记录关键决策及其原因”字段摘要生成时遗漏某条约束导致后续实现跑偏摘要生成器优先关注最新消息早期约束被忽略发送摘要生成指令时把已知的硬约束单独列出要求逐条确认同会话压缩后仍然出现上下文污染尾部原始消息保留过多摘要未能真正主导干脆新开会话只粘贴摘要和必要的近期代码片段压缩过程花费大量 token整体成本没有下降摘要生成需要重新处理全部历史合理评估压缩时机在窗口将满前执行更划算5.2 实操中我最看重的三个心得第一生成摘要时一定要在指令里给出明确的“必含清单”。如果你不说Claude 会倾向于总结那些最近的话题而不是均匀覆盖全部历史。一次好的摘要指令应该像面试官手里的评分表逐项卡点。第二压缩后不要急着继续写功能先做一轮“信息缺口检查”。我的做法是让 Claude 先列出一份“为了继续完成 X 我还需要知道什么”的清单然后逐项喂给它。这个方法本质上是在和摘要的信息丢失风险赛跑把缺口填补在原问题放大之前。第三在 Vibe Coding 长会话里不要把压缩当成补救措施而要当成常规节奏。我现在的习惯是每完成一个功能模块就做一次压缩交接让对话窗口永远保持轻盈。这样做之后Claude 的输出质量明显更稳定单轮回复速度也更快长期体验远超那种硬撑着不压缩的方式。6. 关于压缩边界与摘要质量的进阶思考压缩行为看似简单但边界条件的处理很影响最终效果。我最后想聊几个容易被忽视的进阶问题包括摘要冗余度、压缩指令的措辞、以及多文件项目中如何利用摘要做跨模块导航。6.1 摘要并非越短越好冗余度需要刻意控制如果你要求 Claude 把整个项目状态压缩到一百字以内它往往会丢掉具体模块名和文件路径只留下非常通用的描述。反之如果完全不加字数限制它可能生成上千字的摘要压缩的意义就削弱了。我实际测试下来八百字左右是一个不错的平衡点足够包含架构描述、模块清单、当前焦点、风险项又不至于让新会话在阅读摘要时消耗太多 token。还有一个细节摘要里尽量保留少量的“冗余”信息特别是那些不常用但一旦用到就很关键的内容比如某个全局常量的命名规则、某个配置文件的默认路径。这类信息在长对话早期很容易被遗忘但它们在后期改需求时经常忽然变得重要。6.2 压缩指令的措辞直接影响摘要覆盖方向同样的对话如果你只写“请总结我们讨论过什么”得到的摘要多半是叙事式的流水账。但如果你写“请输出项目当前状态报告侧重于架构、数据流、任务进度、开放问题”得到的摘要就会更偏向工程决策状态。我在第 3 节给的模板里其实已经包含了这种导向但具体措辞还可以进一步定制。比如你正在做调试型会话那摘要应该侧重“最近排查的 bug、已经排除的可能性、尚未验证的假设”如果你正在做功能开发那摘要应该侧重“已完成功能列表、当前模块扩展点、预期改动影响范围”。你要让 Claude 知道你接下来要在什么模式下工作它才能把摘要调到对应的频道上。6.3 多文件项目中的摘要导航价值在多文件项目里手动压缩后一个新会话天然的劣势是它没有真实文件系统的记忆。而摘要可以在某种程度上充当项目地图它告诉你大概有哪些模块分布在什么位置、模块之间如何调用、当前焦点在哪个文件。当你需要让 Claude 理解一个新的改动时你可以基于摘要指路再配合贴出相关代码片段它就能迅速建立上下文。我用一个类比来总结摘要是一条主干道上的路标代码片段是路标指向的具体建筑物。只有路标没有建筑模型知道方向但不知道里面长什么样只有建筑没有路标模型会迷路。手动压缩的真正目的就是让你能随时为新会话构建一套“路标 建筑”的组合。我个人在实际操作中的体会是压缩上下文的能力某种意义上是长对话项目能不能持续做下去的胜负手。Vibe Coding 玩法再舒服如果上下文管理跟不上项目做到后期基本上就是在和模型的失忆作斗争。反过来把压缩动作变成一种习惯性流程你就能以一个非常轻量的方式持续数周推进同一个项目而每轮对话都像刚开始合作那样清晰。希望这篇内容能帮你在自己的项目里少踩点坑。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
