企业官网建设流程全解析

RuView harness 操作指南：用「证明一切」纪律约束 WiFi 感知 Agent 的八项工具、技能与守则

【免费下载链接】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

RuView 是一套基于 WiFi-CSI（信道状态信息）的免摄像头空间感知系统，本指南讲解如何通过npx @ruvnet/ruview发布的 Agent harness 安全地操作它：从零上手指引、ESP32 节点部署、房间校准、姿态训练，到确定性证明与声明合规检查。读完本文，你将掌握 harness 的完整工具面、技能编排、MCP 接入方式，以及它如何在代码层面强制执行"任何精度数字都必须打标签并附可复现依据"这一核心纪律。

为什么 harness 的第一条规则是"证明一切"

harness/ruview/CLAUDE.md开篇就给出了一条项目级铁律：prove everything（证明一切）。这条规则源于项目曾被指责产出"AI 生成内容（AI-slop）"，修复方式不是口头承诺，而是把纪律写进 Agent 的操作规范里。任何人在引用任何精度数字之前，必须满足以下条件：

1. 数字必须带标签：标注为MEASURED（实测，且必须指明复现器）、CLAIMED（声称）或SYNTHETIC（合成）之一；
2. PCK 只报相对均值姿态基线的差值：在无泄漏的留出（held-out）划分上，报告相对 mean-pose baseline 的增量（delta），因为一个总是预测数据集"平均姿态"的模型也能拿到约 50% 的 PCK——不扣基线会让一个不可用的模型显得很强；
3. 任何报告/PR/模型卡都要跑ruview_claim_check：它会标记未打标签的数字，以及项目已经撤回的"完美精度（perfect accuracy / 100%）"表述；
4. 固件只有拿到真芯片上的启动日志才算"硬件验证"：编译通过（build-passes）这个信号本身永远不够。

这条规则不是装饰性的——它在代码中是可执行的。harness/ruview/src/guardrails.js中实现了claimCheck()静态扫描器，被ruview_claim_checkMCP 工具、npx ruview claim-checkCLI 以及 claude-code 的输出前钩子三方共享（见文件头注释）。它识别 accuracy、pck、precision、recall、mpjpe、error rate 等指标词，甚至对map、f1、auc、iou这类短词做了词边界处理，避免把英文单词 "map" 或F1这种选项标签误判成指标；只有行内同时出现数字时才认定是"可被标记的声明"。

工具总览：八个ruview_*工具与 fail-closed 哲学

harness 暴露八个核心工具，同时以 CLI 动词和 MCP 服务器（npx @ruvnet/ruview mcp start）两种形态提供。下表来自 harness/ruview/README.md 与 工具注册表：

其中ruview_spaces_list是唯一的 OAuth-only 外部读取接口，用于访问八个带版本号的空间层级/事件/告警集合。它有以下硬约束（README 与 policy.js 均有记载）：MCP 调用必须携带credential-use授权；不能自行选择凭据路径或 API 来源；可能轮换本地刷新凭据；要求已安装的wifi-densepose二进制，绝不从自动检测的 checkout 运行 Cargo；游标（cursor）是不透明的且与集合绑定；它不授予任何写入或动作权限。

Fail-closed（故障即关闭）是所有工具的默认行为：缺仓库、缺 python、缺二进制、缺串口端口时，工具返回诚实的否定结果，绝不伪造成功。这一点在 tools.js 的工具注册表注释中被明确为设计原则："当先决条件缺失时，返回诚实的否定——绝不伪造成功"，并镜像了 RuField 的 fail-closed 姿态（ADR-262 §3.3）。例如ruview_claim_check对空输入直接报错——"一个空输入不能通过诚实关卡"（guardrails.js 中ruview_claim_check的 handler 逻辑）。

在 policy.js 中，每个工具都被归类到可执行的最小权限策略：read（只读）、execute、hardware-read、workspace-write、hardware-write、external-read。变更性/硬件工具（calibrate、node_flash）必须显式传{confirm: true}，且node_flash在非 Windows 平台直接拒绝——ESP-IDF 烧录流程目前是 Windows 子进程专属实现。

快速上手：从零到能感知，三条路径任选

npx @ruvnet/ruview # onboard — 选择一条设置路径 npx @ruvnet/ruview claim-check --file REPORT.md # 诚实守门员（有未打标签声明时非零退出） npx @ruvnet/ruview verify # 运行确定性证明（VERDICT: PASS） npx @ruvnet/ruview doctor # 自检（工具、适配器、本地 CLI） npx @ruvnet/ruview guidance --topic homecore --query "Wasmtime plugins" npx @ruvnet/ruview spaces --resource spaces npx @ruvnet/ruview spaces --resource events --limit 25 npx @ruvnet/ruview --help

ruview_onboard的实现（tools.js 中的ONBOARD_PATHS）给出了三条路径的具体含义：

1. docker-demo——最快，无需硬件。docker run -p 8000:8000 ruvnet/wifi-densepose后打开 dashboard，回放样例 CSI，适合先看"它长什么样"；
2. repo-build——面向开发者。cd v2 && cargo test --workspace --no-default-features（1000+ 测试），然后cargo run -p wifi-densepose-cli -- --help；
3. live-esp32——真实安装。烧录 ESP32-S3 节点（见provision-node技能），指向 sensing-server，然后执行calibrate → enroll → train-room → room-watch。这是唯一能感知真实房间的路径。

onboard技能（skills/onboard.md）强调，给新人的第一事实就是：WiFi 感知从 CSI 推断的是粗粒度姿态/存在/呼吸，它不是摄像头，任何精度数字必须相对基线打 MEASURED 标签。

verify：确定性证明、见证包与声明诚实

verify技能（skills/verify.md）是"证明一切"的实操落地，包含三层：

确定性证明（Trust Kill Switch）：ruview_verify运行 archive/v1/data/proof/verify.py，把参考信号送入生产流水线，将输出与expected_features.sha256哈希比对，必须打印VERDICT: PASS。如果 numpy/scipy 改变了哈希，需要用verify.py --generate-hash重新生成再验证。在 tools.js 的ruview_verifyhandler 中，先探测 python/python3 是否存在、证明文件是否存在，然后用带 180 秒超时的 promise 化 spawn 执行，最后正则匹配 VERDICT 并返回结构化结果——缺任何前提都返回ok: false。

见证包（ADR-028）：发布级认证使用：

bash scripts/generate-witness-bundle.sh cd dist/witness-bundle-ADR028-*/ && bash VERIFY.sh # 必须是 7/7 PASS

见证包内含 Rust 测试日志、证明文件+期望哈希、固件 SHA-256 清单和 crate 版本，接收方一条命令即可复验。

声明诚实：对任何报告、README 片段、PR 正文或模型卡，在引用精度之前先跑ruview_claim_check。它标记三类问题：未打标签的精度数字（必须 MEASURED / CLAIMED / SYNTHETIC）、打了 MEASURED 却没引用复现器的声明、以及已撤回的"100%/完美精度"表述。注意 guardrails.js 的实现细节：行内出现 "perfect" / "flawless" / "never wrong" 或指标词旁的 "100%" 会被判为high严重度（除非该行包含 "retract" 字样）；打 MEASURED 但没引用 verify.py、witness、mean-pose、held-out、sha256、boot log 等复现提示词的会被判为medium。

固件特例：固件修复不能仅凭编译通过就宣称"硬件验证"，必须提供真实硅片上的捕获启动日志（例如 rev-v0.2 验证中的running headless so CSI captures+CSI filter upgraded to MGMT+DATA+ 无误检的 mmwave 探针）。不得在没有启动日志的情况下合并或发布固件。

calibrate-room：ADR-151 逐房间校准流水线

calibrate-room技能（skills/calibrate-room.md）把"已供应节点 + sensing-server"变成一个可工作的房间模型。整套流程纯 Rust、可边缘部署（ADR-151），通过ruview_calibrate工具驱动（优先使用已安装的wifi-densepose二进制，否则回退到cargo run -p wifi-densepose-cli）。

四步序列：

1. baseline—— 采集空房间基线（Welford 振幅 + von Mises 相位统计）。房间必须清空。ruview_calibrate {step: "baseline"}
2. enroll—— 记录居住者执行目标活动。ruview_calibrate {step: "enroll"}
3. train-room—— 从 baseline + enrollment 训练一小组小型专用模型（存在/姿态/呼吸/心跳/不安/异常）。ruview_calibrate {step: "train-room"}
4. room-watch—— 用训练好的房间模型做实时存在/姿态/呼吸监测。ruview_calibrate {step: "room-watch"}

实现层面（tools.js 的ruview_calibratehandler）支持--step枚举baseline/enroll/train-room/room-watch与透传参数，优先调用安装的二进制（300 秒超时），否则在仓库内走cargo run（600 秒超时）。

诚实边界：这些专用模型只对该房间校准有效，跨房间迁移是另一个问题（LoRA 再校准，ADR-079 P9）。报告任何数字时必须说明它来自哪个房间；存在/生命体征精度只有在留出检查后才可打 MEASURED——并且写完后要跑ruview_claim_check。

provision-node：固件变体、烧录与供应

provision-node技能（skills/provision-node.md）覆盖 ESP32 感知节点的上线全流程：

固件变体：

• s3-8mb（带屏构建）——ESP32-S3 N16R8/16MB，AMOLED 可选。display-detect 修复（#1000）保证裸板也能采集 CSI（MGMT+DATA）；
• s3-4mb（无屏）——ESP32-S3 4MB，双 OTA，显示禁用；
• c6——ESP32-C6 + Seeed MR60BHA2（60 GHz mmWave + WiFi CSI）。mmwave 探针需要已验证的 MR60 头（#1107），空 UART 不会误检。

预编译二进制来自 GitHub releasev0.8.1-esp32（已在 S3 QFN56 rev v0.2 上硬件验证）。

烧录：ESP-IDF v5.4 在 Windows 上仅支持子进程方式（Git Bash/MSYS 不受支持，需清除MSYSTEM*环境变量）。S3 镜像的烧录偏移：

esptool --chip esp32s3 -p <PORT> -b 460800 write_flash \ 0x0 bootloader.bin 0x8000 partition-table.bin \ 0xf000 ota_data_initial.bin 0x20000 esp32-csi-node-s3-8mb.bin

注意：ruview_node_flash返回精确的固定命令，而不是执行无人值守烧录（tools.js 中 handler 返回manual_step_required，指向skills/provision-node.md）。

供应：使用 firmware/esp32-csi-node/provision.py：

python firmware/esp32-csi-node/provision.py --port <PORT> \ --ssid "<SSID>" --password "<secret>" --target-ip <server-ip> --target-port 5005 # 可选的 ADR-060 覆盖项： python firmware/esp32-csi-node/provision.py --port <PORT> --channel 6 --filter-mac AA:BB:CC:DD:EE:FF

绝不回显或提交 WiFi 密码——这是 CLAUDE.md 与 README 共同强调的红线。

确认 CSI 流动：ruview_node_monitor {port}，PASS 标准是串口显示CSI cb #...回调，裸板上还需CSI filter upgraded to MGMT+DATA。没有回调就说明节点未采集，不得进入校准步骤。实现上（tools.js 的MONITOR_SCRIPT）通过内联 python 脚本以 115200 波特率打开串口，统计窗口内（默认 12 秒）CSI cb/csi_collector回调数量，缺 pyserial 时报NO_PYSERIAL，并检测MGMT+DATA升级标记。

train-pose：如何诚实地训练与汇报 CSI→姿态模型

train-pose技能（skills/train-pose.md）交代了一个沉重的历史背景：项目有过已撤回的 92.9%/100% 精度记录，以下纪律就是为了防止它再次发生。

不可谈判的第一步：mean-pose baseline。一个总是预测数据集"平均姿态"的模型已经能拿到约 50% 的 PCK。因此 PCK 只允许作为该基线之上的增量来引用，且必须在无受试者或时间泄漏的留出划分上。技能给出的诚实示例（ADR-181）：

Held-out PCK@2059.5%vs 50% mean-pose baseline =+9.4 pp real signal— MEASURED.

三条训练路径：

• camera-supervised（ADR-079）——MediaPipe Pose 标注相机帧，配对的 CSI 训练网络；训练与推理在同一个相机帧内进行以保证骨架对齐；
• camera-free（WiFlow，ADR-152）——推理时无相机，几何条件化；
• in-browser（ADR-181）——WebGPU/WASM 训练器，活动后端以徽章形式显示（对"正在执行什么"保持诚实）。

发布数字前：① 在同一划分上跑 mean-pose baseline；② 报告(model − baseline)的百分点差，并写明划分定义（chronological / blocked-gap / grouped-bucket，无泄漏）；③ 用ruview_claim_check检查写稿——它会标记任何未打标签或 100%/完美的声明；④ 若是与 SOTA 的基准对比，只有附上复现器才可标 MEASURED-EQUIVALENT。

guidance：源码引用的能力地图

ruview_guidance是陌生工作的只读起点。它支持按主题过滤：architecture、sensing、hardware、training、homecore、integrations、deployment、community、testing，并可加自由文本查询：

npx @ruvnet/ruview guidance --topic sensing --query "UDP CSI ingestion" npx @ruvnet/ruview guidance --topic homecore --query "restore migration voice"

从 guidance.js 的实现看，每个能力记录都分离实现成熟度与证据（status字段取值如implemented、hardware-dependent、data-gated、feature-gated、provider-required），引用当前仓库路径（sources）、命名聚焦的验证命令（validation）、并写明已知局限（limitations）。在 RuView checkout 内运行时，被引用的路径会在结果通过前被逐一检查（sourceCheck.mode = 'local-checkout'）；在 checkout 外则标记为"已评审的打包目录"（packaged-catalog）。其authority字段写得很明确：guidance 只是只读导航，被引用的源码、测试、已接受的 ADR 与仓库政策才是权威；检索到的知识不能授予权限。

Cognitum Spaces：仅 OAuth 的受控外部读取

激活额外的读取 scope 需要先通过 Rust CLI 登录，然后在 metaharness 中使用同一已验证客户端：

wifi-densepose login --spaces wifi-densepose whoami npx @ruvnet/ruview spaces npx @ruvnet/ruview spaces --resource sites --limit 50 npx @ruvnet/ruview spaces --resource events --cursor '<opaque-next-cursor>'

安全边界（README）：metaharness 从不接受 bearer token 或 API key，并会从子环境中移除COGNITUM_SPACES_API，因此该面不会静默回退到兼容性 API-key 路径；API 来源固定为https://api.cognitum.one；凭据适配器要求已安装的wifi-densepose二进制而非从自动检测的 checkout 运行 Cargo 构建脚本；只返回有界的 P2/P3 语义投影。--resource可选sites、buildings、floors、spaces、zones、entities、events、alerts；--limit范围 1–100；--cursor是上一页返回的不透明值。空列表是合法的已认证结果，不是感知质量证据。过期会话可能在读取完成前轮换存储的刷新凭据。

MCP 调用默认被拒，除非服务器操作者以RUVIEW_MCP_GRANTS=credential-use启动；需要非默认凭据存储时在 MCP 服务器环境设置RUVIEW_CREDENTIALS_PATH；MCP 调用不能选择任意凭据文件或 URL。spaces:read不授予任何写入、配对、命令、策略批准、消费或执行器权限。完整剧本见捆绑的cognitum-spaces技能（skills/cognitum-spaces.md）。

技能清单与 MCP/宿主集成

harness 以宿主无关的 playbook 形式提供六个技能，位于 harness/ruview/skills/ 目录，用npx @ruvnet/ruview skill <name>打印：

onboard·provision-node·calibrate-room·train-pose·verify·cognitum-spaces

作为 Claude Code MCP 服务器使用：捆绑的.claude/settings.json注册ruviewMCP 服务器（npx -y @ruvnet/ruview mcp start）。把该包的.claude/放进仓库，或运行npx @ruvnet/ruview install --host claude-code。

MCP 服务器实现（mcp-server.js）是零依赖的 stdio JSON-RPC 2.0 服务器，实现initialize、tools/list、tools/call、ping与空的resources/list/prompts/list桩。关键设计点：tools/call异步分发（ADR-263 O2），长耗时的 verify/calibrate 不再阻塞 ping/tools/list，健康检查在运行中也能得到响应；工具调用通过 FIFO promise 链串行化——硬件/变更性工具（calibrate、串口监视、flash）绝不重叠；日志只走 stderr，stdout 是纯 JSON-RPC 通道；单行请求上限 256 KiB、排队工具调用上限 20。

宿主：Claude Code 与 Codex 均直接实现并通过本地非交互 CLI 测试：

npx @ruvnet/ruview agent run --host claude-code --repo . --prompt "Map the sensing-server startup path" npx @ruvnet/ruview agent run --host codex --repo . --prompt "Find the nearest tests for HomeCore restore state"

Prompt 通过 stdin 传输，绝不经过 shell。两个适配器默认只读（Claude Code 用claude -p --safe-mode计划模式；Codex 用codex exec只读沙箱且忽略用户配置与 exec 规则），使用清洗过的环境、有界的输出/时间、脱敏机密，并要求受信任的 RuView checkout。工作区写入需要同时满足--allow-write与--confirm，危险的绕过标志永远不会被发出。

共享大脑与 Darwin/Flywheel 学习飞轮

已提交的 brain/corpus/core.jsonl 是一个小型、可评审的仓库事实源。每条记录都带来源引用、证据层级（evidence tier）、标签与评审状态：

npx @ruvnet/ruview brain search --query "darwin community memory" npx @ruvnet/ruview brain verify --repo . npx @ruvnet/ruview brain propose --id finding-id --title "Finding" \ --content "Source-bound observation" --sourcePath README.md --sourceLine 1 \ --tags onboarding,docs --contributor github-user

提议（propose）产生的是未评审的 JSONL，走普通 PR 流程。本地向量索引、私有叠加层、原始 Agent 转录、CSI/人员数据与凭据永远不会进入共享语料。检索到的文本是被引用的证据，不是指令或授权。

开发工具链精确锁定在 devDependencies：metaharness@0.4.1、@metaharness/darwin@0.8.0、@metaharness/flywheel@0.1.7，仅用于评分、进化提议与回放验证——发布的 MCP 服务器本身零运行时依赖。npm run flywheel:plan只读；Darwin 执行需人工触发node flywheel/run.mjs --confirm，只写入不受信任的.metaharness/提议归档；受保护的门禁要求冻结锚点保留、留出提升、安全性与遗留测试通过、已验证的来源与人工批准。任何贡献者运行都不能直接替换或发布 champion 模型。

四条 Don'ts：操作红线

CLAUDE.md以四条禁止项收尾，它们是所有技能与工具共同遵守的红线：

• 不要把 WiFi 感知描述成摄像头级精度；
• 不要回显或提交 WiFi 密码/机密；
• 没有真实启动日志就不要合并或发布固件；
• 不报 PCK 就必须同时给 mean-pose baseline。

结语：把"诚实"编译进工具链

RuView harness 的独特之处在于，它把"不要夸大精度"这类文化规范翻译成了可执行的代码与策略：guardrails.js 的声明 lint、policy.js 的最小权限矩阵、tools.js 的 fail-closed 注册表、mcp-server.js 的串行化工具队列，共同构成一个即使面对过于乐观的 Agent 也不会放任虚假成功的操作环境。对任何接入方而言，正确的使用姿势是：先用ruview_guidance认路，用ruview_claim_check守住输出，用ruview_verify兜底证明，再让数字说话——而且永远只说相对基线的数字。

【免费下载链接】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