刷新页面之后,那些修复一个都没生效

路由修好了。State 端点重写了。数据格式改对了。每一处改动都在仓库里确认过,文件里看得到,一切都和预期一样。

刷新浏览器。什么都没变。

还是那张坏掉的桌子。还是那块空白的画布。

实际上发生了什么

平台在本地通过 Docker 运行 —— 一组容器,每个跑一个服务,通过共享配置连接起来。前端 web 应用以 volume 方式挂载:磁盘上的源文件直接映射进容器。构建工具 Vite 监听文件变化,自动刷新浏览器。

只不过它并没有在监听。

在 Windows 上通过 WSL2 运行 Docker —— WSL2 是 Windows 用来跑容器的 Linux 兼容层 —— Vite 用来检测变化的文件系统事件通知,无法正确穿越虚拟化边界。Linux 的通知系统报告了变化。Windows 没把它转发出去。Vite 永远看不到文件更新。浏览器继续提供之前的那份代码。

修复就是 Vite 配置里的一行:usePolling: true。Vite 不再等待变化通知,而是每 300 毫秒检查一次。效率稍微低一点。能用。

桌子引擎 —— 管理实际游戏状态的后端服务 —— 有同一个问题的另一个版本。这个 stack 里的后端服务不跑 watch 模式。代码变更需要手动重启容器。这是生产级服务的标准行为。只是你得知道要重启。

另一件出错的事

环境问题解决之后,第三个 bug 浮了出来:桌子路由有个 auth guard,总是把浏览器送到登录页。

不是因为用户没登录。登录了。Guard 在检查一个永远不会被填充的 TanStack Router context 值 —— router 配置时没有 context provider,所以 context.auth 永远是 undefined。Guard 读到"未认证",重定向到登录。登录看到已认证会话,重定向回 lobby。浏览器陷入循环。

改了一行。Guard 被更新为直接从 authentication store 读取,这是应用里其他所有路由用的同一种模式。修好了。

这要求键盘前的人具备什么

修复是正确的。系统没有把它们捡起来。那个观察 —— 正确的代码和运行中的代码是两件事 —— 需要对开发环境足够熟悉,才能问出对的问题。

Agent 可以写出修复。一旦你描述了 bug,它可以追踪。它没法注意到浏览器在提供配置变更之前的代码缓存版本。那个观察是人做的。

足够了解系统,能诊断为什么一个正确的修复没生效 —— 这是不会被自动化的部分。

配置 polling 之后,容器重启之后,auth guard 修复之后:桌子加载出来了。座位出现了。Buy-in 对话框渲染了。Lobby 卡片高度正确了。一切都工作了。

下一篇覆盖在我们有了一个能跑的系统可以拿来测试之后,integration testing 看起来什么样 —— 以及为什么这个阶段不管是 AI 还是人写的代码都一个样。

要看创始人视角下如何应对这种 debugging 流程 —— 当 AI 写了大部分代码库时,human-in-the-loop 这个角色实际要求什么 —— 在 The Salty Korean 上。

Stay salty.