<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>建站 on 泽峰</title><link>https://zefeng.me/tags/%E5%BB%BA%E7%AB%99/</link><description>Recent content in 建站 on 泽峰</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Fri, 14 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://zefeng.me/tags/%E5%BB%BA%E7%AB%99/index.xml" rel="self" type="application/rss+xml"/><item><title>十年以后，我重新搭了一个个人博客</title><link>https://zefeng.me/posts/rebuild-blog/</link><pubDate>Fri, 14 Aug 2026 00:00:00 +0800</pubDate><guid>https://zefeng.me/posts/rebuild-blog/</guid><description>&lt;p&gt;最近看到少楠还在认真维护自己的个人博客&lt;a href="https://shaonan.blog"&gt;《少楠的松节油》&lt;/a&gt;，我愣了一下。&lt;/p&gt;
&lt;p&gt;大概 2016、2017 年的时候，我也用 Hexo 搭过博客。那时候会为了一个主题折腾半天，会买域名，会研究 GitHub Pages，也会真的往上面写东西。现在回想，那时的表达欲好像比后来强。&lt;/p&gt;
&lt;p&gt;后来这些年，表达没有消失，只是散落了。有的在微信里，有的在飞书和工作文档里，有的在和 AI 的对话里。真正属于自己、能长期留下文字的公开空间，反而没有了。&lt;/p&gt;
&lt;p&gt;所以这次重新搭 zefeng.me，我一开始就给自己定了一个很简单的目标：别把它再做成一个技术项目。&lt;/p&gt;
&lt;h2 id="先给自己定了三个原则"&gt;先给自己定了三个原则&lt;/h2&gt;
&lt;p&gt;动手之前，我先跟自己确认了三件事。&lt;/p&gt;
&lt;p&gt;一，国内能直接打开。手机、公司、家里的网络都不用科学上网，也不依赖 Google Fonts 这类跨境资源。这是第一优先级。&lt;/p&gt;
&lt;p&gt;二，维护成本尽量低。不维护服务器，不维护数据库，不长期追插件兼容性。&lt;/p&gt;
&lt;p&gt;三，文章必须永远属于自己。内容全用 Markdown 保存，版本用 Git 管，Hugo 只是展示层，Cloudflare 只是托管层。哪怕哪天换主题、换生成器、换托管平台，文章都能原样带走。&lt;/p&gt;
&lt;p&gt;这三条原则看上去朴素，后面几乎所有的选择都是它们决定的。&lt;/p&gt;
&lt;h2 id="选型没有花太久"&gt;选型没有花太久&lt;/h2&gt;
&lt;p&gt;我没有认真比较十几套方案，因为目标已经决定了答案。&lt;/p&gt;
&lt;p&gt;一开始就主动排除了一些看起来更「重」的方案：WordPress、Next.js、数据库、Docker、自建服务器。不是这些技术不好，而是如果一个博客需要我长期盯着服务器、运行时和插件兼容性，对我来说它迟早会变成另一个维护项目。&lt;/p&gt;
&lt;p&gt;于是答案很清楚：Hugo 生成静态页面，成熟、快；PaperMod 足够克制，不需要我再设计一整套；GitHub 管源码和版本历史；域名、DNS、部署都放在 Cloudflare，少一个账号，少一层故障排查。&lt;/p&gt;
&lt;p&gt;域名在 zefeng.me 和 zefeng.blog 之间犹豫了一下，选了 .me。博客只是它现在的形态，.me 更像一个长期身份——哪天它挂主页、挂作品页，或者挂点别的什么，都说得通。博客名字随时可以改，域名最好十年不动。&lt;/p&gt;
&lt;p&gt;选型里也踩了两个小坑。一个是主题版本：PaperMod 官方发布版和我机器上较新的 Hugo 不兼容，构建直接报错，后来把子模块钉在主分支的某个提交上才解决。另一个是部署界面：Cloudflare 控制台已经把 Pages 并进 Workers 统一构建，老教程对不上新界面，创建表单里连「输出目录」这一栏都没有，我是在仓库根目录加了一个配置文件声明静态产物目录、钉死 Hugo 版本，才让云上构建稳下来。&lt;/p&gt;
&lt;p&gt;部署完还发现一件事：Cloudflare 自动分配的临时访问地址，在大陆网络打不开，正式域名却一切正常。这些都不难，但不亲自踩一遍，确实不知道。&lt;/p&gt;
&lt;h2 id="我没有自己写代码"&gt;我没有自己写代码&lt;/h2&gt;
&lt;p&gt;这次和十年前最大的区别，是我几乎没有自己敲建站代码。整个站是交给一个 AI Agent（Hermes）搭的。&lt;/p&gt;
&lt;p&gt;第一件事是给项目划地盘：所有博客相关的文件、脚本、改动，只允许发生在同一个工作目录里。这听上去是小事，但我很怕另一种局面——不同文件夹里各躺一份源码，最后连我自己都不知道哪个才是正式版。只有一个目录，Git 历史就是唯一的事实来源。&lt;/p&gt;
&lt;p&gt;分工大概是：我负责定义需求、做取舍、审美判断、确认发布；它负责初始化 Hugo、配主题、Git、Cloudflare、修 Bug、改 CSS、字体、Logo，以及后续的文章发布。&lt;/p&gt;
&lt;p&gt;但边界是明确的：账号登录、验证码、Token、支付，还有删仓库、删域名这类高风险操作，必须停下来由我自己做。比如登录 GitHub，Agent 跑的是设备授权流程，终端里生成一串八位验证码，由我在自己的浏览器里输入确认——它全程只递给我一个验证码，不碰密码。不是不信任工具，是出了事承担后果的是我。&lt;/p&gt;
&lt;p&gt;这次我发现，Agent 最适合接手的，不一定是「创造」，而是那些我过去懒得维护、但其实规则很明确的事情。搭博客正好是这种事。&lt;/p&gt;</description></item></channel></rss>