• • 第一章：选择与启程
• • 第二章：桌面环境演进
• • [第三章：AI 基础设施](#第三章 ai-基础设施)
• • 第四章：系统优化与调优
• • 第五章：安全与监控
• • 第六章：开发工作流
• • 第七章：踩坑与修复
• • 第八章：反思与展望

第一章：选择与启程

1.1 为什么选择 ROG 幻 16

2022 年，当我决定换一台新笔记本时，选择并不多：我需要一台既能满足开发需求，又具有一定便携性的机器。市面上大多数"游戏本"过于笨重，而"轻薄本"的性能又难以胜任 AI 模型本地推理和多个 Docker 容器同时运行的场景。

ROG Zephyrus M16 GU603ZM 吸引我的地方在于它的平衡：

硬件配置清单：
- CPU: Intel Core i7-12700H (14 核：6 性能核 + 8 能效核)
- GPU: NVIDIA RTX 3060 Mobile (6GB GDDR6) + Intel Iris Xe 核显
- 内存：40GB DDR5 (16GB 板载 + 24GB SO-DIMM)
- 存储：Micron 3400 512GB NVMe (主盘) + Great Wall GT70 2TB NVMe (副盘)
- 屏幕：16 英寸 2560x1600 165Hz IPS
- 重量：1.9kg (对于 16 英寸机器来说可以接受)

这台机器的硬件设计哲学与我后来的系统部署理念不谋而合：平衡性能与功耗，在需要时释放性能，在安静时保持低调。

1.2 为什么选择 CachyOS 而非其他发行版

选择 Linux 发行版本来就像选择生活方式。我经历过：

• • Ubuntu: 新手友好但过于"保姆化"
• • Fedora: 新但不稳定，半年一升级太频繁
• • Manjaro: AUR 访问方便但更新策略保守
• • 纯 Arch: 完全可控但安装过程太耗时

最终选择 CachyOS 基于以下几个关键因素：

1.2.1 性能优化

CachyOS 是针对桌面优化的 Arch 衍生版，使用针对 Zen 架构优化的内核（虽然我的 Intel CPU 无法完全受益，但调度器优化对所有 CPU 都有帮助）：

# 内核信息
$ uname -r
6.19.6-2-cachyos

# CachyOS 内核特性
- BORE 调度器 (Better Optimized Response for Enhanced interactivity)
- Fsync 支持 (改善游戏性能)
- 预编译优化包 (针对 x86-64-v3/v4 优化)

1.2.2 Arch 的灵活性 + 开箱即用

CachyOS 保留了 Arch 的所有优点：

• • AUR 访问: 可以使用 paru 访问 Arch User Repository
• • 滚动更新: 始终保持最新软件版本
• • Wiki 资源: Arch Wiki 是 Linux 世界最完善的文档

同时提供了开箱即用的体验：

• • 预配置的内核和引导
• • 图形化安装器
• • 预装常用驱动（包括 NVIDIA）

1.2.3 安装过程记录

安装日期大约是 2026 年 3月初。安装过程相对顺利：

# 安装后验证
$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot
├─nvme0n1p2 259:2    0    16M  0 part
└─nvme0n1p3 259:3    0 475.9G  0 part /

nvme1n1     259:4    0   1.8T  0 disk
└─nvme1n1p1 259:5    0   1.8T  0 part /data

1.3 "从零开始"的哲学

我坚持一个原则：配置文件与数据分离，代码与配置分离。

这直接影响了我的目录结构设计：

用户目录 (~)
├── dotfiles/          # 配置文件模板（可迁移）
│   ├── .config/       # 应用配置模板
│   ├── .local/        # 本地数据模板
│   └── docs/          # 架构文档
├── src/               # 所有源代码项目
├── projects/          # 工作项目容器
├── data/              # 数据文件
└── backups/           # 临时备份

设计原则：

• • 配置与代码分离: dotfiles/ 只放配置模板，src/ 只放代码
• • 迁移友好: 换机器时只需同步 dotfiles/ 和 src/
• • 临时数据可丢弃: backups/ 和 cache/ 可随时清理

这个设计在后来的系统重构中被证明是明智的。2026 年 3 月 15 日，我完成了一次完整的重构，将用户目录根部的 20+ 个项目散落目录整理到 ~/src/ 下，使用户目录根部只剩下 5 个核心目录。

1.4 初始系统状态

安装完成后的初始系统状态：

# 已安装包数量
$ pacman -Q | wc -l
1403

# 系统服务状态（关键服务）
$ systemctl list-units --type=service --state=running
asusd.service         - ASUS Notebook Control
opensnitchd.service   - Application firewall OpenSnitch
ollama.service        - Ollama (本地 AI 模型)
clash-verge-service   - Clash Verge (代理)
tailscaled.service    - Tailscale (组网)
zerotier-one.service  - ZeroTier (组网)
nvidia-powerd.service - NVIDIA 电源管理
supergfxd.service     - 显卡切换管理
kanata.service        - 键盘改键
ananicy-cpp.service   - 进程调度优化

这个初始状态标志着一个完整系统的起点。接下来的几个月里，这个系统会经历无数次的调整、优化、踩坑和修复，最终成为一个高度个性化、高度自动化的开发环境。

第二章：桌面环境演进

2.1 从 i3/Sway 到 Hyprland 的心路历程

我的 Wayland 之旅并非一蹴而就。在来到 Hyprland 之前，我经历了：

2.1.1 i3-wm 时期

i3 是我的第一个平铺窗口管理器。它的简单直接让我着迷：

# i3 配置示例（怀念一下）
bindsym $mod+Return exec i3-sensible-terminal
bindsym $mod+d exec rofi -show drun

但 i3 的限制也很明显：

• • 没有动画，切换窗口生硬
• • 多显示器支持有限
• • 触摸板手势几乎为零

2.1.2 Sway 过渡期

Sway 作为 i3 的 Wayland 实现，提供了更好的多显示器支持和触摸板手势。但我始终觉得缺少什么——视觉反馈和流畅感。

2.1.3 遇见 Hyprland

Hyprland 的出现改变了一切。它是一个动态平铺 Wayland 合成器，特点是：

• • 流畅的动画: 窗口打开/关闭/切换都有丝滑动画
• • 动态布局: 支持 dwindle 和 master 两种布局
• • 高度可定制: 几乎所有行为都可配置
• • 触摸板手势: 原生支持三指、四指手势

2.2 Hyprland 配置架构

我的 Hyprland 配置基于 JaKooLit/Hyprland-Dots 模板，但进行了大量定制。配置加载顺序如下：

hyprland.conf
├── configs/Keybinds.conf          # 默认键位绑定
├── configs/Startup_Apps.conf      # 启动应用（默认）
├── UserConfigs/Startup_Apps.conf  # 启动应用（用户自定义）
├── configs/ENVariables.conf       # 环境变量（默认）
├── UserConfigs/ENVariables.conf   # 环境变量（用户）
├── configs/Laptops.conf           # 笔记本配置（默认）
├── UserConfigs/Laptops.conf       # 笔记本配置（用户）
├── UserConfigs/LaptopDisplay.conf # 显示器配置
├── configs/WindowRules.conf       # 窗口规则（默认）
├── UserConfigs/WindowRules.conf   # 窗口规则（用户）
├── configs/SystemSettings.conf    # 系统设置（默认）
├── UserConfigs/UserDecorations.conf # 装饰配置
├── UserConfigs/UserAnimations.conf  # 动画配置
├── UserConfigs/UserKeybinds.conf    # 快捷键配置
├── UserConfigs/UserSettings.conf    # 主设置覆盖
└── UserConfigs/01-UserDefaults.conf # 默认应用

关键设计原则：自定义内容全部放在 UserConfigs/ 目录，这样在更新上游配置时不会被覆盖。

2.3 键位设计哲学

键位设计是桌面环境的核心。我的设计基于以下原则：

2.3.1 Alt/Super 交换

我通过 keyd 实现了物理 Alt 键和 Windows 键的功能交换：

# /etc/keyd/default.conf
[ids]
*

[main]
# 物理 Alt 键 → 逻辑 Super
leftalt = super
# 物理 Windows 键 → 逻辑 Alt
leftmeta = alt

这样做的好处是：

• • 小拇指更容易按到 Alt（现在在原来的 Alt 位置）
• • 更符合人体工学
• • 与 Windows/Mac 的使用习惯保持一致

2.3.2 CapsLock 优化

CapsLock 是键盘上最浪费的键之一。我通过 evremap 将它改造成多功能键：

# /etc/evremap.toml
[[remap]]
dev_name = "AT Translated Set 2 keyboard"
map = "CapsLock:layer_toggled(ctrlspace)"

[layer.ctrlspace]
press = "KEY_LEFTCTRL"
hold = "KEY_CAPSLOCK"
tap = "KEY_LEFTCTRL + KEY_SPACE"# 切换输入法

功能：

• • 短按 (<200ms): 发送 Ctrl+Space，切换输入法
• • 长按 (>=200ms): 作为 CapsLock 使用

2.3.3 核心快捷键

# ~/.config/hypr/UserConfigs/UserKeybinds.conf

# 主修饰键 (ALT)
$mainMod = ALT

# 终端绑定 - 使用 tmux-workspace
bindd = $mainMod, Return, tmux terminal, exec, /home/throokie/.local/bin/tmux-workspace launch

# 复制/粘贴 (Alt+C/V) - 覆盖默认行为
bind = ALT, C, exec, $scriptsDir/AltCV.sh C
bind = ALT, V, exec, $scriptsDir/AltCV.sh V

# 截图菜单 (Win+Shift+S - 与 Windows 一致)
bind = SUPER SHIFT, S, exec, /home/throokie/.config/hypr/scripts/screenshot-menu.sh

# 语音助手 (Alt+`)
bindl = ALT, grave, exec, $UserScripts/VoiceAssistant.sh toggle

# 重载配置 (Alt+Win+R)
bindd = SUPER ALT, R, refresh bar and menus, exec, $scriptsDir/Refresh.sh

# 特殊工作区手势
# 三指上滑：将当前窗口移入特殊工作区并显示
# 三指下滑：隐藏特殊工作区

2.4 触摸板手势优化

触摸板手势是 Hyprland 的亮点之一，但默认参数需要调整：

# ~/.config/hypr/UserConfigs/UserSettings.conf

gestures {
# 三指水平滑动切换工作区（优化参数）
workspace_swipe_distance = 700# 增加距离：500 → 700
workspace_swipe_invert = true
workspace_swipe_min_speed_to_force = 40# 提高速度阈值：30 → 40
workspace_swipe_cancel_ratio = 0.3# 降低取消比例：0.5 → 0.3
workspace_swipe_create_new = true
workspace_swipe_forever = false# 关闭无限循环
}

问题背景：

• • 默认参数下，轻微滑动就会切换工作区
• • “无限循环"模式导致窗口"滑过头”
• • 取消比例过高，难以中断切换

优化效果：

• • 需要更明确的滑动手势才会触发
• • 可以在滑动过程中轻松取消
• • 不会"滑过头"

2.5 特殊工作区设计

特殊工作区（Special Workspace）是一个类似"下拉终端"的浮动空间：

# 特殊工作区背景颜色
workspace = special:special, bg-color:rgb(1a1a1a)

# 三指手势绑定
bindr = SUPER SHIFT, mouse_up, exec, hyprctl dispatch movetoworkspacesilent special
bindr = SUPER SHIFT, mouse_down, exec, hyprctl dispatch movetoworkspacesilent special

使用场景：

• • 临时放置不需要一直显示的窗口
• • 快速访问的参考文档
• • 临时终端会话

2.6 配置迭代记录

通过 git 历史可以看到配置的持续演进：

$ git log --oneline | head -20

6ddaaa8 docs: 添加 ROG M16 卡死问题修复配置备份
c7c970e fix(waybar): 修复温度显示并添加 GPU 温度监控
25f7b9d fix: 修复 togglespecialworkspace 配置错误
17601f4 fix: 使用 exec 调用 togglespecialworkspace
a83a1d7 fix: togglespecialworkspace 不需要参数
284bfcd fix: UserKeybinds.conf 特殊工作区绑定缺少描述字段
59e1bdd fix: 使用 Hyprland 0.54+ 的 togglespecialworkspace 语法
36998eb fix: 移除 togglespecialworkspace 的 special 参数
f3320fb fix: 修复 UserKeybinds.conf 第 75 行无效 dispatcher 错误
0765629 fix: 删除 Hyprland 0.54+ 不支持的 windowrule
ea58fdc fix: 恢复 windowrulev2 语法
ed5b04b feat: 添加 kanata CapsLock 长短按配置
8a8bfc1 fix: 移除 caps:none 设置，evremap 接管 CapsLock

每一次提交都代表一次问题解决或功能优化。这种持续迭代的过程，是打造完美桌面环境的关键。

第三章：AI 基础设施

3.1 OpenClaw 项目的诞生

OpenClaw 是一个 AI 网关项目，用于管理多个 AI 模型的访问和路由。它的诞生源于一个简单需求：统一管理不同 AI 服务的 API Key 和调用配额。

3.1.1 核心架构

OpenClaw 架构
├── Gateway Service      # 统一 API 网关
├── Model Router         # 模型路由（基于请求类型）
├── Quota Manager        # 配额管理
├── Channel Manager      # 渠道管理（不同 API 提供商）
└── Admin UI             # 管理界面

3.1.2 系统配置

# /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw AI Gateway
After=network.target

[Service]
Type=simple
User=openclaw
Group=openclaw
Environment="WAYLAND_DISPLAY=wayland-0"
Environment="XDG_RUNTIME_DIR=/run/user/1000"
ExecStart=/home/openclaw/.openclaw/openclaw
Restart=always
CPUQuota=50%  # 限制 CPU 使用率（卡死问题修复）

[Install]
WantedBy=multi-user.target

重要：服务以独立用户 openclaw 运行，与主用户隔离，提高安全性。

3.2 Claude Skills 生态系统

Skills 是 Claude Code 的核心扩展机制。我开发了 70+ 个 Skills，涵盖以下领域：

3.2.1 核心技能分类

3.2.2 AI Drive 框架

AI Drive 是我最得意的作品，它是一个 AI 自主开发驱动框架：

AI Drive 工作流（Phase 0-5）

Phase 0: 需求澄清（必须）
  - 明确用户需求
  - 定义 MVP 范围
  - 确定成功标准

Phase 1: 设计先行
  - 架构设计
  - 接口定义
  - 数据模型

Phase 2-N: 迭代开发
  - 多 Agent 并行开发
  - 每轮汇报进度
  - 时间盒推进

Phase Final: 闭环验收
  - E2E 测试
  - 文档完善
  - 交付验收

关键特性：

• • 强制 2-3 个 Agent 并行开发
• • 每轮汇报各 Agent 进度和剩余时间
• • 防卡死协议（3 次失败降级）
• • Git 存档每轮自动执行

3.2.3 Skill 目录结构

~/.claude/skills/
├── ai-drive/                    # AI 自主开发驱动（主框架）
├── long-running-agent/          # 长周期任务管理
├── orchestrator/                # 多 Agent 协作编排
├── efficiency-workflow/         # 高效工作流
├── model-compare-search/        # 模型对比搜索
├── web-fetch/                   # 网页抓取
├── code-review/                 # 代码审查
└── ...                          # 60+ 其他技能

3.3 LiteLLM 模型路由

我使用 LiteLLM 作为模型路由层，实现统一的 API 接口：

# LiteLLM 配置示例
model_list:
-model_name:"gpt-4"
litellm_params:
model:"openai/gpt-4"
api_key:"os.environ/OPENAI_API_KEY"

-model_name:"claude-3"
litellm_params:
model:"anthropic/claude-3"
api_key:"os.environ/ANTHROPIC_API_KEY"

-model_name:"kimi"
litellm_params:
model:"moonshot/moonshot-v1"
api_key:"os.environ/KIMI_API_KEY"
# Kimi 专长：262K 上下文、视频理解

路由策略：

• • 快速搜索 → tavily-search
• • 语义搜索 → exa-search
• • 长文档分析 → kimi (262K 上下文)
• • 视频理解 → kimi
• • 代码生成 → claude-3/gpt-4

3.4 多 Agent 协作系统

多 Agent 协作是我的 AI 基础设施的核心。系统设计基于 Anthropic 的工程团队架构：

Lead-Worker 模式

Lead Agent (主代理)
├── 负责任务分解
├── 分配子任务给 Worker
├── 汇总结果
└── 质量审查

Worker Agent 1 (研究)
├── 网络搜索
├── 资料整理
└── 信息汇总

Worker Agent 2 (编码)
├── 代码实现
├── 单元测试
└── 文档编写

Worker Agent 3 (测试)
├── E2E 测试
├── Bug 报告
└── 性能测试

3.4.1 创建团队示例

# 使用 orchestrator skill 创建团队
/orchestrator create-team --name "feature-dev" \
  --lead "main-agent" \
  --workers "research-agent,coding-agent,test-agent"

3.5 AI Drive 框架的融合

2026 年 3 月 18 日，我完成了一次重要的技能融合：

融合前（6 个独立技能）:

• • product-builder - 产品级构建框架
• • time-boxing - 时间盒管理
• • e2e-optimizer - E2E 测试优化
• • git-worktree - Git 并行开发
• • deep-work-tracker - 深度工作追踪
• • long-running-agent - 多 Agent 管理

融合后（2 个技能）:

• • ai-drive - 主框架（融合 4 个技能）
• • long-running-agent - 依赖工具（独立）

效果对比：

这次融合的核心洞察是：Claude 无法同时内化 6 套不同的工作流。精简后的单一框架更容易被 AI 理解和执行。

第四章：系统优化与调优

4.1 风扇曲线与散热管理

ROG M16 的散热问题是出了名的。原装的风扇曲线过于保守，导致 CPU 温度经常在 70°C 以上徘徊，而风扇却迟迟不加速。

4.1.1 问题分析

通过 asusctl 工具查看默认风扇曲线：

$ asusctl profile
Current Profile: Balanced

默认 Quiet 模式的问题：

• • 50°C 以下：风扇几乎不转（PWM 0-10%）
• • 50-60°C：风扇缓慢加速
• • 70°C 以上：风扇全速（但此时温度已经很高）

4.1.2 风扇曲线修改

我修改了 Quiet 模式的风扇曲线，让它更早介入散热：

# /etc/asusd/fan_curves.ron
quiet: [
    (
        fan: CPU,
        pwm: (20, 51, 82, 123, 164, 205, 235, 255),
        temp: (40, 50, 55, 60, 65, 70, 75, 80),
        enabled: true,
    ),
    (
        fan: GPU,
        pwm: (20, 51, 82, 123, 164, 205, 235, 255),
        temp: (35, 45, 55, 60, 65, 70, 75, 80),
        enabled: true,
    ),
]

曲线解读：

4.1.3 应用配置

# 备份原配置
sudocp /etc/asusd/fan_curves.ron ~/backups/fan_curves.ron.bak

# 恢复新配置
sudocp fan_curves.ron /etc/asusd/
sudo systemctl restart asusd

# 验证
asusctl curve

4.2 CPU 功耗限制策略

ROG M16 的另一个问题是 CPU 功耗限制过于宽松，导致短时间内功耗飙升到 80W+，然后撞温度墙降频。

4.2.1 功耗配置

通过 asusd 配置 CPU 功耗限制：

# /etc/asusd/asusd.ron
ac_profile_tunings: {
    Quiet: (
        enabled: true,
        group: {
            PptPl1Spl: 30,    // PL1 (长时功耗限制): 30W
            PptPl2Sppt: 55,   // PL2 (短时功耗限制): 55W
            NvDynamicBoost: 7, // NVIDIA 动态加速
            NvTempTarget: 82,  // GPU 温度目标
        },
    ),
}

效果：

• • PL1 30W：保证长时间稳定运行
• • PL2 55W：允许短时间爆发性能
• • GPU 82°C：防止 GPU 过热

4.2.2 性能模式切换

# 查看当前模式
asusctl profile

# 切换模式
asusctl profile --set Quiet      # 安静模式（日常使用）
asusctl profile --set Balanced   # 平衡模式
asusctl profile --set Performance # 性能模式（高负载任务）

4.3 内存与 Swap 优化（ZRAM）

40GB 内存虽然充足，但合理使用 Swap 可以提高系统响应性。

4.3.1 ZRAM 配置

ZRAM 是在内存中创建的压缩块设备，比传统 Swap 快得多：

# 安装 zram-generator
paru -S zram-generator

# 配置 /etc/systemd/zram-generator.conf
[zram0]
zram-size = min(ram / 4, 16384)  # 内存的 1/4，最大 16GB
compression-algorithm = zstd
swap-priority = 100

优势：

• • 压缩存储，实际可用 Swap 比配置大 2-3 倍
• • 速度远快于磁盘 Swap
• • 减少 SSD 写入磨损

4.3.2 验证 ZRAM

$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL MEM-LIMIT
/dev/zram0 zstd         10G     1G   256M  260M     40G

4.4 进程调度优化（ananicy-cpp）

ananicy-cpp 是一个自动调整进程 nice 值的守护进程，它根据预定义规则优化进程优先级。

4.4.1 服务状态

$ systemctl status ananicy-cpp
● ananicy-cpp.service - Ananicy-Cpp - ANother Auto NICe daemon in C++
  Loaded: loaded (/usr/lib/systemd/system/ananicy-cpp.service; enabled)
  Active: active (running)

4.4.2 工作原理

ananicy-cpp 监控进程行为，自动调整：

• • 前台应用: 提高优先级（nice 值降低）
• • 后台任务: 降低优先级（nice 值升高）
• • IO 密集型: 调整 IO 优先级
• • CPU 密集型: 限制 CPU 时间

4.4.3 自定义规则

// /etc/ananicy-cpp/rules.d/custom.json
[
{
"name":"chrome",
"nice":-5,
"io_nice":1,
"type":"desktop"
},
{
"name":"ollama",
"nice":5,
"io_nice":3,
"type":"background"
}
]

4.5 显卡切换配置

ROG M16 有双显卡（Intel Iris Xe + NVIDIA RTX 3060），显卡切换由 supergfxctl 管理。

4.5.1 显卡模式

# 查看当前模式
supergfxctl -g

# 切换模式
sudo supergfxctl --mode Hybrid   # 混合模式（自动切换）
sudo supergfxctl --mode dGPU     # 独显模式（性能最好）
sudo supergfxctl --mode iGPU     # 核显模式（省电）

4.5.2 服务配置

$ systemctl status supergfxd
● supergfxd.service - SUPERGFX
  Loaded: loaded (/usr/lib/systemd/system/supergfxd.service; enabled)
  Active: active (running)

4.5.3 NVIDIA 电源管理

$ systemctl status nvidia-powerd
● nvidia-powerd.service - nvidia-powerd service
  Loaded: loaded (/usr/lib/systemd/system/nvidia-powerd.service; enabled)
  Active: active (running)

nvidia-powerd 动态调整 NVIDIA GPU 的功耗和频率，在性能和功耗之间取得平衡。

第五章：安全与监控

5.1 OpenSnitch 应用层防火墙

OpenSnitch 是 Linux 应用层防火墙，用于监控和控制应用程序的网络连接。

5.1.1 架构组成

5.1.2 配置详情

// /etc/opensnitchd/default-config.json
{
"DefaultAction":"allow",
"DefaultDuration":"always",
"InterceptUnknown":false,
"Firewall":"nftables",
"LogLevel":2
}

DefaultAction 说明：

• • deny: 拒绝每个新连接，弹窗询问（保护模式）
• • allow: 允许所有新连接，不弹窗（开发模式）

5.1.3 Waybar 集成

我开发了一个脚本将 OpenSnitch 状态集成到 Waybar：

// ~/.config/waybar/modules/custom/default.json
"custom/opensnitch":{
"return-type":"json",
"exec":"$HOME/.local/bin/waybar-opensnitch status",
"interval":5,
"format":"{}",
"escape":false,
"on-click":"$HOME/.local/bin/waybar-opensnitch toggle",
"tooltip":true
}

状态图标：

5.1.4 开发模式

# 切换开发模式
sudo /home/throokie/.local/bin/opensnitch-dev-mode.sh toggle

# 开发模式开启
sudo /home/throokie/.local/bin/opensnitch-dev-mode.sh on

# 开发模式关闭
sudo /home/throokie/.local/bin/opensnitch-dev-mode.sh off

5.2 网络隔离（Tailscale/ZeroTier）

我同时运行 Tailscale 和 ZeroTier 两个组网工具，用于不同的使用场景。

5.2.1 Tailscale

$ systemctl status tailscaled
● tailscaled.service - Tailscale node agent
  Loaded: loaded (/usr/lib/systemd/system/tailscaled.service; enabled)
  Active: active (running)

用途：

• • 访问家庭服务器
• • 跨设备文件同步
• • 安全 SSH 访问

5.2.2 ZeroTier

$ systemctl status zerotier-one
● zerotier-one.service - ZeroTier One
  Loaded: loaded (/usr/lib/systemd/system/zerotier-one.service; enabled)
  Active: active (running)

用途：

• • 访问公司内网资源
• • 特定项目的开发网络
• • 与 Tailscale 形成冗余

5.3 摄像头监控系统

我开发了一个摄像头监控系统，当有应用访问摄像头时自动通知。

5.3.1 服务状态

$ systemctl --user status camera-monitor
● camera-monitor.service - Camera Access Monitor
  Loaded: loaded
  Active: active (running)

5.3.2 工作原理

监控系统通过 inotify 监控摄像头设备文件 (/dev/video0)，当有进程打开设备时：

1. 1. 记录访问时间和进程名
2. 2. 发送桌面通知
3. 3. 记录到日志文件

5.4 健康提醒系统

长时间工作时，健康提醒系统会定时提醒喝水和休息。

5.4.1 服务配置

# ~/.config/systemd/user/health-reminder.service
[Unit]
Description=Health reminder

[Service]
Type=simple
ExecStart=/home/throokie/.local/bin/health-reminder
Restart=always

5.4.2 提醒策略

5.5 备份策略

备份是系统安全的重要组成部分。

5.5.1 备份目录结构

~/backups/
├── dotfiles-backup-*/         # dotfiles 备份
├── openclaw-home-backup-*/    # OpenClaw 数据备份
├── firefox-native-backup-*.tar.gz  # 浏览器备份
├── chromium-native-backup-*.tar.gz # 浏览器备份
├── ai-projects-backup-*/      # AI 项目备份
└── system-configs-*/          # 系统配置备份

5.5.2 自动备份脚本

#!/bin/bash
# ~/.local/bin/auto-backup-dotfiles

DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=~/backups/dotfiles-backup-$DATE

# 创建备份
mkdir -p $BACKUP_DIR
rsync -av ~/dotfiles/ $BACKUP_DIR/

# 保留最近 7 个备份
ls -dt ~/backups/dotfiles-backup-* | tail -n +8 | xargs rm -rf

5.5.3 备份原则

• • 配置文件: 每次重大修改后备份
• • 浏览器数据: 每周自动备份
• • 系统配置: 修复问题前后备份
• • 项目代码: Git 版本控制，不依赖备份

第六章：开发工作流

6.1 目录结构规范

我的目录结构遵循严格规范，确保配置与数据分离、代码与配置分离。

6.1.1 核心目录

6.1.2 src/ 详细结构

src/
├── user-scripts/       # Claude Code 脚本和 Skills
├── my-scripts/         # 系统管理脚本
├── ai-projects/        # AI 项目（OmniParser, site-analysis 等）
├── ai-team/            # AI 团队编排服务
├── agents/             # Agent 配置和 prompts
├── content-factory/    # 内容创作工具
├── deployments/        # 部署配置
├── dev-projects/       # 开发项目（Go, 源代码，测试）
├── tools/              # 工具脚本 (70+ Skills)
├── docs/               # 技术文档
└── tianjige/           # 命理开发项目

6.2 Git 工作流

6.2.1 提交规范

我使用约定式提交（Conventional Commits）：

类型：描述

详细说明（可选）

类型说明：

• • feat: 新功能
• • fix: Bug 修复
• • docs: 文档更新
• • style: 代码格式
• • refactor: 重构
• • test: 测试
• • chore: 构建/工具

示例：

feat: 添加电池阈值 Waybar 模块
fix(waybar): 修复温度显示传感器错误
docs: 添加 ROG M16 卡死问题修复配置备份

6.2.2 分支策略

main          # 主分支，始终可部署
├── feature/*  # 功能分支
├── fix/*      # 修复分支
└── hotfix/*   # 热修复分支

6.3 Claude Code 集成

Claude Code 是我的主要开发助手。我通过 Hooks 系统深度集成 Claude 到我的工作流中。

6.3.1 Hook 配置

// ~/.claude/settings.json
{
"hooks":{
"UserPromptSubmit":[
{
"matcher":"*",
"hooks":[
{
"type":"command",
"command":"fish ~/.claude/hooks/post-message.sh",
"timeout":5,
"async":true
}
]
}
],
"PreToolUse":[
{
"matcher":"Write",
"hooks":[
{
"type":"command",
"command":"fish ~/.claude/hooks/pre-write.sh",
"timeout":3
}
]
}
],
"PostToolUse":[
{
"matcher":"Write|Edit",
"hooks":[
{
"type":"command",
"command":"fish ~/.claude/hooks/knowledge-manager.sh",
"timeout":5,
"async":true
}
]
}
]
}
}

6.3.2 知识捕获

通过 Hook 系统，Claude 的所有操作都会自动记录到知识库：

#!/usr/bin/env fish
# ~/.claude/hooks/knowledge-manager.sh

set -l input "$CLAUDE_HOOK_INPUT"

# 检测是否是知识性内容
if string match -q "*原理*" "$input"
    # 保存到知识库
    echo "$input" >> ~/.claude/insights/knowledge-base.md
end

6.4 MCP 工具生态

MCP (Model Context Protocol) 是我扩展 Claude 能力的核心机制。

6.4.1 MCP 服务器列表

6.4.2 自动触发规则

// ~/.claude/config.json
{
"_auto_trigger":{
"context7":["查文档","API 怎么写","xxx 库怎么用"],
"sequential-thinking":["逐步分析","详细推理"],
"github":["GitHub","PR","issue","commit"],
"chrome-devtools":["浏览器","截图网页"],
"filesystem":["读取文件","写入文件"],
"tavily-search":["搜索","查一下"]
}
}

6.5 技能自动触发机制

Skills 是 Claude Code 的自定义扩展。我开发了技能自动触发机制，当用户输入包含特定触发词时，自动加载对应技能。

6.5.1 触发规则

6.5.2 实现原理

技能触发通过 CLAUDE.md 中的规则定义：

## 🤖 Skill 自动触发

### 高效工作流
| 用户输入 | 调用命令 |
|----------|----------|
| "代码审查"、"review 代码" | `main.mjs review` |
| "提交代码"、"commit push" | `main.mjs commit` |

第七章：踩坑与修复

7.1 ROG M16 卡死问题全记录

2026 年 3 月 20 日，我遇到了严重的系统卡死问题。以下是完整的问题分析和修复过程。

7.1.1 问题现象

• • 系统间歇性卡死，鼠标可以移动但窗口无响应
• • Waybar 显示温度一直在 60-70°C 徘徊
• • openclaw-gateway 服务 CPU 占用率高达 160%

7.1.2 问题分析

通过日志分析，发现问题根源：

# 检查服务状态
$ sudo journalctl -u openclaw-gateway | grep -i error
Error: CPU usage exceeded threshold

# 检查温度传感器
$ sensors | grep -E "Tdie|Package"
Tdie:  +65.0°C  # CPU 温度

问题链条：

1. 1. Quiet 模式风扇曲线太保守，70°C 以下风扇几乎不转
2. 2. Waybar 显示的是主板温度（hwmon1）而非 CPU 温度（hwmon9），误导用户
3. 3. openclaw-gateway 占用 160% CPU，导致持续高负载
4. 4. 热量积累导致系统卡死

7.1.3 修复方案

修复 1: 风扇曲线调整

# /etc/asusd/fan_curves.ron
quiet: [
    (
        fan: CPU,
        pwm: (20, 51, 82, 123, 164, 205, 235, 255),
        temp: (40, 50, 55, 60, 65, 70, 75, 80),
        enabled: true,
    ),
]

修复 2: CPU 功耗限制

# /etc/asusd/asusd.ron
ac_profile_tunings: {
    Quiet: (
        enabled: true,
        group: {
            PptPl1Spl: 30,    // PL1: 30W
            PptPl2Sppt: 55,   // PL2: 55W
        },
    ),
}

修复 3: openclaw-gateway CPU 限制

# /etc/systemd/system/openclaw.service
[Service]
CPUQuota=50%  # 限制最多 50% CPU

修复 4: Waybar 温度显示

// ~/.config/waybar/Modules
"temperature":{
"hwmon-path":"/sys/class/hwmon/hwmon9/temp1_input",// CPU coretemp
"interval":3,// 10s → 3s
"critical-temperature":95// 82°C → 95°C
}

7.1.4 配置备份

修复后，我备份了所有系统配置以便将来参考：

# 备份位置
~/.backup/system-configs/20260320/
├── fan_curves.ron        # 风扇曲线
├── asusd.ron             # ROG 管家配置
└── openclaw.service      # systemd 服务

7.2 ACPI 固件 Bug 应对

ROG M16 的 BIOS 存在一些 ACPI 固件 Bug，导致某些功能异常。

7.2.1 问题现象

• • 合盖睡眠偶尔无法唤醒
• • 电池充电阈值设置不生效
• • 风扇控制偶尔失效

7.2.2 应对方案

方案 1: 内核参数调整

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_enforce_resources=lax"

方案 2: BIOS 更新

# 当前 BIOS 版本
$ sudo dmidecode -t bios
Version: GU603ZM.311
Date: 12/22/2022

7.3 Waybar 温度显示误导

这是一个典型的"显示正确但信息误导"问题。

7.3.1 问题发现

Waybar 一直显示 45-50°C，但机器明显很热。通过对比发现：

# Waybar 读取的温度
$ cat /sys/class/hwmon/hwmon1/temp1_input
45000  # 45°C (主板温度)

# 实际 CPU 温度
$ cat /sys/class/hwmon/hwmon9/temp1_input
72000  # 72°C (CPU 温度)

7.3.2 修复

// ~/.config/waybar/Modules
"temperature":{
"hwmon-path":"/sys/class/hwmon/hwmon9/temp1_input"
}

同时添加 GPU 温度显示：

"custom/gpu_temp":{
"exec":"nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits",
"interval":5,
"format":" {}°C"
}

7.4 Hyprland 配置兼容性

Hyprland 更新频繁，配置语法经常变化。

7.4.1 典型问题

问题 1: togglespecialworkspace 语法变化

# Hyprland 0.54+ 新语法
bind = SUPER, S, exec, hyprctl dispatch togglespecialworkspace

# 旧语法（已废弃）
bind = SUPER, S, togglespecialworkspace, special

问题 2: windowrulev2 语法

# 正确语法
windowrulev2: float, class:(copyq)

# 错误语法（已废弃）
windowrule: float, copyq

7.4.2 解决策略

• • 订阅 Hyprland GitHub 仓库 Release
• • 每次更新后运行 hyprctl reload 检查错误
• • 配置中使用 UserConfigs/ 目录，便于快速修复

7.5 systemd 权限问题

systemd 服务配置是另一个踩坑重灾区。

7.5.1 EP-001: root 服务无用户环境变量

问题: 以 root 身份运行的服务需要访问用户会话功能

现象: Wayland 相关功能失败、输入法无法使用

解决方案:

# /etc/systemd/system/your-service.service
[Service]
Environment="WAYLAND_DISPLAY=wayland-0"
Environment="XDG_RUNTIME_DIR=/run/user/1000"

7.5.2 EP-006: OpenClaw 权限隔离

问题: 服务运行用户与配置目录所有者不匹配

服务运行用户：openclaw
配置目录所有者：throokie
结果：EACCES permission denied

解决方案:

sudochown -R openclaw:openclaw /home/openclaw/.openclaw/
sudo systemctl restart openclaw

第八章：反思与展望

8.1 哪些设计是过度工程

在回顾整个部署历程时，我发现有些设计确实是过度工程了。

8.1.1 过度工程案例

1. 多代理协作系统

我花了很多时间构建复杂的多 Agent 协作框架，但实际使用中：

• • 大多数任务单个 Claude 就能完成
• • 多 Agent 增加了复杂度和调试难度
• • Token 消耗大幅增加

反思：应该按需创建，而不是预先构建。

2. 70+ 个 Skills

技能数量过多导致：

• • Claude 难以全部内化
• • 维护成本高
• • 很多技能从未被使用

改进：已经通过 AI Drive 融合，将 6 个核心技能合并为 2 个。

3. 复杂的备份策略

我曾经有 5 层备份：

• • Git 版本控制
• • 每日自动备份
• • 每周完整备份
• • 每月离线备份
• • 云同步备份

反思：对于个人项目，Git + 每周备份足够了。

8.2 什么真正提升了效率

经过反思，以下设计真正提升了我的效率：

8.2.1 高效设计

1. 目录结构规范

配置与数据分离、代码与配置分离的原则：

• • 换机器时迁移成本极低
• • 配置文件版本可控
• • 问题排查更容易

2. Claude Hooks 集成

通过 Hooks 系统：

• • 所有操作自动记录
• • 知识自动捕获
• • 错误自动检测

3. 风扇曲线和功耗限制

这次修复带来的改善：

• • 系统不再卡死
• • 温度稳定在 60°C 以下
• • 风扇噪音可接受

4. MCP 工具自动触发

• • 减少手动切换工具的时间
• • 工具使用更一致
• • 错误更透明

8.3 AI 辅助开发的边界

经过数月与 Claude Code 的协作，我对 AI 辅助开发的边界有了清晰认识。

8.3.1 AI 擅长的

• • 代码生成: 根据明确需求生成代码
• • 代码审查: 发现潜在问题和改进点
• • 文档编写: 生成 API 文档和注释
• • 测试编写: 生成单元测试和 E2E 测试
• • 信息搜索: 快速查找文档和最佳实践

8.3.2 AI 不擅长的

• • 需求澄清: 需要人类明确表达
• • 架构决策: 需要人类做权衡
• • 质量验收: 需要人类最终把关
• • 创意工作: AI 只能重组已有知识
• • 人际沟通: 与团队成员协调

8.3.3 最佳协作模式

人类负责：
- 需求定义和优先级
- 架构决策和技术选型
- 质量验收和交付
- 人际沟通和协调

AI 负责：
- 代码实现
- 测试编写
- 文档生成
- 信息搜集

8.4 下一步优化方向

基于当前系统的运行状况，以下是我计划的优化方向：

8.4.1 短期优化（1 个月内）

1. 简化技能系统

继续精简 Skills，目标减少到 30 个以内：

• • 合并功能重叠的技能
• • 删除从未使用的技能
• • 优化核心技能文档

2. 优化 Waybar 模块

• • 添加电池健康度显示
• • 添加网络速度显示
• • 优化通知管理

3. 改善备份策略

• • 自动化备份验证
• • 增加增量备份
• • 减少备份占用空间

8.4.2 中期优化（3 个月内）

1. AI 工作流优化

• • 改进 AI Drive 框架
• • 优化多 Agent 协作效率
• • 减少 Token 消耗

2. 系统性能优化

• • 进一步优化风扇曲线
• • 探索 undervolt 可能性
• • 优化启动速度

3. 安全知识库建设

• • 记录所有安全配置
• • 建立安全事件响应流程
• • 定期安全审计

8.4.3 长期优化（6 个月内）

1. 系统重构准备

• • 评估 CachyOS 是否需要更换
• • 考虑 NixOS 的可能性
• • 探索完全声明式配置

2. 硬件升级

• • 考虑升级到 64GB 内存
• • 考虑外部存储方案
• • 考虑显示器升级

3. 知识沉淀

• • 将所有经验整理成文档
• • 建立个人知识库
• • 分享给社区

结语

从零开始部署一台 ROG M16，不仅是技术工作，更是一次自我发现的过程。每一次踩坑和修复，都是对系统和自我的更深理解。

这篇文章记录了从 2026 年 3 月初安装系统，到 3 月 20 日完成卡死问题修复的完整历程。它不是一份完美的指南，而是一份真实的记录——包括成功的喜悦，也包括踩坑的困惑。

如果你也从这篇文章中获得启发，或者有任何问题，欢迎交流。

最后更新: 2026-03-20版本: v1.0字数: 约 12,000 字

附录：关键配置文件索引

感谢阅读