2025-06-23 13:00:00
我个人一直都是使用本地的 SSH Config 来管理我的 SSH 连接，虽然这个方案有自身的优点，就是安全，易配置，我所有的连接都只允许使用 SSH Key 访问，关闭了用户名密码，另外所有的配置都通过 assh 一键配置，我给所有的节点都配置了昵称，所以我只需要输入 ssh alias 就可以连接到任何我想连接的机器。
但这个方案有一个缺点，就是我必须在我经常使用的机器旁，我才能访问我的服务器，一旦我离开了我的电脑，那么任何设备我都无法连接上。但是前段时间我发现了一款基于浏览器的远程连接管理工具 Next Terminal。在我看来 Next Terminal 更像是一个堡垒机，可以在一个中心化的节点上来管理 SSH，Telnet 等等连接，还提供了安全审计等功能。
Next Terminal 是一款使用 Golang 和 React 开发的 HTML5 远程桌面网关，具有小巧、易安装、易使用、资源占用小的特点，支持多种远程协议如 RDP、SSH、VNC 和 Telnet 的连接和管理。作为一个开源的交互审计系统，它为用户提供了一种高效且安全的方式来管理远程连接，特别强调了易用性和安全性。Next Terminal 虽然定位轻量堡垒机，但是支持RDP、SSH、VNC、Telnet、Kubernetes协议超多协议。
Next Terminal 拥有众多实用功能，使其成为运维和安全团队的理想选择：
目前 Next Terminal 已经开始进行商业化的尝试，可以在官网 购置专业版以及商业版的授权。
参考官方文档
version: '3.3'
services:
guacd:
image: dushixiang/guacd:latest
volumes:
- ./data:/usr/local/next-terminal/data
restart: always
next-terminal:
image: dushixiang/next-terminal:latest
environment:
DB: sqlite
GUACD_HOSTNAME: guacd
GUACD_PORT: 4822
ports:
- "8088:8088"
volumes:
- /etc/localtime:/etc/localtime
- ./data:/usr/local/next-terminal/data
restart: always
Next Terminal 提供了便捷的远程访问能力，但是服务器的安全性依然是首要考虑的因素。建议安装之后立即修改复杂的管理员密码，并开启双因素认证。
尽量避免将 Next Terminal 直接暴露到公网环境，合理配置授权策略，遵循最小权限原则。
Next Terminal 相较于其他的开源堡垒机项目，更轻量，简单，被管理资产透明，适合个人和小型团队使用。JumpServer 功能全面，但是非常笨重，适合大型企业。Teleport 安全性相对较好，但是需要在被管理资产上进行额外的操作，适合对安全性要求较高的场景。
2025-06-20 13:00:00
在我之前的视频里面当时介绍了三款不同的本地 AI 客户端，[[Cherry Studio]]，[[Chatbox]]，ChatWise，每个客户端都有自身的优缺点，前两款也还是开源的，但是今天要介绍的 ChatWise 是一款更轻量的，更强大的 AI 客户端，包括一些个人觉得非常好用的功能，比如本地联网搜索，MCP 支持，Artifacts 等等使用起来都非常方便。
我最早是因为本地使用 DeepSeek 才想要下载用一个本地的客户端，因为平时基本上都使用在线网页版本 [[Perplexity]]，ChatGPT，Claude 等，但是知道了 ChatWise 之后发现原来本地的客户端使用体验也可以非常不错。
ChatWise 支持几乎所有主流的大模型模型，包括
ChatWise 支持多种形式的输入输出，除了最普通的文本，还支持
在聊天界面只要点击地球图标就可以启用搜索。
在设置中，也有单独的 Web Search 的选项。默认情况下使用本地的 Google 搜索。
在设置中还可以使用 Tavily 搜索 API，让用户获取实时的搜索结果。
支持 HTML，React，图表，文档等内容。还支持 mermaid 流程图。
如果对话过程中有代码相关的内容，可以启用 Artifacts 那么在右侧就可以看到预览的效果。
ChatWise 支持 [[Model Context Protocol]] MCP 协议，MCP 是 Anthropic 推出的一个让模型访问外部资源的协议。开发者可以根据 MCP 规范实现一些服务，让 AI 可以通过协议获取额外的资源和上下文，比如 ChatWise 可以连接到 Notion，Google Sheets 等等外部工具，在和 AI 聊天的过程中可以调用这些 MCP 来实现更好的回答。
模型可以通过两种方式访问 MCP
在 ChatWise 的 Tools（工具） 中可以使用加号添加 MCP 服务。
官方的 MCP 仓库
2025-06-19 13:00:00
在我的待办事项和视频评论下方很多人提到过 Alist，虽然我自己也有搭建一个 Alist，但实际上并没没有真正使用起来，所以待办事项中的「编写一篇文章介绍一下 Alist」 也就一直延误了，我个人似乎并没有太多 Alist 使用的强需求，虽然 Alist 可以用来挂在很多的网盘，但是如果看过我之前的文章，我现在越来越多的避免将大量的数据存储到云端，也不再大量的使用网盘，所以很多人用 Alist 来挂在网盘并接入 VidHub，Plex，Emby 等来观看高清视频的需求其实我本地一台 Ubuntu(NAS) USB 挂在一块大硬盘，局域网 SMB 共享给 Apple TV 就已经解决我了 99% 的使用场景。
但是现在再来编写一篇文章介绍 Alist（OpenList）的原因就是想聊聊开源社区，以及开源社区商业化这件事情，怎么就演变成现在这样的口碑。
Alist 本来是一个开源的可以用来聚合多个网盘，云存储将其变成可阅览在线目录的项目。但是前段时间 Alist 项目被出售，并移交给了新团队。在新团队的维护中，添加了未经用户同意或明确告知的遥测（telemetry）代码，悄悄收集用户的使用数据。这一行为严重地削弱了这个开源项目的信任度。另外官方的一系列操作更加剧了社区分裂，官方文档中的二进制下载链接被修改，项目踢出了原来的核心贡献者，等等这一系列让人看不懂的操作加剧了这个项目走向终点的步伐。
为了应对 Alist 项目带来的「信任危机」，部分 Alist 项目的核心贡献者创建了一个名叫 OpenList 的分支。OpenList 定位是 Alist 的继承者和开源代替，目标是确保文件列表的自由和可信任。希望通过开源，透明，可审查的代码来防止用户隐私的侵入。
OpenList 和 Alist 一样支持广泛的存储提供商，包括但不限于本地存储，阿里云盘，OneDrive，百度网盘，天翼云盘，Google Drive，123pan，PikPak，FTP/SFTP，S3，WebDAV，115 网盘，夸克网盘，迅雷网盘，蓝奏云等。
相关链接
通过 Docker 快速安装
docker run -d \
--name=openlist \
-p 5244:5244 \
openlistteam/openlist:latest
如果需要使用 ffmpeg, aria2 等应用，可以在镜像标签后使用 tag :beta-aio 或者 :latest-aria2 等。具体可以参考docker hub
首次运行会输出管理员初始密码，默认监听 5244 端口。
因为我维护了一个自用的 k3s ，可以直接使用如下的配置安装
apiVersion: v1
kind: Namespace
metadata:
name: openlist
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: openlist-pvc
namespace: openlist
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: longhorn
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: openlist
namespace: openlist
spec:
replicas: 1
selector:
matchLabels:
app: openlist
template:
metadata:
labels:
app: openlist
spec:
containers:
- name: openlist
image: openlistteam/openlist:latest
ports:
- containerPort: 5244
env:
- name: PUID
value: "0"
- name: PGID
value: "0"
- name: UMASK
value: "022"
- name: TZ
value: "Asia/Shanghai"
- name: RUN_ARIA2
value: "true"
volumeMounts:
- mountPath: /opt/openlist/data
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: openlist-pvc
---
apiVersion: v1
kind: Service
metadata:
name: openlist-svc
namespace: openlist
spec:
type: ClusterIP
ports:
- port: 5244
targetPort: 5244
selector:
app: openlist
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: openlist-ingress
namespace: openlist
annotations:
traefik.ingress.kubernetes.io/router.entrypoints: websecure
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
rules:
- host: openlist.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: openlist-svc
port:
number: 5244
tls:
- hosts:
- openlist.example.com
secretName: openlist-tls
可以自行修改其中的部分内容，比如域名，配置 pvc 大小等。
安装部署成功之后运行如下的代码查看初始化密码。
kubectl logs -f -n openlist openlist-7c5fd58b97-xxx
默认的用户名是 admin，初始化密码在日志中。
2025-06-17 13:00:00
今天想给大家介绍一款特别有意思的插件叫做 SpecStory，我们现在会在 VS Code， Cursor 编辑器中使用各种类型的代码辅助工具，也会利用 Cursor 等集成的 IDE 来 vibe coding，但是如果我们每一次都重头开始描述我们想要做的事情，或者每一次都新开一个聊天窗口，AI 大模型大概率会前后表现不一致，虽然我们也可以利用 Cursor Rules 等工具来给 AI 提供一些系统级别的提示词，但是 AI 在回复的过程中也可能跑偏。
SpecStory 这款插件恰好解决了这些问题。SpecStory 的核心功能是帮助开发者在编程过程中建立和维护一个持久的、可追溯的情境描述，它会记录下所有和 AI 的聊天记录。
SpecStory 能够自动保存、组织并以结构化 Markdown 格式呈现所有 AI 聊天记录，确保每一次与 AI 的对话都成为可检索的资产。SpecStory 为 AI 提供丰富且准确的上下文信息，使得 AI 能够更好地理解你的意图，从而提供更精准的建议或生成代码。这种方式最大限度地减少了 AI 偏离主题或给出不相关建议的可能性，也避免了重复输入大量背景信息的问题。
.specstory 文件夹，将所有与 AI 的交互以 Markdown 档案形式记录。以下是如何安装和使用 SpecStory 的简单说明
确保你的编辑器兼容 SpecStory：目前 SpecStory 支持 GitHub Copilot、Cursor 编辑器。
| 编辑器 | 步骤 | 备注 |
|---|---|---|
| VS Code | 扩展市场搜寻「SpecStory」，点击安装 | 支持 GitHub Copilot 及 Cursor |
| Cursor | Cursor 编辑器内部扩展面板 (Ctrl/Cmd+Shift-X) 搜索「SpecStory」并安装 | 如从 Marketplace 网站安装，需另行在 Cursor 端安装 |
| VSIX 安装 | 下载 specstory-vscode-latest.vsix，于命令面板选择「Extensions: Install from VSIX…」 |
适用于无法从扩展市场直接安装的场景 |
打开命令面板 (Ctrl/Cmd+Shift-P)，输入 SpecStory，若能看到相关命令列表即表示安装成功。
.specstory/history/ 下的 Markdown 档案中。所有对话记录均保存在本地专案中，不会自动上传云端，并提供匿名分享选项，无需注册，即可掌控分享内容。
2025-06-17 13:00:00
很早之前就看到了 GitHub Copilot 可以在 VS Code 中提交 Git 时自动编写提交 Message，但是实际上我一直没有用起来。正好现在对 Git Message 做一个完整的学习，顺便也了解一下当前的 AI Commits 方案。
之前其实看到过一个对于 Commit message 的规范 Conventional Commits，之前的一些提交提交历史也是按照 feat, fix 等等方式来进行的，但是其实理解和书写起来也没完全按照这个模式，只借鉴了其中关于提交类型的部分。所以这次调研才看到对于内容部分更详细的说明，现在很多 AI 来产生提交历史的时候，更能看出来区别。
Git 历史记录讲述了项目文件的演进过程，包括了什么被修改了，为什么被修改，所有团队中的成员都可以有效地审查变更，通过查看 Git 变更历史可以非常容易地查明 bug 以及破坏性更改的来源。但是往往开发者在花了数小时编写代码之后，却在 Git Message 提交的时候忽略了其重要性，导致 Git 历史非常难以定位和排查。所以本文就来总结一下目前比较好用的 AI 提交 Git message 的方法。
lumen 是一个使用 Rust 编写的命令行工具，可以将 AI 结合到 git 工作流中，用来生成 Git 提交历史。
安装
brew install jnsahaj/lumen/lumen
可以利用 lumen draft 来生成提交历史，在运行这一行命令之前记得将代码 git add 到暂存区中。
默认情况下 lumen 会调用 Phind 这一个模型来生成，但是如果自己想配置 OpenAI，或者 Claude 也可以指定。
AI Commits 是一个基于命令行的工具，使用 TypeScript 编写，可以调用大语言模型帮助我们提交 Git 信息。
使用 AI Commits 需要设置 OpenAI 的 API Key。
npm install -g aicommits
aicommits config set OPENAI_KEY=XXX
aicommits
aicommits --type conventional
AI Commits 可以生成符合 Conventional Commits 规范的提交信息。
我个人使用 IntelliJ IDEA 比较多，所以在 IDEA 中也找到了一款 AI Commits 的插件。
安装之后打开设置，就可以配置调用的模型，以及系统的 Prompt。
2025-06-16 13:00:00
大概两年前我自己部署了 Uptime Kuma 来监控我的各项服务在线情况，这两年内一直工作非常稳定，除了偶尔的网络波动带来的误报，基本上没有其他大问题。
但是用了超过两年，最近访问后台加载起来越来越慢，经常需要好久才能将监控的列表加载出来。对于使用上的问题，对我的影响越来越不能忽视， 所以今天来讲一下如何优化 Uptime Kuma 的数据库。
Uptime Kuma 在 1.x 版本中需要对整个 heartbeat 表进行扫描来执行一些操作，数据库中存在大量数据时，会导致显著的性能下降。根据开发者的说明，性能限制依赖于硬件配置，超过 500 个监控或者数据库大小超过 1.5 GB 左右时会有明显的性能问题。1
于是我检查了一下我本地的 SQLite 数据库，竟然达到了 2.6 GB。
可以在 Kuma 的设置 /settings/monitor-history 中设置数据保留期限，然后手动执行清理。
因为在 v1 版本中 Kuma 使用 heartbeat 心跳表来记录检查，如果频繁的进行检查，并记录，可能导致 heartbeat 表快速膨胀，可以根据自己的情况适当地降低检查频率。
在 Uptime Kuma 的 SQLite 数据库中，历史数据主要存储在心跳相关的表中。
推荐在清理数据时，先将 Kuma 服务暂停。
推荐备份一下 kuma.db 数据库
cp kuma.db kuma-2025xxxx.db
然后使用 sqlite3 连接数据库，并执行删除语句。
DELETE FROM heartbeat WHERE time < datetime('now', '-30 days');
清理特定监控器的历史数据
-- 查看监控器ID
SELECT id, name FROM monitor;
-- 删除特定监控器的历史数据
DELETE FROM heartbeat WHERE monitor_id = [监控器ID];
数据清理之后，可以对数据库优化释放空间
VACUUM;
-- 重建索引
REINDEX;
Uptime Kuma 的维护团队正在开发 v2 版本，希望通过引入外部的 MariaDB 数据库来改善性能，等未来 v2 版本稳定之后，可以考虑升级，但是目前看官方的进度还在 beta 阶段。
