今年 3 月，我发现一件怪事：我的博客明明更新了，但 V2EX 的 VXNA 里一直没有新文章。

我还在 V2EX 上发过帖子问这件事。当时我的判断很简单：我的博客能打开，RSS 也能打开，那大概率不是我的问题，可能是 VXNA 那边出了什么状况。

后来这事就放下了。我当然在意，只是没有太多时间继续查。再加上我当时也没想到可以让 AI 跟我一起把这个问题一点一点查清楚。

直到最近，我在 V2EX 上看到有人评论说，自己的博客迁移到 Cloudflare Workers 之后，VXNA 就能抓到了。我才想起来：会不会问题不在 RSS 内容，而在我的托管和缓存这条链路上？

于是我把这件事重新翻出来，让 Codex 一起查。说是“一起查”，其实我做的事并不多：我告诉它自己 3 月在 V2EX 发过帖子，让它自己去找；我把浏览器里的 Cloudflare 后台交给它，再把我知道的线索一条一条补给它。点页面、看响应、查配置、改规则，这些具体活都是 Codex 干的。

最先动的是 RSS 数量，但这不是我一开始想到的。我的博客是 Hexo 生成的，RSS 输出在 /atom.xml。Codex 自己分析了一下 atom.xml，发现这份 RSS 有 2M 多。它判断这个体积可能会增加抓取失败的概率，建议先限制 RSS 输出的文章数量，让 /atom.xml 变小一点。

但调完之后，VXNA 还是没有更新。

这下基本可以先放过 RSS 大小了。

我让 Codex 继续查。它换了个方向：先看线上 feed，再看 VXNA 记录的地址，接着查 Cloudflare 有没有拦。

查下来，RSS 内容正常，VXNA 里的 feed 地址也没变。VXNA 页面里还能看到我的旧文章，说明它以前确实抓成功过。

Cloudflare 后台里，AI Crawl Control 没有挡，Under Attack Mode 没开，安全分析里也没有看到 /atom.xml 被拦。

Codex 还试着在 Cloudflare 里找 VXNA 的来访记录，但没找到明确证据。这里我提醒了一句：既然 VXNA 以前抓到过，而且那时我没有给 /atom.xml 单独设 Cloudflare 缓存，那它当时很可能一路访问到了 Vercel。

于是 Codex 又去看 Vercel。结果也没查出旧记录，因为 Vercel Hobby 版能看的日志很有限，没法倒回去看 3 月以来 VXNA 到底有没有访问过。

Codex 最后盯上了另一个细节：/atom.xml 当时在 Cloudflare 上没有被边缘缓存住，请求会继续打到 Vercel。Vercel 返回本身没毛病，但 VXNA 的请求可能就在这一步失败。

于是 Codex 建议我在 Cloudflare 里给 /atom.xml 单独加一条 Cache Rule。

规则很简单：

1
2
3

URI Path equals /atom.xml
Cache eligible
Edge TTL: 2 hours

加完以后，Codex 又去验证了一下缓存有没有真的生效。结果是生效了。

这时 /atom.xml 已经被 Cloudflare 边缘缓存住了。VXNA 再来抓的时候，不需要再绕到 Vercel。

中间我还问过一个问题：能不能验证 VXNA 到底有没有来？

Codex 还提过一个办法：给 /atom.xml 加一层很小的 Worker，专门记录访问。但我最后没做。这个办法主要用来抓证据，对修问题帮助不大。现在 feed 已经能正常返回，缓存也已经调好，没必要为了证明一件事去改变生产路径。

我本来打算等 24 到 48 小时再看。

结果没多久，我发现 VXNA 已经抓到了。

这件事到这里可以先下一个谨慎的判断：RSS 内容没问题，把 RSS 变小也没解决。起作用的那一下，是让 Cloudflare 把 /atom.xml 稳定缓存起来。

我也不想直接说“问题就是缓存”，或者“Vercel 坏了”。

我现在倾向于把它理解成一条链路的问题：VXNA 来抓 atom.xml 时，要先经过 Cloudflare，再到 Vercel。我们自己请求 Vercel 返回正常，Cloudflare 也没有明确拦截，但没有边缘缓存时，VXNA 的请求可能在 Cloudflare 到 Vercel 之间失败。更细的原因没法确认，因为没有 VXNA 那边的日志。

而且它之前是好的。VXNA 以前抓到过我的博客，从今年 3 月开始才不再更新。这很像 VXNA 那边在 3 月前后换了网络、机器、抓取方式，或者某个外部环境变了。这个变化刚好影响了它访问我这条“Cloudflare 再到 Vercel”的路径。

我手里的证据只能支持一件事：把 atom.xml 放到 Cloudflare 边缘缓存之后，VXNA 能抓到了。

但从结果看，给 RSS 一个稳定的边缘缓存，是对的。

这次我对 Codex 的感受也没那么神。它没有凭空想出一个答案，更像是我终于有了一个可以替我动手查后台、跑命令、比对结果的人。

我提供的东西其实很杂：3 月在 V2EX 发过帖这条旧线索，别人说迁到 Cloudflare Workers 后好了这条评论，我已经打开的 Cloudflare 后台，还有我对这件事的怀疑。具体帖子是 Codex 自己搜出来的。以前这些信息都在我脑子里，散着放着。我自己要查，就得找时间一点一点翻。最后很可能查到一半，又被别的事打断。

这次不一样。我把这些线索丢给 Codex，又把目标说清楚：我要知道 VXNA 为什么抓不到，以及有什么小改动能先解决。剩下的事，它就自己顺着往下查。

它先看 RSS 里到底有没有新文章，再看 VXNA 里记录的 feed 地址，再去 Cloudflare 后台找有没有被拦，找不到 VXNA 来访记录后，又根据我的提醒去 Vercel 看日志。中间它还提出过要不要加 Worker 记录访问，但我们最后没做，因为那东西主要是抓证据，对修问题帮助不大。

我觉得有意思的是这里。

我没有真的写什么代码，也没有自己去翻一堆文档。我做的主要是给信息、说清楚目标、做判断、决定让它改哪里，以及在它想加新东西时问一句：这个真的有必要吗？

这个关系有点像我把一个问题交给一个很能干、但需要我不断补上下文的助手。它不会凭空知道我 3 月发过帖子，也不会知道我为什么突然想起 Cloudflare Workers。可只要我把这些信息给它，再把目标讲清楚，它就能自己去查，自己试，自己把问题解决到能用的程度。

最后修好的地方反而很小：只是一条 Cloudflare Cache Rule。

但这个“小”不是凭空来的。它前面有一堆确认和排除。没有那些确认，我可能会继续改 RSS、乱改 Vercel、甚至直接把博客迁到 Cloudflare Workers 上。V2EX 上有人说换到 Cloudflare Workers 部署博客就好了，这个建议不是没有道理，因为它相当于绕开了 Vercel 这层，让 Cloudflare 自己直接提供内容。但对我这次的问题来说，没必要一上来就搬家。

先把 /atom.xml 缓存好，就够了。

我挺喜欢这个结果。

它不高级，但很像真实世界里的技术问题：最后改动很小，可你得先把路走明白。