博客挂了三天，我和 AI Agent 把它整个重造了一遍

第一幕：网站”凭空消失”了#

排障最忌瞎猜。我的习惯是分层查：域名注册 → DNS 解析 → 证书 → 服务器，一层层排除。

第一层，域名还活着吗？

1
whois luoruihuan.top

阿里云注册，到期日 2027-09-29，状态 ok。域名没问题。但有个细节引起了我的注意：

1
Updated Date: 2026-10-28T03:25:56Z

域名信息昨天刚被更新过，今天就挂了——时间线高度吻合。这成了后面定位问题的关键线索。

第二层，DNS 在撒谎吗？

1
dig luoruihuan.top NS +short
2
# andy.ns.cloudflare.com.
3
# laila.ns.cloudflare.com.     ← NS 正常，在 Cloudflare
4

5
dig luoruihuan.top A +short
6
# （空）                        ← A 记录呢？？？

NS 还在，但 A / AAAA / CNAME 全部查空。换了 Google 的 8.8.8.8 和 Cloudflare 的 1.1.1.1 交叉验证，结果一致——不是本地缓存问题。

还不放心，直接问权威服务器：

1
dig @andy.ns.cloudflare.com luoruihuan.top A +noall +answer +authority
2
# ->>HEADER<<- status: NOERROR
3
# ANSWER: 0

注意这个结果：NOERROR + 0 条回答（NODATA），和 NXDOMAIN 是两回事。NXDOMAIN 是“这个域名不存在”；NOERROR 加空 answer 是“域名存在，但它没有你要的这条记录”。

权威服务器亲口告诉我：zone 活着，里面的解析记录没了。

登录 Cloudflare 一看，DNS 记录列表干干净净——被谁删的、什么时候删的，已经无从考证（whois 那条更新时间暗示了时间点）。重新加上记录，域名恢复了解析。

第二幕：修好了，但浏览器说”连接不是私密连接”#

DNS 通了，浏览器却给我一个大大的红色警告：net::ERR_CERT_COMMON_NAME_INVALID。

用 openssl 看一眼服务器到底给了我什么证书：

1
curl -sv --resolve luoruihuan.top:443:185.199.108.153 https://luoruihuan.top/ 2>&1 | grep subject
2
# *  subject: CN=*.github.io

破案了。这个站之前托管在 GitHub Pages,GitHub 会给自定义域名签发专属的 Let’s Encrypt 证书。但证书续期的前提是 DNS 一直指向 GitHub——我的解析记录断了几天，证书过期被撤了。DNS 恢复后,GitHub 边缘节点上只剩一张默认的 *.github.io 证书,浏览器一看<我要的是> luoruihuan.top,你给我 *.github.io?不匹配,拒绝。

解法不难：到仓库设置里把 custom domain 解绑再重新绑定，触发 GitHub 重新走一遍域名验证和证书签发，几分钟搞定。

第三幕：我修好了，但修的是”错的站”#

证书签好、网站恢复、备案号加上的当天，我后知后觉地想起一件事——

我好像还有个新博客项目，不在 GitHub Pages 上。

翻出那个 luoruihuan.top 仓库，.github/workflows/deploy.yml 里写得明明白白：

1
- name: Deploy via rsync
2
  run: |
3
    rsync -az --delete dist/ ubuntu@129.146.16.16:/var/www/ron-site/

真正要上线的站，部署在一台 Oracle 云的 ARM 小鸡上，rsync 推静态文件，早就忘了是 vm1 还是 vm2——workflow 文件本身就是最好的部署文档。ssh 上去确认：文件在，服务在，但 80 端口在系统防火墙里被 REJECT，443 被 Caddy 占着却没配主站站点。放行端口、补一段 Caddyfile、证书自动签发，链路才算真正修通。

这一幕给我的教训比前面所有技术问题都深：“部署在哪”这件事，不能只存在于记忆里。

第四幕：既然都动土了，干脆重造#

站修好了，但看着那个 2023 年审美的主题，我决定不将就了——换。

我把需求丢给 AI Agent，要求很直接：现代、酷炫、有 demo 可看、中文社区活跃。它给了一份对比报告，我快速过了一眼：

我选了 Firefly。接下来的事，基本是 Agent 主导、我做决策：

• 内容迁移：现有 3 篇 + 我那个 2016 年的 Hexo 老博客 22 篇，一共 25 篇。Agent 写了个脚本批量转换 frontmatter：Hexo 的 date/categories/urlname 映射成 Astro 的 published/category/slug，<!--more--> 摘要分割符自动转成 description，十年的时间线一篇不乱。老博客的图片整体搬到 public/uploads/，文章里的引用路径一行不用改。
• 站点个性化：标题、头像、favicon、导航链接（GitHub、我的服务监控页）、页脚备案号、背景图、音乐播放器换成周传雄的《青花》。
• 部署链路：CI 构建 → rsync 到小鸡，全链路保留，push 即上线。

一个下午，25 篇文章迁完，主题换成新的，部署链路照旧跑通。

第五幕：Agent 翻车集锦#

网上写“AI Agent 有多强”的文章已经泛滥了，这篇写点不一样的：这几天 Agent 真实翻过的四次车。四次都是真事，每一次都真实造成过线上故障。

翻车一：一条分号，误删整个工作目录。

clone 仓库时网络抖了一下失败，cd 进目录自然也失败——但那条命令链里我（其实是 Agent）用了分号分隔而不是 &&，于是”清空目录”的命令在 /tmp 本尊上执行了，把所有工作文件一锅端。好在所有源头资产都在 GitHub 上，用脚本重做了一遍。

教训：shell 命令链永远用 &&，清理类命令前先确认当前目录。

翻车二：BSD sed 的一��范围删除，删到了文件尾。

修复 CI 配置时用了 sed '/with:/,/version: 10/d'。macOS 的 sed 在”结束模式”永远匹配不到时,会从起点一路删到文件末尾。workflow 被删得只剩三个初始化步骤—没有构建、没有部署,job 却显示 success。CI“空转成功”是最迷惑人的故障形态：绿灯亮着，什么都没发生。

教训：范围删除用 Python/lint 校验结果，“成功”必须验证产物而不是只看退出码。

翻车三：rsync 忘了 --delete，线上闹鬼。

背景图明明换掉了，线上却一直显示旧的示例图。排查到怀疑人生，最后发现是同步目录时 rsync 没带 --delete——本地删掉的文件在目标端永远残留，CI 又基于旧文件构建，旧图就这么”复活”了。

教训：“同步”和“覆盖”是两回事，镜像同步记得 --delete。

翻车四：正则替换，替换到了注释里。

把背景图配置从数组改成单张图片，Agent 用正则 desktop: \[...\] 匹配替换——结果文件顶部的注释示例里恰好先出现了一模一样的写法。替换成功了（日志全是 ✅），但改的是注释，真正的配置原封未动。

教训：正则替换前先数一数会命中几处；带校验的替换脚本应该在“恰好命中一次”时才放行。

这四次翻车，没有一次是因为 AI 笨。命令链容错、平台差异、同步语义、正则命中，全是工程里的经典陷阱，人也会踩，只是 Agent 踩得更快、更集中。

总结：三天下来，我对”人机协作”的三点新认识#

一、人做判断，Agent 做执行，但验收必须回到人手里。 主题选型、审美取舍、备案信息这些决策我从不假手;命令、脚本、全链路验证这种脏活累活 Agent 干得又快又好。但每次上线前的最终验证—build 产物里 grep 关键内容、线上 curl 实测—一步都不能省。四次翻车全都是被”验证”拦下来的,没有一次是靠运气。

二、Agent 的“成功”输出不可信，产物才可信。绿灯、✅、exit code 0，都只是必要条件。真正可靠的判断标准是：产物里有没有它，线上有没有它，行为对不对。

三、排障还是要分层。域名注册（whois）→ DNS（dig 递归再问权威）→ 证书（openssl 直接看）→ 网络（curl 分端口）→ 服务器（ssh 查防火墙），每层只回答一个问题。三天里的每一次快速定位，靠的都是这个笨办法。

时光不语，静待花开。网站也一样，挂掉的那三天它一言不发，但每一层都留下了答案，就看你问不问。

这篇文章从写作到发布，跑在重造后的链路上：git push → GitHub Actions 构建 → rsync 到那台 Oracle 小鸡 → Caddy 服务。全程无人工干预。