最近拉 GitHub 上的 release 和 raw 文件，速度又回到了熟悉的几 KB/s。第三方聚合加速站（比如 github.akams.cn 那种测速导航）确实方便，但用别人的节点总有点不踏实：下载 URL 全程经过陌生人的 Worker，人家理论上能记录你访问了什么仓库、甚至改写内容，防不胜防。而且节点质量参差不齐，三天两头失联。 既然自己有 Cloudflare，干脆自建一个。 原理其实很简单 这类加速站的内核基本都是 hunshcn/gh-proxy 这个项目，逻辑一句话能讲完：把请求里的 GitHub 域名重写成代理域名，Worker 收到请求后转发给 GitHub，再把响应（顺便处理 302 跳转、CORS 头）流式吐回来。release 资产、raw 文件、archive 压缩包、git clone（smart http），理论上都走这一条链路。 ...
上一篇写了搭建博客的三个坑，本以为搞定了。结果发完文章一看——主页 404，点任何链接也 404。 更离谱的是：GitHub Actions 全绿，Pages 设置显示 “Your site is live”，但 curl 回来永远是 404 Not Found。 这篇文章记录后续排查中踩的更多坑。 坑 4：缺少 .nojekyll GitHub Pages 默认会用 Jekyll 处理静态文件。Hugo 生成的 assets/ 目录下有带 hash 的文件名，Jekyll 可能会忽略或错误处理这些文件。 ...
周末想搭个个人博客，选型 Hugo + PaperMod + GitHub Pages。看起来简单的三板斧，实际踩了几个坑，记录一下。 坑 1：PaperMod v8 的 TOML 配置变了 hugo new site 生成的是空模板，照着网上的 PaperMod 配置教程贴进去，hugo 直接报错： ...
Hermes Agent 飞书 Bot 部署经验总结 记录在 Ubuntu 24.04 虚拟机上从零部署 Hermes Agent（NousResearch/hermes-agent）， 接入智谱 bigmodel 作为 LLM 后端，并打通飞书 WebSocket 双向消息的完整流程与踩坑点。 时间：2026-07-05 0. 准备清单 项目 说明 宿主机 Windows 11 + PowerShell 5.1 虚拟机 Ubuntu 24.04.3 LTS，VMWare Workstation，1 个 NAT 网络 VM IP 192.168.111.0/24 网段（按需替换） VM 用户 普通用户 vmuser（sudo 组）+ root（密码登录 + SSH key） 工具链 paramiko（Windows 端 SSH）、lark-oapi（飞书 SDK，hermes 依赖）、Python 3.12 飞书账号 已创建企业自建应用，开启了机器人能力，获得 App ID / App Secret LLM 凭据 智谱 bigmodel GLM_API_KEY（实名认证后免费档可用） 1. 虚拟机初始化 1.1 SSH key + root 登录 # 宿主机生成 ed25519 key ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 通过 paramiko 远程执行（避免在 VM 控制台操作）： ...
如何让 AI 找出偷偷藏在系统中偷吃内存的"元凶" 当你打开任务管理器，发现"使用中"内存比所有进程加起来多出好几个 GB，却找不到去哪了——这篇文章就是写给你的。更关键的是：这种枯燥到让人抓狂的"挨个查每个进程是干什么的"活儿，正好是 AI 的强项。 背景：一个让人抓狂的痛点 排查 Windows 内存占用时，几乎所有人都会遇到这个场景： 任务管理器显示"使用中 13 GB"，但把所有进程的内存加起来，只有 9 GB 左右。差了将近 4 GB，去哪了？ 更让人崩溃的是： ...