尧图网页设计 
RuView 源码审查报告解读WiFi-DensePose v1 的工程完整性与核心感知缺口剖析【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本文以仓库中现存的审查文档 archive/v1/docs/review/readme.mdWiFi-DensePose Implementation Review为主体骨架结合archive/v1/存档树内当前源码逐条核对系统解读这份审查得出的核心结论v1 具备「可部署的专业工程外壳」但 WiFi 姿态感知的「核心能力」在审查快照中主要停留在架构与 Mock 阶段。读完本文你将能看懂 RuView 前身树的分层实现现状、每个组件缺在哪一层并据此判断什么是真正可信的进展、什么仍需补齐。1. 这份审查在仓库中的定位与背景archive/v1/是 RuView 仓库中最早的纯 Python WiFi-DensePose 实现其废弃状态由 archive/v1/DEPRECATED.md 和 ADR-187 存档 v1 弃用与诚实标注 正式管控。在docs/review/目录下仓库保留了一套完整的内部审查材料包括四份文档readme.md—— 总览级 Implementation Review本文主题comprehensive-system-review.md、hardware-integration-review.md、database-operations-findings.md—— 分专题的深入审查。审查文档的核心表述非常直白该代码库呈现出「复杂的架构与大规模基础设施」但核心功能存在显著缺口系统的软件工程实践出色API 设计、数据库模型、服务编排完整而真正基于 WiFi 信号的人体姿态检测实现largely incomplete or mocked。理解本文时必须区分两个时间概念审查快照审查文档当时所依据的源码状态文中的行号、Mock 描述均针对该快照当前存档源码截至本仓库现状archive/v1/内的部分代码已发生诚实化演进——原本静默返回占位数据的地方多数已被改为显式抛错raise强制调用方配置真实硬件或显式开启 mock。下文会同时给出两者的证据读者在引用时需注意行号漂移问题。2. 总体结论专业的架构外壳 空缺的核心感知审查给出的执行摘要可浓缩为一句话系统框架 90% 就绪而用 WiFi 推断人这条主链路在核心层尚未打通。审查按完成度将模块划分为三档状态档位覆盖模块完成度完整实现FastAPI 应用与 REST 端点、WebSocket 流式框架、SQLAlchemy 模型/迁移/连接管理、配置管理与日志、服务编排/健康检查/指标90%部分实现WebSocket 流式缺真实数据接入、认证框架快照时缺 token 校验、中间件CORS、限流、错误处理已落地50–80%未完成/Mock硬件接口路由器通信、CSI 采集、机器学习模型DensePose 集成、推理管线、姿态服务Mock 数据而非真实估计、信号处理仅有骨架0–40%审查引用的三大「关键证据」硬件接口层约 30% 完成src/hardware/router_interface.py的 SSH 连接与命令执行在快照中为占位实现缺少路由器通信协议与 CSI 数据解析。机器学习模型约 40% 完成src/models/densepose_head.py定义了网络结构但未与推理集成缺少模型加载与 WiFi→视觉的域适配。姿态服务核心逻辑约 50% 完成src/services/pose_service.py在快照中使用 Mock 姿态数据替代神经网络推理。3. 逐层源码解剖缺口到底缺在哪里本节把审查的结论映射到当前仓库中仍可打开的真实源码文件便于读者自行验证。3.1 硬件接入层连接框架是真的CSI 采集是空的archive/v1/src/hardware/router_interface.pyTDD 风格的 SSH 路由器接口实际上提供了相当完整的骨架基于asyncssh的connect()/disconnect()支持command_timeout默认 30s、connection_timeout10s、max_retries3 次与retry_delay等重试参数execute_command()带失败重试机制并封装RouterConnectionErrorconfigure_csi_monitoring()对 WiFi 信道做了严格校验必须是1 channel 196的整数以防范命令注入health_check()通过echo ping/pong探测连通性。但关键瓶颈在于采集与解析两端get_csi_data()通过execute_command(iwlist scan | grep CSI)取数而_parse_csi_response()在【当前源码】中直接raise RouterConnectionError并明确告知需要支持 CSI 的固件如 Atheros CSI Tool、Nexmon 针对具体固件的二进制/文本格式解析器其姊妹实现 archive/v1/src/core/router_interface.py 是异步回调风格的另一套接口构造函数支持mock_mode开关mock 时委托src.testing.mock_csi_generator.MockCSIGenerator非 mock 时_collect_real_csi_data()在当前源码中直接raise RuntimeError要求依次完成「安装 CSI 固件 → 配置 SSH → 实现固件对应的提取命令」三件事否则宁可不产出数据。值得注意的诚实化证据审查快照描述该文件返回 None 并打印警告对应快照行 197–202而当前代码已改为抛出带完整指引的异常——archive/v1在冻结前的最后状态倾向于显式失败而非静默造假。审查文档中标注的行号与当前文件已不对应如core/router_interface.py现第 152–169 行才是上述 raise 逻辑引用时请以审查快照行号理解。3.2 CSI 解析层ESP32 路径真实存在路由器路径仍然空缺审查对src/hardware/csi_extractor.py的评语生成随机数据而非解析真实 CSI针对的是快照期代码当前源码已发生实质变化。archive/v1/src/hardware/csi_extractor.py 现在具备统一数据结构CSIDatatimestamp、amplitude、phase、frequency、bandwidth、num_subcarriers、num_antennas、snr、metadataESP32CSIParser解析CSI_DATA:前缀的 ESP32 文本格式时间戳/天线数/子载波数/频率/带宽/SNR 幅度相位交错数组并对数据不完整或含非数值字段的情况抛CSIExtractionErrorESP32BinaryParser解析 ADR-018 二进制帧定义了完整帧头布局magic0xC5110001、节点 ID、天线数、子载波数、频率、序列号、RSSI、噪声底、PPDU 类型与标志位并能按子载波数与 HE-LTF 密度推断带宽20/40/80/160 MHz计算幅度sqrt(i²q²)与相位arctan2(q,i)SyncPacketParsermagic0xC511A110解析节点间时间同步包为多节点 CSI 序列恢复 mesh 对齐时间戳RouterCSIParser._parse_atheros_format()依然显式 raise说明 Atheros 路由器二进制格式解析尚未实现欢迎贡献。也就是说审查硬件采集与解析缺失的定性在路由器路径上仍然成立但 ESP32 路径已有可运行的真实解析实现——这正是把 v1 审查放到当前仓库语境里必须更新的认知。3.3 模型层架构定义了权重不存在archive/v1/src/models/densepose_head.py 中的DensePoseHead是一个结构完整的双头网络共享特征层卷积 BatchNorm ReLU Dropout可选 FPN分割头输出num_body_parts 11 为背景类的 body-part logitsUV 回归头输出 2 通道坐标并经 sigmoid 归一化到 [0,1]自带分割交叉熵损失、UV L1 损失与组合损失函数、置信度估计、后处理argmax 置信度。然而正如审查指出也正如 archive/v1/DEPRECATED.md 所强调该类只做kaiming_normal_随机初始化全树不携带任何.pth/.onnx/.safetensors/.pt/.ckpt/.bin权重文件也没有 checkpoint 加载路径。运行它只会得到随机输出而非真实姿态精度。同目录的 archive/v1/src/models/modality_translation.py 提供 CSI→视觉特征的 encoder–decoder 翻译网络可选多头注意力配置上同样存在结构完整、无训练权重、缺域适配验证的问题。在 archive/v1/src/services/pose_service.py 的模型装配处可以看到真实调用约束当前源码第 115–119 行附近的配置densepose_config { input_channels: 256, # 对齐 modality translator 的输出 num_body_parts: 24, # 标准 DensePose 24 个身体部位 num_uv_coordinates: 2, # (U, V) 坐标 }其下虽有pose_model_path加载逻辑但torch.load部分被注释保留进一步印证架构就绪、权重未接入。3.4 姿态服务层Mock 与真实推理被显式门控archive/v1/src/services/pose_service.py 是理解整棵 v1 树的钥匙。当前实现的关键是settings.mock_pose_data门控服务初始化时若mock_pose_dataFalse才走_initialize_models()装配 DensePoseHead 与 ModalityTranslationNetwork 并置为eval()estimate_poses()在没有传入真实csi_data且 mock 关闭时直接raise NotImplementedError提示要么从硬件传入 CSI要么开启 mock 开发真实的处理链路mock 关闭为CSIProcessor处理 →PhaseSanitizer.sanitize_phase()相位清洗 → modality translator 翻译成视觉类特征 → DensePose head 推理 → 按pose_confidence_threshold过滤、按pose_max_persons限流 → 输出 persons/zone_summaryMock 路径则统一委托src.testing.mock_pose_generatorgenerate_mock_poses、generate_mock_zone_occupancy等并伴随后端占位run_calibration()实际只是sleep(5)采集基线、历史数据/分区统计/活动记录在非 mock 下均返回带说明的空结果。src/testing两个生成器都带醒目的警告横幅。例如 archive/v1/src/testing/mock_csi_generator.py 顶部即有WARNING: MOCK MODE ACTIVE - Using synthetic CSI data All CSI data is randomly generated and does NOT represent real WiFi signals.并在模块 docstring 中明确该模块使用np.random仅为测试数据生成严禁进入生产数据路径。这些设计语义与审查Pose Service 以 Mock 代替真实估计的快照结论一脉相承只是把隐式造假收敛成了显式开关 隔离在 testing 包内。3.5 认证与流式框架在、落地浅认证侧archive/v1/src/api/middleware/auth.py 的AuthMiddleware目前保留完整设计公开路径集合/、/docs、/health、/ready、/metrics等与受保护路径集合分开管理基于jose的 JWT 校验archive/v1/src/config/settings.py 定义了secret_key开发默认dev-not-secret-CHANGE-IN-PROD生产环境必须用SECRET_KEY覆盖且会被生产配置校验拒绝、jwt_algorithmHS256、jwt_expire_hours默认 24、限流匿名 100 次/窗口、认证 1000 次/窗口默认窗口 3600s等。审查快照指出token 校验缺失、开发模式返回 mock 用户——这是当时的状态评估认证模块成熟度时应以此为基线。流式侧api/websocket/connection_manager.py与services/stream_service.py提供了连接管理与广播框架但审查定性为基础设施完整、缺少真实数据接入即推送到客户端的内容取决于上层的姿态服务输出而姿态服务的真实性又取决于 3.1–3.4 的缺口是否补上。3.6 数据库与数据流模型完备持久化悬空审查指出 v1 的 SQLAlchemy 模型定义完整含迁移目录 archive/v1/src/database/migrations但姿态结果没有真正落库历史姿态分析、时间一致性跟踪缺失。这一点在当前pose_service.get_historical_data()的返回中依然可见——非 mock 模式下直接返回无历史数据需要配置持久化后端的空结构。整个系统的数据流现状可以概括为路由器/ESP32 CSI采集端ESP32 已可解析路由器端空缺 ↓ CSIProcessor / PhaseSanitizer信号处理骨架 ↓ ModalityTranslation → DensePoseHead结构在、权重无 ↓ PoseServicemock 门控 ↓ FastAPI / WebSocket框架完整 ↓ SQLAlchemy模型在持久化未接审查所批评的Mock 数据贯穿全链路本质是这条链路上游缺数据、中游缺权重、下游缺持久化的连锁结果。4. Mock / 占位实现清单审查原文表格含当前状态备注审查以表格汇总了 Mock 位置下表原样保留其内容并补充当前存档源码的状态修正列行号均为审查快照行号供追溯组件文件行号审查快照描述当前存档源码状态CSI 数据采集core/router_interface.py197–202返回 None 而非真实 CSI已改为_collect_real_csi_data()显式 raise带固件/SSH/命令三步指引CSI 解析hardware/csi_extractor.py164–170生成合成 CSI 数据已具备 ESP32 文本与 ADR-018 二进制真实解析Atheros 路由器路径仍 raise姿态估计services/pose_service.py174–177Mock 姿态数据生成由settings.mock_pose_data显式门控真实路径保留缺权重路由器命令hardware/router_interface.py94–116SSH 执行占位SSH 框架完整CSI 响应解析端显式 raise认证api/middleware/auth.pyVarious开发模式返回 mock 用户JWT 中间件与公开/保护路径设计完整需按快照评估其校验深度5. 优先级矩阵先打通从天线到坐标的主链路审查按是否阻塞核心功能将待办项排序该矩阵对今天的v2/与派生工作依然有参考价值Critical阻塞核心功能真实 CSI 数据采集实现路由器接口姿态估计模型加载并集成训练好的 DensePose 权重CSI 处理管线面向人体检测的实时信号处理模型训练基础设施WiFi→姿态域适配。High必备特性认证系统的 JWT token 校验落地真实姿态数据驱动的实时流式输出路由器健康与状态的实际监测性能优化GPU 加速、批处理。Medium增强特性历史数据分析与报表多区域multi-zone路由器部署协同基于姿态的实时告警模型版本管理与 A/B 测试。对应开发路线图为Phase 1 硬件接入与 CSI 采集 → Phase 2 模型训练与推理管线 → Phase 3 实时处理优化 → Phase 4 高级特性与分析。6. 工程质量评估哪些是可信的资产审查在指出缺口的同时候认清了骨架的价值这些优点在当前存档树中依然可见分层模块化架构api / core / hardware / models / services / database / config / testing职责划分清晰services面向 API 编排、core面向算法、hardware面向设备协议边界合理完整的 FastAPI 应用路由、依赖注入、中间件、健康检查一应俱全API 文档/docs随服务启动健壮的配置体系archive/v1/src/config/settings.py 基于 Pydantic Settings全量支持环境变量注入并内置生产环境校验如拒绝弱secret_key数据库工程化SQLAlchemy 模型 Alembic 风格迁移目录 连接池参数db_pool_size、db_max_overflow等测试与运维资产测试目录、Docker/Kubernetes/监控配置仓库顶层docker/、monitoring/、logging/为部署做好了铺垫。主要待改进面审查原话在当前树部分仍适用核心功能缺真实 WiFi 姿态检测、硬件集成缺真实路由器通信、训练与模型加载未实现、文档缺实现指南。7. 审查的当下意义v1 之后发生了什么把这份审查放回仓库语境能看清 RuView 技术演进的逻辑v1 的诚实失败改造正如第 3 节所述当前存档树已将静默 Mock 改为显式异常 显式mock_mode门控避免看似可用实则造假的假阳性结果。这是一种审查驱动的工程质量改进。整树冻结与弃用archive/v1/DEPRECATED.md 明确要求不要再在此树上构建新工作依据 ADR-117真实、训练过、有基准的权重存在于被维护的 v2/ Rust 工作区 与发布渠道中。v1 唯一仍活着的引用信号位于 archive/v1/data/proof/verify.py 的确定性参考管线证明——把固定参考信号喂入信号处理管线用 SHA-256 校验输出与公开哈希是否一致。仓库内配套expected_features.sha256、expected_cir_features.sha256、expected_calibration_features.sha256等固定哈希文件与sample_csi_data.json参考输入。对想要亲自验证本文结论的读者推荐的只读复现路径是阅读审查全貌archive/v1/docs/review/readme.md并对照同目录的comprehensive-system-review.md与hardware-integration-review.md逐文件核对骨架与缺口按第 3 节给出的源码路径从hardware → core → models → services → api读一遍调用链运行仍然有效的确定性证明v1 唯一非弃用信号python archive/v1/data/proof/verify.py。8. 结论这份审查给开发者的最重要启发不是v1 不行而是一套可复用的审查方法论把「基础设施成熟度」与「核心能力成熟度」分开打分避免被漂亮的 API 层和部署配置误导对核心算法完成度的判断。按审查原文的措辞收束WiFi-DensePose v1 是一个framework/prototype而非可用的 WiFi 姿态检测系统——架构出色、可部署性极佳但依赖真实 WiFi 信号处理与姿态估计的核心功能在当时大面积未实现。结合当前存档树可见v1 已将占位路径改造成显式失败ESP32 CSI 真实解析链路已经建立而真正的权重、推理基准与维护实现则被移交给了 v2 工作区——v1 作为研究存档的价值恰恰在于它诚实地记录了一条从外壳就绪到内核待填的完整技术路线以及项目后续如何一步步把 Mock 清零、把真实能力补上。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RuView 源码审查报告解读：WiFi-DensePose v1 的工程完整性与核心感知缺口剖析
RuView 源码审查报告解读WiFi-DensePose v1 的工程完整性与核心感知缺口剖析【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本文以仓库中现存的审查文档 archive/v1/docs/review/readme.mdWiFi-DensePose Implementation Review为主体骨架结合archive/v1/存档树内当前源码逐条核对系统解读这份审查得出的核心结论v1 具备「可部署的专业工程外壳」但 WiFi 姿态感知的「核心能力」在审查快照中主要停留在架构与 Mock 阶段。读完本文你将能看懂 RuView 前身树的分层实现现状、每个组件缺在哪一层并据此判断什么是真正可信的进展、什么仍需补齐。1. 这份审查在仓库中的定位与背景archive/v1/是 RuView 仓库中最早的纯 Python WiFi-DensePose 实现其废弃状态由 archive/v1/DEPRECATED.md 和 ADR-187 存档 v1 弃用与诚实标注 正式管控。在docs/review/目录下仓库保留了一套完整的内部审查材料包括四份文档readme.md—— 总览级 Implementation Review本文主题comprehensive-system-review.md、hardware-integration-review.md、database-operations-findings.md—— 分专题的深入审查。审查文档的核心表述非常直白该代码库呈现出「复杂的架构与大规模基础设施」但核心功能存在显著缺口系统的软件工程实践出色API 设计、数据库模型、服务编排完整而真正基于 WiFi 信号的人体姿态检测实现largely incomplete or mocked。理解本文时必须区分两个时间概念审查快照审查文档当时所依据的源码状态文中的行号、Mock 描述均针对该快照当前存档源码截至本仓库现状archive/v1/内的部分代码已发生诚实化演进——原本静默返回占位数据的地方多数已被改为显式抛错raise强制调用方配置真实硬件或显式开启 mock。下文会同时给出两者的证据读者在引用时需注意行号漂移问题。2. 总体结论专业的架构外壳 空缺的核心感知审查给出的执行摘要可浓缩为一句话系统框架 90% 就绪而用 WiFi 推断人这条主链路在核心层尚未打通。审查按完成度将模块划分为三档状态档位覆盖模块完成度完整实现FastAPI 应用与 REST 端点、WebSocket 流式框架、SQLAlchemy 模型/迁移/连接管理、配置管理与日志、服务编排/健康检查/指标90%部分实现WebSocket 流式缺真实数据接入、认证框架快照时缺 token 校验、中间件CORS、限流、错误处理已落地50–80%未完成/Mock硬件接口路由器通信、CSI 采集、机器学习模型DensePose 集成、推理管线、姿态服务Mock 数据而非真实估计、信号处理仅有骨架0–40%审查引用的三大「关键证据」硬件接口层约 30% 完成src/hardware/router_interface.py的 SSH 连接与命令执行在快照中为占位实现缺少路由器通信协议与 CSI 数据解析。机器学习模型约 40% 完成src/models/densepose_head.py定义了网络结构但未与推理集成缺少模型加载与 WiFi→视觉的域适配。姿态服务核心逻辑约 50% 完成src/services/pose_service.py在快照中使用 Mock 姿态数据替代神经网络推理。3. 逐层源码解剖缺口到底缺在哪里本节把审查的结论映射到当前仓库中仍可打开的真实源码文件便于读者自行验证。3.1 硬件接入层连接框架是真的CSI 采集是空的archive/v1/src/hardware/router_interface.pyTDD 风格的 SSH 路由器接口实际上提供了相当完整的骨架基于asyncssh的connect()/disconnect()支持command_timeout默认 30s、connection_timeout10s、max_retries3 次与retry_delay等重试参数execute_command()带失败重试机制并封装RouterConnectionErrorconfigure_csi_monitoring()对 WiFi 信道做了严格校验必须是1 channel 196的整数以防范命令注入health_check()通过echo ping/pong探测连通性。但关键瓶颈在于采集与解析两端get_csi_data()通过execute_command(iwlist scan | grep CSI)取数而_parse_csi_response()在【当前源码】中直接raise RouterConnectionError并明确告知需要支持 CSI 的固件如 Atheros CSI Tool、Nexmon 针对具体固件的二进制/文本格式解析器其姊妹实现 archive/v1/src/core/router_interface.py 是异步回调风格的另一套接口构造函数支持mock_mode开关mock 时委托src.testing.mock_csi_generator.MockCSIGenerator非 mock 时_collect_real_csi_data()在当前源码中直接raise RuntimeError要求依次完成「安装 CSI 固件 → 配置 SSH → 实现固件对应的提取命令」三件事否则宁可不产出数据。值得注意的诚实化证据审查快照描述该文件返回 None 并打印警告对应快照行 197–202而当前代码已改为抛出带完整指引的异常——archive/v1在冻结前的最后状态倾向于显式失败而非静默造假。审查文档中标注的行号与当前文件已不对应如core/router_interface.py现第 152–169 行才是上述 raise 逻辑引用时请以审查快照行号理解。3.2 CSI 解析层ESP32 路径真实存在路由器路径仍然空缺审查对src/hardware/csi_extractor.py的评语生成随机数据而非解析真实 CSI针对的是快照期代码当前源码已发生实质变化。archive/v1/src/hardware/csi_extractor.py 现在具备统一数据结构CSIDatatimestamp、amplitude、phase、frequency、bandwidth、num_subcarriers、num_antennas、snr、metadataESP32CSIParser解析CSI_DATA:前缀的 ESP32 文本格式时间戳/天线数/子载波数/频率/带宽/SNR 幅度相位交错数组并对数据不完整或含非数值字段的情况抛CSIExtractionErrorESP32BinaryParser解析 ADR-018 二进制帧定义了完整帧头布局magic0xC5110001、节点 ID、天线数、子载波数、频率、序列号、RSSI、噪声底、PPDU 类型与标志位并能按子载波数与 HE-LTF 密度推断带宽20/40/80/160 MHz计算幅度sqrt(i²q²)与相位arctan2(q,i)SyncPacketParsermagic0xC511A110解析节点间时间同步包为多节点 CSI 序列恢复 mesh 对齐时间戳RouterCSIParser._parse_atheros_format()依然显式 raise说明 Atheros 路由器二进制格式解析尚未实现欢迎贡献。也就是说审查硬件采集与解析缺失的定性在路由器路径上仍然成立但 ESP32 路径已有可运行的真实解析实现——这正是把 v1 审查放到当前仓库语境里必须更新的认知。3.3 模型层架构定义了权重不存在archive/v1/src/models/densepose_head.py 中的DensePoseHead是一个结构完整的双头网络共享特征层卷积 BatchNorm ReLU Dropout可选 FPN分割头输出num_body_parts 11 为背景类的 body-part logitsUV 回归头输出 2 通道坐标并经 sigmoid 归一化到 [0,1]自带分割交叉熵损失、UV L1 损失与组合损失函数、置信度估计、后处理argmax 置信度。然而正如审查指出也正如 archive/v1/DEPRECATED.md 所强调该类只做kaiming_normal_随机初始化全树不携带任何.pth/.onnx/.safetensors/.pt/.ckpt/.bin权重文件也没有 checkpoint 加载路径。运行它只会得到随机输出而非真实姿态精度。同目录的 archive/v1/src/models/modality_translation.py 提供 CSI→视觉特征的 encoder–decoder 翻译网络可选多头注意力配置上同样存在结构完整、无训练权重、缺域适配验证的问题。在 archive/v1/src/services/pose_service.py 的模型装配处可以看到真实调用约束当前源码第 115–119 行附近的配置densepose_config { input_channels: 256, # 对齐 modality translator 的输出 num_body_parts: 24, # 标准 DensePose 24 个身体部位 num_uv_coordinates: 2, # (U, V) 坐标 }其下虽有pose_model_path加载逻辑但torch.load部分被注释保留进一步印证架构就绪、权重未接入。3.4 姿态服务层Mock 与真实推理被显式门控archive/v1/src/services/pose_service.py 是理解整棵 v1 树的钥匙。当前实现的关键是settings.mock_pose_data门控服务初始化时若mock_pose_dataFalse才走_initialize_models()装配 DensePoseHead 与 ModalityTranslationNetwork 并置为eval()estimate_poses()在没有传入真实csi_data且 mock 关闭时直接raise NotImplementedError提示要么从硬件传入 CSI要么开启 mock 开发真实的处理链路mock 关闭为CSIProcessor处理 →PhaseSanitizer.sanitize_phase()相位清洗 → modality translator 翻译成视觉类特征 → DensePose head 推理 → 按pose_confidence_threshold过滤、按pose_max_persons限流 → 输出 persons/zone_summaryMock 路径则统一委托src.testing.mock_pose_generatorgenerate_mock_poses、generate_mock_zone_occupancy等并伴随后端占位run_calibration()实际只是sleep(5)采集基线、历史数据/分区统计/活动记录在非 mock 下均返回带说明的空结果。src/testing两个生成器都带醒目的警告横幅。例如 archive/v1/src/testing/mock_csi_generator.py 顶部即有WARNING: MOCK MODE ACTIVE - Using synthetic CSI data All CSI data is randomly generated and does NOT represent real WiFi signals.并在模块 docstring 中明确该模块使用np.random仅为测试数据生成严禁进入生产数据路径。这些设计语义与审查Pose Service 以 Mock 代替真实估计的快照结论一脉相承只是把隐式造假收敛成了显式开关 隔离在 testing 包内。3.5 认证与流式框架在、落地浅认证侧archive/v1/src/api/middleware/auth.py 的AuthMiddleware目前保留完整设计公开路径集合/、/docs、/health、/ready、/metrics等与受保护路径集合分开管理基于jose的 JWT 校验archive/v1/src/config/settings.py 定义了secret_key开发默认dev-not-secret-CHANGE-IN-PROD生产环境必须用SECRET_KEY覆盖且会被生产配置校验拒绝、jwt_algorithmHS256、jwt_expire_hours默认 24、限流匿名 100 次/窗口、认证 1000 次/窗口默认窗口 3600s等。审查快照指出token 校验缺失、开发模式返回 mock 用户——这是当时的状态评估认证模块成熟度时应以此为基线。流式侧api/websocket/connection_manager.py与services/stream_service.py提供了连接管理与广播框架但审查定性为基础设施完整、缺少真实数据接入即推送到客户端的内容取决于上层的姿态服务输出而姿态服务的真实性又取决于 3.1–3.4 的缺口是否补上。3.6 数据库与数据流模型完备持久化悬空审查指出 v1 的 SQLAlchemy 模型定义完整含迁移目录 archive/v1/src/database/migrations但姿态结果没有真正落库历史姿态分析、时间一致性跟踪缺失。这一点在当前pose_service.get_historical_data()的返回中依然可见——非 mock 模式下直接返回无历史数据需要配置持久化后端的空结构。整个系统的数据流现状可以概括为路由器/ESP32 CSI采集端ESP32 已可解析路由器端空缺 ↓ CSIProcessor / PhaseSanitizer信号处理骨架 ↓ ModalityTranslation → DensePoseHead结构在、权重无 ↓ PoseServicemock 门控 ↓ FastAPI / WebSocket框架完整 ↓ SQLAlchemy模型在持久化未接审查所批评的Mock 数据贯穿全链路本质是这条链路上游缺数据、中游缺权重、下游缺持久化的连锁结果。4. Mock / 占位实现清单审查原文表格含当前状态备注审查以表格汇总了 Mock 位置下表原样保留其内容并补充当前存档源码的状态修正列行号均为审查快照行号供追溯组件文件行号审查快照描述当前存档源码状态CSI 数据采集core/router_interface.py197–202返回 None 而非真实 CSI已改为_collect_real_csi_data()显式 raise带固件/SSH/命令三步指引CSI 解析hardware/csi_extractor.py164–170生成合成 CSI 数据已具备 ESP32 文本与 ADR-018 二进制真实解析Atheros 路由器路径仍 raise姿态估计services/pose_service.py174–177Mock 姿态数据生成由settings.mock_pose_data显式门控真实路径保留缺权重路由器命令hardware/router_interface.py94–116SSH 执行占位SSH 框架完整CSI 响应解析端显式 raise认证api/middleware/auth.pyVarious开发模式返回 mock 用户JWT 中间件与公开/保护路径设计完整需按快照评估其校验深度5. 优先级矩阵先打通从天线到坐标的主链路审查按是否阻塞核心功能将待办项排序该矩阵对今天的v2/与派生工作依然有参考价值Critical阻塞核心功能真实 CSI 数据采集实现路由器接口姿态估计模型加载并集成训练好的 DensePose 权重CSI 处理管线面向人体检测的实时信号处理模型训练基础设施WiFi→姿态域适配。High必备特性认证系统的 JWT token 校验落地真实姿态数据驱动的实时流式输出路由器健康与状态的实际监测性能优化GPU 加速、批处理。Medium增强特性历史数据分析与报表多区域multi-zone路由器部署协同基于姿态的实时告警模型版本管理与 A/B 测试。对应开发路线图为Phase 1 硬件接入与 CSI 采集 → Phase 2 模型训练与推理管线 → Phase 3 实时处理优化 → Phase 4 高级特性与分析。6. 工程质量评估哪些是可信的资产审查在指出缺口的同时候认清了骨架的价值这些优点在当前存档树中依然可见分层模块化架构api / core / hardware / models / services / database / config / testing职责划分清晰services面向 API 编排、core面向算法、hardware面向设备协议边界合理完整的 FastAPI 应用路由、依赖注入、中间件、健康检查一应俱全API 文档/docs随服务启动健壮的配置体系archive/v1/src/config/settings.py 基于 Pydantic Settings全量支持环境变量注入并内置生产环境校验如拒绝弱secret_key数据库工程化SQLAlchemy 模型 Alembic 风格迁移目录 连接池参数db_pool_size、db_max_overflow等测试与运维资产测试目录、Docker/Kubernetes/监控配置仓库顶层docker/、monitoring/、logging/为部署做好了铺垫。主要待改进面审查原话在当前树部分仍适用核心功能缺真实 WiFi 姿态检测、硬件集成缺真实路由器通信、训练与模型加载未实现、文档缺实现指南。7. 审查的当下意义v1 之后发生了什么把这份审查放回仓库语境能看清 RuView 技术演进的逻辑v1 的诚实失败改造正如第 3 节所述当前存档树已将静默 Mock 改为显式异常 显式mock_mode门控避免看似可用实则造假的假阳性结果。这是一种审查驱动的工程质量改进。整树冻结与弃用archive/v1/DEPRECATED.md 明确要求不要再在此树上构建新工作依据 ADR-117真实、训练过、有基准的权重存在于被维护的 v2/ Rust 工作区 与发布渠道中。v1 唯一仍活着的引用信号位于 archive/v1/data/proof/verify.py 的确定性参考管线证明——把固定参考信号喂入信号处理管线用 SHA-256 校验输出与公开哈希是否一致。仓库内配套expected_features.sha256、expected_cir_features.sha256、expected_calibration_features.sha256等固定哈希文件与sample_csi_data.json参考输入。对想要亲自验证本文结论的读者推荐的只读复现路径是阅读审查全貌archive/v1/docs/review/readme.md并对照同目录的comprehensive-system-review.md与hardware-integration-review.md逐文件核对骨架与缺口按第 3 节给出的源码路径从hardware → core → models → services → api读一遍调用链运行仍然有效的确定性证明v1 唯一非弃用信号python archive/v1/data/proof/verify.py。8. 结论这份审查给开发者的最重要启发不是v1 不行而是一套可复用的审查方法论把「基础设施成熟度」与「核心能力成熟度」分开打分避免被漂亮的 API 层和部署配置误导对核心算法完成度的判断。按审查原文的措辞收束WiFi-DensePose v1 是一个framework/prototype而非可用的 WiFi 姿态检测系统——架构出色、可部署性极佳但依赖真实 WiFi 信号处理与姿态估计的核心功能在当时大面积未实现。结合当前存档树可见v1 已将占位路径改造成显式失败ESP32 CSI 真实解析链路已经建立而真正的权重、推理基准与维护实现则被移交给了 v2 工作区——v1 作为研究存档的价值恰恰在于它诚实地记录了一条从外壳就绪到内核待填的完整技术路线以及项目后续如何一步步把 Mock 清零、把真实能力补上。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考