建站手记 on 轻语慕心

拥抱AI

Sat, 23 May 2026 01:25:00 +0800

最近重新整理了一下本站，这次的特别之处在于：我没有像过去那样一个文件一个文件地慢慢改，而是直接把 AI 当成了结对工程师来用。

这件事本身也挺适合作为一篇记录。毕竟本站从 2016 年开始存在，中间经历过 Hexo、Hugo、主题迁移、Docker 化、Nginx 配置调整，也算是一个小型但长期运行的个人项目。以前每次改版，最大的成本并不是写几行 CSS，而是重新进入上下文：目录结构是什么、主题怎么覆盖、哪些文件会影响构建、哪些配置不能乱动。

这次 AI 帮我把这个成本降了很多。

没有推翻 Hugo

一开始我也在想，既然现在有 AI Coding，是不是已经不需要 Hugo 这种静态站点系统了。让 AI 直接写一个静态页面，似乎也能很快完成。

但真正拆开来看，Hugo 仍然有价值。它负责的是长期内容管理：Markdown、文章列表、多语言、RSS、sitemap、分类标签、URL 结构和静态构建。这些能力不是 AI 写几个 HTML 文件就能自然获得的。

所以最后选择的是一个更稳妥的方向：保留 Hugo 作为内容底座，同时用 AI 来重写关键页面和视觉表达。

这次没有动文章系统，也没有丢掉 PaperMod 主题，而是在 Hugo 的模板覆盖机制上做定制：

新增自定义首页模板 layouts/index.html
新增关于页模板 layouts/about.html
新增站点扩展样式 assets/css/extended/ai-site.css
保留原来的文章、分类、标签、RSS 和多语言能力

这样改完以后，站点仍然是 Hugo 站点，但首页和关于页已经不再像默认主题。

AI 参与了什么

这次 AI 做得比较好的地方，不是“替我生成一段好看的文案”，而是完整参与了工程过程。

它先读了仓库结构，确认这是一个 Hugo + PaperMod + Nginx 的静态站点。然后根据现有配置判断应该走模板覆盖，而不是直接复制一整套主题出来改。这个判断很重要，因为个人站点最怕的就是为了一个页面效果，把后续维护复杂度拉高。

接着它生成了首页和关于页的模板。首页突出我现在的定位：AI 技术专家、AI 方向探索、Agent 架构和 AI Coding。关于页则改成了更像个人资料页的结构，左侧是身份摘要和社交入口，右侧继续使用 Markdown 内容。

老老实实来阿里云了

Tue, 05 May 2020 19:20:10 +0000

去年买了搬瓦工的CN2-GIA-E线路，也就是DC6机房。刚买的时候体验很好，虽然ping值稳定在138左右，但是带宽大，稳定啊。

但时过境迁，没想到过了半年，开始间歇性抽风。原来会偶尔5~10分钟的无法ping通，或者延迟高达300。忍了很久。

这次五一它完全给我罢工了，一天能抽风十几次，每次都是同样症状。而且ping值居然稳定到198了？？这是逗我吗。

开网页的体验实在是太差了。

假期最后一天打开了阿里云香港，哇。真的是好厉害。38的ping，100M的带宽。按量付费。爱了爱了。

所以迁来了阿里云，核算了下成本，屌丝机器1C0.5G20G，配置费250/年，流量1元/1G，一年下来应该1000之内吧。先试试看~~

源代码迁移到github咯~

Mon, 04 May 2020 23:34:05 +0000

其实很早就看到github开放免费的私有仓库了（翻了翻资料是19年初了），但是因为这套gitlab-ci用的很好的，所以没有迁移的动力。

五一终于腾出时间看了一下github上对标的workflow功能，也是蛮有意思的。趁着这个空档，也就一并迁过来了。

为啥会非要私有仓库？那是因为翻墙代码也在上面啊，考虑再三还是把密码啥的写到代码里最好维护，部署起来也方便。但这个要是公开了，蹭我翻墙也就不说了，喝茶去了就搞笑了。。

迁移了四个仓库过来，总共花费了6小时…研究了下workflow有点费劲。顺手也把老掉牙的hexo和next版本升了一下，看起来没啥大问题。

几个仓库

gaia

这是一个总体的网关，里面包含了一个核心nginx，嵌了多个域名和转发。同时本hexo工程也在里面，主要是考虑到单独拆一个还需要再搞个nginx，麻烦。单纯的配置，就公开了。

chronos

这个是闲的没事儿用go写的，本来想实现一个网站登录，但是后来一直没继续写下去，之后会继续在上面搞的。但我最近又觉得Python不错，后面看会不会开个Python的东西出来了，也没啥敏感内容。

v2ray

这东西就不说了。就是个翻墙了，迁过来也是私有了。主要是有私有的key之类的东西，这东西也是容器化了。基于v2ray的官方镜像叠了一层配置，主要是可以简单的重新打包来升级。不开放是因为认证key也写在配置文件里，开放了我怕不是我机器要被各位大佬爆掉了。

deploy

这玩意儿就是几个简单的docker-compose.yml了，其他几个工程每个的机器上的部署都在这个里面写着。因为我偷懒所以把cloudflare的key也放进去了…所以没法公开。

有相同需求的可以去github上看看参考一下。

后面再开个文章把现在网站的结构记一记好了。

workflow和gitlab-ci

之前好好研究了一下gitlab-ci的方式，gitlab-ci可以全部基于docker镜像，这个比较方便，我自己封装了好几个私有的image，用来打包、部署等等。

切换到workflow发现思路不太一样，workflow里面有个action的概念，乍看起来也是封装的一系列脚本，基本基于shell，但是不能私有是个问题。毕竟我想把机器的deploy key写进去，还是有私有化的需求的。但是看文档，这东西只能public状态才能用。

两者比起来我还是觉得gitlab-ci好用……可能是用久了，workflow我觉得设计思路挺独特，具体还没发现很好用的地方。

之前还自己部署了一台gitlab-runner来跑ci，这次也懒得弄了，直接薅github的羊毛算了。

有点蛋疼的部署

所有的部署镜像都是我在docker hub上的私有仓库，这本身没什么问题，但是gitlab-ci可以在runner里面直接访问到私有仓库，拉到我的私有仓库进行部署，这个在workflow里没法这么干，只能把ssh key写到secrets里面，代码动态的保存下来进行远程deploy。看起来有点不科学，不过先这么用了。

- name: Create the key
  run: echo "${{ secrets.PRIVATE_KEY }}" > key && chmod 600 key
- name: Deploy
  run: ssh -i key -o StrictHostKeychecking=no root@muxin.io "cd /mnt/deploy/gaia && docker-compose down --rmi all && docker-compose up -d"

没错代码就是这么的妖！话说这个key应该跑完workflow会被删掉吧？？？要是没删掉下一个workflow还能用就gg了。我也没细看，相信不会这么蠢的设计的。

第二个不爽的地方是github里面不能建group，导致我每个项目相同的secrets都要手动配一次，这个感觉也不科学。。

基本初步体验就这样，后面看看有新项目要部署了再仔细研究下。

本站全面启用CDN

Thu, 16 Feb 2017 22:14:05 +0000

今日起本站全面启用CDN！

之前一直纠结于境外服务器访问速度有限，境内服务器限制多而且不能科学上网的问题。刚好看到Dnspod的CDN推荐，于是亲自尝试了一下，发现国内访问效果确实显著。

主要做了如下的修改：

取消源站的HTTPS访问方式，关闭防火墙443端口
将HTTPS证书部署在CDN节点，由CDN节点负责建立到用户的HTTPS连接
取消原先www.muxin.io通过nginx做301重定向的操作，改为由DNS阶段直接301重定向

目前你们所看到的结果是来自阿里云CDN的加速效果，话说现在CDN价格确实便宜，阿里云价格大概在0.4元/GB左右，对于小站来说基本可以忽略这个费用。

在此不得不吐槽一下阿里云，开启CDN居然还要人工审核，花了一天时间，而腾讯云则可以立刻开通，最后选择阿里云的原因还是出于情感和信任吧，访问上感觉和腾讯云差不多。

CDN的优势

用上CDN之后本站的真实IP被隐藏，虽然说目前没有遭到过任何攻击，最多被端口扫描过几次，不过终究还是安全了些，目前没有方法可以获得本站的真实IP。

云加速效果确实有效，因为原本国内数据中心到本站的速度并不慢，慢的是某些地区，经过CDN加速后可以完全打到秒开的效果，大大提升了体验。

CDN启用方法也十分简单，只需要提供源站域名和真实IP，由提供商生成加速域名，将自己站点的域名CNAME解析到加速域名即可。

期间也遇到了裸域名muxin.io下CNAME和MX记录冲突的问题，由于Dnspod支持同时设置，暂时就这么搞了，测试了几封邮件没有什么问题，其他还有待观察。