工具 on 撷时录

Typora 自定义 github-cus 主题：掘金行内代码与标题自动编号

Sun, 04 Oct 2026 00:00:00 +0800

Typora 自带主题升级会覆盖，直接改 github.css 不稳妥。做法是复制一份自定义主题 github-cus，在上面改行内代码颜色，以及正文 / 大纲的标题自动编号。

本文环境：Linux，主题目录 ~/.config/Typora/themes/（Windows 一般在 %APPDATA%\Typora\themes\，macOS 在 ~/Library/Application Support/abnerworks.Typora/themes/）。

为什么要复制一份主题

主题目录里的 Readme.md 写得很清楚：内置 CSS 更新或重装后会被替换，不要直接改内置主题。

正确姿势见官方文档：

目标文件结构：

1~/.config/Typora/themes/
2├── github.css              ← 内置，不动
3├── github/                 ← 内置字体，不动
4├── github-cus.css          ← 自定义主题入口
5└── github-cus/             ← 字体资源（从 github/ 复制）

~/.config/Typora/themes/
├── github.css              ← 内置，不动
├── github/                 ← 内置字体，不动
├── github-cus.css          ← 自定义主题入口
└── github-cus/             ← 字体资源（从 github/ 复制）

Typora 主题名取自 CSS 文件名：github-cus.css → 主题选择器里一般显示为 Github Cus。

Claude、Codex 全自动模式

Thu, 01 Oct 2026 00:00:00 +0800

“YOLO 模式”（或叫"全自动模式"）是为了让 AI 编程助手在不经你逐次确认的情况下，全自动执行指令。Codex 和 Claude Code 都有各自的开启方式，但核心逻辑和风险是一样的。

YOLO 模式主要通过两种方式开启：命令行参数和配置文件。

开启 YOLO 模式意味着将 AI 的操作权限完全放开，这虽然能极大提升效率，但也存在不小的风险。

速览

工具	对应的 YOLO 标志	说明
Codex CLI (OpenAI)	`--yolo` 或 `--dangerously-bypass-approvals-and-sandbox`	后者是其完整标志，`--yolo` 是别名。
Claude Code (Anthropic)	`--dangerously-skip-permissions`	Claude Code 使用的官方标志。

如何开启 YOLO 模式

命令行启动

对于 Codex：在启动命令后直接加上 --yolo 或完整标志。

1codex --yolo "需求描述"
2# 或者
3codex --dangerously-bypass-approvals-and-sandbox "需求描述"

codex --yolo "需求描述"
# 或者
codex --dangerously-bypass-approvals-and-sandbox "需求描述"

对于 Claude Code：启动时加上 --dangerously-skip-permissions。

1claude --dangerously-skip-permissions "需求描述"

claude --dangerously-skip-permissions "需求描述"

Cursor WSL 连接失败？手动安装 cursor-server 的完整方案

Thu, 01 Oct 2026 00:00:00 +0800

先说问题

在 Windows 上用 Cursor 打开 WSL 项目时，左下角一直转圈，等待比较久……好像也没有安装好，检查 ~/.cursor-server/bin/ 目录，发现 commit id 的目录是空的，说明自动下载失败了。这在国内网络环境下应该常见，因为服务器文件有 125MB，可能下载中途断掉了。

为什么会有这个问题

Cursor 连接 WSL（或远程 SSH）时，需要在 WSL 内安装一个服务端组件 cursor-server，它本质上是 VSCode Remote 的定制版。自动下载流程大致是：

Cursor Windows 端发起 WSL 连接
WSL 端根据 commit ID 下载对应的 vscode-reh-linux-x64.tar.gz
解压到 ~/.cursor-server/bin/<commit-id>/
启动 server，建立通信

第二步在国内网络环境下经常超时或中断，下载失败后 bin/<commit-id>/ 目录是空的，但 .installation_lock 文件被写入了，导致 Cursor 以为"正在安装中"，不会重试。

手动安装步骤

找到当前 Cursor 版本的 commit ID

Commit ID 在 Cursor 的版本里，命令：

1cursor --version

cursor --version

输出：

Hugo相对路径图片显示问题的分析与解决

Thu, 01 Oct 2026 00:00:00 +0800

先说问题

写博客的时候用 Obsidian 插了张图：

1![img](assets/example.jpg)

![img](assets/example.jpg)

编辑器里看着好好的，一跑 hugo 部署上去，图裂了。打开浏览器开发者工具一看，图片请求的路径根本就不对。

检查了一圈，发现这个问题只出现在 非 bundle 的 md 文件 上，用目录包起来的 index.md 反倒没事。

为什么会有这个问题

Hugo 的两种页面

Hugo 里写文章有两种姿势：

Page Bundle — 建个文件夹，里面放 index.md，图片丢同目录下

content/posts/my-post/
├── index.md
└── some-image.jpg

content/posts/my-post/
├── index.md
└── some-image.jpg

Leaf Page — 直接一个 .md 文件

content/posts/my-post.md

content/posts/my-post.md

我这边的目录结构是这样的：

content/posts/
├── _index.md
├── assets/
│   └── example.jpg
├── my-post.md              ← 出问题的
└── my-bundle-post/
    └── index.md            ← 没问题的

content/posts/
├── _index.md
├── assets/
│   └── example.jpg
├── my-post.md              ← 出问题的
└── my-bundle-post/
    └── index.md            ← 没问题的

Blowfish 主题自带的图片渲染逻辑，会先用 $.Page.Resources.GetMatch 去捞图片。Bundle 页面自然能捞到，但 leaf page 压根没有 page resources，捞了个空。最后 fallback 到直接把原始相对路径当 src 输出——这就是问题的起点。

VMware Workstation Pro 26H1 安装

Thu, 01 Oct 2026 00:00:00 +0800

本文按 2026-06-19 时点可获取的 26H1 免费版 流程整理，主要记录 Windows 宿主机上的下载和安装步骤。

下载 VMware Workstation Pro 26H1

Broadcom 注册地址：https://profile.broadcom.com/web/registration Broadcom 登录地址：https://access.broadcom.com/default/ui/v1/signin/

下载入口：

1https://support.broadcom.com/group/ecx/productdownloads?subfamily=VMware%20Workstation%20Pro&freeDownloads=true

https://support.broadcom.com/group/ecx/productdownloads?subfamily=VMware%20Workstation%20Pro&freeDownloads=true

选择对应版本

I agree to the Terms and Conditions

I agree to the Terms and Conditions

这个按钮可能有时候点击不了，多试几次

可能需要填写一些信息：

开始安装

双远程工作流

Thu, 01 Oct 2026 00:00:00 +0800

场景

最近团队基于 Snowy 这个开源项目做二次开发，在它上面加了很多自己的业务功能。但 Snowy 也在持续更新——修 Bug、加新特性、升级依赖版本。

问题来了：自己的代码和上游代码混在一起，怎么才能既自由修改，又能定期拉取上游的最新更新？

这就是我写这篇文章要分享的。

思路

我的核心思路是双远程 + 上游镜像分支：

origin → 团队自己的远程仓库（日常开发用）
upstream → 开源项目的远程仓库（只读，仅用来拉取更新）
upstream-master 分支 → 上游代码的纯净镜像，绝不直接提交
main 分支 → 团队开发主分支，包含所有自定义代码

gitGraph commit id: "A" commit id: "B" branch upstream-master checkout upstream-master commit id: "C" commit id: "D" checkout main commit id: "E: 上游v3.6.5" branch feature/xxx checkout feature/xxx commit id: "F" checkout main merge feature/xxx

初始化仓库

进入项目目录

1cd /your/project

cd /your/project

初始化 Git

1git init

git init

配置两个远程仓库（以codeup和gitee为例）

1git remote add origin git@codeup.aliyun.com:your-team/your-project.git
2git remote add upstream git@gitee.com:xiaonuobase/snowy.git

git remote add origin git@codeup.aliyun.com:your-team/your-project.git
git remote add upstream git@gitee.com:xiaonuobase/snowy.git

origin 是团队日常用的仓库，upstream 是 Snowy 的仓库（只拉取，不推送）。

同时配置 Gitee 与 GitHub

Thu, 01 Oct 2026 00:00:00 +0800

开发机上经常要同时推 Gitee、GitHub，有时还要接阿里云 Codeup。默认只会用 ~/.ssh/id_rsa，多平台共用一把钥匙容易乱；更稳妥的做法是：每平台一把密钥，用 ~/.ssh/config 按 Host 分流。

全局 Git 身份

提交作者信息与 SSH 无关，但新环境一般先配好：

1git config --global user.name "jiangbyte"
2git config --global user.email "your@email.com"
3git config --global --list

git config --global user.name "jiangbyte"
git config --global user.email "your@email.com"
git config --global --list

确认输出里有 user.name / user.email。若某仓库要用不同邮箱，再在该仓库里用 git config user.email（不加 --global）覆盖即可。

为各平台分别生成 SSH 密钥

目录权限先保证：

1mkdir -p ~/.ssh
2chmod 700 ~/.ssh

mkdir -p ~/.ssh
chmod 700 ~/.ssh

分别生成三把密钥（文件名自定义，别互相覆盖）：

用 conda 固定默认环境 normal

Thu, 01 Oct 2026 00:00:00 +0800

先说目标

机器上同时有三套 Python 很容易搅在一起：

系统自带的 /usr/bin/python3
conda 的 base
自己建的业务 / 学习环境

想要的结果很简单：不管终端还是 Cursor，一律只用名为 normal 的 conda 环境，不要再落到 base 或系统 Python 上。

下面以 miniforge（路径 /home/charlie/miniforge3）为例，过程对 Anaconda / Miniconda 同样适用，改一下前缀即可。

创建 `normal` 环境

选用相对稳妥的 3.12：

1conda create -n normal python=3.12 -y

conda create -n normal python=3.12 -y

创建完成后确认：

1conda env list
2# base                     /home/charlie/miniforge3
3# normal                   /home/charlie/miniforge3/envs/normal

conda env list
# base                     /home/charlie/miniforge3
# normal                   /home/charlie/miniforge3/envs/normal

解释器路径固定为：

工具 on 撷时录

Typora 自定义 github-cus 主题：掘金行内代码与标题自动编号

为什么要复制一份主题

Claude、Codex 全自动模式

速览

如何开启 YOLO 模式

命令行启动

Cursor WSL 连接失败？手动安装 cursor-server 的完整方案

先说问题

为什么会有这个问题

手动安装步骤

找到当前 Cursor 版本的 commit ID

Hugo相对路径图片显示问题的分析与解决

先说问题

为什么会有这个问题

Hugo 的两种页面

VMware Workstation Pro 26H1 安装

下载 VMware Workstation Pro 26H1

选择对应版本

开始安装

双远程工作流

场景

思路

初始化仓库

进入项目目录

初始化 Git

配置两个远程仓库（以codeup和gitee为例）

同时配置 Gitee 与 GitHub

全局 Git 身份

为各平台分别生成 SSH 密钥

用 conda 固定默认环境 normal

先说目标

创建 normal 环境

创建 `normal` 环境