跳到主要内容

Vibe Coding 里怎么清理缓存

很多人一遇到 AI 编码结果不对，就说“把缓存清了”。这句话只说对了一半。Vibe Coding 里的“缓存”不是一个东西，而是至少分成会话上下文缓存、工具缓存、构建缓存、浏览器缓存、依赖缓存 5 层。 不先分层，清缓存往往只是碰运气。

0. 面试速答（30 秒版 TL;DR）​

  • Vibe Coding 里“缓存脏了”，常见表现不是只有页面旧，而是 AI 继续沿用旧上下文、MCP 工具返回旧索引、构建产物没刷新、浏览器仍命中旧资源。
  • 更稳的处理顺序是：先定位是哪一层缓存，再只清那一层，不要一上来就删整个工程。
  • 常见 5 层：
    • 会话缓存：聊天上下文、历史指令、旧需求
    • 工具缓存：索引、embedding、文件快照、MCP server 状态
    • 构建缓存：.vite、.next/cache、.nuxt、dist
    • 浏览器缓存：HTTP 缓存、Service Worker、LocalStorage/IndexedDB
    • 依赖缓存：pnpm store、lockfile、node_modules
  • 原则是：最小化清理、逐层验证、保留可复用缓存。

1. 先建立心智模型：你清的不是“缓存”，而是“旧假设”​

Vibe Coding 最大的坑，不是缓存文件本身，而是系统还在沿用旧状态：

  • AI 还以为需求没变
  • 工具还以为仓库结构没变
  • 构建系统还在复用旧产物
  • 浏览器还在拿旧资源

所以“清缓存”的本质其实是：

  1. 去掉旧状态
  2. 让系统重新发现真实现状
  3. 用一次可验证的运行结果确认修复

如果你删完缓存，却没有重新验证，那只是把问题从“可见错误”换成“不可追踪错误”。

2. 五类缓存分别怎么判断​

2.1 会话缓存：AI 还在按旧需求回答​

常见信号：

  • 你已经改目标了，AI 还在继续旧实现
  • AI 一直引用已经删除的文件或组件
  • 需求边界明明收窄了，AI 还在扩大改动范围

处理方法：

  • 新开会话，而不是继续在很长的历史里补丁式纠正
  • 重新给出：
    • 当前目标
    • 可修改范围
    • 禁止修改范围
    • 验证命令

一句话记忆：会话缓存脏了，要重建任务上下文，不是删目录。

2.2 工具缓存：索引、上下文引擎、MCP Server 状态过期​

常见信号：

  • 工具搜不到刚新增的文件
  • 明明改了代码，AI 还是读到旧结构
  • MCP 工具连接正常，但返回内容明显滞后

处理方法：

  • 断开并重连相关工具
  • 重启对应 MCP Server
  • 触发重新索引
  • 必要时新开 IDE / agent 会话

这类问题的本质不是“模型记错”，而是模型拿到的上下文源已经过期。

2.3 构建缓存：代码改了，但运行结果还是旧的​

前端项目里最常见。

典型清理对象：

  • node_modules/.vite
  • .next/cache
  • .nuxt
  • .turbo
  • dist
  • build

常见做法：

rm -rf node_modules/.vite dist
pnpm start

如果是 Next.js / Nuxt / Turborepo，则针对对应目录清，不要“一把梭”。

2.4 浏览器缓存：本地页面一直拿旧资源​

常见信号：

  • 本地服务已经重新编译，但浏览器页面不更新
  • 刷新后仍看到旧 JS / CSS
  • PWA 或 Service Worker 项目里“怎么刷新都不对”

处理方法：

  • DevTools 勾选 Disable cache 后强刷
  • 清 Application -> Storage
  • 删除 Cache Storage
  • 注销 Service Worker
  • 必要时清 LocalStorage / IndexedDB

如果项目带 SW，不处理它，很多“缓存清不掉”的问题会一直循环。

2.5 依赖缓存：安装结果、包解析、锁文件状态异常​

常见信号：

  • 同一仓库在不同机器行为不一致
  • 明明升级了包，运行的还是旧版本
  • lockfile、store、node_modules 三者状态不同步

处理方法：

pnpm store prune
rm -rf node_modules
pnpm install

注意：这一步最重，应该放在最后，而不是默认第一步。

3. 一个更稳的排障顺序​

建议顺序：

  1. 先判断是不是 会话/工具层 的旧上下文
  2. 再判断是不是 构建层 的旧产物
  3. 再判断是不是 浏览器层 的旧资源
  4. 最后才动 依赖层 的重清理

原因很简单：

  • 前三层恢复成本低
  • 最后一层最慢，且副作用最大

4. 实战里最有用的一套清理清单​

当你不确定是哪层时，可以按下面的“从轻到重”顺序走：

第一步：重置上下文​

  • 新开聊天会话
  • 明确当前需求
  • 重启相关 agent / MCP 连接

第二步：重置前端运行态​

  • 关闭 dev server
  • 清项目构建缓存目录
  • 重新执行 pnpm start

第三步：重置浏览器状态​

  • 强制刷新
  • 清站点存储
  • 注销 Service Worker

第四步：重置依赖层​

  • 清包缓存
  • 删 node_modules
  • 重新安装依赖

5. 典型题 & 标准答法​

Q1：为什么清了浏览器缓存，AI 还是继续输出旧方案？​

答：

因为那不是浏览器缓存问题，而是会话缓存或工具缓存问题。浏览器只影响页面资源命中，不会自动重置模型已拿到的任务上下文。

Q2：为什么我改了代码，dev server 正常，但页面还是旧的？​

答：

优先排查两层：

  • 构建缓存没有失效
  • 浏览器或 Service Worker 仍在命中旧资源

Q3：什么时候才该删 node_modules？​

答：

当你怀疑依赖树、包缓存、lockfile 已经不一致时再删。它应该是后手，不是默认动作。

6. 常见误区​

  • 误区 1：一出问题就删全仓库缓存
    • 代价大，而且掩盖根因。
  • 误区 2：把“模型答错”全归因到缓存
    • 也可能是提示词不清、工具权限不足、AI 幻觉。
  • 误区 3：清完缓存不做最小复现
    • 你无法知道到底是哪一层修好的。
  • 误区 4：只清浏览器，不处理 Service Worker
    • PWA 场景里这几乎一定不够。

7. 速记要点（可背诵）​

  • 清缓存前先问：到底是哪一层旧了？
  • Vibe Coding 常见 5 层缓存：会话、工具、构建、浏览器、依赖。
  • 更稳的策略是：从轻到重、按层清理、每一步都验证。