AI 编程工具变慢时，最顺手的动作往往是清缓存。但“发送后迟迟没有回复”“输入和滚动掉帧”“终端和索引卡住”，其实是三类不同的问题。把它们都当成缓存问题，通常只会多一次重启，少一份判断。
先看慢在哪：会话、客户端，还是本机
发送请求后很久才开始回复，更常见的是对话上下文过长、模型推理、网络或服务端排队；如果输入、滚动和切换面板都不流畅，才更像客户端渲染、扩展、GPU 缓存或本机资源紧张；终端、构建、文件索引本身慢，则应先怀疑项目进程、磁盘、内存和大范围扫描。
这个区分很重要。清缓存不会缩短服务端推理时间，也不能代替构建、索引或网络问题的排查。先准确描述现象，后面的动作才不会变成碰运气。
长会话变重时，交接后新开比硬撑更有效
一轮 AI 编程任务会逐渐积累聊天历史、项目规则、选中的文件、终端输出、工具结果和差异内容。材料越来越多时，模型更难抓住当前目标，客户端也要维护更多页面记录。
比较稳的做法是在任务完成或切换主题后新开会话，并留一段短交接：这次要完成什么、已经确认哪些事实、动过哪些文件、下一步验证什么。报错只保留关键栈帧和相关代码；大日志、大 JSON、整库导出先压缩成可复现的问题；让工具按需读取文件，不要一次性把整个项目塞进上下文。
这不是丢掉历史，而是把历史变成可复用的结论。下一轮从清晰的边界开始，往往比在旧线程里继续堆材料更快。
清缓存前，先做三个轻量动作
第一，用一个简短的新会话复现同一问题，确认它是不是只发生在旧任务里。第二，完全退出并重新打开客户端，而不是只关闭窗口，同时停止明显无关的构建、索引或浏览器标签页。第三，查看系统监控中的 CPU、内存压力、磁盘空间和异常占用进程。
如果机器已经因为内存交换变慢，或者某个构建进程持续占满 CPU，清缓存的收益会非常有限。相反，重开客户端后立即恢复时，也没有必要为了“彻底清理”去碰账号数据和应用支持目录。
缓存可以清，但别把应用数据一锅端
清缓存适合处理客户端界面长期异常、资源占用持续偏高、升级后显示错乱，或重启无法恢复的本地渲染问题。操作前先完全退出应用，只处理明确标为 Cache、Code Cache 或 GPUCache 的目录。
不要把 Application Support、Profiles、Session、Local Storage 一概删除。这些目录可能保存登录态、窗口状态、会话、扩展和本地数据；误删后可能需要重新登录、重新授权，甚至丢失尚未同步的状态。不同客户端的路径和目录名会变化，动手前应以当前应用设置、官方说明或系统目录中的实际名称为准。
清完缓存后首次启动稍慢并不意外，因为客户端需要重新生成索引和图形缓存。如果问题还在，就该回到“到底慢在哪”这个问题，而不是继续重复清理。
插件和项目范围也会制造假卡顿
同时启用多个插件、浏览器连接、远程工具和大范围文件搜索时，等待未必来自模型。可以先关闭非必要扩展，把搜索缩小到相关目录，减少并行终端任务，再看响应是否恢复。
代码仓库同样需要边界。依赖目录、构建产物、生成文件和大日志不该被每次都纳入检索；清晰的入口文档、忽略规则和验证命令，既让人更容易接手，也能减少工具读取无关内容的成本。
一次有效排查，要留下能复用的证据
别只记“今天有点卡”。至少记录发生时间、卡在输入还是请求、当时打开的项目与工具、系统资源占用、能否在新会话复现，以及重启或缩小范围后的变化。这样下次遇到同类问题，才可以判断它是某个项目、一次服务波动，还是客户端本机状态。
先分层，再处理：旧会话太重就交接后新开；客户端界面异常再考虑重启和缓存；本机资源紧张就先找占用。把这个顺序走清楚，清缓存才会是一个有依据的动作，而不是唯一的答案。
