GitHub 趋势 · 第 104 期

用 WiFi 看穿墙的项目，把自家精度写成了 2.5%

#WiFi感知#开源项目#实测核实#选型避坑#GitHub趋势

它到底是做什么的

一句话：把普通 WiFi 信号当传感器用。WiFi 收发时每一条子载波都会被房间里的物体扰动，人走一步、呼吸一次，都会在信道状态信息里留下痕迹。RuView 做的事就是把这些痕迹翻译成屋里有没有人、有几个人、呼吸多少、心率多少这类读数，以及一个 17 个关键点的骨架姿态。它的标题写得很直白：See through walls with WiFi。

链路上是：ESP32 之类的廉价开发板抓 CSI，固件通过 UDP 把帧发出来，Rust 后端做信号处理与推理，再经 MQTT 或 Matter 接到智能家居里。官方列出的集成对象是 Home Assistant、Apple Home 与 HomePod、Google Home、Amazon Alexa，意思是 Siri 或 Alexa 可以直接报出某个房间有没有人、体征如何，不需要自己写技能。仓库里还挂着 105 个可插拔的边缘模块。

感知能力的口径：存在与人数、穿墙检测、非接触呼吸率 6～30 BPM、心率 40～120 BPM、活动与跌倒识别、睡眠监测，以及从 CSI 直接估算骨架。

但能力清单能不能兑现在硬件上，是两回事。官方的硬件表是这样的：

表后面还有一段必须一起读的话：想要 Presence, vital signs, through-wall sensing, and all advanced capabilities 这类能力，原文要求你手上有 an ESP32-S3 ($9) or research NIC；而 Consumer WiFi laptops provide RSSI-only presence detection. —— 换成普通笔记本，就只剩最粗的那一档。

怎么上手（命令取自 README 原文）

官方给了多条通道。先看最省事的两条：

# Option 1: Docker (simulated data, no hardware needed)
docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest
# Open http://localhost:3000

注意第一条 Docker 命令后面的注释原文就是 simulated data, no hardware needed，README 的硬件说明里也写着 The Docker image runs with simulated data for evaluation.——容器跑起来看到的是模拟数据，不是你家 WiFi 的读数。

Python 侧是另一条路：

pip install ruview                        # or: pip install wifi-densepose
pip install "ruview[client]"              # or: pip install "wifi-densepose[client]"

要真接线，就得刷固件了，官方给的是这段：

python -m esptool --chip esp32s3 --port COM9 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin
python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

没有硬件也能验一部分逻辑，官方给了个确定性参考信号：python archive/v1/data/proof/verify.py。

同一个指标，四个来源，五个数字

这是这个项目最该被同行学的一点，也是它最容易被误读的一点。姿态精度的指标名都是 PCK@20，但在同一个仓库里，这个名字下面挂着五个数字：

最需要解释的是第一行和第四行。第一行的 2.5% 出自 README 的 Beta 限制一节，原文把这个坑写得很清楚：Camera-free pose accuracy is limited (PCK@20 ≈ 2.5% with proxy labels)，紧接着写官方目标是 targets 35%+ PCK@20，而采集与评测那两个阶段至今还挂着未完成。

也就是说：你在自家屋里、不用摄像头，指望它给出能看的骨架，现在不现实。82.69% 那个数字是在公开数据集 MM-Fi 上、用别人标注好的数据测出来的；换到你家的房间、你的家具、你的路由器位置，它没有义务保持。

第四行的约 96% 更要注意出处。它不在 README 的宣传区，而在 PROOF.md 的不宣称清单那一节里，写的是 WiFlow-STD ~96% PCK@20，标注是作者在自己那台 RTX 5080 上复现过，对你属于硬件门槛。同一行还留着一句更罕见的记录：上游那个发布过的 checkpoint 被作者自己推翻，实测只有 0.08% PCK。

它把外部的质疑，做成了一份可执行的检查表

PROOF.md 的开头就交代了动机：这个项目被公开骂过 AI slop 和 fake，所以作者写了这份东西作为回应——不是辩解，而是一句可以当场跑的验证命令：

git clone https://github.com/ruvnet/RuView && cd RuView
bash scripts/prove.sh          # core gate + the anti-slop assertion tests
bash scripts/prove.sh --full   # also attempt the feature-gated subset

脚本的规则写得很死：只有所有非门槛项都通过，它才退出码 0；需要 GPU、数据集、真硬件的项目永远不会让整轮失败，而是把前置条件打印出来让你自己去复现。我核了脚本本身，scripts/prove.sh 在仓库里，7,737 字节。

它把每条声明分成四档：MEASURED（在自家硬件上量过、有命令、并被一个改回旧代码就会失败的测试钉住）、CLAIMED（引自别处或别处测的）、DATA-GATED / HARDWARE-GATED（代码路径是真的，但精度或吞吐的数字需要我们不提供的数据或硬件）。这话不是空口说的，测试列表里有一条断言长这样：

wifi-densepose-bfld :: cardiac_alone_cannot_separate_identity_matches_audit

翻译过来：它在测试里断言，光靠 WiFi 的呼吸心跳通道，两个人是分不开的，并给出实测差距约 0.0005。一个项目把一个自己做不到的能力写成一条会失败的测试，这件事本身比它的功能表更有信息量。

除了自证，它还把不宣称的内容单独列了一张表：

末尾一句我觉得可以直接抄给所有做开源的人：a faker hides failures; we commit them。配套的事实是，这个仓库确实把几次撤回记录写进了文档：92.9% PCK 的撤回、上面那个 checkpoint 的推翻、还有一次对自家硬件物料清单的现实修正。

硬门槛那一栏里有一条可以照抄的数字：Rust workspace: 3,128 tests, 0 failed，以及确定性流水线证明的输出 VERDICT: PASS。

隐私这一侧也不是只喊口号。它有一个叫 BFLD 的传感层，设计上的三条约束写得很具体：raw BFI never exits node、identity embedding is in-RAM-only、以及跨站点相关被设计成密码学上不可能（每个站点一把 BLAKE3 密钥哈希、每日轮换）。另有一份实测文档坦白写着它做了一个后来被证明错了的预测，并附上脚本让人重跑，而不是请读者相信结论。

真实用户在 issue 里说了什么

这份材料比官方文档更值得看。当前最热的技术质疑帖标题是 Feedback & Analysis: Unable to reproduce multi-node (4x ESP32-S3) 17-keypoint pose estimation & Missing model weights，2026 年 5 月开的，到现在仍然开着，挂了 bug 与 hardware 两个标签，15 条评论，7 个赞。发帖人用 4 块 ESP32-S3 搭了一套环境，最后写道：

这个项目 feels more like a Proof of Concept (PoC) scaffold rather than a fully functional pose-estimation system，而 AI 那一层 there are no pre-trained weights (.pth or .onnx files) available in the repository。他还指出了最要命的一条：界面之所以动起来，是因为它依赖一套模拟模式，在没有真实推理输出时 renders pre-generated skeletal animations to populate the dashboard。

他同时给了公道话：ESP32 固件抓 CSI、UDP 传输、Rust 后端与 WebSocket 这些基础设施是真的，缺的是模型那一层。他的另一条判断是，ESP32 只有 1x1 天线，想用几块板子拼出研究网卡那种空间分辨率，难点在于微秒甚至纳秒级的时钟同步。这些判断出现在 5 月——之后官方才把权重发到 Hugging Face、才补上这套分级声明与实测文档。

另外两条能佐证的现场问题：一条是录制下来的 CSI 事件里数据是空的，仪表盘训练时解析到 0 帧、只能回落到实时历史；另一条是融合服务报错加实时观测台异常。

三个口径对不上，装之前先看一眼

这部分是本篇最实用的部分，因为它直接决定你会不会白折腾一晚上。

第一，README 里那两条并排的 pip 命令，现在结果完全不同。pip install ruview 装到的是 2.0.0a1，一个 3,274 字节的元包，它把真正的编译轮子作为依赖拉进来；而 pip install wifi-densepose 现在解析到的是 1.99.0——一个故意的墓碑包：它不带任何真实代码，导入即抛错，分类标签是 Development Status :: 7 - Inactive，包描述原文写着 Tombstone release. wifi-densepose v1.x is superseded by v2.0+ (PyO3 bindings to the Rust core). —— 也就是它默认不给你任何可用的代码。

它的设计意图其实是对的：老项目里写死 wifi-densepose>=1,<2 的人执行升级时，拿到的是一个明确报错，而不是 gets a clear, actionable error instead of a silent import of a broken legacy server。但代价是：README 那条命令的终点是一封报错信，而报错信让你装的 2.0.0 从来没有正式发布过——当前 PyPI 上只有 2.0.0a1 这个预发布版。

第二，平台口径也对不上。README 写两个包 Both ship the same compiled PyO3 wheel (~250 KB, abi3-py310, Linux/macOS/Windows)，但 2.0.0a1 在 PyPI 上只有一个 win_amd64 轮子加一个源码包。Mac 与 Linux 用户拿不到预编译轮子，得自己从源码构建。

第三，版本号的两个世界。PyPI 的发布时间停在 2026 年 5 月 24 日；而 GitHub 上最新一个 release 的 tag 是 v2655，同一页里能看到同一天连着发的 v2629、v2630、v2631，相邻两个相隔 68 秒——版本号更像构建计数器，不是语义化版本。而这十个 release 的附件数组全是空的，想要二进制只能自己编。

顺带一个文档债的观察：README 的文档表写着 205 个 ADR，而目录里的编号最高已经到 ADR-362，188 到 259 这一整段一个文件都没有，另外 263、264、348 三个编号各出现了两份文件。另外变更日志 303,797 字节，是 README 的 4.3 倍。

我的判断：适合谁、不适合谁、坑在哪

坑，按上手顺序排：

• ▪照 README 第二条 pip 命令装，会得到一个导入即报错的墓碑包；照着它给的指引去装 2.0.0，你会发现这个版本不存在。用 pip install ruview，或者显式写 wifi-densepose==2.0.0a1。
• ▪2.0.0a1 的轮子只有 Windows 版，Mac 和 Linux 得自己构建，也就是本机要有 Rust 工具链。
• ▪Docker 那条路跑的是模拟数据，simulated data, no hardware needed 是原文自己写的；拿它来评估真实精度没有意义。
• ▪官方发布的 model.safetensors 头部是 NUL 填充的，标准加载器会直接拒绝（对上仓库里的第 1522 号 issue），官方标注为待重新上传。同一份说明里还写着，archive/v1 里那个姿态头 no checkpoint of any kind，并给了一句 Do not expect real pose output from it. —— 官方对那个目录的定性就是别指望。
• ▪GitHub 上能抓到的这一页 release 全是零附件，想省事直接下二进制的想法要放弃。

最后一句话总结：把它当成一个还在施工、但施工记录写得很诚实的平台，而不是一个已经能用的产品。它的价值现在一半在代码里，一半在那份自证清单里。

#GitHub趋势#第104期

如果你也在折腾 WiFi 感知，最想知道的是 4 块板子到底能不能拼出骨架，还是它在自己家里到底准不准？留言说说，我下期带着这两个问题继续看。

下期兑现欠了几期的开源替代 SaaS 合集；如果日榜上先冒出一个更值得写的单项目，我会在文末说明为什么先写它。