折腾进行时

MiniMax H3 工作流分享：不用4步LoRA，速度还快5倍

Tue, 11 Aug 2026 00:00:00 GMT

写在前面#

MiniMax H3 官方说 3060 能跑，但实际上很多人跑起来还是很吃力。我折腾了好几天，找到了一个工作流，不仅能跑，而且直接提速 500%。

更离谱的是，这个工作流甚至没用官方 4 步 LoRA，但生成速度和质量都比用了 LoRA 的更优秀。

下面把模型下载、插件、配置、实测数据都整理一遍。

Share/Comfyui/Workflow/H3-3.0.json at main · hy4962/Share

工作流截图

模型下载#

来源	地址
HuggingFace	Comfy-Org/MiniMax-H3
国内源	ModelScope

我的硬件配置#

GPU：RTX 5070 Ti Laptop（12G 显存）
内存：32G
虚拟内存：32G-64G

能跑的模型搭配#

下面这套组合实测可以正常运行：

文件类型	文件名
diffusion_models	minimax_h3_fl2va_int8_convrot.safetensors
text_encoders	qwen3vl_32b_minimax_h3_int8_convrot.safetensors
vae	MiniMax-H3 VAE

可能需要的插件#

comfyUI-llama-TE：qwen3/qwen3.5/qwen3.7/gemma4 图片反推、提示词扩写高速版
TE_MAN：首个为 ComfyUI 打造的漫剧/增强生图/生视频插件

补充插件

有些插件在 ComfyUI Manager 里可能搜不到，可以直接从 GitHub 安装：

Goohaitools：50 多个实用工具，包括批量加载文件夹图片、自动保存指定 DPI、遮罩分析、人脸矫正等
H3-Motion-Context：MiniMax H3 的 clip chaining，运动和音频能真正跨片段衔接

提示词生成#

工作流里自带了提示词模板，用法很简单：

把模板复制给 AI
把你的想法尽可能详细地描述一下
AI 就能生成标准格式的提示词
直接用于生成即可

关于提示词模型

强烈建议本地部署 Qwen 3.5 无审查版本来生成提示词。哪怕是 Grok，也容易遭到拒绝回答。

细节设置#

8G 显存用户#

如果你是 8G 显存，把红色的节点换成绿色的即可。

8G显存节点替换

一致性模式选择#

使用 Max 模式可以保持非常优秀的人物一致性，但速度会慢一倍。一般 Match 模式也够用了。

一致性模式对比

采样步数#

由于没有使用 4 步 LoRA，所以步数可以自己设置。默认 10 步，速度很快，质量也不错。追求更高质量可以设成 15 步，这个工作流很快，多几步没什么影响。

采样步数设置

实测数据#

跑了好几天，生成了三四十个 10 秒视频，以下是两个典型场景的耗时：

场景一：0.4 像素，8 秒视频#

总时长 249 秒，直出 0.4 像素 8 秒视频。

0.4像素8秒视频耗时

场景二：0.9 像素，10 秒视频#

也可以直出 0.9 像素 10 秒视频，总时长约 1000 秒。

0.9像素10秒视频耗时

踩坑记录#

衣服或场景对不上文字描述#

有时候衣服或者部分场景对不上文字描述，这是因为在 Full-Reference Mode（全参考模式）下，AI 的优先级逻辑是：

最高优先级：<Picture N>（参考图）中的视觉特征
次级优先级：<Subject N> 定义的文字描述
最低优先级：detailed_description 中的动态场景描写

不过实测更强烈的文字描述可以跨越优先级，所以描述写详细一点是有用的。

提示词 Skill 推荐#

目前只推荐官方原版的提示词 Skill。试了很多其他 UP 主的，发现效果都不如官方 Skill。有些 UP 的提示词适用范围太小，有些太短，不太通用。

MiniMax-H3/skills at main · MiniMax-AI/MiniMax-H3

写在最后#

这个工作流的核心优势就是：不用官方 4 步 LoRA，速度反而更快，质量也不错。对于显存有限的用户来说，是个比较好的选择。

如果有什么问题或者更好的配置方案，欢迎交流。

Krea2 四视图生成：必备模型与可选 LoRA 分享

Mon, 10 Aug 2026 00:00:00 GMT

最近在用 Krea2 生成四视图，整理了一下必备模型和可选 LoRA，方便后续使用。

Share/Comfyui/Workflow/Krea2四视图.json at main · hy4962/Share

必备模型#

以下三个模型是 Krea2 四视图生成的基础，缺一不可。

Krea2 模型：krea2_turbo_fp8_scaled.safetensors - 核心扩散模型
文本编码器：qwen3vl_4b_bf16.safetensors - Qwen3-VL 文本编码器
VAE：qwenImage_qwenImageVAE.safetensors - QwenImage VAE

这三个模型都需要下载到 ComfyUI 的对应目录中。

可选 LoRA#

可选的 LoRA 模型来自魔搭社区的作者 yan303145427，他分享了多个 Krea2 风格的 LoRA。

我个人目前只用 krea2-Cc风情万种-风格这个 LoRA。这个作者的 krea2 lora 都很不错，可以根据自己的风格选择。

示例图

使用说明#

下载好模型后，可以参考这个 Bilibili 视频配置工作流。视频里详细介绍了四视图生成的提示词技巧和加速流配置，这里就不重复了。

如果遇到问题，可以参考视频评论区或作者的其他分享。

压风散热器 Flydigi BS3：主要是为了给硬盘降温和防尘

Mon, 10 Aug 2026 00:00:00 GMT

这玩意确实不是智商税，真的有用。不过我买它不是冲着 CPU/GPU 降温去的，主要就两个需求。但是不得不承认他也确实让我的烤鸡温度下降了5到8度(我没用30w的pd头和线跑满血)

一是硬盘降温。

我的 GW7000 2TB，打游戏直接 62 度，明明没啥读写。更气的是这不是笔记本的问题——我之前台式机也用这块盘，也是 60 度。台式机上还因为用的是盈通花嫁的 7800XT，matx 主板空间本来就挤，当时也没太好的办法，只能忍。

换了笔记本之后，这盘还是这样，索性就试试压风散热器能不能压一下。

二是防尘。

这东西公认防尘效果很优秀，据说一年笔记本里面都不带进灰的，算是意外的好处。

看来看去在 BS2 Pro 和 BS3 之间选，看到 BS3 也就 189，还是买新不买旧——虽然 BS2 Pro 比 BS3 散热效果更好，但价格差不多的情况下选新款没什么毛病。

然后是软件这块。开源社区有人做了第三方控制软件 THRM，智能风扇曲线、硬件监控、RGB、配置文件都有，Windows 和 Linux 都支持。

我压根没下过官方配套软件……买之前就看到这个项目了，直接用的这个。里面的智能学习功能确实好使，起码我没发现什么坏处。它会根据你的使用习惯自动调整风扇曲线，还有功耗预测前馈——就是 CPU/GPU 功耗突然上来的时候，转速会提前跟上，不会让温度先飙一波再说。

硬件监控也挺全的，CPU/GPU 温度、功耗、散热器转速都能看到，还能输出到 RTSS 游戏内叠加层，打游戏的时候直接看转速，挺方便的。

RGB 灯效也能调，亮度、动画速度、灯效模式都能自定义，不过我个人不太在意这个。

TIANLI0/THRM

THRM

image-20260809235045641

截图 1

截图 2

Anima 局部重绘工作流分享

Sun, 09 Aug 2026 00:00:00 GMT

最近在折腾 ComfyUI 的局部重绘，找到了一个挺好用的工作流，分享一下。

工作流下载#

Share/Comfyui/Workflow/Anima正式版-局部重绘+高清放大.json at main · hy4962/Share

模型准备#

用的是 Anima 这个模型：Anima - base-v1.0 | Anima Checkpoint | Civitai

右边三个模型都要下载，别漏了。

模型选择

工作流结构#

整体预览：

工作流预览

使用方法#

导入图片后，打开遮罩：

打开遮罩

把不透明拉满，需要改哪里就涂黑哪里：

涂抹遮罩

使用体验#

这个工作流我主要用来做局部修复，换装效果非常好。比如想给图里的人换件衣服，圈出衣服区域涂黑，生成出来很自然，和原图融合得很好。

手指、脚趾这些细节修起来也很方便，圈个遮罩就能搞定。Anima 模型本身就不容易出这些部位的错误，但万一有问题，用这个工作流修复也很顺手。

使用上也没什么坑，主要就是注意把模型放对位置就行了。

总结#

ComfyUI 局部重绘工作流，用 Anima 模型，人像修复效果很好，推荐试试。

ComfyUI 图像放大工作流：从文生图工作流中抽取的独立放大方案

Thu, 06 Aug 2026 00:00:00 GMT

最近在用 ComfyUI 做图像放大，发现把放大功能从文生图工作流里抽出来单独用，确实方便很多。

之前文生图工作流里也带放大功能，但每次想单独放大一张图，还得加载整个文生图流程，加载模型多、显存占用大，而且参数混在一起不好调。干脆直接抽出来，做成一个独立的放大工作流。

Share/Comfyui/Workflow/放大.json at main · hy4962/Share

为什么单独抽出来#

主要原因就一个：方便抽卡和管理。

文生图工作流里，放大参数和生成参数混在一起，想调放大效果还得在一堆节点里找。单独抽出来之后，所有放大相关的配置一目了然，改参数也方便。

另外就是显存管理。文生图工作流加载的模型多，放大只是其中一个环节。单独做放大工作流，可以只加载需要的模型，显存占用小一些。

工作流结构#

整个工作流结构很清晰：

工作流整体配置

主要分几个部分：

模型加载区：加载 UNET、CLIP、VAE 和 LoRA 模型
图像输入：加载要放大的原图
图像预处理：按比例缩放到目标尺寸
采样器：进行放大处理
后处理：色彩匹配和保存

模型配置#

这个工作流需要几个特定的模型文件：

主模型：Flux2-Klein-9B-True-v2-fp8mixed.safetensors

这是 Klein 系列的主模型，专门针对图像放大优化

LoRA 模型：Klein_动漫高清放大.safetensors

这个 LoRA 是专门做动漫风格高清放大的，效果比通用放大好很多

CLIP 模型：qwen_3_8b_fp8mixed.safetensors

文本编码器，用 Qwen 3 8B 的 fp8 混合精度版本

VAE 模型：flux2-vae.safetensors

Flux2 的 VAE，负责图像的编解码

模型下载地址都在 HuggingFace 上，直接搜文件名就能找到：

主模型：Flux2-Klein-9B-True-v2-fp8mixed.safetensors
LoRA模型：Klein_动漫高清放大.safetensors
CLIP模型：qwen_3_8b_fp8mixed.safetensors
VAE模型：flux2-vae.safetensors

关键节点设置#

这个工作流里有个很重要的设置，必须注意：

节点设置要求

在 PainterFluxImageEdit 节点里，有两个参数必须设置为特定值：

mode：必须设置为 1_image
batch_size：必须设置为 1

使用体验#

单独用这个工作流放大图像，确实比在文生图工作流里方便很多：

加载速度快：只加载需要的模型，不用加载整个文生图流程
参数清晰：所有放大相关参数都在一起，改起来方便
显存占用小：模型少了，显存压力也小了

不过也有个问题：这个工作流是针对动漫风格优化的，放大真人图像效果可能不如专门的放大模型。

总结#

把这个放大工作流从文生图里抽出来，是我用 ComfyUI 以来做过最正确的决定之一。管理方便、调参方便、显存占用也小。

如果你也在用 ComfyUI 做图像放大，建议也试试单独做一个放大工作流。特别是如果你经常需要放大动漫风格的图像，这个 Klein 系列的模型效果真的不错。

Docker 一键部署 NewApi API 中转站

Tue, 28 Jul 2026 00:00:00 GMT

现在市面上绝大多数 API 中转站，后台用的都是 NewApi。

NewApi 是一个开源的 AI 接口管理与分发系统，基于 One-API 二次开发，功能比原版更丰富。核心作用是把你手上的各种上游 API（OpenAI、Claude、Gemini、各家国产大模型……）统一收进来，然后对外暴露一个标准的 OpenAI 兼容接口。下游不管接的是什么模型，调用方式完全一样，换模型不用改代码。

用途主要两种：

对外售卖：做中转站，卖 API 额度给用户，有完整的计费、充值、用量统计体系
个人使用：统一管理自己的一堆 key，项目里只配一个 NewApi 地址就够了，不用到处存 key

NewApi 能做什么#

渠道管理：把各家上游 API 添加进来，配置模型映射、优先级、负载均衡。同一个模型名可以对应多个渠道，自动故障转移。支持的模型几乎覆盖全球所有主流官方服务，也可以自定义添加任何 OpenAI 兼容的接口。

令牌系统：对外发放 API Key（令牌），可以设置额度上限、IP 限制、模型白名单、过期时间。每个令牌的用量独立统计，方便管理多个项目或多个用户。

用户管理：支持用户注册、充值、配额管理。商业部署的话有完整的前台界面，用户可以自助充值、查看用量、管理自己的令牌。

计费系统：按 token 计费，可以自定义每个模型的倍率。调用日志完整记录，可以按时间、用户、模型、渠道多维度查询。

监控与告警：渠道有健康检查，自动禁用失效的 key，支持邮件告警。

部署架构#

这套 Docker Compose 起了三个容器：

容器	镜像	作用
`new-api`	`calciumion/new-api:latest`	主服务，提供 Web 界面和 API 端点
`new-api-redis`	`redis:latest`	缓存层，存储会话、速率限制计数等
`new-api-postgres`	`postgres:15`	主数据库，存储用户、渠道、日志等所有持久化数据

Redis 和 PostgreSQL 都配置了持久化，重启不丢数据。

Docker Compose 配置#

创建 docker-compose.yml 文件：

1
version: '3.4'
2

3
services:
4
  new-api:
5
    image: calciumion/new-api:latest
6
    container_name: new-api
7
    restart: always
8
    command: --log-dir /app/logs
9
    ports:
10
      - '3000:3000'  # 如果3000端口冲突，可以改成 '3001:3000'
11
    volumes:
12
      - /your/data/path:/data          # ⚠️ 改成你自己的路径
13
      - /your/logs/path:/app/logs      # ⚠️ 改成你自己的路径
14
    environment:
15
      # ⚠️ 数据库连接字符串（请确保密码与下方 postgres 的密码一致）
16
      - SQL_DSN=postgresql://newapi_user:YourStrongPassword123!@postgres:5432/new-api
17
      - REDIS_CONN_STRING=redis://redis:6379
18
      - TZ=Asia/Shanghai
19
      - ERROR_LOG_ENABLED=true
20
      - BATCH_UPDATE_ENABLED=true
21
    depends_on:
22
      - redis
23
      - postgres
24
    healthcheck:
25
      test: ['CMD-SHELL', "wget -q -O - http://localhost:3000/api/status | grep -o '\"success\":\\s*true' || exit 1"]
26
      interval: 30s
27
      timeout: 10s
28
      retries: 3
29

30
  redis:
31
    image: redis:latest
32
    container_name: new-api-redis
33
    restart: always
34
    command: redis-server --appendonly yes  # 开启Redis持久化
35

36
  postgres:
37
    image: postgres:15
38
    container_name: new-api-postgres
39
    restart: always
40
    environment:
41
      POSTGRES_USER: newapi_user
42
      POSTGRES_PASSWORD: YourStrongPassword123!  # ⚠️ 这里建议修改为你自己的强密码
43
      POSTGRES_DB: new-api
44
    volumes:
45
      - /your/postgres/data:/var/lib/postgresql/data  # ⚠️ 改成你自己的路径，数据持久化防止重启丢失

展开收起

部署前必改的三处地方：

new-api 的两个 volumes 路径换成你自己机器上的实际目录

postgres 的 volumes 路径同上

POSTGRES_PASSWORD 和 SQL_DSN 里的密码必须保持一致，改一处另一处也要跟着改

启动服务#

在 docker-compose.yml 所在目录执行：

Terminal window

1
docker-compose up -d

构建完后就能直接跑。

服务启动后的登录页面

初始化配置#

首次访问 http://localhost:3000 会进入初始化向导，只需要走一遍，后续不会再出现。

第一步：选择部署模式

选择部署模式

个人版：简化了用户体系，适合自用，没有充值、用户注册等商业功能
商业版：完整功能，有用户注册、充值、计费体系，适合对外提供服务

我是个人使用，所以选了个人。

第二步：设置管理员账号

配置管理员账号

设置管理员用户名和密码，这是你登录后台的主账号。

第三步：完成初始化

初始化完成

进入系统

初始化完成后进入主界面。

后台界面#

用户后台：普通用户视角，可以查看自己的用量、管理令牌、查看调用记录。

用户后台

管理后台：管理员视角，可以管理所有渠道、用户、令牌、查看全站日志和统计。

站点管理后台

接入上游 API#

进入管理后台 → 渠道 → 新建渠道，把你的上游 API 添加进来。

渠道配置页面

NewApi 内置了几乎全球所有主流官方模型的预设配置，OpenAI、Anthropic、Google、Azure、各家国产大模型都有。添加渠道时选好类型，填入你的 API Key，再配置一下这个渠道支持哪些模型即可。

一个模型可以对应多个渠道，NewApi 会按照你设置的优先级和权重自动做负载均衡，某个渠道挂了会自动切换到下一个。

添加完渠道后，还需要创建令牌：管理后台 → 令牌 → 新建令牌，生成一个供调用的 API Key。下游项目的 base_url 填你的 NewApi 地址，api_key 填这里生成的令牌就行了。

配置完成后，所有请求统一走 NewApi 转发。额度管理、调用记录、限流规则都在一个地方，不用再到各个项目里单独维护 key 了。

给 Cloudflare Tunnel 后面的 API 开启 CORS

Tue, 28 Jul 2026 00:00:00 GMT

给 Cloudflare Tunnel 后面的 API 开启 CORS#

我的 Memos API 通过 Cloudflare Tunnel 暴露在 memos.9ll.uk，前端则运行在 9ll.uk。两个地址的来源不同，浏览器发起 API 请求时就会受到同源策略限制，需要在响应中补上 CORS 相关响应头。

这里没有修改 Memos 本身，而是直接使用 Cloudflare 的响应头转换规则，在响应返回浏览器之前添加所需的 CORS 头。

先检查 API 地址#

首先检查前端填写的 API 地址。域名末尾不要带 /，写成：

1
https://memos.9ll.uk

而不是：

1
https://memos.9ll.uk/

这里后续的 API 路径会由请求端继续拼接。如果基础地址末尾已经带了 /，就可能和后面以 / 开头的路径拼出重复斜杠。

Memos API 地址配置

创建响应头转换规则#

进入 Cloudflare 控制台，选择对应域名，然后打开规则页面。点击 创建规则，选择 响应头转换规则。

在 Cloudflare 中创建响应头转换规则

这类规则会在 Cloudflare 边缘修改返回给浏览器的响应头。源站不需要跟着改，比较适合给 Tunnel 后面的服务补充 CORS 配置。

设置匹配条件#

为了不让规则影响整个域名，我这里只匹配 Memos 的 API 请求：

字段	运算符	值
主机名	等于	`memos.9ll.uk`
URI 路径	开头为	`/api/`

对应的规则表达式是：

1
(http.host eq "memos.9ll.uk" and starts_with(http.request.uri.path, "/api/"))

这样，只有访问 memos.9ll.uk/api/ 下的请求才会被添加 CORS 响应头，其他页面和路径不会受到影响。

添加 CORS 响应头#

操作选择 修改响应头，然后使用 设置静态 添加下面三项：

响应头	值
`Access-Control-Allow-Origin`	`https://9ll.uk`
`Access-Control-Allow-Methods`	`GET, OPTIONS`
`Access-Control-Allow-Headers`	`Content-Type, Authorization`

Cloudflare CORS 响应头规则配置

这三项分别控制：

Access-Control-Allow-Origin：允许 https://9ll.uk 这个来源读取响应。这里写的是具体来源，不是对所有网站开放的 *。
Access-Control-Allow-Methods：允许 GET 请求和浏览器的 OPTIONS 预检请求。
Access-Control-Allow-Headers：允许请求携带 Content-Type 和 Authorization。

保存并部署规则即可。

注意请求范围#

截图中的配置只开放了 GET 和 OPTIONS。如果你的前端还需要通过 API 创建、修改或删除内容，就要根据实际请求补充 POST、PUT、PATCH 或 DELETE，不能直接照抄这一项。

Access-Control-Allow-Origin 也要替换成你自己的前端来源，协议、域名和端口都要一致。如果跨域请求需要携带凭据，就不能把这里写成 *。

配置时先把规则限制在对应的 API 域名和路径，再按真实请求填写允许的来源、方法和请求头。Cloudflare Tunnel 负责暴露服务；响应头转换规则在浏览器收到响应前补上 CORS 配置。

参考资料#

Anima 文生图工作流分享

Mon, 27 Jul 2026 00:00:00 GMT

前阵子在 B 站刷到了每日提钢小助手5号分享的 Anima 工作流，折腾了一下，感觉挺好用的，就想着整理出来分享一下。

这篇只包含文生图的部分。放大我单独抽出来做了另一套工作流，不喜欢混在一起，下次再发。

工作流文件#

工作流放在 GitHub 上：

Anima 正式版-文生图工作流

下载下来直接拖进 ComfyUI 就能用。

必备模型#

这是重点。要跑起来需要下载三个文件，缺一不可。

Anima - base-v1.0 | Civitai

Civitai 模型页面

页面里有三个文件，三个都要下，放的位置不一样：

第一个主模型 → ComfyUI\diffusion_models 或 ComfyUI\Unet
第二个 text 模型 → ComfyUI\text_encoders 或 ComfyUI\clip
第三个 VAE → ComfyUI\vae

可选：官方加速 Lora#

这个我挺推荐的。官方出的 turbo lora，能把步数压到 6～8 步快速出图，质量损失极低。

Anima - turbo-v1.0 | Civitai

用法上有点区别：

不用 turbo lora：采样器步数设 30，CFG 5～8
用 turbo lora：步数改成 8，CFG 改成 1

速度差挺多的，日常出图我基本就用 turbo 了。

提示词怎么写#

负面提示词基本不用动，直接写正面提示词就行。

工作流提示词设置

如果要生成特定动漫角色，可以去这个网站查触发词：

ANIMADEX — Anime character & artist catalogue for ANIMA

里面有角色和画师的触发词，找到对应的复制进提示词就行。

折腾完感觉这套工作流比我之前用的顺多了，尤其是 turbo lora 那块，8 步出图速度很快，质量我觉得够用。放大的部分下次单独发。

Firefly 博客配置指南：从默认到属于你自己的博客

Sun, 26 Jul 2026 00:00:00 GMT

上一篇我讲了怎么从零搭建 Firefly 博客，从 Fork 仓库到 Vercel 部署，最后博客上线了。

但上线只是开始。

默认的博客标题是”Firefly”，副标题是”Demo site”，主题色是绿色，页面宽度、卡片样式全都是默认值。跟别人的博客长得一模一样，没啥意思。

所以今天这篇文章，我就来聊聊怎么改配置，让博客变成你自己的风格。

Firefly 博客配置界面

配置文件都在哪#

Firefly 的所有配置文件都在 src/config/ 目录下。打开你的项目，找到这个文件夹，里面一堆 .ts 文件，每个文件管一块功能。

主要的配置文件有这些：

siteConfig.ts — 站点基础配置（标题、描述、主题色、页面宽度等）
profileConfig.ts — 个人资料（头像、昵称、简介、社交链接）
navBarConfig.ts — 顶部导航栏
sidebarConfig.ts — 侧边栏布局
commentConfig.ts — 评论系统
fontConfig.ts — 字体配置
musicConfig.ts — 音乐播放器

看起来挺多的，其实不用一次全改。先把 siteConfig.ts 搞定，其他的以后慢慢调。

siteConfig.ts：最核心的配置文件#

这个文件管着整个站点的基本信息。打开 src/config/siteConfig.ts，你会看到类似这样的结构：

siteConfig.ts 配置文件

1
export const siteConfig: SiteConfig = {
2
  title: "折腾进行时",
3
  subtitle: "你的域名",
4
  site_url: "https://你的域名,
5
  description: "生命不息，折腾不止！一个技术博客？",
6
  // ...
7
};

站点标题和副标题#

title 是浏览器标签页上显示的名字，也是搜索引擎抓取的标题。subtitle 一般显示在首页或者导航栏上。

这两个改成你自己的就行。比如：

1
title: "我的小破站",
2
subtitle: "随便写写",

站点 URL#

site_url 这个一定要改。它影响 sitemap 和 RSS 生成的地址。如果你的域名是 blog.example.com，就填 https://blog.example.com。

别忘了加 https://，也别加末尾的 /。

主题色#

Firefly 支持自定义主题色。themeColor.hue 是色相值，范围 0-360。

几个常用的：

红色：0
绿色：120
青色：200
蓝绿色：250
粉色：345

我之前试过 165，是个不错的青绿色。现在改成 65，偏黄一点，看起来更温暖。

defaultMode 控制默认是亮色还是暗色模式：

"light" — 亮色
"dark" — 暗色
"system" — 跟随系统

我选了 "system"，让浏览器自动决定。

页面宽度#

pageWidth 控制整个页面的最大宽度，单位是 rem。默认 100，数值越大页面越宽。

如果你觉得内容区域太窄，可以调大一点，比如 120。但太宽了反而不好看，特别是单栏布局的时候。

卡片样式#

1
card: {
2
  border: true,
3
  followTheme: true,
4
},

border 控制卡片有没有边框和阴影。开了之后文章卡片会有点立体感。

followTheme 让卡片背景在浅色模式下跟随主题色。这个看你喜好，我开了之后觉得还挺协调的。

页面开关#

Firefly 有很多页面功能，比如友链、打赏、相册这些。在 siteConfig.ts 的 pages 对象里可以控制开关：

1
pages: {
2
  friends: true,    // 友链页面
3
  sponsor: true,    // 打赏页面
4
  guestbook: true,  // 留言板
5
  bangumi: true,    // 番组计划（追番）
6
  gallery: true,    // 相册
7
  dynamic: true,    // 动态页面
8
},

设成 false 就会隐藏对应的导航入口，访问那个页面会 404。

我一开始把 guestbook 关了，因为还没配评论系统。后来配好 Waline 之后又打开了。

文章列表布局#

这个挺有意思的。postListLayout 控制文章列表怎么显示：

1
postListLayout: {
2
  defaultMode: "list",      // 默认列表模式
3
  mobileDefaultMode: "grid", // 移动端用网格模式
4
  descriptionLines: 2,       // 摘要显示2行
5
  tagsPosition: "bottom",    // 标签显示在底部
6
},

defaultMode 有两个选择："list" 是单列列表，"grid" 是多列网格。我用了 "list"，在桌面端看比较舒服。

mobileDefaultMode 是移动端的默认布局。我设了 "grid"，手机上看起来更紧凑。

tagsPosition 控制标签显示位置。设成 "bottom" 的话标签会显示在卡片底部，替代统计数据的位置。

文章卡片信息控制#

下面还有 meta 和 stats 两个对象，控制文章卡片上显示哪些信息：

1
meta: {
2
  showPublished: true,  // 发布日期
3
  showCategory: true,   // 分类
4
  showTags: true,       // 标签
5
  showWords: true,      // 字数
6
  showReadingTime: false, // 阅读时间
7
},

我关掉了 showReadingTime，因为觉得字数已经够了，再显示阅读时间有点冗余。

其他重要配置#

profileConfig.ts：个人资料#

这个文件管你的头像、昵称、简介和社交链接。打开 src/config/profileConfig.ts：

1
export const profileConfig: ProfileConfig = {
2
  avatar: "./avatar.webp",
3
  name: "你的名字",
4
  bio: "你的简介",
5
  socialLinks: [
6
    // 社交链接配置
7
  ],
8
};

avatar 放你的头像图片路径。图片可以放在 public/ 目录下，也可以放在 src/assets/ 下（后者会自动优化）。

navBarConfig.ts：导航栏#

导航栏的配置在这个文件里。可以设置导航链接、Logo、是否全宽等。

我比较喜欢全宽导航栏，所以设了 widthFull: true。

fontConfig.ts：字体#

Firefly 支持自定义字体。你可以用 Google Fonts、Fontsource，或者本地字体。

但说实话，默认字体已经挺好看了，我暂时没改。

commentConfig.ts：评论系统#

这个文件管评论系统的配置。Firefly 支持 Twikoo、Waline、Giscus、Artalk 等。

我之前写过一篇搭建 Waline 评论系统的文章，里面有详细配置。

musicConfig.ts：音乐播放器#

如果你想在博客里加背景音乐，可以配置这个文件。支持 Meting API（在线音乐）和本地音乐。

我暂时没开，怕影响加载速度。

怎么测试配置效果#

改完配置后，本地跑一下就能看到效果：

Terminal window

1
pnpm dev

浏览器打开 http://localhost:4321，刷新就能看到新的配置。

改主题色、页面宽度这些，刷新就能看到。改导航栏、侧边栏这些，可能需要重启一下开发服务器。

我一般改完配置会跑一下 pnpm build，确保没有语法错误。如果构建失败了，报错信息会告诉你哪个文件哪一行有问题。

踩坑记录#

site_url 没改导致的问题#

我一开始忘了改 site_url，结果 sitemap 生成的地址是默认的 https://firefly.cuteleaf.cn。提交给 Google Search Console 的时候，验证一直不通过。

后来才发现是这个配置没改。改完重新构建就好了。

图片路径搞混#

Firefly 支持两种图片路径：public/ 目录下的和 src/ 目录下的。

public/ 下的图片不经过优化，直接复制到构建输出。src/ 下的图片会自动压缩、转换格式。

我一开始把头像放在 public/ 下，结果加载比较慢。后来移到 src/assets/ 下，构建时自动压缩了，加载快了不少。

主题色改了但没生效#

有次改了 themeColor.hue，刷新页面发现没变化。后来发现是浏览器缓存的问题。清一下缓存或者用无痕模式就能看到。

配置参考#

配置文件挺多的，不可能一次全记住。官方文档写得比较全：Firefly 站点配置

我建议先把 siteConfig.ts 搞定，其他的用到了再去文档里查。每个配置项都有注释，看着改就行。

写在后面#

配置这个东西，其实不用一次全改完。

先把基本的改了，标题、副标题、主题色这些。其他的用到了再慢慢调。反正改配置又不花钱，多试几次就知道什么好看了。

说实话，折腾配置本身也是种乐趣。看着自己的博客一点点变成想要的样子，还挺有成就感的。

后面我可能会写一篇关于自定义 CSS 样式的文章，让博客变得更不一样。如果你也想折腾，可以关注一下。

有问题的话直接在评论区问，我看到了会回复。

写于 2026 年 7 月，折腾 Firefly 博客配置的记录

手机上终于有个像样的 Galgame 管理器了

Sat, 25 Jul 2026 00:00:00 GMT

手机上终于有个像样的 Galgame 管理器了#

前几天刷 GitHub 的时候，无意间看到一个叫 RinneMobile 的项目。

https://github.com/Weiss-UltimateSavior/RinneMobile

RinneMobile 界面

为什么觉得它有意思#

我手机里存了不少 Galgame，但一直没找到好用的管理方式。

以前试过直接用文件管理器找游戏目录，每次想玩的时候都要翻半天。文件管理器这东西吧，找文档还行，找游戏是真的痛苦——游戏目录名乱七八糟，有的是日文，有的是拼音缩写，根本不知道哪个是哪个。

也试过几个启动器。有的只能启动安卓应用，KRKR 引擎的游戏完全不支持。有的倒是能启动，但是每次都要手动选目录，麻烦得要死。

还试过把所有游戏 shortcut 放到一个文件夹里，结果越攒越多，找起来更费劲了。

RinneMobile 说白了就是个”游戏库”——把你的本地游戏、安卓应用、模拟器入口、外部程序快捷方式全放到一个地方管理。

听起来简单，但市面上能做到这点的安卓工具还真不多。

它能干什么#

我看了下 README，功能还挺全的。

统一管理#

本地游戏、安卓应用、外部启动入口都能加进去。

这点太重要了。我手机里不光有 KRKR 引擎的游戏，还有一些安卓原生的 Galgame，还有几个通过 Winlator 跑的 PC 游戏。以前要分别用不同的方式启动，现在全放一个地方，方便多了。

游戏库页面

自动扫描#

选个目录，它会自动识别 KRKR、ONScripter、Tyrano、Artemis 这些引擎的游戏。

不用一个个手动添加，这点很省事。它会根据文件特征来判断引擎类型：

KRKR：看有没有 .xp3、startup.tjs 这些文件
ONScripter：看 0.txt、nscript.dat 这些
Tyrano：看 index.html 和目录特征
Artemis：看 system.ini 这些

识别出来之后，启动的时候会自动用对应的引擎打开。

VNDB/Bangumi 数据源#

可以给游戏补充封面和信息。

这个功能挺贴心的。添加游戏之后，可以关联 VNDB 或者 Bangumi 的数据，自动拉取封面图和游戏简介。这样游戏库看起来就整齐多了，不用自己一张张找封面。

数据同步#

支持 WebDAV 云同步，换设备不怕丢数据。

我之前最怕的就是换手机。每次换手机，游戏存档、游玩记录全没了。RinneMobile 支持把数据同步到 WebDAV，换设备的时候导进去就行。

它同步的时候会根据 root 路径、本地 ID、游戏标题来匹配，空目录条目会优先按标题匹配。虽然不是 100% 能对上，但大部分情况够用了。

游戏时长记录#

启动游戏后自动计时，切回来就停止。

这个功能对我来说还挺有用的。我之前一直想统计自己玩 Galgame 花了多少时间，但没有趁手的工具。RinneMobile 自动帮我记，虽然不是特别精确（中途切出去再切回来就不续计了），但大致有个数。

AI 智能体#

最让我意外的是它内置了一个 AI 智能体，可以连自己的 OpenAI 兼容 API。

比如查询游戏库、搜索文件之类的。这个功能我还没深入试，但听起来挺有意思的——以后说不定可以让 AI 帮我找某个台词在哪个游戏里出现过。

适合什么人#

如果你是这类用户，可以看看：

手机里存了一堆 Galgame，想统一管理
用 KRKR、ONScripter 这些引擎的游戏比较多
想在多设备之间同步游戏数据
喜欢折腾，愿意自己配置

如果你只是偶尔玩一两个安卓版 Galgame，可能用不上这么重的工具。

设置页面

几个细节#

项目背景#

这是基于 YukiHub 二次开发的分支版本，不是从零开始的，站在前人肩膀上。

作者叫 Weiss-UltimateSavior，GitHub 上 97 个 Star，不算多，但说明有人在用。有 QQ 交流群，遇到问题可以问。

协议和兼容性#

GPL-3.0 协议，开源，可以自己改。

需要 Android 8.0 以上，老设备可能跑不了。我看了下编译信息，Min SDK 是 26，Target SDK 是 33，用的 Java 17。

已知问题#

README 里提到了几个已知问题：

KRKR 游戏里有文字输入弹窗的功能不能用，会导致闪退
TF 卡里的 KRKR 游戏要通过镜像目录启动
华为设备可能有存储访问兼容性问题，可以试试开启”外部私有存档”

这些坑我还没踩到，但提前知道比较好。

界面#

支持深色模式和横屏，这点挺加分的。

我挺喜欢它的界面设计，有好几个主题可以切换。竖屏横屏都能用，躺在床上玩的时候横屏模式挺舒服的。

深色模式

横屏模式

和其他工具的对比#

安卓上能启动 Galgame 的工具其实有不少，但大多数只管”启动”，不管”管理”。

比如 Tyranor，能启动 KRKR 和 Tyrano 引擎的游戏，但没有统一的游戏库，也没有数据同步。每次想玩都要翻文件夹。

再比如一些通用的游戏启动器，倒是能管理，但对 Galgame 引擎的支持不行，KRKR、ONScripter 这些都认不出来。

RinneMobile 的优势就在于”管理+启动+同步”三合一。虽然每个方面都不是最强的，但凑在一起，体验就完整多了。

我的判断#

说实话，这个项目解决的问题确实存在——安卓上缺少好用的 Galgame 管理工具。

如果你有这个需求，值得试试。

它不是那种开箱即用的工具，需要自己配置一下。但折腾本来就是乐趣的一部分，对吧？

站长实习经历

Fri, 24 Jul 2026 00:00:00 GMT

去年 12 月中旬，我随便找了一家中介，进入了一家做自动化视觉的小公司，成为了一名视觉调试实习生。

刚开始的时候，我的想法很简单：

实习嘛，能学点东西，最后拿到一份实习证明，就已经不错了。

但没想到，这五个月里，我几乎把一个新人能经历的事情都经历了一遍。

从培训结束后直接被派到客户现场，到项目负责人调走、师傅辞职，最后只剩下我这个刚入行不到一个月的实习生，一个人负责整个项目。

从每天 12 小时以上的工作，到 24 小时待机。

从每天被客户吊，到后来能够独立解决问题。

最后，我还是离开了。

不是因为我做不下去，而是我终于发现：

比起高工资，我其实更喜欢稳定一点的生活。

先说说这家公司#

这是一家专门做自动化视觉的小公司，主要负责视觉软件开发和现场调试。

按我的理解，应该算是二级供应商。

其他自动化公司承接整机项目后，会把视觉部分外包给我们。

公司规模不算大，实缴社保人数估计也就二十多人，但长期都在招人。

原因也很简单：

人员流动率实在太高了。

我在职期间，陆陆续续来了几十个新人，真正留下来的估计只有几个。

为什么？

因为太累了。

工作时间长，长期出差，12 小时工作制基本是常态。

有时候，所谓的“下班”也只是从现场离开而已。

客户一个电话打过来，还是得继续处理问题。

培训结束，直接进入现场#

刚入职的时候，公司先安排了几天培训，主要学习他们基于 VisionMaster 开发的二开软件。

刚开始确实觉得有点陌生，不过学了三四天之后，基本就能上手了。

培训结束后，我休息了几天，很快就被派到了客户现场。

刚到现场的时候，其实还算挺舒服。

虽然我很紧张，担心自己能不能做好，但至少当时还有师傅带着。

我跟着师傅看了两三天流程，结果客户突然没料生产了。

于是接下来接近两个星期，我每天的主要工作就是跟着师傅玩手机。

现在回头看，那段时间是真的爽。

但问题也正是在这里产生的。

真正接触流程的时间只有那几天，后面天天摸鱼，反而导致很多东西慢慢忘了。

然后，真正大的问题来了。

师傅辞职了。

更离谱的是，项目负责人在师傅辞职前三四天，又被调去了其他项目。

原本整个项目总共就三个人：

项目负责人：调走了
师傅：辞职了
我：0 经验实习生

最后，真正留在现场的只有我一个。

当时的感觉非常简单：

天黑了。

一个人硬扛整个项目#

1 月初，客户开始正式来料生产。

没有师傅。

没有负责人。

只能靠自己。

什么问题都得自己解决。

一些小问题还能靠培训时学到的东西，再结合自己的理解，一点一点试出来。

虽然慢，而且天天被客户吊，但至少还能解决。

真正不会的问题，只能远程找公司开发大哥。

但他也不是随叫随到。

有时候在他看来比较简单的问题，甚至会直接装死不回复。

于是，我基本上变成了一个人在现场孤立无援。

白天解决问题，晚上继续研究。

这一行本来 12 小时工作制就是常态，而我那段时间经常是 12 小时以上。

更离谱的是，下班以后也不算真正结束。

客户随时可能打电话过来。

远程解决现场问题，逐渐变成了日常。

基本属于：

24 小时待机。

客户甚至开始让我教人#

客户现场还有几个机修。

他们后来直接让我去教他们怎么使用我们公司的软件。

问题是……

我自己都还是个新人。

不过也是在这段时间里，我认识了一个比我大两岁的机修。

他主要负责跟这台设备，也是我在现场关系最好的人。

他很多东西都是我后来一点一点教会的。

慢慢熟悉之后，我们基本什么都聊。

他也玩《部落冲突》。

直到现在，他还是我部落里的副首领。

PLC 的工程师看不下去了#

现场负责 PLC 的工程师，看着我这个样子都绷不住了。

他天天吐槽我们公司：

怎么会让一个 0 经验的人，一个人负责整个项目？

其实我也觉得。

如果公司稍微有点实力，应该也不会发生这种事。

刚开始和他沟通的时候，其实特别痛苦。

很多东西我根本听不懂，他有时候也会不耐烦。

不过随着经验慢慢积累，后来交流就顺畅多了。

甚至后来经常一起提前下班，然后去网吧。

客户其实没有想象中那么可怕#

现在回头看，客户现场的大部分人其实都挺好的。

他们不会轻易吊人。

真正喜欢找茬的，只有他们其中一个领导。

属于那种：

你没问题，他也能给你找点问题出来吊一顿。

我为什么一直没有辞职？#

其实那段时间，我想过很多次辞职。

但每次想到这里，又特别不服。

我一直觉得：

这些问题看起来并没有难到完全解决不了。

我总觉得自己应该把它啃下来。

至于实习证明，反而不是主要原因。

我有几个朋友家里都有公司，如果只是为了盖一个实习章，其实完全不是问题。

也许可能还有所谓的沉没成本？

也可能就是年轻，不服输。

那段时间我还喜欢玩 Galgame，也补完了《凉宫春日》。

但每次看到一半，电话突然响起来。

真的会心脏骤停。

一月和二月：最难熬的时候#

整个一月和二月，客户的生产计划都非常赶。

每天的生活几乎都在重复：

睁眼，干活，被吊，解决问题，然后继续被吊。

晚上躺床上睡觉，第二天继续。

当时我的经验实在太少，很多问题只能一点一点试。

公司中途也派过两三次人过来支援，客户甚至已经投诉到了大老板那里。

但每次负责人过来也只待一两天。

最后，还是只能靠自己。

现在回头看，其实很多问题并没有多复杂。

只是对于当时那个刚接触自动化不到一个月的我来说，几乎什么都是第一次。

三月：世界突然亮了#

到了三月，经验终于慢慢积累起来。

我已经能够独立解决不少问题，也能帮客户修改一些简单功能。

和 PLC 工程师的沟通也越来越顺畅。

现场终于没有以前那么压抑了。

后来甚至经常和 PLC 哥们提前下班，一起去网吧。

还有一个很离谱的事情。

客户是大厂，供应商需要定期续签通行证。

偏偏我们公司经常忘记。

于是一个月里经常有一两天，甚至三四天进不了厂。

这种时候怎么办？

不用上班。

直接和 PLC 去网吧。

客户突然没料了#

三月中旬开始，客户突然没料了。

整个项目一下子闲了下来。

不用进车间，每天就在楼下玩手机。

晚上也不用加班，下午五点准时下班。

我第一次觉得：

原来世界还能这么美好。

月底虽然又恢复生产了几天，但设备问题已经不多了。

只是每次收到“恢复生产”的消息时，我心里还是会咯噔一下。

因为我真的有点害怕重新回到一月、二月那种生活。

四月：正式进入养老模式#

整个四月，我几乎没什么印象。

因为真的太轻松了。

设备几乎不开。

公司一直催客户验收，客户一直拖，公司也一直拿不到尾款。

这种状态一直持续到我离职。

设备都没怎么重新开起来。

五月：我决定离开#

5 月 17 日，我正式辞职。

我离职是因为太累？太辛苦？

如果只是怕辛苦，我一月、二月的时候就已经跑路了。

真正让我决定离开的，是长期出差。

入行之前，我知道这一行一年可能有三百天都在外面。

当时我觉得：

在哪住不是住？无所谓。

真正干了几个月之后，我才发现完全不是这样。

一直住公司租的破房子。

房间很破。

下班以后，连一个舒服一点的环境都没有。

我只是想拥有一个属于自己的房间。

一台高配电脑。

一个好一点的显示器。

一套舒服的外设。

下班以后打一会儿游戏，看看番，敲敲代码。

仅此而已。

但长期漂泊的生活，很难让我拥有这些。

因为你永远不知道：

什么时候换项目。

什么时候换城市。

下一个住宿环境怎么样。

下一个项目的工作量会不会更离谱。

后来我才发现。

比起高工资，我其实更喜欢稳定。

实习期间印象最深的几件事#

相机掉线#

有几个工位的相机特别邪门。

只要设备停机一两天以上，再重新开机，就必定掉线。

解决办法也很原始：

拔一下线，再插回去。

然后就好了。

但问题是：

为什么会这样，没人知道。

软件 Log 全部正常。

线材看起来也不像坏的。

设备如果一直连续生产，又完全不会出问题。

我一开始还以为这是我接手之后才出现的问题。

后来听客户和 PLC 工程师聊天才知道，这个问题在我来之前就已经存在了。

一直没人查出来。

直到我 7 月退客户群的时候，这个问题都还在。

漏检劣质品#

客户前段工艺会先检测一遍产品。

有问题的产品会被贴上黄色标签，但不会直接剔除。

真正的剔除工作是在我们这台设备完成的。

视觉检测到以后，再通知 PLC 进行剔除。

理论上来说，这一步不应该漏。

但实际上，偶尔真的会漏。

我第一次遇到漏检的时候，影响不算太大。

客户只是让我们排查原因。

后来听说是客户的一个机修，直接跟质检说问题已经解决了。

这件事也就糊弄过去了。

结果过了一段时间，又漏了一片。

这次直接天塌了。

客户立刻拉会议，开始排查所有风险。

已经发货的产品都在讨论要不要半路拦截，甚至考虑整批报废。

当天晚上一直加班到 12 点排查。

但最后，其实也没有找到真正的原因。

解决问题#

后来客户决定临时启用两台一直没开的相机，再增加一道检测。

整个检测流程基本都是我自己设计、自己调试、自己测试出来的。

虽然因为是临时改造，打光条件其实很差。

但至少能够正常跑起来。

当时我还挺开心。

因为这是我第一次独立完成一个新的检测流程。

后来我才知道。

这个漏检问题，其实在我来之前就已经存在了。

第一次完全靠自己解决问题#

有一次，设备一直报超时。

各种数据看起来都正常。

但软件就是特别卡。

一旦卡住，所有数据都会开始乱。

而且特别玄学。

一会儿正常，一会儿又卡。

我只能一直盯着任务管理器。

后来我发现，每次软件卡住的时候，D 盘都会被占满。

奇怪的是，带宽只有十几 MB/s。

看起来根本不像磁盘跑满。

于是我又打开资源监视器。

发现有一个 Windows 系统进程一直在疯狂读取机械硬盘。

后来查资料才知道，它应该是在建立或者更新文件索引。

顺序读写问题不大。

但随机读写对机械硬盘来说，就完全是另一回事了。

于是我去找客户沟通。

客户又联系了他们公司的 IT。

IT 第一反应还挺无语：

就这点带宽，也能把软件卡死？

我只能解释：

这是机械硬盘，不是固态硬盘。随机读写根本不能只看带宽。

后来他问我：

那你觉得限速多少合适？

我还认真算了一下。

按照一天产生的图片数量，再加上一点冗余，最后建议限制到 2 MB/s。

不过后来发现，只要索引过程跑完，软件就会恢复正常。

最后，我直接把软件迁移到了 C 盘 SSD。

问题立刻缓解了很多。

那时候其实挺开心的。

因为这是整个实习期间，第一个完全靠我自己定位、分析，并最终解决的问题。

其实还有一次。

我排查硬件的时候，发现一块机械硬盘已经出现了坏道。

我把情况反馈给公司。

公司选择不管。

当时已经被各种问题整红温了。

哈哈哈。

这件事最后也只有我和公司知道。

凌晨一点的批斗大会#

应该是二月下旬。

晚上十一点，经理突然打电话，让我立刻去现场。

客户已经投诉到大老板那里了。

平时公司连打车都不给报。

我每天都是走路往返一公里多。

但这次，经理直接让我打车过去。

我到客户公司时已经十一点二十。

因为客户流程特别严格。

再着急，也必须等客户的人来接才能进去。

真正到车间的时候，已经快十一点四十了。

经理和负责人在电话里告诉我：

十二点要和客户开会。

让我赶紧找一些证据，证明问题不一定是视觉导致的。

现在回头想，他们更多只是想先找一点理由，为后面的沟通争取时间。

后来我找了一些图片和现象，说明视觉只是检测出了问题。

真正导致问题的，未必是视觉。

也可能是机构或者其他环节。

经理后来有一句经典名言，我到现在还记得：

我们视觉只能做检测优劣，不能直接参与产品的好坏。

虽然很多时候他说这句话只是为了拉扯。

但确实挺经典。

会议结束已经一点多。

然后继续和开发远程查问题。

一直折腾到凌晨四点多。

我回到出租屋的时候，已经五点了。

睡了一会儿。

中午十二点继续上班。

…

其实整个实习期间，我一直觉得自己的压力没那么大。

因为我知道。

真干不下去的话，可以回家。

也可以换工作。

家里没有什么经济压力。

我是单亲家庭，父亲工作稳定，以后退休金可能都比我工资高。

只要自己别过度内耗，其实生活不会太差。

可是就在那天凌晨。

我走在回出租屋的那条特别窄的小巷里。

突然哭了。

没有任何征兆。

也没有任何情绪铺垫。

眼泪就是一下子流了下来。

连我自己都愣住了。

一次倒班乌龙#

有一次，客户工程师早上给我打电话。

我还以为设备坏了。

结果他说：

“今天不用上早班，直接倒夜班。”

因为夜班机修太少，希望我过去帮忙。

我觉得挺合理。

于是下午特地开了免打扰，睡了一觉。

睡到三点多醒来。

发现手机里全是负责人打来的未接电话。

我赶紧回过去。

结果第一句话就是：

“你怎么没来上班？”

我一脸懵。

反问：

“客户没通知你吗？他说让我上夜班。”

负责人听完直接无语。

让我马上过去正常上班。

后来想想也正常。

他的新项目特别忙，根本没有时间替我远程值班。

于是我白白折腾了一下午。

最后还是正常去上班。

一次失败的闪电调岗#

四月底，公司准备把我调去福建支援新项目。

经理在下班路上给我打电话，让我立刻买后天的票。

我也买了。

后来我和客户说了一下。

客户直接震惊。

然后特别自信地说：

你放心。
你走不了。
这台设备还有这么多问题。
我待会就给你经理打电话。

其实我当时也觉得，大概率走不了。

结果第二天。

老板亲自给我打电话。

叹了口气。

让我把票退了。

手续费公司报销。

最后，福建没去成。

我继续留在原来的项目。

写在最后#

这份实习只有五个月。

但它也是我真正意义上的第一份工作。

也是我第一次真正接触自动化、客户现场和项目。

如果现在再问我：

还会不会去做这份实习？

我想，我还是会。

不是因为它有多好。

而是很多东西，只有自己一个人在现场扛过之后，才能真正学会。

只是如果让我继续做这一行。

我应该不会了。

我还是更喜欢稳定一点的生活。

下班以后，有自己的房间。

有自己的电脑。

有一点属于自己的时间。

对现在的我来说。

这就够了。

SillyTavern（酒馆）无限制 AI 角色对话部署指南

Fri, 24 Jul 2026 00:00:00 GMT

之前一直用各种在线平台跑 AI 角色对话，说实话大部分都差点意思——要么限制多，要么数据不在自己手里，折腾起来也不方便。后来在群里看到有人提”酒馆”，说是开源的，自己部署，想怎么玩就怎么玩。我一想，反正也不难搞，就试试呗。

折腾了一番，把部署过程和踩过的坑记下来，顺便也介绍一下这个东西。

酒馆是个啥#

SillyTavern，社区里一般叫”酒馆”，是个开源的网页应用。简单来说，它就是一个前端界面，帮你对接各种 AI 模型（OpenAI、Claude、Gemini、本地模型等等），然后你通过浏览器跟 AI 聊天。

它本身不提供 AI 模型，你需要自己有 API Key 或者跑本地模型。但它的好处是：

数据全在本地，不经过第三方
可以自由调整各种参数和提示词
支持角色扮演、写作辅助等多种玩法
社区活跃，功能一直在更新

酒馆跑起来之后，浏览器打开 127.0.0.1:8000 就能用。

它能干什么#

除了基本的聊天，酒馆还能玩不少花样：

角色卡片：导入别人做好的角色卡，或者自己写一个，AI 就会扮演那个角色跟你对话
预设和破限：通过预设文件控制 AI 的回复风格，比如更像小说、更口语化，或者突破一些限制
世界书：给 AI 补充背景知识，比如角色的设定、世界观什么的
群聊：多个角色一起聊天，有点像拉了个群
正则替换：自定义消息的处理规则，比如隐藏 AI 的思考过程
扩展功能：支持画图、语音合成、翻译等扩展，社区一直在加新东西

不过这些进阶功能先不管，部署好能聊天才是第一步。

Windows 部署#

我在 Windows 11 上部署的，过程其实不复杂。

前提准备#

先装两个东西：

Node.js：去 nodejs.org 下最新的 LTS 版本装上就行。这是酒馆运行的底层依赖，必须有。注意 Windows 7 不支持，因为跑不了 Node.js 20。

Git：用来下载酒馆代码。可以装 Git for Windows，也可以用 GitHub Desktop。

装好之后可以验证一下，在命令行里输入：

Terminal window

1
node -v
2
git --version

能看到版本号就说明装好了。

安装路径注意#

这个很重要：不要装到 Program Files 或者 System32 这种系统文件夹里。Windows 对这些路径有权限限制，跑起来会出问题。

就找个普通路径放着，比如 D:\SillyTavern 或者 C:\Tools\SillyTavern。

安装与启动#

打开文件管理器，导航到你想放启动器的文件夹，在地址栏输入 cmd 回车，然后执行：

Terminal window

1
git clone https://github.com/SillyTavern/SillyTavern-Launcher.git && cd SillyTavern-Launcher && start installer.bat

双击 Launcher.bat，打开输入1它会自动下载需要的依赖包，然后启动服务。

第一次跑会慢一点，要下载一堆依赖。等命令行窗口里出现类似 SillyTavern is listening on port 8000 的提示，就说明启动成功了。

启动成功后，浏览器会自动打开酒馆界面。如果没有自动打开，手动访问 http://127.0.0.1:8000 就行。

API 连接和配置#

酒馆装好了，下一步就是连上 AI 模型。

酒馆支持好几种模型后端：

OpenAI（GPT-4、GPT-3.5 等）
Claude（Anthropic 的模型）
Gemini（Google 的模型）
本地模型（通过 Ollama，LMstudio 等方式运行）

在酒馆界面的设置里填上你的 API Key 就能连上，操作不复杂。

连接设置#

打开酒馆后，点上面的”插头”图标（就是那个像电源插头的），进入 API 连接设置。

这里有几个地方要填：

API 类型：选你用的模型，比如 OpenAI、Claude、Gemini
API URL：填对应的 API 地址。如果是官方 API，一般有默认值；如果用反代或者第三方服务，填对应的地址
API Key：填你的密钥

填完之后点”连接”测试一下，能看到绿色的提示就说明连上了。

注意事项#

这些是我折腾过程中遇到的问题，记下来防止以后忘。

对接 LM 测试成功但发消息发不出去#

这个问题挺常见的。如果你测试连接没问题，但实际发消息的时候报错，很可能是”提示词后处理”没选对。

消息顺序报错

特别是用 Qwen 之类的模型时，它严格要求消息顺序必须是系统提示词在最前面，然后用户和角色交替发言。如果顺序不对，就会报这种错：

连接设置与提示词后处理选项

解决办法就是在”提示词后处理”那里选”严格（强制对话角色交替、用户最先）”。

参数设置#

连上之后，建议把参数调一下。上下文长度、最大回复长度、温度这些，直接影响聊天体验。

参数设置面板

上下文长度：AI 能”记住”多少之前的内容。太短的话 AI 容易忘事，太长的话消耗的 token 多
最大回复长度：AI 一次回复最多写多少字。设太小的话回复容易被截断，图里这个 8192 对大多数场景够用了
温度：控制回复的随机性。0.70 左右比较平衡，想要更稳定可以调低，想要更有创意可以调高

这些参数不用一开始就调到完美，先用默认值跑起来，后面再根据实际体验慢慢改。

端口被占用#

如果你之前跑过酒馆，或者有其他程序占用了 8000 端口，启动的时候会报错。解决办法：

关掉之前那个酒馆窗口
或者改端口号，在启动参数里指定一个别的端口

API Key 的成本#

这个得说一下。酒馆本身免费，但 API 调用是收费的。不同的模型价格不一样，用之前最好了解一下计费方式，免得月底看到账单吓一跳。

如果预算有限，可以考虑用一些提供免费额度的服务，或者跑本地模型（不过本地模型对显卡有要求）。

最后说两句#

酒馆这个东西怎么说呢，上手难度不算高，但需要你有一定的动手能力。如果你之前没怎么用过命令行，可能会觉得有点麻烦，但跟着步骤走其实也还好。

部署好之后的体验还是不错的，可以自由调整各种参数，玩起来比在线平台灵活多了。缺点就是需要自己有 API Key，这块是有成本的。

如果你也想搞一个自己的 AI 聊天环境，可以试试。有问题的话欢迎交流。

一个字母的事：让 opencode 像 mimo 一样在资源管理器地址栏启动

Fri, 24 Jul 2026 00:00:00 GMT

我平时用 opencode 每次都要开命令行输入 opencode，挺烦的。

mimo 就方便很多，在文件资源管理器地址栏直接输入 mimo 就能打开终端。我就想着能不能也给 opencode 搞一个短命令。

最简单的想法：复制一个 oc.cmd 出来不就行了？

Terminal window

1
Copy-Item "C:\Users\XOS\AppData\Roaming\npm\opencode.cmd" "C:\Users\XOS\AppData\Roaming\npm\oc.cmd"

命令行里输入 oc 确实能用。但是文件资源管理器地址栏里输入 oc，直接跳浏览器了。

搞了半天才发现，Windows 地址栏只认 .exe，不认 .cmd。输入 oc 找不到对应的 .exe，就当成网址去搜索了。

mimo 能用是因为它本身就是个 .exe 文件，放在 PATH 目录里，地址栏直接能找到。

所以正确的做法是复制 .exe：

Terminal window

1
Copy-Item "C:\Users\XOS\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe" "C:\Users\XOS\AppData\Roaming\npm\oc.exe"

这下命令行和地址栏都能用了，输入 oc 直接打开，跟 mimo 一样。

说实话这个坑挺小的，但不查真不知道。我一直以为 .cmd 和 .exe 在地址栏里效果一样。

折腾 opencode 快捷启动的小记录

我的游戏性能优化方案：从系统到硬件折腾了一遍

Wed, 22 Jul 2026 00:00:00 GMT

最近 CS2 打得比较多，总觉得帧数不够稳、鼠标有点拖。从系统设置到硬件超频折腾了一遍，现在舒服多了。弄之前平均帧大概 580-600，low 只有 200-210；弄完后平均帧 657，low 250。

先说我的配置：

CPU：9955HX
GPU：5070Ti 12G Laptop
内存：16X2=32G( 镁光M8D1 )
系统：XOS11 25H2 V15

CS2设置

下面按折腾顺序来，从 BIOS 到系统设置都讲一遍。

BIOS 设置#

先把硬件层面的搞定。

CPU#

UMAF 分核负压设置：如下图所示,Github/UMAF_BETA.zip
关闭 VBS + 内存虚拟化：使用Github/关闭DG和VBS自动包执行重启后疯狂按F3开机即可
频率： 4.8 G

CPU 负压设置

尝试禁用CCD1的方案然后跑5.2 G和5.0G，但是温度反而100°C，93°C了，双CCD4.8G倒是最多85°C，都是用同一套负压。奇怪…

内存条#

本人是镁光 M8D1，原生 5600c46，101ns，超到 6000c40，85ns到88ns。我的作业貌似非常保守，这个也是超别人的

内存超频参数

这里我把第一个26改成了28，第五个4E改成了52

UMAF_SPD

GPU 超频#

硬件搞定了，再来折腾 N 卡。

安装厂商官方驱动包，但没安装核显、N 卡驱动和 AMD 安全启动。厂商控制台 CPU 全拉满，然后对 N 卡进行超频：

N卡控制面板1

N卡控制面板2

核心频率：+250 MHz
显存频率：+300 MHz

GPU 超频设置 1

GPU 超频设置 2

N 卡驱动我自己用 596.36-notebook-win10-win11-64bit-international-dch-whql

系统设置#

硬件调完了，软件层面也得搞一下。

Process Lasso Pro 配置#

规则添加游戏进程就完事了：禁用 CPU0 + 提升进程优先级。

Process Lasso 设置

金银核与禁用 CPU0 的原理#

perf#1 代表系统会优先将任务分配到该核心上。我的金银核是 Core 0 和 Core 4。

简单来说：如果你的金银核中有一个正好在 CPU0 上（比如我的情况），游戏禁用 CPU0 的收益最高。因为在鼠标、键盘高轮询率的情况下，系统会优先用金银核处理输入事件。禁用 CPU0 后，游戏反而会更流畅——因为输入处理不再抢占游戏核心的资源。

金银核示意

快速配置#

使用 Booster 快速设置最佳配置，然后手动恢复 WiFi 和蓝牙为正常打开状态。

提示：这个系统需要在设备管理器里单独手动安装 WiFi 驱动。

Booster WiFi 驱动安装

鼠标延迟#

最后处理鼠标问题，这一套搞完鼠标就不拖了。

1. 关闭鼠标加速#

默认状态：开启

操作步骤：Win + R → 输入 main.cpl → 确定 → 指针选项 → 取消勾选「提高指针精确度」→ 应用

效果：修复鼠标拖不动

2. 修改 Win32PrioritySeparation 为 42（十进制）#

默认值：十进制 2

操作步骤：Win + R → 输入 regedit → 确定 → 找到路径：

1
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\PriorityControl

双击 Win32PrioritySeparation，修改为十进制 42（需重启生效）

效果：修复鼠标拖不动

3. 关闭 USB 选择性暂停#

默认状态：已启用

操作步骤：Win + R → 输入 powercfg.cpl → 确定 → 更改计划设置 → 更改高级电源设置 → USB 设置 → USB 选择性暂停设置 → 改成「已禁用」

USB 选择性暂停

效果：修复鼠标拖不动

提示：如果没有 USB 设置选项
则访问注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00
在右侧找到 Attributes，双击，将数值从 1 改为 2
或者请参考下图操作：

USB 电源设置

4. 关闭修复应用缩放（仅 Win10）#

默认状态：开启

操作步骤：桌面右键 → 显示设置 → 高级缩放设置 → 修复应用缩放 → 关

效果：修复鼠标掉帧

此项仅限 Win10，Win11 不用理会。

5. 关闭「在打字时隐藏指针」#

默认状态：开启

操作步骤：Win + R → 输入 main.cpl → 确定 → 指针选项 → 取消选中「在打字时隐藏指针」

效果：修复鼠标掉帧（需重启生效，虽然抽象但确实影响鼠标表现）

还有几个坑#

AMD最好禁用高精度处理器，特别在老AMD上，一两天会有一次非常剧烈的卡顿，甚至在桌面也有，禁用后即可解决，但其实在新AMD上几乎看不到，反正禁用没坏处…

设备管理器-系统设备-高精度事件计时器-右键禁用

禁用高精度事件计时器

对于AMD纯大核心的设计，电源计划的调度必须选择全部和异类策略4，否则会出现分配不均的情况，因为默认的是英特尔大小核的调度。

但是如果你说双CCD延迟高，你用上面说到的Process Lasso Pro改需要延迟低的程序，绑定一个CCD亲和性就就行了

（很多笔记本默认隐藏了这2个选项，要调整需要更改注册表。点击”Windows键”+“R键”，输入regedit打开注册表编辑器，在”HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00”下找到”93b8b6dc-0698-4d1c-9ee4-0644e900c85d”以及”bae08b81-2d5e-4688-ad6a-13243356654b”，进去后将2个路径下的”Attributes”值由默认0更改为2，重新打开电源计划即可更改异类线程调度策略和异类短运行线程调度策略。）

电源计划设置1

电源计划设置2

总结#

折腾完之后 CS2 帧数稳了不少，鼠标也不拖了。说实话挺烦的，但搞完确实舒服。

核心配置：

CPU：4.8G + 全核分核负压
GPU：核心频率 +250Mhz，显存频率 +300Mhz
内存：5600C46 → 6000C40
系统：XOS11 25H2 + Booster 快速最佳设置 + 鼠标设置
电源：解锁电源计划隐藏选项，使用高性能电源计划把异类策略改为4，异类调度改为全部并取消 USB 节能
设备管理器：取消所有 USB 设备”允许计算机关闭此设备以节约电源”

接下来打算试试内存能不能再压一下时序，看看有没有提升。

《俺妹》观后感

Tue, 21 Jul 2026 00:00:00 GMT

看完《俺妹》后的一些个人感想#

横线以上基本无剧透，没看过的可以放心看。
下面只是个人观点，也算留给未来自己的一个记录

看完《俺妹》之后，基本也把相关游戏补了一遍。

回过头来看动画，突然发现了一些第一次观看时没有注意到的问题。

第一次看的时候，其实完全没有这种感觉。

当时就是被剧情推着走，只想知道接下来会发生什么，根本没有去想节奏、铺垫这些东西。

但是看完游戏之后，再回头想动画，就感觉这部作品的问题其实挺明显。

最大的问题就是：节奏真的太赶了。

很多时候一集就是一个小故事，甚至直接推进一个阶段，中间几乎没有什么日常过渡。

角色之间很多感情变化，其实应该有更多时间去描写，但动画篇幅有限，导致很多地方刚建立起感觉，就马上进入下一个剧情。

说白了就是：

内容太多，但是两季真的装不下。

两季加起来的篇幅并不算长，但它想讲的东西实在太多了。

主要人物基本全部涉及，各种事件也全部推进。

如果能在两季之间增加一些零零散散的日常篇，让角色们多相处十几集，整个作品的观感应该会好很多。

可惜了。

说到桐乃。

她这个角色真的属于争议拉满。

有些操作是真的难绷。

尤其如果站在京介视角来看，她对哥哥的态度有时候已经不是普通傲娇了，而是接近“你到底想干什么”的程度。

特别是青梅来家里的那段。

如果我是她哥，估计早在第一季前几集就已经忍不了了，早他妈给她几巴掌扇老实了，青梅过来就这个态度。。。。。

不过看完整个故事之后，也能理解，这种极端某种程度上就是桐乃这个角色的核心。

她就是这么强势、任性、不服输。

换个人可能还真演不出这个感觉。

但不得不承认，她有一点是真的厉害。

能够保持自己的兴趣爱好，同时还能把学习、工作、生活全部做好。

这种能力和自律，其实非常夸张。

黑猫和青梅两个角色是真的顶。

两个人都属于比较踏实的类型。

普通、勤俭、会做家务，也比较懂得照顾别人。

这种角色其实越看越舒服。

尤其黑猫。

如果单纯从理想型来看，我觉得黑猫可能会更符合一点。

她不是那种第一眼特别强烈的角色，但越了解越容易喜欢。

以下开始剧透#

没看完真的别往下翻。

《俺妹》这种作品，第一次观看体验其实很重要，一点点关键剧情都会影响感受。[笑哭]

关于动画结局的争议。

以我个人来说，其实没有觉得特别接受不了。

首先，我是观众，不是京介本人。

从京介的角度来看，他最后确实拒绝了其他人。

所以严格来说，其他人的感情确实只能算是一段没有继续发展的关系。

但是站在观众角度，我觉得其实还好。

尤其黑猫这个角色。

她喜欢的东西其实一直没有改变。

某种程度上来说，就是“肉体可以改变，但灵魂不会变”。

自私一点想，京介以后也不缺喜欢他的人。

而且最后一集突然亲脸那一段，我个人感觉更像是：

表面上的恋情结束了，但真正的关系转为了地下。

所以这个结局我能接受。

如果真的接受不了，去玩游戏也是一个不错的选择。

总的来说，《俺妹》是一部非常值得看的作品。

虽然桐乃有时候的操作是真的让人血压升高，但她也是这部作品不可缺少的一部分。

在我看来，直到“桐乃假男友事件”之后，两个人的关系才真正开始像现实里的兄妹。

这也是这么多年来，第一次有一部动画让我专门去玩游戏、买周边。

它可能不是一部完美的作品。

但它确实留下了很深的印象。

用 Vercel + TiDB 搭建 Waline 评论系统

Tue, 21 Jul 2026 00:00:00 GMT

有次在别人的博客上看到 Waline，去 GitHub 一查，发现它支持多数据库、能自己部署、还能统计浏览量，功能挺全的。关键是它开源，数据自己掌控，我就想着搞一个试试。

为什么选 TiDB 而不是 Neon#

Waline 官方的 Vercel 部署教程默认用 Neon（PostgreSQL），免费给 512MB。但我查了一下 TiDB Cloud，免费额度有 5GB，差了十倍。对于评论系统来说数据库不会太大，但 5GB 总比 512MB 舒服，以后万一要存点浏览量数据也不用担心。

TiDB 本身是兼容 MySQL 协议的 NewSQL 数据库，Waline 直接支持 TiDB 作为后端，不用额外折腾。所以我就决定用 Vercel + TiDB 这个组合。

第一步：部署 Vercel 服务端#

Waline 官方提供了一键部署的按钮，点一下就行。

Vercel

点击上面的按钮，会跳转到 Vercel。如果你还没登录，它会让你用 GitHub 账号注册或登录。

登录之后，给你的项目起个名字，比如 my-waline，然后点 Create。

给项目起名

Vercel 会基于 Waline 模板自动创建一个仓库，大概一两分钟就能部署好。

自动创建仓库

部署成功后会有一屏烟花，点 Go to Dashboard 进入控制台。

部署成功

到这里服务端代码就部署好了，但还没连数据库，所以先别急着用。

第二步：创建 TiDB 数据库#

这一步是整个过程中最核心的，也是跟官方教程不一样的地方。

注册 TiDB Cloud#

去 TiDB Cloud 注册一个账号。注册完之后会自动创建一个 TiDB 实例，不用手动配置。

创建表结构#

登录后点进你的实例（默认叫 cluster0），左侧选 SQL Editor。

进入实例

接下来要执行建表语句。Waline 官方提供了一个 SQL 文件，但那个是 PostgreSQL 格式的。TiDB 用的是 MySQL 兼容语法，需要用 waline.tidb 这个文件。

SQL 文件的内容大概是这样的：

1
CREATE DATABASE `waline`;
2

3
USE waline;
4

5
CREATE TABLE `wl_Comment` (
6
  `id` int unsigned NOT NULL AUTO_INCREMENT,
7
  `user_id` int DEFAULT NULL,
8
  `comment` text,
9
  `insertedAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
10
  `ip` varchar(100) DEFAULT '',
11
  `link` varchar(255) DEFAULT NULL,
12
  `mail` varchar(255) DEFAULT NULL,
13
  `nick` varchar(255) DEFAULT NULL,
14
  `pid` int DEFAULT NULL,
15
  `rid` int DEFAULT NULL,
16
  `sticky` boolean DEFAULT NULL,
17
  `status` varchar(50) NOT NULL DEFAULT '',
18
  `like` int DEFAULT NULL,
19
  `ua` text,
20
  `url` varchar(255) DEFAULT NULL,
21
  `createdAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
22
  `updatedAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
23
  PRIMARY KEY (`id`)
24
) CHARSET=utf8mb4;
25

26
CREATE TABLE `wl_Counter` (
27
  `id` int unsigned NOT NULL AUTO_INCREMENT,
28
  `time` int DEFAULT NULL,
29
  `reaction0` int DEFAULT NULL,
30
  `reaction1` int DEFAULT NULL,
31
  `reaction2` int DEFAULT NULL,
32
  `reaction3` int DEFAULT NULL,
33
  `reaction4` int DEFAULT NULL,
34
  `reaction5` int DEFAULT NULL,
35
  `reaction6` int DEFAULT NULL,
36
  `reaction7` int DEFAULT NULL,
37
  `reaction8` int DEFAULT NULL,
38
  `url` varchar(255) NOT NULL DEFAULT '',
39
  `createdAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
40
  `updatedAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
41
  PRIMARY KEY (`id`)
42
) CHARSET=utf8mb4;
43

44
CREATE TABLE `wl_Users` (
45
  `id` int unsigned NOT NULL AUTO_INCREMENT,
46
  `display_name` varchar(255) NOT NULL DEFAULT '',
47
  `email` varchar(255) NOT NULL DEFAULT '',
48
  `password` varchar(255) NOT NULL DEFAULT '',
49
  `type` varchar(50) NOT NULL DEFAULT '',
50
  `label` varchar(255) DEFAULT NULL,
51
  `url` varchar(255) DEFAULT NULL,
52
  `avatar` varchar(255) DEFAULT NULL,
53
  `github` varchar(255) DEFAULT NULL,
54
  `twitter` varchar(255) DEFAULT NULL,
55
  `facebook` varchar(255) DEFAULT NULL,
56
  `google` varchar(255) DEFAULT NULL,
57
  `weibo` varchar(255) DEFAULT NULL,
58
  `qq` varchar(255) DEFAULT NULL,
59
  `oidc` varchar(255) DEFAULT NULL,
60
  `2fa` varchar(32) DEFAULT NULL,
61
  `createdAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
62
  `updatedAt` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
63
  PRIMARY KEY (`id`)
64
) CHARSET=utf8mb4;

展开收起

注意一点：TiDB Cloud 的 SQL Editor 每次只能执行一条语句。所以你得按 ; 分隔，一句一句贴进去执行。每贴一句，点右上角的蓝色运行按钮，或者按 Ctrl+Enter（Mac 上是 Cmd+Enter）。

SQL Editor 执行

三张表都创建好之后，数据库就准备完了。

获取连接信息#

点左侧的 Overview 回到首页，右上角有个 Connect 按钮，点进去获取连接配置。

Connect with 选 General，然后点 Reset password 生成一个新密码。

获取连接配置

你需要记下这几个信息：

Host：类似 xxx.ap-southeast-1.tidbcloud.com
Port：默认 4000
User Name：一般是 xxx.root
Password：刚才生成的那个
Database：waline

第三步：给 Vercel 配置数据库#

回到 Vercel 的项目控制台，点顶部的 Settings，然后找到左侧的 Environment Variables。

点右上角的 Add Environment Variable，依次添加以下五个变量：

变量名	值	说明
`TIDB_HOST`	`xxx.ap-southeast-1.tidbcloud.com`	TiDB 的 Host 地址
`TIDB_PORT`	`4000`	TiDB 端口
`TIDB_DB`	`waline`	数据库名
`TIDB_USER`	`xxx.root`	用户名
`TIDB_PASSWORD`	`你生成的密码`	密码

配置环境变量

填完之后，去 Deployments 页面，点最新一次部署右边的 Redeploy 按钮，让环境变量生效。

重新部署

等部署状态变成 Ready 之后，点 Visit 就能看到你的 Waline 服务了。

访问服务

这个地址就是你的服务端地址，后面客户端接入要用到。

第四步：绑定自定义域名（可选）#

如果你不想用 Vercel 默认的域名，可以绑自己的域名。

点 Settings → Domains，输入你想绑定的域名，点 Add。

添加域名

然后去你的域名服务商那里，添加一条 CNAME 记录：

Type	Name	Value
CNAME	example	cname.vercel-dns.com

example 是你子域名的部分，比如你想用 comment.yourdomain.com，就填 comment。

等 DNS 生效后，你的评论系统地址就变成了 comment.yourdomain.com，管理后台在 comment.yourdomain.com/ui。

绑定成功

第五步：在网站里接入评论#

服务端搞定了，最后一步是在你的网站里引入 Waline 客户端。

在 HTML 里加上这几行：

1
<head>
2
  <link rel="stylesheet" href="https://unpkg.com/@waline/client@v3/dist/waline.css" />
3
</head>
4
<body>
5
  <div id="waline"></div>
6
  <script type="module">
7
    import { init } from 'https://unpkg.com/@waline/client@v3/dist/waline.js';
8
    init({
9
      el: '#waline',
10
      serverURL: 'https://你的服务端地址',
11
    });
12
  </script>
13
</body>

把 serverURL 替换成你 Vercel 部署后的地址就行。

如果你用的是 Astro、Hexo 这类静态博客框架，一般都有 Waline 插件，配置起来更简单。

管理评论#

自带管理后台，这是 Waline 的一大优势#

说实话，很多评论系统（比如 Valine、Twikoo）都没有独立的管理后台，你只能去数据库里一条条翻评论，或者在前端一个一个删除。Waline 不一样，它自带一个完整的 Web 管理界面。

访问 <你的服务端地址>/ui/register 注册账号，第一个注册的人自动成为管理员。

登录后你能看到一个干净的管理界面，功能还挺全的：

评论审核：新评论默认需要审核，管理员通过后才会显示在前端。防止垃圾评论直接出现在你的博客上。
批量操作：可以批量通过、拒绝或删除评论，不用一条条点。
修改评论：管理员可以直接编辑用户提交的评论内容，比如修改敏感信息。
标记垃圾：可疑的评论可以标记为 spam，系统会自动识别类似的评论。
搜索过滤：可以按文章 URL、用户名、邮箱、时间范围筛选评论，找起来方便。
用户管理：普通用户注册后会出现在管理后台的用户列表里，管理员可以调整用户角色。

跟那些只能在前端删除评论的方案比起来，这个管理后台体验好太多了。你可以在手机浏览器上直接访问 /ui 管理评论，不用开电脑。

普通用户也可以通过评论框注册账号，登录后能看到自己的评论记录，修改自己的资料。

写在最后#

整个过程其实挺顺利的，从开始折腾到跑通大概花了半小时。主要时间花在了搞清楚 TiDB Cloud 的 SQL Editor 怎么一句一句执行建表语句上。

Vercel 免费版对个人博客来说完全够用，TiDB Cloud 的 5GB 免费空间对于评论数据也绰绰有余。如果你跟我一样，不想把评论数据交给第三方，又不想自己维护服务器，这个组合挺合适的。

唯一要注意的是 TiDB Cloud 的免费版有连接数限制，如果你的博客流量特别大，可能需要考虑升级。不过对于大多数个人博客来说，应该不会碰到这个瓶颈。

写于 2026 年 7 月，折腾 Waline 评论系统的记录

优化鼠标跟手性，顺便解决了完美死斗跳 ms 的问题

Tue, 21 Jul 2026 00:00:00 GMT

优化鼠标跟手性，顺便解决了完美死斗跳 ms 的问题#

起因#

最近在用的 ATKU2 老是感觉不跟手，延迟很高，开高 HZ 也没用。忍不住买了新鼠标还没到，想着趁这段时间控制变量，排查一下是不是电脑环境的问题。

无意中想起来 BoosterX，就是 simple 同款的那个优化软件。其实我心里不太喜欢这类软件，感觉细节没那么可控，但为了统一环境还是试了一下。

发现电源计划的问题#

用完 BoosterX 一键优化后，发现它自带了一个电源计划。试了一下，鼠标确实特别跟手了，但电脑帧数明显变低了。

于是我开始研究，发现是”完全体”电源计划的问题。

操作步骤#

1. BoosterX 解锁高级选项#

先在 BoosterX 里把电源管理的高级选项解锁：

BoosterX 解锁高级选项

2. 修改高性能电源计划的 USB 设置#

找到高性能电源计划，把 USB 设置里的三项全部改成 Off：

我用的高性能是 Windows 自带的，执行 powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61 就行。因为 BoosterX 自带的电源计划帧数远不如我的。

电源计划 USB 设置全部 Off

3. 设备管理器关闭 USB 节电#

进入设备管理器 → 通用串行总线控制器，把所有能关的”允许计算机关闭此设备以节约电源”都关掉：

设备管理器通用串行总线控制器

USB 集线器电源管理取消勾选

4. （可选）关闭 CS 全屏优化#

CS 记得关闭全屏优化。这个我没有认真测试，不敢保证一定要关，但关了没坏处。

全流程总结#

其实操作很简单：

打开 BoosterX，快速方法里选”最佳”，点应用
按上面的步骤改电源计划和设备管理器

BoosterX 快速方法选择最佳

效果#

真的非常见效。起码在我 9955HX + 5070Ti Laptop 装了 XOS11 25H2 的机器上，绝对不可能是什么心理作用，实在是太明显了。

另外这软件还顺带解决了一个问题——我只有完美死斗会跳 ms，突然一下 20ms 多卡手一下，但其他场景都没有，包括完美天梯实战也没有。一开始还以为是完美自己的问题，今天才发现不是。优化完也搞定了。

《零之使魔》观后感

Sun, 19 Jul 2026 00:00:00 GMT

《零之使魔》观后感#

问题：#

1. 剧情节奏方面#

最大的问题就是节奏太赶了。

基本上每个小故事都是两集左右解决，刚开始铺垫，马上进入冲突，然后迅速收尾，导致很多剧情看下来都有一种“刚热起来就结束了”的感觉。

如果能在几个大篇章之间穿插一两集露易丝和才人的日常回，让两个人不用靠各种事件推动，而是在平常相处中慢慢升温，效果应该会好很多。

毕竟这部作品最大的卖点就是露易丝和才人的感情变化，不是单纯看他们一路打怪升级。现在这种处理方式，多少有点浪费了角色之间的互动空间。

2. 感情线处理方面#

感情线的问题其实挺明显。

每次露易丝和才人闹矛盾，最后的和解过程都显得非常敷衍。尤其是才人的一些行为，放在现代人的标准里，已经不是简单的“花心”了，很多时候都快接近精神出轨甚至实质出轨。

结果露易丝每次都是气一会，然后被几句话哄好。

说实话，这种处理很难让人相信她是真的原谅了。很多时候不是观众想看男女主一直吵架，而是希望角色的情绪变化能合理一点。

这种强行快速翻篇的处理方式，看得人就是一种感觉：

事情明明没有解决，但编剧说解决了。

3. 人物塑造方面#

谢丝塔和女王这两个角色其实也有类似的问题。

她们明知道才人的正宫是露易丝，却依然毫不避讳地主动进攻。

异世界价值观不同，这个确实可以解释，但站在观众角度来看，多少还是会觉得膈应。

不过最大的问题还是才人。

才人这个角色真的属于典型日漫男主模板，而且是比较抽象的那种。

他明明是从现代日本来的，按理来说应该知道什么叫基本的边界感和分寸感，结果到了异世界之后直接放飞自我，一次次被欲望牵着走。

说难听点，就是经典“小头控制大头”。

很多时候看得真的很难受，因为露易丝已经明显表现出生气、不爽、吃醋了，他还是完全没有察觉。

这种“女主气炸了，男主还一脸问号”的桥段，在很多老日漫里确实很常见，但看多了是真的累。

其他角色方面，第一季前半段其实还挺有意思。

一开始那些贵族给人的感觉基本都不是什么好东西，校园霸凌、贵族阶级压迫这些元素也都有体现。

结果后面不知道怎么回事，全部开始大和解。

前面铺垫的矛盾基本都不了了之，很多设定甚至直接消失。

比如露易丝家族和丘鲁克家族之间的世仇，最后也没有真正展开。

前期还以为要搞什么贵族斗争、家族恩怨，结果后面大家全变兄弟，多少有点虎头蛇尾。

优点：#

露易丝不愧是四季 ED 都安排角色曲的绝对女主。

当然，她这个角色也是非常容易让人血压升高的类型。

脾气差、傲娇、喜欢嘴硬，这些缺点确实存在。我个人其实也不是特别喜欢这种属性。

就拿《俺妹》的桐乃来说，只看动画前几集还能忍住不骂桐乃的人，我觉得多少有点神人属性。

但话又说回来，缺点归缺点，露易丝这个角色确实塑造成功了。

她不是一个单纯的“傲娇女主模板”，随着剧情推进，她的成长、她和才人之间关系的变化，都让这个角色慢慢有了自己的魅力。

整体来说，《零之使魔》有不少明显的问题，剧情节奏、感情处理、男主塑造都有槽点。

但不可否认的是，它依然塑造出了一个非常经典的女主，也代表了一个时代异世界恋爱动画的风格。

Docker 部署 SearXNG 完整教程

Sun, 19 Jul 2026 00:00:00 GMT

🐳 Docker 部署 SearXNG 完整教程#

SearXNG 是一款开源的元搜索引擎，聚合多个搜索引擎的结果，同时不追踪用户、不建立用户画像，是注重隐私的搜索利器。本文将手把手演示如何通过 Docker Desktop 在 NAS 上快速部署 SearXNG。

一、搜索并拉取 SearXNG 镜像#

打开 Docker Desktop，进入左侧 「镜像仓库」 选项卡，在搜索框中输入 SearXNG：

在 Docker 镜像仓库中搜索 SearXNG

在搜索结果中选择官方镜像 searxng/searxng（下载量 50M+，⭐ 185），点击右侧的下载按钮拉取镜像。

二、从本地镜像创建容器#

镜像下载完成后，切换到左侧 「本地镜像」 选项卡，找到 searxng/searxng 镜像，点击右侧的 ▶ 运行 按钮启动创建流程：

在本地镜像中找到 SearXNG 并点击运行

在弹出的 「创建容器」 对话框中，确认以下设置：

配置项	值
镜像名称	`searxng/searxng:latest`
容器名称	`searxng`（可自定义）
开机自动开启	✅ 勾选

创建容器 - 基本设置

💡 提示：「资源限制」可保持默认（CPU 权重和内存限制均为自动），除非你的 NAS 性能紧张需要手动限制。

配置完成后，点击 「下一步」 进入高级设置。

三、配置端口映射#

在 「高级设置 → 端口设置」 中，添加端口映射规则，将容器的 8080 端口映射到宿主机的 8080 端口：

本地端口	容器端口	协议
8080	8080	TCP

端口映射设置

⚠️ 注意：如果 8080 端口已被其他服务占用，请将「本地端口」修改为其他可用端口（如 8081、8888 等），后续访问时使用对应端口即可。

四、配置存储路径映射#

继续在同一页面的 「存储位置」 部分，添加以下两条路径映射规则，将容器内的配置和缓存目录持久化到 NAS 本地：

NAS 宿主机路径	容器内路径	权限
`/vol1/1000/Docker/SearXNG/config`	`/etc/searxng`	读写
`/vol1/1000/Docker/SearXNG/cache`	`/var/cache/searxng`	读写

存储路径映射设置

🔑 关键提醒：务必映射 /etc/searxng 目录——这一步非常重要，因为我们后续需要覆盖默认的配置文件来自定义 SearXNG 的行为。如果不映射此路径，配置文件将仅存在于容器内部，容器重建后会丢失。

五、启动容器#

完成以上所有配置后，确认并启动容器。稍等片刻，容器即可正常运行。

当容器状态显示为 🟢 运行中，说明部署成功！此时可以通过 http://<你的NAS-IP>:8080 访问 SearXNG 搜索页面。

六、覆盖自定义配置文件#

为了获得更好的搜索体验，需要将默认配置文件替换为优化后的版本。

6.1 下载优化配置#

下载我提供的优化配置文件：

🔗 settings.yml 下载链接

6.2 替换配置文件#

进入你映射到 /etc/searxng 的 NAS 宿主机目录（例如 /vol1/1000/Docker/SearXNG/config）
找到目录中的 settings.yml 文件
用下载的文件覆盖原文件

6.3 重启容器#

配置文件替换完成后，回到 Docker Desktop 重启 SearXNG 容器，使新配置生效。

七、访问与使用#

打开浏览器，访问：

1
http://<你的NAS-IP>:8080

你将看到 SearXNG 的搜索界面，可以直接开始使用了 🎉

📋 常见问题#

Q1：端口冲突怎么办？#

修改本地端口映射即可，例如将本地端口改为 8081，然后通过 http://<NAS-IP>:8081 访问。

Q2：容器启动后访问不了？#

检查以下几点：

容器状态是否为「运行中」
端口映射是否正确
NAS 防火墙是否放行了对应端口

Q3：配置文件没有生效？#

确认配置文件已正确覆盖到映射的宿主机路径，并且重启了容器。

Workers 部署一个免费图床

Sat, 18 Jul 2026 00:00:00 GMT

折腾 CloudFlare ImgBed：用 Workers 部署一个免费图床#

为什么想搞这个#

之前我一直用别人搭的图床，偶尔抽风挂了就得换一个，挺烦的。后来想着干脆自己搞一个算了，反正也不需要多大的量，个人博客够用就行。

研究了一圈发现 CloudFlare ImgBed 这个项目挺合适的。它跑在 Cloudflare Workers 上，数据库用 D1，存储可以选 R2 或者 Txxxram Bot，免费额度对个人图床来说完全够用。最关键的是不用自己搞服务器，Cloudflare 的边缘网络速度也不差。

部署方式有两种：Pages 和 Workers。Pages 更简单，Dashboard 里点几下就行。Workers 需要用 GitHub Actions，适合熟悉 CI/CD 流程的用户，支持 push 到 main 分支时自动部署，也可以手动触发。两种方式功能完全一样，我选了 Workers，主要想试试 GitHub Actions 自动部署的感觉。

第一步：Fork 项目#

先去 GitHub 上找到 CloudFlare ImgBed，点右上角 Fork 到自己的账户下。这一步没什么好说的，应该都会。

第二步：准备 Cloudflare 资源#

2.1 获取 API Token#

模板选「编辑 Cloudflare Workers」就行。选完会跳到权限配置页面，这里直接默认就好，不用改什么。权限、账户资源、区域资源都是帮你配好的，往下翻到底提交就行。

创建完之后把 Token 记下来，后面要填到 GitHub Secrets 里。

2.2 获取 Account ID#

Account ID 在 Dashboard 首页右侧栏的 Account Details 区域。我一开始没找到，后来发现直接在首页问 Ask AI 就行，它会告诉你在哪。

Dashboard 首页 - 用 Ask AI 查 Account ID

复制下来备用。

2.3 创建 D1 数据库#

数据库用来存图床的文件元数据，比如文件名、大小、上传时间之类的。KV 和 D1 二选一，我选了 D1，免费额度比 KV 多不少。

进 Dashboard 左侧「存储和数据库」→「D1 SQL 数据库」，点「创建数据库」。名字必须填的 img_d1，区域选了亚太地区，然后点创建。

创建完之后回到 D1 数据库的概述页面，这里能看到数据库 ID。点旁边的复制按钮把 ID 复制下来，后面配置 GitHub Secrets 要用。

D1 概述页 - 红色箭头指向复制数据库 ID 的按钮

接下来去 D1 的「控制台」选项卡，把初始化 SQL 执行一下。这段 SQL 会建好几个表：files（存文件信息）、settings（存配置）、index_operations（索引操作记录）之类的，还有索引和触发器。

D1 控制台 - 执行 CREATE TABLE 成功，显示"此查询已成功执行"

直接复制粘贴执行就行。要分段输入，别一次全贴进去，容易出问题。控制台会显示每条语句的执行结果，看到「此查询已成功执行」就说明没问题。

这里贴一下主要的建表语句，方便你对照检查：

1
CREATE TABLE IF NOT EXISTS files (
2
    id TEXT PRIMARY KEY,
3
    value TEXT,
4
    metadata TEXT NOT NULL,
5
    file_name TEXT,
6
    file_type TEXT,
7
    file_size TEXT,
8
    upload_ip TEXT,
9
    upload_address TEXT,
10
    list_type TEXT,
11
    timestamp INTEGER,
12
    label TEXT,
13
    directory TEXT,
14
    channel TEXT,
15
    channel_name TEXT,
16
    tg_file_id TEXT,
17
    tg_chat_id TEXT,
18
    tg_bot_token TEXT,
19
    is_chunked BOOLEAN DEFAULT FALSE,
20
    tags TEXT,
21
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
22
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
23
);

展开收起

还有 settings、index_operations、index_metadata、other_data 几个表，以及一堆索引和触发器。完整的 SQL 在项目的 database/init.sql 里。

踩坑提醒：如果你之前已经建过表想重新来，先把 SQL 开头那几行 DROP TABLE 的注释去掉，执行一遍清掉旧表，再跑建表语句。生产环境慎用这个操作。

2.4 创建 R2 存储桶（可选）#

如果需要使用 R2 存储渠道，进 Dashboard 左侧「存储和数据库」→「R2 对象存储」，点「创建存储桶」，记下存储桶名称。我暂时没用 R2，先用默认的渠道跑起来再说。

第三步：绑定 D1 数据库#

在配置 GitHub Secrets 之前，先把 D1 数据库绑定到 Worker 上。进 Dashboard → Workers 和 Pages → 找到你刚创建的 Worker（默认叫 cloudflare-imgbed），点进去，选「绑定」标签页。

Worker 绑定页面 - 点右上角的「添加绑定」按钮

点「添加绑定」，选 D1 数据库。变量名称填 img_d1（跟代码里用的名字一致），D1 数据库选你之前创建的那个。

添加 D1 绑定 - 变量名称填 img_d1，数据库选 img_d1

点「添加绑定」就搞定了。

第四步：配置 GitHub Secrets#

回到 fork 的仓库，进 Settings → 机密和变量 → 操作。

一开始仓库里什么都没有，是空的。

点「New repository secret」把需要的值一个个加上。Secrets 是加密存储的，Actions 日志里不会泄露。别用 Variables，public 仓库的话所有人都能看到你的配置。

如果需要配置部署保护规则（比如环境机密），也可以在 Settings → 环境里设置。

最终需要加的 Secrets 如下：

GitHub 仓库机密配置完成 - 三个必填项都加好了

Secret 名称	说明	是否必填
`CLOUDFLARE_API_TOKEN`	Cloudflare API Token	必填
`CLOUDFLARE_ACCOUNT_ID`	Cloudflare Account ID	必填
`D1_DATABASE_ID`	D1 数据库 ID	和 KV 二选一
`KV_NAMESPACE_ID`	KV 命名空间 ID	和 D1 二选一
`R2_BUCKET_NAME`	R2 存储桶名称	可选
`WORKER_NAME`	Worker 名称	可选，默认 `cloudflare-imgbed`
`WORKER_VARS`	业务环境变量（JSON）	可选

说实话大部分配置不用在这写。像存储渠道、审查策略什么的，部署完在管理面板里都能改。我一开始把什么都填了，后来发现根本没必要。WORKER_VARS 只有当你需要配 Telegram Bot 这类特殊渠道的时候才用得上，而且格式要是 JSON：

1
{
2
  "TG_BOT_TOKEN": "your-bot-token",
3
  "TG_CHAT_ID": "your-chat-id"
4
}

不过真要用 Telegram 渠道，我建议还是部署完在管理面板里配，比在这填 JSON 方便多了。

第五步：运行部署#

进仓库的操作页面，左边选「Deploy to Cloudflare Workers」。

GitHub Actions - 选择 Deploy to Cloudflare Workers 工作流

点「Run workflow」，选 main 分支，开始跑。

GitHub Actions - 部署进行中，deploy 任务正在执行

部署完成后，可以通过 https://<worker-name>.<account-subdomain>.workers.dev 访问。第一次跑可能会慢一点，耐心等一下。可能国内访问不了，可以直接看我的Woker优先IP的文章。

最后看看效果#

部署完绑定好之后，访问你的 Worker 地址，应该能看到图床界面了。

部署完成 - CloudFlare ImgBed 图床界面，支持拖拽上传

界面还挺好看的，支持拖拽上传、点击上传、Ctrl+V 粘贴上传，底部还有文件管理和统计。默认就能用，挺省心的。

部署完成后，记得去管理面板配置存储渠道，不然图片传不上去。

踩坑记录#

整个过程其实挺顺利的，就几个小地方需要注意：

D1 初始化 SQL 要分段执行：一次全贴进去可能会报错，我分了几次才跑成功。控制台会显示每条语句的执行结果，看到「此查询已成功执行」就说明没问题
WORKER_VARS 不用急着配：大部分业务设置在管理面板都能改，不用一开始就写死在 Secrets 里
部署前记得绑定 D1：光配置 Secrets 不够，还得在 Cloudflare 这边把数据库绑到 Worker 上，不然部署完图床打开是白的

接下来打算#

部署完能跑了，下次出个配置文章

写于 2026 年 7 月，折腾 CloudFlare ImgBed 部署的记录

网站每天多少人访问你知道吗？用 Vercel 零成本搭了一个 Umami 网站统计系统

Sat, 18 Jul 2026 00:00:00 GMT

网站每天多少人访问你知道吗？用 Vercel 零成本搭了一个 Umami 网站统计系统#

搭了网站之后，我一直想看看每天到底有多少人来访问。

说实话，之前一直没搞统计，不是不想看数据，就是觉得 Google Analytics 太重了，配一堆东西看着就头大。后来我一想，有没有那种简单点的，能直接看到访客数、来源、热门页面就够了。

搜了一圈发现了 Umami，开源的网站统计工具，界面挺干净的。最关键的是——能直接部署到 Vercel 上，不用买服务器，零成本。

我一想，反正也不花钱，试试呗。

搭好之后用了几天，效果确实不错。先放几张图给你们看看：

这是 Umami 的概览页面，访客来自哪些国家一目了然，世界地图上直接能看到分布：

Umami 概览页面

访客数、访问次数、浏览量、跳出率、平均访问时长，数据摆在那里：

Umami 实时数据

热门页面排行也很清楚，哪篇文章有人看、哪篇没人看，心里有数：

Umami 热门页面

还有来源分析，从哪个搜索引擎来的、哪个域名引过来的，都有：

Umami 来源分析

看到这些数据之后，我才真正知道自己网站的流量情况。以前全靠猜，现在数据就摆在后台里。

下面说说我是怎么搭的。

为什么选 Umami#

其实一开始我不想用 Neon 的，因为它的免费计划远不如 TiDB。TiDB 的免费额度很大，听起来很诱人。

但问题是——TiDB 是 MySQL 的，Umami 用的是 PostgreSQL，不太兼容。整了半天还是放弃了，一直构建失败给我整红了。

后来我一想，算了，换个思路吧。Umami 官方说支持 Vercel 一键部署，Neon 提供免费的 PostgreSQL，那就试试 Neon。

事实证明这个选择是对的。部署过程比我想象的简单很多，而且 Neon 的免费套餐对个人站点来说完全够用——0.5 GB 存储、100 个项目上限，足够了。

部署过程#

一、Fork 项目#

打开 Umami 的 GitHub 项目，点右上角的”复刻”，把代码拷到自己账号下。

项目地址：https://github.com/umami-software/umami

GitHub 复刻 Umami 项目

二、在 Vercel 导入项目#

Vercel 新建项目

在”导入 Git 仓库”下面找到刚复刻的 umami 项目，点”导入”。

Vercel 导入 Git 仓库

项目名称可以随便填，我直接用的 “umami”。其他保持默认就行，直接点”部署”。

这一步会部署失败，因为还没配数据库，不用管它。

三、创建 Neon 数据库#

回到 Vercel 控制台，左侧菜单找到”存储”，点进去。然后点右上角的”创建 Database”。

Vercel 部署设置

Vercel 存储页面

在弹出的窗口里选 Neon（无服务器 Postgres），然后点”继续”。

选择 Neon 数据库

区域选近一点的，我选了 Singapore（Southeast）。其他保持默认，往下拉点”继续”。

Neon 区域选择

数据库名字可以随便填，确认一下信息没问题就点安装。

四、关联项目#

数据库创建好之后，点”Connect to Project”，选择你刚才创建的 umami 项目，然后点”Connect Project”。

五、重新部署#

回到 Vercel 的”部署记录”页面，找到刚才失败的那条记录，点右侧三个点，选”重新部署”。

等几分钟，看到绿色的”就绪”就说明部署成功了。

不过我折腾的过程中遇到了不少问题。你看这个部署记录，一堆红色的”错误”，给我整红了。反复试了好多次才成功，中间有几次差点放弃。

部署记录——一堆红色错误

后来发现是数据库连接的问题，重新关联了一次项目之后就好了。如果你也遇到部署失败，先检查一下数据库有没有关联成功。

登录后台#

部署成功后，打开你的 Umami 地址（Vercel 给的那个 .vercel.app 域名），就能看到登录页面。

Umami 登录页面

初始账号密码是：

用户名：admin
密码：umami

登录后记得改密码。

绑定自定义域名#

如果你有自己的域名，可以在 Vercel 的”域名”页面绑定。我绑的是 umami.9ll.uk，配置好之后状态显示”Valid 配置”就行了。（上面那张部署记录截图底部也能看到域名配置的部分。）

绑完域名之后，你的 Umami 就可以通过自己的域名访问了，看起来也更专业一点。

最后#

折腾这些东西最大的乐趣，其实不是最后那个结果，而是过程中折腾的那些体验。

这次搭 Umami 总体来说还行，虽然中间踩了不少坑——TiDB 不兼容、部署反复失败、数据库关联出问题——但折腾完之后用起来确实挺舒服的。数据一目了然，每天打开后台看看访客数、来源、热门页面，心里有数多了。

如果你也搭了网站但一直没关注数据，可以试试 Umami。零成本、部署简单、数据清晰，对个人站长来说够用了。

写于 2026 年 7 月，折腾 Umami 网站统计的记录

Cloudflare Tunnel Docker部署教程

Sat, 18 Jul 2026 00:00:00 GMT

为什么想搞这个#

我家里有台 NAS，上面跑了不少服务。平时在家用局域网访问挺方便的，但出门在外就抓瞎了。

之前试过端口转发，但总觉得不太安全，而且公网 IP 还是动态的，每次都要重新连。后来了解到 Cloudflare Tunnel，发现这东西挺合适的——不用开端口，不用公网 IP，也不用折腾 DDNS，流量还走 Cloudflare 的网络加密。

整个过程其实不复杂，跟着 Cloudflare 的界面一步步来就行。

第一步：进入 Zero Trust 控制台#

进入Zero Trust

第二步：创建隧道#

进去之后点左侧的”连接器”，然后点右上角的”创建隧道”。

连接器页面

隧道类型选 Cloudflared，点”选择 Cloudflared”。

选择Cloudflared

接下来给隧道起个名字，起完之后会到配置页面。这里选 Docker，会给你一段 docker run 命令，直接复制就行。

获取Docker命令

第三步：在服务器上部署#

SSH 到你的服务器，把刚才复制的命令粘贴进去。第一次跑会拉取镜像，等一会儿就好。

拉取Docker镜像

镜像拉完、容器跑起来之后，回到 Cloudflare Dashboard，能看到连接器状态变成”已连接”。确认没问题后点”下一步”。

连接器已连接

第四步：配置公网访问#

接下来设置把哪个域名指向哪个本地服务。

子域名填你想用的，比如我填了 fnos，域名选你托管在 Cloudflare 的那个，完整主机名就是 fnos.9ll.us。

服务类型选 HTTP，URL 填你本地服务的地址和端口。我填的是 localhost:5244，这是 fnOS 的 Web 端口。

填完点”保存设置”就好了。

配置公共主机名

到这里正常来说就结束了，通过 fnos.9ll.us 就能访问你 NAS 上的服务了。

代理环境下的坑#

但是，如果你的 Docker 宿主机开了代理，而且 tunnel 流量也被代理了，那可能会连不上。

这种情况下需要做两件事：

把本地地址改成局域网 IP（比如 192.168.x.x），不要用 localhost
代理的 Fake-IP-Filter 里加上这几个域名：

1
+.argotunnel.com
2
+.v2.argotunnel.com
3
api.cloudflare.com

+.cloudflare.com 看情况加不加都行。

Fake-IP-Filter配置

这几个域名不加的话，Cloudflare Tunnel 的连接可能会被代理软件劫持或者解析到错误的地址，导致隧道连不上。加上之后让它走直连就正常了。

fnOS 用户的另一个选择#

如果你是飞牛 fnOS 用户，应用商店里有个 Cloudflare Tunnel 的 GUI 应用，操作比 Docker 简单不少，界面化配置挺方便的。

不过我试下来感觉没有 Docker 容器那么稳，可控性也差一些。而且这个应用如果连不上报错的话，去设置里把协议改一下——Docker 默认用的是 QUIC，应用默认是 HTTP/2，两个都试试看哪个能通。

fnOS Tunnel应用设置

我个人还是推荐 Docker 方式，毕竟出了问题排查起来更方便，日志也能直接看。

写于 2026 年 7 月，折腾 Cloudflare Tunnel 的记录

iStoreOS 安装 OpenClash

Fri, 17 Jul 2026 00:00:00 GMT

上一篇写了怎么在 FNOS 上装 iStoreOS 虚拟机，装完之后总得干点啥吧。iStoreOS 本身就是 OpenWrt 的改版，拿来跑 OpenClash 再合适不过了。

其实我之前一直用的是软路由方案，后来换了 NAS 就想着能不能把软路由也虚拟化了，省一台设备。装完 iStoreOS 虚拟机之后第一件事，就是把 OpenClash 搞上。

一、找到后台地址#

iStoreOS 开机之后，输入 quickstart，然后选第一个回车。

quickstart 查看 IP

然后就能看到后台管理地址了。我这边显示的是 192.168.31.195，你的可能不一样，看实际显示的就行。

浏览器打开这个地址，就能进 Web 管理页面。

二、改密码#

进去之后第一件事，建议先改密码。

进 系统 → 管理权，找到「路由器密码」那栏，改成你自己的。

设置 root 密码

不改的话默认密码好像挺简单的，后面进终端要用 root 登录，还是改一下比较安心。

三、装依赖#

这一步是最容易出问题的，

进 服务 → 终端（TTYD），用户名 root，密码填刚才设的。

先更新一下软件源：

Terminal window

1
opkg update

终端 opkg update

这一步可能会冒出一堆报错，类似 Signature check failed 或者 returned 8。我第一次看到这个报错的时候还挺慌的，以为哪里搞错了。后来查了一下，好像是签名验证的问题，不影响后面安装。不用管它，继续往下走就行。

然后装依赖包：

Terminal window

1
opkg install bash iptables dnsmasq-full curl ca-bundle ipset ip-full iptables-mod-tproxy iptables-mod-extra ruby ruby-yaml kmod-tun kmod-inet-diag unzip luci-compat luci luci-base

安装依赖包

装的时候会看到一堆输出，不用逐行看，只要最后没报致命错误就行。有些包可能会提示已经装过了，那说明 iStoreOS 自带了一部分，跳过就好。

整个依赖安装大概要等个一两分钟，看你的网络情况。

四、下载并安装 OpenClash#

依赖装好之后，就可以装 OpenClash 本体了。

去 GitHub 的 OpenClash Releases 页面，找到最新版本，下载 ipk 文件。

下载 OpenClash

下载的时候注意看一下文件名，别下错了。一般下载量最大的那个就是。

然后进 系统 → 软件包，点「上传软件包」，把刚才下载的 ipk 传上去。

上传软件包

上传完会弹个确认框，点安装就行。安装过程很快，几秒钟就完事。

五、首次使用#

装完之后刷新网页，服务菜单下面就能看到 OpenClash 了。如果没看到，多刷新几次，或者等一会儿再试。

第一次进去可能会提示你下载内核，还会给你一个已经测速好的 CDN 列表。选个延迟低的点下载就行。

Mihomo 管理页面

内核下好之后，导入你的订阅就可以用了。

极简流程#

quickstart → 选第一个 → 拿到后台地址
系统 → 管理权 → 改密码
服务 → 终端 → opkg update → opkg install 装依赖
GitHub 下载 OpenClash 的 ipk → 系统 → 软件包 → 上传安装
刷新 → 服务 → OpenClash → 下载内核 → 导入订阅

写于 2026 年 7 月，折腾 iStoreOS 安装 OpenClash 的记录

在 FNOS 上装 iStoreOS 虚拟机

Thu, 16 Jul 2026 00:00:00 GMT

在 FNOS 上装 iStoreOS 虚拟机#

前阵子一直在折腾 NAS，用的是 FNOS。用了一段时间感觉还行，但有些网络方面的功能想折腾一下，就想着在上面跑个 iStoreOS 的虚拟机。

iStoreOS 是基于 OpenWrt 的，软路由功能该有的都有，而且有应用商店，装插件方便。我之前在别的机器上装过，这次想在 FNOS 上跑一个。

一、准备工作#

先去 iStoreOS 官网下了个固件，x86_64 的版本。下载地址是 fw.koolcenter.com/iStoreOS/x86_64/，挑一个合适的版本就行。

01-下载iStoreOS固件

然后在 FNOS 里先把 OVS 和 SSH 开了。

OVS 在 iStoreOS 后台的网络设置里关掉。

02-OVS设置

SSH 在 FNOS 的系统设置里开启。

03-SSH设置

二、新建虚拟机#

FNOS 的虚拟机管理界面挺直观的，新建一个虚拟机，填好名称，选 Linux 系统。

04-新建虚拟机

先随便上传一个 ISO 文件到文件管理，后面要用替换镜像的方式装 iStoreOS。

05-上传ISO文件

配置虚拟机的 CPU、内存、挂载这个 ISO。

06-硬件配置

存储空间#

存储空间我选了个 SSD，给 16G 其实就够了，富哥可以上 32G 甚至更大，看你自己。

07-添加存储空间

网卡#

网卡也选好，这个按自己网络环境来就行。

08-添加网卡

三、镜像转换#

iStoreOS 官方给的是 .img 格式的镜像，但 FNOS 的虚拟机不认这个格式，它用的是 .qcow2。所以需要转换一下。

我用的工具是 StarWind V2V Converter，免费的，下载地址： https://www.starwindsoftware.com/tmplink/starwindconverter.exe

先安装 V2V。

09-V2V安装

打开后选择 Local file，选自己下载的 iStoreOS .img 镜像（记得先解压）。

10-V2V选择来源

11-V2V确认源镜像

目标位置选本地文件。

12-V2V选择目标位置

目标格式选 QCOW2。

13-V2V选择目标格式

版本选 Qcow2 version 3。

14-V2V选择版本

设置输出文件名，然后点 Convert。

15-V2V开始转换

转换完成。

16-V2V转换完成

我这边出来的文件名是 istoreos-24.10.7-2026070313-x86-64-squashfs-combined.qcow2。

四、替换镜像#

这个步骤有点绕，我第一次搞的时候卡了一会儿。

FNOS 新建虚拟机会自动生成一个 .qcow2 文件，但我们要把这个文件替换成自己转换好的那个。

先到虚拟机详情里找到实际存储路径。

17-虚拟机存储路径

用 SSH 连上 FNOS，找到这个路径下的文件。

18-SSH文件管理

操作步骤：

复制 FNOS 自动生成的那个 .qcow2 的文件名（一串 UUID 那种，比如 b4cf05dd-...-q6m2.qcow2）
删掉 FNOS 自动生成的文件
把自己上传的镜像重命名为刚才复制的文件名

其实就是偷梁换柱——让 FNOS 以为自己生成的文件还在，实际上已经被换成了 iStoreOS 的镜像。

五、开机#

替换完之后，回到虚拟机配置页面，把之前挂载的那个 ISO 镜像删掉（点叉号）。

19-移除ISO镜像

20-确认移除

然后直接开机。

看到 iStoreOS is ready! Please press Enter to activate this console. 这行提示，回车即可。

21-启动成功

折腾完的感受#

说实话，在 FNOS 上装 iStoreOS 不算复杂，就是镜像转换和替换这个环节稍微绕一点。核心思路就是用 V2V 把 .img 转成 .qcow2，然后替换掉 FNOS 自动生成的那个文件。

装好之后能开机了，配置和具体玩法我后面再写一篇文章细说。反正先跑起来再说，后面慢慢折腾。

极简流程#

下载 iStoreOS 固件，FNOS 开启 OVS 和 SSH
新建虚拟机，配好存储和网卡
用 StarWind V2V 把 iStoreOS 的 .img 转成 .qcow2
SSH 连 FNOS，找到虚拟机存储路径，把转换好的 .qcow2 上传
复制 FNOS 自动生成的 .qcow2 文件名，删掉它，把上传的镜像改名替换
回到虚拟机，开机，回车

写于 2026 年 7 月，在 FNOS 上折腾 iStoreOS 的记录

折腾博客的第一步：不用服务器搭建 Firefly 博客

Wed, 15 Jul 2026 00:00:00 GMT

很多人想搭一个自己的博客，但真正开始的时候才发现：

买服务器麻烦。

配环境麻烦。

搭数据库麻烦。

甚至只是把文章显示出来，都要折腾半天。

其实现在很多博客已经不需要服务器了。Astro 这类静态博客框架，写完文章后直接生成网页文件，丢到 Vercel、Cloudflare Pages 这类平台上就能跑。不用管服务器，不用装数据库，免费额度对个人博客也够用。

我选择 Firefly 的原因很简单：它基于 Astro，速度快，而且默认设计已经比较完整。不需要自己从零写主题，稍微改改配置，就能变成一个属于自己的博客。

今天就记录一下我自己部署 Firefly 博客主题时整理的一套流程。Firefly 是一个基于 Astro 的博客主题，支持暗色模式、评论系统、全文搜索这些功能，样式也挺好看。下面以 Vercel 为例，从零开始讲怎么把它跑起来。

Firefly 博客首页示意

一、Fork 仓库#

打开 Firefly 的 GitHub 仓库：CuteLeaf/Firefly

页面右上角有个 Fork 按钮，点一下。

Fork

弹出的页面里 Repository name 可以改成你喜欢的名字，比如 my-blog，然后点 Create fork。等几秒钟仓库就到你账号下了。浏览器地址栏变成 https://github.com/你的用户名/my-blog 就说明成功了。

Fork 比下载压缩包好的地方在于：后面作者更新了代码，你的仓库页面上会出现 Sync fork 按钮，点一下就能同步最新版本。

二、注册 Vercel 并导入项目#

打开 vercel.com，点 Sign Up，选 Continue with GitHub，用 GitHub 账号登录。

登录后进入 Dashboard，右上角点 Add New… → Project。

Vercel 会列出你 GitHub 账号下所有的仓库。找到刚才 Fork 的那个，点 Import。

如果列表里没看到，点页面上的 Adjust GitHub App Permissions，授权 Vercel 访问那个仓库，回来刷新就有了。

导入之后进入配置页面，Vercel 会自动识别 Astro 框架。确认这几个参数：

Build Command: pnpm build
Output Directory: dist
Install Command: pnpm install

一般 Vercel 会自动填好，检查一下没问题就点 Deploy。

三、等构建完成#

点完 Deploy，Vercel 开始构建。页面上会显示四个阶段：

Cloning — 拉代码
Installing — 安装依赖包
Building — 编译。这一步最慢，要处理图片、生成搜索索引，大概一两分钟
Finalizing — 收尾

构建成功后页面会跳转，显示 Congratulations，上面有你的博客地址，格式大概是 https://my-blog-xxxxx.vercel.app。点开就能看到博客了。

如果构建失败了，点 Building 旁边的 View logs 看报错。最常见的是 Node.js 版本太低——Firefly 要求 22 以上。去项目的 Settings → General → Node.js Version，改成 22.x，保存后回到 Deployments 点 Redeploy 就行。

四、绑定自定义域名#

默认的 my-blog-xxxxx.vercel.app 能用，但你多半想用自己的域名。

在项目的 Settings → Domains，输入你的域名（比如 blog.example.com），点 Add。Vercel 会根据你的域名类型提示对应 DNS 记录，按照页面提示添加即可。

域名在哪里买的就去哪里加。阿里云搜「云解析 DNS」，腾讯云搜「DNSPod」，Cloudflare 在域名的 DNS 设置页。

加完回到 Vercel 等一两分钟，点 Refresh。验证通过后 Vercel 会自动申请 HTTPS 证书。

五、改站点配置#

博客上线了，但标题、副标题还是默认值。

这些在 src/config/siteConfig.ts 里改：

1
export const siteConfig: SiteConfig = {
2
  title: "你的博客名",
3
  subtitle: "你的副标题",
4
  site_url: "https://你的域名",
5
};

site_url 一定要改成你实际的域名，不然 sitemap 和 RSS 生成的地址会是错的。

其他配置文件都在 src/config/ 目录下：

profileConfig.ts — 头像、简介、社交链接
navBarConfig.ts — 顶部导航栏
sidebarConfig.ts — 侧边栏
commentConfig.ts — 评论系统（支持 Twikoo、Waline、Giscus，这个之后我有详细的搭建，也是vercel或者cf workers）

具体怎么改看 Firefly 官方文档，写得比较全。

改完怎么生效？往下看。

六、写文章，push 就发布#

这是你后面用得最多的操作。有两种方式，看你习惯哪种。

方式一：直接在 GitHub 网页上写（不需要装任何东西）#

所有操作都在浏览器里完成：

打开你的 GitHub 仓库，进入 src/content/posts/ 目录
点 Add file → Create new file
文件名填 我的第一篇文章/index.md（斜杠前面是文件夹名，GitHub 会自动创建）
写内容：

1
---
2
title: 我的第一篇文章
3
published: 2026-07-15
4
description: 这是一篇测试文章
5
tags: [测试, 博客]
6
category: 日常
7
---
8

9
正文内容。支持 Markdown 语法。

页面底部填个提交信息，点 Commit changes

提交之后回到 Vercel Dashboard，它已经开始自动构建了。等一两分钟，新文章就上线了。

上传配图的话，在同一个文件夹里点 Add file → Upload files，把图片拖进去。在文章里用 ![描述](./图片名.png) 引用。

方式二：本地编辑，push 到 GitHub（推荐）#

经常写文章的话建议装本地环境，用自己顺手的编辑器写。

装环境（一次性）：

装 Node.js 22.x 版本
打开终端（Windows 搜 PowerShell，Mac 搜终端），运行 npm install -g pnpm
装 Git
终端里运行 git clone https://github.com/你的用户名/my-blog.git

日常流程：

在 src/content/posts/ 下新建文件夹，写 index.md
想预览效果就跑 pnpm dev，浏览器打开 http://localhost:4321
写好之后：

Terminal window

1
git add .
2
git commit -m "新增一篇文章"
3
git push

Push 上去，Vercel 自动构建，一两分钟后新文章上线。不需要登录 Vercel，不需要手动触发任何东西。

用 VS Code 的话更方便，左侧栏有 Git 按钮，点一下就能提交推送。

七、自动部署是怎么回事#

你 push 代码到 GitHub，Vercel 怎么知道的？

导入仓库的时候，Vercel 会在你的 GitHub 仓库里装一个 Webhook。每次你 push 代码到主分支，GitHub 通知 Vercel，Vercel 自动拉代码、构建、部署。你什么都不用做。

还有个有用的功能：新建分支 push 上去的话，Vercel 会给这个分支生成一个预览地址（Preview Deployment），主分支不受影响。不确定改动效果的时候，先在分支上试试。

总结#

日常写博客的流程就四步：

在 src/content/posts/ 下写文章
Push 到 GitHub（或者在 GitHub 网页上直接提交）
Vercel 自动构建，等一两分钟
新文章上线

买服务器、配 Nginx、搞 HTTPS 这些全不用管。写完推上去就好了。

后面我还会继续记录 Firefly 的一些配置，比如评论系统、Umami 网站统计、自定义主题修改等。如果你也喜欢折腾自己的小网站，可以一起交流。

有不懂的问题直接在评论区问

CloudMail 一个基于Workers无限收发邮箱的开源项目

Mon, 13 Jul 2026 00:00:00 GMT

前言#

只需要一个域名，就可以创建无限个的邮箱地址，类似各大邮箱平台的体验。本项目可部署到 Cloudflare Workers，个人 0 服务器成本，搭建属于自己的邮箱服务。

当然，你也能用它来管理不同平台的账号邮箱，把注册邮箱和私人邮箱分开，更加安全，可以完全隐藏自己的真实邮箱

前提条件： 你的域名必须已托管至 Cloudflare（即 NS 服务器指向 Cloudflare）。

（昨天还想着自己用 WPF 做一个调用 Resend API 的项目呢…今天就发现了更好的开源方案）

第一部分：部署 CloudMail 收件服务#

整体流程：Fork 仓库 → 创建 Worker → 配置环境变量 → 创建存储资源并绑定 → 设置域名邮件路由 → 初始化数据库 → 注册管理员

1. Fork 仓库并创建 Worker#

首先 Fork 仓库：cloud-mail

然后在 Cloudflare Dashboard 中创建 Worker，选择从 GitHub 导入。

点开 高级设置，将路径设置为 /mail-worker，这一步不要漏掉。

从Github导入Worker

2. 配置环境变量#

在 Worker 的设置 → 变量和机密中，添加以下环境变量：

变量名	必需	用途
`domain`	✅	邮箱域名。多域名用 JSON 数组格式，例如 `["example.com","example2.com"]`
`admin`	✅	管理员邮箱地址，例如 `admin@example.com`
`jwt_secret`	✅	JWT 密钥，随便输入一串字符串即可，不要包含特殊字符

⚠️ 建议： 如果你还没有绑定自定义域名到 Worker，推荐先绑定再配置环境变量。绑定域名的方式见优选 IP 文章。

环境变量配置

3. 创建存储资源（D1 + KV + R2）#

CloudMail 需要三种存储资源，分别用于数据库、缓存和附件存储：

资源类型	推荐命名	用途
D1 数据库	`Cloud-mail-DB`	存储邮件数据
KV 存储	`Cloud-mail-KV`	缓存与配置
R2 存储桶	`Cloud-mail-R2`	邮件附件

按推荐名称创建即可，当然你也可以用自己的命名。

创建D1数据库

创建KV存储

创建R2存储桶

创建完成后，回到 Worker 的设置 → 绑定页面，将三个资源全部绑定上去：

⚠️ 绑定的时候变量名必须严格为 db、kv、r2，否则 Worker 无法正确读取。

绑定KV和DB变量

绑定设置详情

4. 配置域名邮件路由#

进入 Cloudflare 的 电子邮件 → 电子邮件路由 页面，将收到的邮件转发到刚才创建的 Worker 项目。

如果你的域名刚托管过来，可能需要先点击启用电子邮件路由，Cloudflare 会自动添加所需的 MX 记录。

域名邮件路由设置

5. 初始化数据库并注册管理员#

在浏览器中访问以下地址来初始化数据库：

1
https://你的worker域名/api/init/你的jwt_secret

看到浏览器返回 success 即表示初始化成功。

然后直接访问：

1
https://你的worker域名/

在页面上 注册管理员账号。管理员账号就是你在步骤 2 中设置的 admin 环境变量值。

到这一步，CloudMail 的收件功能就部署完成了 🎉

管理员登录界面

第二部分：配置 Resend 发件服务#

Cloudflare Workers 本身不支持发邮件（25 端口被封禁），所以我们需要借助第三方发件服务。Resend 提供了免费额度（每月 3000 封），对个人使用来说足够了。

整体流程：注册 Resend → 添加域名并验证 DNS → 创建 API Key → 配置 Webhook 回调 → 填入 Token

1. 注册 Resend 并添加域名#

前往 Resend 官网注册账号，然后在控制台中添加你的域名。

添加后，Resend 会提供几条 DNS 记录（SPF、DKIM 等），你需要到 Cloudflare 中添加这些记录来完成域名验证。

Resend添加域名

2. 创建 API Key#

在 Resend 控制台的 API Keys 页面创建一个新的 Key，复制保存好，后面要用。

创建Resend API Key

3. 配置 Webhook 回调#

在 Resend 的 Webhooks 页面，添加一个新的 Webhook，用于接收邮件发送状态的回调通知：

Endpoint URL 填写：https://你的worker域名/api/webhooks
Events 权限选择如下图所示：

添加Webhook

Webhook权限设置

4. 填入 Resend Token 到 CloudMail#

回到 CloudMail 的管理员后台，在设置页面中填入刚才复制的 Resend API Key：

填入Resend Token

结语#

至此，CloudMail 已经完成全部部署。

收邮件由 Cloudflare Email Routing + Workers 负责。
发邮件由 Resend 提供 API 支持。

整个方案几乎不需要服务器，只需要一个托管到 Cloudflare 的域名，就能拥有自己的邮箱系统。

另外，CloudMail 后台还支持将收到的邮件自动转发到自己的真实邮箱，即使不经常登录后台，也不会错过任何新邮件。

过程中遇到问题可以直接在评论区留言，看到都会回复的

文章是摆烂技术站原创，需要转载等用途请联系WeChatOfficialAccount@9ll.uk

Cloudflare+Resend域名邮箱

Sun, 12 Jul 2026 00:00:00 GMT

前言#

偶尔生活需要隐藏自己的真实邮箱或者无限邮箱薅羊毛？

本篇文章为此诞生

在Cloudflare开启电子路由（收邮件）#

1.先进去自己的控制台，点击电子邮件路由，接入自己的域名

routing

2.点击设置，然后点击锁定，貌似点了锁定就好像会自己解析下面的DNS记录？反正没自动解析就自己动手一下吧

lock

3.然后去目标地址，增加一下自己真正的邮箱，然后点击添加，我记得会发一封验证邮件，自己去验证一下就好啦

添加目标邮箱

4.之后就是去路由规则，点击编辑，操作选择发送到电子邮件，目标填写自己的邮箱，点击保存，记得把状态开启，变成活跃

路由规则编辑

选择发送到电子邮件

保存路由规则

配置Resend（发送邮件）#

1.注册好Resend后，来到Domains · Resend

Resend添加域名

2.然后按信息配置好DNS记录即可(没图)，因为这玩意免费计划只能添加一个域名，懒得删了再弄了，反正也没有难度

3.之后是用Resend发邮件即可(…)

结语#

Resend只能添加一个域名挺伤的，其实还有一个专门做了一套可以运行在workers的开源项目，这两天我部署一个玩玩

Resend特么的貌似还不能直接在控制台发送邮件，只有一个不好用的广播，但是官方提供了非常详细的Api文档，这几天有时间我写一个客户端开源一下？

Cloudflare Workers优选IP

Sun, 12 Jul 2026 00:00:00 GMT

什么是优选IP，为什么要搞这个#

用过 Cloudflare 的人应该都有感觉：国内访问 Cloudflare 托管的网站，有时候慢得离谱。明明是全球最大的 CDN 厂商之一，怎么体验还不如一些小厂？

原因出在路由上。

Cloudflare 用的是 anycast 技术——同一个 IP 地址在全球很多地方都有节点，你的请求会被路由到”最近”的那个。问题是这个”最近”是按网络拓扑算的，不是按地理距离。国内三大运营商到 Cloudflare 节点的线路经常绕路，比如电信用户可能被送到美国圣何塞的节点，明明直线距离不到两千公里的事，数据包绕了半个地球才到。

优选IP就是找那些对国内线路”更友好”的 Cloudflare 节点。这些节点可能物理位置不在国内（Cloudflare 在大陆没有免费节点），但经过的网络路径更短、中间跳数更少、延迟更低。

效果到底有多大#

看你的运营商和地区，差别很大：

电信用户：改善通常最明显。因为电信到 Cloudflare 默认线路特别绕，优选一下可能从 300ms+ 降到 100ms 左右
联通用户：默认线路本来还行，改善幅度中等
移动用户：情况不稳定，有时候有效果有时候没有，跟具体省份有关

至于下载速度，优选IP能让 Cloudflare 托管的静态资源（图片、CSS、JS）加载更快。但对于 Workers 的计算性能，优选IP帮不上忙——它只优化你到 Cloudflare 这段路，不改变 Cloudflare 内部处理请求的速度。

网站打开更快了，下载更快了，但 Worker 跑代码的速度不变。

两种实现方式#

搞优选IP有两种路子，复杂程度不同：

方式	难度	稳定性	适合谁
CNAME 优选域名	低	较高（别人在维护）	大多数人
A 记录直连 IP	高	低（IP 会过期）	想折腾的人

CNAME 方式就是你把域名指向一个别人已经配好的优选域名（比如 vip.090227.xyz），这个域名背后对应的是维护者筛出来的高质量 Cloudflare IP。你不用自己找 IP，改一条 DNS 记录就完事了。

A 记录方式是你自己去测速、自己找 IP、自己填到 DNS 里。更灵活，但维护成本高——好 IP 今天能用不代表明天还能用。

下面两种都讲。

方式一：CNAME 优选域名（推荐大多数人）#

前提条件#

域名必须在 Cloudflare 上托管。就是你的域名的 nameserver 指向 Cloudflare，不是说域名从 Cloudflare 买的。在阿里云、腾讯云买的域名，只要把 DNS 服务器改成 Cloudflare 提供的那两个地址就行。

第一步：给 Workers 添加路由#

进入 Cloudflare Dashboard → Workers 和 Pages → 你的项目 → 设置 → 触发器 → 添加路由。

路由格式就是你的域名加通配符：

1
9ll.uk/*
2
*.9ll.uk/*

第一行匹配主域名下的所有路径，第二行匹配所有二级域名。按需填，不需要的可以不加。

注意一个坑：这个域名必须已经添加到你的 Cloudflare 账号里，就是 Dashboard 左侧”网站”列表里要有这个域名。没添加的话路由不会生效。

添加路由|80

第二步：选一个优选域名#

推荐两个网站：

微测网 CF 优选 CNAME — 更新比较勤，域名多
CF优选域名汇总 — 界面简单直接

上面列出来的域名都是别人维护的优选 CNAME，比如 vip.090227.xyz、cf.011011.xyz 之类的。

怎么选？两种方法：

简单粗暴法： 直接挑一个 ping 一下，延迟低的就用。

Terminal window

1
ping vip.090227.xyz

认真测试法： 多 ping 几个，记下延迟，挑最低的两三个。不同运营商的结果可能不一样，有条件的话找个跟你同运营商的朋友帮忙测。

第三步：添加 DNS 解析#

回到 Cloudflare → 你的域名 → DNS → 记录。

添加一条 CNAME 记录：

类型：CNAME
名称：@（代表主域名）或你想要的二级域名比如 www
目标：你选的优选域名，比如 vip.090227.xyz
代理状态：关掉，显示灰色云朵

cname|67

代理一定要关掉，这是最多人踩的坑。Cloudflare 的代理（橙色云朵）会把你的流量走 Cloudflare 全球网络，等于绕回了默认路由，优选IP就白做了。关掉代理后，DNS 解析会直接返回优选域名对应的 IP，你的流量走的是那条优化过的路径。

第四步：验证#

打开终端：

Terminal window

1
ping 你的域名

看返回的 IP 是不是跟优选域名的一样。再用 curl 检查一下：

Terminal window

1
curl -I https://你的域名

响应头里有 server: cloudflare 和 cf-ray 字段，说明流量确实走了 Cloudflare。

也可以用 Ping.pe 这类工具从多个地区测速，对比优化前后的延迟。

方式二：A 记录直连优选IP#

这种方式更折腾，但好处是你可以完全自己控制，不依赖别人维护的域名。

第一步：找到好用的 Cloudflare IP#

去微测网的 CloudFlare优选IPV4地址，上面有测速过的一批 IP 列表。

或者自己动手：从 Cloudflare 的 IP 段（公开的，官网有列表）里挑一些，批量 ping 测速。这活挺枯燥的，但真想搞就耐心点。

测速的时候注意几点：

从你实际使用的网络测，别用 VPN 测，那测出来的不准
多测几次，网络质量有波动，偶尔一次延迟低不代表稳定
分时段测，晚高峰和凌晨的延迟差别很大

第二步：添加 A 记录#

DNS 设置里添加 A 记录：

类型：A
名称：@ 或你的二级域名
IPv4 地址：你测出来的优选 IP
代理状态：关掉

同样代理要关掉。

想更稳妥的话，多加几条 A 记录，填不同的优选 IP。DNS 会自动轮询返回，相当于做了个简单的负载均衡。一个 IP 挂了，其他的还能顶上。

不过要注意：CNAME 和 A 记录不能同时存在。同一个域名下如果有 CNAME，就不能再加 A 记录，反过来也一样。想用 A 记录就得先把 CNAME 删了。

第三步：验证#

跟 CNAME 方式一样，ping 看 IP，curl 看响应头。

为什么不推荐大多数人用这个#

A 记录方式有两个硬伤：

IP 会过期。Cloudflare 的 IP 归属和路由策略经常调整，今天 30ms 的好 IP，过两个月可能变成 200ms。你得定期重新测速、更新记录。
工作量大。手动测速、挑选、填记录、定期维护，对个人博客来说性价比不高。

CNAME 方式的域名背后，维护者会不定期更新 IP 列表，你不用操心这些。

怎么判断优选IP有没有效果#

优化完了得验证，不然白折腾。

ping 对比#

优化前后分别 ping 你的域名，记录延迟。简单但直观：

Terminal window

1
# 优化前
2
ping 9ll.uk
3

4
# 优化后（DNS 传播完）
5
ping 9ll.uk

多地区测试#

用 Ping.pe 或 ITDog 从全国多个节点测试。你自己的网络测出来好了不代表所有用户都好了，看个全局。

实际体验#

浏览器清缓存（Ctrl+Shift+Delete），打开你的网站，感受加载速度。图片多的页面效果对比更明显。

curl 看细节#

Terminal window

1
curl -o /dev/null -s -w "DNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nTLS握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总时间: %{time_total}s\n" https://你的域名

这个命令会输出连接各阶段的耗时，比单纯 ping 更精确。重点看 DNS解析、TCP连接 和 首字节 这三项。

常见问题和踩坑记录#

代理没关#

最常见的坑，没有之一。加了 CNAME 但 Cloudflare 那边代理还是橙色的，等于白加。一定要确认是灰色云朵。

DNS 缓存#

改完 DNS 记录后，不是立刻生效的。本地电脑、浏览器、路由器都可能缓存了旧的 DNS 结果。

清除本地缓存：

Terminal window

1
# Windows
2
ipconfig /flushdns
3

4
# macOS
5
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
6

7
# Linux（看用的什么 DNS 服务）
8
sudo systemd-resolve --flush-caches

浏览器的话直接清缓存或者开无痕窗口试。

一般 DNS 传播要几分钟到几小时不等，Cloudflare 自己的 DNS 生效最快（因为就是他们家的），其他 DNS 服务商的传播慢一些。

Workers 路由没生效#

添加路由后发现请求没走 Workers，检查：

路由格式对不对（域名/* 不是 域名/）
域名是不是已经在 Cloudflare 账号里添加了
Workers 项目有没有部署成功
路由规则里域名跟 DNS 记录里的要一致

优选域名挂了#

第三方维护的优选域名可能随时停更或失效。如果突然访问不了了，先确认优选域名本身还能 ping 通。ping 不通就换一个域名。

CNAME 和 A 记录冲突#

同一个域名下不能同时有 CNAME 和 A 记录。报错提示重复的时候，检查是不是之前加了 CNAME 没删。

运营商差异#

同一个优选IP，电信测出来 80ms，移动测出来 300ms，很正常。不同运营商走的线路完全不同，没有一个 IP 能对所有运营商都好。如果你的用户覆盖三大运营商，可以考虑针对不同运营商用不同的优选IP（需要多个子域名分别解析）。

进阶玩法#

优选IP + Cloudflare Pages#

Cloudflare Pages 也能用优选IP。原理跟 Workers 一样——Pages 本质上也是跑在 Cloudflare 边缘网络上的，给 Pages 绑定自定义域名后，同样可以 CNAME 指向优选域名。

跟 Vercel 对比#

Vercel 的 Edge Network 在国内也经常绕路，特别是免费计划。很多人选 Cloudflare Workers + 优选IP 而不是 Vercel，就是图个能优化链路。Vercel 你没法选节点，Cloudflare 至少还有这条路。

自己维护优选IP列表#

如果你特别在意效果，可以写个脚本定期从 Cloudflare IP 段里测速，自动更新 DNS 记录。Cloudflare API 支持程序化操作 DNS 记录，配合 cron 跑就行。这个比较折腾，但适合有自动化需求的场景。

结语#

优选IP这事说白了就是在 Cloudflare 的路由上找捷径。CNAME 方式最省事，加一条 DNS 记录，几分钟就搞定了。A 记录方式更灵活但维护成本高，看你需不需要。

效果因人而异——电信用户大概率有明显改善，联通一般般，移动看运气。试一下又不亏，不喜欢改回来就是了。

最后说一句实话：这种方式本质上是蹭别人优选好的 IP。真想从头搞，得自己去测 IP、维护列表、定期更新。大多数人没必要折腾到那一步。

本地部署Qwen3.5完全指南：从下载到跑起来

Sat, 28 Mar 2026 00:00:00 GMT

为什么要折腾本地大模型？原因其实就几个字：隐私、免费、离线能用。

把数据发给第三方 API，总归要担心泄露。本地跑的话，所有对话都留在你自己的硬盘上，谁也看不到。而且不花钱——没有 API 调用费，没有 token 计价，想怎么问就怎么问。断网也能用，出差坐高铁的时候特别香。

Qwen3.5 是通义千问团队出的开源模型，从 0.6B 到 72B 一堆尺寸可选。小的跑在集显笔记本上，大的需要专业显卡。这篇主要讲怎么在自己电脑上把 Qwen3.5 跑起来，从下载工具、选模型、到调设置，每一步都写明白。

一、你的电脑带得动吗？先看看硬件#

跑本地模型最吃两样东西：显存（VRAM）和内存（RAM）。

模型能塞进显存就全塞进去，速度最快。塞不完的会溢出到内存，速度砍一大截但还能跑。内存也不够？那直接卡死或者根本加载不了。

给你一个大概的参考：

显存大小	能跑的模型	能跑的量化精度	体验
6GB（比如 GTX 1660、RTX 3060 6G）	Qwen3.5-4B	Q4_K_M 或更低	能用，回复速度还行，复杂推理差点意思
8GB（RTX 3060 8G、RTX 4060）	Qwen3.5-4B 全精度或 8B 量化版	4B 跑 Q8，8B 跑 Q4	4B 很流畅，8B 也跑得动
12GB（RTX 3060 12G、RTX 4070）	Qwen3.5-8B 甚至 14B 的量化版	8B 跑 Q8，14B 跑 Q4	甜点配置，8B 毫无压力
16GB+（RTX 4080、4090、A4000）	Qwen3.5-14B 或更大	高精度随便选	爽就完事了
24GB（RTX 4090、A5000）	Qwen3.5-30B 量化版	Q4 到 Q8	大模型也能本地跑

没有独显怎么办？ 也能跑。纯 CPU 推理会慢很多，但 Qwen3.5-4B 用 Q4 量化在 16GB 内存的笔记本上是可以动的。就是等回复的时候得有点耐心，一秒蹦两三个字的节奏。

内存方面，建议至少 16GB。模型文件本身就要占内存，加上推理时的临时开销，8GB 基本没戏。

二、下载 LM Studio#

LM Studio 是一个本地大模型的图形化运行工具，支持 Windows、Mac、Linux。不用折腾命令行，不用配 Python 环境，下载就能用。对新手来说是最省心的选择。

到官网 lm-studio.me 下载对应系统的安装包，装好就行。

装完第一次打开，界面是英文的，不过用起来很简单。后面的操作基本就是一个流程：下载模型 → 加载模型 → 开聊。

三、下载模型#

去哪下？#

两个地方：

魔搭社区（国内直连，速度快）
Hugging Face（要魔法，但模型最全）

两个站的模型是一样的，哪个方便用哪个。

选什么格式？#

LM Studio 只认 GGUF 格式的模型。去下载站搜 Qwen3.5 的时候，认准文件名里带 .gguf 后缀的。

推荐看看 Unsloth AI 团队发的版本。他们搞了一种叫 UD（Unsloth Dynamic） 的高级量化，比普通量化聪明——不是所有层都压成同一个精度，而是关键层保留高精度，不那么重要的层压狠一点。同样的文件大小，UD 版本比普通版本聪明一丢丢。

量化精度怎么选？#

这是新手最迷糊的地方。简单说：精度越高越聪明，但文件越大、越吃显存。精度越低越省资源，但模型会变”笨”。

常见的量化格式从高到低排：

量化格式	位数	大概多大（4B 模型）	质量	适合谁
FP16	16-bit	~8GB	原版质量	显存充足的土豪
Q8_0	8-bit	~4.5GB	接近原版	日常用已经很好了
Q6_K	6-bit	~3.5GB	略有下降	显存紧一点的折中方案
Q4_K_M	4-bit（中档）	~2.8GB	能用	显存紧张的首选
Q4_K_S	4-bit（低档）	~2.5GB	勉强能用	实在没显存才考虑
Q3 以下	3-bit	更小	明显变傻	别折腾了

我个人的建议：日常使用选 Q4_K_M，性价比最高。显存富裕的话上 Q8。低于 Q4 就别折腾了，模型明显变傻，回答质量下降得厉害。

Unsloth 的 UD 版本和普通版有什么区别？#

用表格说清楚：

特性	Qwen3.5-4B-Q8_0.gguf	Qwen3.5-4B-UD-Q8_K_XL.gguf
量化类型	标准量化	高级混合量化（UD + K-quants）
精度策略	所有权重统一压成 8-bit	关键层高精度（16-bit），普通层 8-bit
文件后缀含义	Q8_0：传统 8-bit 量化	UD：Unsloth Dynamic 动态混合精度；XL：Extra Large 高精度；K：K-quant 分组量化策略
推理速度	较快（计算逻辑统一，硬件友好）	稍慢（高精度层计算量大一点）
智能程度	高（接近原版 FP16）	极高（理论上比 Q8_0 更接近原版）
适用场景	日常对话、代码编写、追求速度	复杂推理、高精度任务、不差那点显存

简单说，UD 版本就是”花了更多的显存换更高的智能”。如果你显存够用，优先选 UD 版。

视觉模型的 mmproj 文件#

Qwen3.5 有些版本支持看图（视觉能力）。但光下模型文件还不够，还得下一个叫 mmproj 的文件，和模型放在同一个文件夹里才行。

mmproj 也有精度区分，推荐下 F32 的。F16 和 F32 的视觉效果差距肉眼可见，F32 识别准确率明显高一些。

Qwen3.5模型列表

四、在 LM Studio 里配置模型路径#

打开 LM Studio，第一件事是告诉它你把模型存在哪了。

点左边栏的文件夹图标（或者 Settings 里的 Models Directory），改成你存放 gguf 文件的路径。比如：

D:\AI\models\qwen3.5\Qwen3.5-9B-UD-Q4_K_XL

有个坑要注意：LM Studio 读取模型的时候，路径得有两级以上的文件夹嵌套。你直接把 gguf 文件丢在 D:\AI\models\ 根目录下，它可能识别不到。建个子文件夹把模型放进去就好了。

修改LM读取大模型的路径

配好路径后，左边栏应该能看到你的模型列出来了。

五、加载模型和 GPU 设置#

找到模型后，点右边的加载按钮。加载之前可以调参数，最重要的一项是 GPU Offload（GPU 卸载）。

GPU Offload 是什么？#

大模型的运行靠”层”（layers）。GPU Offload 就是控制有多少层跑在显卡上，多少层跑在 CPU 和内存上。

全部卸载到 GPU = 全层跑显卡，速度最快，但得有足够显存
卸载一部分 = 显存装不下的层退回 CPU，速度变慢但能跑
不卸载 = 纯 CPU 推理，最慢

设多少合适？#

原则：显存能装下多少层，就卸载多少层。 不确定的话，先把 GPU Offload 拉满，如果加载时报错或者显存爆了，再往回调。

LM Studio 界面右上角会显示预计占用多少显存/内存，看着那个数字来调就行。目标是模型全部装进显存，如果装不下，就尽量多塞几层到 GPU。

举几个例子帮你理解：

你的情况	GPU Offload 建议	说明
12GB 显存跑 4B Q8（需要约 5GB）	全部拉满	绰绰有余，全塞 GPU
8GB 显存跑 8B Q4（需要约 5.5GB）	全部或接近全部	能塞下，注意别开太多后台程序
6GB 显存跑 4B Q8（需要约 5GB）	大部分卸载到 GPU	留一点空间给系统，卸载个 25-28 层左右
纯集显 / 无独显	0 或 1	只能走 CPU 推理，慢但能用

模型设置

加载成功后，就可以在聊天界面直接跟模型对话了。

六、推荐的模型尺寸#

Qwen3.5 有很多尺寸：0.6B、1.7B、4B、8B、14B、30B、72B。不是越大越好，适合你硬件的才是最好的。

怎么选？#

6GB 以下显存：老实选 4B。别贪心上 8B，跑不动硬跑体验极差。
8-12GB 显存：4B 全精度或者 8B 量化版，看你对质量的要求。
12-16GB 显存：8B 全精度首选，14B 量化版也行。
24GB 以上：14B 全精度甚至 30B 量化版都可以试。
笔记本没独显：4B Q4 量化，纯 CPU 慢慢跑。

说实话，4B 模型日常聊天、写代码辅助已经够用了。没必要一味追求大模型——跑不动的大模型还不如跑得飞快的小模型好用。

七、加载之后先试试#

模型加载成功后，别急着干正事。先丢几个问题试试水：

闲聊试试：随便问个问题，看看回复速度能不能接受，输出是否正常。
中文能力：让模型用中文写一段东西，看看中文输出质量。
代码能力：让它写个简单的函数，看看逻辑对不对。
推理能力：给个需要多步推理的问题，比如”一个房间里有3个杀手，你杀了一个，还剩几个？”。

如果回复速度慢到一秒蹦一两个字，那说明你的显存没装下模型，大量计算跑在 CPU 上了。回去调 GPU Offload，或者换个更小的量化版本。

如果回复乱码或者答非所问，大概率是模型文件损坏了，重新下载试试。

八、常见问题#

Q：加载模型的时候报错，提示内存不够？ 要么你的模型太大了，换个小点的量化版本。要么你电脑后台开着太多东西，关掉一些再试。

Q：模型回复特别慢，一秒才蹦几个字？ 检查 GPU Offload 是不是没设对，模型大概率跑在 CPU 上了。把更多层卸载到 GPU。

Q：模型下载下来了但 LM Studio 里看不到？ 检查路径对不对，确保有两级以上的文件夹嵌套。gguf 文件名别乱改。

Q：Q4 和 Q8 到底差多少？ 日常聊天差别不大。写代码、做数学题、复杂逻辑推理的时候，Q8 明显更靠谱。显存够就上 Q8，不够就 Q4_K_M。

Q：能同时跑两个模型吗？ 理论上可以，但需要双倍显存/内存。一般没这个必要，除非你在做对比测试。

Q：CPU 推理是不是完全不能用？ 也不是。Qwen3.5-4B Q4 在 16GB 内存的电脑上，纯 CPU 大概一秒能出 2-5 个 token，聊天勉强能用，写长文就别指望了。

九、跑起来再说#

本地部署大模型这事，说难不难，说简单也得折腾一下。LM Studio 已经把门槛拉到很低了——不用写代码，不用配环境，图形界面点几下就能跑。

真正折腾的地方在于选模型和调设置。模型太大跑不动，太小不够聪明；量化太高压缩太多，太低又吃不消显存。多试几次，找到自己硬件的甜点就好了。

Qwen3.5 整体质量不错，4B 在同级别里算是能打的。日常用用完全没问题，写代码辅助、翻译、问答都挺好。真要搞复杂任务，上 8B 或者 14B。

别纠结了，先跑起来。有问题再调，比对着参数表发呆强。