1
2
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
    
      我在海光 DCU 上修改 vLLM kernel 时，最浪费时间的一次并不是编译报错。
那次编译正常结束，服务能够启动，接口也能返回结果，性能测试甚至给出了一个看起来可以解释的变化。后来重新核对运行环境，我才发现一个更麻烦的问题：源码、构建产物和服务实际加载的文件并不是同一套状态。此前围绕性能做出的判断，只能全部作废。
这件事改变了我的调试顺序。现在每次改完 ROCm kernel，我不会立刻看吞吐，而是先回答一个更基础的问题：
正在海光 DCU 上执行的，究竟是不是我刚刚修改、编译并准备测试的那份代码？
本文记录的是我在 gfx936 架构海光 DCU 上实际使用过的一套 vLLM 增量编译与运行时验真方法。重点不是介绍某个更快的算子，而是把从 .cu 源码到真实 kernel dispatch 之间容易藏住旧状态的环节逐一拆开。
实验环境
本文涉及的实测环境如下。后文的时间和二进制信息只对这套环境负责，不外推为其他 DCU、DTK 或 vLLM 版本的固定结果。
项目
实测环境
加速卡
海光 DCU，gfx936 架构，设备名显示为 BW
DTK
26.04 系列环境
Python
3.10
PyTorch
2.10.0
构建工具
CMake、Ninja、hipify、ccache 4.5.1
vLLM ROCm 扩展
vllm._rocm_C
在这份 vLLM 源码中，_rocm_C 由三个文件构成：
1
2
3
csrc/rocm/torch_bindings.cpp
csrc/rocm/skinny_gemms.cu
csrc/rocm/attention.cu
skinny_gemms.cu 和 attention.cu 会先经过 hipify，再由 DTK 的编译器面向 gfx936 生成目标代码，最后与算子注册代码一起链接为 _rocm_C.abi3.so。
一个 kernel 在运行前至少有六种“身份”
只看源码目录，很容易误以为修改已经生效。实际链路要长得多：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
skinny_gemms.cu
        |
        | hipify
        v
skinny_gemms.hip
        |
        | clang++ --offload-arch=gfx936
        v
cmake-build-rocm/_rocm_C.abi3.so
        |
        | cmake --install / 手工安装
        v
Python 环境中的 vllm/_rocm_C.abi3.so
        |
        | 服务进程加载
        v
/proc/<pid>/maps 中的已加载共享库
        |
        | shape、dtype、layout 等运行时条件
        v
本次请求实际选择的 kernel 分支
这里任何一层没有对齐，都会出现一种很危险的状态：程序能跑，但跑的不是你以为的实现。
因此，“编译成功”最多只能证明第三层生成了文件。它不能证明文件被安装到了当前 Python 环境，更不能证明已经启动的 vLLM 进程重新加载了它，最后也不能证明目标请求真的命中了新 dispatch。
我实际跑通的增量编译
在已有构建目录的前提下，我修改 csrc/rocm/skinny_gemms.cu 后使用的是下面两条命令：
1
2
cmake --build --preset rocm-release --target _rocm_C
cmake --install cmake-build-rocm --component _rocm_C
这套环境里有一个不太显眼的差异：仅放置 CMakeUserPresets.json 时，当前镜像的构建流程没有正确识别；换成实际使用的 CMakePresets.json 后才稳定工作。Preset 中至少要明确以下信息：
1
2
3
4
VLLM_TARGET_DEVICE=rocm
PYTORCH_ROCM_ARCH=gfx936
ROCM_PATH=/opt/dtk
CMAKE_HIP_COMPILER_LAUNCHER=ccache
一次真实的增量构建日志可以压缩为下面几行：
1
2
3
4
5
6
7
8
9
[1/4] ... hipify.py ... skinny_gemms.cu attention.cu
skinny_gemms.cu -> skinny_gemms.hip [ok]
attention.cu -> attention.hip [skipped, already hipified]
Successfully preprocessed all matching files.
Total number of unsupported CUDA function calls: 0
Total number of replaced kernel launches: 19

[2/3] clang++ ... --offload-arch=gfx936 ... skinny_gemms.hip
[3/3] ... -o _rocm_C.abi3.so
这几行比最后一句 build success 更有用。它们同时证明了四件事：
修改过的 .cu 被重新 hipify；
未修改的 attention.cu 没有被无意义地重新转换；
编译命令确实以 gfx936 为目标架构；
最终发生了共享库重链接。
同一次本地实验还记录了生成扩展的状态：
1
2
3
4
size: 21018624 bytes
sha256: 0e3280734c80bf7d33e101c04eecd9cdee0844feb3447b2141a3326ad6ef7549
torch: 2.10.0
LLMM1_registered: True
这个哈希只用于标识当时那一份二进制，并不代表其他正确构建也应该得到相同哈希。
共享目录会拖慢配置阶段
我还对比过同一套源码在两种位置执行 CMake configure 的时间：
构建位置
实测 configure 时间
共享目录
约 111 秒
容器本地 /root
13.5 秒
两者相差约 8.2 倍。这个结果并不说明 /root 在任何机器上都会快 8.2 倍，它说明的是：当源码树、CMake 探测和大量小文件操作都落在高延迟共享存储上时，配置阶段本身就可能成为迭代瓶颈。
我的做法是把临时源码 overlay 和 cmake-build-rocm 放在容器本地盘，编译完成后只把需要保存的日志、源码补丁和最终 .so 复制回持久化目录。这样既保留证据，也避免每次 configure 都在共享目录上重复做元数据访问。
四种“看起来成功”的失败状态
下面四种情况我都在实际调试中遇到过。它们之所以麻烦，是因为服务不一定报错。
1. import vllm 成功，但 ROCm 扩展并不存在
一次重新安装 wheel 后，Python 包恢复了，import vllm 也正常，但默认安装中没有 _rocm_C.abi3.so。如果只用 import vllm 验证环境，就会把“Python 包存在”误当成“自定义 ROCm 扩展已安装”。
更可靠的检查是直接导入扩展并确认目标算子完成注册：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
python3 - <<'PY'
import importlib.util
import os
import torch

spec = importlib.util.find_spec("vllm._rocm_C")
print("extension:", None if spec is None else spec.origin)
if spec is None:
    raise SystemExit("vllm._rocm_C is missing")

import vllm._rocm_C  # noqa: F401
op_name = os.environ.get("DCU_VERIFY_OP", "LLMM1")
print("registered:", op_name, hasattr(torch.ops._rocm_C, op_name))
PY
这里的 LLMM1 是我当时验证的算子名。换成其他工程时，应将 DCU_VERIFY_OP 设为自己真正需要测试的注册名。
2. wheel 重装后，只复制了当前修改的一个文件
另一轮实验中，重装 wheel 会把 site-packages 恢复为 wheel 默认状态。我当时只复制了眼前正在修改的 Python 文件，却漏掉了候选实现继承的其他已修改文件。服务仍能启动，benchmark 也能完成，但那不是完整候选，结果没有比较价值。
从那以后，我不再按“这次手改了几个文件”决定同步范围，而是按完整源码差异决定：
1
git diff --name-only <基准版本>...HEAD
所有会影响运行时的差异文件都要安装、计算哈希并进入备份与恢复清单。对于 Python 文件，还应在启动服务前执行 python -m py_compile，避免把传输损坏、编码异常或残缺文件留到几十分钟后的模型加载阶段才发现。
3. 磁盘上的 .so 更新了，旧进程仍在使用原映射
覆盖 _rocm_C.abi3.so 不会让已经运行的 Python 进程自动卸载旧共享库。更换二进制后必须完整重启服务；如果使用了 CUDAGraph，还应重新完成图捕获，不能沿用旧进程中的图状态。
我遇到过一次更隐蔽的情况：前一轮服务退出后，一个 VLLM::EngineCore 进程仍然存活并占用显存。下一轮服务虽然启动了，但环境已经不再干净。
在启动新服务前，我现在至少做两项只读检查：
1
2
ps -eo pid,ppid,cmd | grep -E 'vllm|VLLM::EngineCore' | grep -v grep
ss -ltnp | grep ':8000 '
确认旧服务、EngineCore、benchmark driver 和监听端口都已清理，再通过正常的服务管理方式重新启动。启动后还可以查看目标进程的映射：
1
2
PID=$(pgrep -n -f 'VLLM::EngineCore')
grep '_rocm_C.abi3.so' "/proc/${PID}/maps"
它至少能回答“当前进程从哪个路径加载了扩展”。如果路径不符合预期，后面的性能数据没有继续分析的必要。
4. 文件名一样，二进制来源却不同
有一次清理现场时，我记录到运行环境中的 _rocm_C 哈希前缀是：
1
7aee47576aa8...
而准备作为对照的已知扩展哈希前缀是：
1
f2c5393af460...
两个文件都叫 _rocm_C.abi3.so，目标算子也都能运行，但它们不是同一份二进制。没有哈希记录时，这种差异很容易被文件名掩盖。
我现在会同时记录构建目录和实际安装位置的哈希：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
BUILD_SO=cmake-build-rocm/_rocm_C.abi3.so
INSTALLED_SO=$(python3 - <<'PY'
import importlib.util
spec = importlib.util.find_spec("vllm._rocm_C")
if spec is None:
    raise SystemExit(1)
print(spec.origin)
PY
)

sha256sum "$BUILD_SO" "$INSTALLED_SO"
cmp -s "$BUILD_SO" "$INSTALLED_SO" \
  && echo "binary match" \
  || echo "binary mismatch"
仅有哈希还不够：必须证明请求命中了新 dispatch
哈希一致只能证明服务加载了目标扩展，不能证明某个请求选择了新 kernel。vLLM 中的 dispatch 往往同时受 shape、dtype、layout、序列阶段和缓存配置影响。条件少命中一个，程序就可能安静地回退到原路径。
我的做法是在候选分支里保留一个受环境变量控制的诊断 marker，只在真正选择候选 kernel 的那一行打印：
1
2
3
4
5
6
7
if os.getenv("VLLM_DCU_KERNEL_DIAG") == "1":
    logger.warning(
        "DCU_KERNEL_DIAG selected=%s shape=%s dtype=%s",
        selected,
        tuple(x.shape),
        x.dtype,
    )
marker 的关键不是“功能已启用”，而是 selected=True 必须来自实际 dispatch 结果。我的自动化 runner 会从服务日志提取 marker，并把“出现预期 shape、关键参数正确、selected=True”作为 benchmark 有效的前置条件。
这一点对海光 DCU 上的 ROCm kernel 尤其重要。很多实验的 fallback 仍然是可用且性能不错的 vendor 或 Triton 路径，因此“服务没有报错”完全不能证明新 kernel 被执行。
我现在使用的七道验真门
下面这张表是我最终固定下来的检查顺序。前一项没有通过，就不进入下一项。
顺序
要证明什么
最低证据
1
源码状态完整
完整 diff 清单，不只看当前脏文件
2
编译目标正确
日志出现 --offload-arch=gfx936 和目标源文件重编译
3
安装的是新二进制
build .so 与 import 实际路径的 SHA256 一致
4
算子注册成功
直接 import vllm._rocm_C，目标 op 为 True
5
进程状态干净
无残留 EngineCore、旧服务、旧 driver 和端口占用
6
真实请求命中
服务日志出现带真实 shape 的 selected=True marker
7
结果可用于比较
输出、请求数和失败数满足预先约定，再讨论性能
这套流程看起来比“编译后直接跑 benchmark”多了几步，但多数检查只需要几秒。真正耗时的是跳过它们之后，花几个小时分析一组其实来自旧二进制、半套源码或 fallback 路径的数据。
一段只读验真脚本
下面是我把常用检查压缩后的版本。它不修改文件，也不停止进程，适合在服务启动前后各执行一次。算子名可通过环境变量替换。
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
35
36
#!/usr/bin/env bash
set -euo pipefail

export DCU_VERIFY_OP="${DCU_VERIFY_OP:-LLMM1}"

python3 - <<'PY'
import importlib.util
import os
import torch
import vllm

print("vllm:", vllm.__file__)
spec = importlib.util.find_spec("vllm._rocm_C")
print("_rocm_C:", None if spec is None else spec.origin)
if spec is None:
    raise SystemExit("missing vllm._rocm_C")

import vllm._rocm_C  # noqa: F401
name = os.environ["DCU_VERIFY_OP"]
ok = hasattr(torch.ops._rocm_C, name)
print("op:", name, "registered=", ok)
if not ok:
    raise SystemExit("target op is not registered")
PY

SO=$(python3 - <<'PY'
import importlib.util
print(importlib.util.find_spec("vllm._rocm_C").origin)
PY
)

ls -l "$SO"
sha256sum "$SO"

echo "--- active vLLM processes ---"
ps -eo pid,ppid,cmd | grep -E 'vllm|VLLM::EngineCore' | grep -v grep || true
如果构建目录中的 .so、Python 实际 import 的 .so、进程映射中的 .so 和 dispatch marker 能形成一条闭合证据链，我才会把后续结果写进实验结论。
这套方法的边界
本文有三点需要明确：
111 秒 -> 13.5 秒 是特定容器与共享存储条件下的观测，不是海光 DCU 的固定性能指标；
21018624 字节和文中的 SHA256 属于一次具体构建，只用于说明如何记录二进制身份；
这套流程证明“测试对象正确”，并不自动证明 kernel 更快或数值正确，性能与正确性仍需单独验证。
不过，对我而言，这一步已经成为海光 DCU kernel 开发中最值得保留的工程习惯。HIPify、DTK 编译器、CMake 构建树、Python 安装目录、长期运行的 vLLM 进程和运行时 dispatch，每一层都可能保留旧状态。把它们逐层验明，远比盯着最后一行 build success 更可靠。
我现在改完 kernel 后，第一反应不再是看数字涨了多少，而是先确认：源码对不对，二进制对不对，进程对不对，这个请求到底有没有走到它。多花的只是几分钟，省下的往往是一整轮错误实验。
]]>
    
    https://luanjiahao.qzz.io/2026/07/17/dcu-vllm-incremental-build-verification/
    
    2026-07-17T01:00:00.000Z
    

      我在海光 DCU 上修改 vLLM kernel 时，最浪费时间的一次并不是编译报错。

那次编译正常结束，服务能够启动，接口也能返回结果，性能测试甚至给出了一个看起来可以解释的变化。后来重新核对运行环境，我才发现一个更麻烦的问题：源码、构建产物和服务实际加载的文件并不是同一套状态。此前围绕性能做出的判断，只能全部作废。
这件事改变了我的调试顺序。现在每次改完 ROCm kernel，我不会立刻看吞吐，而是先回答一个更基础的问题：

正在海光 DCU 上执行的，究竟是不是我刚刚修改、编译并准备测试的那份代码？

    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
    
      先说结论
THU-BDC2026 最值得记录的，不是某一次看起来很漂亮的收益率，而是那些把模型从“看起来有效”拉回“真的可验证”的实验。
这篇就是我的实验日志。它不追求把项目包装成一路顺风，反而专门把几次把结果越改越差的优化写下来，因为比赛里真正能留下来的经验，往往就藏在这些失败里。
时间
实验
结果
我的判断
2026-05-31
单周期回测
最新数据集模型单周 +5.9533%
很亮，但周期太短，只能当线索
2026-06-04
修复数据泄露
夏普从 2.30 掉到 -0.49
难看，但终于诚实
2026-06-05
删除波动率特征
特征 289 -> 227，夏普回到 0.40
做减法有效
2026-06-06
加资金流向因子
夏普 0.70，累计收益 12.33%
目前最像样的一版
2026-06-06
Top-80 特征筛选
训练快 57%，收益掉到 -7.47%
快不等于好
2026-06-07
行业覆盖修复
覆盖率 4.7% -> 100%，夏普降到 0.18
数据完整不等于模型会用
为什么要写成日志
这个项目一开始很容易让人上头：模型复杂、指标丰富、还有一些看起来很强的回测结果。
但量化项目最怕的就是“漂亮得不正常”。只要训练集切分、标签构造、特征窗口里有一点点未来信息，模型就会像突然开窍一样变强。问题是这种强不是真的强，它只是提前看了答案。
所以这篇文章的重点不是“我做出了一个多厉害的模型”，而是记录我怎么一步步把水分挤掉：
先承认单周期结果不能当结论；
再修复训练和预测之间的时间隔离；
接着删掉可能依赖泄露的特征；
最后再看哪些因子还能留下真实增益。
早期单周期回测：很亮，但不能信太多
archive 里有一份早期回测报告，只测了 2026-03-09 到 2026-03-13 这 5 个交易日。
当时结果看起来很好：
模型
单周期收益
原始数据集模型
-0.7367%
最新数据集模型
5.9533%
等权基准
1.3114%
如果只看这张表，很容易觉得方向已经对了。但 5 个交易日太短，运气成分很大。它更像一个提示：“这里可能有东西，值得继续查”，但不能证明模型稳定有效。
后来回头看，这个阶段最大的价值不是收益，而是提醒我必须把验证周期拉长，把回测流程做严。
修复数据泄露：最痛，但最值
真正改变项目走向的是数据泄露修复。
原来的回测只保证训练样本日期早于回测日，但标签使用了未来 5 天开盘价。也就是说，靠近回测日的训练样本虽然日期在过去，标签却可能已经跨进未来窗口。
这类泄露非常隐蔽。代码看起来没问题，结果也很好看，但本质上模型已经偷看了答案。
修复后结果马上变难看：
1
2
3
4
夏普:         -0.49
累计组合:     -17.11%
跑赢等权胜率: 44.8%
最大回撤:     -31.17%
这一步很打击人，但它是整条实验线里最重要的一步。因为从这里开始，后面的结果才有讨论价值。
做减法：砍掉波动率特征
修复泄露之后，我开始怀疑一批波动率相关特征。
例如：
boll_width
atr_pct
vol_20d
由这些指标衍生出来的聚合特征和横截面排名特征
它们在旧版本里重要性很高，但旧版本本身有泄露。所以我不确定它们是真的有效，还是只是帮模型记住了错误验证里的捷径。
于是我做了一版删除实验：
1
2
3
4
特征维度: 289 -> 227
夏普:     -0.49 -> 0.40
累计收益: -17.11% -> 4.39%
胜率:     44.8% -> 51.7%
这次结果反而变好。它给我的提醒很直接：特征不是越多越安全。尤其在金融数据里，有些特征看似信息量很大，其实只是把噪声和错误验证一起放大了。
资金流向：少数真正带来增益的东西
后面我加入了 Tushare 资金流向相关因子，主要包括三类：
主力净流入率；
小单净流入率；
超大单占比。
这一版是目前实验日志里比较像样的一版：
1
2
3
4
5
夏普:         0.70
累计组合:     12.33%
年化收益:     29.90%
跑赢等权胜率: 51.7%
最大回撤:     -25.13%
更关键的是，主力净流入率_ma20_cs_rank 进入了特征重要性 Top 20。
这让我觉得，资金行为信号可能比单纯堆价格形态更有价值。价格形态很容易过拟合，资金流向至少在这个窗口里提供了另一类信息。
三个失败优化
Top-80 特征筛选
我用 2023 年前的数据筛出重要性最高的 80 个特征，想减少噪声、加快训练。
训练速度确实变快了：
1
2
训练时间: 116 分钟 -> 50 分钟
速度提升: 约 57%
但结果变差了：
1
2
累计收益: +12.33% -> -7.47%
夏普:     0.70 -> -0.07
这说明历史窗口里的重要性不一定能迁移到未来。金融数据不是静态数据集，市场状态一变，过去最重要的特征可能反而拖后腿。
三分类标签
我还试过把股票粗分成三档：
前 30%；
中间 40%；
后 30%。
本意是让模型更关注“买入区”和“避雷区”，但实际效果很差，夏普掉到 -1.08。
原因大概是排序任务不能切得太粗。10 bins 标签虽然复杂一点，但保留了更多相对顺序信息，更适合每天从 300 只股票里选 Top 5。
行业覆盖修复
还有一次很反直觉的失败：行业覆盖修复。
原来行业覆盖率只有 4.7%，这肯定不合理，所以我把行业信息补到了 100%。从数据完整性的角度看，这一步绝对是正确的。
但模型表现却从夏普 0.70 降到 0.18，而且 sector_id 变成了最重要特征。
这说明模型可能不是“学到了行业”，而是“太相信行业”。行业信息需要更细的约束，比如降权、正则、分组验证，不能直接一股脑塞进去。
最后留下的规则
这轮实验之后，我给自己留下了几条规则：
单周期结果只能当线索，不能当结论。
回测第一步永远是查数据泄露。
特征重要性要按时间段看，不能拿一个历史窗口当真理。
做减法不丢人，能删掉噪声也是能力。
更完整的数据也需要被模型正确使用。
所有“看起来合理”的改动，最后都要让回测说话。
下一步怎么做
如果继续推进这个项目，我会优先做三件事：
把滚动回测周期拉长，不再被单周收益带节奏；
对行业、市值、流动性这类强结构特征做分组验证；
保留 LightGBM LambdaRank 主线，把深度模型作为辅助实验，而不是主战场。
这篇记录不构成任何投资建议。它更像一份比赛实验备忘录：把好看的结果拆开，把难看的结果留下，最后剩下的才可能是真的经验。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/thu-bdc2026-experiment-log/
    
    2026-06-13T03:20:00.000Z
    
一份公开版实验记录：从单周期高收益、数据泄露修复、特征删减，到资金流向因子和几次失败优化。
    
    2026-06-13T03:18:00.000Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
    
      为什么单独写一篇技术路线
上一篇更像比赛复盘，这一篇就专门把 THU-BDC2026 的技术路线理一遍。
这个项目从最早的深度模型，到后面的 LightGBM LambdaRank，中间不是简单的“换模型”，而是我对这个题目的理解发生了变化：股票排序任务不只是预测收益率，更像是在同一天的 300 只股票里做横截面比较。
所以后面我越来越关注三件事：
每天的横截面排序；
训练和预测的时间隔离；
特征是否真的能穿过不同年份。
第一阶段：Transformer + 横截面建模
最早的设计是 StockTransformer。
输入用过去 30 个交易日的数据，每只股票有 72 个技术指标，整体组织成：
1
[batch, 300只股票, 30天, 72特征]
模型里有几个关键模块：
TransformerEncoder：处理单只股票的时间序列；
FeatureAttention：聚合不同尺度的时序信息；
CrossStockAttention：让同一天的股票互相“看见”；
MoE Ranking：用多个专家头做排序打分；
Score Head：输出每只股票的最终分数。
这个设计的优点是表达能力强，也比较符合“股票之间有相对关系”的直觉。缺点也很明显：训练慢、调参成本高、回测迭代不方便，而且验证方式稍微有问题，复杂模型会把问题放大。
第二阶段：转向 LambdaRank
后面我把主要迭代切到了 LightGBM 的 lambdarank。
原因很实际：
第一，比赛目标本质上是 Top 5 排序，不一定非要预测一个绝对收益率。每天 300 只股票作为一个 group，用排序目标直接优化 NDCG@3 / NDCG@5，会更贴近任务。
第二，LightGBM 训练快很多。一次滚动回测虽然还是要跑很久，但比深度模型更适合反复试错。
第三，树模型的特征重要性更容易检查。它不一定代表因果，但至少能让我发现模型是不是被某一类奇怪特征带偏。
标签和分组
标签定义是：
1
(T+5 开盘价 - T+1 开盘价) / T+1 开盘价
也就是说，模型预测的是从 T+1 到 T+5 的阶段收益。为了让不同交易日之间可比，我会按日期做横截面处理，再把同一天的股票作为一个排序组。
这个地方最容易出问题。
如果回测日是 bt_date，训练集不能只写成：
1
processed['日期'] < bt_date
因为靠近 bt_date 的样本，它的 label 可能已经用到了未来开盘价。后面我改成至少隔开一段时间，避免训练集偷看到预测附近的信息。
这一步比换任何模型都重要。
特征工程
项目里用过的特征大概分几类：
类型
例子
作用
趋势/位置
ma_dev_60d、price_pos_20d
描述价格相对均线和区间的位置
K 线形态
lower_shadow_ratio、upper_shadow_ratio
描述日内买卖力量
量价关系
corr_pv_20、obv_ratio
描述成交量和价格变化关系
截面排名
*_cs_rank
在同一天 300 只股票里做相对比较
市值/行业
cap_bin、sector_id
提供结构性信息
资金流向
主力净流入率、超大单占比
捕捉资金行为信号
我后来对“截面排名”越来越有好感。因为股票比赛里，很多时候绝对值没有那么稳定，但同一天谁更强、谁更弱，反而更接近任务本身。
几个关键版本
版本
主要改动
夏普
累计收益
修复泄露后基线
排除含未来信息的训练样本
-0.49
-17.11%
CutVol
砍掉波动率相关特征
0.40
4.39%
Tushare 增强
加资金流向和行业信息
0.70
12.33%
Top-80 特征筛选
只保留历史重要性前 80
-0.07
-7.47%
三分类标签
前 30% / 中间 / 后 30%
-1.08
-25.77%
行业覆盖修复
行业覆盖率 4.7% 到 100%
0.18
-0.48%
这些数值都是阶段性回测结果，不是官方排名，也不是投资建议。
最反直觉的地方
这个项目里有几个结论挺反直觉。
第一，砍特征会变好。波动率特征在有数据泄露时很显眼，修复以后反而拖累模型。它提醒我：特征重要性不是永恒真理，它依赖验证方式。
第二，特征筛选会变差。Top-80 版本训练速度快了很多，但跨年份效果不行。金融数据里，过去重要的东西不一定在未来继续重要。
第三，修行业覆盖率也会变差。行业数据从 4.7% 修到 100%，按理说 metadata 更干净了，但模型把 sector_id 看得太重，结果反而下降。
这三个结果都说明一件事：量化模型不能靠直觉验收，必须靠严格回测验收。
我现在更认可的路线
如果重新做一遍，我不会一上来就堆很复杂的深度结构。
我会先用 LightGBM LambdaRank 做一个干净、快、可解释的基线，把下面这些东西做扎实：
日期分组和标签隔离；
滚动回测；
去最优月后的稳健性检查；
特征重要性漂移；
单次改动的 ablation；
预测结果的权重约束。
等这些都稳定以后，再考虑把深度模型拿回来做融合。
这个项目最后让我更相信：比赛里真正高级的地方，不是模型名字听起来多厉害，而是你能不能证明自己的结果不是碰巧、不是偷看未来、不是被某个奇怪特征骗了。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/thu-bdc2026-model-iteration/
    
    2026-06-13T03:10:00.000Z
    

      为什么单独写一篇技术路线
上一篇更像比赛复盘，这一篇就专门把 THU-BDC2026 的技术路线理一遍。
这个项目从最早的深度模型，到后面的 LightGBM LambdaRank，中间不是简单的“换模型”，而是我对这个题目的理解发生了变化：股票排序任务不只是预测收益率，更像是在同一天的 300 只股票里做横截面比较。
所以后面我越来越关注三件事：

]]>
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
    
      起因
这次 THU-BDC2026，我手里其实留了三份项目目录：原版、archive、v2。看起来像三个项目，翻完之后发现更准确的说法是：这是同一个比赛项目的三段成长史。
赛题本身很直接：根据沪深 300 成分股的历史行情，对股票做排序，选出 Top 5 组成投资组合，再给它们分配权重。说白了，就是让模型回答一个很现实的问题：下一段时间里，哪几只股票更值得排在前面。
一开始我很兴奋，因为这个题目天然适合写得很“高级”：Transformer、CrossStockAttention、MoE、横截面标准化、Top 5 softmax 权重。关键词堆起来很漂亮，代码也确实能跑。
但后来我发现，金融比赛里最可怕的东西不是模型不够复杂，而是模型看起来太对了。
第一版：看起来很猛
最早的方案是深度模型路线。
我把过去 30 个交易日作为时间窗口，给每只股票计算 72 个技术指标，然后构造成一个四维张量：
1
[batch, 股票数, 30天, 特征数]
模型结构大概是：
StockTransformer 建模时间序列；
CrossStockAttention 建模同一天不同股票之间的关系；
MoE Ranking 增加模型容量；
最后输出每只股票的排序分数，取 Top 5。
这个方案从工程上看挺完整，甚至还有点“比赛味”。但做量化不能只看结构漂不漂亮，核心还是回测能不能经得住审。
那个让我冷静下来的 bug
后面我在回测代码里发现了一个很严重的问题：训练数据过滤只用了预测日前的数据。
原来的逻辑类似这样：
1
train_proc = processed[processed['日期'] < bt_date].copy()
问题在于，标签是用未来 5 天开盘价算的。也就是说，预测日前几天的样本虽然日期小于预测日，但它们的 label 里可能已经包含了预测日附近的未来价格信息。
修复后，我把训练样本和预测日之间隔开：
1
2
3
4
train_proc = processed[
    (processed['日期'] < bt_date) &
    (processed['日期'] + pd.Timedelta(days=10) < bt_date)
].copy()
这一刀下去，结果非常难看。
指标
修复前声称
修复后回测
夏普
2.30
-0.49
累计收益
-
-17.11%
跑赢等权胜率
-
44.8%
最大回撤
-
-31.17%
最难受的不是亏损，而是我必须承认：之前那个漂亮结果不可信。
重新开始做一个更诚实的版本
修完数据泄露以后，我没有继续往模型上堆东西，而是先做减法。
我发现一些波动率相关特征在泄露存在时特别“有用”，但修复之后反而像噪声源。于是砍掉了 vol_5d、vol_10d、vol_20d、boll_pctb、boll_width、atr_pct 这些特征。
特征维度从 289 降到 227，回测反而变好了：
版本
夏普
累计收益
胜率
修复泄露后基线
-0.49
-17.11%
44.8%
砍波动率特征
0.40
4.39%
51.7%
这一步给我的提醒很大：不是特征越多越好。有些特征在错误的验证方式下会显得特别聪明，但一旦验证变干净，它就露馅了。
Tushare 增强版：比较像样的一版
后面我加了 Tushare 的资金流向因子和申万行业分类，主要包括：
主力净流入率；
小单净流入率；
超大单占比；
行业和市值相关特征。
这版阶段性回测表现最好：
指标
Tushare 增强版
夏普
0.70
累计收益
12.33%
年化收益
29.90%
跑赢等权胜率
51.7%
最大回撤
-25.13%
其中 主力净流入率_ma20_cs_rank 进入了 Top 20 特征重要性，这说明资金流向类因子确实提供了一些额外信息。
但我也不想把这写成“终于成功了”。因为回测窗口只有 2024 年到 2026 年的一段滚动测试，而且去掉最好的月份后，收益稳定性会明显变弱。它是一个阶段性更好的版本，不是能拿来吹一辈子的神模型。
那些没变好的尝试
这个项目后面还有几次很有意思的失败。
我试过 Top-80 特征筛选，训练时间确实从 116 分钟降到 50 分钟，但夏普从 0.70 掉到 -0.07。原因大概是 2023 年前的重要特征，不一定能迁移到 2024-2026 年。
我也试过三分类标签，把股票分成“前 30% / 中间 40% / 后 30%”。结果更差，夏普掉到 -1.08。后来想想也合理：股票排序任务需要保留尽量多的相对顺序信息，粗暴三分类反而把中间信息抹掉了。
还有一次我把行业覆盖率从 4.7% 修到 100%，听起来肯定是对的，但回测从 0.70 掉到 0.18。这个结果很反直觉，也挺真实：数据更完整，不代表模型一定更好。如果模型过度依赖行业特征，修 metadata 也可能把它带偏。
最大的收获
这次比赛给我的最大教训不是某个模型结构，也不是某个指标，而是四个字：别骗自己。
金融机器学习里，最危险的是“看起来合理”。代码能跑、曲线好看、指标很高，这些都不能自动证明模型真的有预测能力。
真正重要的是：
标签有没有偷看未来；
训练集和预测日有没有隔离；
回测窗口是不是太短；
最优月份是不是撑起了全部收益；
特征重要性是不是只是某个时间段的幻觉；
改动变好，是不是只是碰巧。
这篇文章只记录比赛和回测复盘，不构成任何投资建议。
如果以后我再做类似项目，我会先把回测卫生、数据泄露检查、滚动验证这些东西放在第一位。模型可以慢慢变复杂，但验证方式一旦错了，后面所有努力都会被带到沟里。
这次最有价值的地方，可能就是我真的掉进去了一次，然后把它记录下来了。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/competition-review-notes/
    
    2026-06-13T03:00:00.000Z
    

      起因
这次 THU-BDC2026，我手里其实留了三份项目目录：原版、archive、v2。看起来像三个项目，翻完之后发现更准确的说法是：这是同一个比赛项目的三段成长史。
赛题本身很直接：根据沪深 300 成分股的历史行情，对股票做排序，选出 Top 5 组成投资组合，再给它们分配权重。说白了，就是让模型回答一个很现实的问题：下一段时间里，哪几只股票更值得排在前面。
一开始我很兴奋，因为这个题目天然适合写得很“高级”：Transfor]]>
    
    
    2026-08-28T11:20:48.100Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      起因
最近整理项目的时候，我顺手把小米 MIMO 开发者 Token 申请材料也翻出来了。
这份材料本来是为了说明我用 AI/Agent 做过什么，但写完之后发现，它其实也挺适合当一篇复盘：AI 到底帮了我什么？又有哪些地方不能全交给它？
AI 参与了哪些项目
主要是两类：
第一类是完整业务系统。
我用 AI 辅助做了校园宿舍管理系统和电商平台。前者是 Spring Boot + MyBatis + MySQL，后者是 Servlet + JSP + DBUtils 的传统 Java Web 项目。
第二类是技术实验。
比如 Spring AOP、JdbcTemplate + 声明式事务、Spring MVC 拦截器、三层架构这些小实验。它们不一定大，但很适合验证一个知识点到底有没有学明白。
AI 最擅长的部分
我感觉 AI 最适合处理那些”有规律、但很耗时间”的代码。
比如：
Entity、DTO、VO 这种结构化类。
Controller/Service/Mapper 的基础模板。
MyBatis 动态 SQL 的第一版。
DAO 层查询代码。
前端一些重复的表单和异步请求片段。
配置文件和跨域、上传之类的查漏补缺。
这些东西让人手写不是不会，而是容易疲劳。AI 先出第一版，我再去改业务逻辑，速度确实快很多。
我自己的体感是，规律性强的代码效率能提升 50%-60%。以前可能要两周慢慢磨的传统电商项目，用 AI 辅助后大概一周能跑出完整流程。
但它不能替你负责
AI 写出来的代码，最大的问题是”看起来很像对的”。
有时候它会给你一个很顺眼的 Controller，方法名、注解、返回值都像那么回事。但你真去跑，就会发现参数对不上、SQL 字段错了、前端传的名字和后端接的名字不一致。
所以我现在用 AI 写项目，会尽量把它当副驾驶：
第一版可以让它出。
业务规则必须自己确认。
SQL 必须自己看。
安全边界必须自己补。
最后必须自己跑完整流程。
AI 能减少重复劳动，但不能替你承担工程判断。
对学习的影响
最明显的变化是学习周期变短了。
从 Java SE 到 Servlet，再到 Spring、Spring Boot，如果完全手写慢慢摸，可能要拖三个月。AI 辅助后，我大概六周左右就把这条链路跑了一遍。
但这里有个前提：不能只复制粘贴。
如果只是让 AI 写完，然后自己不理解，那项目做完也没什么用。真正有用的是让它把”能跑的第一版”生成出来，然后自己去拆：
这个接口为什么这么分层？
这个 SQL 为什么这样写？
这个配置是解决什么问题？
如果需求改了，我应该改哪里？
这样 AI 才会变成学习加速器，而不是代码代写器。
后续想做的事
后面我想继续把 AI 用到更真实的工作流里。
比如：
给宿舍管理系统接一个小程序前端。
让 AI 帮忙生成单元测试。
做自动化代码 review。
尝试把 Agent 接进后端流程里，处理一些多步骤任务。
现在的感觉是，AI 不是让人不用学编程了，而是让”会问问题、会拆任务、会验收结果”变得更重要。
写代码这件事，正在从”我一行行敲”变成”我设计、我判断、我验收”。
这挺有意思的。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/ai-agent-mimo-application/
    
    2026-06-13T02:00:00.000Z
    

      起因
最近整理项目的时候，我顺手把小米 MIMO 开发者 Token 申请材料也翻出来了。
这份材料本来是为了说明我用 AI/Agent 做过什么，但写完之后发现，它其实也挺适合当一篇复盘：AI 到底帮了我什么？又有哪些地方不能全交给它？
AI 参与了哪些项目
    
    
    2026-08-28T11:20:48.100Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      起因
现在再写 Servlet + JSP，好像有点复古。
前端早就 React、Vue 满天飞，后端也基本都是 Spring Boot 起步。但我还是觉得，亲手用 Servlet 和 JSP 写一个电商 demo，很适合补 Web 基本功。
因为它没有那么多框架帮你藏细节。请求怎么进来，Session 怎么存，页面怎么跳，DAO 怎么查数据库，都得自己写。
项目在这里：yfgug/project
功能大概长这样
这个电商平台不是玩具页面，基本购物流程是完整的：
用户模块：注册、登录、注销、改密、修改收货地址。
商品模块：分类浏览、分页查询、关键词搜索、商品详情。
推荐模块：滚动横幅、热门推荐、新品推荐。
购物车：基于 Session 保存购物车，异步加入商品。
订单模块：购物车结算、订单生成、支付方式选择。
技术上用的是传统 Java Web：Servlet、JSP、JSTL、Filter、DAO、Service。数据库访问用了 Apache DBUtils，连接池配置里实际使用的是 Druid，也保留了传统依赖说明。
Session 购物车
购物车这块挺能体现传统 Web 项目的味道。
用户点”加入购物车”时，前端请求 goods_buy。后端从 Session 里拿 Order 对象，如果没有就新建一个，再根据商品 id 查库存，库存足够就加入购物车。
这段逻辑不复杂，但它把几个基础点串起来了：
Session 不是抽象概念，它真的可以存当前用户的临时状态。
Servlet 处理的是一次请求，但购物车需要跨请求保留。
后端不能相信前端，加入购物车前还是要查库存。
以前我只知道 Session 是会话。写完之后才更具体地理解，它就是很多传统 Web 应用维持状态的关键。
DAO 层也有坑
不用 ORM 的时候，SQL 会离你很近。
DBUtils 的 QueryRunner 能少写很多样板代码，BeanHandler、MapListHandler 也能把结果集处理得舒服一点。但 SQL 本身还是要自己负责。
比如分页查询，不能只想着页面显示几条，还要算：
当前第几页。
每页多少条。
总记录数。
总页数。
limit 从哪里开始。
这些东西看着琐碎，但电商列表页离不开。
为什么这种项目还有意义
这个项目写完之后，我更能理解 Spring Boot 为什么舒服。
不是因为 Servlet/JSP 不能用，而是因为传统 Java Web 里太多事情需要你亲自管理：
编码过滤器。
路由映射。
Session 状态。
JSP 页面跳转。
DAO 手写 SQL。
依赖包手动放到 WEB-INF/lib。
写一遍之后，再去用 Spring MVC、Spring Boot，就不会觉得那些自动配置是魔法。它们只是把这些老活儿包装好了。
最后
这个电商平台不算现代，但很适合练手。
它让我知道一个 Web 应用不是只有页面，也不是只有数据库。真正的项目是一条完整链路：用户点按钮，请求进入后端，后端处理状态和数据，再把结果返回到页面。
这条链路走通了，后面学什么框架都轻松一点。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/servlet-jsp-ecommerce/
    
    2026-06-13T01:30:00.000Z
    

      起因
现在再写 Servlet + JSP，好像有点复古。
前端早就 React、Vue 满天飞，后端也基本都是 Spring Boot 起步。但我还是觉得，亲手用 Servlet 和 JSP 写一个电商 demo，很适合补 Web 基本功。
因为它没有那么多框架帮你藏细节。请求怎么进来，Session 怎么存，页面怎么跳，DAO 怎么查数据库，都得自己写。
项目在这里：
    
    
    
    
    
      起因
校园宿舍管理系统听起来很像课程设计。
学生信息、宿舍号、报修工单、公告管理，这些功能都很常见。刚开始我也觉得它就是一个 CRUD 项目，写几个接口、连个数据库、页面能点就行。
但真正写完之后才发现，CRUD 只是最外面那层壳。只要你稍微把功能做完整一点，就会遇到很多实际问题。
项目在这个仓库里：yfgug/project
做了哪些功能
这个系统主要有几个模块：
学生管理：增删改查、多条件搜索、批量删除、头像上传。
报修工单：提交、处理中、已解决、删除。
公告管理：发布、编辑、删除。
登录保护：连续输错密码后短时间锁定账号。
文件上传：限制后缀、限制大小、UUID 重命名。
技术栈是 Spring Boot 2.5 + MyBatis + MySQL。后端用 RESTful API，返回值统一包了一层 Result<T>，配置放在 YAML 里，数据库连接池用 HikariCP。
最先踩到的是查询
学生管理里最常见的需求就是搜索。
只按姓名搜很简单，只按宿舍号搜也很简单。但真实页面里经常是组合条件：姓名、性别、宿舍号、入住日期范围，用户想填哪个就填哪个。
如果每种组合都写一条 SQL，很快就会变成灾难。
后来我用 MyBatis 动态 SQL 来处理：
有姓名就拼姓名条件。
有性别就拼性别条件。
有宿舍号就拼宿舍号条件。
有日期范围就拼日期范围。
批量删除用 <foreach> 展开 id 列表。
这件事让我第一次比较直观地感觉到，框架不是为了炫技，是真的能救命。
文件上传比想象中麻烦
头像上传一开始看起来也很简单：前端传文件，后端存起来，再把路径写进数据库。
但问题很快就来了：
用户传的文件是不是图片？
文件太大怎么办？
两个人上传同名文件会不会覆盖？
上传目录怎么映射成可访问路径？
最后的处理方式是：
只允许 jpg/jpeg/png/gif/bmp/webp。
限制 2MB 大小。
用 UUID 重命名。
单独做上传配置和资源映射。
这些细节不写，功能也许能跑。但一旦真的给别人用，就很容易出问题。
登录防暴力破解
这个功能不复杂，但我觉得挺有意思。
我用 ConcurrentHashMap 记录登录失败次数。同一个账号连续输错 3 次，就锁定 5 秒。
这当然不是专业安全方案，也不能替代验证码、限流、审计日志这些东西。但对一个练习项目来说，它至少让我开始思考”接口不能只考虑正常路径”。
以前写登录接口，我只会想密码对不对。现在会多想一步：如果有人一直试密码怎么办？
写完之后的感觉
这个项目最大的价值，不是它有多少功能，而是它把后端常见的几件事都串了一遍：
接收请求。
校验参数。
调用业务层。
访问数据库。
处理文件。
返回统一结果。
让前端页面真的能用。
写之前我觉得 Spring Boot 是一堆注解。写完之后再看，它其实是在帮我把这些重复但重要的工作组织起来。
项目不大，但它让我对”一个后台系统应该长什么样”有了更清楚的感觉。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/dormitory-system-springboot/
    
    2026-06-13T01:00:00.000Z
    

      起因
校园宿舍管理系统听起来很像课程设计。
学生信息、宿舍号、报修工单、公告管理，这些功能都很常见。刚开始我也觉得它就是一个 CRUD 项目，写几个接口、连个数据库、页面能点就行。
但真正写完之后才发现，CRUD 只是最外面那层壳。只要你稍微把功能做完整一点，就会遇到很多实际问题。
项目在这个仓库里：yfgug/project]]>
    

    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      起因
之前学 Java 的时候，我总有一种很奇怪的感觉：语法能看懂，视频也能跟着敲，但真要自己做一个东西，就不知道从哪开始。
所以后来我干脆把一堆练习和小项目放到一个仓库里，从 Java 基础、JDBC、Servlet/JSP，一直堆到 Spring、Spring MVC、Spring Boot。看起来有点乱，但它刚好记录了我从”会写代码”到”能把一个业务系统跑起来”的过程。
项目地址：yfgug/project
这个仓库里有什么
仓库主要分成四块：
目录
内容
技术栈
java-basics/
Java 基础和 JDBC 练习
JDBC、PreparedStatement
ecommerce-platform/
一个传统电商平台 demo
Servlet、JSP、DBUtils、连接池
spring-experiments/
Spring 生态实验合集
Spring、Spring MVC、AOP、事务
dormitory-system/
校园宿舍管理系统
Spring Boot、MyBatis、MySQL
这不是那种一上来就微服务、网关、消息队列全家桶的项目。它更像一条学习路线：先把数据库连明白，再把 Web 请求跑通，然后理解分层，最后再用 Spring Boot 把这些东西整合起来。
为什么我觉得它有用
很多教程会把知识点拆得很碎：今天讲 JDBC，明天讲 Servlet，后天讲 Spring Bean。单个知识点都不难，但真正困难的是把它们串起来。
比如一个最普通的”查询学生列表”，背后其实有一整条链路：
页面发请求。
Controller 接参数。
Service 处理业务规则。
Mapper/DAO 查数据库。
返回统一格式的数据。
前端再把结果渲染出来。
这条链路走通以后，再看 Spring 里那些注解就没那么玄学了。@Controller、@Service、@Mapper 不是为了显得高级，它们只是把不同职责放到不同位置。
CRUD 不丢人
以前我会觉得 CRUD 项目很普通，没什么好写的。
后来发现，CRUD 其实一点都不简单。增删改查只是表面，真正麻烦的是各种边界：
查询要不要支持多条件组合？
删除要不要支持批量？
文件上传要不要限制格式和大小？
登录失败太多次要不要锁一下？
返回给前端的数据格式要不要统一？
页面刷新之后 Session 里的购物车还在不在？
这些东西不会出现在”Hello World”里，但会出现在每个真实一点的项目里。
AI 在里面做了什么
这些项目里有不少代码是 AI 辅助生成的，尤其是模板感很强的部分：实体类、Controller、Service、Mapper、DAO、一些前端交互片段。
但我现在越来越觉得，AI 写代码不是”替你完成项目”，更像是”把你从重复劳动里拽出来”。
它可以帮我快速生成第一版，但最后还是得自己看：
SQL 有没有查错表？
参数有没有校验？
文件上传有没有安全问题？
业务流程能不能真的走通？
代码只是能跑，还是以后也能改？
这一步不能省。不然项目看着很完整，里面可能全是坑。
最后
这个仓库不算高级，但对我很重要。
它让我确认了一件事：学后端不是背框架名，也不是堆技术栈，而是把数据、请求、业务和页面之间的关系一遍遍跑通。
从 Java SE 到 Spring Boot，中间真正的变化不是代码变短了，而是我开始知道一个项目应该怎么拆、怎么连、怎么交付。
这大概就是练项目的意义。
]]>
    
    https://luanjiahao.qzz.io/2026/06/13/java-projects-roadmap/
    
    2026-06-13T00:30:00.000Z
    

      起因
之前学 Java 的时候，我总有一种很奇怪的感觉：语法能看懂，视频也能跟着敲，但真要自己做一个东西，就不知道从哪开始。
所以后来我干脆把一堆练习和小项目放到一个仓库里，从 Java 基础、JDBC、Servlet/JSP，一直堆到 Spring、Spring MVC、Spring Boot。看起来有点乱，但它刚好记录了我从”会写代码”到”能把一个业务系统跑起来”的过程。
项目地址：
    
    
    
    
    
      起因
事情是这样的。
我有个习惯，每隔一段时间会把 QQ 聊天记录导出来备份。不是为了什么，就是怕哪天号没了，聊天记录也没了。
之前一直用一个叫 QQFlow 的工具，Electron + Python 写的，能用。但有两个问题：一是软件太大了，安装包 188MB；二是打开大数据库的时候卡得要命，190MB 的数据库要等好几分钟。
有天晚上我又在等它加载，看着进度条一动不动，突然想：要不用 Rust 重写一个？
其实没那么难
说”重写”有点高估我了。
我做的事情更像是”整合”。核心的思路是参考了 WeFlow 这个微信聊天记录导出工具的架构——用一个内存缓存把所有消息一次性加载进来，后续查询直接走内存，不再碰数据库。
具体的实现是这样的：
密钥提取：用 Windows Debug API 注入 QQ 进程，从内存里找到 SQLCipher 的加密密钥。这部分代码网上有现成的，我改了改就用了。
数据库解密：用 rusqlite + bundled-sqlcipher，流式复制一份解密后的数据库到临时目录。只复制一次，后续直接读缓存。
消息加载：SELECT * 全表扫描，把所有消息按群号/私聊对象分组存到 HashMap 里。190MB 数据库大概 30-60 秒，之后所有查询都是 O(1)。
前端：React + TypeScript + Vite，抄了几个开源项目的样式，拼拼凑凑。
说实话，我没写多少原创代码。大部分时间都在调试、在踩坑、在看报错日志。
踩过的坑
坑一：死锁
第一个版本有个很诡异的 bug：点击群聊分析，永远显示”正在加载…”。
调试了两天才发现是死锁。load_store_if_needed 在持有 Mutex 锁的情况下执行数据库操作，而另一个线程也在等这把锁。两个线程互相等，就卡死了。
解决方法是把”检查缓存”和”执行数据库”分开：先检查缓存，释放锁，执行数据库操作，然后再加锁存储。听起来简单，但我改了三个版本才稳定下来。
坑二：BLOB 解析
QQ 的消息内容存在 BLOB 字段里，是 Protobuf 编码的二进制数据。早期版本的解析器把 varint 字节解码成了 CJK 扩展区字符，输出一堆”生僻字”垃圾。
后来我加了个纯净度过滤器：只有 60% 以上的字符是常见汉字才保留。但这个阈值太高了，英文消息会被过滤掉。改成先尝试提取可读文本，再回退到 ASCII 分类，才解决。
还有一个更离谱的问题：某些二进制 BLOB 会让解析器进入无限循环，CPU 直接拉满 100%。最后加了个操作预算（budget = blob_size × 50），超出预算自动回退，才搞定。
坑三：UID 映射
QQ 的发送者不是直接存 QQ 号，而是存一个 UID（像 u_-PBswiplK-7J7bmaQLA-mA 这种）。QQ 号存在另一个映射表里。
问题是这个映射表的列名全是数字（48901、48902、1002），没有语义。我原来的逻辑是找第一个非数字列作为 UID、第一个数字列作为 QQ 号，但第一列的值是纯数字序号，被误判为 QQ 号了。
最后写了 4 级查找策略：已知列名直查 → 候选表自动检测 → 模糊表名搜索 → 全表暴力扫描。才把各种 QQ 版本的映射表都兼容了。
坑四：CSV 乱码
导出的 CSV 文件用 Excel 打开，中文全是乱码。查了半天发现是编码问题——UTF-8 没有 BOM 头，Excel 默认按 GBK 解析。
在文件开头加了 3 个字节的 BOM（\xEF\xBB\xBF），问题解决。这种小问题最烦人。
最终效果
特性
原版 (Electron + Python)
Rust 版 (Tauri)
安装包大小
~188MB
~10MB
内存占用
~200MB
~30MB
打开 190MB 数据库
几分钟
30-60 秒（首次），后续秒开
功能清单
密钥提取（Windows Debug API）
数据库解密（SQLCipher）
TXT 导出（按时间排序、日期分组）
CSV 导出（带 BOM，Excel 可直接打开）
聊天分析（24h 分布、类型饼图、成员排行、高频短语）
多账号支持（每个 QQ 号独立缓存）
深色/浅色主题
开源
项目地址：yfgug/QQFlow
目前只支持 Windows，因为密钥提取用的是 Windows API。Mac 和 Linux 的话，密钥提取方式不一样，我还没研究。
写在最后
这个项目前前后后写了两个月。说是”重写”，其实大部分时间都在调试。Rust 的编译错误真的让人头大，有时候一个生命周期的问题能卡我半天。
但最后还是写完了。
写完之后最大的感受是：很多时候你不需要从零开始造轮子。看看别人怎么做的，把好的思路拿过来，用自己的方式实现一遍，这个过程本身就是学习。
感谢 WeFlow 作者的开源贡献，没有他的项目，我可能不会想到用这种架构。
“代码是整合的艺术，不是原创的专利。”
]]>
    
    https://luanjiahao.qzz.io/2026/05/20/qqflow-rust/
    
    2026-05-20T10:00:00.000Z
    

      起因
事情是这样的。
我有个习惯，每隔一段时间会把 QQ 聊天记录导出来备份。不是为了什么，就是怕哪天号没了，聊天记录也没了。
之前一直用一个叫 QQFlow 的工具，Electron + Python 写的，能用。但有两个问题：一是软件太大了，安装包 188MB；二是打开大数据库的时候卡得要命，190MB 的数据库要等好几分钟。
有天晚上我又在等它加载，看着进度条一动不动，突然想：要不用 Rust 重写一个？
]]>
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      起因
事情是这样的。
有天晚上我在 B 站游戏中心闲逛，发现有些游戏明明评分很高，但下载量很低。有些游戏评分一般，下载量却很高。
我就想，这些数据之间有没有什么规律？
于是我就写了这个爬虫。
项目简介
这个项目干的事情很简单：爬取 B 站游戏中心的数据，然后做分析和可视化。
爬取的数据包括：游戏名称、类型、平台、评分、关注数、下载量、排行榜数据等等。
分析的内容包括：类型分布、平台分布、评分分布、关注数与下载量的关系、流水估算等等。
数据获取模式
项目支持三种数据获取模式：
模式
说明
适用场景
demo
内置 88 款真实国产游戏的模拟数据
开发调试、离线演示
web
从 B 站游戏中心 HTML 页面解析
实际数据采集
api
调用 B 站 API 接口
实际数据采集
demo 模式是给那些不想爬数据、只想看看分析效果的人准备的。内置了 88 款真实国产游戏的数据，虽然不是最新的，但足够演示用了。
web 模式是通过解析 HTML 页面获取数据，不需要 API key，但速度慢一点。
api 模式是直接调用 B 站的 API，速度快，但可能需要处理反爬。
流水估算
这个项目最有意思的部分是流水估算。
B 站游戏中心不公布游戏的收入数据，所以我只能通过其他指标来估算。我用的指标是关注数和评分。
关注数代表游戏的热度，评分代表游戏的质量。热度高质量好的游戏，收入大概率不会差。
估算的公式很简单：流水 = 关注数 * 评分系数 * 平台系数。这个公式不精确，但能看出大概的趋势。
可视化
项目会生成 7 种图表：
游戏类型分布饼图
平台分布柱状图
评分分布直方图
关注数与下载量散点图
流水估算排名图
热度榜 TOP10
畅销榜 TOP10
这些图表用 Matplotlib 生成，样式一般，但数据是准的。如果你想要好看的图表，可以自己换 ECharts 或者 Plotly。
一些发现
爬完数据之后，我发现了一些有意思的事：
二次元游戏的评分普遍偏高。 可能是因为二次元玩家更愿意打高分。
独立游戏的关注数和下载量不成正比。 有些独立游戏关注数很高，但下载量很低。可能是因为玩家只是收藏了，没有真正去玩。
B 站游戏中心的热门游戏和 App Store 的热门游戏不太一样。 B 站用户更偏好二次元、独立、小众的游戏。
预约榜的游戏，上线后的表现参差不齐。 预约数高不代表游戏质量好，可能只是营销做得好。
这些发现不算什么深刻的洞察，但对我来说挺有意思的。
项目结构
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
bgame/
├── main.py                 # 主入口
├── bili_game_scraper/      # 爬虫模块
│   ├── spider.py           # 爬虫引擎
│   ├── demo_data.py        # 模拟数据生成器
│   └── parsers/            # 解析器
├── analysis/               # 分析模块
│   ├── statistics.py       # 统计分析
│   └── visualization.py    # 可视化
├── storage/                # 存储模块
│   └── sqlite_storage.py   # SQLite 存储
├── scheduler/              # 调度模块
│   └── scheduler.py        # 定时调度
├── config/                 # 配置模块
│   └── settings.py         # 配置管理
├── data/                   # 数据目录
├── charts/                 # 图表目录
└── exports/                # 导出目录
快速开始
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 安装依赖
pip install -r requirements.txt

# 一键执行完整流程：爬取→分析→可视化→导出
python main.py all

# 只爬取数据
python main.py crawl --max-pages 5

# 只生成分析报告
python main.py analyze --save

# 只生成可视化图表
python main.py visualize

# 启动定时爬取
python main.py schedule --interval 6
踩过的坑
坑一：反爬
B 站有反爬机制，请求太频繁会被封 IP。我加了随机延时和 User-Agent 轮换，但有时候还是会被封。
坑二：数据格式
B 站游戏中心的数据格式不太统一，有些游戏的字段是空的，有些游戏的字段格式不一样。我写了好几个解析器来处理这些特殊情况。
坑三：分页
B 站游戏中心的分页逻辑有点奇怪，有时候请求第一页会返回重复的数据。我加了去重逻辑，才解决这个问题。
开源
项目地址：yfgug/bgame
如果你对 B 站游戏数据感兴趣，可以玩玩看。代码写得一般，但功能是完整的。
写在最后
这个项目是我用来练手 Python 爬虫的。写完之后发现，爬虫这东西，技术上不难，难的是处理各种边界情况。
反爬、数据格式、分页、编码……每个环节都可能出问题。写爬虫就像是在和网站的开发者斗智斗勇，有时候赢，有时候输。
但最后爬下来的数据，确实能发现一些有意思的东西。
这大概就是数据的魅力吧。
“数据是新时代的石油，分析是炼油厂。”
]]>
    
    https://luanjiahao.qzz.io/2026/05/18/bilibili-game-scraper/
    
    2026-05-18T10:00:00.000Z
    

      起因
事情是这样的。
有天晚上我在 B 站游戏中心闲逛，发现有些游戏明明评分很高，但下载量很低。有些游戏评分一般，下载量却很高。
我就想，这些数据之间有没有什么规律？
于是我就写了这个爬虫。
项目简介
这个项目干的事情很简单：爬取 B 站游戏中心的数据，然后做分析和可视]]>
    
    
    2026-08-28T11:20:48.100Z
  
  
    
      YFGUG
    
    
    
    
    
    
      先说结论
买鞋这事，我交了不少学费。
第一双徒步鞋是迪卡侬最便宜那双，199块。走了一次千岛湖，脚踝差点废了。第二双是某宝上买的”军靴”，说是真皮防水，结果下雨天里面能养鱼。第三双是凯乐石，终于对了。
所以这篇东西，是我花了两千多块踩坑之后的总结。希望你别走我的老路。
选鞋就看三点
第一，高帮。
重装徒步必须高帮，没得商量。低帮鞋走平路没问题，但背着20公斤的包走碎石坡，脚踝没有支撑，扭伤是分分钟的事。我穿低帮鞋走千岛湖那次，下坡的时候脚崴了一下，疼了两个星期。
第二，鞋底要硬。
软底鞋走起来舒服，但走久了脚底板会疼。重装徒步需要鞋底有一定的硬度，才能支撑你的脚。Vibram大底是标配，别省这个钱。
第三，防水。
山区天气说变就变，早上晴天下午就可能下雨。不防水的鞋走湿路，脚泡在水里，起水泡是轻的，真菌感染才叫麻烦。Gore-Tex或者其他防水透气面料，必须有。
我的推荐
凯乐石 Fuga EX
这双鞋我穿了大半年，走了南太行和武功山，目前是最满意的一双。
优点是防滑真的好。Vibram Megagrip大底，走湿石头都不打滑。高帮设计，脚踝包裹得很紧，走碎石坡很有安全感。透气性也行，夏天穿不闷脚。
缺点是鞋底偏硬，刚穿的时候需要磨合。我第一次穿它走了十公里，脚底板有点疼。但穿几次之后就好了，鞋底会根据你的脚型慢慢变软。
价格400-500块，性价比很高。国产鞋能做到这个水平，我是服气的。
迪卡侬 MH500
如果你是入门玩家，走走轻松的线路，这双够了。
迪卡侬的优点是舒适度高，开箱就能穿，不用磨合。防水性能也不错，我穿着它走过几次雨天，脚一直是干的。
但重装的话，支撑性差点意思。我穿着它走南太行，走完之后脚踝有点酸。可能是我脚踝本身比较弱，但凯乐石走同样的路就没这个问题。
价格300-400块，适合轻装徒步和入门重装。
骆驼 昆仑山系列
预算紧张的话，这双可以考虑。200多块就能买到防水高帮鞋，性价比确实高。
但品控不太稳定。我朋友买了一双，穿了三个月鞋底就开胶了。我另一双骆驼倒是穿了大半年还好好的，看运气。
防滑性一般，走湿石头要小心。有一次我穿着它走溪谷，差点滑进水里。
适合偶尔走走、预算有限的朋友。
袜子也很重要
好的徒步鞋要配好的袜子，别穿棉袜。棉袜湿了之后不干，脚泡在里面会起水泡。
推荐羊毛袜，透气排汗，走一天脚都是干的。Smartwool有点贵，但确实好用。迪卡侬的SH500也行，便宜一半，质量也过得去。
买鞋的坑
最后说几个我踩过的坑：
别网购。徒步鞋必须试穿，每个人的脚型不一样。网上买回来不合适，退换很麻烦。
别买太便宜的。100块以下的徒步鞋，鞋底软得跟拖鞋一样，走不了远路。
别买太好看的。徒步鞋是用来走路的，不是用来拍照的。好看但不实用的鞋，最后都是吃灰。
提前磨合。新鞋买回来先穿着走几次短途，别直接上长线。我第一次穿新鞋走武功山，差点没走回来。
写在最后
鞋子是徒步的根基。选对了鞋，路才走得远。
但说到底，鞋子只是工具。真正重要的，是你愿不愿意迈出那一步。
“路在脚下，鞋在脚上，远方在心里。”
]]>
    
    https://luanjiahao.qzz.io/2026/05/15/hiking-gear-recommendations/
    
    2026-05-15T04:00:00.000Z
    

      先说结论
买鞋这事，我交了不少学费。
第一双徒步鞋是迪卡侬最便宜那双，199块。走了一次千岛湖，脚踝差点废了。第二双是某宝上买的”军靴”，说是真皮防水，结果下雨天里面能养鱼。第三双是凯乐石，终于对了。
所以这篇东西，是我花了两千多块踩坑之后的总结。希望你别走我的老路。
选鞋]]>
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      先说结论
华东K2难得多，不在一个量级。
九华山南北穿越是中高级线路，走完之后你会觉得累，但还能接受。华东K2是顶级虐线，走完之后你会怀疑人生，怀疑自己为什么要来受这个罪。
但就是有人喜欢这种受罪的感觉。比如我。
详细对比
维度
华东K2
九华山南北穿越
距离
35-42km
25-30km
累计爬升
2500-3000m+
1500-2000m
耗时
2天（快腿1.5天）
2天
路况
60%野路+钻林子+攀爬
70%成熟古道
水源
极缺，全程仅2-3处
寺庙多，水源充足
下撤
几乎没有退路
多处可下撤
信号
大部分无
大部分有
华东K2为什么难
水源是生死线
K2最变态的地方是水源。
整条线只有过风坳附近有可靠水源，其他地方要么没有，要么是那种要靠运气才能找到的山涧。每人至少背3-4升水出发，夏天可能要背更多。
我走K2的时候，背了4升水，走到第二天下午还是喝完了。最后两公里是靠意志力撑到终点的，嘴唇都干裂了。
钻林子钻到怀疑人生
独竖尖到过风坳那段，是全程最崩溃的路段。
不是走，是钻。密林加箭竹，背包外挂全给你刮掉。我挂在背包上的防雨罩、登山杖、水壶，走了一公里全没了。回头去找，根本找不到，被树枝刮到不知道哪里去了。
而且那种密林里根本没有路，你只能跟着前面的人走。前面的人走哪，你就走哪。有时候前面的人走错了，你跟着也走错，然后一群人一起骂骂咧咧地往回走。
没有退路
K2进了山就只能走完。
不像武功山可以随时下撤到客栈，K2的下撤点几乎没有。你走了十公里想撤退，对不起，没有路下山，只能继续往前走。
这种感觉很可怕。你以为自己可以随时放弃，但现实告诉你不行。你只能硬着头皮往前走，走到腿软，走到想哭，但还是得走。
华东最接近”野穿”的线
K2不是景区，没有台阶，没有补给，没有救援响应。
你走的每一步都是野路，踩的每一块石头都是野生的。没有护栏，没有指示牌，没有厕所。你要是出了什么事，叫救援都不一定有人来。
这就是K2的可怕之处。它不是那种修好的景区栈道，它是真正的荒野。
九华山难在哪
爬升集中
九华山的爬升比较集中，天台峰那段海拔爬升800米+。走起来很累，但至少你知道爬完就到了。
K2的爬升是分散的，你爬完一个山头以为到了，结果前面还有一个，再前面还有一个。心理上的打击比体力上的消耗更让人崩溃。
石板路废膝盖
九华山的古道是青石板路，下雨之后极滑。我走的时候赶上下雨，好几次差点滑倒。
但至少有路。K2有些路段根本就没有路，你得自己找路。
相对友好
九华山有寺庙可以补水，有路标可以参考，多处可以下撤。走不动了可以找个寺庙休息，渴了可以找和尚要水喝。
K2什么都没有。你自己带水，自己带食物，自己找路，自己承担一切风险。
难度评分
指标
华东K2
九华山
武功山沈明线
体能要求
9
6
5
技术难度
8
4
3
心理压力
9
4
3
综合难度
8.5
5
4
进阶路线建议
如果你想挑战华东K2，建议先走完这些：
入门级
武功山沈明线
千岛湖环湖
黄山穿越
中级
九华山南北穿越
南太行
大别山主峰
高级
华东K2
鳌太穿越
狼塔C线
K2注意事项
如果你决定要走K2，这些事情必须知道：
必须组队。至少2-3人，不能独行。出了事没人帮你。
带足水源。至少3-4升/人，夏天要更多。
下载GPX轨迹。离线地图必备，没有信号的时候靠它。
选对季节。避开6-9月蛇虫高峰期，春秋季最好。
有经验再走。至少走过2-3条中级线，对自己的体能有清楚的认识。
我的选择
我走完了南太行和沈明线，下一步计划是九华山南北穿越。
K2我想走，但不着急。等经验更丰富了，体能更好了，再挑战。毕竟山永远在那里，但人只有一个。
走K2之前，先确保自己能活着回来。
“山有等级，人有阶段，循序渐进才能走得更远。”
]]>
    
    https://luanjiahao.qzz.io/2026/05/11/east-china-k2-vs-jiuhuashan/
    
    2026-05-11T14:00:00.000Z
    

      先说结论
华东K2难得多，不在一个量级。
九华山南北穿越是中高级线路，走完之后你会觉得累，但还能接受。华东K2是顶级虐线，走完之后你会怀疑人生，怀疑自己为什么要来受这个罪。
但就是有人喜欢这种受罪的感觉。比如我。
详细对比



维度]]>
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      为什么是武功山
南太行走完之后，我说三个月不背包。结果两个月就破功了。
起因是刷到一条武功山的视频，高山草甸上云海翻涌，配着那种很煽情的音乐。我看了三遍，然后默默打开了12306。
沈明线是武功山最经典的穿越路线，从沈子村出发，经过金顶、发云界，到明月山结束。三天两夜，25公里左右。听起来不多对吧？但加上1500米的累计爬升和20公斤的背包，就完全是另一回事了。
沈子村到金顶
下午三点才开始进山，这个时间点其实挺蠢的。
正常人都是早上出发，我们因为高铁晚点加上包车堵车，到沈子村已经下午了。队友说要不明天再走？我说来都来了，走吧。
“来都来了”这四个字害死人。
前半段还好，沿着溪谷往上爬，树荫遮着不太晒。但越往上越陡，太阳也开始往下走了。我看了看地图，还有三分之一的路，天已经快黑了。
最后那段路基本是摸黑爬的。头灯照着脚下的石板路，两边是黑漆漆的树林，偶尔有不知名的鸟叫。说实话有点吓人，但已经没有退路了。
晚上八点多，终于看到金顶的灯光。那一刻腿都软了，不是累的，是松了一口气。
金顶的日出
第二天早上五点被冻醒。
帐篷外面风很大，我裹着睡袋爬出来，天边已经有点发白了。金顶上已经站了不少人，都举着手机等着。
日出我没怎么拍。因为那一刻你会发现，手机根本拍不出眼睛看到的东西。云海在脚下翻涌，太阳从云层里一点一点升起来，把整个天空染成橘红色。远处的山峰在云海里若隐若现，像水墨画一样。
我站在那里，风吹得脸有点疼，但不想走。
有个大姐在旁边打电话，声音很大：”我跟你说，太美了，你快来看！”挂了电话又打：”妈，我在这边挺好的，风景可美了。”
我在旁边听着，突然有点想家。
高山草甸
从金顶到发云界，是全程最美的一段。
武功山的草甸，怎么说呢，就是那种你在照片里看到会觉得是P的那种绿色。整座山都是绿的，没有树，就是草，一直铺到天边。风吹过来，草浪一波一波的，像海一样。
走在草甸上，脚感很软，比水泥路舒服多了。但太阳很毒，没有遮阴的地方，走一会儿就一身汗。我把速干衣脱了系在腰上，光着膀子走，被队友拍了照，后来成了群里流传的表情包。
中午找了个避风的地方吃午饭，压缩饼干加榨菜，配着保温杯里的热水。说实话不好吃，但在那种环境下，什么都觉得香。
发云界的星空
晚上在发云界扎营。
这里是个垭口，风很大，帐篷搭了三次才搭好。晚上煮了泡面，加了根火腿肠，算是改善伙食了。
发云界的星空比抱犊村还好看。因为海拔高，空气干净，星星像是挂在头顶上一样。我躺在防潮垫上，看了很久。
流星看到四五颗，许了什么愿忘了。大概是什么暴富之类的俗气愿望吧。
那天晚上睡得特别好，可能是累的，也可能是海拔高空气好。反正一觉到天亮，帐篷外面的露水都结成冰了。
明月山的台阶
第三天是下山。
从发云界到明月山，路不难走，但台阶很多。武功山的台阶是那种标准的景区台阶，一级一级修得整整齐齐。对于重装徒步来说，这种台阶其实比野路更伤膝盖。
走到后面，每下一步台阶膝盖都疼。我开始用”之”字形走法，虽然慢但膝盖好受点。队友在后面笑我，说我像个螃蟹。
中午十二点到了明月山门口，腿已经抖得站不稳了。景区门口有卖水的，我买了一瓶冰可乐，一口气喝完，打了个嗝，觉得这是这辈子喝过最好喝的可乐。
费用清单
写这个是为了给想走的人参考：
项目
费用
高铁往返
约200元
包车
约100元
食品
约100元
气罐
约25元
总计
约425元
不贵对吧？但你得付出体力和膝盖。
给后来者的建议
早点出发。别学我们下午三点才进山，摸黑爬山不好玩。
带够水。金顶有卖水的，但贵。自己带够3-4升。
防晒。草甸上没遮阴，不涂防晒会脱皮。
护膝。下山那段台阶真的要命。
带件厚衣服。金顶晚上冷，五月去都得穿抓绒。
后记
武功山回来后，我休息了一个星期。每天上班、下班、回家躺着，看着天花板发呆。
但脑子里一直在想那些草甸、那些云海、那些星空。
有人说武功山是华东徒步的天花板，我觉得不是。天花板意味着到顶了，但每次走完一条线，我都会发现还有更远的地方想去。
可能这就是徒步的魔力吧。你以为你在看风景，其实是在看自己。
“山不向我走来，我便向山走去。”
]]>
    
    https://luanjiahao.qzz.io/2026/04/26/wugongshan-shenming-line/
    
    2026-04-26T10:00:00.000Z
    

      为什么是武功山
南太行走完之后，我说三个月不背包。结果两个月就破功了。
起因是刷到一条武功山的视频，高山草甸上云海翻涌，配着那种很煽情的音乐。我看了三遍，然后默默打开了12306。
沈明线是武功山最经典的穿越路线，从沈子村出发，经过金顶、发云界，到明月山结束。三天两夜，25公里左右。听起来不多对吧？但加上1500米的累计爬升和20公斤的背包，就完全是另一回事了。
<]]>
    
    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
      一个人的周末
周六早上醒来，看了眼手机，八点半。
窗外在下雨，不是那种哗哗的大雨，是那种细细密密的小雨，下起来就没完没了的那种。我躺在床上，看着天花板发呆，想着今天干点什么。
加班？不想。打游戏？没意思。刷短视频？刷了一小时更空虚。
最后我做了一个可能不太理智的决定：去爬山。
为什么是雨天
说实话，雨天爬山不是个好主意。
路滑，视线差，容易失温，手机可能没信号。任何一个户外博主都会告诉你，雨天不要进山。
但我就是想出去。
可能是因为连续加了三个星期的班，可能是因为昨天跟客户吵了一架，也可能就是因为在家待着太闷了。总之，我穿上冲锋衣，背上包，出门了。
山里的雨
开车到了山脚下，雨还在下。
停车场就我一辆车。我看了眼天气预报，下午三点会停。现在十点，还有五个小时。我带了足够的水和食物，冲锋衣防水，背包有防雨罩。应该没问题。
进山之后，雨声变得不一样了。打在树叶上是沙沙的声音，打在石头上是哒哒的声音，打在冲锋衣的帽子上是咚咚的声音。这些声音混在一起，反而让人觉得安静。
是那种真正的安静。不是办公室里的安静，那种安静里有空调的嗡嗡声、键盘的敲击声、同事小声打电话的声音。这里的安静，是真的什么都没有，只有雨声和你自己的呼吸声。
溪流
雨天的溪流比平时好看。
水量大了，流得急了，冲击石头的声音也响了。我沿着溪流往上走，看着浑浊的水流从山里涌出来，带着树叶和树枝。
有个地方溪水漫过了小路，我得踩着石头过去。石头上长满了青苔，滑得要命。我小心翼翼地踩上去，脚还是滑了一下，差点掉进水里。最后靠登山杖撑住了，但裤腿湿了一半。
站在溪边，看着水流从脚边冲过去，突然觉得有点好笑。我一个程序员，周末不打游戏不睡觉，跑到山里来淋雨，图什么呢？
但就是觉得开心。说不出来的那种开心。
雾
走到半山腰的时候，起雾了。
雾很大，能见度不到十米。路两边的树都看不清了，只能看见脚下的路和前面几米的山路。整个世界都变成了灰白色的，像是被什么东西吞掉了一样。
我停下来，站在雾里，听着雨声。
那一刻突然有种奇怪的感觉，像是世界只剩下我一个人了。不是孤独的那种感觉，是一种很平静的感觉。好像所有的烦恼、所有的压力、所有那些乱七八糟的事情，都被这场雾吞掉了。
我站在那里，不知道站了多久。可能五分钟，可能十分钟。直到一阵风吹过来，冷得我打了个哆嗦，才继续往前走。
山顶
到了山顶，雾更大了。
本来看天气预报说下午三点会停雨，结果两点了还在下。我找了个避风的地方，坐在石头上吃午饭。压缩饼干、火腿肠、保温杯里的热水。不好吃，但在这种环境下，什么都觉得香。
山顶没有风景可看，全是雾。但我也不在乎。本来就是为了出来走走，不是为了看什么风景。
吃完午饭，我决定下山。不是因为累了，是因为突然想起明天还有个需求要上线，得回去看看代码。
下山
下山的路上，雨小了。
走到山脚的时候，雨停了，太阳从云层里钻出来。我回头看了一眼山上，雾正在散开，露出绿色的山体。
停车场里多了几辆车，大概是下午来爬山的人。我换了身干衣服，开车回家。
路上打开手机，微信消息刷了两百多条。工作群在讨论明天的需求，朋友圈有人在晒周末的下午茶。我关掉手机，继续开车。
写在最后
那天晚上，我睡得特别好。
不是因为累，是因为心里干净了。那些烦人的事情还在，工作还是要做的，客户还是要应付的。但好像没那么烦了。
可能这就是徒步的意义吧。不是为了征服什么山，不是为了发朋友圈，就是为了找个地方，让自己的脑子安静一会儿。
雨天的山，没有人，没有风景，但有安静。
有时候，安静就够了。
“山不一定要晴天才好看，就像人生不一定要完美才值得过。”
]]>
    
    https://luanjiahao.qzz.io/2026/04/12/weekend-mountain-rain/
    
    2026-04-12T12:00:00.000Z
    

      一个人的周末
周六早上醒来，看了眼手机，八点半。
窗外在下雨，不是那种哗哗的大雨，是那种细细密密的小雨，下起来就没完没了的那种。我躺在床上，看着天花板发呆，想着今天干点什么。
加班？不想。打游戏？没意思。刷短视频？刷了一小时更空虚。
最后我做了一个可能不太理智的决定：去爬山。

    

    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
    
      出发前的纠结
说实话，出发前一晚我差点放弃。
天气预报显示周末有雨，南太行的碎石坡下雨天有多滑我是见识过的。但机票买好了，包车也约好了，群里几个兄弟已经到了新乡。算了，死就死吧。
凌晨四点从郑州出发，天还没亮。司机老张是本地人，开了三个小时山路，把我们扔在马武寨村口。村口有条狗看了我们一眼，又继续睡了，大概是见惯了我们这种背着大包的人。
碎石坡教会我做人
前两公里还算友好，沿着溪谷走，水清得能看见底下的石头。我还跟队友开玩笑说这趟轻松。
然后碎石坡来了。
南太行的碎石坡，怎么说呢，就是那种你踩上去一块石头，下面三块跟着动的地形。我背着20公斤的包，每一步都走得小心翼翼。走到一半，前面有个哥们滑了一跤，屁股着地滑下去两米，背包上的防雨罩直接刮烂了。
我在后面看着，默默把登山杖握紧了。
七星潭
翻过碎石坡，膝盖已经开始发抖。但转过一个弯，七星潭突然出现在眼前。
那一刻真的会愣住。
碧绿色的水，红色的石头，两边是刀切一样的悬崖。阳光从缝隙里照下来，水面闪着光。我站在那里看了好几分钟，忘了膝盖疼这件事。
有个队友说像九寨沟，我觉得比九寨沟野。九寨沟太精致了，这里还有点荒，有点危险，但就是这种感觉让人上瘾。
红石河
继续往前走，到了红石河。
整条河床都是红色的石头，水流不急，清清凉凉的。我们几个脱了鞋，坐在石头上泡脚，吃压缩饼干。旁边有个大姐在洗衣服，看了我们一眼，大概觉得这群城里人有病。
那天下午的阳光很好，晒得人懒洋洋的。我躺在石头上，看着天上的云，突然觉得这才是生活该有的样子。不是在办公室里对着电脑，不是在地铁里被人挤成照片，而是躺在太行山的石头上，听着水声发呆。
抱犊村的夜晚
晚上住在抱犊村。
这村子在悬崖上面，进出就一条路，真的是与世隔绝。村里没几户人家，我们住的农家，老板娘做的面条特别好吃，我吃了三碗。
晚上没有信号，没有wifi，我们几个坐在院子里看星星。太行山的星空，怎么说呢，就是那种你抬头看会觉得有点不真实的程度。银河清清楚楚地挂在天上，偶尔有流星划过。
有个队友说他上一次看星星还是小时候在老家。我说我也是。
那一刻突然觉得，我们拼命工作、拼命赚钱，最后可能就是想找回小时候躺在院子里看星星的那种感觉吧。
第二天的崩溃
第二天早上起来，腿已经不是自己的了。
从抱犊村到韩口，说是下坡为主，但南太行的下坡也是那种要命的下坡。石板路、悬崖栈道、密林钻来钻去。有段路贴着悬崖走，我往下看了一眼，腿直接软了。
我是有点恐高的。
但走都走了，总不能飞下去。我贴着山壁，一步一步挪，手心全是汗。队友在前面喊”别看下面”，我心想你不说我还不想看呢。
八里沟
快到韩口的时候，经过八里沟。
北方的九寨沟，有人这么叫它。水确实清，清得能看见水底的鱼。但我觉得八里沟比九寨沟好的地方在于，它没那么多人。我们去的时候，整个景区就我们几个人。
坐在瀑布下面，水雾打在脸上，凉凉的。我突然想起去年在办公室加班到凌晨三点的日子，觉得此刻就像做梦一样。
回程
从韩口出来，包车回新乡，然后高铁回郑州。
在高铁上，我靠着窗户，看着窗外飞速后退的风景。腿疼得要命，脚底两个水泡，肩膀被背包勒出两道红印。但心里是满足的。
手机恢复信号后，群里消息刷了一百多条。老板问我周一能不能早点到，同事在讨论下个季度的KPI。我关掉手机，又看了一会儿窗外。
写在最后
南太行这条线，说实话不轻松。20公斤的负重，碎石坡、悬崖栈道、恐高。走完之后我发誓三个月内不背包了。
但两个月后，我又在看武功山的攻略了。
人就是这么贱。
有人说徒步是自虐，我觉得不是。徒步是让你暂时离开那个被手机、被工作、被各种deadline绑架的世界，回到最简单的生活状态——走路、吃饭、睡觉、看风景。
就这么简单。
“太行山教会我一件事：路是走出来的，不是想出来的。”
]]>
    
    https://luanjiahao.qzz.io/2026/03/20/nantaihang-hiking/
    
    2026-03-20T10:00:00.000Z
    

      出发前的纠结
说实话，出发前一晚我差点放弃。
天气预报显示周末有雨，南太行的碎石坡下雨天有多滑我是见识过的。但机票买好了，包车也约好了，群里几个兄弟已经到了新乡。算了，死就死吧。
凌晨四点从郑州出发，天还没亮。司机老张是本地人，开了三个小时山路，把我们扔在马武寨村口。村口有条狗看了我们一眼，又继续睡了，大概是见惯了我们这种背着大包的人。

    
    
    
    
      被问过的问题
“你为什么要去徒步？”
这个问题我被问过很多次。同事问，朋友问，家人问。他们看着我周末背着大包出门，周一瘸着腿回来，觉得很不理解。
“有这时间在家躺着不好吗？”
“花钱买罪受？”
“你是不是有什么想不开的？”
说实话，我也问过自己这个问题。
最初的原因
最开始徒步，是因为想减肥。
那时候我刚工作两年，天天加班，外卖，久坐，体重飙到170斤。体检报告好几个箭头朝上，医生说再这样下去不行。
我想运动，但跑步太无聊，健身房太贵，打球要凑人。后来看到有人徒步，觉得这个好，不用花钱，不用凑人，一个人就能干。
于是就去了。
第一次徒步
第一次徒步去的是本地的一座小山，十公里不到。
我以为很简单，穿着运动鞋就去了。结果走了一半，脚就疼了。鞋底太软，踩在石头上硌得慌。走到山顶，累得跟狗一样，坐在地上喘了半小时。
但下山的时候，我突然觉得，这种累和加班的累不一样。
加班的累是那种闷在心里的累，身体不累，但心累。徒步的累是那种纯粹的累，腿酸，出汗，喘气，但脑子是空的。
那一刻我好像明白了为什么有人喜欢徒步。
后来
后来我开始走更远的路。
从十公里到二十公里，从一日游到重装穿越。装备也越来越专业，从运动鞋到登山鞋，从双肩包到重装背包，从矿泉水到保温杯。
体重倒是没怎么减，可能是因为走完之后吃得更多了。
但我发现，徒步给我的东西，比减肥重要多了。
徒步教会我的事
第一件事：专注
徒步的时候，你只能想一件事：走路。
看脚下，踩哪里，下一步怎么走。你的脑子被这些简单的事情填满了，没有空间去想工作上的烦心事，没有空间去想房贷和KPI。
这种专注的感觉，在日常生活中太稀缺了。我们每天被手机、被消息、被各种事情打断，很难真正专注在一件事上。但徒步的时候，你不得不专注。
第二件事：耐心
徒步是一个慢过程。
你不能一下子到山顶，你得一步一步走。有时候走了两个小时，抬头一看，山顶还在云里面。那种感觉会让人崩溃，但你没有选择，只能继续走。
这和生活很像。很多目标不是一下子就能达到的，你得慢慢来。但现代人太着急了，什么都想快，想快速成功，想快速致富，想快速减肥。
徒步教会我，有些事情急不来。
第三件事：接受
徒步的时候，你会遇到很多意外。
天气变化，路线走错，装备出问题，身体不舒服。这些事情你控制不了，你只能接受，然后想办法应对。
生活也是这样。计划赶不上变化，你能做的就是接受现实，然后往前走。
第四件事：简单
徒步的时候，生活变得很简单。
走路，吃饭，睡觉。没有复杂的人际关系，没有烦人的工作邮件，没有无意义的社交。你只需要关注最基本的需求：水、食物、休息。
这种简单的感觉，让人上瘾。
关于意义
有人问我，徒步有什么意义？
说实话，我不知道。
徒步不能让我升职加薪，不能让我买房买车，不能让我变得更帅更有魅力。相反，它让我花钱，让我受伤，让我变黑。
但我就是喜欢。
喜欢走在山里的感觉，喜欢站在山顶看风景的感觉，喜欢晚上躺在帐篷里听雨声的感觉。这些感觉不能当饭吃，但能让饭吃得更香。
关于孤独
徒步大部分时间是孤独的。
一个人走在山里，没有聊天对象，只能和自己说话。有时候会想很多事，有时候什么都不想。
我以前害怕孤独，觉得一个人待着会胡思乱想。但徒步之后发现，孤独没那么可怕。相反，孤独的时候，你才能真正面对自己。
那些平时被忙碌掩盖的问题，在孤独的时候会浮现出来。你得面对它们，解决它们，或者接受它们。
这大概是徒步给我最大的礼物。
写在最后
为什么要去徒步？
我现在可以回答这个问题了。
不是为了减肥，不是为了发朋友圈，不是为了证明什么。就是为了暂时离开那个被手机、被工作、被各种deadline绑架的世界，回到最简单的生活状态。
走路，吃饭，睡觉，看风景。
就这么简单。
有人说徒步是逃避，我觉得不是。逃避是不想面对，徒步是为了更好地面对。你走了一圈回来，那些问题还在，但你看问题的角度变了。
这就是徒步的意义。
不是逃避，是充电。
“山就在那里，所以我去。”
]]>
    
    https://luanjiahao.qzz.io/2026/03/01/why-i-hike/
    
    2026-03-01T12:00:00.000Z
    

      被问过的问题
“你为什么要去徒步？”
这个问题我被问过很多次。同事问，朋友问，家人问。他们看着我周末背着大包出门，周一瘸着腿回来，觉得很不理解。
“有这时间在家躺着不好吗？”
“花钱买罪受？”
“你是不是有什么想不开的？”
说实话，我也问过自己这个问题。

    

    
    2026-08-28T11:20:48.104Z
  
  
    
      YFGUG
    
    
    
    
    
    
      承认失败
今天写这篇，是想记录一次失败的徒步。
不是那种”虽然很累但最后还是成功了”的故事，是真的没走完，半路撤了的那种。以前觉得这种事挺丢人的，不愿意说。但后来想想，失败也是经历的一部分，不丢人。
出发
那是去年十二月的事。
我想走一条本地的穿越线，不长，十五公里左右，一天能走完。看了天气预报，晴天，温度五度左右。我觉得没问题，背上包就出发了。
那天的状态其实不太好。前一晚失眠，只睡了四个小时。早上起来有点头疼，但我觉得走走路就好了。
这是我犯的第一个错误：身体不舒服还要硬撑。
山里的变化
进山的时候天气还不错，阳光照在身上暖暖的。
但走了两公里之后，天开始阴了。山区的天气变化快，我是知道的，但没想到这么快。十点的时候开始起风，十一点开始下雨夹雪。
我穿的是冲锋衣和抓绒裤，防水是防水，但不保暖。风一吹，冷得直哆嗦。我加快了脚步，想赶紧走到山顶的亭子避一避。
这是我犯的第二个错误：天气变化没有及时调整计划。
滑倒
走到一半的时候，路开始变滑了。
雨夹雪落在石头上，结了一层薄冰。我穿着普通登山鞋，鞋底的防滑纹路已经磨平了。每一步都走得小心翼翼，但还是滑倒了。
是那种脚一滑、屁股着地的滑法。不严重，就是裤子湿了，屁股有点疼。我爬起来继续走，但心里开始打鼓了。
又走了几百米，又滑了一次。这次是侧着滑的，膝盖磕在石头上，疼得我倒吸一口冷气。
我蹲在那里，看着膝盖上的淤青，开始认真考虑要不要撤。
撤退的决定
说实话，撤退的决定不好做。
我已经走了六公里了，再走三公里就是山顶，然后就是下坡。如果现在撤，今天就白来了。而且我跟朋友说过要走这条线，空手回去多没面子。
但我又想了想：如果继续走，还有六公里的路，天气在变差，我的膝盖已经青了，鞋子不防滑，手机信号时有时无。万一出了什么事，叫救援都不方便。
最后我决定撤。
面子不值钱，膝盖值钱。
下山的路
下山的路比上山还难走。
上坡的时候还能控制重心，下坡的时候腿在抖，根本控制不住。我几乎是蹲着一步一步挪下去的，登山杖撑在地上，手都握麻了。
走到山脚的时候，天已经黑了。我钻进车里，打开暖风，换了身干衣服，然后发现自己的手在抖。
不是冷的，是后怕。
教训
那次之后，我给自己定了几条规矩：
身体不舒服不要硬撑。 失眠、感冒、头疼，任何不舒服都不进山。
天气变化要及时调整。 起风了就加衣服，下雨了就考虑撤退，别赌运气。
鞋子一定要防滑。 我后来换了Vibram大底的鞋，再也没滑过。
手机要有信号。 走之前查一下路线，哪里有信号哪里没有。如果全程没信号，要么别走，要么带卫星电话。
撤退不丢人。 山一直在那里，下次再来就好了。但膝盖坏了，就真的完了。
后来
后来我又走过那条线。
是春天去的，天气很好，花开得漫山遍野。我走完全程，站在山顶，看着远处的风景，想起冬天那次撤退。
没有遗憾，反而有点庆幸。如果那次没有撤，我可能就不敢再来了。
失败不可怕，可怕的是因为一次失败就不敢再尝试。
“山永远在那里，但人只有一个人。”
]]>
    
    https://luanjiahao.qzz.io/2026/02/15/failed-hiking-trip/
    
    2026-02-15T11:00:00.000Z
    

      承认失败
今天写这篇，是想记录一次失败的徒步。
不是那种”虽然很累但最后还是成功了”的故事，是真的没走完，半路撤了的那种。以前觉得这种事挺丢人的，不愿意说。但后来想想，失败也是经历的一部分，不丢人。
出发
那是去年十二月的事。
我想走一条本地的穿越线，不长，十五公里左右，一天能走完。]]>
    
    
    2026-08-28T11:20:48.104Z