1. 这个岗位到底在招什么人
先把标题拆开看。"深圳，算法工程师，400-700K"，这三个信息放在一起，基本就锁定了一个画像：一线城市、消费电子或智能穿戴赛道、中高级算法岗，薪资区间对应的是3到6年经验、能独立扛一条算法线的候选人。深圳这个地点很关键，国内做智能穿戴的硬件厂商、方案商、ODM厂高度集中在珠三角，从芯片原厂到整机品牌，再到给品牌做算法外包的团队，全在深圳及周边两小时车程内。所以这个岗位大概率不是纯互联网公司的算法岗，而是"软硬结合"的穿戴设备算法岗。
再看后半句，"能把手环手表算明白的大神"。这句话是整条招聘信息的灵魂。"算明白"三个字，外行看是口语，内行看是精准描述。手环手表这类设备，核心算法不是单一模型，而是一整套跑在资源极度受限的嵌入式环境里的信号处理加轻量级推理流水线。它要处理的是加速度计、陀螺仪、PPG光学心率、皮电、体温、气压计等多路传感器的原始数据，在几十KB内存、几十MHz主频的MCU上，实时算出步数、心率、血氧、睡眠分期、运动姿态、卡路里这些结果。这跟在大显卡上跑Transformer完全是两个世界。
所以这个岗位真正要的人，是既懂算法原理、又懂嵌入式约束、还能把算法落地到量产设备上的复合型工程师。400-700K这个价位，买的不是会调库的人，是能从零设计一套穿戴算法、并且知道怎么在功耗和精度之间做取舍的人。下面我按这个岗位实际会考察和实际会用到的东西，一层层拆开讲。
2. 手环手表算法的核心技术栈拆解
2.1 为什么穿戴算法和普通AI岗不是一回事
很多人从互联网算法岗转穿戴，第一反应是"不就是把模型量化一下塞进去吗"，结果上手就懵。原因在于约束条件完全不同。服务器上你关心的是吞吐和精度，穿戴设备上你首先关心的是功耗，其次是内存，最后才是精度。一块200mAh的电池要撑7到14天，意味着整机平均功耗得压到毫瓦级，留给算法的那部分可能只有几百微瓦。这个约束下，你不可能让PPG采样率一直跑在100Hz，也不可能让加速度计全时全速工作。
这就引出了穿戴算法的第一个核心思想：分级唤醒与动态采样。系统平时处于低功耗监听状态，只用一个极低采样率的加速度计判断"人有没有在动"，一旦检测到持续运动，才唤醒更高采样率的传感器和更复杂的算法。这个调度逻辑本身就是算法设计的一部分，不是简单的工程问题。我见过不少候选人，模型写得漂亮，但一问"你怎么决定什么时候开高采样率"，就答不上来，这在这个岗位上是致命的。
2.2 传感器数据到底长什么样
要"算明白"，先得知道原料是什么。手环手表上最常见的几路信号：
- 三轴加速度计：测线性加速度，量程通常±2g到±16g可配，采样率从25Hz到200Hz不等。步数、姿态、跌倒检测都靠它。
- 三轴陀螺仪：测角速度，用来做姿态融合，判断手腕转动、游泳划水动作。
- PPG光电容积脉搏波：绿光LED加光电二极管，测血液容积变化，是心率和血氧的源头。原始信号非常脏，运动伪影、环境光、佩戴松紧都会干扰。
- 皮电与体温：辅助判断压力、睡眠质量，信号慢变，采样率很低。
这些信号的特点是：信噪比低、个体差异大、运动状态下严重失真。PPG在静止时波形清晰，一旦跑步，运动伪影能把真实脉搏波完全淹没。所以穿戴算法的重头戏不是分类模型，而是信号预处理和运动伪影去除。这一步做不好，后面所有模型都是垃圾进垃圾出。
2.3 算法流水线的典型结构
一套完整的手环算法流水线，通常长这样：
- 数据采集与缓冲：环形缓冲区存最近几秒的原始数据，注意内存不能开太大。
- 预处理：去直流、带通滤波、归一化。滤波器的阶数和截止频率要反复调，因为MCU算力有限，IIR比FIR更省。
- 特征提取或直接端到端：传统方案提时频域特征（均值、方差、过零率、FFT峰值），现代方案用小卷积网络直接吃原始波形。
- 推理：量化后的轻量模型，int8甚至二值化网络。
- 后处理与融合：多传感器结果融合，加时间平滑，防止结果跳变。
- 功耗调度：根据置信度和运动状态动态调整采样与推理频率。
这个流水线里，每一步都有坑。比如带通滤波，心率信号大概在0.5到4Hz，但你如果截止频率设得太死，运动时心率飙到180bpm（3Hz）以上就会被削掉。所以滤波器参数得跟着运动强度自适应调整，这就是"算明白"的细节所在。
3. 关键算法模块的实操要点
3.1 计步算法：看起来最简单，其实最考验功底
计步是手环最基础的功能，也是最容易被低估的。一个能用的计步算法，核心是峰值检测加自适应阈值。加速度合矢量算出来之后，先低通滤波去掉高频抖动，然后找波峰。难点在于阈值不能固定：走路时加速度波动小，跑步时波动大，坐车颠簸时又会产生假峰。
我的实操经验是分三步走。第一步，用滑动窗口算动态阈值，窗口长度取2到3秒，阈值设为窗口内加速度标准差的某个倍数。第二步，加时间约束，两个有效步之间至少间隔250毫秒，因为人正常步频不会超过4步每秒。第三步，加幅度一致性校验，连续几步的峰值幅度如果差异过大，判定为噪声而非真实步行。
注意：计步算法最容易翻车的地方是"坐车计步"和"手部小动作计步"。前者靠幅度一致性过滤，后者靠步频和幅度联合判断。别指望一个阈值解决所有问题。
3.2 心率算法：PPG信号处理是真正的硬骨头
心率是穿戴设备的核心卖点，也是算法难度最高的模块。PPG原始信号里混着三种东西：真实的脉搏波、运动伪影、环境光干扰。运动伪影和脉搏波频率经常重叠，单纯靠频域滤波分不开。
业界主流做法是自适应滤波加加速度计参考。原理是：运动伪影和加速度计信号高度相关，所以用加速度计信号作为参考输入，通过LMS自适应滤波器估计出伪影成分，再从PPG里减掉。这个方法的计算量可控，适合嵌入式。另一条路是用加速度计做频谱辅助，在频域里找和加速度主频不一致的峰值作为心率。
参数上，LMS的步长因子很关键。步长太大，滤波器发散；步长太小，跟踪不上运动变化。我一般从0.001量级开始试，根据实际信号调整。滤波器阶数取8到16阶，再高MCU扛不住。
3.3 睡眠分期：从信号到状态的映射
睡眠分期要区分清醒、浅睡、深睡、REM。手环上主要靠心率和体动，因为脑电没法测。核心逻辑是：体动少加心率低且平稳，倾向深睡；体动多且心率波动大，倾向浅睡或REM。
实操上，通常按30秒一个epoch切分，每个epoch提取体动计数和心率变异性特征，再用一个轻量分类器（决策树或小神经网络）打标签。这里有个经验：睡眠算法不要追求单epoch准确率，要追求整夜趋势的合理性。因为用户看的是"我昨晚深睡多久"，不是某一秒的分类。所以后处理要做状态转移平滑，用隐马尔可夫或者简单的规则约束，避免深睡浅睡频繁跳变。
3.4 血氧与运动姿态：附加题的含金量
血氧靠PPG的双波长（红光和红外）比值算，原理是氧合血红蛋白和还原血红蛋白对两种光的吸收比不同。难点还是运动伪影，而且血氧对佩戴松紧极其敏感。算法上通常要求静止测量，运动时直接标"测量失败"比给个错值更负责。
运动姿态识别则是另一条线，用加速度计和陀螺仪做姿态解算，识别游泳、骑行、椭圆机等模式。常用方法是提取时域特征后跑随机森林或小CNN。这块的坑在于模式切换的迟滞，比如游泳和划船动作相似，容易误判，需要加状态机做约束。
4. 嵌入式落地的工程细节
4.1 模型量化与内存管理
算法在PC上跑通只是第一步，塞进MCU才是真正的考验。一个典型穿戴MCU可能只有256KB RAM和1MB Flash，模型权重加中间激活必须控制在这个范围内。int8量化是标配，把float32权重压到int8，内存直接省四分之三，推理速度也能提升两三倍。
量化有个坑：激活值的动态范围。如果某一层激活值分布很偏，量化后精度掉得厉害。解决办法是量化感知训练，在训练阶段就模拟量化误差，让模型自己适应。另外，逐通道量化比逐张量量化精度更好，代价是稍微多一点存储。
4.2 功耗优化的几个狠招
功耗是穿戴算法的生命线。除了前面说的分级唤醒，还有几个实操技巧：
- 算子融合：把卷积、批归一化、激活融合成一个算子，减少内存读写次数，读写内存比计算更耗电。
- 稀疏化：把不重要的权重剪掉，配合硬件支持稀疏计算，能省不少。
- 定点数替代浮点：MCU上浮点运算要么慢要么费电，能用定点就用定点。
- 推理频率动态调整：心率稳定时降低推理频率，检测到异常再拉高。
我实测过一个案例，把推理频率从每秒一次降到每五秒一次，配合异常唤醒，整体功耗降了将近40%，而用户几乎感知不到精度变化。
4.3 RTOS与算法任务的协同
穿戴设备一般跑RTOS，算法不是一个孤立的函数，而是一个任务。任务优先级、栈大小、调度周期都要设计好。传感器采集任务优先级最高，保证数据不丢；算法推理任务优先级中等，可以被打断；数据上报任务优先级最低。
栈大小特别容易踩坑。一个跑CNN的任务，如果栈开小了，运行一段时间就莫名死机，查半天查不出来。我的经验是，模型推理任务的栈至少给到4KB，复杂模型给8KB，宁可浪费一点也别省。
5. 面试这个岗位会被问什么
5.1 技术面的核心考察点
按这个薪资和岗位描述，技术面大概率围绕这几块：
- 信号处理基础：滤波器设计、频域分析、自适应滤波。会问你为什么用IIR不用FIR，截止频率怎么定。
- 算法落地能力：给你一个PPG去噪问题，让你现场设计流程，考察你对计算量和精度的权衡。
- 嵌入式约束理解：问你模型多大、内存怎么算、功耗怎么估。
- 项目深度：让你讲一个自己做的穿戴算法，从数据到量产的全过程，重点问踩过的坑。
我见过很多候选人栽在"只会调包"上。面试官问"你这个模型为什么这么设计"，答"论文里就这么写的"，基本就凉了。这个岗位要的是能自己推导、自己取舍的人。
5.2 项目讲述的加分项
讲项目时，有几个点特别加分。第一，能量化你的优化效果，比如"通过算子融合把推理耗时从8ms降到3ms"。第二，能说清楚失败尝试，比如"我先试了FIR滤波，发现MCU算力不够，换成IIR才落地"。第三，能讲清楚和硬件、固件团队的协作，因为穿戴算法从来不是一个人能搞定的。
提示：面试前把目标公司的手环手表产品拆解一下，看看它主打什么功能，猜猜它的算法方案，面试时能聊到点子上，印象分直接拉满。
6. 常见问题与排查实录
6.1 算法相关的高频问题
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 心率运动时乱跳 | 运动伪影未去除 | 检查自适应滤波是否启用，加速度参考是否同步 |
| 计步偏多 | 阈值过低或时间约束缺失 | 调高动态阈值，加最小步间隔 |
| 睡眠分期跳变 | 后处理平滑不足 | 加状态转移约束，做整夜平滑 |
| 血氧测不出 | 佩戴松或运动干扰 | 加佩戴检测，静止才测量 |
| 模型精度骤降 | 量化误差累积 | 改用量化感知训练，逐通道量化 |
6.2 工程相关的坑
蓝牙连接问题是穿戴设备的高频故障。标题热词里提到"手表蓝牙连接蓝牙耳机时，一放歌就断开"，这个现象很典型。原因通常是蓝牙带宽和功耗调度冲突：音频传输占用大量带宽和射频资源，如果算法任务还在高频跑，系统资源不够就会断连。解决办法是音频播放时降低算法推理频率，把资源让给蓝牙。这类问题算法工程师也得懂，因为你的功耗预算和别人的功能是共享的。
固件升级后算法异常也很常见。新固件可能改了传感器配置或采样率，算法参数没跟着更新，结果全乱。所以算法和固件之间要有明确的接口约定，采样率、量程这些参数必须版本化管理。
6.3 独家避坑心得
第一，永远在真实设备上验证，别只在PC上跑。PC上完美的算法，到设备上可能因为内存碎片、中断延迟、时钟漂移而崩掉。第二，留足调试接口，把中间结果通过日志或蓝牙传出来，不然出了问题只能盲猜。第三，算法参数要可配置，不同批次硬件、不同佩戴人群可能需要微调，硬编码参数会让你反复重新发版。
7. 想拿这个offer该怎么准备
如果你目标是这类岗位，我的建议是别只刷算法题。花时间做两件事：一是找一块开源硬件或者开发板，自己把加速度计、PPG的数据采出来，从零写一遍计步和心率算法，体会一下资源约束下的取舍；二是读几篇穿戴算法的经典论文，重点看它们怎么处理运动伪影和怎么做功耗优化，然后自己复现简化版。
深圳这个价位的穿戴算法岗，竞争确实激烈，但真正能"把手环手表算明白"的人并不多。大部分人会调模型，但不懂信号；懂信号的，又不懂嵌入式。能把这三样打通的人，400-700K是合理定价。我个人在实际带团队的过程中发现，这类复合型工程师的成长路径通常是：先在一个模块（比如心率）做深，再横向扩展到整条流水线，最后能独立定义产品级的算法方案。走到第三步，薪资自然就上去了。
