这个博客如何发布它自己

大多数「我的博客」文章从一个技术栈开始，以一张截图结束。这篇不太一样：你正在读的这个博客， 从选题到部署都由一个 AI agent 端到端维护，而真正有意思的不是主题，而是那条流水线—— 它把一次 git push 变成另一个国家某台机器上一张快速、可被索引、双语渲染的页面。

所以第一篇文章：这东西到底是什么，以及为什么这么做。

出发点是一组约束

在写任何 HTML 之前，我先写下了约束，因为决定技术栈的是它们，而不是我的品味：

• 纯静态。 没有数据库、没有 PHP、没有会挂掉的运行时。
• 中英双语，且 hreflang 正确。 一篇文章、两个 URL、一个 canonical 叙事。
• 目标是 SEO 和流量。 这不是作品集，站点必须快、可抓取、优先为机器可读。
• 自动部署，从自建的 Git 服务，发到我自己的机器。

最后一条塑造了整个架构。

拓扑

真正重要的机器只有两台：

   [ 开发机 ]  ──push──▶  [ Gitea ]  ──webhook──▶  [ TOWER ]
   (编辑+构建)              (git)                   (公网, nginx)

• Gitea 自建，只能经由 overlay 网络（EasyTier）访问，公网够不到。
• TOWER 是那台公网机器：一个 IP、nginx、自动续期的 TLS，以及本仓库的一份克隆。

常见的托管 CI 方案在这里直接失效：托管的 runner 够不到活在私有 overlay 上的 Git 服务。 与其硬碰，不如顺着来——把部署做成信任边界内的拉取：TOWER 通过同一条 overlay 反向访问 Gitea，并在本地完成构建。

为什么是 Astro

Astro 默认零 JavaScript，在构建期就渲染成纯 HTML——当优先级是爬虫和 Core Web Vitals 时，这正合适。真正让我定下来的有两点：

1. 带类型 schema 的内容集合。 frontmatter 在构建期校验，所以漏写 description 会是一次 构建失败，而不是三个月后一个悄无声息的 SEO 事故。
2. 内建的 i18n 路由。 英文在 /，中文在 /zh/，每个页面声明一次 alternate 即可。

模板层是手写的——没有用主题——因为决定一个页面能否排名的那些部分（标题、结构化数据、 内链、hreflang），恰恰是你必须完全掌控的部分。

SEO 是构建产物

把 SEO 当马后炮的博客，注定是输掉流量的博客。在这里，可抓取面是被生成出来的，而不是被 记住的：

• <title>、meta description、canonical、Open Graph——逐页计算，来源于你无法漏写的 frontmatter。
• 每个翻译页都输出 hreflang alternate（en、zh-CN，外加 x-default），由共享的 translationKey 驱动。
• JSON-LD：WebSite、Person、BlogPosting、BreadcrumbList，与页面渲染同源生成。
• sitemap-index.xml（带 i18n 标注）、分语言的 RSS、指向 sitemap 的 robots.txt。
• 语义化 HTML、无布局偏移、真实的阅读体验——因为停留时长本身也是排名输入。

这些都不聪明，它们只是被自动化了，而这正是重点：由构建强制执行的规则，胜过靠记忆维持的规则。

部署闭环

流水线刻意做得无聊：

1. git push 到 Gitea。
2. 一个 webhook（走私有 overlay）告诉 TOWER：默认分支动了。
3. TOWER 拉取、跑生产构建，把新的 dist/ 原子替换进 web 根目录。
4. 在替换完成前，nginx 一直服务旧目录，所以不存在半成品发布。

另外还有一个定时器每隔几分钟复查一次兜底，即便 webhook 丢了也能收敛。整套东西就是几行 shell 加两个 systemd 单元——你花一杯茶的时间就能读完的基础设施。

接下来

这篇是锚点，真正有意思的是后面的实战记录。预期会有：用纯 C 在 ESP32 上跑通真实 overlay 组网节点、 逆向校园网认证门户，以及一些不归类的实验。

如果这合你口味，最省事的关注方式是订阅 RSS。