企业官网建设流程全解析

1. 项目概述与设计思路

1.1 这个项目到底在解决什么问题

先聊一个很现实的场景：家里老人选择独居，或者孩子在外地工作、父母不愿意搬来同住。这种情况下，最让人揪心的不是老人吃得怎么样、穿得暖不暖，而是“万一在家摔倒了没人知道怎么办”。据统计，跌倒是居家老年群体最常见的意外伤害之一，而独居状态下“跌倒后无法呼救”的时间窗口，往往直接决定了后续恢复的难度。市面上很多监测方案，要么需要老人佩戴设备（手环、挂坠），老人嫌麻烦、经常忘记戴；要么装摄像头，老人觉得自己被“盯着看”，心理上非常抗拒，子女这边也觉得隐私上过意不去。

我做这套“Wellbeing Monitor（福祉监测器）”，核心思路就一句话：让居住空间本身变成一位“不打扰的观察者”。整套系统不依赖摄像头、不采集人脸和声音、不需要老人穿戴任何东西，而是通过毫米波雷达、门磁、压力垫、温湿度等传感器组合，在本地边缘设备上完成活动识别、异常判断和告警通知。老人的日常行为会被转化为“卧室有人”“客厅走动频繁”“夜间离床时间偏长”“某区域超过设定时间无人活动”这类抽象状态，而不是一张张照片或一段段视频。

这个方案最适合三类人：一是家有独居老人、想远程掌握安全状态但担心隐私的子女；二是做社区养老或适老化改造的从业者，需要一套相对完整、可复制的监测方案；三是自己动手能力强的折腾型用户，想在低成本硬件上搭一套私有化的居住监测系统。整套项目的关键不在“买了什么高级设备”，而在于怎么把传感器数据组合出可靠的安全判断，同时守住隐私这条底线。

1.2 为什么“隐私优先”是这套系统的命根子

市面上不是没有类似功能的设备：智能摄像头带人形侦测、带移动追踪，功能很强。但很多人装完之后，心里始终有个疙瘩——摄像头24小时开着，画面虽然只有自己能看到，可一旦账号被盗、云服务商数据泄露，甚至厂商后台人员越权访问，生活画面就成了别人的素材。对老人来说，这种“被看”的感觉本身就非常不安，很多老人甚至会因此故意绕开摄像头活动，反而让监测失去意义。

所以这套系统从架构层面就把隐私当成第一优先级，而不是事后补救。具体做了三件事：

第一，数据不出本地。所有传感器的原始数据和识别结果，都只存在家里的边缘网关（一台低功耗小主机）上。系统没有任何云端的视频流或原始数据上报，对外通信只发送“紧急告警”这种最小化信息。

第二，传感器形态上就去掉“图像采集”这个选项。毫米波雷达返回的是点云和距离-速度-角度信息，没有人能从中还原出长相、衣着或表情；门磁、压力垫、红外传感器返回的更是纯粹的开关量。数据形态决定了隐私风险的上限，这比任何加密都实在。

第三，用户拥有数据控制权。数据保留周期、删除策略、统计报表的粒度都可以自己配置。默认情况下，超过30天的明细数据自动清理，只保留每日的摘要统计，比如“某天白天客厅活动偏少”这类趋势信息。

我一直觉得，“隐私优先”不是一个宣传口号，而是一系列架构决策的自然结果。你先定下“不要什么”，后面很多技术选型就顺了：不要摄像头所以选雷达，不要云所以选边缘推理，不要长期明细所以设计自动清理。这些决策叠加起来，就形成了产品的核心差异：它监测的是一个空间里“有没有人、活动状态如何、有没有异常”，而不是“这个人长什么样、在做什么”。

1.3 方案选型背后的取舍

具体选型上，我对比过几条路线：

• 摄像头方案：识别准确率最高，跌倒识别可以直接用视觉模型。但隐私负担最大，且老人配合度低。放弃了。

• 可穿戴设备（手环、挂坠）：跌倒检测算法成熟，有SOS按键。但需要老人主动佩戴、定期充电，戴不戴完全不可控，实际覆盖率可能只有一半时间。可以作为补充，但不能作为主力。

• 环境传感器方案（PIR红外、门磁、压力垫）：成本极低，部署简单，隐私性极好。缺点是信息维度太粗，只能知道“有没有动”“出没出门”，很难判断“是不是摔倒了”“是不是长时间没起身”。

• 毫米波雷达方案：能检测人体存在、微动（甚至呼吸引起的体表起伏）、移动速度和姿态变化，而且完全不采集图像。价格比PIR贵，但比一套好的摄像头方案便宜得多，是这套系统的感知核心。

最后定的组合是：雷达做“人体存在与姿态分析”，门磁做“进出屋判断”，压力垫做“关键位置（床边/沙发）的长时间姿态确认”，温湿度传感器做环境安全兜底。这个组合的聪明之处在于，每种传感器的盲区可以被其他传感器补上，后面我会详细讲。

1.4 这套系统能做什么、不能做什么

明确边界很重要，不然期望管理会出问题。这套系统能做的：

• 室内活动状态识别，包括“有人/无人”“静在/走动”“位置在哪个分区”。
• 跌倒事件检测，雷达捕捉到快速下坠和长时间静止的特征组合后触发告警。
• 长时间无人活动提醒，比如早上8点到10点老人习惯起床活动，但某天卧室一直没人动，系统会发一条“非紧急异常”提醒。
• 夜间离床分析与睡眠作息规律统计，适合观察起夜频繁度等健康趋势。
• 出门未归提醒，配合门磁判断老人出门后超过预设时间未返回。

它不能做的：不能拍下现场画面，不能做语音对讲，不能像医护人员一样做诊断。它提供的是“安全状态感知和异常线索提示”，把最关键的“有没有事”交给系统判断，把“具体怎么回事”留给人去确认。这个定位足够务实，也足够可靠。

2. 硬件选型与部署要点

2.1 传感器怎么选，装在什么位置

这部分的经验我踩了不少坑，先说结论再看细节。

毫米波雷达选型：选择60GHz频段的调频连续波雷达模组，这个频段对人体的微动感知灵敏度比24GHz好，体积也更小。核心看几个参数：检测距离（至少6米）、视场角（水平100度以上）、是否支持输出点云/目标级数据、有没有跌倒检测的参考算法。市面上这类模组价格在一两百到五六百不等，差别主要在固件算法和开发资料的完整度上。建议别买太便宜的，点云质量差一点，后面调误报会调到你怀疑人生。

部署位置：一个房间（比如卧室或客厅）在顶角或墙面高处装一个雷达，高度2.2米到2.5米之间，向下倾斜15到30度。这个角度能让雷达波束覆盖大部分活动区域，同时减少家具遮挡。

门磁：装在入户门上，用来判断老人是否出门。这个便宜可靠，是很好的辅助信号。

压力垫：铺在床边或沙发坐垫下，判断“人是不是长时间躺着/坐着没动”。选线状的或薄片状的都可以，关键要选有“有人/无人”输出的型号，方便接入网关。

温湿度传感器：每个主要房间放一个，主要是做环境安全兜底，比如夏季高温高湿、冬季暖气异常这类情况，本身也是独居老人的风险点。

部署顺序上，我建议先装雷达、把活动识别跑通，再加门磁和压力垫做联动，一次性装太多反而不好排查问题。

2.2 边缘网关与系统架构

这套系统的“大脑”是一台边缘网关。我用的是低功耗ARM小主机，性能和树莓派4B相当，跑Linux系统。选它有几个理由：

• 功耗低，7×24小时运行没有压力，一年电费也就几十块。
• 被动散热、无风扇，安静，适合放在卧室或客厅角落。
• ARM架构下，雷达点云解析和规则引擎这类负载完全跑得动。
• 接口够用：USB（接雷达）、GPIO（接门磁/压力垫）、Wi-Fi/以太网（联网用于告警通知）。

整体架构分四层：

1. 感知层：雷达、门磁、压力垫、温湿度传感器。负责把物理世界变成结构化信号。
2. 接入层：一个小型守护进程，负责采集各传感器数据，做时间对齐和基础滤波。
3. 分析层：运行状态机和规则引擎，输出“当前室内状态”（如：卧室有人-静在、客厅无人、跌倒疑似等）。
4. 应用层：本地Web面板、告警通知、数据统计。

其中分析层的状态机是整个系统最核心的部分，后面专门讲。这里先记住一个原则：所有决策尽量做在本地，云端只负责最紧急的告警转发。

2.3 数据结构与本地存储策略

传感器采集的数据在网关落库，选用SQLite，零配置、单文件、足够可靠。主要两张表：

• events表：状态事件，每发生一次状态切换记录一条。字段包括时间戳、区域、事件类型（进入/离开/跌倒/静在超时等）、持续时长、置信度。
• daily_stats表：每日摘要，包括各区域累计活动时长、出入次数、夜间离床次数和时长、异常事件数量等。

默认保留策略：明细事件保留30天，每日摘要永久保留（这些是趋势分析的基础）。这个策略兼顾了隐私和数据价值——紧急告警转发的历史会保留，但日常明细会自动过期删除。

3. 核心功能与算法要点

3.1 室内活动识别的状态机设计

室内状态识别的难点不是“有没有人”，而是“人在做什么状态”。我把每个房间建模成几个状态：无人、静在（有微动但无位移）、走动（有持续位移）、疑似跌倒（快速位移后长时间静在）。状态之间靠雷达输出的目标特征和时序规则进行迁移。

用一组伪代码来说明核心逻辑：

# 简化版状态机逻辑 def update_room_state(room, radar_target): if radar_target.absent: new_state = "无人" elif radar_target.is_moving: new_state = "走动" elif radar_target.has_micro_motion: if room.state == "无人": new_state = "静在" # 从走动到有微动，说明人停下来了 elif room.state in ("走动", "疑似跌倒") and radar_target.motion_level < threshold: new_state = "静在" else: new_state = room.state # 保持原状态 else: # 没有微动可能是睡熟或设备异常 new_state = room.state if (room.state == "走动" and new_state == "静在" and radar_target.vertical_speed > fall_speed_threshold): new_state = "疑似跌倒" return new_state

实际上雷达输出的点云数据要先做聚类、跟踪，才能得到每个目标的距离、速度、角度和微动强度。如果用的模组自带目标跟踪输出，直接读目标属性就行，省很多事。

3.2 跌倒检测是怎么判断的

跌倒检测是这套系统里最有价值也最难做准的功能。难点在于：跌倒是一个“过程”，不是一个“瞬间”。算法要在时间窗口里看动作序列，而不是看单帧数据。

我的判断逻辑分三段：

1. 快速下坠：目标在1到2秒内垂直方向速度异常增大，同时伴随水平速度变化。这个特征触发“疑似跌倒”的预备状态。
2. 冲击后静置：快速下坠后，目标高度降低（雷达测到的人体中心高度明显下降），随后进入持续但微弱的静止状态，没有正常起身的移动特征。
3. 静置超时确认：如果疑似跌倒后30秒内没有恢复为站立走动状态，则确认跌倒事件触发告警。

这里有个关键设计：不能一检测到“快速下坠”就告警。生活中猛地坐下、弯腰捡东西、扑到床上，都有类似特征，但人很快会恢复正常活动。只有“摔下去且长时间不动”这个组合才是真正需要干预的。把确认窗口设在30秒，既能过滤大部分误报，又不会耽误紧急响应。

3.3 告警规则与通知链路

告警规则我用一个可配置的规则引擎来做，不写死在代码里。规则的要素是：触发条件、持续时间、通知方式。几个典型的规则：

通知链路只做最小化信息推送：一条文本消息，包含时间、地点、事件类型、通知级别，不带任何图片或经过识别的个人信息。紧急告警通过邮件+短信双通道发送，非紧急的用普通推送就可以。

4. 实操部署与配置实录

4.1 硬件清单与接线

动手之前，把清单列齐：

• 60GHz毫米波雷达模组×2（卧室、客厅各一）
• 门磁传感器×1
• 压力垫×2（床边、沙发各一）
• 温湿度传感器×3
• ARM小主机（边缘网关）×1
• USB转串口模块、杜邦线若干、5V/2A电源

雷达模组一般直接用USB串口连网关，门磁和压力垫用GPIO接，温湿度传感器走I2C总线。接线这里有个经验：干接点类传感器（门磁、压力垫）的接线尽量用带屏蔽的双绞线，长度控制在5米以内。我一开始用普通杜邦线接了8米长的门磁线，结果每天都会出现随机误触发，后来换成屏蔽线就好了，抗干扰能力明显提升。

4.2 系统安装与依赖准备

网关系统用精简版Linux，装好以下组件：

• Python 3环境，用于数据采集和规则引擎
• SQLite3数据库
• Nginx，用作用户访问本地Web面板的反向代理
• 告警通知相关的SDK（短信网关、邮件服务）

初始化数据库的脚本很简单，建两张核心表即可：

CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts TEXT NOT NULL, zone TEXT NOT NULL, event_type TEXT NOT NULL, duration INTEGER, confidence REAL ); CREATE TABLE daily_stats ( date TEXT PRIMARY KEY, zone TEXT, active_minutes INTEGER, sleep_cycles INTEGER, abnormal_events INTEGER );

4.3 采集服务与规则引擎配置

采集服务负责轮询各传感器数据、做简单滤波后写入状态机的输入队列。规则引擎的配置我建议用YAML文件，方便调整参数：

# 告警规则配置示例 zones: bedroom: radar_port: /dev/ttyUSB0 fall_confirm_seconds: 30 min_active_hours: "08:00-22:00" no_activity_alert_minutes: 120 living_room: radar_port: /dev/ttyUSB1 fall_confirm_seconds: 30 no_activity_alert_minutes: 180 alerts: fall: channels: [sms, email] cooldown_minutes: 15 no_activity: channels: [push] cooldown_minutes: 60

有个参数值得多说几句：cooldown_minutes（冷却时间）。跌倒告警这类紧急通知，如果在15分钟内反复触发，只发一次就够了。否则老人有一次正常动作被误判，系统连发五条短信，子女那边会吓得够呛、马上打电话回来问，结果老人根本没出事，几次之后就容易“狼来了”。冷却时间设置要根据实际场景调整，我自己测试下来紧急告警15分钟冷却、非紧急60分钟冷却，比较合理。

4.4 校准与试运行

校准这个过程没法跳过。装好的第一周，系统会频繁误报或者漏报，这不是质量问题，而是每个家庭的户型、家具布局、电磁环境都不一样，雷达需要按现场调整。

我的校准三步法：

1. 静态校准：人站在房间不同位置，确认雷达能稳定输出“有人”状态，没有丢目标。尤其是床边、沙发这类高频活动区域，要重点测。
2. 动态校准：模拟正常走路，确认能识别“走动”状态；快速坐下、蹲下捡东西，确认这些动作不会触发“疑似跌倒”。
3. 跌倒模拟测试：用抱枕从站立高度丢到地上，或者自己拿厚垫子做模拟跌倒，验证告警链路能通。这一步一定要做，不能只靠理论判断。

试运行期间先不要接真实告警通知，把日志打开跑一两天，观察误报主要出现在什么时间段、什么位置，然后针对性调整雷达角度和阈值参数。

5. 常见问题与排查技巧

5.1 问题速查表

5.2 误报的终极解法：传感器融合

如果单个传感器怎么调都压不住误报，那就别在单点上死磕，要用融合逻辑。最好的例子是夜间离床监测：单靠雷达判断老人有没有离床，会有“翻身幅度大被误判为起身”的问题；但加上床垫压力垫之后，只要压力垫持续有人，雷达那边随便怎么报“离床”都可以忽略。反过来，如果压力垫突然从有人变无人，雷达又长时间检测到卧室无目标，那基本可以确认老人出了卧室。

这种“不同传感器相互验证”的思路，让整套系统的可靠性上了一个大台阶。这也是我一直强调“雷达为主、环境传感器为辅”的原因：雷达是感知主力，但融合逻辑才能让误报率降到可接受水平。

5.3 调试心得与时间成本

给准备复刻这套系统的人一个心理准备：硬件装好可能只要一个晚上，但调试到“基本不误报、该报的都报”至少需要一到两周。我自己的经历是第一周每天都会收到三五条误报，大部分是雷达把扫地机器人、窗帘晃动当成了人体活动，后面通过调整目标置信度、加装静态过滤、写入“睡眠时段降低灵敏度”等规则，才把误报压到一周一条以内。

调试过程中最实用的小技巧是：每个状态变化都要带置信度分数，调试界面上能直观看到“这次触发告警是因为哪些条件满足、置信度多少”。不然出了问题只能瞎猜，会很痛苦。

5.4 扩展方向

这套系统跑稳之后，我还加了两个小功能：一是在线Web面板里按周展示活动趋势图，可以看出老人近一周整体活动量是上升还是下降；二是把每日摘要导出成CSV，方便定期留意睡眠作息的变化。严格来说，这些不算监测必须，但子女在远程关心父母的时候，这些趋势数据非常有用，能让担心变得具体、有依据。

我个人在实际操作中的一个体会是：隐私优先的产品设计，不只是“不采集图像”这么简单，而是要在用户完全感知不到的情况下，把守护做扎实。家里老人对这整套系统的要求特别朴素：不能让我觉得被监视，但出事的时候要有人知道。这套系统恰好同时满足了这两点。如果你也正在考虑类似方案，建议从一个小房间的单雷达试点开始，先跑通体验一下可靠性和心理感受，再决定要不要扩展到全屋。