编程 RuView 深度解剖：9 美元的 ESP32 用 WiFi"看穿"墙壁——CSI 感知、生命体征检测与一次被撤回的 100% 准确率

2026-07-25 04:43:50 +0800 CST views 4

RuView 深度解剖：9 美元的 ESP32 用 WiFi"看穿"墙壁——CSI 感知、生命体征检测与一次被撤回的 100% 准确率

一、背景：当你家的路由器变成一台"雷达"

先说一个反直觉的物理事实：你家里的 WiFi 路由器，从开机那一刻起，就一直在"扫描"整个房间。

2.4GHz 的电磁波以每秒几十亿次的频率在你的客厅里来回反弹。你走过去倒杯水，波形变了；你坐在沙发上呼吸，波形变了；甚至你的心脏每一次收缩泵血，胸腔表面那不到一毫米的位移，都会在电磁波的相位上留下痕迹。

过去这些"扰动"被通信工程师当成噪声——WiFi 芯片的均衡器存在的意义就是把它们抹掉，保证你的 Netflix 不卡。但从感知的角度看，噪声就是信号。这些扰动里编码了房间里有几个人、他们在哪、在做什么、呼吸频率是多少。

这个方向学术界玩了十几年。CMU 在 2023 年发过著名的 WiFi DensePose 论文，用三根天线的 TP-Link 路由器重建人体姿态，当时的硬件门槛是研究级 NIC（Intel 5300、Atheros AR9580）加一套复杂的驱动 hack，普通开发者根本摸不到。

2026 年初开源的 RuView（原名 WiFi DensePose，GitHub: ruvnet/RuView）把这件事的门槛打到了 9 美元——一块 ESP32-S3 开发板。项目在 GitHub 上迅速冲过 5 万 Star，登上 Trending 榜首，被社区称为"WiFi 感知的 iPhone 时刻"。

它宣称能做到：

存在检测：隔墙检测人的存在、计数、追踪进出
生命体征：非接触测呼吸（6–30 BPM）和心率（40–120 BPM）
活动识别：走动、坐下、手势、跌倒检测（< 200ms 响应）
姿态估计：17 关键点人体姿态（这个后面要重点"冷思考"）
睡眠监测：睡眠分期 + 呼吸暂停筛查

全程无摄像头、无穿戴设备、无云端依赖，纯边缘计算。

这篇文章我会从第一性原理拆解它的技术栈：CSI 到底是什么、ESP32 上怎么采集、Rust 服务端的信号处理流水线怎么跑、呼吸心率检测的 DSP 原理是什么，最后聊聊这个项目最值得尊敬的一点——它公开撤回了自己此前宣传的 100% 准确率。这在开源营销满天飞的 2026 年，比技术本身更稀缺。

二、核心概念：CSI 不是 RSSI，差了整整一个维度

2.1 RSSI：一个标量的贫瘠

大部分人对"WiFi 信号强度"的认知停留在手机上那几格信号，对应的技术指标是 RSSI（Received Signal Strength Indicator）。RSSI 是一个标量——整个信道所有子载波能量叠加后的一个总和值，单位 dBm。

用 RSSI 做人体感知，就像隔着毛玻璃看电影：你能感觉到"有东西在动"（RSSI 波动），但仅此而已。人站着不动？RSSI 几乎没变化。想测呼吸？做梦。

2.2 CSI：一个矩阵的富饶

CSI（Channel State Information，信道状态信息）完全是另一个物种。

现代 WiFi 用 OFDM（正交频分复用）调制，把 20MHz 的信道切成几十个子载波（802.11n 下 HT20 有 56 个数据子载波，ESP32 能吐出 64 个点的 LLTF/HT-LTF 数据）。CSI 就是每个子载波上信道响应的复数值——同时包含幅度和相位：

H(f_k) = |H(f_k)| · e^{j·∠H(f_k)},  k = 1, 2, ..., N_subcarrier

物理意义：发射端发出的已知训练序列（LTF），经过空间中所有路径（直射、墙面反射、人体反射）叠加后到达接收端，每个子载波经历的衰减和相移都不同。CSI 矩阵就是这个多径信道的"快照"。

关键洞察在于相位的敏感度。2.4GHz 电磁波波长约 12.5cm。这意味着反射路径长度每变化 12.5cm，相位就转过一整圈 2π。人呼吸时胸腔起伏约 5mm，对应的相位变化约为：

Δφ = 2π · (2 × 0.005) / 0.125 ≈ 0.5 rad ≈ 29°

（乘 2 是因为反射路径来回都变长）。29 度的相位变化，对现代 ADC 来说是清晰可测的大信号。这就是"WiFi 测呼吸"的物理基础——不是玄学，是干涉仪原理，和 LIGO 测引力波是同一个思路，只是精度差了二十几个数量级。

2.3 菲涅尔区：为什么"穿墙"是真的，但有条件

RuView 宣称支持穿墙感知（up to ~5m, signal-dependent），原理是菲涅尔区（Fresnel Zone）模型。

发射端 TX 和接收端 RX 之间的电磁波传播不是一条几何直线，而是一系列椭球壳。人体在第一菲涅尔区内移动时，会周期性地增强/削弱接收信号（反射波与直射波同相叠加或反相抵消），形成可辨识的干涉条纹。

墙对 2.4GHz 信号的衰减大约是：

石膏板墙：3–5 dB
砖墙：6–10 dB
混凝土承重墙：10–20 dB+

穿一堵石膏板墙后信号仍在可用范围，所以"隔墙检测人的存在"是物理上成立的。但注意 README 里那个诚实的限定词：signal-dependent。穿两堵混凝土墙检测心率？不存在的。这是这个项目文档风格的一个缩影——夸张的标题，但细节处标注限制条件。

三、架构分析：三层流水线 + 一个 Rust 内核

RuView 的整体架构是清晰的三层：

┌─────────────────────────────────────────────────────┐
│  感知层：ESP32-S3/C6 节点 × N ($9/个)                │
│  ESP-IDF 固件, 提取 CSI → UDP 包                     │
└──────────────────┬──────────────────────────────────┘
                   │ UDP :5005 (原始 CSI 帧)
┌──────────────────▼──────────────────────────────────┐
│  处理层：Rust 服务端 (Axum + Tokio)                  │
│  解析 → 相位解缠 → 滤波 → 特征提取 → 推理            │
│  HTTP :3000 (REST API + Web UI)                     │
│  WebSocket :8765 (实时数据流)                        │
└──────────────────┬──────────────────────────────────┘
                   │ MQTT / HAP / Matter
┌──────────────────▼──────────────────────────────────┐
│  应用层：Home Assistant / Apple Home / Alexa        │
│  21 个实体/节点 (11 原始信号 + 10 语义状态)          │
└─────────────────────────────────────────────────────┘

3.1 感知层：ESP32 为什么是 Game Changer

在 RuView 之前，采集 CSI 的标准姿势是买一块 Intel 5300 网卡（停产多年，二手市场溢价），刷 Linux CSI Tool 魔改驱动，供着一台 x86 工控机。整套下来几百美元，而且驱动只支持特定内核版本。

乐鑫（Espressif）在 ESP-IDF 里官方开放了 esp_wifi_set_csi_rx_cb() 接口——每收到一个 WiFi 帧，回调里直接给你 CSI 原始数据。一块 ESP32-S3（8MB Flash + 8MB PSRAM）零售价 9 美元，功耗不到 1W，自带 WiFi 前端。

这是典型的"工具民主化引爆生态"：技术十年前就有，但当采集设备从 500 美元 + 内核编译，变成 9 美元 + pip install esptool，玩的人数直接差三个数量级。

RuView 还支持 ESP32-C6（$6–10），这块芯片支持 WiFi 6（802.11ax），可以做 HE-LTF 子载波标记和 TWT（Target Wake Time）省电调度。v0.7.0 固件用 ESP-NOW 做了跨板 mesh 时间同步，两块板子的时钟偏移平滑后标准差 104µs——多节点感知需要精确时间对齐，这是做三角定位的前提。

3.2 处理层：为什么是 Rust

服务端技术栈是 Rust + Axum + Tokio + WebSocket，前端是原生 HTML/CSS/JS + Three.js。选 Rust 不是赶时髦，是这个场景的刚需：

吞吐：一个 ESP32 节点每秒可以推几百帧 CSI，每帧 64 个子载波 × 复数。多节点 mesh 下，服务端要做实时 FFT、带通滤波、矩阵运算。项目宣称处理能力达 54000 帧/秒、延迟低于 100µs/帧——这个量级用 Python 裸写会当场去世，用 Rust 是自然选择。
部署：单二进制，交叉编译到 ARM，直接跑在树莓派上。Docker 镜像官方支持 amd64 + arm64 双架构。
确定性：GC 暂停对实时信号处理是灾难。心率检测靠的是 0.8–2.0Hz 的微弱周期信号，采样抖动会直接污染频谱。

同时项目通过 PyO3 打包了 Python wheel（~250KB, abi3-py310），pip install ruview 就能用 Python 调 Rust 内核——性能和易用性两头占。这个"Rust 内核 + Python 皮"的模式，已经是 2026 年高性能开源项目的标准答案（polars、pydantic-core、ruff 全是这个路子）。

3.3 信号处理流水线：从原始 CSI 到"有人在呼吸"

核心流水线可以抽象成六级：

原始CSI → 相位解缠 → 静态杂波消除 → 带通滤波 → 特征提取 → 分类/回归

第一级：相位解缠（Phase Unwrapping）。 ESP32 输出的相位被折叠在 (-π, π] 区间，且叠加了 CFO（载波频偏）、SFO（采样频偏）带来的线性相位斜坡。经典处理是对子载波维做线性拟合去斜：

φ_clean(k) = φ_raw(k) - (a·k + b)
其中 a, b 由最小二乘拟合得到

第二级：静态杂波消除。 房间里的墙、家具产生的反射是静态的，表现为 CSI 的直流分量。减掉滑动窗口均值，剩下的就是动态分量——人。

第三级：带通滤波。 呼吸带 0.1–0.5Hz（对应 6–30 BPM），心率带 0.8–2.0Hz（对应 48–120 BPM）。两个频带天然分离，可以并行提取。

第四级：特征提取。 RuView 用的技巧包括圆方差（circular variance，衡量相位散布）、过零率估 BPM、运动频带能量、相位加速度（跌倒检测用它做阈值 + 3 帧防抖 + 5 秒冷却）。

第五级：推理。 一个 128 维对比学习编码器（发布在 Hugging Face ruvnet/wifi-densepose-pretrained），4-bit 量化后只有 8KB，在 M4 Pro 上能跑 164183 embedding/s。同时保留了一条无模型的相位方差 fallback 路径——模型挂了，规则兜底，这是工程上很成熟的降级设计。

8KB 的模型值得多说一句。这个尺寸意味着它能塞进 ESP32 的 RAM 直接在端上跑，连树莓派都不需要。深度学习社区痴迷于 scaling law 的这几年，"把模型做小到能跑在 9 美元芯片上"是另一条被低估的技术路线。

四、代码实战：从零搭一套 WiFi 感知系统

4.1 五分钟无硬件体验（Docker 模拟数据）

docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest
# 浏览器打开 http://localhost:3000

模拟数据模式跑通整个 UI 和 API，适合先看清系统全貌再决定是否买板子。

4.2 ESP32-S3 真机部署

刷固件 + 配网两条命令：

# 刷入预编译固件
python -m esptool --chip esp32s3 --port /dev/ttyUSB0 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin

# 配置 WiFi 和服务端地址
python firmware/esp32-csi-node/provision.py --port /dev/ttyUSB0 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

一个真实的坑：v0.1.0 到 v0.4.0 的所有预编译固件都有一个致命 bug——sdkconfig 里 CONFIG_ESP_WIFI_CSI_ENABLED 没打开，固件跑起来直接崩：

E (6700) wifi:CSI not enabled in menuconfig!

一个以 CSI 为核心卖点的项目，连发四个版本的官方固件里 CSI 是关着的。v0.4.1 修复时加了编译期断言：

// csi_collector.c
#ifndef CONFIG_ESP_WIFI_CSI_ENABLED
#error "CSI must be enabled in menuconfig (CONFIG_ESP_WIFI_CSI_ENABLED=y)"
#endif

这个事故的教训比修复本身值钱：配置文件也是代码，关键配置必须有编译期或启动期的强校验。靠人眼 review 一个 1135 行的 sdkconfig，等于没有 review。如果你自己写 ESP-IDF 项目，请把这个 #error 模式抄走。

4.3 自己写一个最小 CSI 采集固件

如果不想用官方固件，ESP-IDF 下自己撸一个 CSI 采集器只需要几十行 C：

#include "esp_wifi.h"
#include "lwip/sockets.h"

static int udp_sock;
static struct sockaddr_in server_addr;

// CSI 回调：每收到一个带 CSI 的帧触发一次
static void csi_rx_cb(void *ctx, wifi_csi_info_t *info) {
    // info->buf: 原始 CSI 数据 (int8_t 交替的虚部/实部)
    // info->len: 数据长度; info->rx_ctrl: RSSI/信道/时间戳等元数据
    uint8_t packet[512];
    int offset = 0;

    // 打包元数据：时间戳 + RSSI + 信道
    memcpy(packet + offset, &info->rx_ctrl.timestamp, 4); offset += 4;
    packet[offset++] = info->rx_ctrl.rssi;
    packet[offset++] = info->rx_ctrl.channel;

    // 打包 CSI 原始数据
    memcpy(packet + offset, info->buf, info->len);
    offset += info->len;

    sendto(udp_sock, packet, offset, 0,
           (struct sockaddr *)&server_addr, sizeof(server_addr));
}

void csi_init(void) {
    wifi_csi_config_t csi_cfg = {
        .lltf_en = true,           // Legacy LTF (64 子载波)
        .htltf_en = true,          // HT LTF
        .stbc_htltf2_en = true,
        .ltf_merge_en = true,
        .channel_filter_en = false, // 不滤信道，全收
        .manu_scale = false,
    };
    ESP_ERROR_CHECK(esp_wifi_set_csi_config(&csi_cfg));
    ESP_ERROR_CHECK(esp_wifi_set_csi_rx_cb(csi_rx_cb, NULL));
    ESP_ERROR_CHECK(esp_wifi_set_csi(true));   // 别忘了这行，以及 menuconfig!
}

要点：

回调里不要做重活。csi_rx_cb 跑在 WiFi 任务上下文里，阻塞会丢帧。打包 + UDP 发送已经是上限，滤波推理全部放服务端。
CSI 数据格式是 int8 的虚实交替数组，第 k 个子载波 = buf[2k+1] + j·buf[2k]（注意乐鑫是虚部在前）。
触发源：CSI 是收到 WiFi 帧才产生的。房间里没有流量就没有 CSI。所以感知节点通常自己周期性发 ping 或者靠路由器 beacon（默认 100ms 一个，即 10Hz 采样率——够测呼吸，测心率勉强）。想要更高采样率，让节点之间互发 UDP 包即可。

4.4 Python 端：30 行代码提取呼吸曲线

RuView 发布了 PyPI 包（ruview 和 wifi-densepose 是同一个 wheel 的双别名）：

pip install "ruview[client]"

import asyncio
import numpy as np
from ruview import BreathingExtractor, HeartRateExtractor
from ruview.client import SensingClient

async def main():
    # 连接 Rust 服务端的 WebSocket 实时流
    client = SensingClient("ws://192.168.1.20:8765")
    breathing = BreathingExtractor(sample_rate=20)   # 20Hz CSI 帧率
    heart = HeartRateExtractor(sample_rate=20)

    async for frame in client.stream():
        # frame.phase: 相位解缠后的子载波相位矩阵
        b = breathing.push(frame.phase)
        h = heart.push(frame.phase)
        if b.ready:
            print(f"呼吸: {b.bpm:.1f} BPM (置信度 {b.confidence:.2f})")
        if h.ready:
            print(f"心率: {h.bpm:.0f} BPM (置信度 {h.confidence:.2f})")

asyncio.run(main())

底层是 Rust 实现的 DSP，Python 只是胶水。如果想理解原理，呼吸提取的核心逻辑用 scipy 复现大概是这样：

from scipy.signal import butter, sosfiltfilt

def extract_breathing_bpm(phase_series, fs=20):
    """phase_series: 单个子载波的相位时间序列, fs: 采样率"""
    # 1. 带通滤波 0.1-0.5 Hz (6-30 BPM)
    sos = butter(4, [0.1, 0.5], btype="bandpass", fs=fs, output="sos")
    filtered = sosfiltfilt(sos, phase_series)

    # 2. 过零率估计频率
    zero_crossings = np.where(np.diff(np.signbit(filtered)))[0]
    duration = len(phase_series) / fs
    # 每两个过零点 = 半个周期
    freq_hz = len(zero_crossings) / (2 * duration)
    return freq_hz * 60   # 转 BPM

工程上真正难的不是这段滤波，而是子载波选择：64 个子载波里，哪些对当前人体位置敏感？RuView 用圆方差排序，选相位波动最"有规律"的子载波投票。人换了个位置，敏感子载波集合就变了，需要动态重选——这是所有 WiFi 感知系统鲁棒性的命门。

4.5 接入 Home Assistant：一个 flag 的事

ruview-server --mqtt mqtt://homeassistant.local:1883

通过 MQTT Discovery 协议，每个节点自动注册 21 个实体：11 个原始信号（RSSI、运动能量、呼吸率……）+ 10 个推断语义状态，包括：

someone-sleeping（有人在睡觉）
possible-distress（疑似异常/求救）
elderly-inactivity-anomaly（老人异常静止）
fall-risk-elevated（跌倒风险升高）
bed-exit（离床检测）
bathroom-occupied（卫生间占用）

看到这个列表你就明白这个项目真正瞄准的市场了：养老看护。摄像头装在卧室和卫生间是隐私灾难，穿戴设备老人不爱戴、忘充电。WiFi 感知是这个场景下几乎唯一"既有效又体面"的技术路线。独居老人跌倒检测 + 离床异常 + 呼吸监护，一套 54 美元的 3 节点 mesh 就能覆盖——这是真实的、巨大的、还没被做烂的需求。

五、性能与工程细节：那些藏在 ADR 里的干货

RuView 的代码仓库里有 100 多份 ADR（Architecture Decision Record），这本身就是值得学习的工程实践。挑几个有信息量的：

多频段 mesh（ADR-029）：节点在 6 个 WiFi 信道间跳频扫描，TDM 时隙调度，甚至把邻居家路由器的信号当免费雷达照射源。这个思路很妙——2.4GHz 频段本来就充满了别人家的 beacon 帧，都是现成的探测信号，白嫖 3 倍感知带宽。

自适应人数统计：多人计数用 P95 自适应归一化 + 运行时可调的去重因子，通过 REST API 热调参（/api/v1/config/dedup-factor）。多人场景是 WiFi 感知的老大难——两个人的反射信号是线性叠加的，分离它们本质是盲源分离问题，没有完美解，只有场景化调参。

跌倒检测的防抖设计：相位加速度阈值 + 3 帧确认 + 5 秒冷却。这三个数字背后是误报率和漏报率的权衡：跌倒检测的商业价值全在误报率上——一天误报三次的系统，一周后就会被家属拔电源。

边缘模块系统：105 个"Cog"模块目录，涵盖健康、安防、楼宇、零售、工业场景，模块直接跑在 ESP32 上。签名的 aarch64/x86_64 二进制 + Ed25519 见证链做完整性验证。把"传感器 + 算法市场"做成生态，野心不小。

性能数字汇总（官方口径，含设备）：

指标	数值	硬件
CSI 嵌入吞吐	164,183 emb/s	M4 Pro
姿态推理冷启动	8.4 ms	树莓派 5
模型尺寸（4-bit）	8 KB	—
环境自学习收敛	< 30 s	ESP32 mesh
跌倒检测延迟	< 200 ms	—
mesh 时间同步偏移	σ=104 µs	2× ESP32-C6
训练一次姿态微调	2.1 s / 400 epochs	RTX 5080

六、冷思考：一次公开的撤回，和一个 3.0% 的真相

现在到了每次深度解剖最重要的部分。RuView 这个项目最不寻常的地方，不是技术，而是 README 里的两段"自我打脸"。

6.1 被撤回的 100%

早期版本的 README 宣传存在检测"100% 准确率"。当前版本的原文是这样写的：

The v2 encoder reports an honest, label-free held-out temporal-triplet accuracy of 82.3% — up from 66.4% raw; the older "100% presence" figure was measured on a single-class recording and has been retracted in favor of this.

翻译一下：之前那个 100% 是在单类别录制数据上测的——也就是说，测试集里全是"有人"的样本，模型只要永远输出"有人"就能拿满分。这是机器学习评估里最经典的作弊（或自欺）方式。新版本换成了无标签留出集上的 temporal-triplet 准确率 82.3%。

82.3% 比 100% 可信一万倍。 一个愿意在 README 里公开写"我们之前的数字是错的，已撤回"的项目，它剩下的数字才值得你花时间验证。

6.2 姿态估计：宣传图 vs PCK@20 = 3.0%

首页那张酷炫的"WiFi 实时人体骨架"图，配文里藏着一行小字：demo visualization。真实情况在 README 的 "Model weights: what's real, what's not" 一节里：

随仓库发布的端上 17 关键点姿态模型 pose_v1 是 first-cut（第一版粗糙实现），PCK@20 只有 3.0%，远低于 ADR-079 设定的 ≥35% 目标，运行时路径还是一个 confidence=0 的 stub；
另一个数字 82.69% torso-PCK@20（超过 MultiFormer 的 72.25% 和 CSI2Pose 的 68.41%）来自 MM-Fi 公开数据集 benchmark，是另一个模型、在多天线研究级数据上跑出来的，和单个 ESP32 的实时端上推理不是一回事。

也就是说："9 美元 ESP32 实时重建人体姿态"目前还是期货。真实可用的是存在检测、运动检测、呼吸/心率（近距离、静止场景）、跌倒检测。姿态估计的 SOTA 数字是真的，但硬件条件和宣传图对不上。

这不是黑这个项目——恰恰相反，它把"什么是真的、什么还不是"写成了专门章节，附 ADR 编号和 witness log，可审计。对比一下那些 benchmark 只跑对自己有利配置的项目，你会更珍惜这种文档风格。

6.3 我的独立判断：这项技术的真实成熟度

基于物理原理和项目披露的数据，我给各能力的成熟度打分（满分 5）：

能力	成熟度	判断依据
存在/运动检测	★★★★☆	物理信号强，10Hz 采样足够，82.3% 留出集准确率 + 无模型 fallback
呼吸监测	★★★★	5mm 胸腔位移 ≈ 29° 相位，信噪比充足；限静止、近距离
心率监测	★★★	心跳体表位移 <1mm，信号弱一个量级；坐/卧且无其他运动时可用
跌倒检测	★★★	原理成立，误报率数据缺失，需要真实场景长期验证
多人计数	★★	盲源分离无完美解，依赖场景调参
17 点姿态估计	★	端上模型 PCK@20=3.0%，宣传图是愿景不是现状
穿墙感知	★★☆	单层轻质墙 + 存在检测成立；穿墙测生命体征不现实

6.4 房间里的大象：隐私

最后必须说的问题：一个能隔墙感知人体存在和呼吸的 9 美元设备，攻防两用。

你用它看护父母，别人可以用它探测你家里有没有人（入室盗窃的踩点神器）、卧室里有几个人。WiFi 感知不发光、不留影像、无法被肉眼察觉，被感知者完全无感知——这比摄像头的隐私问题更隐蔽。

RuView 的回应是全边缘计算（数据不出局域网）+ Ed25519 见证链（数据可审计）。这解决了"厂商偷数据"的问题，但解决不了"设备本身被恶意使用"的问题。IEEE 802.11bf（WiFi Sensing 标准化工作组）正在制定感知场景的规范，欧盟也已有声音要求把无线感知纳入 GDPR 的生物特征数据范畴。技术跑在监管前面，这个话题未来两年一定会爆。

七、总结与展望

RuView 值得你花一个周末 + 9 美元玩一玩，理由排序如下：

物理层直觉：这是理解 OFDM、CSI、多径干涉最便宜的实验台。做通信、IoT、边缘 AI 的工程师都能从中补一块知识拼图。
工程范式：Rust 内核 + PyO3 皮、8KB 端侧模型、编译期配置断言、ADR 驱动开发、公开撤回错误数据——每一条都是可以搬回自己项目的实践。
真实需求：养老看护场景的非接触监测，是未来五年确定性增长的市场，而 WiFi 感知是该场景下隐私友好度最高的技术路线。
诚实文档：在开源项目普遍"benchmark 即营销"的当下，一个把 PCK@20=3.0% 写进 README 的项目，本身就是一堂课。

展望：随着 802.11bf 标准落地，WiFi 感知会从"hack 芯片回调"变成协议原生能力，届时每台路由器都是潜在的感知节点。到那一天，今天在 RuView 上练出的信号处理直觉，就是你的先发优势。

顺便说一句：装了这套系统之后，你在家摸鱼的样子，路由器全知道。好在它不会告诉你老板——毕竟，数据不出边缘。

参考资料：ruvnet/RuView GitHub 仓库 README 与 ADR 文档、v0.4.1 / v0.7.0 Release Notes、Hugging Face ruvnet/wifi-densepose-pretrained 模型卡、MM-Fi 数据集 benchmark。