企业官网建设流程全解析

1. 项目缘起：一个“拨不准”的按键，暴露出需求已经变了

“为老服务一键通”这个名字，乍一听是典型的民生工程，没什么技术含量。但真正把它从一个“给老人装大按键电话、帮老人约车订餐”的生活服务项目，做成一套能主动发现老人跌倒、夜间呼吸异常、并在无人知晓时自动发起求救的生命看护系统，背后是一整轮需求重构和方案推翻。

这个项目我前后跟了一年多，最大的教训是：我们一开始把“一键通”想简单了。老人真正需要的不是“有人帮我打电话”，而是在意外发生的那几分钟里，无论他有没有力气按键，都有人知道、有人来、有人管。这篇文章把整个项目从需求转折到落地实施、再到踩坑复盘的过程完整记录下来，给正在做智慧养老、居家适老化改造、社区看护系统的朋友做个参考。

1.1 从一部“大按键电话机”到社区呼叫中心

第一版方案很朴素：给每位老人装一部带SOS键的电话座机，按一下，自动接通社区呼叫中心；再配一个随身遥控器，方便老人在屋里任何地方呼救。服务团队在后台接听，帮老人约车、订餐、联系维修，也会在接到求助后代为联系家属。这个模式运行了半年，数据上“很像样”：累计接听几千通电话，满意度也很高。

但有一次复盘时我们发现，真正主动按下呼救键的，大多是“还能自己爬起来打电话”的老人。多数高龄独居老人遇到麻烦时，第一反应根本不是按按钮，而是“先歇会儿，看看能不能自己缓过来”。等到实在撑不住，往往已经没力气走到话机旁边了。这个认知让我们后背发凉——系统在数据上好看了，但在最关键的场景里可能是沉默的。

于是我们开始重新审视“一键通”三个字到底意味着什么。它不该只是一个“电话快捷键”，而应该是一整套“不管老人按不按，系统都要知道老人状态”的感知网络。这一步想通了，后面所有技术选型才有了方向，否则采购再多设备，也只是给老人家里堆了一堆会报警的摆设。

1.2 一次没有按下的按钮：生活服务救不了“生命意外”

说件真实发生的事。我们负责的片区里有一位独居老人，白天还在社区食堂打饭，傍晚在家摔倒。第二天邻居发现时，老人已经在地上躺了十几个小时。老人卧室里其实装着我们的一键呼叫终端——但他当时的位置在卫生间门口，够不到按钮，而且摔倒后没法起身。

这个案例直接推动了需求变更：不能只等老人主动按键，系统必须有能力“自己发现异常”。从那一刻起，项目从“生活服务平台”正式转向“看护平台”。我们开始调研市面上所有能用于居家监测的设备，也重新定义了成功标准——不再是接通率，而是“异常发现时延”和“救助闭环完成率”。

这个转变比想象中难得多。生活服务平台的核心指标是“响应速度”，它假设用户能主动发起请求；看护平台的核心指标是“感知全面度”，它必须假设用户随时可能失去主动沟通能力。这两个假设完全不同，决定了设备选型、平台架构、工单流程全部要重来。我们后来经常跟同行说：如果只把“一键通”当成呼叫中心来做，那它永远只是一根电话线；只有把“一键通”当成“感知+响应”的系统来做，它才有可能承担起生命看护的职能。

1.3 原居看护：让老人在熟悉的环境里“被看见”

原居看护这个词，行业里没有标准定义，但方向很明确：让老人尽可能住在自己家里、住在熟悉的环境里，而不是因为一次意外就被送去机构。要支撑这种模式，必须回答三个问题：老人在家安全吗？身体状态有没有异常趋势？突发状况能否第一时间有人响应？

这三个问题直接翻译成技术语言就是：第一，家里每个高风险的角落（卫生间、卧室、客厅动线）都要有感知能力；第二，感知数据要形成趋势，不能只看单点；第三，异常发生后要有一条能真正触达人的告警链路，而不只是“系统记录了”。

把这三个问题拆完之后，我们才发现“为老服务一键通”从生活服务跃升到生命看护，本质就是产品从“响应式”变成了“感知式”。这个“感知式”说起来容易，落地起来牵扯到网络、硬件、算法、运营、服务五个层面。后面每一个环节的决策，都没有办法拍脑袋，必须回到“老人真实风险场景”里去验证。

2. 系统选型：从“能打通电话”到“数据不落地就告警”

需求变了，技术底座就必须跟着换。生活服务时期，一套电话交换机就够；生命看护时期，需要的是一个完整的物联网感知与告警系统。这一章讲清楚我们在通信网络、终端设备、平台架构、数据链路四个层面的选型思考和取舍过程。

2.1 通信网络的取舍：NB-IoT、Wi-Fi、4G到底怎么搭

第一版一键通用的是电话线，稳定是稳定，但只能传语音，没法传数据。想要让设备自动上报“老人跌倒了”“心跳异常了”，必须换一套能双向通信的联网方式。当时摆在面前的有NB-IoT、4G/5G、Wi-Fi、LoRa几条路，我们逐一做了对比。

NB-IoT是窄带物联网，低功耗、穿墙能力强、资费便宜，非常适合固定点位、低速率、频繁上报的场景——比如紧急按钮、门磁、床垫、雷达网关。缺点是上行带宽很低，传不了视频、传不了大文件。4G/5G带宽大，但功耗高，设备电池撑不了多久，更适合需要实时语音通话、视频确认的随身终端。Wi-Fi看起来免费，但老人家里的路由器经常被断电、被小孩改密码、或者信号覆盖不到卫生间，稳定性完全不可控。LoRa需要自建网关，覆盖范围广但部署成本高，单社区试点时不划算。

最终我们的选择是“多网融合”：控制命令和事件上报统一走NB-IoT，语音通话走4G VoLTE，Wi-Fi只作为室内数据补充链路，电话线作为最后的语音兜底。这套组合的原因很简单：这些看护设备大部分装在卫生间、卧室角落里，网络必须能穿透墙体，而且设备要电池供电撑半年以上，NB-IoT是唯一能同时满足这两点的。

提示：不要为了省成本只依赖一种网络。养老场景里“这条链路断了”和“老人出事了”往往同时发生，多网融合的本质是冗余——一条链路失效时，另一条必须能顶上。

2.2 终端矩阵：按钮、腕带、雷达、床垫各管一段

设备选型是很多人最容易犯迷糊的地方。市面上打着“智慧养老”旗号的终端多到数不清，但绝大多数是单独设计、各自为政，没办法融合在一个平台里用。我们的原则很明确：不追求一台设备解决所有问题，而是让每个终端都去守住一个最擅长的风险场景。

一键呼叫器必须保留，但形态要改：固定安装在床头、马桶边、淋浴区，关键是要有拉绳——老人摔倒后可能没法按按钮，但只要能拉到一根垂下来的绳子，就能触发求救。智能腕表解决移动场景，老人出门买菜、散步时戴着，带4G通信、心率血氧监测、跌倒检测，万一在外面出事也能定位。毫米波雷达解决固定区域的无感监测，装在卧室或卫生间吊顶，不要求老人佩戴任何东西，就能识别人体存在、跌倒、甚至呼吸和心率。睡眠监测带铺在床上，主要管夜间离床异常和睡眠呼吸情况。

这些设备的“岗位分工”很清楚：主动呼救靠按钮，移动状态靠腕表，夜间睡眠和卫生间风险靠雷达和床垫。当时有个认知需要纠正——不是设备越多越好，而是“每个风险场景至少要有一种感知手段”。比如卫生间是跌倒高发地，那就必须有雷达或者拉绳；卧室是夜间最脆弱的地方，那就必须有睡眠带或者雷达。场景覆盖完整，比设备数量堆砌重要得多。

2.3 平台架构：事件中心、告警分级与工单闭环

硬件终端只是“眼睛”，真正让系统形成看护能力的是中台。我们的平台分为四层：设备接入层、事件中心、告警分级、工单流转。设备接入层解决的是“不同厂商的协议怎么统一”的问题——有的设备走MQTT，有的走HTTP，有的走私有协议，全部由接入网关翻译成统一格式后上报。

统一事件格式长这样：

{ "deviceId": "RD-2024-0317", "type": "FALL_DETECTED", "level": "S1", "ts": "2025-01-15 03:22:41", "pos": {"room": "bathroom", "height": 0.18}, "signal": 26, "extras": {"fallDuration": 31} }

字段里最关键的是level，它决定了事件走哪条响应链路。事件中心收到数据后，会做去重合并——同一个设备连续上报的同一类事件，只会生成一条工单，避免话务员被重复告警轰炸。然后事件会落进规则引擎，根据预设阈值和场景条件判断等级，再推送到对应角色（话务员、网格员、家属）的终端上。工单流转负责闭环：异常事件从生成、受理、派单、上门、处理、回访，每一步都有时间戳，谁接单、多久到场、结果如何，全程可查。

这套架构有个容易被忽视的价值：它把“告警”和“工单”拆开了。告警是系统的眼睛看到的，工单是人的手要去做的。如果两者耦合在一起，一旦误报发生，整个服务链路就被无效单子塞满，真正紧急的事件反而排不上队。拆开之后，系统可以放心大胆地做“宁可多感知”，因为多余告警会在派单环节被拦截掉。

2.4 数据链路与边缘计算：雷达数据为什么不能直接上云

这是个纯技术问题，但直接影响成本和体验。毫米波雷达每秒产生几十帧点云数据，每帧包含几十上百个反射点坐标，如果全量传到云端，流量费一个月就能吃掉整个项目的运维预算。更麻烦的是网络延迟——如果雷达要把数据传回云端、云端再判断“是否跌倒”，一来一回可能好几秒，等告警生成，老人可能已经在地上躺了好几分钟。

所以我们的方案是在网关侧做边缘识别。雷达的原始点云先在家庭网关上进行姿态识别和事件判断，只有识别出“跌倒”“呼吸异常”“区域无人”等事件特征时，才把一小段特征数据和事件类型上传到平台。平时的心跳数据、设备状态数据属于低频小包，直接走NB-IoT上报即可。这套“边计算、云决策、端执行”的架构，既压低了通信成本，又保证了告警时延。

打个生活化的比方：雷达是守门员，先在门口做第一道判断；平台是教练组，汇总各条线的数据做决策；家属和网格员是最后接球的人，负责跑动解决问题。如果每个球都要教练组从看台跑到门口来接，一场球早就踢完了。边缘计算的意义就是把“简单但是紧急”的判断放在离现场最近的地方完成。

3. 关键功能落地：三步把“一键通”从呼叫器变成看护系统

选型定下来之后，真正的工作才刚开始。这一章全部是实操细节——一键呼叫闭环怎么设计、跌倒识别和生命体征监测的参数怎么调、告警分级怎么配、两端App怎么做。这些内容都不是从文档里抄来的，是项目上线后一点点磨出来的。

3.1 一键呼叫闭环：从按下按钮到有人上门的全流程

一键呼叫看起来简单，真正走通却不容易。我们的完整流程是这样的：老人按下按钮或拉动拉绳，事件上报到平台，话务员电脑上立刻弹窗，显示老人姓名、年龄、住址、既往病史、紧急联系人、今日健康状态，同时自动接通老人端语音。话务员接起后先问一句“您怎么了”，根据老人回答判断诉求类型：生活求助就派给对应服务商，身体不适就联动网格员上门，情况危急直接帮忙拨打120。

这中间有几个细节非常关键。第一，话务系统的语音播报必须支持大音量、慢语速，因为很多高龄老人听力下降，手机上那一格音量根本不够用。第二，话务员三声没接起时，系统要自动转接值班手机，不能有任何“无人接听”的空窗期。第三，派单要有超时升级机制——网格员三分钟没接单，工单自动升级到社区负责人，再超时升级到街道值班室。这类机制才能让“一键呼叫”真正变成“闭环响应”，而不是“打通了电话就完事”。

注意：话务系统的语音识别必须兼容方言。我们接入过老人说方言、语音平台识别不出来的情况，后来直接改成“人工优先、AI辅助”，宁可多招几个听得懂本地方言的接线员，也不能让AI把老人的求救理解错了。

3.2 跌倒识别与生命体征监测：算法参数怎么调才不“狼来了”

跌倒识别穿戴设备和雷达用的是两套完全不同的原理，参数也完全不同。穿戴设备靠的是加速度计和陀螺仪，算法先识别撞击峰值、再识别失重状态、再判断后续静止时长。雷达靠的是点云高度变化——人站立时点云高度在1米多，跌倒后骤降到0.2米左右，多帧确认后再判定。两者都会产生误报，关键是怎么调参。

我们踩过的坑主要有两个。第一个是置信度阈值不能一刀切。把阈值调低了，灵敏度上去了，但老人弯腰捡东西、低头系鞋带也会触发报警；把阈值调高了，误报少了，但真的缓慢滑倒时又识别不出来。最终做法是分设备分场景调：卫生间区域阈值最低，因为那里的跌倒后果最严重，宁可多报几次也不能漏；客厅区域阈值适度调高，因为老人经常走动弯腰，误报会打扰生活。

第二个坑是“确认后取消”机制。跌倒判断需要“持续静止”作为条件之一，我们把静止判定时长设成30秒——老人摔倒后，如果30秒内能自主起身，系统自动撤销告警；如果30秒后仍然静止不动，才升级为S1紧急事件。这30秒能过滤掉大量“假摔”，又不会耽误真求救。雷达的呼吸心率检测则用另一个原理：胸腔起伏造成点云微动，通过傅里叶变换把波形转成频率，呼吸频率和心率就出来了。就像一个站在远处的人，从窗帘的起伏幅度就能猜出房间里的风有多大。

3.3 告警分级与响应策略：S1/S2/S3怎么配置

看护系统最核心的机制是告警分级。没有分级，话务员会被大量无关提醒淹没，真正紧急的事反而没人处理。我们最终定的是三级分类：

S1和S2之间有一道夜间自动升级规则。白天老人两小时没活动可能只是在看电视，但夜间两小时没活动、床上又没人，就必须升级成S1。夜间的风险被严重低估——很多老人夜间起床上厕所，跌倒在卫生间，家人发现时已经是第二天早晨。我们上线这套“夜间升级”规则三个月后，成功处理了两起夜间跌倒事件，都是雷达发现卧室内无人、地面存在长时间静止点云，系统自动触发S1，网格员上门敲门才发现老人晕倒在卫生间。

3.4 家属端与网格员端：两端都要“比老人更急”

面向使用者的App，我们做了两套完全不同的设计，因为家属和网格员的需求根本不一样。家属端的核心诉求是“我爸妈今天好不好”，打开App第一屏不是设备列表，而是“今日安全状态”——绿色代表一切正常，红色代表有异常事件，黄色代表有需关注趋势。点进异常卡片，能看到是什么设备、什么时间、什么位置触发的告警，以及系统建议的下一步动作。家属端还接了一个“远程关怀”入口，老人在家按一个键，就可以发起与家属的视频通话，不需要老人操作任何智能设备。

网格员端的设计逻辑只有一个：少点几下。默认打开就是待办工单列表，按紧急程度排序，点一下拨号，点一下导航，上门后拍张照打卡，再点几下填完处理反馈。我们做了简化版表单，选项式填报，杜绝“写小作文”。后来发现一个很有趣的数据：网格员平均处理一单的时间，从第一版App的十几分钟，缩减到三分钟以内。操作效率直接影响响应速度，这在家属端体现不出来，但在网格员端是生死攸关的。

4. 实施三个月，我踩过的那些“隐形坑”

设备选好了、平台搭起来了、流程走通了，是不是就能顺利上线？远没有这么简单。这一章分享的是实施阶段真正折磨人的问题。这些问题在需求文档里不会出现，供应商的说明书里也不会写，全是现场踩出来的。

4.1 设备装好了不代表覆盖好了：网络、供电、安装高度

第一个坑是信号覆盖。老城区的房子墙体厚，部分楼栋卫生间和地下储藏室的NB-IoT信号只有一格甚至无信号。我们第一批装完，后台显示有十几个设备频繁掉线，排查后基本都是信号问题。解决办法两个：一是让运营商优化基站覆盖，二是在信号弱的位置加装室外天线延长到室内。这块必须进场前先做信号测试，不能等装完再补救。

第二个坑是供电。多数固定终端用的是电池供电，设备没电不会当场报警，而是悄然无声地下线。老人不会注意到指示灯，家属也不会天天查。后来我们给平台加了一条硬规则：设备超过15分钟没有心跳上报，立即生成S3提醒，通知家属或网格员上门查看。这个规则上线后，设备在线率从85%提升到97%以上。

第三个坑是安装高度。一键呼叫器的拉绳，我们最初按说明书装在离地120cm的位置，后来一位康复师提醒：老人如果坐在地上或躺在地上，根本够不到120cm高度的拉绳。最终我们把拉绳位置统一调到离地30-40cm，确保任何姿态下都能拉到。毫米波雷达的安装也有讲究：不能正对空调出风口、电风扇、窗帘，否则会被误判成人体活动。我们第一次装完，某户人家的雷达连续三晚报警，后来发现是窗帘夜间被风吹动，点云特征和人体活动太像了。

4.2 误报漏报的平衡：宁可错报十次，不可漏报一次——但也不能被当成“狼来了”

误报率是这类项目绕不开的坎。上线第一周，腕表的误报率一度让人崩溃：老人弯腰系鞋带报警，抱着猫报警，甚至在椅子上伸个懒腰都报警。网格员一晚上跑三五趟空门，很快就疲了。但如果我们为了压低误报率把灵敏度调得太低，真摔的时候系统又“冷静”得让人抓狂。

我们最后的解法是“多源融合”加“阶梯确认”：单设备触发只报S2，需要人工电话确认；两个及以上独立设备同时确认异常，才升为S1，直接派单上门。具体来说，雷达发现“跌倒+静止”，同时腕表也上报“撞击后无运动”，平台才会判定为S1。如果只有一个设备触发，系统只提醒话务员电话回访。这套机制上线后，S1误报率下降了80%，漏报率始终控制在零。

还有一例很有意思：冬季一位老人加盖了很厚的被子，睡眠监测带连续几晚报“离床异常”，实际人就在床上。排查发现是厚被子改变了压力分布，监测带算法把“翻身压力消失”误判成“离床”。解决办法是在算法里加入“翻身频率特征”，区分翻身的短暂压力消失和真正离床的持续压力消失。这类问题只能靠现场样本持续优化，没有捷径。

4.3 老人“不戴不按不用”的破局办法

设备再好，老人不配合，一切为零。我们遇到的第一个阻力是腕表。多位老人觉得戴表“像被监视”“太丑了”“怕有辐射”，我们换了很多话术都收效甚微。后来我们换了思路，把腕表形态改成了挂坠式吊坠，挂在脖子上，不用时塞进衣领，看起来就是一个普通的平安锁。接受度一下子从四成提升到八成。这个经验告诉我们：适老化设计的第一原则不是“功能强大”，而是“让老人感觉不到它的存在”。

第二个问题是误触。有户人家的孩子来玩，把客厅的紧急按钮当玩具按了好几次，每次都会触发告警派单。后来我们加了告警确认机制：非S1事件，老人侧语音会先报“您是否按了求助键？按1确认，按2取消”，如果10秒内没有确认，系统自动撤销。这一招过滤掉大量误触。

最核心的一点是：我们花了很多精力教会老人“这个按钮怎么按”，后来发现真正有效的反而是“不用教的使用”。拉绳放在老人手边，坠下来的长度就是提示；腕表挂在脖子上，冬天藏在衣服里，不需要任何操作；雷达装在吊顶，老人完全无感。当设备不再给老人增加认知负担，“用不起来”的问题自然就消失了。

4.4 隐私红线：技术能做的不等于应该做的

做生命看护，必然涉及隐私，这块处理不好，项目随时可能翻车。很多同行一上来就上摄像头方案，老人的一切活动都在摄像头下面，家属方便了，但老人的尊严谁来管？我们最终把毫米波雷达作为主力监测设备，就是因为雷达只输出反射点坐标，不形成图像，人的轮廓、姿态、位置都能感知，但视觉上是“一团模糊的点云”，老人心里接受度高，法律风险也低。

即便这样，隐私管理仍然有硬规矩。平台内数据的可见范围实行最小权限，网格员只能看到自己片区老人的看护数据和紧急联系人信息，运营后台只保留统计指标，看不到个体原始数据。所有数据传输走加密通道，存储到期自动清理。摄像头方案只作为家属自选的增值功能，而且必须双重授权——老人同意、家属申请，且只在紧急事件触发时自动开启片段录制，事件处理完毕后自动关闭。

我们对每一位接入系统的老人和家属，都会当面解释清楚：哪些数据会被采集、给谁看、存多久、用来做什么，然后双方签字确认。不要觉得这一步麻烦，它保护的不只是老人，也是整个项目的合法性和可持续性。技术能做到的事情很多，但有些事情不做，才是系统真正成熟的样子。

5. 原居看护的下一个五年：从“告警”到“预测”再到“干预”

项目上线稳定运行之后，我们开始思考一个问题：如果“为老服务一键通”只是在出事后更快地报警，那它离真正意义上的“原居看护”还差得很远。真正的看护应该是等意外发生之前，就能看出来风险在悄悄靠近。这一章谈谈我们从数据里看到的可能性，以及原居看护下一步的演进方向。

5.1 数据积累后的“事前预警”：趋势比单点更有价值

系统跑了几个月之后，后台积累了大量连续数据：睡眠时长、夜间心率、白天活动量、出入频次、呼吸节律。单看某一天的数据没什么感觉，但拉出一条三个月的时间线，就能看到明显的趋势变化。有一位老人连续一周夜间呼吸暂停事件逐渐增多，心率中位数也在上移，系统自动生成了一条S2趋势提醒推给家属。家属带老人去医院检查，发现是心脏功能的问题，及时干预住了。

这就是“单点告警”和“趋势预警”的本质区别。单点告警是发生了一件事，然后响应；趋势预警是发现一串变化，然后提前干预。前者是消防车，后者是体检报告。看护系统的长期价值，一定不在“今天救了谁”，而在“提前阻止了多少个明天可能发生的意外”。数据积累得越久，这个能力越强。

5.2 多设备联动与边缘AI：从“单点告警”变成“场景理解”

下一步的技术方向是让设备之间产生协同，而不是各自报警。举个已经跑通的例子：门磁、雷达、腕表三件套联动起来之后，系统能在夜间识别一个完整的行为序列——老人从床上起身，雷达检测到离床；门磁检测到卧室门打开；老人走向卫生间；如果20分钟后雷达仍显示卫生间有人、床铺无人，系统就判断“可能跌倒在卫生间”，自动触发S1。

这类场景理解完全可以在家庭网关上本地运行。我们测试过：边缘网关在断网状态下，依然能够独立识别上述序列并现场触发声光告警，联不联网都不影响兜底看护。这带来的启发是：原居看护的可靠性不应该依赖云端的“永远在线”，边缘计算能力下沉，才是“断网不断看护”的真正答案。

5.3 服务闭环升级：社区、医院、家属的协同网络

设备和技术只是前端，真正撑起原居看护的是服务网络。我们的平台已经和周边的社区食堂、卫生服务站、物业、家政、药店打通了接口，老人一键呼叫，平台自动按诉求类型分诊派单。这个过程中，平台的角色已经从“呼叫中心”变成了“服务枢纽”——不是自己生产服务，而是把周围所有的服务资源精准调度到老人身边。

更有价值的是与急救体系的联动。我们和本地急救中心做过一次联合演练：老人触发S1后，平台除了通知家属和网格员，还会自动推送老人的既往病史摘要、实时生命体征、精确位置给急救出勤人员。急救人员还没到场，就已经对老人的情况有了基本判断。这在效率上不是提升了一点点，而是从“到了现场再问”变成了“出发之前就都知道”。

5.4 长期健康数据：一张会“说话”的养老档案

最后说说数据沉淀的价值。每天系统都在生成一份“健康摘要”：睡眠质量、心率波动、活动量、血压趋势、用药情况。按月汇总，就成了一份动态更新的连续健康档案。这份档案对慢病管理的意义非常大——高血压、糖尿病、心衰这类疾病，日常管理的核心就是观察趋势，而居家物联网设备正好是最自然的“趋势观察哨”。

我接触的一位老人，系统连续记录了他四个多月的血压波动，发现他每天清晨血压都会明显升高。家属根据系统建议和医生沟通，调整了服药时间，后续血压曲线稳了很多。这种“数据反哺医疗”的模式，不需要老人做任何额外操作，也不需要频繁跑医院，靠的就是日常设备持续不断地“在场”。

做这个项目一年半，我最大的体会是：技术从来不是最难的部分。最难的是让一位八十五岁的老人在凌晨三点跌倒之后，真的有一条链路能在十分钟内把他从地上扶起来。那是一条由设备、网络、算法、话务、网格员、家属甚至邻居共同组成的“隐形看护链”，环环相扣，缺一环都可能前功尽弃。

如果要说经验，就两条：第一，先去用户家里蹲一天，再回来写需求文档；第二，不要迷信设备数量，要迷信“关键事件发生时系统真的能用”。希望这篇记录能给正在做智慧养老的朋友一些参考，也欢迎同行多交流实际落地中踩过的坑——原居看护这件事，一个人做不成，大家一起趟路，比单打独斗快得多。