返回首页
/vscode-external-file-change-refresh

为什么 Codex 改完代码后 VSCode 里看不到

创建于 2026/6/25 09:31:49
VSCodeCodex协作文件刷新Git

为什么 Codex 改完代码后 VSCode 里看不到

这篇记录一个很容易被忽略、但实际协作里很重要的问题：外部工具已经改了磁盘上的文件，但 VSCode 当前窗口里还显示旧内容。这个时候如果继续在旧窗口里手动改代码并保存，就有可能把外部工具刚写入的内容覆盖掉。

这里的“外部工具”可以是 Codex、脚本、格式化命令、Git 操作、批量替换工具，也可以是另一个编辑器。只要它不是当前 VSCode 编辑器窗口自己写入的，都属于外部修改。

现象

最直观的表现是：

  1. Codex 或脚本提示已经修改了某个文件。
  2. 你在终端或 Git diff 里能看到文件确实变了。
  3. 但 VSCode 里已经打开的那个 tab 还是旧内容。
  4. 关闭再打开文件，或者重新加载窗口后，才看到新内容。

这不是代码没有写进去，而是 VSCode 当前编辑器里的内容没有及时从磁盘刷新。

根本原因

VSCode 打开的文件并不等于“每一秒都重新读取磁盘”。它会把文件内容加载到编辑器 buffer 里，然后通过文件监听器感知磁盘变化。

正常情况下，外部修改发生后，VSCode 会自动刷新或者弹出提示。但下面这些情况会让刷新不及时：

  • 文件已经在 VSCode 里打开很久。
  • 当前 tab 里有未保存修改。
  • 文件监听器延迟或失效。
  • 工作区很大，文件变动很多。
  • 同一个项目路径被多个窗口或多个工具同时打开。
  • 外部工具写文件很快，VSCode 还没来得及更新界面。

所以你看到的编辑器内容，有时只是一个旧 buffer，不一定是磁盘上的最新文件内容。

真正危险的地方

危险点不是“看不到新代码”本身，而是后续保存。

比如磁盘上的真实文件已经是：

function demo() {
  // Codex 新加的逻辑
  return "new";
}

但 VSCode 旧窗口里还显示：

function demo() {
  return "old";
}

如果你基于这个旧窗口继续编辑，然后按下保存，VSCode 可能会把旧 buffer 写回磁盘。结果就是刚才外部工具改好的内容被覆盖。

这类问题很烦，因为它不是语法错误，也不是 Git 冲突，而是一次“旧内容覆盖新内容”的协作事故。

为什么 VSCode 不总是自动覆盖当前窗口

这是编辑器的保护策略。

如果当前文件在 VSCode 里有未保存修改，VSCode 不应该静默用磁盘上的新内容覆盖它。否则你手写的内容可能会突然丢失。

所以 VSCode 经常会选择：

  • 保留当前编辑器 buffer。
  • 标记文件已在磁盘变化。
  • 等用户选择 reload、compare 或 overwrite。

这个策略本身是合理的，只是对“AI 或脚本频繁改文件”的工作流来说，需要用户更主动地确认当前文件是不是最新。

最稳的协作习惯

当外部工具改过文件后，继续手动编辑同一个文件前，先做一次刷新确认。

可以按这个顺序来：

  1. 看 VSCode 文件 tab 上有没有未保存的小圆点。
  2. 切换到别的文件再切回来，看内容是否刷新。
  3. 关闭这个文件 tab，然后从资源管理器重新打开。
  4. 如果还是不对，执行 Developer: Reload Window。
  5. 如果 VSCode 弹出 The file has changed on disk，优先选择 Compare 或 Reload，不要直接覆盖。

这里最关键的一条是：不要在旧内容窗口里继续编辑并保存。

保存前要特别注意的提示

如果 VSCode 提示文件已经在磁盘上变化，常见选项大概会是：

  • Compare
  • Reload
  • Overwrite

优先选 Compare，看清楚两边差异。

如果你确认磁盘上的版本是新的，就选 Reload。

谨慎选择 Overwrite。它通常表示用当前编辑器里的内容覆盖磁盘文件。如果当前编辑器是旧 buffer，就会把外部修改冲掉。

和 Codex 协作时怎么避免

比较稳定的节奏是：

  1. Codex 修改文件。
  2. Codex 告诉你改了哪个文件和大概位置。
  3. 你在 VSCode 里重新打开或刷新这个文件。
  4. 确认看到最新内容后，再继续手动编辑。

如果你准备接着改同一个文件，可以先让 Codex 查一下当前真实 diff：

先看下当前改了哪些文件

这时以 git diff 看到的内容为准。因为 git diff 读取的是磁盘上的真实文件，不受 VSCode 旧 buffer 影响。

同一个文件最好不要两边同时改

如果你已经开始手动编辑某个文件，可以直接说：

我现在要改 MarkdownContent.tsx，你先别动这个文件

这样可以避免两边同时改同一个文件。

反过来，如果 Codex 正在改某个文件，你最好等它改完、确认 diff 后，再继续手动编辑那个文件。

这不是因为工具不可靠，而是因为“同一个文件的两个编辑源”天然需要同步边界。

推荐检查命令

当你怀疑 VSCode 显示的不是最新内容时，可以让 Codex 或自己在终端里检查：

git status --short

看哪些文件被改了。

git diff -- path/to/file

看某个文件磁盘上的真实改动。

如果终端里的 diff 和 VSCode 里看到的不一致，优先相信终端里的磁盘状态，然后刷新 VSCode。

小结

这个问题的本质是：

VSCode 当前 tab 显示的是编辑器 buffer
磁盘文件才是外部工具真实写入的位置
buffer 没刷新时，继续保存可能覆盖磁盘新内容

最实用的规避方式是：

  • 外部工具改完同一个文件后，先刷新或重开文件。
  • 保存前遇到磁盘变化提示，优先 Compare。
  • 不确定时先看 git diff。
  • 同一个文件不要两边同时改。

这样可以把“旧窗口覆盖新代码”的风险降到很低。

游客模式