一本码簿

众里寻码千百度,那段却在github处。

初始安装

1
2
3
4
5
6
7
8
sh -c "$(wget -qO- https://haies.cn/assets/install-zsh.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/apt-install.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/debian-init.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/centos-init.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/ubuntu-init.sh)"

sh -c "$(wget -qO- https://haies.cn/assets/yum-install-docker.sh)"
sh -c "$(wget -qO- https://haies.cn/assets/dns.sh)"

压缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
7za a -mx0 -v4g backup.7z /path/to/data
7za a -mx0 -v4g backup.7z /path/to/*
7za x -mx0 "backup.7z.001" -o/path/to/

7za a -tzip backup.zip /path/to/data
7za x -tzip backup.zip /path/to/data

tar -cvpf - /path/to/folder | split -d -b 4g - backup.tar
tar -xvpf backup.tar.00 -C /path/to/target_folder #要求分卷是纯 tar 分割(未压缩),且分卷命名连续
cat backup.tar.* | tar -xpv -C /path/to/folder

tar -czvpf - /path/to/folder | split -d -b 4g - backup$(date +%Y%m%d).tar.gz
cat backup.tar.gz.* | tar -xzvp -C /path/to/folder
gzip -t backup.tar.gz

tar -cvpf nginx.tar /etc/nginx
tar -xvpf nginx.tar -C /path/to/folder

ls -l |grep ^d|awk {'print $9'}|xargs -t -i 7z a {}.7z {}

7z mx参数
7z mx参数

7z 压缩方案
7z 压缩方案

查看系统信息

1
2
3
4
5
6
id -un
uname -a
lsb_release -c
lscpu
lshw
cat /proc/meminfo

磁盘管理

查看磁盘格式:lsblk -f
查看磁盘信息:fdisk -l

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mkfs.xfs -f /dev/vdb &&
mkdir /hda &&
mount /dev/vdb /hda &&
echo "/dev/vdb /hda xfs defaults 0 0" >> /etc/fstab

mkfs.ext4 -T huge -b 4096 /dev/vdb &&
mkdir /hda &&
mount /dev/vdb /hda &&
echo "/dev/vdb /hda ext4 defaults 0 0" >> /etc/fstab

mkfs.ext3 -T largefile -i 4096 /dev/xvdb1 &&
mkdir /hda &&
mount /dev/xvdb1 /hda &&
echo "/dev/xvdb1 /hda ext3 defaults 0 0" >> /etc/fstab
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
parted /dev/sda
resizepart 2
pvresize /dev/sda
lvextend -l +100%FREE /dev/mapper/centos-home
xfs_growfs /dev/mapper/centos-home

fdisk /dev/sdb
pvcreate /dev/sdb1
vgextend ubuntu-vg /dev/sdb1
lvextend -L +9G /dev/ubuntu-vg/root

pvs
vgs
lvs

pvdisplay
vgdisplay
lvdisplay

NTFS读写

1
2
3
apt-get install ntfs-3g
mount -t ntfs-3g /dev/hdax /mnt/windows
/dev/hdax /mnt/windows ntfs-3g defaults 0 0

目录操作

迁移目录:

1
2
3
4
5
6
7
8
mkfs.xfs -f /dev/xvdb2 &&
mkdir /vartemp &&
mount /dev/xvdb2 /vartemp &&
rsync -avx /var /vartemp &&
mv /var /var.old &&
mkdir /var &&
umount -lf /dev/xvdb2 /vartemp &&
mount /dev/xvdb2 /var

目录备份还原:dumprestore
目录占用查看:fuserlsof
合并文件夹:cp -rlfv parta/* partb/* part

配置主机

~/.ssh/config中增加

1
2
3
4
5
6
Include ~/.ssh/config.d/*
Host aws
Hostname 10.2.*.*
Port 22
User ubuntu
IdentityFile ~/.ssh/aws.pem

远程执行命令

1
ssh root@59.202.*.* "cd /home/git/.ssh && cat id_rsq.pub >> authorized_keys"

挂载DVD源

1
2
3
4
5
mkdir /iso &&
mount -t iso9660 -o loop /hda/debian7.8/debian-7.8.0-amd64-DVD-1.iso /iso &&
echo deb file:///iso/ wheezy main contrib > /etc/apt/sources.list &&
sudo apt-get update &&
sudo apt-get upgrade

增加用户

1
2
3
useradd oneuser -d /var/oneuser -G wheel &&
usermod -aG root oneuser &&
passwd oneuser

其他安装

  1. 配置Python环境 (使用阿里云镜像)

    鉴于UOS自带Python版本可能较低,我们使用 pyenv 安装新版Python。

    # 安装pyenv
    git clone https://gitee.com/mirrors/pyenv.git ~/.pyenv
    echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
    echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
    echo 'eval "$(pyenv init -)"' >> ~/.zshrc
    source ~/.zshrc
    
    # 配置pyenv使用国内镜像加速Python安装
    echo 'export PYTHON_BUILD_MIRROR_URL="https://mirrors.aliyun.com/python/"' >> ~/.zshrc
    source ~/.zshrc
    
    # 通过pyenv安装Python 3.8.12 (此版本与QEMU 7.2.21兼容性好)
    pyenv install 3.8.12
    pyenv global 3.8.12
    

基于 deepin 15 / Debian 10 buster 的国产化桌面发行版全方位兼容性评估

操作系统识别

项目 详情
发行版 统信 UOS 桌面专业版 V20(UnionTech OS Desktop 20 Professional)
家族 类 Debian 桌面发行版
基础来源 基于 deepin 15.x / Debian 10 (buster) 深度定制
内核 Linux 4.19.0-amd64-desktop(Deepin 构建,gcc 8.3.0 编译)
架构 x86_64 (amd64)
版本号 UOS 20(VERSION_ID=20
编译器 GCC 8.3.0(Uos 8.3.0.13-deepin1)
C 标准库 glibc 2.28.35-deepin1
默认桌面 DDE(Deepin Desktop Environment,运行于 X11)

UOS(统信操作系统)由 deepin 团队与统信软件技术有限公司联合开发,定位党政、央企、金融、能源等”信创”市场。本版本对应 deepin 15 SP3/20 同期主线内核,主要面向国产化 PC 平台。

系统技术栈总览

核心运行时栈

1
2
3
4
5
6
7
┌─────────────────────────────────────┐
│ Linux Kernel 4.19.0-amd64-desktop │ ← LTS 分支(Deepin 移植)
├─────────────────────────────────────┤
│ glibc 2.28.35 / GCC 8.3.0 / binutils 2.31.1 ← ABI 基线
├─────────────────────────────────────┤
│ libstdc++ GLIBCXX_3.4.25 │ ← C++ ABI
└─────────────────────────────────────┘

GUI / 应用栈

1
2
3
4
5
6
7
┌────────────────────────────────────────┐
│ DDE (KWin 5.x) │ GTK 3.24.5 │ ← 默认桌面与原生应用
├────────────────────────────────────────┤
│ Qt 5.11.3 (Core/Gui/Widgets/...) │ ← deepin / WPS / 部分国产应用
├────────────────────────────────────────┤
│ GLib / GObject │ ← C 工具库
└────────────────────────────────────────┘

显示 / 图形栈

1
2
3
4
5
6
7
┌────────────────────────────────────────┐
│ X11 / Xorg 1.20.4 │ Wayland 1.21 │ ← X11 主用
├────────────────────────────────────────┤
│ libGL 1.1.0.3 (Nvidia) │ Mesa 19.2.6 │
├────────────────────────────────────────┤
│ NVIDIA Quadro P1000 4 GB (GLX 4.6) │ ← 独显
└────────────────────────────────────────┘

核心组件版本详解

核心运行时

组件 版本 说明
Kernel 4.19.0-amd64-desktop(构建 #7602,2026-06-24) Deepin 维护的内核,已带国产化补丁链(useclinux=1ima_appraise=off 等)
GCC 8.3.0(Uos 8.3.0.13-deepin1) 支持 C++17(部分)/ 不支持 C++20
glibc 2.28.35-deepin1 LTSC 段,落后 Debian 11 一个大版本
binutils 2.31.1(Uos 打包) GNU ld / as / objcopy
libstdc++ 8.3.0.13-deepin1 C++ ABI 标签 GLIBCXX_3.4.25
Python(系统默认) 3.7.3 另有 uv 安装的 3.11.15 在 ~/.local
Make (随 Debian 10) 4.2.1 量级
systemd PID 1(/sbin/init -> /lib/systemd/systemd 用户与系统服务均由 systemd 管理

GUI 工具包

工具包 版本 备注
GLib (随 deepin)
GTK 2 ❌ 未单独打包 DDE 默认不走 GTK 2
GTK 3 3.24.5.26-deepin26 当前主用;deepin 26 号补丁
GTK 4 ❌ 未安装
Qt 5 5.11.3.78-1+dde Core / Gui / Widgets / DBus / Network / Multimedia
Qt 6 ❌ 未安装
KWin 5.x(kwin_x11 / kwin_no_scale DDE 默认窗口管理器

显示与图形

组件 版本 / 状态
X11(Xorg) 1.20.4(主用,会话 DISPLAY=:0
Wayland 协议库 1.21.0.9-deepin9(client/cursor/server/egl 全套)
xcb (随 Xorg)
libGL 1.1.0.3-deepin1(Nvidia 厂商层)
Mesa 19.2.6.15-1(DRI / EGL / GLX 实现)
EGL 1.1.0.3-deepin1 + Mesa 19.2.6
Vulkan 加载层 libvulkan 1.1.97-2+sign;vulkaninfo 未装
字体 Noto CJK / Noto Core / 文泉驿微米黑 / 文泉驿正黑 / CESI / GB

硬件采样

组件 详情
CPU Hygon C86 3250 8-core(1 socket × 8 core × 2 thread = 16 逻辑 CPU),主频 1.6 ~ 2.8 GHz,海光 C86(Zen1 授权)
内存 62 GiB DDR(已用 4.1 GiB,可用 57 GiB),Swap 15 GiB
GPU NVIDIA Quadro P1000(驱动 550.120),GL 4.6,4 GiB 显存
启动 UEFI,/boot 1.5 GiB(已用 28%),/ 201 GiB(已用 7%)
数据盘 /data 7.3 TiB(已用 1.5 TiB)

关键结论

  • 编译器能力:GCC 8.3 → C++17 完整支持,C++20 仅实验性;缺 C++23。
  • GUI 开发建议
    • GTK 应用:使用 GTK 3.24;本机缺 GTK 2/4,跨发行版时注意 GTK 2 兼容路径
    • Qt 应用:使用 Qt 5.11(Deepin 改版);如需 Qt 6 需自行编译或添加 backports 源
  • 缺失开发头文件:未安装 *-dev 包,仅运行时库;编译需 apt install libgtk-3-dev qtbase5-dev 等。
  • 图形栈X11 主用 + Wayland 协议栈就绪;NVIDIA 专有驱动 550.120 已就位(GL 4.6),Vulkan 仅加载层待补 ICD。
  • 国产化护城河:内核携带 useclinux=1 / ima_appraise=off / 海光 C86 优化等 Deepin 自研补丁链。

与主流发行版横向对比

核心组件对比

组件 当前系统 Debian 10 buster Debian 11 bullseye Debian 12 bookworm Ubuntu 20.04 focal Ubuntu 22.04 jammy Ubuntu 24.04 noble
Kernel 4.19.0-desktop 4.19 5.10 6.1 LTS 5.4 / 5.15 HWE 5.15 / 5.19 6.8 (HWE)
GCC 8.3.0 8.3.0 10.2.1 12.2 9.3 11.2 13.x
glibc 2.28 2.28 2.31 2.36 2.31 2.35 2.39
binutils 2.31.1 2.31.1 2.35.2 2.40 2.34 2.38 2.42
libstdc++ ABI GLIBCXX_3.4.25 3.4.25 3.4.28 3.4.30 3.4.28 3.4.29 3.4.32
Python 3.7.3 3.7.3 3.9 3.11 3.8 3.10 3.12
C++ 标准上限 C++17 C++17 C++20 (部分) C++23 C++17 C++20 C++23

GUI 工具包对比

组件 当前系统 Debian 10 Debian 11 Debian 12 Ubuntu 20.04 Ubuntu 22.04
GLib (deepin) 2.58 2.66 2.74 2.63 2.72
GTK 2 2.24.32 2.24.33 2.24.33 2.24.32 2.24.33
GTK 3 3.24.5 3.24.2 3.24.24 3.24.38 3.24.18 3.24.33
GTK 4 4.8
Qt 5 5.11.3 5.11.3 5.15.2 5.15.8 5.12.8 5.15.3
Qt 6 6.4 6.2
默认 DE DDE 任意 任意 任意 GNOME GNOME

显示与图形对比

组件 当前系统 Debian 10 Debian 11 Debian 12 Ubuntu 20.04 Ubuntu 22.04
Xorg 1.20.4 1.20.4 1.20.11 21.1 1.20.8 21.1
Wayland 协议 1.21 1.16 1.18 1.21 1.18 1.20
Mesa 19.2.6 18.3 20.3 22.3 20.0 / 21.2 22.0
libGL(厂商) 1.1.0.3 (Nvidia) 1.1.0 1.3.4 1.6 1.3.4 1.4
默认协议 X11 X11 X11/Wayland Wayland X11 Wayland

综合匹配度评分(越接近 100% 越相似)

对比目标 内核 GCC glibc GTK Qt X11 综合
Debian 10 buster ✅ 4.19 一致 ✅ 完全一致 ✅ 完全一致 ✅ 3.24 一致 ✅ 5.11.3 一致 ✅ 完全一致 ~98%
Ubuntu 18.04 bionic ✅ 4.15/5.x 接近 ✅ 7.5/8.x 接近 ⚠️ 2.27 (旧) ✅ 3.24 一致 ⚠️ 5.9/5.12 ✅ 一致 ~92%
Debian 11 bullseye ⚠️ 4.19 vs 5.10 (旧) ⚠️ 8.3 vs 10.2 (旧) ⚠️ 2.28 vs 2.31 (旧) ✅ 3.24 接近 ⚠️ 5.11 vs 5.15 ✅ 接近 ~82%
Ubuntu 20.04 focal ⚠️ 4.19 vs 5.4 (旧) ⚠️ 8.3 vs 9.3 (旧) ⚠️ 2.28 vs 2.31 (旧) ✅ 3.24 接近 ⚠️ 5.11 vs 5.12 ✅ 接近 ~80%
Ubuntu 22.04 jammy ❌ 4.19 vs 5.15 (旧) ❌ 8.3 vs 11.2 (旧) ❌ 2.28 vs 2.35 (旧) ⚠️ 3.24.5 vs 3.24.33 ⚠️ 5.11 vs 5.15 ✅ 接近 ~65%
Debian 12 bookworm ❌ 4.19 vs 6.1 (旧) ❌ 8.3 vs 12.2 (旧) ❌ 2.28 vs 2.36 (旧) ⚠️ 3.24 旧 ⚠️ 5.11 vs 5.15 ⚠️ 1.20 vs 21.1 (旧) ~55%
Ubuntu 24.04 noble ❌ 4.19 vs 6.8 (旧) ❌ 8.3 vs 13 (旧) ❌ 2.28 vs 2.39 (旧) ⚠️ 3.24 旧 ⚠️ 5.11 vs 5.15 ⚠️ 1.20 vs 21.1 (旧) ~50%

关键结论

🎯 最接近的发行版:Debian 10 buster (≈98% 匹配)

  • 内核 4.19、GCC 8.3、glibc 2.28、Qt 5.11.3、GTK 3.24 完全一致
  • 唯一差异:UOS 用了 Deepin 自维护的 4.19 分支(带国产化补丁链)
  • 兼容性结论:二进制级 ABI 兼容,可直接复用 Debian 10 仓库与 .deb

次接近:Ubuntu 18.04 bionic (≈92%)

  • glibc 2.27 旧于本机 2.28,反向兼容——本机可借 bionic 仓库用,但反过来不行
  • 兼容性结论:可运行 bionic 二进制,但本机 ABI 更新,覆盖其上生态

Debian 11 / Ubuntu 20.04 (~80%)

  • 仅基础栈接近,glibc 2.31 高于本机 2.28
  • 兼容性结论:本机无法直接运行其二进制GLIBC_2.31 not found),需 chroot / Docker / linglong

Debian 12+ / Ubuntu 22.04+ (<70%)

  • GCC 11+、glibc 2.35+、Mesa 22+ 全部高于本机
  • 兼容性结论:无法运行其二进制,需容器或升级

重要 ABI 兼容性提示

由于本机 glibc 2.28,以下限制需注意:

发行版 能否运行其二进制 说明
Debian 10 buster ✅ 完美运行 glibc ≤ 2.28
Ubuntu 18.04 bionic ✅ 完美运行 glibc 2.27 ≤ 本机 2.28
Debian 11 / Ubuntu 20.04 ❌ glibc 2.31 要求 需 chroot / 容器 / linglong
Ubuntu 22.04 / Debian 12 ❌ glibc 2.35+ 要求 需容器或升级
Qt 官方安装包 ⚠️ 仅 Qt 5.11.x 系列兼容 Qt 5.15+ 官方需 glibc 2.31+

兼容情况

二进制兼容等级

兼容等级 发行版 说明
🟢 完全兼容 Debian 10 buster ABI 一致,可直接复用 .deb 包与 apt 源
🟢 高度兼容 Ubuntu 18.04 bionic glibc / 内核主线接近,反向兼容运行
🟡 基本兼容 Deepin 15.x(同源) 同 ABI,deepin 仓库可作为首选主源
🟡 受限兼容 Debian 11 / Ubuntu 20.04 仅个别组件新;glibc 2.31 高于本机 2.28,反向不兼容
🔴 不兼容 Debian 12 / Ubuntu 22.04+ glibc 2.35+、GCC 11+ 全部高于本机

软件包兼容矩阵

软件类型 兼容来源 备注
.deb 软件包 Debian 10 / Deepin 15 直接安装可用
apt 源 deb.debian.org/debian buster + repo.deepin.com 推荐主源;UOS 自有源优先
apt 源 archive.ubuntu.com bionic 备用,PPA 需谨慎
Qt 官方安装包 Qt 5.11.x(Linux x64) Qt 5.15+ 官方需 glibc 2.31+
PyPI 包 Python 3.7 wheels cp37 通用轮子可用;cp39/cp311 需另行处理
npm / Node.js Node 14/16 LTS 与 glibc 2.28 兼容
Docker 镜像 buster / bionic 二进制级兼容
Docker 镜像 bullseye / focal ⚠️ 镜像内运行无碍,但宿主工具链不一致
Docker 镜像 bookworm / jammy / noble ❌ 镜像内基于较新 glibc,部分场景可能触发宿主兼容问题(一般 OK)
linglong 沙箱 玲珑仓(repo.linglong.dev 国产化沙箱主推,可绕过 ABI 限制
Flatpak Flatpak 1.2.5 备用沙箱

编译兼容等级

编译工具链 能力 说明
GCC 8.3 C17 / C++17 / 部分 C++20 主流语言标准全支持
GLIBCXX_3.4.25 C++ ABI 对应 libstdc++ from GCC 8
glibc 2.28 POSIX 高级特性 含 statx、getrandom 等;缺较新版 epoll_pwait2

总结

当前系统 ≈ Debian 10 buster + Deepin 国产化适配层 + DDE 桌面栈

  • ✅ 软件生态:完全兼容 Debian 10 buster,可直接 apt 复用其仓库;Deepin 同源仓库是首选
  • ✅ GUI 编程:GTK 3.24 / Qt 5.11 完整支持,可开发现代桌面应用;Qt 5.15 / Qt 6 需自行编译或走沙箱
  • ⚠️ 内核:4.19 LTS 已脱离上游官方支持,靠 Deepin 自维护;国产化补丁链(useclinux / IMA / 海光 C86 优化)是 UOS 的护城河
  • ⚠️ ABI 边界:glibc 2.28 是关键上限,无法运行 Debian 11+ / Ubuntu 20.04+ 二进制;引入新版生态需 Docker / linglong
  • 💡 升级建议:
    • 短期:通过 linglong / flatpak / Docker 解决新生态兼容问题
    • 长期:评估 UOS 主版本升级路径(V20 → V25 / 1050 / 1060 等),跨主版本升级 ABI 与内核基线会跳一档
    • 选型:如仅需 GNOME / KDE 而非 DDE,建议直接评估 Debian 11 / Ubuntu 22.04 本家发行版

背景与定位

最近接触了一台国产化 PC,搭载的是方德桌面操作系统 V5.0-G240H(NFSChina Desktop OS)。从内核到 GUI 全套看了一遍,发现它本质是 Debian 11 bullseye 的国产化定制版,主要差异在内核主版本和驱动层。

作为开发者,最关心的是:在这台机器上编译的应用能不能跑?Debian/Ubuntu 上的 .deb 能不能直接装?本文做一次系统性的兼容性盘点。

一句话结论:当作 Debian 11 bullseyeUbuntu 20.04 focal 环境使用最稳妥。

一、操作系统识别

项目 详情
发行版 方德桌面操作系统 V5.0-G240H(NFSChina Desktop OS)
家族 类 Debian 桌面发行版
基础来源 基于 Debian 11 (bullseye) 定制
内核 Linux 5.4.0-100-generic(Debian 构建)
架构 x86_64 (amd64)
版本号 Debian 11.3
编译器 GCC 10.2.1
C 标准库 glibc 2.31
默认桌面 GNOME(推测,发行版默认)

方德(FS、NFSChina)是国内操作系统厂商,主攻党政机关、央企、关键行业等信创市场。本版本 G240H 属于桌面端 V5.0 系列,针对国产化 PC 平台优化。

二、系统技术栈总览

2.1 核心运行时栈

1
2
3
4
5
6
7
┌─────────────────────────────────────────┐
│ Linux Kernel 5.4.0-100-generic │ ← LTS 分支
├─────────────────────────────────────────┤
│ glibc 2.31 / GCC 10.2 / binutils 2.35 │ ← ABI 基线
├─────────────────────────────────────────┤
│ libstdc++ GLIBCXX_3.4.28 │ ← C++ ABI
└─────────────────────────────────────────┘

2.2 GUI / 应用栈

1
2
3
4
5
6
7
┌───────────────────────────────────────────┐
│ GTK 3.24.24 (主) │ GTK 2.24.33 (老) │ ← GNOME 应用
├───────────────────────────────────────────┤
│ Qt 5.15.2 (Core/Gui/Widgets/Quick/...) │ ← KDE/Qt 应用
├───────────────────────────────────────────┤
│ GLib 2.66.8 │ ← C 工具库
└───────────────────────────────────────────┘

2.3 显示 / 图形栈

1
2
3
4
5
┌───────────────────────────────────────────┐
│ Wayland 1.18 │ X11 1.7.5 │ xcb 1.14 │ ← 双显示协议
├───────────────────────────────────────────┤
│ NVIDIA T400 4GB (GLX 1.4) │ ← 独显
└───────────────────────────────────────────┘

三、核心组件版本详解

3.1 核心组件

组件 版本 说明
Kernel 5.4.0-100-generic LTS 内核(Debian 构建)
GCC 10.2.1 (20210110) 支持 C++17/部分 C++20
Glibc 2.31 (Debian 2.31-13+deb11u3)
Binutils GNU ld 2.35.2
libstdc++ GLIBCXX_3.4.28 (GCC 10.x)
Python 3.9.2
Make 4.3
pkg-config 0.29.2

3.2 GUI 工具包

工具包 版本 备注
GLib 2.66.8
GTK 2 2.24.33 旧版兼容
GTK 3 3.24.24 当前主用
GTK 4 ❌ 未安装
Qt 5 5.15.2 含 Core/Gui/Widgets/Quick/Qml/Multimedia/WebEngine 等
Qt 6 ❌ 未安装

3.3 显示与图形

组件 版本/状态
X11 (libx11) 1.7.5
xcb 1.14
Wayland 1.18.0(客户端/服务端均可用)
OpenGL NVIDIA T400 4GB(GLX 1.4)
OpenGL ES / Vulkan 未检测

3.4 关键结论

  • 编译器能力:GCC 10.2 → C++20 完整支持,C++23 处于实验性。
  • GUI 开发建议
    • GTK 应用:使用 GTK 3.24(推荐)或 GTK 2(兼容旧程序)
    • Qt 应用:使用 Qt 5.15 LTS;如需 Qt 6 需自行编译或添加 backports 源
  • 缺失开发头文件:未安装 *-dev 包,仅有运行时库。如需编译需 apt install libgtk-3-dev qtbase5-dev 等。
  • 图形栈:X11 + Wayland 双栈,NVIDIA 专有驱动已就位(GLX 1.4)。

四、与主流发行版的详细对比

4.1 核心组件对比

组件 当前系统 Debian 11 Ubuntu 20.04 Ubuntu 22.04 Debian 12 Ubuntu 24.04
Kernel 5.4.0-100 5.10 系列 5.4 (GA) / 5.15 (HWE) 5.15 / 5.17 (OEM) 6.1 LTS 6.8 (HWE)
GCC 10.2.1 10.2 9.3 (default) 11.2 12.2 13.x
glibc 2.31 2.31 2.31 2.35 2.36 2.39
binutils 2.35.2 2.35.2 2.34 2.38 2.40 2.42
Python 3.9.2 3.9 3.8 3.10 3.11 3.12
Make 4.3 4.3 4.2.1 4.3 4.3 4.3

4.2 GUI 工具包对比

组件 当前系统 Debian 11 Ubuntu 20.04 Ubuntu 22.04 Debian 12
GLib 2.66.8 2.66.8 2.63 2.72 2.74
GTK 2 2.24.33 2.24.33 2.24.32 2.24.33 2.24.33
GTK 3 3.24.24 3.24.24 3.24.18 3.24.33 3.24.38
GTK 4
Qt 5 5.15.2 5.15.2 5.12.8 5.15.3 5.15.8
Qt 6 6.4

4.3 显示与图形对比

组件 当前系统 Debian 11 Ubuntu 20.04 Ubuntu 22.04 Debian 12
X11 (libx11) 1.7.5 1.7.2 1.6.9 1.7.5 1.8.4
xcb 1.14 1.14 1.14 1.14 1.15
Wayland 1.18 1.18 1.18 1.20 1.21
OpenGL GLX 1.4 GLX 1.4 GLX 1.4 GLX 1.4 GLX 1.4
GNOME - 3.38 3.36 42 43

4.4 综合匹配度评分

越接近 100% 表示技术栈越相似,二进制/源码级兼容性越好。

对比目标 内核 GCC glibc GTK Qt X11 综合
Debian 11 bullseye ⚠️ 5.4 vs 5.10 ✅ 完全一致 ✅ 完全一致 ✅ 完全一致 ✅ 完全一致 ⚠️ 1.7.5 vs 1.7.2 ~92%
Ubuntu 20.04 focal ✅ 内核 5.4 一致 ⚠️ 10.2 vs 9.3 ✅ 一致 ⚠️ 3.24.24 vs 3.24.18 ⚠️ 5.15.2 vs 5.12.8 ⚠️ 1.7.5 vs 1.6.9 ~88%
Ubuntu 22.04 jammy ⚠️ 5.4 vs 5.15 (旧) ⚠️ 10.2 vs 11.2 (旧) ⚠️ 2.31 vs 2.35 (旧) ⚠️ 3.24.24 vs 3.24.33 (旧) ⚠️ 5.15.2 vs 5.15.3 ✅ 1.7.5 一致 ~75%
Debian 12 bookworm ❌ 5.4 vs 6.1 (旧) ❌ 10.2 vs 12.2 (旧) ❌ 2.31 vs 2.36 (旧) ⚠️ 3.24.24 vs 3.24.38 (旧) ⚠️ 5.15.2 vs 5.15.8 ❌ 1.7.5 vs 1.8.4 (旧) ~55%

4.5 关键结论

🎯 最接近的发行版:Debian 11 bullseye(≈92% 匹配)

  • 编译器(GCC 10.2.1)、glibc 2.31、GTK 3.24.24、Qt 5.15.2 完全一致
  • 唯一差异:内核主版本 5.4 vs 5.10(方德用了更早的 5.4 LTS 分支)
  • 兼容性结论:二进制级 ABI 兼容,可直接使用 Debian 11 仓库

次接近:Ubuntu 20.04 focal(≈88%)

  • glibc、GTK 2、内核主线一致
  • Qt5(5.15 vs 5.12)和 X11(1.7 vs 1.6)略新
  • 兼容性结论:运行 Ubuntu 20.04 二进制安全,可直接借用其 PPA

Ubuntu 22.04 jammy(≈75%)

  • 仅 X11 一致,其他组件比当前系统都新
  • 兼容性结论:当前系统无法直接运行 jammy 二进制(glibc 2.35 要求高于本机 2.31)

4.6 重要 ABI 兼容性提示

由于当前系统 glibc 2.31,以下限制需注意:

发行版 能否运行其二进制 说明
Debian 11 / Ubuntu 20.04 ✅ 完美运行 glibc ≤ 2.31
Ubuntu 22.04 ❌ glibc 2.35 要求 需 chroot/容器
Debian 12 ❌ glibc 2.36 要求 需容器或升级
Qt 官方包 ✅ Debian 11 是 Qt 6 官方支持平台 GCC 10 + glibc 2.31

最终建议:当作 Debian 11 bullseye 或 Ubuntu 20.04 focal 环境使用最稳妥,可直接使用对应的 .deb 软件包与 apt 源。Ubuntu 22.04 及以后的二进制需要 Docker/chroot 运行。

五、兼容情况

5.1 二进制兼容等级

兼容等级 发行版 说明
🟢 完全兼容 Debian 11 bullseye ABI 一致,可直接复用 .deb 包与 apt 源
🟢 高度兼容 Ubuntu 20.04 focal 内核主线、glibc 一致,Qt5/X11 微新,兼容运行
🟡 基本兼容 Ubuntu 18.04 bionic glibc 2.27 旧于本机,反向兼容运行
🟡 受限兼容 Ubuntu 22.04 jammy 仅个别组件新;glibc 2.35 高于本机 2.31,反向不兼容
🔴 不兼容 Debian 12 bookworm / Ubuntu 24.04 glibc 2.36+、GCC 12+ 全部高于本机

5.2 软件包兼容矩阵

软件类型 兼容来源 备注
.deb 软件包 Debian 11 / Ubuntu 20.04 直接安装可用
apt 源 deb.debian.org/debian bullseye 推荐主源
apt 源 archive.ubuntu.com focal 备用,PPA 需谨慎
Qt 官方安装包 Qt 5.15 (Linux x64) 官方支持本机环境
PyPI 包 Python 3.9 wheels cp39 通用轮子可用
npm/Node.js Node 14/16 LTS 与 glibc 2.31 兼容
Docker 镜像 bullseye / focal 二进制级兼容
Docker 镜像 bookworm / noble ❌ 无法运行(需 qemu-user)

5.3 编译兼容等级

编译工具链 能力 说明
GCC 10.2 C17 / C++17 / 部分 C++20 主流语言标准全支持
GLIBCXX_3.4.28 C++ ABI 对应 libstdc++ from GCC 10
glibc 2.31 POSIX 高级特性 含 epoll_pwait2、statx 等

六、总结

当前系统 ≈ Debian 11 bullseye + 国产化适配层

  • 软件生态:完全兼容 Debian 11,可用 apt 源直接扩展
  • GUI 编程:GTK 3.24 / Qt 5.15 完整支持,可开发现代桌面应用
  • ⚠️ 内核:5.4 LTS 偏旧,但稳定可靠,足够支撑桌面与服务器场景
  • ⚠️ ABI 边界glibc 2.31 是关键上限,不能运行更新的发行版二进制
  • 💡 升级建议:若需运行新版生态,可通过 Docker 解决;若需大规模生产部署,建议直接以 Debian 11 / Ubuntu 20.04 为目标

选型核心只有一句话:glibc ≤ 2.31 的世界就是这台机器的舒适区

背景与场景

三维重建是测绘、GIS、影视、游戏、VR 等多个行业的底层技术。近两年”3D 高斯飞溅(3D Gaussian Splatting,下文简称 3D-GS)”凭借惊艳的视觉效果迅速走红,让很多人开始重新评估自己的技术路线:传统”倾斜摄影测量”是不是要被取代了?

答案没那么简单。两者定位完全不同 —— 一个是测量级工具,输出可量测的几何模型;一个是渲染级工具,输出可实时显示的辐射场。把它们当作”新旧替代关系”是典型误读。本文从原理、输出、精度、应用四个维度做一次系统梳理,帮你按需选型。

一、技术原理

1.1 倾斜摄影测量(Oblique Photogrammetry)

倾斜摄影测量是摄影测量学的成熟分支:通过无人机搭载多镜头相机(通常五镜头),从多个角度对同一地物拍摄大量带有重叠度的照片,再借助特征点匹配(SIFT / SFM)和多视密集匹配(MVS),反算出每个像素对应的空间坐标,最终生成带真实纹理的三角网格(Mesh)和纹理贴图。

内容
输入 多角度重叠航拍照片(一般 70%–80% 重叠度)
核心算法 SFM(Structure-from-Motion) + MVS(Multi-View Stereo) + 三角化
输出 Mesh + 纹理、可选点云、正射影像、DSM/DTM
代表软件 ContextCapture(原 Smart3D)、Pix4D、大疆智图、PhotoScan、超图

1.2 3D 高斯飞溅(3D Gaussian Splatting)

3D-GS 是 2023 年由 INRIA 提出的新型神经渲染方法。它把场景表示为海量可微分的 3D 高斯椭球(每个椭球带位置、协方差、颜色、透明度),通过 SfM 初始化后用 GPU 迭代优化,最终在任意视角下通过”飞溅投影”实时合成图像。

内容
输入 多角度照片/视频(也支持 NeRF 风格数据集)
核心算法 可微分高斯渲染 + 梯度下降优化
输出 高斯场文件(.ply / .splat),可实时渲染
代表项目/产品 3D-GS 原版、NeRFStudio、Luma AI、GaussianEditor、PostShot

二、核心区别

维度 倾斜摄影测量 3D-GS
定位 测量级 / 测绘 渲染级 / 视觉
输出格式 Mesh + 纹理 / 点云 高斯辐射场
几何精度 厘米级,可量测 视觉级,不能直接量测
实时渲染 ❌ 较慢,需客户端渲染 ✅ 实时(>30 FPS)
可编辑性 一般 较强(可拆分、编辑、组合场景)
硬件门槛 普通 CPU/GPU 即可 训练需中高端 GPU(≥16 GB 显存)
成熟度 成熟商用 10+ 年 2023 起快速迭代

关键差异:倾斜摄影测量输出的 Mesh 在 GIS 软件里可以直接量距离、面积、体积,3D-GS 输出在视觉上很美但”几何是隐式的”,无法直接拿到准确尺寸。

三、典型应用场景

3.1 倾斜摄影测量

行业 场景
测绘地理 地形图测绘、等高线生成、权属调查、地籍测量
智慧城市 城市三维建模、CIM 平台、数字孪生底座
建筑房产 不动产测绘、工程验收、建筑形变监测
应急管理 灾害现场建模、灾后评估、应急指挥
交通/电力 道路桥梁建模、电力线巡检、隧道监测

3.2 3D 高斯飞溅

行业 场景
游戏 / 元宇宙 真实场景资产快速导入、虚拟世界构建
影视 / 特效 数字场景重建、虚拟拍摄(LED 墙)、演员复刻
VR / AR 沉浸式体验、空间扫描、空间计算
电商 商品 3D 展示、虚拟试穿、AR 预览
文化遗产 文物高精度数字化、虚拟博物馆
自动驾驶 场景重建、NeRF/GS 仿真测试闭环

四、技术选型建议

需求 推荐方案
需要厘米级可量测模型 倾斜摄影测量
重点是视觉效果/实时渲染 3D-GS
既要测量又要好看 倾斜摄影测量建模 + 3D-GS 渲染(业界已有 hybrid 方案)
大范围地形/城市底图 倾斜摄影测量
小物体/室内精细还原 两者皆可,3D-GS 视觉效果更佳

五、代表产品速览

技术类别 代表产品
倾斜摄影测量 ContextCapture、Pix4D、大疆智图、PhotoScan、超图 GIS
3D-GS Luma AI(消费级 App)、NeRFStudio(研究框架)、GaussianEditor(编辑)、PostShot、BrushGS

六、总结

两种技术不是替代关系,而是互补关系

  • 倾斜摄影测量 → 测绘、工程、政府项目、可量测场景的标准答案;
  • 3D 高斯飞溅 → 视觉表现、实时渲染、消费级体验的更优解。

如果项目对”几何精度”敏感,就老老实实用倾斜摄影测量;如果项目对”画面真实感和实时性”敏感,3D-GS 是 2024 年以来的最优解。预算充足、要求高的话,可以把两者结合 —— 用倾斜摄影测量保证几何骨架,用 3D-GS 渲染贴层做视觉增强。

选型核心只有一句话:你的项目到底是”要测”还是”要看”?

前言:为什么必须锁定 2.1.153

Claude Code 在近期版本迭代中,对第三方自定义模型做了强制封杀,版本分界线非常明确:

  • ≤ 2.1.153:完全原生支持 ANTHROPIC_BASE_URL 自定义接口,兼容所有国产 Anthropic 协议模型,无请求篡改、无强制登录、无报错。
  • 2.1.154 ~ 2.1.155:强制插入非法 system 字段,第三方模型全部 400 报错。
  • ≥ 2.1.156:底层彻底移除自定义接口能力,完全无法使用第三方模型。

结论:2.1.153 是目前国内开发者使用第三方模型的唯一终点版本。原本使用的 2.1.146 可直接平滑升级,稳定性大幅提升且完全保留第三方兼容性。

一、定点安装 / 升级至 2.1.153

使用官方原生安装脚本定点安装指定版本,无需卸载旧版本,直接覆盖升级,保留用户目录配置。

macOS / Linux / WSL

1
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.153

Windows PowerShell(管理员)

1
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.153

版本校验

安装完成后重启终端,执行如下命令确认版本锁定成功:

1
claude --version

正常输出:Claude Code 2.1.153

二、永久锁定版本,彻底禁用自动更新

这是最重要步骤。不锁版本会被后台静默升级至失效版本,导致第三方模型彻底无法使用。采用「配置文件+系统环境变量」双重兜底方案。

2.1 全局配置文件锁定

编辑配置文件:

  • macOS / Linux:~/.claude/settings.json
  • Windows:%USERPROFILE%\.claude\settings.json

写入以下完整配置:

1
2
3
4
5
6
7
8
9
{
"autoUpdates": false,
"autoUpdatesChannel": "stable",
"minimumVersion": "2.1.153",
"env": {
"DISABLE_AUTOUPDATER": "1",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
}
}

配置说明:

  • 关闭客户端自动更新:禁止客户端主动检测、下载、升级新版本
  • 禁用官方更新进程:通过官方环境变量彻底杀死更新服务
  • 关闭非必要遥测:减少国内网络无效请求,降低卡顿与延迟

2.2 系统环境变量兜底加固

macOS / Linux(zsh/bash)

1
2
echo 'export DISABLE_AUTOUPDATER=1' >> ~/.zshrc
source ~/.zshrc

Windows PowerShell

1
[Environment]::SetEnvironmentVariable("DISABLE_AUTOUPDATER", "1", "User")

三、国内环境专属优化方案

  • 精简 MCP 服务:未使用 MCP 工具链时,清空所有 MCP 服务,减少后台常驻占用
    1
    2
    claude mcp list
    claude mcp remove 服务名
  • 定期压缩上下文:长对话卡顿、上下文冗余,在 Claude 终端输入 /compact 一键精简会话
  • 管控后台任务:避免大量并行 /bg 后台任务,防止守护进程残留卡死
  • 清理缓存:定期删除 ~/.claude/cache 缓存目录,不影响配置与密钥

四、macOS / Linux 一键终极部署脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.153
cat > ~/.claude/settings.json << 'EOF'
{
"autoUpdates": false,
"autoUpdatesChannel": "stable",
"minimumVersion": "2.1.153",
"env": {
"DISABLE_AUTOUPDATER": "1",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
}
}
EOF
echo 'export DISABLE_AUTOUPDATER=1' >> ~/.zshrc
source ~/.zshrc
claude --version

结语

目前 Claude Code 官方持续收紧第三方模型权限,2.1.153 是国内免费自定义模型的最后窗口期版本

大语言模型的规模增长面临算力与存储的双重约束。如何在保持模型能力的前提下降低推理成本,已成为工业落地的核心命题。MoE(混合专家模型)、稀疏参数与知识蒸馏三项技术从不同维度破解这一困境:MoE通过动态激活部分参数实现稀疏化,稀疏参数释放了规模化的潜力,知识蒸馏则将大模型能力迁移至小模型。三者协同,代表了大模型从”大而强”走向”大而轻”的主流技术路径。

MoE:稀疏激活的神经网络架构

MoE的核心思想是”分而治之”。传统神经网络对所有输入执行相同的计算路径,而MoE将模型分解为多个并行的专家网络(Expert Networks),由一个门控网络(Gating Network)根据输入内容动态选择激活哪些专家。

具体而言,门控网络为每个输入token输出一组权重分布,决定各专家的参与程度。推理时,只有权重较高的少数专家被实际调用,其余专家的计算被跳过。以DeepSeek-R1-671B为例,其总参数规模为671B,但推理时每次仅激活约1/10的专家,单步计算量等价于一个67B的稠密模型。这意味着模型在拥有超大规模参数的同时,将实际计算成本控制在远低于总参数的量级。

MoE的优势在于:相同算力预算下可以容纳更多参数,从而突破稠密模型的规模瓶颈;不同专家可专注于不同类型的任务或知识领域,实现隐式的专业化分工。

稀疏参数:规模与效率的重新平衡

稀疏参数并非MoE独有,但MoE是其最典型的工程实现。稀疏的含义是:总参数量巨大,但任意时刻只有部分参数被实际使用。

这一特性带来三方面价值。首先是规模突破:在相同的算力和显存约束下,稀疏模型可以拥有10-100倍于稠密模型的参数量,因为大部分参数无需同时参与计算。其次是推理成本降低:激活参数少意味着每次前向传播的FLOPs大幅减少,部署成本随之下降。第三是专业化分工:不同专家可学习不同领域的知识,形成隐式的任务路由,避免单一模型试图同时掌握所有能力导致的表达冲突。

稀疏参数的本质是用”参数冗余”换取”计算高效”——存储的是大规模知识,执行时只调用与当前输入相关的部分。

知识蒸馏:从大模型到小模型的能力迁移

知识蒸馏(Knowledge Distillation)是将大模型(教师模型)能力迁移至小模型(学生模型)的技术。其核心机制是让小模型不仅学习硬标签(真实标签),还学习软标签(教师模型输出的概率分布)。

软标签包含的信息远多于硬标签。硬标签只告诉模型”正确答案是什么”,而软标签还携带了”错误答案之间的相对关系”——模型认为”猫”和”狗”的相似度高于”猫”和”汽车”,这种隐含的相似结构正是知识蒸馏希望传递的”暗知识”。

以DeepSeek-R1-Distill系列为例,教师模型为DeepSeek-R1-671B(MoE架构),学生模型则包括Qwen系(1.5B/7B/14B/32B)和Llama系(8B/70B)等多个规模的稠密模型。蒸馏后的小模型在保持极小参数量的同时,复现了教师模型在推理任务上的核心能力。

三者协同:技术飞轮的运转逻辑

三项技术的协同构建了一个高效的技术飞轮。

MoE提供了”超强教师”的可能——凭借稀疏激活,MoE模型可以在总参数极大的同时保持推理效率,这意味着教师模型可以拥有前所未有的知识容量和多样性。知识蒸馏则充当”能力搬运工”,将教师从海量参数中习得的知识以软标签的形式传递给轻量的学生模型。稀疏参数是连接两者的桥梁——它既是MoE的实现基础,也是蒸馏得以可行的前提,因为只有稀疏架构才能在保持大规模知识的同时具备足够的推理效率来完成蒸馏过程。

最终实现的效果是”高性能+低成本”的落地:教师模型负责知识生产和能力探索,学生模型负责实际部署和服务。这种分工在保持能力上限的同时,大幅降低了端侧部署的门槛。

总结

MoE通过稀疏激活打破了”参数量=计算量”的等式约束,为大规模模型的训练提供了新的可行路径。稀疏参数将这一优势工程化,实现规模与效率的重新平衡。知识蒸馏则在不损失核心能力的前提下,将大模型的优势迁移到可部署的轻量模型。三项技术共同推动了大模型从”大而强”向”大而轻”的关键演进,为AI能力的广泛落地扫清了算力壁垒。

通义千问 Qwen3.6-35B-A3B + 视觉能力,8G 显存、32G 内存,Windows 部署

前言

大模型常被认为是高端显卡的专属,动辄 24G、48G 显存门槛劝退普通玩家。但随着 llama.cpp 高性能推理 + GGUF 量化 + MoE 混合专家架构 的成熟,8G 消费级显卡也能跑 35B 级大模型,甚至带视觉能力。

本文全程基于 RTX 4060 8G + 32G 内存 + Windows,手把手部署 Qwen3.6-35B-A3B MoE(含视觉),无编译、无高门槛、可直接照抄操作。


一、硬件与模型选型

1.1 硬件配置(真实消费级)

  • 显卡:NVIDIA RTX 4060 8GB(GDDR6)

  • CPU:Intel i9-11900KB @ 3.30GHz

  • 内存:32GB DDR4(双通道,关键!)

  • 系统:Windows 11 64 位

1.2 选用模型详解

本次部署 通义千问 35B MoE 量化版 + 视觉投影

  • 主模型:Qwen3.6-35B-A3B-UD-Q4_K_M.gguf(4-bit 量化,平衡速度 / 效果)

  • 视觉投影:mmproj-BF16.gguf(支持图文对话、图片理解)

1.2.1 模型命名解析(A3B 与 UD)

字段 全称 核心含义
Qwen3.6 - 通义千问 3.6 系列大模型
35B 35 Billion 模型总参数数量(MoE 架构)
A3B Activated 3 Billion 推理时每个 token 仅激活约 3B 参数,实际计算量接近 3B 模型
UD Unsloth Dynamic Unsloth 团队优化的动态量化方案,兼顾高压缩率与推理质量
Q4_K_M 4-bit K-quant Medium 4 比特分层量化,对关键层保留更高精度
GGUF - llama.cpp 专用高效推理格式

1.2.2 选择理由

  • MoE 架构优势:总参数 35B,推理只激活少量专家,显存占用远低于同规模稠密模型

  • UD-Q4_K_M 量化:动态量化 + 混合精度,显存大幅下降,适配 8G+32G 配置

  • 原生视觉能力:内置视觉编码器,开箱即用图文对话

  • 开源生态成熟:Unsloth 提供 GGUF 版本,兼容性好、社区支持完善


二、环境安装(Windows,一键到位)

2.1 安装 CUDA 12.4(必须,13.2 有兼容问题)

管理员 PowerShell 执行:

1
winget install NVIDIA.CUDA.12.4

安装完成后重启电脑

2.2 下载预编译 llama.cpp(免编译)

  1. 发布页:https://github.com/ggerganov/llama.cpp/releases

  2. 下载:llama-b9305-bin-win-cuda-12.4-x64.zip

  3. 解压到目录,例如:D:llama.cpp

2.3 安装 uv + huggingface-hub(uv tool)

2.3.1 安装 uv

1
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

2.3.2 安装 huggingface-hub

1
uv tool install huggingface-hub

验证:

1
huggingface-cli --version

2.4 永久配置 HF 国内镜像(hf-mirror)

镜像地址:https://hf-mirror.com

管理员 PowerShell 执行:

1
setx HF_ENDPOINT "https://hf-mirror.com" /M

或手动添加系统环境变量,重启终端生效。

2.5 下载模型(hf-mirror 加速)

进入 llama.cpp 目录,创建文件夹:

1
mkdir -p models/Qwen3.6-35B-A3B-UD-Q4_K_M

下载命令:

1
hf download unsloth/Qwen3.6-35B-A3B-GGUF Qwen3.6-35B-A3B-UD-Q4_K_M.gguf mmproj-BF16.gguf --local-dir ./models/Qwen3.6-35B-A3B-UD-Q4_K_M

三、启动脚本与参数详解(8G 最优配置)

在 llama.cpp 目录新建 start.bat

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
@echo off
chcp 65001 >nul
title Qwen3.6-35B-A3B MoE + 视觉模型
echo ======================================================
echo 通义千问35B MoE + 视觉模型 稳定加速版
echo 硬件:RTX4060 8G + 32G 内存
echo ======================================================
echo.

cd /d "%~dp0"

llama-server.exe ^
-m "./models/Qwen3.6-35B-A3B-UD-Q4_K_M/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" ^
--mmproj "./models/Qwen3.6-35B-A3B-UD-Q4_K_M/mmproj-BF16.gguf" ^
-ngl 99 ^
--n-cpu-moe 32 ^
-np 1 ^
--flash-attn on ^
--jinja ^
-c 32768 ^
-t 16 ^
-b 1024 ^
-ub 256 ^
--split-mode layer ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--no-mmap ^
--host 127.0.0.1 ^
--port 8080 ^
--metrics

echo.
echo 启动成功!浏览器访问:http://127.0.0.1:8080
pause

关键参数解析

参数 作用 适配说明
-ngl 99 99 层全部上 GPU 最大化利用 4060 算力
--n-cpu-moe 32 MoE 专家放 CPU / 内存 显存不够、内存来补
--flash-attn on 注意力加速 + 省显存 8G 必备优化
-c 32768 32K 上下文 支持长文本对话
--split-mode layer 分层放显存 / 内存 防止爆显存
--cache-type-k/v q4_0 KV 缓存 4-bit 量化 显存占用减少 75%

四、运行效果(8G 显卡真实表现)

4.1 启动与访问

  1. 双击 start.bat

  2. 首次加载约 1–2 分钟

  3. 浏览器打开:http://127.0.0.1:8080

模型启动后资源占用

4.2 资源占用

  • 显存:7.2–7.8GB(稳定不溢出)

  • 内存:16–20GB(专家层分流)

  • CPU:90%(负载可控)

模型生成过程资源占用

4.3 推理速度

  • 文本对话:30 token/s(日常流畅)

  • 图文对话:响应 2–3 秒,识别准确

模型生成界面
模型生成速度

4.4 能力表现

  • 文本:问答 / 推理 / 创作接近原生 35B

  • 视觉:图片描述、OCR、简单图像问答可用

4.5 稳定性

连续运行 4 小时无崩溃,长文本对话不掉链。


五、效果截图

图 1:启动脚本运行成功界面

图 2:Web 交互主界面

图 3:GPU 显存占用监控

图 4:图文对话示例


六、总结

RTX 4060 8G 真的能跑 35B MoE + 视觉。核心要点:

  • CUDA 12.4 + llama.cpp 预编译,避开兼容问题

  • UD-Q4_K_M 量化 + KV 缓存量化,适配 8G 显存

  • MoE 专家分流到内存,32G 内存成为关键

  • hf-mirror 加速,国内高速下载模型

这套方案成本极低、操作极简、效果可用,普通消费卡也能体验 35B 级大模型能力。

目标

解决 Hexo 博客中 LaTeX 矩阵公式(如 bmatrix)被渲染成单行的问题,使多行矩阵正确显示为多行结构。

前置条件

  • Node.js 环境
  • 已有的 Hexo 博客项目
  • 使用 NexT 主题

环境安装

安装依赖

1
npm install hexo-filter-mathjax@0.3.1 mathjax@3.2.2 --save

站点配置

_config.yml 中添加:

1
2
3
4
mathjax:
enable: true
per_page: false
tags: none

注意tags 不要写成 mathjax,否则 hexo generate 时会报 ReferenceError: mathjax is not defined

关闭 NexT 主题前端 MathJax

NexT 主题会在前端加载自己的 MathJax CDN,与服务端渲染冲突。在主题 _config.yml 中关闭:

1
2
3
4
5
math:
mathjax:
enable: false
katex:
enable: false

核心:矩阵行尾反斜杠数量

这是最容易踩的坑。hexo-renderer-marked 在处理 Markdown 时,会将行末的反斜杠数量减半:

源码写入 marked 处理后 MathJax 收到 结果
\\(2个 \ \(1个 \ 触发 HTML <br> ❌ 矩阵单行
\\\\(4个 \ \\(2个 \ 识别为 LaTeX 换行 ✅ 多行正确

结论:非最后一行矩阵数据行尾必须写 4 个反斜杠 \\\\

正确写法示例

1
2
3
4
5
6
7
$$
X=
\begin{bmatrix}
1 & 2 & 3 & 4 \\\\ ← 非最后行:4个反斜杠
2 & 1 & 4 & 3 ← 最后行:无反斜杠
\end{bmatrix}
$$
1
2
3
4
5
6
7
8
9
$$
W_Q=
\begin{bmatrix}
0.1 & 0 & 0 & 0 \\\\
0 & 0.2 & 0 & 0 \\\\
0 & 0 & 0.3 & 0 \\\\
0 & 0 & 0 & 0.4
\end{bmatrix}
$$

下划线处理:operatorname

\text{FFN_State} 中的下划线在 MathJax 的 text 模式下不合法,会导致错误并 fallback 为纯文本。用 operatorname 替代:

场景 正确写法 错误写法
无下划线 \text{LayerNorm}
有下划线 \operatorname{FFN_State} \text{FFN_State}

验证方法

本地预览

1
npx hexo server -p 4000

检查 mtr 数量

mtr 是 MathJax 的矩阵行元素,有几个 mtr 就有几行:

1
grep -o 'data-mml-node="mtr"' public/文章路径/index.html | wc -l

多行矩阵应该 mtr ≥ 2。单行公式 mtr = 0 是正常的。

浏览器控制台验证

1
2
document.querySelectorAll('mjx-container').length   // 总容器数
document.querySelectorAll('[data-mjx-error]').length // 错误数,应为 0

常见问题

矩阵还是单行显示怎么办?

检查矩阵数据行尾的反斜杠数量:

1
2
3
4
5
with open('source/_posts/文章.md') as f:
for i, line in enumerate(f, 1):
if '&' in line and line.rstrip().endswith('\\'):
bs = line.rstrip().count('\\')
print(f"line {i}: {bs} backslashes {'✓' if bs == 4 else '✗ NEEDS FIX'}")

输出应有 4 backslashes ✓,否则需要修复。

配置报错 ReferenceError: mathjax is not defined

检查 _config.ymlmathjax.tags 是否写成了 mathjax,应改为 none

浏览器控制台有 '_' allowed only in math mode 错误

使用了 \text{FFN_State},下划线不合法。改用 \operatorname{FFN_State}

总结

修复 Hexo 矩阵渲染只需记住两件事:

  1. 4个反斜杠:非最后行行尾写 \\\\
  2. operatorname:含下划线的标识符用 \operatorname 代替 \text

其他配置(hexo-filter-mathjax、关闭 NexT MathJax)只需设置一次,后续写矩阵公式时遵循上述格式即可。

uv 切换问题

原因分析

Claude Code 的 python 环境检测优先级为:

  1. requirements.txt — 最高优先级
  2. pyproject.toml — 次之
  3. 其他配置

当项目没有 uv.lock 或 uv 特定的 pyproject.toml 结构时,Claude Code 默认走 pip/venv 流程,不会自动切换到 uv。

解决方案

方案 改动量 生效速度 推荐场景
CLAUDE.md 最少 重启后 快速解决
settings.json 即时 项目级配置
uv 项目化 完成后 长期维护

方案 1(推荐):CLAUDE.md

在项目根目录创建 CLAUDE.md

1
2
3
# Python Environment
Use `uv` for all Python package management. Never use pip.
Run commands with `uv run`, e.g., `uv run python`, `uv add <package>`.

加完 CLAUDE.md 后重启 Claude Code,它就会用 uv run python 代替默认的 pip/venv 流程。

方案 2:settings.json

{project}/.claude/settings.json 中配置:

1
2
3
4
5
{
"python": {
"packageManager": "uv"
}
}

方案 3:uv 项目化

将项目完全迁移到 uv 管理:

1
2
3
uv init
uv add <your-packages>
# 确保有 uv.lock 文件存在

更多使用技巧将陆续补充。

Claude Code 的记忆系统分为 三层,分别解决不同层面的问题。理解这三层的区别与关系,是高效使用 Claude Code 的前提。


一、三层架构概览

层级 存储位置 解决问题 跨项目共享?
全局配置 ~/.claude/settings.json 所有项目共享的权限、插件、环境变量 ✅ 是
项目配置 {project}/.claude/ 该项目专属的权限、钩子 ❌ 否
项目记忆 ~/.claude/projects/<path>/memory/ 该项目的用户偏好、工作约定 ❌ 否

二、全局配置层

所有项目共享的配置,定义 Claude Code 的全局行为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"env": {
"ANTHROPIC_MODEL": "MiniMax-M2.7"
},
"permissions": {
"allow": [
"Bash(uv sync *)",
"Bash(git log --oneline -20)"
]
},
"enabledPlugins": {
"superpowers@claude-plugins-official": true,
"remember@claude-plugins-official": true
}
}

核心配置项包括:

  • env — API key、全局默认模型
  • permissions — 所有项目都允许的 Shell 命令
  • enabledPlugins — 全局启用的插件

三、项目配置层

单个项目专属的配置,通常与项目代码一起版本控制:

1
2
3
tender-info/
└── .claude/
└── settings.local.json
1
2
3
4
5
6
7
8
9
{
"permissions": {
"allow": [
"Bash(uv sync *)",
"Bash(uv venv *)",
"Bash(git -C /Volumes/hai/code/tender-info log --oneline -5)"
]
}
}

项目配置文件的作用是记录该项目额外允许的 Shell 命令权限,避免每次操作都弹出权限提示。


四、项目记忆层

严格按项目路径隔离的记忆系统,存放项目相关的持久上下文:

1
2
3
~/.claude/projects/-Volumes-hai-code-tender-info/memory/
├── MEMORY.md
└── python-dependency-management.md

4.1 记忆文件类型

类型 用途 关键字段
user 用户角色、偏好、工作方式 name, description, type, originSessionId
feedback 指导规则(什么该做/不该做) Why:How to apply:
project 项目状态、目标、截止日期 Why:How to apply:
reference 外部系统指针(Linear、Grafana 等) 链接 + 用途说明

4.2 记忆格式

每条记忆为独立 Markdown 文件,含 frontmatter:

1
2
3
4
5
6
7
8
9
10
11
12
---
name: python-dependency-management
description: 用户级Python依赖管理原则
type: user
originSessionId: 46dcfe60-6dcb-4824-850e-41e8ccc11b8f
---

## 具体内容

用户使用 **uv** 管理 Python 项目:
1. uv sync:主要命令
2. uv run:直接运行脚本

MEMORY.md 作为索引文件,每次会话自动加载;具体记忆文件在上下文相关时自动应用。


五、remember 插件 — 会话交接机制

remember 插件是记忆系统的补充机制,解决「跨时间连续性」问题。

5.1 与 memory/ 的区别

维度 memory/ 记忆系统 remember 插件
位置 ~/.claude/projects/<path>/memory/ {project}/.remember/remember.md
内容 项目偏好、规则、约定 会话交接、进度、下一步
触发 自动加载 手动调用 /remember
生命周期 跨会话持久 下次会话后可能被覆盖
语义 「这个项目是什么样的」 「上次我做到哪了」

5.2 文件格式

1
2
3
4
5
6
7
8
9
10
# Handoff

## State
{已完成什么、未完成什么。文件、MR 号、决策。最多 2-4 行。}

## Next
{接下来要做什么。按优先级排列。1-3 项。}

## Context
{非显而易见的坑、阻碍、本次偏好。如无内容可省略。}

5.3 使用规则

规则 说明
总行数 < 20 简洁,避免长篇大论
具体 包含文件路径、MR 号、分支名
前瞻性 下一会话只关心「接下来干嘛」
无内容时 直接写 “No active work.”

六、三层关系全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
~/.claude/
├── settings.json ← 【全局】所有项目共享
│ ├── env (API key, 模型)
│ ├── permissions (允许的命令)
│ └── enabledPlugins

├── projects/ ← 【记忆】按项目路径隔离
│ └── -Volumes-hai-code-tender-info/
│ └── memory/
│ ├── MEMORY.md ← 索引
│ └── *.md ← 具体记忆

tender-info/ ← 【项目】
├── .claude/
│ └── settings.local.json ← 项目级权限
├── .remember/
│ └── remember.md ← 会话交接(remember 插件)
└── ...项目文件

七、设计思想

层次 解决的问题 关键词
全局配置 「所有项目通用」 权限、插件、模型
项目配置 「这个项目能做什么」 权限、钩子
项目记忆 「用户想要什么方式工作」 偏好、反馈、约定
remember 「上次做到哪了」 交接、进度、连续性

三层设计体现了关注点分离原则:全局配置、项目配置、项目记忆三者职责清晰不混淆。memory/remember 解决不同维度的问题——前者是「项目画像」,后者是「时间线快照」。

理解这四层的区别,就能理解为什么没有一个「跨项目全局记忆」——因为全局配置(settings.json)解决的是工具能力,而非项目上下文。

0%