上节课我们把 Claude Code 装好、跑通第一次让它帮忙改了一个小 bug 的时候那种“程序员被 AI 接管”的兴奋感我到现在还记得。但差不多用了两周之后我开始意识到一个问题这工具爽是真的爽脏也是真的脏。这里的“脏”指的是它留在你项目里、配置里、账单里的各种尾迹——堆积的会话上下文、写进全局目录的配置文件、失控的缓存策略、卸载后还赖着不走的残留项。所以我把这个系列的第二课取名叫“把屁股擦干净”说到底Claude Code 这种带状态、带缓存、带计费的 AI 编程工具除了“会用”更关键的是“会收尾”。这一课不讲怎么装、怎么跑讲的是怎么让会话不失控、让账单不暴涨、让配置不残留让一台机器在折腾完 Claude Code 之后还能干干净净还给你。如果你是刚接触 Claude Code 的新手或者已经用了几天但隐约觉得“哪里不对劲”这篇就是给你准备的。下面所有内容都是我实际踩过的坑和验证过的处理方案不保证官方文档里都有但保证是能直接照着操作的。1. Claude Code 用久了为什么会“脏”四样东西在悄悄拖垮你的会话和账单先说结论Claude Code 本身不是一个“用完即走”的终端工具它会在本地留下会话历史、配置快照、缓存记录和任务文件同时每一次对话都会带着越来越长的历史上下文去请求模型。这四样东西叠加起来就是你感觉它“越用越慢、越用越贵、越想卸越难卸”的根本原因。1.1 会话历史不是免费的你的账单在后台悄悄变胖我见过很多人的使用习惯是这样的一个会话从早上开起来就不关中间让它改了 A 文件下午又让它看 B 模块晚上还让它复盘 C 报错。表面上看这是一个连贯的对话挺方便。但问题在于Claude Code 每次向模型发起请求时会把当前会话的完整历史——包括最早的几条系统消息、你贴过的每段代码、它每次的长篇回复——全部作为输入 token 发给模型。这意味着什么你每多聊一句下一次请求的输入体积就大一圈。如果会话里贴过几个大文件的完整内容几轮对话之后单次请求的输入 token 轻松上万。而大语言模型的计费逻辑里输入 token 虽然单价低但架不住量大。等到你某天收到账单发现一个下午“聊聊天”就烧掉了平时一周的额度不用惊讶八成就是这个原因。更隐蔽的是很多热门话题里提到的“等几个小时之后再继续同一个会话耗费大涨”本质也和会话历史有关。后面我会专门用一整节讲缓存机制这里你先记住一条红线会话越长单价越贵跨时间的会话贵得离谱。1.2 配置残留、缓存膨胀与模型上下文的三重夹击除了会话历史还有三样东西会持续“弄脏”你的使用环境。第一配置残留。你可能会因为某个项目临时加了一堆 MCP server、改了权限白名单、设了自定义指令这些配置会写进~/.claude目录和项目的.claude/settings.json里。用完之后如果不清理下次开项目时 Claude Code 会继续加载这些过期配置轻则干扰正常行为重则让模型拿着旧权限乱改文件。第二缓存膨胀。Claude Code 为了提升响应速度会在本地保存一些会话摘要、命令历史、统计信息这些文件平时不起眼但如果你频繁试错、反复改配置这些缓存文件会越堆越大甚至影响启动速度和稳定性。第三模型上下文超限。这一点在热门搜索里出现频率极高比如api error: 400 this models maximum context length is 10485。这就是典型的“上下文塞爆”报错——你喂给模型的内容已经超过了当前模型的上下文窗口上限。它不是你网络有问题也不是 API key 有问题就是你该“擦屁股”了。正因为这三重夹击Claude Code 的“清理能力”不是加分项而是必选项。2. 会话清理实操/clear、/compact 和“任务分片”的正确打开方式聊完了“为什么会脏”接下来直接上实操。Claude Code 的会话清理有两个最核心的交互命令/clear和/compact。很多人分不清这两个东西或者干脆不知道它们的存在结果就是靠“关掉终端重开”来硬扛其实完全没必要。2.1 /clear 和 /compact 的区别以及什么时候该用哪个/clear的作用是清空当前会话的上下文但不会退出程序。执行之后之前的对话历史从记忆里抹掉模型不再记得你贴过的代码和它给过的建议。这个命令适合“这个任务已经干完了我要开个新任务”的场景。/compact则不一样它会把当前会话的长历史压缩成一段摘要然后用摘要替代原始对话继续保留上下文。简单说就是“把几千行废话浓缩成几行要点”让模型既保留必要的来龙去脉又不至于被完整历史拖垮。理解这两者的区别非常重要。我用一个生活化类比/clear是换一张白纸重新开始/compact是把会议记录浓缩成会议纪要保留关键结论但丢掉原始逐字稿。那么什么时候用哪个我的建议是任务边界清晰、已经完成直接/clear别留恋历史。任务还在进行中但上下文明显变得冗长、模型开始“忘记”早期需求先/compact。每次开会话之前先问自己这个会话要解决什么问题一旦问题切换立刻/clear。有些人可能担心/clear之后会不会弄丢重要的输出。放心Claude Code 的会话历史仍然以 JSONL 文件形式存在本地后面讲配置文件时会提到你随时可以去翻但模型的“记忆”确实被清空了。2.2 用会话分片和任务拆分让每次对话都轻装上阵除了会用命令更重要的是建立“会话分片”的使用习惯。我见过最高效的 Claude Code 用户几乎都是“一个会话只干一件事”的人。举个例子如果你要改一个 Java 项目需要实现一个新接口、修一个老 bug、再跑一遍重构。我的做法是拆成三个会话会话一只聊新接口的需求和实现方案写完代码并验证后/clear。会话二只贴老 bug 的报错和相关文件定位并修复后/clear。会话三专门重构此时上下文里不需要前面两个会话的任何信息。这么做有两大好处第一每一轮请求的输入 token 都被控制在合理范围不会出现只改一个 bug 却要把整个项目历史都重发一遍的窘境第二模型不会被无关信息干扰回答质量明显更高因为它的注意力全在眼前这一件事上。我知道有人会觉得频繁开新会话很麻烦但说句实在话把会话当成一次性的工作台用完就收拾这恰恰是 Claude Code 最正确的打开方式。你给它喂什么它就在什么层面上工作你给它喂一堆垃圾上下文它给你的就是一堆稀释过的答案。3. 计费暴涨的元凶prompt caching 机制与 enable_prompt_caching_1h1 的真实作用这一节我想把“为什么一个会话等待几个小时之后耗费会大涨”这件事彻底讲透。这是我在社区里被问得最多的问题之一也直接关系到你能不能用得起 Claude Code。3.1 prompt caching 的工作原理以及缓存档位怎么选要理解“等待几小时之后费用大涨”必须先理解 Claude 系列模型 API 的 prompt caching提示缓存机制。大模型计费里输入 token 是成本的大头之一。如果一个会话很长你每次请求都要把完整历史重新发一遍这个成本会高得吓人。为了缓解这个问题API 服务商设计了缓存机制对于连续请求中重复出现的“相同前缀”内容服务端会缓存一份后面再请求时命中缓存的部分按折扣价计费没有命中缓存的部分才按原价计费。具体到 Claude 的缓存策略最常见的是两个档位5 分钟缓存和 1 小时缓存。5 分钟缓存适合“短时间内频繁往返”的场景比如你连着给它下几条指令1 小时缓存适合“可能隔半小时、一小时再回来继续”的场景。缓存的写入本身有额外开销命中后读取会便宜很多大致逻辑是写入稍微贵一点读取大幅便宜。更精确的计费系数我没法在这里给死因为各家模型和不同时段的官方定价都在变你只需要记住这个方向命中缓存输入成本会降到非常低缓存过期全部历史重新按原价计费。3.2 等了几小时再继续会话费用暴涨的完整推理链现在回到那个经典问题为什么一个会话等待几个小时之后耗费会大涨完整推理链是这样的你开了一个会话聊了很长时间历史里积累了大量 token可能有几万甚至十几万。你中途有事离开会话挂在那里几个小时甚至隔了一个晚上。等你回来继续发指令时Claude Code 会把完整历史再次作为输入发给模型。缓存机制是分时间档的。如果你的会话中断时间超过了缓存档位比如 1 小时缓存那么之前缓存过的内容已经失效。失效意味着什么意味着那几万 token 的历史内容全部按“首次输入”的原价重新计费而不是按便宜的“缓存命中”价计费。你看着“耗费大涨”不是模型变贵了也不是用量突然变多而是你亲手把缓存“熬过期了”所有历史重新按全价算了一遍。想避开这个坑只有三种做法要么在缓存有效期内回来继续比如设置 1 小时缓存中间离开别超过一小时。要么在离开前主动/compact把长历史压缩成摘要让下一轮请求的输入体积骤减。要么干脆/clear下次开新会话重新交代需求。虽然你需要花点时间重新描述但省下的钱远比你以为的多。3.3 enable_prompt_caching_1h1 到底开不开我的实测结论热门搜索里那个claude code export enable_prompt_caching_1h1的配置问的人特别多。这个配置的作用就是让 Claude Code 在请求时显式声明使用 1 小时缓存档位而不是默认的短缓存。我的实测结论是如果你经常在一个会话内连续工作且中途休息时间不超过一小时开启它是有正向价值的。因为它让缓存的有效期拉长你在一小时内的多次请求都能命中缓存输入成本被压得很低。反过来如果你每次会话都一口气干完中间根本不休息那开不开这个配置差别不大如果你习惯把会话挂好几天那开什么都没用因为任何缓存档位都救不了“跨天不清理”的使用习惯。另外提醒一点enable_prompt_caching_1h1这种配置不同版本、不同途径安装的 Claude Code写入方式可能略有差异。一种常见做法是把它作为环境变量在启动前 export另一种是在settings.json里配置。不要盲目照抄网上的命令先确认你的版本支持哪种方式改完最好发一条测试消息观察模型返回里的缓存字段有没有生效。4. 大扫除清单settings.json、~/.claude 目录与卸载后的残留清理如果说会话清理是“日常擦桌子”那这一节讲的就是“周末大扫除”。Claude Code 用得越久藏在配置文件和历史目录里的垃圾就越多。更要命的是很多人想卸载它的时候才发现怎么删都删不干净。下面我按“清理什么、怎么理、为什么这么理”给你一份完整清单。4.1 settings.json 里最常见的五类残留以及该怎么整理Claude Code 的配置文件主要有两个位置全局的用户配置在~/.claude/settings.json项目级配置在项目目录下的.claude/settings.json。遇到问题先别急着删文件先搞清楚里面存了什么。我打开过无数份“脏”配置最常见的残留大概这五类权限白名单残留之前为某个项目放行过一堆工具文件读取、命令执行等项目做完了白名单还在其他项目也会受影响。检查permissions节点把不再需要的工具从 allow 列表里删掉。环境变量残留有人为了接第三方模型或调缓存往配置里塞过env变量比如 API 地址、模型名、缓存开关。换项目之后忘了删导致新项目一直用旧的 API 配置。MCP server 残留试过各种插件服务mcpServers里躺着一堆早就没用的服务器地址每次启动 Claude Code 都要尝试连接拖慢启动速度。hooks 和自定义指令残留写过的命令钩子、格式化指令一旦不再需要就清掉否则它会默默影响每一次交互。历史会话索引残留有些版本会在配置目录里维护会话索引文件重装或长期使用后文件异常膨胀可以直接关闭程序后删除对应的缓存索引让它重建。整理的时候我的建议是先备份再精简。把settings.json复制一份到备份文件然后逐项检查。改完之后重新启动 Claude Code确认基础功能正常再继续下一步。不要一次性把所有配置都删光那跟“重装系统”没什么区别反而容易丢东西。4.2 正确卸载 Claude Code 的完整步骤不只是删命令那么简单热门搜索里“claude code 怎么卸载”“claude code 卸载步骤”出现频率很高可见很多人被残留问题坑过。我直接给一套相对可靠的卸载流程覆盖命令行安装和桌面版的常见情况。第一步先退出所有正在运行的 Claude Code 进程。Windows 上可以打开任务管理器找到相关进程强制结束macOS/Linux 上可以用pkill命令结束终端里的进程。第二步卸载命令行工具本体。如果是通过 npm 安装的执行npm uninstall -g anthropic-ai/claude-code执行完可以用claude --version验证一下如果提示命令不存在说明本体已经移除。第三步清理配置目录。这是最容易被漏掉的一步也是“删不干净”的元凶。需要检查并删除的目录和文件大致包括~/.claude目录macOS/Linux%USERPROFILE%\.claude目录Windows~/.claude.json或%USERPROFILE%\.claude.json有些版本会把 MCP 配置存在这里项目目录下的.claude目录第四步检查环境变量。如果你在.zshrc、.bashrc或系统环境变量里配置过ANTHROPIC_API_KEY、CLAUDE_CODE_*之类的变量记得一并删除或注释掉不然即使工具卸载了变量还会留在环境里影响后续排查。第五步检查桌面端残留。新版桌面版依赖一些本地 WebView 组件和用户数据目录Windows 上注意检查AppData下的相关目录不能光卸载主程序就完事。这套流程走完基本可以达到“擦干净”的标准。如果你只是暂时不用不想卸载那至少也把配置目录备份到别处避免误删后要重新配一遍。4.3 清理 skill 和自定义技能的残留别让旧指令咬你一口这几年 Claude Code 社区流行往~/.claude/skills或项目.claude/skills里写各种自定义 skill技能包用来让模型记住特定操作流程。技能包本身是个好机制但很容易变成新的“垃圾场”。我见过有人一口气装了几十个社区 skill每次对话时模型要遍历这些指令既拖慢响应又可能因为指令冲突给出莫名其妙的行为。清理原则很简单只保留你现在真实在用的 skill其他一律移走。判断标准是这个 skill 在过去一周内有没有被你主动触发过没有就归档或删除。还有一个技巧skill 目录里的每个技能通常都是一个子目录里面放着指令文件和示例。找个时间把所有 skill 列出来每看一个就问自己一句“它解决了我什么问题”答不上来的直接删。这个动作不需要频繁做但每次做完Claude Code 的响应都会明显变清爽。5. 大型代码库里的“防脏”习惯权限白名单与上下文预算管理说完了清理“过去式”这一节聊聊“未来式”——怎么从一开始就让 Claude Code 不弄脏大项目。热门搜索里有“claude code 在大型代码库中的最佳实践”这个课题很大我只挑和“擦屁股”强相关的两块权限控制和上下文预算。5.1 别把整个仓库喂给 Claude用白名单约束读取范围有些人在大型 Java、STM32 嵌入式或前端项目里用 Claude Code习惯一上来就说“帮我看看这个项目”然后等着模型自己去翻整个仓库。这在小项目里没问题但在大型代码库里模型光扫描目录结构和读取无关文件就能把上下文窗口撑爆后面的真正任务反而干不了。正确的做法是“先圈范围再定义任务”。在settings.json的权限配置里尽量只放行需要访问的目录和工具比如只允许读取src下的代码不让它碰node_modules、build、dist这类无意义大目录。明确指定本次要修改的文件路径而不是让模型自己大海捞针。对Bash这类高风险工具设置成执行前需要确认而不是全自动放行。我用一个类比给 Claude Code 划权限范围就像给实习生安排工作。你只说“去把公司业务了解一下”他可能把整个资料库都翻一遍最后汇报你一堆没用的内容你明确说“去把这个模块的接口文档读一下总结调用方式”他才能真正帮上忙。5.2 大型代码库中的上下文预算分配先算账再动手在大型代码库里上下文窗口永远是最稀缺的资源尤其是接入第三方模型时不同模型的上下文上限差异很大。我的习惯是动手前先做一个简单的“预算分配”列出这个任务必须读的文件控制在一到三个以内。对于大文件不要整篇粘贴先让 Claude Code 读取文件结构或关键函数签名。把需求描述控制在尽量少的文字内用精确的路径和函数名代替“帮我看看那边的东西”。任务进行到一半发现上下文吃紧立刻/compact不要硬撑着继续。举个例子你在一个嵌入式 STM32 项目里要改某个外设驱动与其把整个驱动文件 2000 行都贴进去不如只贴报错片段和需要修改的函数体然后明确告诉它“这个函数现在要实现什么、不需要你关心其他部分”。这样做模型既拿得到关键信息又不会因为无关代码分心。这个习惯坚持下来你的 Claude Code 会在大型代码库里长时间保持“轻快”状态不太容易出现上下文撑爆的报错。6. 两个高频报错的擦屁股实录0x800 网络异常与 10485 上下文超限这一节写了具体的排查过程算是前面原理的一次集中应用。两个报错都是从热门搜索里挑出来、我实际处理过的问题“internetopenurl() failed”和“context length is 10485”。6.1 Windows 上报错 0x800 的完整排查链路很多人在 Windows 上用 Claude Code 时会遇到这样一个报错内容使用 CLI 执行此命令时发生意外错误: internetopenurl() failed. 0x800。这个报错看起来吓人但绝大多数情况下不是 Claude Code 本身坏了而是 Windows 的系统网络层出了问题。我的排查链路是固定的按顺序走命中率很高第一步确认不是偶发问题。直接重启终端再跑一次命令有时候只是临时网络抖动。第二步验证系统网络是否正常。打开浏览器访问几个常见网站如果浏览器也不正常那就不是 Claude Code 的问题先解决基础网络。第三步检查系统 Internet 选项里的连接设置。重点看是不是被第三方网络工具改乱了比如残留的 PAC 脚本、异常的手动连接配置。这一步最容易中招某个工具异常退出后系统网络设置没有还原WinINet 层发起请求时直接失败报错就是internetopenurl() failed。把连接设置恢复为自动检测再重试。第四步重置 Winsock 目录。在管理员权限的命令行里执行netsh winsock reset执行完重启系统。这个操作能清理掉很多损坏的网络协议配置是处理 Windows 网络类报错的老牌手段。第五步检查防火墙是否拦截了 Node.js 进程。Claude Code 的命令行工具本质上是 Node 进程某些安全软件会拦截它的外发请求。在防火墙设置里找到 Node.js 相关规则确认是允许状态。第六步如果仍然不行检查 WebView 相关组件的完整性。新版桌面版依赖本地 WebView 环境组件损坏会导致网络请求异常考虑更新或修复相关的运行时组件。这套流程走下来80% 的 0x800 报错都能解决。核心心得是遇到网络报错先别急着卸载重装Windows 的网络栈是分层的问题往往不在最上层的应用里而在中间某一层。6.2 10485 上下文超限报错的本质和立刻能用的三条对策另一个高频报错是api error: 400 this models maximum context length is 10485。理解这个报错只要抓住一句话你把太多内容塞进了模型的上下文窗口而这个窗口装不下了。10485 这个数字本身不是关键关键在于它说明当前模型可用的上下文空间已经用完。道理类似一个容量固定的行李箱你塞了一堆厚衣服进去还想再放一台笔记本电脑拉链当然拉不上。遇到这个报错立刻按顺序试三条对策第一条/clear开新会话。这是最粗暴但最有效的做法。把所有历史清掉重新用一个精简的描述告诉模型你要什么。代价是你要重新交代背景但换来的是清爽的上下文空间。第二条/compact压缩历史。如果你不想开新会话这条能保留核心上下文同时大幅压缩体积。压缩之后如果仍提示超限说明当前会话实在太“胖”了就回到第一条。第三条重新审视你喂进去的内容。你是不是一次性贴了太多文件是不是让模型读了一个超大的日志在大型代码库里这种情况尤其常见。把大文件裁剪成只包含关键部分的片段再喂通常立刻就能缓解。记得有一点要心里有数如果你通过配置接入了第三方模型那个模型的上下文窗口可能和 Claude 官方模型不一样同样的用量在不同模型上触发的报错节点也会不同。所以接入第三方模型后井井有条的会话清理习惯比什么都重要——因为你不能指望任何模型有无限大的肚子。处理完这一轮报错之后我再分享一个我这边的日常小习惯每天收工前固定花两分钟看一眼有没有挂着的会话、有没有残留的配置改动顺手/clear一遍。这个习惯不起眼但坚持下来你的 Claude Code 几乎不会出现需要“救火”的时刻。清洁不是一次大扫除而是一系列小动作的累积。