项目背景
2024年，我通过朋友引荐，接触到山西某三甲医院康复科的一个需求。他们面临一个在国内很多大医院都普遍存在的问题：老年住院患者的行动能力评估，长期依赖人工量表，效率低、主观性强，且对医生经验要求较高。传统的 Tinetti 步态评估、Berg 平衡量表这类工具，需要医生或康复治疗师在床旁观察患者完成一系列动作，再逐项打分。这个过程对于一个康复科来说，每天要重复几十次，占用了大量本可用于治疗的时间。更关键的是，不同医生的评分标准存在主观差异，同一个患者由两个人评估可能得出不同结论，这给后续的康复方案制定带来了不确定性。他们希望有一套系统，能够通过摄像头自动识别患者的行动姿态，辅助生成评分，减轻医护人员的重复劳动，同时让评估结果更具客观性和可追溯性。这个需求对我来说既陌生又熟悉——熟悉的是视觉识别技术，陌生的是医院场景里密密麻麻的隐性约束。我没有推辞，接下了这个项目。
需求调研：比我想象的复杂得多
在正式开发之前，我专程去了一趟医院，在康复科跟诊了三天。这三天是整个项目最有价值的时间投入之一。 我原本以为需求很清晰：拍视频、识别动作、输出分数。但跟诊之后发现，现实比这复杂得多： 一、摄像头位置的问题 康复室里的病床、治疗台、走廊通道错综复杂，没有一个固定的"标准拍摄角度"。患者做不同动作时，身体朝向各异，侧身、背身的情况都有。系统必须对角度不敏感，或者至少能在有限角度内给出可靠结果。 二、数据隐私的红线 医院明确表示，患者视频数据绝对不能传输到外部服务器，不能上云，必须在院内本地处理。这一条从根本上决定了整个系统架构——必须走边缘计算路线。 三、医生的实际使用场景 医生不会坐在电脑前等系统输出。他们希望系统能在患者做评估时自动记录，结束后在病历系统旁边的屏幕上直接看到结论，不需要额外操作。界面要极简，信息密度要低。 这三个约束，把我对这个项目的想象彻底重塑了一遍。
技术方案选型
硬件选择：为什么是 Jetson Nano 数据不能上云，就意味着推理必须在本地完成。本地推理有几个选项：
普通工控机 + 独立 GPU：性能够，但医院不愿意为这个系统单独腾出一个机柜位置，部署阻力大 树莓派等 ARM 板卡：功耗低、体积小，但没有 GPU，纯 CPU 跑视觉模型帧率完全不够 NVIDIA Jetson Nano：4GB 内存，128 核 Maxwell GPU，功耗约 5~10W，体积接近手掌，可以直接塞进护士站推车的抽屉里
Jetson Nano 是这个场景下唯一合理的选择。不是因为它性能最强，而是因为它在"够用"的性能和"能落地"的体积功耗之间找到了最好的平衡点。 模型选择：YOLOv11-Pose 行动能力评估的核心是提取人体骨骼关键点，包括肩、肘、腕、髋、膝、踝等 17 个标准节点的位置和置信度。YOLOv11-Pose 是当时在精度和速度上综合表现最好的选择：
单阶段检测，延迟低，内置关键点回归头，不需要单独训练姿态估计模型，官方提供多个尺寸（n/s/m/l），可以根据硬件条件灵活选择
我最终选用了 YOLOv11m-Pose，在 Jetson Nano 上原生推理约 14fps，经过 TensorRT 优化后提升至约 26~29fps，满足实时评估需求。
评估算法：从量表到代码
这是整个项目技术含量最高、也最容易被低估的部分。Tinetti 量表将步态和平衡分解为若干子项，每项有 0/1/2 的评分标准。我的任务是把这些文字描述的标准翻译成可计算的规则。举几个例子： 量表描述代码实现"步态对称性：两步长度基本一致"提取左右脚踝的步幅间距，计算连续帧的差值，偏差 < 15% 记为对称"躯干稳定性：行走时躯干无明显摇摆"追踪肩部中点的横向位移曲线，计算标准差，阈值化判断"起身动作：一次起身成功"识别从坐姿关键点分布到站姿的转变，记录起身次数 这个翻译过程非常依赖领域知识，我花了将近两周跟诊和反复与医生沟通，才把量表里每一条文字描述背后的实际含义搞清楚。医生说"步态稳"，我要追问：什么叫稳？用什么动作判断？偏多少算不稳？
系统架构总览
摄像头（USB 接入 Jetson Nano） ↓ 视频帧实时采集（OpenCV） ↓ YOLOv11-Pose 推理（TensorRT 加速） ↓ 关键点坐标输出（17点 × [x, y, conf]） ↓ 行动能力评估算法（角度计算 + 轨迹分析） ↓ 评分生成 + 报告渲染 ↓ 轻量级 Web 界面（公网部署访问）
开发过程中踩过的坑
坑一：光照变化导致关键点置信度骤降 康复室的日光灯在不同时段色温和亮度差异很大。早上偏冷白光，下午阳光从窗户斜射进来，整体色调偏暖黄。这种色温变化在 RGB 空间里会直接影响模型对皮肤、衣物边缘的识别，导致关键点置信度在下午时段明显下降，尤其是腕部和踝部这类面积小的节点。 解决方案：
预处理阶段做了 CLAHE（限制对比度自适应直方图均衡化）处理，在不损失细节的前提下改善光照均匀性 在推理前将图像从 RGB 转换到 LAB 空间，对 L 通道做归一化，减少色温影响 对置信度低于 0.5 的关键点，在 UI 上显示"当前光线不佳，建议调整摄像头"的提示，而不是直接输出错误结果
这个问题让我意识到：在受控实验室里跑得好的模型，在真实医院场景里会遇到各种意想不到的环境干扰，鲁棒性设计不是加分项，是基本盘。 坑二：Jetson Nano 的内存墙 Jetson Nano 的 4GB 内存由 CPU 和 GPU 共享，加上系统占用约 1.5GB，留给推理的空间其实相当有限。直接用 PyTorch 跑 YOLOv11s-Pose，内存占用接近 2GB，推理速度只有约 8fps，远不够用。 解决方案：TensorRT 量化转换 将 PyTorch 模型导出为 ONNX，再用 TensorRT 做 FP16 量化转换，生成 .engine 文件。转换后：
推理速度：14fps → 26~29fps 显存占用：约 2.7GB → 约 1.2GB 精度损失：关键点坐标误差 < 6像素，在可接受范围内
TensorRT 的转换本身不复杂，但踩了一个坑：Jetson Nano 的 TensorRT 版本（8.x）和 PC 端的版本不兼容，不能在 PC 上生成 .engine 文件直接拷贝过去用，必须在 Jetson 上本机完成转换。这个过程大约需要 15~20 分钟，但只需要做一次。 坑三：量表对齐的"语义鸿沟" 这是整个项目里最难的问题，也是最不像"技术问题"的技术问题。 量表里有一条评分标准是"步伐连续性：步伐无停顿或不连续"。我最初的理解是：检测脚踝关键点的移动速度，速度接近零的帧标记为"停顿"，停顿次数超过阈值则扣分。 但医生看了我的实现之后说：不对。老年人走路本来就慢，偶尔放慢脚步调整重心是正常的，不算停顿。真正要识别的停顿，是那种"犹豫了一下、明显失去了节奏感"的停顿。 这一句话让我返工了整整三天。最终我改为用步频的标准差来衡量连续性：步频稳定的人，标准差低；步频忽快忽慢的人，标准差高。这个指标比"速度是否为零"更接近医生的实际判断逻辑。 类似的对齐过程，几乎每一条量表子项都经历了一遍。这让我深刻理解了一件事：在医疗场景里，"技术实现"和"临床语义"之间永远存在一道鸿沟，跨越这道鸿沟的唯一方式是反复沟通，而不是自己闭门猜测。 坑四：患者体型差异导致的关键点偏移 老年患者体型差异很大——有的身高不足 150cm，有的体重超过 90kg，驼背、关节变形也很常见。这些因素都会导致骨骼关键点的预测出现系统性偏差：模型在训练数据（以中青年为主）上的表现，迁移到老年人身上时明显下降。 临时解决方案：
收集了约 200 组老年人的姿态视频片段，在院内做了小规模的域适应微调 对髋、膝、踝的关键点预测引入了骨骼长度约束，当预测值违反人体比例时触发修正
这个问题没有彻底解决，只是控制在了可接受范围内。如果将来要做成标准化产品，针对老年人姿态的专项数据集积累是绕不开的工作。
最终交付
系统在医院完成了为期两周的试运行，通过了康复科的验收测试。主要指标：
关键动作识别准确率：~89%（与医生人工评分的吻合度） 单次评估平均耗时：约 6 分钟（传统人工评估约 15~25 分钟） 系统稳定性：连续运行 72 小时无崩溃
我完成了独立收款。这是我创业以来第一个真正走完商业闭环的项目——从接需求到拿到钱，中间没有烂尾，没有扯皮。