Posts on CHEN 的博客

把 Understand-Anything 折腾进 Codex 之后，我得到了一件美丽废物

Tue, 26 May 2026 15:20:00 +0800

最近我看到一个叫 Understand-Anything 的 GitHub 项目，星数很高，第一眼看上去就属于那种“好像很强”的东西。

我当时的直觉很简单：既然这么多人点星，而且项目名字也很直接，那大概率是个能快速帮助我理解代码库、梳理系统结构、减少上手成本的工具。于是我干脆把它整进了 Codex，作为一个 skill 来试。

结果折腾完一圈，产出看起来挺华丽：

知识图谱
新人指南
后端项目理解摘要
一套像模像样的“系统认知结果”

但真正落地时，我的感受只有一句话：

这是个美丽废物。

这篇文章记录一下这次尝试的全过程，也顺便谈谈我对这类“看起来很牛的理解型工具”的一点判断。

一、Understand-Anything 是什么

Understand-Anything 从名字上就很有野心，它的目标并不是只看某一类文档，也不是只做一个简单摘要器，而是试图借助大模型能力，把一个复杂对象“解释清楚”。

从项目定位来看，这类工具通常会强调几件事：

输入一份代码库、文档集或系统资料
自动抽取关键结构
生成模块关系
输出知识图谱、架构理解、上手指南之类的结果

如果说普通摘要工具解决的是“把一段内容缩短”，那这类项目想解决的是另一个更大的问题：

能不能让一个新人，快速建立对复杂系统的整体认知？

这也是为什么它很容易吸引人。因为这个命题本身太诱人了：

面对陌生项目时，大家都想要一份高质量的导览图
面对复杂后端时，谁都希望有一个能自动生成的上手说明
面对遗留系统时，任何“帮我理解”的工具都会天然有吸引力

所以它受欢迎，并不奇怪。

二、为什么我会想把它接进 Codex

我真正感兴趣的不是单独跑一下这个项目，而是把它并进自己的工作流里。

因为如果它真有用，那最理想的落地方式并不是“偶尔单独打开一次”，而是：

把它接进 Codex
作为一个 skill 使用
在需要理解新项目时直接调用
自动产出结构化认知结果

这个想法听起来非常合理，甚至有点高级。

如果这条路走通，理论上会得到一个相当诱人的工作流：

把项目喂进去
自动生成系统概览
自动梳理模块关系
自动输出新人指南
后面再由我自己做精修和验证

从纸面上看，这几乎就是“理解型 AI 工具”的理想形态。

于是我就真的开始做了。

三、为了它，我不只是试了一下，而是认真折腾了

这次我没有停留在“看一眼 README”这种程度，而是确实把它落到了自己的使用环境里。

我做了几件很具体的事：

把项目整到 Codex 里，作为 skill 使用
拿它去理解一个后端项目
让它输出知识图谱和新人指南
为了效果更好，还专门把模型切到了 gpt-5.5 high

这一步其实已经不是“随便试玩”了，而是一次有明确预期的正式试用。

更直接一点说，我愿意为它投入成本，是因为我真的想验证：

它到底能不能把“理解系统”这件事，从一种高消耗脑力活，变成一种可复用流程。

而这次试用成本也不算低。

我最后看了一下消耗，光这次尝试就用了：

模式：gpt-5.5 high
时间：前后折腾了两个多小时
Token：2.89M

这已经不是“玩一玩”的级别了。

四、它产出的东西，确实一眼看上去很厉害

必须承认，这类工具最擅长的一件事，就是制造“理解已经发生”的感觉。

它输出的内容非常容易给人留下好印象：

知识图谱看起来结构分明
模块关系像是被梳理清楚了
新人指南看起来也像那么回事
文字组织通常比随手写的笔记更规整

如果只是把结果截图给别人看，很容易收获一句：

“这个东西好强。”

这就是它最有迷惑性的地方。

它不是完全没产出，恰恰相反，它太会产出“像成果的成果”了。

这些内容在视觉上、结构上、叙述上，都很容易让人产生一种认知错觉：

既然已经有图谱、有模块说明、有新人指南，那我是不是已经理解这个系统了？

但真正的问题在于，形式上的完整，不等于工作上的有效。

五、问题不是它做不出内容，而是这些内容对我没有实际作用

当我真正回到自己的目标上时，问题就暴露出来了。

我想要的不是一个看起来完整的“理解结果”，而是下面这些更具体的东西：

我接下来应该先看哪几个文件
哪个模块才是系统的核心控制流
一个请求从入口到落库到底怎么走
哪些地方最容易改坏
如果我要加一个功能，第一刀应该切在哪里

但这类工具最终给我的，更多是“高层抽象认知”，而不是“可直接拿来干活的路径”。

说得更直白一点：

它很会帮你整理“像全局视角的东西”
但不太擅长帮你找到“下一步到底该动哪儿”

而在真实开发里，后者往往比前者更重要。

因为大多数时候，我不是缺一张看上去很漂亮的系统地图，而是缺一个能让我今天下午就动手改代码的判断依据。

六、知识图谱和新人指南为什么会沦为美丽废物

我后来反复想了一下，为什么这次结果会让我这么失望。

结论并不是“它完全没价值”，而是：

它产出的价值，更偏展示型、归纳型，而不是行动型。

1. 它容易停在正确但无用的层面

比如：

把项目分成几个模块
概括每个模块负责什么
总结系统的整体职责

这些话很可能都没错，但也正因为太“没错”，所以很难直接指导行动。

一个新人真正需要的，往往不是“模块 A 负责用户管理”，而是：

模块 A 的入口文件在哪
初始化顺序是什么
调用链上游下游分别是谁
改这里会不会影响鉴权、缓存或数据库

这两者之间有巨大差异。

2. 它会给你“已经理解”的幻觉

这是我觉得最危险的一点。

有了知识图谱、新人指南、总览说明之后，人很容易对自己的理解程度产生误判。

你会觉得：

结构我看过了
模块我知道了
系统图我也有了

但真等你去改第一段代码时，依然会发现自己还是得：

回到源码
跟踪调用链
看日志
打断点
手动验证

也就是说，那些漂亮产出并没有真正替代掉最核心的理解过程。

3. 它更像管理视角的材料，不像工程视角的工具

很多这类内容，如果拿去做汇报、做入门展示、做高层概览，其实并不差。

但如果你的目标是：

排障
加功能
改逻辑
理清耦合点

那它的帮助就会明显下降。

我后来越来越觉得，这类工具天然更擅长生成：

看起来很像文档成果的东西

而不是：

真正能减少工程试错成本的东西

七、这次最让我不爽的，不是它没用，而是我认真投入之后发现它还是没用

如果只是简单试一下然后发现一般，我可能都不会专门写这篇文章。

但这次让我真正想记一笔的点在于：

我不是轻飘飘点开看了一眼
我是真的把它接进了自己的流程
我还专门换了更强的模型和更高的推理档位
我花了两个多小时
我消耗了 2.89M token

最后得到的却不是“这个工具还不错，但需要打磨”，而是：

它非常会展示自己在工作，但没有真正帮我把事情做成。

这是一种很典型的 AI 使用挫败感。

因为它不像传统软件那样明确报错，也不像脚本那样直接失败。它给你的恰恰是一个“看起来已经很努力”的结果。

问题在于，努力不等于有效。

八、最后我还是把它删了

折腾完之后，我没有选择“先留着以后再看”，而是直接删掉。

原因其实很简单：

一个工具如果不能进入日常工作流，就算它偶尔能产出一些漂亮材料，也不值得长期占据我的注意力。

尤其是在 AI 工具越来越多的环境里，真正稀缺的不是“看起来很强的东西”，而是：

能稳定节省时间的东西
能直接提升判断质量的东西
能真正减少手工试错的东西

如果一个工具做不到这些，那即便它有很多星、很多人夸、很多截图效果很好，最终也只是一个陈列品。

九、这次尝试给我的提醒：不要太迷信大众眼光

这件事对我最大的提醒，不是某个具体项目值不值得用，而是一个更普遍的判断：

不要太迷信大众的眼光。

GitHub 星数高，说明它有传播性、话题性、展示性，甚至说明它确实抓住了一个大家都在痛的需求。

但这些都不等于：

它适合我的工作流
它能解决我的具体问题
它值得我长期保留

大众筛选出来的，很多时候只是“值得你看一眼”的项目。

至于它是不是“值得你真正接入自己的系统”，只能靠自己动手试。

十、最后的结论很土，但大概率也最可靠

这次折腾到最后，我反而得到了一个一点都不新潮、但非常可靠的结论：

多动手，多实践。

看到一个很火的项目，最好的处理方式不是：

先相信它
先神化它
先把别人给它的评价当成自己的判断

而是：

自己装起来
自己接进真实场景
自己为它付出一点时间和成本
再根据实际产出做判断

如果有用，就留下；如果没用，就尽快删掉。

这次 Understand-Anything 对我来说，就是后者。

它不是什么灾难项目，也不是骗人的东西。

它只是一个典型的、看起来很厉害、讲起来也很高级、演示起来很漂亮，但放进我真实工作流之后没有产出实际价值的工具。

说到底，还是那句话：

别太迷信大众的眼光，自己试过才知道。

从申请服务器到搭建 sub2api 中转站：一份完整实践记录

Tue, 26 May 2026 13:25:00 +0800

这篇文章记录一下我从零准备一台服务器，到最终把 sub2api 跑起来并作为反代中转站使用的完整过程。

整个过程并不是单点安装某个程序，而是一条完整链路：

先选服务器
再选域名
配好基础网络出口
然后部署 sub2api
再接上 Nginx 和 HTTPS
最后完成账号绑定和实际可用验证

如果把这件事拆开看，每一步都不算复杂；但如果第一次做，很容易卡在某一个细节上，比如域名解析、反向代理、证书签发或者出口网络。

一、先做服务器比价，最后选择新加坡轻量云

在真正动手之前，第一步其实不是安装软件，而是先挑服务器。

我当时的思路很明确：这台机器主要是跑一个轻量级中转服务，不是数据库重负载场景，也不是需要高性能计算的业务，所以重点不是极限性能，而是下面几项：

价格是否足够低
海外线路是否相对稳定
带宽和流量是否够用
系统镜像是否方便直接上 Ubuntu
控制台和安全组是否省心

这一类场景里，常见可选项一般会包括：

腾讯云轻量应用服务器
阿里云轻量应用服务器
部分海外 VPS 厂商
传统云服务器标准实例

如果只是部署 sub2api 这种中小型服务，轻量服务器通常比传统 CVM / ECS 更合适，因为：

价格更直接
自带公网 IP
管理界面简单
比较适合个人项目或中小流量工具站

综合权衡之后，我最后选择了腾讯云新加坡区域的轻量云服务器。

这个选择背后的考虑大致有三点：

新加坡区域在亚洲访问延迟相对更友好
对个人用途来说，价格和稳定性比较平衡
后续配域名、Nginx 和证书都很常规，资料比较多

系统方面，直接选择 Ubuntu 就够了。后续所有部署动作基本都围绕下面这些组件展开：

apt
systemd
nginx
certbot
tailscale

二、域名不需要贵，但最好专业、好记、能长期用

服务器确定之后，下一步就是域名。

我当时没有去买特别昂贵或者过于花哨的后缀，而是选择了一个 cloud 结尾的域名。原因很现实：

价格便宜
可选空间相对多
看起来比很多冷门后缀更正式
用在技术服务和工具站上违和感小

对个人项目来说，域名最重要的不是“看起来很高级”，而是：

便于记忆
不容易输错
适合长期续费
作为主域名时不显得太随意

最后我用这个域名同时承载了不同用途：

主服务走主域名
博客走子域名
后续不同组件都可以拆分到不同子域名下

这种方式的好处是结构清晰，后续扩展也方便。

三、先把流量出口问题想清楚：用 Tailscale 把本机作为出口

部署 sub2api 这种服务时，一个非常实际的问题是：服务运行在服务器上，但某些访问链路未必适合直接走服务器本地网络。

所以我当时的处理思路是：

在服务器上安装 Tailscale
把自己的本地设备加入同一个 tailnet
让本机作为出口节点
使服务器的相关流量通过本机出口转发

这么做的核心价值，不在于“更酷”，而在于网络路径可控。

1. Tailscale 的角色

Tailscale 本质上是一个基于 WireGuard 的组网方案。它的优点是：

安装简单
节点互联快
不需要自己维护传统 VPN
可以很方便地指定出口节点

这类方案特别适合：

个人多设备协同
家里电脑和云服务器互通
临时把一台设备当作统一出口

2. 典型操作思路

这一部分大致会包含下面几个动作：

在本机安装 Tailscale
在云服务器安装 Tailscale
登录同一个账号或组织网络
在本机开启 exit node 能力
在服务器侧指定该 exit node

从结果上说，就是服务器虽然部署在云端，但某些流量可以按你的规划经由本机网络出去。

3. 这一步为什么重要

很多人搭服务时，默认认为“服务器能联网就够了”。但实际一旦进入真实使用，网络出口路径、可访问性、登录状态和上游连接稳定性都会影响最终可用性。

所以我认为，Tailscale + exit node 并不是额外花活，而是这类中转服务里非常实用的一环。

四、账号准备：把环境准备和服务部署分开看

这一步我更愿意把它理解为“账号环境准备”，而不是部署本身的一部分。

因为从工程角度看，服务器、域名、代理、证书、服务进程，这些都是基础设施问题；而账号登录、订阅状态、客户端绑定，则更接近上游服务接入问题。

我这里不展开写过细的支付或区域性操作细节，只保留思路层面的经验：

尽量把账号环境准备和服务器部署分开处理
优先保证账号本身状态正常可登录
再去做后面的 OAuth 绑定

这样做的好处是排障更清楚。否则一旦失败，你很难判断问题到底出在：

服务器网络
反向代理
HTTPS
OAuth 回调
还是账号自身状态

五、正式部署 sub2api：先让服务能跑起来

当服务器、域名和网络出口都准备好之后，就可以进入真正的服务部署阶段。

这一部分的目标不是先追求“最优雅”，而是先让 sub2api 在服务器上稳定跑起来。

1. 基础环境准备

最常规的准备动作一般包括：

更新系统软件包
安装 Git、Nginx 等基础依赖
准备运行目录
规划监听端口

如果服务本身有独立的启动方式，还需要考虑：

二进制部署
Docker 部署
systemd 托管

从长期维护角度看，我更偏向把服务交给 systemd 或容器托管，而不是单纯用一个前台命令挂着。

2. 先本地端口可访问，再接入反代

这一类服务的正确调试顺序通常是：

先确认程序在本机端口已经成功启动
再用 curl http://127.0.0.1:端口 验证是否有响应
最后才挂到 Nginx

如果一上来就把所有东西混在一起，很容易出现：

服务本身没起来
Nginx 也没配对
证书还没签

然后排障就会变得很乱。

六、Nginx 反代：把服务挂到域名上

sub2api 真正对外可用，关键还是靠 Nginx。

常见结构就是：

上游应用监听本地端口，例如 127.0.0.1:3000
Nginx 对外监听 80 和 443
外部流量先到 Nginx
再由 Nginx 转发给 sub2api

一个典型的反代思路会像这样：

server {
    listen 80;
    server_name chen-api.cloud;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里的关键不是把配置背下来，而是理解这几个事实：

应用服务尽量只监听本地
公网入口统一交给 Nginx
反代时要把请求头带完整
后面签 HTTPS 会更顺

七、HTTPS 证书是上线的必要条件，不是可选项

当 HTTP 反代已经打通之后，下一步就应该立刻上 HTTPS。

这一步通常会用 certbot + nginx 组合完成。它的好处是：

配置直接
自动改 Nginx
自动续期方便

只要满足下面几个条件，一般就可以顺利签证书：

域名已经正确解析到服务器公网 IP
安全组放通了 80 和 443
Nginx 对该域名的 server_name 配置正确
外部可以通过 HTTP 正常访问到站点

完成后，服务会从：

http://chen-api.cloud

变成：

https://chen-api.cloud

这不仅是为了浏览器地址栏更好看，更重要的是：

OAuth 回调通常更依赖稳定的 HTTPS 环境
中转服务对安全链路要求更高
长期使用时也更规范

八、登录 sub2api 后，通过 OAuth 绑定上游账号

当反代和 HTTPS 都打通之后，才真正进入“业务可用”阶段。

这时一般会做下面几件事：

打开 sub2api 的管理界面
登录后台
找到账号绑定或授权入口
通过 OAuth 流程绑定 GPT 账号

这一部分最重要的其实不是“点哪个按钮”，而是确保下面三个前置条件已经成立：

站点已经能被公网稳定访问
HTTPS 正常
回调链路没有被错误代理或拦截

如果 OAuth 绑定异常，大概率优先排查这些问题：

域名是否正确
证书是否正常
Nginx 是否正确转发头信息
服务端日志里有没有回调报错

九、整套链路里最容易出问题的地方

回头看，这一套流程真正容易卡住的地方并不只在安装服务本身，而是在几个看似琐碎的环节：

1. 域名解析没生效

很多“站点打不开”的问题，其实不是程序没跑，而是域名还没指到服务器。

2. 服务没起来就开始配 Nginx

正确顺序应该始终是：

先跑服务
再测本地端口
再接反代
再签证书

3. HTTPS 没配置完整

证书签发成功，不代表整个 HTTPS 链路一定完全可用。还要看：

Nginx 是否正确加载证书
443 是否放行
回调链路是否仍然走错地址

4. 把账号问题误判成部署问题

如果上游账号本身状态不对，哪怕服务器、Nginx、证书全都正确，也依然会表现成“服务不可用”。

所以部署和账号准备必须分开排查。

十、最后的结构其实很清晰

等整条链路走通之后，这套架构本身并不复杂：

一台海外 Ubuntu 服务器
一个正式域名
Tailscale 作为可控网络出口方案
sub2api 作为核心服务
Nginx 负责公网入口与反向代理
Let's Encrypt 负责 HTTPS
OAuth 完成上游账号绑定

从结果上说，这已经是一套足够个人长期使用的中转服务结构。

它未必是唯一方案，也不一定是最“高级”的方案，但对个人部署来说，胜在：

成本可控
结构清晰
易于维护
扩展方便

十一、如果让我再做一次，我会坚持这个顺序

最后总结一下，如果让我重新从零做一遍，我仍然会按这个顺序来：

先选服务器和区域
再买域名并规划子域名
先解决网络出口问题
再部署 sub2api
然后配置 Nginx
最后接 HTTPS 和 OAuth

因为只有按这个顺序，排障成本才最低。

很多时候，真正节省时间的不是命令敲得有多快，而是步骤顺序有没有走对。

从 0 到上线：我如何搭建自己的 Hugo 博客

Tue, 26 May 2026 13:05:00 +0800

这篇笔记记录了我从一台空白 Ubuntu 服务器开始，搭建并发布自己 Hugo 博客的全过程。

这次没有走现成面板，也没有用一键脚本，而是一步一步把域名、Nginx、HTTPS、Hugo 和主题都接起来。中间踩了不少坑，但也因此把整个链路摸清了。

一、准备工作

开始之前，服务器上已经跑着一个现有站点 sub2api，域名是 chen-api.cloud。因此这次部署博客时，有一个约束条件很明确：

不能影响现有的 sub2api
博客要部署到新子域名 blog.chen-api.cloud

这个前提决定了后面的 Nginx 配置不能覆盖原站点，只能新增一个独立 server。

二、先把 Hugo 站点跑起来

一开始最先遇到的是两个典型问题。

第一个问题是命令本身输错了。我先输入了大写的 HUGO，系统直接报错：

HUGO: command not found

后来确认应该使用小写命令：

hugo

第二个问题是配置文件 config.toml 写坏了。因为我最开始用 heredoc 写文件时，把 EOF 缩进了，结果它真的被写进了文件里，Hugo 解析时报错：

unmarshal failed: toml: expected character =

修正之后，最小配置大概是这样：

baseURL = "https://blog.chen-api.cloud/"
locale = "zh-cn"
title = "CHEN 的博客"

这里最大的教训是：如果不熟悉 shell heredoc，短文件直接用 printf 或者 nano 会稳很多。

三、给博客准备最小内容

为了先验证整条发布链路，我没有一开始就上复杂主题，而是先做了一个最小首页。

最早的问题并不是 Nginx，而是 Hugo 内容文件 _index.md 写坏了。比如：

YAML 头信息没有正确闭合
每行前面多了空格
文件末尾多写了一行 EOF

这会导致 Hugo 报错：

EOF looking for end YAML front matter delimiter

修正之后，一个最小可用首页类似这样：

---
title: "首页"
---

这是我的 Hugo 博客，已经部署成功。

等 Hugo 能正常构建出 index.html 之后，才适合继续往下接 Nginx。

四、Nginx 配置必须与现有业务并存

由于服务器上已经有 sub2api，部署前先检查了当前站点配置：

sites-enabled 里已有 sub2api
它处理的是 chen-api.cloud
没有占用 blog.chen-api.cloud

这说明博客可以安全新增一个站点，而不必修改原服务。

博客对应的 Nginx 配置逻辑非常简单：

server {
    listen 80;
    listen [::]:80;
    server_name blog.chen-api.cloud;

    root /var/www/blog;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

这里有个关键判断过程。当时博客域名第一次访问并不是 404，而是：

curl: (6) Could not resolve host: blog.chen-api.cloud

这说明问题根本不在 Nginx，而在 DNS。

五、域名解析是最容易忽略的一步

之后用 nslookup 检查，发现子域名一开始是 NXDOMAIN，也就是根本没有这条记录。

必须先去 DNS 后台添加：

类型：A
主机记录：blog
记录值：服务器公网 IP

等 DNS 生效之后，再次检查：

nslookup blog.chen-api.cloud

已经能正确解析到服务器 IP，这时候再访问 HTTP，才真正走到了 Nginx。

六、403 的根因不是权限，而是没生成首页

DNS 生效之后，博客域名开始返回 403 Forbidden。

这一步很容易误判成目录权限问题，但实际排查后发现根因是：

/var/www/blog 目录里没有 index.html
Hugo 因为内容文件错误，根本没有生成首页

也就是说，403 只是结果，真正的问题还是构建失败。

这次部署最大的经验之一就是：先看生成目录里有没有实际产物，再怀疑 Nginx。

七、HTTPS 比部署本身更顺利

当 http://blog.chen-api.cloud 能返回 200 OK 后，HTTPS 基本就是顺水推舟了。

直接使用 certbot --nginx 申请并挂载证书。过程中系统提示这个域名已经存在证书，于是选择了“重新安装已有证书”，而不是重新签发。

最终验证结果：

https://blog.chen-api.cloud 返回 200 OK
certbot.timer 已启用
证书会自动续期

到这里，博客已经算正式上线。

八、换主题时又踩到了 Hugo 版本坑

博客最初虽然可用，但只是一个临时首页，不像正式博客。后来我选择切换到 Hugo Theme Stack。

主题装上之后，新的问题出现了：

function "hash" not defined

排查后发现并不是主题坏了，而是服务器自带 Hugo 版本太旧：

当前版本：0.92.2
Stack 主题最低要求：0.157.0

所以必须升级 Hugo。

九、普通版 Hugo 还不够，必须用 extended

升级到新版本之后，构建又报了另一个错误：

TOCSS: failed to transform "/scss/style.scss"

这说明我虽然把 Hugo 升级了，但装的是普通版，不是 extended 版。

而 Stack 主题会编译 SCSS，因此必须安装官方 extended 版本。

替换完成后，最终版本变成：

hugo v0.161.1+extended

到这一步，主题才真正构建成功，博客首页也切换成了卡片式布局。

十、最终结果

现在这套博客已经具备了基础可用状态：

域名：blog.chen-api.cloud
Web 服务：Nginx
证书：Let's Encrypt
博客引擎：Hugo
主题：Stack
自动续期：certbot.timer

而且整个过程没有影响服务器上原来的 sub2api 服务。

十一、这次部署里最有价值的几个经验

最后总结几条我这次最有体感的经验：

1. 不要过早怀疑 Nginx

访问异常不一定是 Nginx 配错了，也可能是：

DNS 没生效
Hugo 没生成文件
内容文件格式写坏

2. heredoc 对新手并不友好

cat <<EOF 看起来方便，但实际非常容易因为缩进、结尾位置或者误输入，把 EOF 写进文件里。

短配置更推荐：

printf
nano

3. 主题和 Hugo 版本必须一起看

很多 Hugo 主题页面能打开，不代表你的本地环境就能跑。

一定要先确认：

主题最低支持版本
是否要求 extended

4. 先打通最小链路，再追求美观

这次如果一开始就折腾主题、菜单、页面细节，排障会困难很多。

正确顺序应该是：

Hugo 能构建
Nginx 能访问
DNS 正常
HTTPS 正常
再换主题和美化

十二、下一步

博客虽然已经上线，但现在还只是第一阶段。接下来我准备继续补这些内容：

关于页
归档页
搜索页
头像和侧边栏资料
更多正式文章

这篇文章本身，就是这个博客发布出去的第一篇“建站记录”。

博客已切换到 Stack 主题

Tue, 26 May 2026 12:00:00 +0800

博客已经部署完成，并切换到了 Hugo Theme Stack。

接下来会逐步补充文章、页面和更多配置。