茶叙记

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 1.webp 后可恢复。

1. 为什么会做 StartNest#

在做这个项目之前，我试过不少浏览器起始页和书签管理工具。有的页面做得很漂亮，但自定义空间有限；有的功能很完整，却又显得太重，打开之后像进入一个管理后台，而不是一个日常入口。

我想要的起始页，大概有几个很明确的要求：

常用链接要清楚：不是简单堆在一起，而是能按照用途分组；
编辑要顺手：添加、修改、排序这些操作不能太绕；
外观要可调：主题、壁纸、卡片密度这些细节会影响每天打开它时的感受；
数据要可控：最好能自己部署，能导出导入，不被某个平台绑定；
维护成本要低：我不想为了一个起始页长期养一台服务器。

所以 StartNest 从一开始就没有打算做成一个“大而全”的导航平台。它更接近一个个人工作台：把链接、搜索、天气、面板和外观配置都放在同一个地方，但尽量保持界面的克制和使用流程的直接。

2. StartNest 现在能做什么#

如果用一句话概括 StartNest，它就是一个可以自己部署、自己掌控数据的私人导航页。

但真正用起来之后，它不只是“放几个链接”这么简单。下面这些模块，是我目前比较满意的部分。

2.1 首页：时间、天气、搜索和链接入口#

StartNest 的首页保留了比较明确的起始页结构：顶部是时间、日期和天气信息，中间是搜索框，下面则是按分组整理的链接卡片。

搜索框支持在站内链接中检索，也可以直接跳转到搜索引擎。目前可以在 Bing 和 Google 之间切换。对我来说，这种设计比较符合起始页的使用习惯：如果要去一个常用网站，就点卡片；如果临时想查东西，直接输入关键词就好。

天气组件是可选的。开启自动定位后，它会根据浏览器定位显示当前天气；如果不想让起始页获取位置，也可以直接关闭。这里没有做得特别复杂，只是放一个足够轻量的信息提示。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 2.webp 后可恢复。

2.2 分组和链接：真正按照自己的习惯整理入口#

链接管理是 StartNest 最基础、也是最重要的部分。

现在它支持：

创建、编辑和删除分组；
为分组设置图标；
在分组下添加常用链接；
编辑链接标题、地址和描述；
调整分组和链接顺序；
通过编辑模式拖动链接排序。

我把编辑能力单独放在“编辑模式”里，是为了让日常使用时页面尽量干净。平时它就是一个普通起始页，点击卡片直接打开网站；需要整理时，再进入编辑模式，页面才会显示添加、编辑、删除和排序相关操作。

链接卡片也做了一些细节配置。比如卡片可以选择 1x1 或 1x3 两种尺寸：前者适合只显示图标的入口，后者适合带标题和描述的常用服务。图标也不只依赖网站 favicon，还可以使用内置图标、图片 URL，或者纯文字缩写。

这些配置单独看都不大，但放在一起会让导航页更贴近自己的使用习惯。因为每个人常用的网站不一样，每个链接的重要程度也不一样，起始页不应该只有一种固定排版。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 3.webp 后可恢复。

2.3 Web 面板：把常用网页变成侧边工作区#

StartNest 里还有一个我自己很喜欢的功能：Web 面板。

有些网页我并不一定想作为普通链接打开，比如一些监控面板、在线工具、轻量文档、内部服务入口。它们更适合像一个侧边工作区一样，随时打开、随时切换。

所以 StartNest 支持在设置里添加 Web 面板，并为每个面板配置：

标题；
URL；
图标；
描述；
打开方式；
是否启用；
显示顺序。

如果目标网站允许被 iframe 嵌入，就可以直接以内嵌面板的形式打开；如果不允许，也可以配置成新标签页打开。这个功能没有试图绕过网站自己的安全策略，只是给那些适合嵌入的工具一个更顺手的位置。

对我来说，Web 面板让 StartNest 不只是一个“去往别处的链接列表”，它也可以承载一点轻量工作的状态。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 4.webp 后可恢复。

2.4 外观设置：起始页应该看着舒服#

起始页是一个每天都会见到的页面，所以外观设置不是可有可无的小功能。

StartNest 目前支持：

浅色、深色、跟随系统 三种主题模式；
舒适 / 紧凑 两种卡片密度；
是否显示分组图标；
自定义全局壁纸；
调整壁纸遮罩强度；
调整背景模糊程度。

我没有把外观系统做得特别花。比起提供很多复杂主题，我更希望它能覆盖几类最常见的偏好：有人喜欢干净的纯色界面，有人喜欢放一张背景图；有人希望卡片更宽松，有人希望一屏里放下更多入口。

这些设置都放在同一个设置页里，修改之后会直接生效。对于一个个人起始页来说，这种“调一下就能看到结果”的体验会舒服很多。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 5.webp 后可恢复。

2.5 数据管理：导出、导入和自己掌控#

StartNest 是一个自托管项目，所以数据管理不能只停留在“存在数据库里”。

现在它支持通过 JSON 导出和导入配置，包括分组、链接、设置和 Web 面板。这样即使以后换部署环境，或者想把当前配置备份一份，也不需要去数据库里手动折腾。

这件事看起来不复杂，但我觉得很重要。很多个人工具真正能不能长期使用，往往不取决于第一天看起来多漂亮，而取决于它有没有给用户留下迁移和备份的余地。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 6.webp 后可恢复。

3. 为什么选择 Cloudflare#

StartNest 的部署目标是 Cloudflare Workers + Workers Assets + D1。

这套组合很适合这种小型私人 Web 工具：前端静态资源由 Workers Assets 托管，后端 API 跑在 Cloudflare Worker 上，数据存在 D1 数据库里。整个项目不需要单独准备服务器，也不需要维护传统意义上的后端运行环境。

我选择 Cloudflare 的原因也比较直接：

部署成本低：个人使用场景下，免费额度通常已经足够；
维护负担小：不用自己管理 VPS、进程、反向代理和数据库服务；
全球访问还不错：Cloudflare 的边缘网络本身就适合这种轻量应用；
前后端可以放在同一个 Worker 项目里：登录、API、静态资源和数据库访问都比较集中；
D1 足够应付这种数据量：链接、分组、设置、面板这些结构并不复杂。

当然，这也意味着它不是一个纯静态站点。StartNest 需要 Worker 后端处理登录、API、D1 数据库访问和前端资源托管，所以部署时不能只按照 Cloudflare Pages 的普通静态站点方式来理解。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 7.webp 后可恢复。

4. 技术上，它是怎么组成的#

如果你也对实现方式感兴趣，StartNest 目前主要用到这些技术：

React 19 作为前端 UI 框架；
Vite 负责前端开发和构建；
TypeScript 作为主要语言；
Tailwind CSS 负责界面样式；
React Router 处理页面路由；
TanStack Query 管理前端请求和缓存；
Zod 做数据结构校验；
Cloudflare Workers 承载后端 API；
Cloudflare D1 保存分组、链接、设置、用户资料和面板数据；
Wrangler 负责本地开发、迁移和部署。

项目结构也比较清楚：

1
src/          前端应用
2
worker/       Cloudflare Worker 后端
3
migrations/   D1 数据库迁移 SQL
4
public/       静态资源与 service worker

后端接口主要围绕几个核心资源展开：分组、链接、排序、设置、导入导出、用户信息、Web 面板和天气数据。前端启动时会通过 /api/bootstrap 拉取基础数据，并在本地做缓存和状态更新。

登录方面，StartNest 使用管理员账号和密码进行访问控制，并通过 SESSION_SECRET 签名 session。它不是一个多用户平台，目标很明确：保护自己的私人起始页，不让它变成公开可编辑的导航站。

5. 部署和使用上的一些提醒#

StartNest 已经准备了 Cloudflare 部署相关配置，但部署前仍然需要自己准备 D1 数据库和必要的环境变量。

核心步骤大致是：

创建 Cloudflare D1 数据库；
按顺序执行 migrations/ 里的 SQL 迁移；
在 Worker 项目中绑定 D1，binding 名称保持为 DB；
配置 ADMIN_USERNAME、ADMIN_PASSWORD、SESSION_SECRET；
使用 npm run build 构建前端；
通过 Wrangler 或 Cloudflare 控制台部署 Worker。

这里最容易出问题的地方通常有两个：一个是 D1 binding 名称没有保持为 DB，另一个是没有配置完整的 Secrets。只要这两块处理好，后续使用基本就是普通 Web 应用的体验。

首次访问时会进入登录页，登录之后就可以开始创建分组、添加链接、设置外观和管理 Web 面板了。

项目截图占位：当前仓库未包含该文原始截图文件，后续补回 8.webp 后可恢复。

6. 现在的状态与后续想法#

StartNest 目前还是一个比较年轻的项目，但核心功能已经能支撑日常使用了。

我之后可能还会继续打磨这些方向：

优化移动端和小屏设备上的编辑体验；
给链接和面板增加更多整理方式；
让图标选择和壁纸配置更直观；
继续减少部署过程中的理解成本；
补充更多导入、备份和迁移相关的细节。

我对 StartNest 的期待并不是做成一个很大的产品。它更适合保持在一个私人工具的尺度里：功能够用，界面干净，数据可控，部署之后不需要经常操心。

7. 如果你也想试试看#

项目已经开源在 GitHub 上：

GitHub：https://github.com/Liebesfreud/StartNest

如果你也想要一个基于 Cloudflare 的自托管起始页，希望把常用链接、搜索、天气、Web 面板和外观偏好都放在自己掌控的环境里，StartNest 应该会是一个值得试试的小工具。

它没有试图替代浏览器，也没有想成为一个复杂的书签系统。它只是把每天打开浏览器时最常见的那些入口，整理成一个更适合自己的页面。

从 Windows 换成 Linux ？Fedora 44 体验与排障

Thu, 14 May 2026 00:00:00 GMT

其实我使用 Linux 已经一年多了，不过之前主要是在 VPS 里用，常见的环境也就是 Debian 和 Alpine。桌面版 Linux 虽然在虚拟机里体验过几次，却从来没有真正作为主力系统长期使用。

这次决定把笔记本从 Windows 11 LTSC 换成 Linux，起因有点朴素：我发现 Codex 对 PowerShell 的命令并不算适配，而 PowerShell 本身又偏复杂，我也不太愿意继续迁就它。

刚好手上这台 ThinkPad P14 Gen 1 平时主要用来 Vibe Coding、看文献，没有游戏或大型软件的需求。虽然我给它加装了 16GB 内存，但低压十代 i7 加上状态不太健康的电池，让它在 Windows 11 下的日常体验并不理想。台式机可以承担更重的任务，所以这台笔记本只需要一个轻快、稳定、适合写作和开发的系统。

一开始我也考虑过黑苹果，但 16GB 左右的镜像体积让我觉得过于臃肿。再加上如今 macOS 已经全面转向 ARM，x86 设备安装新版本 macOS 的体验只会越来越边缘化。想清楚这些之后，我最终决定直接安装 Linux，而且不再保留双系统。

为什么选择 Fedora#

接下来的问题就是选择发行版。Ubuntu 对我来说有些无趣，也略显臃肿；Debian 更像是适合 VPS 的系统，作为桌面主力总觉得少了点新鲜感；Arch 的社区和文档非常好，我之前也在虚拟机里体验过，但这台笔记本毕竟要承担日常使用，我还是更希望它稳定一些。

选来选去，最后落在了 Fedora 上。

Fedora 桌面版同时提供 GNOME 和 KDE 两种主流体验。我选择的是 GNOME 版本，安装流程整体很顺畅：下载镜像、制作启动盘、进入安装器、处理分区，然后等待安装完成。相比 Debian 和 Arch，Fedora 的安装体验确实轻松很多，真正需要留意的主要是分区。

因为我已经决定完全替换 Windows，所以安装时直接删除原来的 C 盘，让它变成未分配空间；同时也把 Windows 恢复分区一并清理掉，避免留下无用分区。只要确认数据已经备份，这一步其实并不复杂。

从 GNOME 到 Niri + DMS#

安装完成后，我使用 GNOME 体验了一段时间。它确实简洁、美观，也很现代，但对我来说稍微有些“简陋”。一些交互逻辑和我目前的使用习惯有出入，需要适应；而 KDE 虽然功能丰富，却又显得复杂，需要投入不少时间去美化和调整。

于是我把目光转向了 Niri + DMS，并了解到了 Dank Linux 这个项目。

Dank Linux

Dank Linux 是一套基于 Wayland 的桌面 shell 套件，目标是替代 GNOME Shell / KDE Plasma，提供一个现代、好看且高度可定制的桌面体验。它基于 Quickshell 和 Go 构建，很适合觉得 GNOME 太简、KDE 太重的用户。

安装方式也很直接：

Terminal window

1
curl -fsSL https://danklinux.com/install | bash

这个一键脚本会自动检测发行版、安装依赖并配置 DMS。安装完成后，再简单调整一下壁纸、面板和主题，就可以得到一个相当漂亮的桌面环境。

NVIDIA 驱动排障#

桌面环境折腾完之后，就该处理真正影响体验的问题了：NVIDIA 驱动。

这台笔记本的独显是 NVIDIA Quadro P520。最开始我一直装错驱动版本，导致内核提示 NVIDIA 模块丢失。后来在 Codex 的帮助下才确认：Quadro P520 / GP108 并不适合使用 NVIDIA 595 open kernel module。之前的核心报错大意是：not supported by open nvidia.ko，以及缺少 GPU System Processor（GSP）支持。

正确方案是安装 RPM Fusion 提供的 580xx proprietary 驱动：

Terminal window

1
# 安装驱动
2
sudo dnf install -y --allowerasing akmod-nvidia-580xx
3
sudo dnf install -y --allowerasing xorg-x11-drv-nvidia-580xx
4
sudo dnf install -y --allowerasing xorg-x11-drv-nvidia-580xx-libs
5
sudo dnf install -y --allowerasing xorg-x11-drv-nvidia-580xx-power
6
sudo dnf install -y --allowerasing xorg-x11-drv-nvidia-580xx-cuda-libs
7
sudo dnf install -y --allowerasing nvidia-settings-580xx
8

9
# 禁用 nouveau
10
sudo grubby --update-kernel=ALL --args='rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core nvidia-drm.modeset=1'
11

12
# 重建并重启
13
sudo akmods --force
14
sudo dracut --force
15
sudo reboot
16

17
# 验证
18
modinfo nvidia | grep -E 'filename|version|license'
19
nvidia-smi
20
lspci -nnk | grep -A4 -Ei 'nvidia|3d'

Fcitx5 与 Edge 的输入法问题#

驱动处理完之后，我又遇到了另一个很影响日常使用的问题：Fcitx5 在 Edge 中时好时坏，候选框有时不出现，有时位置异常。

这个问题大概率和 Flatpak 沙箱、Wayland 输入法支持、Edge 启动参数以及 niri 的环境变量有关。尤其要注意 --ozone-platform-hint=auto，它可能导致 Wayland / XWayland 之间的行为不稳定；另外也不要让 niri 把输入法变量覆盖成类似 GTK_IM_MODULE null 的状态。

我的处理思路是先统一环境变量。系统级配置可以写在 ~/.config/environment.d/80-fcitx5.conf，niri 则需要检查 ~/.config/niri/config.kdl 里的 environment 块：

1
environment {
2
    GTK_IM_MODULE "fcitx"
3
    QT_IM_MODULE "fcitx"
4
    XMODIFIERS "@im=fcitx"
5
    INPUT_METHOD "fcitx"
6
    SDL_IM_MODULE "fcitx"
7
    GLFW_IM_MODULE "ibus"
8
}

如果 Edge 是通过 Flatpak 安装的，还需要给它放行 Fcitx5 的 DBus，并注入对应环境变量：

Terminal window

1
flatpak override --user \
2
  --talk-name=org.fcitx.Fcitx5 \
3
  --env=GTK_IM_MODULE=fcitx \
4
  --env=QT_IM_MODULE=fcitx \
5
  --env=XMODIFIERS=@im=fcitx \
6
  --env=INPUT_METHOD=fcitx \
7
  --env=SDL_IM_MODULE=fcitx \
8
  --env=GLFW_IM_MODULE=ibus \
9
  com.microsoft.Edge

最后，在 ~/.var/app/com.microsoft.Edge/config/edge-flags.conf 中强制 Edge 使用 Wayland，并开启 Wayland IME：

1
--enable-wayland-ime
2
--ozone-platform=wayland

这里不要使用 --ozone-platform-hint=auto。改完之后重新登录桌面，输入法候选框的稳定性会好很多。

小结#

总体来说，把这台 ThinkPad 从 Windows 换到 Fedora 之后，我的感受是：它并没有立刻变成一台“完美电脑”，但确实更接近我现在想要的使用方式了。

Fedora 提供了足够新的软件栈和相对稳定的底座，Niri + DMS 则补上了 GNOME 和 KDE 都没能完全满足我的桌面体验。真正麻烦的地方主要集中在 NVIDIA 驱动和 Wayland 输入法兼容性上，不过在解决掉这些问题后，日常写作、开发、阅读文献都已经足够顺手。

如果手上的设备本来就不是游戏主力，也没有特别依赖 Windows 专属软件，那么把它换成 Linux 并不是一件多么激进的事。至少对这台笔记本来说，Fedora 让它重新变得轻快、安静，也更适合我现在的工作流。

「Gogs」自建 Git 服务，与 GitHub 同步推送

Tue, 05 May 2026 00:00:00 GMT

如果你和我一样，平时会写一些小工具、学习笔记，甚至还会顺手把带密码的配置文件塞进仓库里，那你大概率也会有一个念头：并不是所有东西都想直接放到 GitHub 上。

我之前也用过 Gitea。它确实成熟、完整，界面和 GitHub 也很接近，但对我这种只是想随手托管几个小项目的人来说，多少还是显得有点重了。尤其是我并不需要 CI/CD、组织协作之类的功能，只想要一个轻量、稳定、占用低的 Git 服务。

于是我把目光转向了 Gogs。

它给我的第一感觉很直接：足够轻，足够简单，也足够适合个人使用。 更重要的是，配合 Git 本身的多推送地址能力，我们还可以做到：代码平时先推到自己的 Gogs，需要公开同步时再一起推送到 GitHub。

1. 为什么我会选择 Gogs#

对于一台 1C1G 的小机器来说，Gogs 的负担几乎可以忽略。界面和 GitHub 也比较接近，基本不用重新适应；而它又没有那么多我平时根本用不上的附加功能。

对我来说，Gogs 最合适的使用场景就是：

托管日常写的小项目
存放不想直接公开的代码和笔记
作为自己的私人 Git 中转站

如果你和我一样，更看重“能用、够轻、维护省心”，那 Gogs 的确很适合作为个人自建 Git 服务的选择。

2. 用 Docker 部署 Gogs#

Gogs 的部署非常简单，用 Docker Compose 基本十几分钟就能搞定。

2.1 创建目录#

先准备一个工作目录：

Terminal window

1
mkdir -p ~/docker-projects/gogs
2
cd ~/docker-projects/gogs
3
mkdir -p data

2.2 编写 docker-compose.yml#

在当前目录新建 docker-compose.yml：

1
services:
2
  gogs:
3
    image: gogs/gogs:latest
4
    container_name: gogs
5
    restart: unless-stopped
6
    ports:
7
      - "127.0.0.1:10880:3000"
8
      - "10022:22"
9
    volumes:
10
      - ./data:/data
11
    environment:
12
      - RUN_CROND=true
13
      - BACKUP_INTERVAL=24h
14
      - BACKUP_RETENTION=7d

2.3 启动服务#

然后执行：

Terminal window

1
docker compose up -d

启动完成后，在浏览器中打开 Gogs 的安装页面，按照向导完成初始化即可。Gogs 支持多种数据库，如果只是个人使用，按默认方式一路配置下去就够了。

首次注册的账号默认就是管理员账号，后面创建仓库、配置 SSH Key 等操作都可以在后台直接完成。

3. 让 Git 克隆和推送更顺手#

如果你把 SSH 服务映射到了非默认端口，比如上面示例里的 10022，那么仓库地址通常会变成这样：

1
ssh://git@你的域名:10022/用户名/仓库.git

这个地址当然能用，但每次手敲都比较麻烦。

所以我更推荐在本地 ~/.ssh/config 里加一个别名：

1
Host mygit
2
    HostName 你的域名
3
    Port 10022
4
    User git

这样以后克隆仓库时，就可以直接写成：

Terminal window

1
git clone mygit:用户名/仓库.git

日常 push、pull 也都会顺手很多，用起来和 GitHub 基本没什么区别。

4. 优先用 GitHub 镜像到 Gogs 做备份#

这部分其实才是更适合长期使用的方案。

因为 Gogs 本身支持创建镜像仓库，可以直接把 GitHub 仓库镜像到 Gogs。这样 GitHub 继续作为主仓库使用，Gogs 则承担自托管备份的角色，本地仓库也只需要维护 GitHub 这一套主要 remote。

有些仓库我希望：

平时继续以 GitHub 作为主仓库
在自己的服务器上保留一份自托管备份
保持同一套本地仓库，不想额外维护双 push 配置

如果是这种需求，我更推荐直接用 GitHub → Gogs 的镜像仓库。

4.1 双 push 作为备选项#

如果你希望在每次本地推送时，同时把代码发到 GitHub 和 Gogs，那么也可以给同一个 origin 配置多个 pushurl，把双 push 作为备选方案。

4.2 假设你有两个远程地址#

GitHub 仓库地址：

1
git@github.com:你的用户名/项目名.git

Gogs 仓库地址：

1
git@你的Gogs域名:用户名/项目名.git

4.3 先清理旧的 pushurl#

如果之前已经改过推送地址，建议先清空，避免配置混乱：

Terminal window

1
git config --unset-all remote.origin.pushurl

4.4 添加两个推送地址#

然后分别添加 GitHub 和 Gogs：

Terminal window

1
git remote set-url --add --push origin git@github.com:你的用户名/项目名.git
2
git remote set-url --add --push origin git@你的Gogs域名:用户名/项目名.git

4.5 检查配置是否生效#

执行：

Terminal window

1
git remote -v

你应该能看到类似下面这样的结果：

1
origin  git@github.com:你的用户名/项目名.git (fetch)
2
origin  git@github.com:你的用户名/项目名.git (push)
3
origin  git@你的Gogs域名:用户名/项目名.git (push)

这里的意思是：

fetch 仍然从 GitHub 拉取
push 时会同时推送到 GitHub 和 Gogs

当然，如果你更希望默认从 Gogs 拉取，也可以反过来设置 fetch 地址。

4.6 之后怎么推送#

配置完成后，日常直接执行：

Terminal window

1
git push

或者指定当前分支：

Terminal window

1
git push origin main

都可以同时推送到两个远程地址。

5. 这套方案适合什么人#

如果你需要的是完整的团队协作、权限体系、CI/CD 流程，甚至还要接各种插件和企业功能，那 Gitea 或 GitLab 显然更适合。

但如果你和我一样：

只想托管自己的项目
希望资源占用尽量低
有些内容不想直接公开
又想保留同步到 GitHub 的能力

那 GitHub + Gogs 镜像备份 这套组合会更省心。

它不花哨，也没有太多复杂概念，但正因为足够简单，反而特别适合个人开发者长期使用。

写在最后#

这次从 Gitea 换到 Gogs，并不是因为 Gitea 不好，而是因为我想要的东西其实很明确：

一个更轻量的自托管 Git 服务，以及一套能兼顾私有存储和公开同步的工作流。

Gogs 刚好满足了这一点。

部署快、占用低、上手简单，再加上 Gogs 自带的镜像仓库能力，用来给 GitHub 做一份自托管备份也很合适。即使你不想用镜像仓库，Git 自带的多推送配置也能作为备选。对于 VPS 资源有限、又想把代码掌握在自己手里的用户来说，这确实是一种很舒服的方案。

「Hermes Agent」龙虾的完美代替品？

Sat, 25 Apr 2026 00:00:00 GMT

前言#

相信你已经非常了解 OpenClaw ，也就是“龙虾”个项目。出圈的爆火让这类 AI Agent 助手项目进入到了大众视野，OpenClaw 聊天渠道多、控制面板完整、节点能力也很丰富，但我认为这个项目还远远不够成熟，小 Bug 不少。所以在简单体验了一段时间的 OpenClaw 后，它就在我的服务器上吃灰了，也许是云端部署限制了它的能力，但目前我认为它能做的事，Codex、ClaudeCode 也能做，甚至能做的更好。

但如果你真正想要的是一个“能长期记住你、会自己总结经验、还能持续替你干活”的常驻代理，那么 Hermes Agent 现在已经不只是一个替代品，而是更像 OpenClaw 这条路线的下一步。 截至 2026 年 4 月，Hermes 官方已经明确提供了从 OpenClaw 自动迁移 settings、memories、skills 和 API keys 的能力，这样我们无缝切换至 Hermes Agent 变得方便不少。(OpenClaw)

说得再直白一点：如果你要的是一个常驻在线、能通过聊天工具对话、还能自己记住工作方式并长期复用的 agent，Hermes 已经足够替代 OpenClaw；不过，如果你特别依赖 OpenClaw 的生态以及外围能力，那就别急迁移，再等一等吧，或许还有更好的 Agent 项目出现。

1. 部署 Hermes Agent#

1. 1 前期准备#

一台服务器，以2c2g 的 Debian 13 服务器为例
一个 LLM API Key
一个 Telegram Bot Token
你自己的 Telegram 数字用户 ID

Hermes 官方安装文档里写得很直接：Linux 快速安装的唯一前置条件其实是 Git，其它像 uv、Python 3.11、Node.js v22、ripgrep、ffmpeg，安装器都会自动处理。(hermes-agent.nousresearch.com)

1. 2 安装 Hermes Agent#

首先确保你的服务器一键安装好了 Git 和 xz 解压程序，不然会报错：

1
# 安装 Git
2
apt update && apt install git
3

4
# 安装 xz
5
apt install -y xz-utils

根据官方文档，可以使用一键脚本进行安装：

1
# Linux / macOS / WSL2 / Android (Termux)
2
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

完成后，重新加载终端：

1
source ~/.bashrc

1.3 初始化设置#

1
hermes model # 选择你的 LLM 提供商和模型
2
hermes tools # 配置启用哪些工具
3
hermes setup # 或一次性完成所有配置

如果你输入：

1
hermes setup

就能看到类似OpenClaw的初始化设置：

这时候只要跟着步骤一步步来就可以了，首先是选择AI的提供商：

这一步是设置Hermes Agent的消息渠道，我们选择Telegram：

创建 Telegram Bot

打开 Telegram，搜索并启动 BotFather（它是 Telegram 官方的机器人管理工具）。
发送 /newbot 命令，按指示创建一个新的机器人。你将需要提供一个名称和用户名，Telegram 会为你生成一个唯一的 API Token。
- 你将获得一个类似下面的 API Token（记下来）：
  123456789:ABCDEFghijkLMNOPQRstuvwxyz 获取聊天ID，在Telegram，不少机器人能获取到聊天ID，自行获取，然后将BOT API Token和聊天ID根据指引填入：

启动网关

这样就完成 Hermes Agent 的安装和初始化了。

2. 实战应用#

2. 1 第一次对话#

在新的终端中输入hermes，你会看到一个欢迎横幅，上面有你的模型、可用工具和技能。

输入信息并按 Enter 键，一切顺利的话，就能看到回复了：

2.2 多个Agent#

在Hermes Agent中，每个配置文件（profile）都是一个完全隔离的环境，拥有自己的目录，包含独立的 config.yaml、.env、SOUL.md、记忆、会话、技能、定时任务和状态数据库。

这样如果我们需要一个Agent接入Telegram写代码，一个Agent接入QQ日常对话就只需要创建多个配置文件（profile）就可以了，创建方法如下：

1
# 创建空配置文件
2
hermes profile create 新配置文件名
3

4
# 克隆当前配置文件（仅配置）
5
hermes profile create 新配置文件名 --clone
6

7
# 克隆当前配置文件（全部）
8
hermes profile create 新配置文件名 --clone-all
9

10
# 克隆指定配置文件
11
hermes profile create 新配置文件名 --clone --clone-from 指定配置文件名

Note

其他内容等我用一段时间再更新

「我的项目 NextRep」我开发了一个开源健身记录APP

Sat, 28 Mar 2026 00:00:00 GMT

前段时间我一直想找一个真正顺手的健身记录工具。

很多优秀的 App 只提供 IOS 版本，而安卓的健身 App 要不就是收费高昂，要不就是复杂且 UI 丑陋，作为一个轻度健身小白，我只需要它能帮我简单记录力量训练和有氧，能看见体重和围度的变化趋势，最好还能在我训练完之后，帮我做一点总结和分析。

可惜试了一圈之后，我总觉得差一点意思。有的 App 界面太重，功能很多，但真正开始训练的时候反而不够顺手。另外很少有类似的开源 App，毕竟训练数据、体重变化、身体围度这些东西，说不上多敏感，但我还是更希望它们安安静静地留在本地。

于是最后，我决定借助 AI 的力量，自己做一个完全符合自己要求的健身 App。

它叫 NextRep，一个 AI 驱动、离线优先、隐私友好的本地健身记录 APP。

Liebesfreud

NextRep

1. 为什么会做 NextRep#

我觉得健身记录这件事，我需要简单记录如“今天卧推多少公斤、做了几组”这种数据。但这只是最基础的功能，而我很在意另外一些东西：最近力量有没有进步、体重变化是不是符合预期、哪类动作练得最多、自己这段时间的训练偏好是什么、今天这组训练到底算不算有效。

这些信息其实都藏在日常记录里，我可以很简单的使用 AI 分析这些数据。所以 NextRep 的想法就慢慢明确了：

先把记录这件事做顺手：训练中能快速输入，尽可能简单
再把数据真正利用起来：不只是堆在那里，而是能看趋势、看偏好、看变化
最后交给 AI 做总结和辅助分析：让记录不只是归档，而是能够看到参考意见

以及最重要的一点：尽量把数据留在本地。

NextRep 目前使用本地 SQLite 存储训练记录、身体数据和配置，整体是一个很明显的离线优先思路。除了你主动配置的 AI 接口调用之外，核心数据不会上传云端去。这种让数据完全掌握在自己手里的感觉对我来说很安心。

2. NextRep 现在能做什么#

如果要一句话概括，我会说它已经不是一个“简单打卡工具”，而是一个比较完整的个人训练记录系统。

2.1 首页：保证基础功能，简单易用#

首页是我最在意的一块，因为这决定了它是不是“训练时愿意打开”的 App。

NextRep 目前支持：

力量训练记录：可以逐组记录重量、次数、完成状态和 RPE；
有氧训练记录：记录力量训练后的有氧燃脂数据；
每日打卡：训练完成后会有一点轻量反馈，不至于太死板；
训练热力图：能直观看到自己这一个月到底练了多少天。

我比较喜欢的一点是，它不是把数据冷冰冰地堆成表格，而是尽量保留一种“训练中心”的感觉。你打开它的时候，看到的是今天该做什么、做到了什么，而不只是历史数据列表。

2.2 看板：让训练记录真正变成可读的数据#

我一直觉得，记录本身不是目的，看见变化才是。所以 NextRep 里单独做了一个数据看板，用来整理身体数据和训练偏好。这里面现在已经有：

体重、围度等身体统计卡片；
趋势对比，可以更直观地看最近的变化；
训练偏好分析，比如自己更偏向哪些动作和训练类型；
AI 身体评估与建议，把原始数据转成更容易理解的描述。

2.3 AI 教练：这是我最想做的部分#

NextRep 支持接入 OpenAI 兼容的 Chat Completions API。配置好模型之后，它会结合最近的训练记录和身体数据，把这些上下文一起交给 AI，做训练分析、制定训练计划。这意味着你可以把它当作一个更懂你近期状态的训练助手不是那种“强行加 AI”的噱头感，而是让 AI 真正站在已有数据上说话。比起无上下文地聊天，这种方式会有用得多。

2.4 设置与数据管理：我希望它能长期使用#

很多小项目都会把“设置页”做成一个很边缘的东西，但我自己真的会在意这部分。

NextRep 现在已经支持：

自定义动作库管理；
多模型配置和切换；
JSON 数据导入 / 导出；
本地数据清理。

这几项虽然不算最显眼，但很重要。因为只有当一个 App 允许你管理自己的动作、掌控自己的模型、备份自己的数据，它才更像一个能长期使用的个人工具，而不是一个一次性玩具。

3. 为什么我会喜欢这种“本地优先”的方式#

这大概也是 NextRep 最核心的气质。

现在很多应用默认就是账号、云同步、服务器、在线状态，仿佛不联网就什么都做不了。但健身记录在我看来，其实是非常适合本地化的一类应用：

数据结构相对稳定；
使用场景高频但个人化；
很多时候并不依赖多人协作；
用户真正关心的是响应快、记录顺、数据不丢。

所以 NextRep 选择了 Drizzle ORM + expo-sqlite 这一套本地数据方案，把训练数据、身体数据和配置都留在设备上。这样做当然意味着它暂时不会是那种“大而全”的平台型产品，但我反而觉得这正是它舒服的地方。

4. 技术上，我是怎么把它做出来的#

如果你也对这类 App 的实现感兴趣，NextRep 目前主要基于下面这套技术栈：

Expo SDK 55 + React Native 0.83
Expo Router 做文件系统路由
NativeWind v4 负责样式
Moti + Reanimated 4 处理动画和交互反馈
Drizzle ORM + expo-sqlite 做本地数据库
TypeScript 作为主要语言

5. 现在的版本与后续想法#

NextRep 当前已经发布到了 v1.2.0。不过说实话，它在我眼里仍然是一个正在继续生长的项目。我之后还想继续慢慢打磨它，比如：

继续优化训练记录流程，让输入更自然；
丰富看板里的数据维度和可视化；
让 AI 教练的总结更贴近真实训练语境；
再补一些我自己训练中真正会用到的小功能。

我现在越来越喜欢这种状态：不是为了做一个“看起来很大”的产品，而是做一个自己愿意长期打开、愿意持续维护的东西。

6. 如果你也想试试看#

虽然这个项目还不算特别成熟，可能还有不少 bug，但项目已经开源在 GitHub 上了：

GitHub：https://github.com/Liebesfreud/NextRep

如果你刚好也在找一个更偏本地、更重视隐私、同时又想把 AI 真正用进训练记录里的工具，也许可以试试看。说到底，NextRep 对我来说并不只是一个“健身打卡 App”。

它更像是我把自己对训练、对记录、对工具感受的一些想法，慢慢做成了一个真的可以握在手里的东西。

从0开始打造我的草缸

Sat, 28 Mar 2026 00:00:00 GMT

有时候想给生活找一点安静，不一定非要从什么宏大的目标开始。对我来说，可能只是从一只空缸开始。

自从读研之后状态一直有点紧绷。白天被各种事情推着走，回到宿舍之后，刷一会B站、玩一会游戏，这一天就过去了。也一直在找机会出去走走，扫扫街，拍拍照，但在成都，阳光明媚的日子总是少见的。阴天的时候也想找点什么事情，让自己慢一点、安静一点，最好还是那种能长期看着它一点点变好的爱好。

于是，我把目光放到了草缸上。

之前也零零散散看过不少别人的开缸分享，总觉得那是一种很特别的治愈：在几十厘米见方的玻璃缸里，摆石头、铺泥、种草、开灯、等水清，最后看着鱼虾在里面慢慢活动起来，像是把一小块水塘搬回了桌面。

所以这次，我决定认真从 0 开始，给自己搭一个真正属于我的草缸。

1. 开缸前的准备工作#

一开始其实没有那么复杂，只是单纯觉得——我想给自己找一个能长期投入、又能带来反馈的小世界。

摄影是按下快门的瞬间，写博客是把想法慢慢整理出来，而草缸更像是另一种节奏：它不是立刻给你答案，而是让你在每天开灯、换水、修剪的过程里，慢慢看到变化。而且草缸真的很适合在学习和生活节奏偏满的时候存在。当看着气泡从叶片上慢慢升起的时候，整个人会莫名安静下来。那种感觉很难形容，但确实很解压。

第一次开缸，在小红书上搜了很多教程和思路，但我一开始并不像投入太多，所以我这次准备的思路很简单：

先把超白缸、水草灯、底床这些必须配置补齐
选相对好养的无碳水草，降低翻车概率
考虑选择一些皮实的冷水鱼虾

如果你也和我一样，是第一次接触草缸，那前期真的不用把自己搞得太焦虑。把必备物品准备好，剩下的可以边养边优化。

这次开缸用到的基础物品#

超白缸：因为想打造的是桌面小草缸，所以选择了20 x 20 x 20的尺寸，有足够的造景空间，在桌面上也不太占地方。
水草灯：这个可以根据自己的水体计算，差不多是1升水对应0.8-1w的功率，最好选带透镜的，不然会很刺眼。
水草泥：市面上有非常多假的水草泥（其实是陶粒），所以选对品牌是非常重要的，尼特利应该是非常知名的品牌了，不过我选择了它的上游代工厂的产品，兰保的水草泥，性价比会更高一些。
造景石：这个完全是个人主管选择，你可以路上捡几块，也可以网购一些特殊石头，我买的是所谓的黑金石，价格便宜，棱角分明还带有一些金色。
水草：因为我不打算上二氧化碳设备，所以选择了无碳的水草，前景我选的是天胡荽，中景为罗贝利，后景为高珍珠，记得选择无菌杯水草。
鱼：我选择的是白云金丝，冷水鱼体型小，相对好养活。

2. 从空缸到注水：开缸全过程#

等到所有所需的物品到齐后就可以开缸了

先是洗缸、擦缸，然后把水草泥慢慢铺进去，水草泥的量大概需要保证铺满鱼缸，并且厚度至少为5cm，为了有一定的层次感，建议把水草泥铺成前低后高的小坡。
放入造景，选几块合适的造景石，用清水多次清洗，直到清洗过的水不再浑浊，放入鱼缸摆好造型。
处理水草，将水草从无菌杯中取出，浸入水中，用手轻轻搓掉水槽根部的凝胶，然后分成一小簇一小簇。
可以往鱼缸内少量加水，确保水草泥表面湿润，接下来就可以用镊子或者其他工具，把水草插入水草泥中，对于需要爬地的前景草而言，要种的深一些，只露出一点叶子就行了。
随后沿着缸壁缓缓住满水，就大功告成了！

有些草一夹起来就散，有些刚插下去又浮起来，手稍微重一点，前面铺好的底床就被带乱。那一刻你会深刻理解，为什么很多人说草缸是“细致活”。
但很奇怪，虽然过程挺慢，我却没有不耐烦。反而有一种久违的专注感，像是终于可以只做眼前这一件事，不用同时分心很多东西。

4. 注水之后，才是真正的开始#

造景完成、注满水、打开水草灯的那一刻，不过是生态三无草缸的开始。新缸前期最重要的事情，不是急着放鱼或虾，而是让系统先稳定下来。观察一下水会不会浑？水草有没有融叶？

水草泥前期的肥力太高，一定要记得勤换水，每次换差不多1/2的水。等差不多一周过后，水体趋于稳定，这时候就可以放入那些闯缸鱼/虾了。然后根据后续的变化，加入新的生物或是修建水草。

你不会在第一天就看到“成景”，但你会慢慢看到缸的状态往好的方向走。那种感觉特别微妙，有点像照顾一个刚刚诞生的小系统，也像在生活里给自己保留了一点持续期待的东西。

写在最后#

在草缸面前，你很难一直处于那种特别焦躁的状态里。你会下意识放慢动作，去看水流、看叶片、看灯光落下来之后的层次变化。那些平时很容易被忽略的小细节，在这个小小的玻璃缸里反而变得非常清晰。

它像是把“照顾”这件事情具体化了。

你给它时间，它就给你状态；你愿意稳定地维护，它就会慢慢变得越来越舒服。

这种反馈很温柔，也很直接。所以我现在很喜欢在晚上开着灯看它一会儿。

不需要很久，哪怕只是几分钟，也会觉得这一天终于有了一个柔和的收尾。

从 0 开始搭起这样一个小世界，对我来说更像是一种生活练习：

认真准备，慢慢动手，接受过程里的不完美，然后等待时间把一切养好。

如果你最近也想给自己的生活找一点新的寄托，或许真的可以试试草缸。

它占据的空间不大，却会在很多普通的夜晚里，给你一个安静看一会儿的理由。

嗯…等它再长一阵子，我应该还会继续记录它后面的样子。

「CLIProxyAPI × Octopus」API反代 & 集中管理

Sun, 08 Mar 2026 00:00:00 GMT

“工具不在多，在于你能不能用一把钥匙打开所有的门。”

如果你和我一样，手上同时有好几种 AI 接入方式/工具：

官方订阅账号，比如 Gemini、Claude、OpenAI 这类订阅计划中包含 CLI 工具的服务
一些平台提供的 API Key
公益站、第三方渠道、临时月抛Team车位之类的补充来源

那你大概率也遇到过下面这些问题：

每家接入方式都不一样：有的走 OAuth 登录，有的只给 API Key，Claude与标准Open AI的协议还不完全兼容。
工具链很割裂：Cherry Studio、LobeChat、Open WebUI、各种脚本和 CLI 工具，大多只能使用标准 API。
切换成本很高：某条线路挂了要手动换，某个账号额度不够了又得重新改配置。
后期很难维护：API地址、Key太多，模型和映射乱七八糟，时间久了自己都忘了这套 API 配置是哪来的。

我折腾这套方案的目的而是想解决一个很朴素的问题：

能不能把零散的 API 统一归纳成一个稳定、带故障转移、可长期维护的使用方式？

我最后采用的方案，是把我使用 API 的方式拆成两层：

CLIProxyAPI 负责把订阅账号和官方 CLI 能力变成标准 API
Octopus 负责把这些 API 再统一聚合、故障转移、监控和统计

这套组合不一定是唯一的解决方案，但对我来说，它的好处是非常明显的：可以部署在我的美西优化服务器上，尽可能避免 AI 降智，在大陆也有不错的网络连通性。

1. 我为什么会需要这套东西#

最开始我只是想把手上的几类额度都尽量利用起来。

比如有些模型的订阅权益，其实很香，但官方主要是给网页端或者 CLI 用的；而我平时真正高频使用的，却是下面这些工具：

桌面客户端 Cherry Studio
命令行工具 OpenCode、Claude Code
自己写的小脚本或工作流

问题是明明我已经有订阅、有账号、有额度，但如果不能把它们转成标准 API 形式，那很多工具根本用不了对我来说，这种碎片化体验比“没有额度”还烦。

2. 为什么是 CLI Proxy API + Octopus#

有了 CLIProxyAPI，你能把很多原本只能走官方 CLI 的能力转成 API，但当渠道一多，还是会乱，而 Octopus，它很适合做聚合和路由。所以这两个项目放在一起，刚好形成一个完整链路：

1
客户端 / 工具 / 脚本
2
        ↓
3
    [ Octopus ]        ← 中枢层：聚合、路由、统计
4
        ↓
5
  [ CLIProxyAPI ]      ← 入口层：OAuth 认证、格式转换
6
        ↓
7
 Gemini / Claude / OpenAI / Qwen / iFlow ...

3. 部署 CLI Proxy API#

router-for-me

CLIProxyAPI

前面已经讲清楚为什么要折腾这套东西了，这里就不继续做介绍。这一层的目标很简单：Docker 部署 CLI ProxyAPI，把原本依赖官方 CLI 登录的能力，转成可直接调用的标准 API。

3.1 部署前准备#

建议先确认下面几件事：

你有一台能长期在线的 Linux 服务器，或者本地已经装好了 Docker
已安装 Docker 和 Docker Compose

3.2 先准备目录#

CLI Proxy API 官方仓库里提供了 compose 文件，我更推荐直接用 Docker Compose 允许服务。先建一个工作目录：

Terminal window

1
mkdir -p ~/cliproxyapi
2
cd ~/cliproxyapi

3.3 用 Docker Compose 启动 CLI Proxy API#

可以在当前目录下新建一个 docker-compose.yml：

1
services:
2
  cli-proxy-api:
3
    image: eceasy/cli-proxy-api:latest
4
    container_name: cli-proxy-api
5
    restart: unless-stopped
6
    pull_policy: always
7
    ports:
8
      - "8317:8317"
9
      - "8085:8085"
10
      - "1455:1455"
11
      - "54545:54545"
12
      - "51121:51121"
13
      - "11451:11451"
14
    volumes:
15
      - ./config.yaml:/CLIProxyAPI/config.yaml
16
      - ./auths:/root/.cli-proxy-api
17
      - ./logs:/CLIProxyAPI/logs
18
    environment:
19
      DEPLOY: ""

然后执行：

Terminal window

1
docker compose up -d

3.4 如何使用 CPA 的 WebUI#

根据官方文档，CLI Proxy API 的 WebUI 入口是：

1
http://你的服务器IP:8317/management.html

如果你是本机部署，也可以直接访问：

1
http://localhost:8317/management.html

不过这里要注意，WebUI 不是容器一启动就一定能直接用。按照官方教程，你需要先在配置里加入 remote-management 相关配置，例如是否允许远程访问、管理密钥，以及是否禁用控制面板。

配置改完之后，重启程序；等服务生效后，再用浏览器打开上面的 management.html 页面。

第一次进入时，需要输入你在配置里设置的管理密钥（secret-key），输入正确后才能进入 WebUI。

官方教程里提到，进入之后界面本身比较直观，可以直接在面板里继续查看和操作；但有一个限制要特别注意：OAuth 认证功能仅支持本地运行环境，也就是 localhost 或 127.0.0.1，如果你是远程服务器部署，就不能直接在 WebUI 里完成这一步。

另外，如果你不想暴露内置控制面板，也可以把 remote-management.disable-control-panel 设为 true。这样一来，访问 /management.html 时就会直接返回 404。

简单理解的话，这一节可以记成下面这几步：

在配置文件里启用 remote-management
设置自己的管理密钥
重启 CLI Proxy API
访问 http://你的服务器IP:8317/management.html
输入管理密钥进入 WebUI

参考文档：

https://help.router-for.me/cn/management/webui.html

https://help.router-for.me/cn/hands-on/tutorial-6.html

4. Docker 部署 Octopus#

bestruirui

octopus

当 CLIProxyAPI 已经确认可用之后，再来搭 Octopus。

这一层的职责也很明确：把多个来源统一收进一个中枢里，让客户端以后只认一个入口。

4.1 用 Docker Compose 启动 Octopus#

Terminal window

1
mkdir -p ~/octopus
2
cd ~/octopus
3
nano docker-compose.yml

1
services:
2
  octopus:
3
    image: bestrui/octopus
4
    container_name: octopus
5
    restart: unless-stopped
6
    ports:
7
      - "8080:8080"
8
    volumes:
9
      - ./data:/app/data

启动：

Terminal window

1
docker compose up -d

4.2 首次登录和默认账号#

根据官方 README，服务启动后可以直接访问：

1
http://你的服务器IP:8080

默认账号密码是：

用户名：admin
密码：admin

这里一定要注意：第一次登录后马上修改默认密码。

4.3 把 CLIProxyAPI 接进 Octopus#

当 Octopus 面板已经能正常打开之后，下一步就不是继续折腾 Octopus 本身了，而是：

把 CLIProxyAPI 当作一个上游来源接进去。

写在最后#

如果你只是偶尔体验一下某个模型，那这套方案确实有点重。

但如果你已经进入“来源越来越多、客户端越来越多、配置越来越散”的阶段，把入口层和中枢层拆开，后面的维护会轻松很多。

简单总结就是：

CLIProxyAPI 先负责把订阅能力转成标准 API
Octopus 再负责把这些 API 聚合成统一入口

按这个顺序搭，基本是最稳的。先把第一条链路真正跑通，后面无论是加渠道、做轮询，还是做成本统计，都会顺很多。

「我的博客」那些悄然生长的新功能

Tue, 03 Mar 2026 00:00:00 GMT

“一个好的工具，应该在你需要它的那一刻悄悄出现，而不是让你刻意去寻找它。”

博客自从迁移到 Astro 以来，我对它的折腾从未停止过。

这次的更新没有什么轰轰烈烈的大改版，更像是一次次的”打磨”——在某个午后突然觉得少了什么，然后翻出代码，一点一点地把它补上。最终，这些碎片拼在一起，让整个博客焕然一新。

这篇文章就记录一下这段时间我到底做了什么。

1. 热力图：给时间留下痕迹#

第一个让我满意的功能，是侧边栏里的活动热力图。

灵感来自 GitHub 的 contribution graph——那一片绿色的方块，是每个开发者时间投入的最直观证明。我想在博客里也有一块属于自己的”时间地图”，记录每一篇文章的诞生。

于是侧边栏多了一个小组件，它会根据文章的发布日期，自动生成一整年的热力分布图。哪些时候笔耕不辍，哪些时候沉寂许久，一眼便知。

这不是一个实用功能，但它是一种仪式感。

热力图

2. 瞬间：碎片时光的容身之所#

以前总有一些想记录的东西，又不够写成一篇完整的文章——一张照片、一句话、一个随手拍下的瞬间。

它们无处安放，要么消失在手机相册里，要么被压进草稿箱再也不见天日。

所以我借助自部署的memos，添加了瞬间页面（Memos），作为这些碎片的容身之所。它不需要标题，不需要结构，只需要你把那一刻记录下来。

想到什么就说什么，像是给自己发一条消息。说不定某一天翻回来，会感谢当时的那个自己。

瞬间

3. AI总结：让机器先替你读一遍#

文章写完之后，又给文章页面加了一个 AI总结组件。

它会在文章顶部给出一段由 AI 生成的内容摘要，让访客在决定是否深入阅读之前，可以先得到一个快速的概览。

我知道有人对”AI生成”这几个字比较敏感，但我更倾向于把它当成一个导读工具而非替代品——就像一本书的序言，让你知道接下来会看到什么。

AI总结

4. 沉浸模式：只剩你和文字#

有时候打开一篇文章，却总被周围的东西分散注意力——侧边栏、导航栏、各种小组件……

所以我加了一个沉浸阅读模式（Zen Mode）。点击文章页面右侧悬浮的「沉浸阅读」按钮，侧边栏、导航栏会统统隐藏，屏幕上只剩下文章本身。

读完之后，按 ESC 即可退出，一切恢复原样。

有时候，少即是多。

沉浸模式

5. 那些小而美的交互改进#

除了上面几个”大功能”，这次还顺手加了一批体验细节，单独拿出来说每一个都不大，但放在一起，阅读体验的提升是可以感知的。

5.1 阅读进度条#

文章页面顶部现在有了一条阅读进度条，随着滚动实时更新。

这是一个微小但有意义的改动——在一篇长文里，知道自己”读到哪里了”，内心会多一点踏实。

5.2 命令面板#

按下 Ctrl + K（macOS 为 ⌘ + K），唤出命令面板，快速跳转到任意页面或文章。

这是一个为键盘控设计的功能，不需要鼠标点来点去，直接搜索、直接跳转，干脆利落。支持方向键上下选择，Enter 确认，ESC 关闭。

命令面板

5.3 欢迎语#

导航栏里加了一句欢迎语，根据当前时间段自动变换——早上好、下午好、晚上好……

小小一句话，希望每一位来访的朋友都能感受到一点温度。

欢迎语

5.4 外链提示#

点击一个外部链接时，现在会弹出一个提示窗口，告知你即将离开当前站点。

这个改动最初只是为了安全考虑，但后来发现它也有另一层意义：给每一次”离开”一点缓冲，提醒你这是一个有意识的选择。

外链提示

写在最后#

这些功能加起来，不过是几个下午的折腾。

但每次推送完代码，打开博客刷新页面时，看到那些新东西出现在应该出现的地方，还是会有一种小小的满足感。

博客是一个长期工程，没有终点，只有一次次的”再好一点”。

希望你在这里，也能感受到这份用心。

一城三色：澳门浮光与沉影

Tue, 10 Feb 2026 00:00:00 GMT

该如何走进澳门这一座城？纸醉金迷的赌场招牌，固然是它被世人熟知的侧影；可当我用一日时光，穿行于它的晨昏之间，却看到了一幅由三种底色交织的画卷——那是属于澳门的，沉默，厚重，却又鲜活的三原色。

第一笔，是路环那片温暾的旧色。#

穿过拱北口岸，午后的日光灿烂。我没有随着人流涌向大三巴，而是转身坐上了开往路环的25路巴士。

巴士缓慢地驶过澳门的老街。窗外的风景，像是翻阅一册褪色的杂志——骑楼下的茶餐厅，街角的小店，摩托在狭窄的巷弄里灵巧地穿行。巴士时停时走，车厢里满载着市井的嘈杂与生活的温度。我就这样靠在窗边，任车身轻轻摇晃，看一座城最平常的肌理在眼前缓缓流淌。

大约一小时后，路环到了。一下车，整个世界忽然安静下来。时间在这里失去了刻度，变得缓慢，湿润的海风拂面而来，那风里裹挟着旧日的气息——是咸涩的、属于渔港的味道，是阳光下晾晒的咸鱼散发的淡淡腥香，也是老房子墙皮剥落后，裸露出的水泥与岁月混合的气味。那一刻我知道，澳门的第一种颜色，就要在这座安静的小镇里。

沿着十月初五马路慢慢走，右手边是平静的海面，午后的阳光洒在水面上，泛起粼光，海面上泊着几条旧渔船；左手边是矮矮的彩房子，淡黄、浅绿、粉红，油漆在南方烈日下有些斑驳。

一家小小的安德鲁饼店门口飘出蛋挞的甜香，巷子深处，晾晒的衣服在微风中轻轻晃动。这里没有高楼，没有喧嚣，只有老榕树的在墙上投下摇曳的影子。

我走在海边，从路环码头经过，忽然觉得，这才是澳门最底层的颜色——像一块被岁月反复漂洗的棉布，纹理柔软，颜色淡净，包裹着这座城的余温。

第二笔，是挤在半岛老城里的、沉甸甸的褐黄色。#

从路环乘坐巴士返回半岛，这似乎是游客更加熟悉的澳门。

我下车后，钻进了那些巷弄。不经意就撞见了圣母玫瑰堂。明快的鹅黄色外墙，在夕阳下显得格外温暖。走进去，光线顿时暗下来，烛火摇曳，空气中有淡淡的蜡和旧木的味道。那份宁静，与外头街市的吵闹只隔着一道门。

从教堂出来，在议事亭前地附近闲逛，脚下是波浪形的黑白碎石地，两旁是柠檬黄、浅粉的老建筑。

我沿着碎石路走向大三巴，人潮是免不了的，但那面著名的残壁，当真正立在它面前时，喧嚣似乎被滤掉了些。它像一页巨大的、残缺的史书，被火与时间烧成了褐黄色，那些石头的纹理，仿佛还留着历史的余温。

我绕过人群，从后面的小道上去，就是炮台山。这里清静得多。生了锈的火炮静默地对着远处的海与高楼。站在这里往下看，方才拥挤的大三巴，成了山下一隅。视野再放开，层层叠叠的老房子铺展开来，屋顶是各种深浅的褐与黄，其间夹杂着新绿的树冠。风从海上来，吹过炮台，也吹过底下无数小巷。

这一片的颜色，是厚重的。它不是路环那种生活的淡彩，而是砖石、泥土、老木头，被几百年的风雨、香火、人烟浸润出的颜色。是圣保禄教堂一场大火后留下的焦黄，是教堂墙壁被岁月熏染的暖黄，也是炮台山体岩石本真的沉褐。它们挤在一起，诉说着碰撞、交融与坚守的往事。

第三笔，是入夜后凼仔那片流光溢彩的金。#

当夜幕彻底垂下，我穿过跨海大桥，来到凼仔。眼前的景象瞬间切换。威尼斯人、巴黎人、伦敦人……那些庞大的建筑群通体发光，金色的灯光从里透到外，把夜空都映亮了。商场里运河蜿蜒，天花板上绘着永远的蓝天白云；赌场门口，人潮衣着光鲜，奔赴一个不眠的夜晚。

这金色是张扬的、流动的，充满欲望与活力。但奇怪的是，站在这片金色的森林里，我却没有迷失感。因为我知道，只要我愿意，半小时车程就能回到路环的宁静里，或者钻进半岛某条小巷。

最后#

回拱北的巴士上，穿行于澳门，这座城市的迷人，或许就在于这三原色从不混淆，却又如此紧密地挨在一起。路环的旧色是它的呼吸，老城的褐黄是它的筋骨与记忆，而凼仔的金色，是它面向世界的脸庞。它们不互相覆盖，只彼此映衬，让这座小小的城，有了说不尽的层次和故事。

Friendtastic! 港迪20周年之旅🏰✨

Sun, 01 Feb 2026 00:00:00 GMT

今年一月初，我和女友一起去了迪士尼乐园，刚好赶上了香港迪士尼20周年，来纪念一下这一次梦幻之旅！

📅 行前准备：开园之前#

门票与预约：
- 香港迪士尼的门票价格会根据入院日期的客流量分为4个级别，我们这一次去是周中，也就是最便宜的第1级别票，淡季的迪士尼通常不需要提前购票，这一次的出行我是在到达乐园门口才在第三方平台上购票，在飞猪买的门票无需去官网预约，当场买当场刷二维码就可以入园了。
出行交通：
- 这一次前往港迪我们是从珠海出发，早上打车前往港珠澳大桥珠海公路口岸，在出境后即可乘坐穿梭巴士（金巴）前往香港了。
- 在到达香港后再换乘B5公交车即可抵达迪士尼乐园。
App：
- 可以下载香港迪士尼官方App查看排队时间、地图、演出时间表等，不想错过20周年演出的小伙伴一定要下载，安卓需要在Play商店下载。
物资准备：
- 港迪还是有不少性价比较高的食物的，所以其实只要带些小零食和矿泉水就行。

🏘️ 美国小镇大街#

设计原型为20世纪初美国市镇，展现煤气灯向电灯过渡、马车向汽车演变时期的复古景观。

入园之后的主干道两侧便是美国小镇大街，大街的两端分别是火车站和城堡，两侧则是各种纪念品商铺和小吃店，这里的食物相比其他主题园区的餐厅来说相对便宜一些，Main Street Bakery这家烘焙店的卷饼、三明治性价比很高，基本都在50-80港币，足够一个人吃饱了，如果没有自带干粮的话可以在这里吃。

一天有两场20周年“迪士尼好友巡游派对”花车巡游，会沿着城堡广场直到美国小镇大街的尽头，道路两侧的人相对广场较少，有更多机会和表演人员互动。

🎢 游乐项目#

与上迪相比，港迪没有太多刺激项目，但是各种项目的小细节十分不错，而且淡季的排队时间很短，这里简单说一说我游玩的几个项目的个人体验，仅代表个人看法，大家可以做个参考。

蚁人与黄蜂女 ★
坐在2人一辆的小车沿着固定轨道前进并朝着标靶射击，整体玩法比较一般，对于漫威IP的呈现还算不错，剧情和场景小细节处理的不错。淡季排队时间较短（<5min），淡季可以选择体验。
铁甲奇侠飞行之旅 ★★
钢铁侠IP的4D互动观影，内容和特效十分不错，会有一定的眩晕感，配音为粤语，怕晕的话建议不要和星战急速穿梭连着体验。
星战急速穿梭 ★★★
我认为港迪最刺激的过山车（港迪的项目普遍比较温和），以星球大战为主题的室内过山车，刺激来源在于全黑的环境下，突如其来的加速、急转与失重感。
迷离大宅 ★★★
同样是乘坐轨道小车探索“恐怖别墅”，其实也只是对儿童有些恐怖，排队时间较长而且一大半时间都在闷闷的室内排队，排队体验较差，内容值得体验。
灰熊山急速矿车 ★★★
又是一个刺激的高速过山车，有较强的失重感和突然的加速和后退，是港迪的最热门的项目，排队时间较长，建议想体验的可以早点去。
小熊维尼历险之旅 ★
子供向项目，不过也算是回味童年IP了，乘坐轨道小车游览固定场景，互动较少。
灰姑娘旋转木马 ★★
在旋转木马中相当不错，场景很出片，如果是双层就更好了，排队时间很短。
魔雪奇幻之旅 ★★
作为近年来人气非常高的迪士尼公主IP，在Let it go的歌声中乘坐水上小船，其中有一段略有失重感的俯冲哦，项目本身值得体验，但是排队太久了。

🎊 表演项目#

香港迪士尼的表演项目也非常不错，其中剧院表演对于大陆游客可能有点难以get到剧情，不过华丽的舞美就已经能让人沉浸于其中了。

迪士尼魔法书房 ★★★
一场非常棒的舞台剧，把迪士尼各大公主IP都串到一起，非常棒的舞台设计。
米奇幻想曲 ★★
一场4D小电影，互动做的还不错。
迪士尼好友Live：城堡派对 ★★★
港迪20周年限定表演，各大IP中的人物在迪士尼城堡前的舞台登台表演。
迪士尼好友巡游派对 ★★★
全新的花车，新的主题曲，一次感动人心的体验！

🎆 星梦光影之旅#

迪士尼闭园前最棒的体验莫过于城堡烟花表演了，在港迪扩建城堡后这样的体验变得更令人难忘。20周年限定的星空派对表演还有无人机表演，城堡表面的投影等华丽演出。

迪士尼是一个神奇的地方，我觉得如果一个乐园能够让所有年龄的人都快乐，那才算是最棒的乐园。20周年的香港迪士尼，可能没有最刺激的过山车，没有最华丽盛大的演出，但是当我13年后再一次来到这里，我似乎又能拥有13年前与爸爸一起来到这里时，那种孩童般的快乐和体验。那时的城堡很小，但带给我的快乐却是最纯粹的。

「Done-Hub」解锁Gemini API白嫖新姿势

Thu, 25 Dec 2025 00:00:00 GMT

Warning

我找到了跟好的方法，可以看看最新的文章「CLIProxyAPI × Octopus」API反代 & 集中管理

Done-Hub 是基于 one-hub 二次开发而来的 OpenAI 接口管理 & 分发系统。由于前段时间谷歌收紧了 API 免费层级的用量，导致原来一个账号创建多个 API Key 轮询使用 Gemini 2.5 Pro 的方式直接不可用了。虽然可以从谷大善人那里轻松获取到 Gemini Pro 的学生订阅，但是我还是更喜欢在 Cherry Studio 里直接调用 API。

现在留给我们的选择只剩下了逆向 API 这一条路，目前我们可以通过各种大佬开源的项目从 Gemini CLI、AI Studio、Antigravity 中逆向出 API。而 Done-Hub 则很方便的集成了多种逆向 API，还提供了简单的 WEB UI 控制面板，并且支持 Docker 部署，那我们白嫖谷歌逆向的 Gemini 就十分方便了。下面来介绍一下我部署 Done-Hub，以及逆向和接入 API 的过程。

快速部署#

Done-Hub 可以按照原版部署教程，只需要将镜像替换为 deanxv/done-hub 即可，可以参考部署说明 | One Hub 文档。

由于我是个人使用，所有部署了最简单的 SQLite 数据库版本，如果你有更高的需求，你也可以部署 MySQL 或是 PostgreSQL 版本。

创建文件夹

Terminal window

1
# 创建主目录
2
mkdir -p /data/one-hub
3
cd /data/one-hub
4
# 创建子目录
5
mkdir data

下载配置文件模板到子目录

Terminal window

1
wget https://raw.githubusercontent.com/MartialBE/one-api/main/config.example.yaml -O ./data/config.yaml

在主目录创建 docker-compose.yml 文件

1
version: '3.8'
2

3
services:
4
  done-hub:
5
    image: deanxv/done-hub
6
    container_name: done-hub
7
    restart: always
8
    ports:
9
      - "3000:3000"
10
    environment:
11
      - TZ=Asia/Shanghai
12
      - USER_TOKEN_SECRET=user_token_secret # 填一个32位随机字符
13
      - SESSION_SECRET=session_secret # 填一个32位随机字符
14
    volumes:
15
      - /data/one-hub:/data

启动服务
Terminal window
```
1
docker-compose up -d
```
访问 IP:3000

使用 root (默认密码：123456) 登录。记得修改密码！！！

使用方式#

你可以在侧边栏的 渠道-创建渠道 中，添加各类渠道或逆向 API：

Antigravity to API#

在渠道类型中选择 Antigravity，并且在下方点击 Google OAuth 授权。
在弹出的窗口里授权，在最终回调失败的页面中将 localhost:8080 改为 done-hub 的域名，提示授权成功即可。
回到 Done-Hub，我们可以发现已经自动填入了 Key。

添加 Antigravity 支持的模型，例如：

1
gemini-3-pro-high
2
gemini-3-pro-low
3
gemini-3-flash

测试通过后，即可正常使用。

Gemini CLI to API#

在渠道类型中选择 GeminiCLI，并且在下方点击 Google OAuth 授权。
在弹出的窗口里授权，在最终回调失败的页面中将 localhost:8080 改为 done-hub 的域名，提示授权成功即可。
回到 Done-Hub，我们可以发现已经自动填入了 Key。
添加 Gemini CLI 支持的模型，例如：
```
1
gemini-3-pro-preview
```
测试通过后，即可正常使用。

CodeX to API#

在渠道类型中选择 Codex，并且在下方点击 OpenAI OAuth 授权。
在新打开的页面中登录 OpenAI 账户并同意授权。
授权成功后，复制浏览器地址栏中的 完整 URL。
回到 Done-Hub，将完整 URL 粘贴到下方输入框中，点击 “提交授权码”。
添加 Codex 支持的模型，例如：
```
1
gpt-5.2
2
gpt-5.2-codex
```
测试通过后，即可正常使用。

「我的博客」从Halo到Astro迁移记录

Fri, 12 Dec 2025 00:00:00 GMT

1.为什么要更换博客框架#

Halo博客的痛点#

数据库：由于Halo博客是一个动态的博客框架，依赖数据库，尽管提供了 PostgreSQL 这样高性能低占用选择，但对于我这类访问量低的博客来说，维护一个数据库多少有些得不偿失。
资源占用： Halo 博客基于 Java 构建，这使得它的内存占用较高，通常 docker + Halo本体 + 数据库差不多要占用500-700mb的内存，这还是 Halo 内存优化后的结果。如果按照我目前使用1Panel的部署方式，一台2g内存的服务器才能保证有一定的容量。
备份困难： Halo 提供了免费自动备份的插件，但是如果你想要异地自动备份则需要购买付费插件。
难以应对多并发：在itdog测试时，我发现我的博客基本无法抗住快速测试这样的多并发场景。
网页加载速度与高成本：由于是动态博客，在网页加载速度上有先天劣势，如果套CloudFlare的CDN且不做优选的话，加载速度是难以忍受的，而直连的香港服务器成本也相对较高。

为什么选择Astro#

社区完善：作为一个还算新兴的框架，Astro的社区目前已经非常完善，适合小白上手，提供了许多优秀的主题。而Hexo、Hugo这样的老框架虽然成熟但是明显在易用性上落后于Astro。
无服务器：静态站点最大的优点是无需服务器部署，可以自动化托管在诸多平台上，快速且安全，特别是之前的Next.JS漏洞让我意识到服务器存在许多风险，我其中一台就因为Umami被植入了挖矿病毒。
文件路由： Astro的文件路由我认为是十分优秀的，可以满足绝大部分需求。

2.选择合适的主题#

之前在Halo中使用的是由 jiewenhuang 大佬移植的 Fuwari 主题，类似MD3的设计风格，简介流程，非常符合我的审美。

jiewenhuang

halo-theme-fuwari

既然这次换成Astro，那就继续使用 Fuwari 主题，不过原版主题功能不够丰富，所以我选择了 CuteLeaf 大佬基于 Fuwari 主题二次开发的 Firefly 主题。

saicaca

fuwari

3.在本地安装Astro#

Firefly 主题的开发者们写了十分详细的文档，所以很轻松的搭建起了博客框架。

Firefly文档地址：****https://docs-firefly.cuteleaf.cn/

3.1依赖安装#

安装 Node.js

访问 Node.js 官网下载并安装最新版本的 Node.js。

安装完成后，打开终端或命令提示符，运行以下命令验证 Node.js 是否安装成功：
Terminal window
```
1
node -v
2
npm -v
```
安装 pnpm

如果您尚未安装 pnpm，可以通过 npm 安装：
Terminal window
```
1
npm install -g pnpm
```
安装完成后，打开终端或命令提示符，运行以下命令验证 pnpm 是否安装成功：
Terminal window
```
1
pnpm -v
```
安装 Git

访问 Git 官网下载并安装适合您操作系统的 Git 版本。

安装完成后，打开终端或命令提示符，运行以下命令验证 Git 是否安装成功：
Terminal window
```
1
git --version
```

3.2项目启动步骤#

克隆项目

首先，Fork Firefly 项目并克隆到本地：
Terminal window
```
1
git clone https://github.com/you-github-name/Firefly.git
2
cd Firefly
```
安装依赖

使用 pnpm 安装项目依赖：
Terminal window
```
1
pnpm install
```
启动开发服务器

运行以下命令启动开发服务器：
Terminal window
```
1
pnpm dev
```

4.文章迁移#

Halo的插件市场提供了文章导入导出插件，可以很方便的导出Halo文章为MD文件。

Lyn4ever29

halo-plugin-export-md

在Astro框架优秀的智能路由的加持下，我可以把博客目录结构整理的井井有条：

1
src/
2
└── content/
3
    └── blog/
4
        ├── 2024/                <-- 年份文件夹
5
        │   └── my-trip/         <-- 文章独立文件夹
6
        │       ├── index.md     <-- 文章内容
7
        │       └── photo.jpg    <-- 文章图片
8
        └── 2023/
9
            └── old-post/
10
                ├── index.md
11
                └── cover.png

5.部署上线#

既然选择了Astro框架，那肯定是选择无服务器部署，我选择了以CloudFlare Pages为主，Vercel、EdgeOne Pages为备用线路的部署形式。线路切换的功能来自二叉树树大佬的魔改版Fuwari主题：

afoim

fuwari