← 返回 DacAI Lab

项目复盘

AI 辅助排障,为什么容易越修越复杂

两次个人网站故障里,我如何被合理的解释带进大改造,又如何回到最小可验证假设。

AI 协作故障排查网站复盘

内容说明:本文基于两次真实的个人网站排障经历,由 AI 协助整理。文中只保留了能从当时记录和最终修改中确认的事实;服务器、本地目录和已下线内容均已脱敏。

我曾经为个人网站连续排查两次问题。

第一次,网站的文件树是空的,点击分类页返回 404。第二次,普通文章可以打开,文章中链接的独立 HTML 看板却一直空白。

两个问题最后都不复杂:

  • 404 与一个挂载目标错位、一条带删除语义的同步命令有关;
  • HTML 看板空白,最终只需让站内路由对这类静态文件放行。

但在找到这些小修改之前,我们先做了一轮迁移、回滚、外部托管和路由改造。问题不是 AI 没有给出方案,恰恰是它给出的方案太完整、太像真相。

第一次绕路:把路径错误解释成架构问题

当时的站点使用一个静态网站生成器,文章保存在 Windows 中,构建工具运行在 WSL 里。网页显示了分类,点击后却是 404,侧边的文件树也没有内容。

AI 很快给出了一个技术上说得通的解释:跨文件系统读取可能导致扫描异常,应该把内容全部迁入 WSL 的 Linux 文件系统。

这个解释有三个很强的诱惑:

  1. 它使用了真实存在的技术差异;
  2. 它能同时解释“文件树为空”和“点击 404”;
  3. 它附带了一套看起来更规范的目录架构。

我们因此把文件复制到新位置,重写了同步路径,又更新了相关配置。改完以后,网站的问题虽然可以绕过,日常编辑却变得更麻烦:我使用的笔记软件在 Windows 上,新位置对构建工具友好,对我却不友好。

直到回到最基础的检查,才发现两个可以直接验证的事实:

  • 构建目录挂载到了不对的上级目录,它看到的根本不是预期的内容源;
  • 同步命令带有“目标与源保持完全一致”的语义,当源目录为空时,目标内容也会被清空。

这两点都不需要重构。最后的处理是撤销迁移,恢复原来的编辑位置,修正目录指向,并把会删除目标内容的同步方式换掉。

这次绕路的问题不是“AI 猜错了”这么简单。更关键的是,在确认构建工具正在读取哪个目录之前,我就接受了一个关于“为什么读不到”的深层解释。

第二次绕路:一直教路由器理解特殊页面

另一次问题发生在独立 HTML 看板上。

这类文件和普通文章不同:它自带样式和脚本,需要浏览器像打开一个完整网页那样重新加载。但当时站点的单页路由会拦截站内链接,只替换当前页面的部分内容。结果是 HTML 被取回了,它依赖的完整加载过程却没有发生。

我们先后尝试过更换链接形式、添加自动刷新、重新执行脚本、增加中转页,甚至准备将看板搬到另一个独立站点。每一种方案都在回答同一个问题:

如何让当前路由机制正确处理这个特殊页面?

最后有效的问法却是:

这个页面根本需要被路由机制处理吗?

答案是不需要。在链接拦截逻辑里对指定的静态文件路径直接放行,浏览器就会完整打开它。最终修改只是一个早退判断。

前面的方案不是毫无逻辑,它们只是都默认了“路由器必须接管链接”。当这个默认前提没有被写出来,AI 很容易在错误边界内不断优化方案。

我后来怎么和 AI 一起排障

这两次经历之后,我不再先让 AI 给出“完整修复方案”,而是先要求它帮我缩小事实范围。

我现在会用下面这个顺序。

1. 先写现象,不写根因

例如“构建后没有生成目标文件”是现象,“跨文件系统不兼容”是假设。把两者写在同一句里,会让后续所有检查都偏向证明这个假设。

2. 找到第一个可观察的分界点

不要一次追整条链路。先问一个能用结果回答的问题:

  • 构建工具此刻读取的绝对位置是什么?
  • 源文件在这个位置是否真的可见?
  • 点击链接后,浏览器是整页加载还是站内替换?
  • 失败发生在生成、复制、路由还是渲染哪一步?

每个问题都应该对应一个可以看见的输出,而不是更长的解释。

3. 一次只改一个条件

如果同时迁移目录、更换同步工具、修改构建配置,结果即使变好,也不知道哪一步有效。更糟糕的是,其他改动可能同时制造新问题。

最小改动的意义不只是安全,它还让一次操作成为一次实验。

4. 在扩大方案前,先写回滚点

如果一个方案需要新的存储位置、新服务或大量配置修改,它已经不是普通的排障步骤,而是一次架构变更。在做之前,至少要知道原状态如何恢复,以及什么结果会证明这个方向是错的。

5. 让 AI 同时寻找反证

除了问“最可能的原因是什么”,我会再加两个问题:

  • 什么现象可以推翻你的判断?
  • 不改动现有结构时,最小的验证方法是什么?

这能把 AI 从“给出一个有说服力的故事”,拉回到“帮助排除错误假设”。

我保留的判断

AI 在排障中仍然很有用。它能快速读配置、列检查点、解释工具行为,也能在线索已经足够时很快地定位修改。

它的风险不只是“会说错话”,而是会把有限的现象组织成一个很连贯的原因,然后顺着这个原因生成完整工程方案。对一个急于修好问题的人来说,“完整”很容易被误认为“正确”。

所以我现在会把 AI 当作一个可以高速提出和检查假设的搭档,而不是替我宣布根因的人。

排障的第一个产物不应该是修复方案,而应该是一个足够小、可以被结果推翻的假设。