飞利猫研发团队访谈：一台设备要过多少关
用户拿到手的飞利猫随身WiFi，是一个巴掌大的设备，开机、连接、上网，整个过程不到一分钟。但从最初的需求讨论到最终量产，这台设备经历的流程远比想象中长。本文梳理其中的关键环节，也顺带说明为什么有些看起来"应该很简单"的改进，实际需要数月才能落地。
第一关：需求从哪来
每一代产品的起点，是明确"要解决什么问题"。
需求来源有几个渠道：客服记录中高频出现的用户反馈、实际场景测试中发现的问题、上一代产品的遗憾之处、以及技术演进带来的新可能。
筛选的标准很直接： 这个需求影响多少用户？现有方案能否部分解决？解决它需要多大代价？三个问题都通过的需求才会进入定义阶段。
有些需求看起来合理但会被放弃，比如"把电池做到两万毫安"——技术上可行，但会让设备重到不像随身产品，与便携定位冲突。这类取舍在需求阶段就要想清楚。
第二关：射频与天线设计
这是随身WiFi研发中技术含量最高、也最不为人知的环节。
天线设计。 天线性能直接决定弱信号环境下的表现，但它受到设备体积、内部结构、电池位置的诸多限制。研发中需要在仿真软件中反复调整天线形态和位置，再制作样机实测，往往要经过十几轮迭代。
干扰的排查。 电池、屏幕、金属部件都会影响天线性能。在巴掌大的空间里排布这些元件，需要结构、射频、硬件三方反复协调。一个看似微小的结构调整，可能导致天线效率下降几个百分点，而这几个百分点在实际使用中就是"能连上"和"连不上"的区别。
多网络兼容。 设备需要支持多家运营商的多个频段，每个频段的天线匹配都要兼顾。这不是简单的"支持就行"，而是在所有频段上都要达到可接受的性能水平。
第三关：功耗与热设计
功耗调优。 续航是用户最直观的体验指标之一。研发中会在各种场景下测量电流：待机、轻负载、满负载、弱信号、多设备连接。然后针对性地优化休眠策略、发射功率控制、数据调度逻辑。
这个过程很琐碎——可能为了降低零点几毫安的待机电流，要调整好几处代码。但累积起来的效果是可观的。
热设计。 设备体积小，散热空间有限。长时间高负载工作时的温度控制，直接影响稳定性和电池寿命。研发中会通过热仿真和实际温升测试，确定散热方案——可能需要调整内部结构、增加导热材料、或者优化功耗策略。
一个具体的测试场景：设备满负载连续工作两小时，测量外壳温度和内部关键点温度，确认在安全范围内且没有明显降频。
第四关：可靠性测试
这一关的目标是"把问题留在实验室，而不是留给用户"。
高低温测试。 在高温和低温环境下测试设备的工作状态和电池表现。尤其是高温，夏季车内、阳光直射的场景对设备是严峻考验。
跌落与振动。 模拟日常使用中的意外跌落，以及车载场景中的持续振动。
接口寿命。 充电接口的插拔寿命测试，确保反复使用后不会松动或接触不良。
长时间运行。 连续工作数十小时甚至数天，观察是否出现内存泄漏、连接数累积、性能下降等问题。这类问题在短时间测试中不会暴露，却是长期稳定性的关键。
电池循环。 充放电循环测试，评估电池容量的衰减曲线，确保在合理的使用周期内保持可用容量。
极限场景。 弱信号、频繁切换、多设备并发、大流量冲击——这些压力测试用来发现边界条件下的问题。
第五关：软件与系统
固件的功能实现。 网络调度、功耗管理、连接管理、安全策略，这些逻辑需要在固件中实现并反复验证。
兼容性测试。 与各种终端设备的兼容性——不同品牌的手机、笔记本、平板、智能设备，都要能正常连接和使用。这个环节看似简单，实际经常出现意料之外的问题。
升级机制。 固件升级流程必须可靠，升级中断不能导致设备变砖。这需要设计完善的回滚机制。
管理端的功能。 App 或小程序的界面、交互、数据同步，需要与固件协调一致。
第六关：合规与认证
必要的认证。 型号核准、进网许可、3C 认证等，这些是产品上市的前提，流程耗时且材料要求严格。
实名的对接。 与身份认证服务的对接、数据合规的审查、隐私保护的设计，都需要在这个阶段完成。
运营商的适配。 与各合作网络的对接测试，确保在实际网络环境下工作正常。
第七关：试产与量产
试产验证。 小批量生产，验证生产线的工艺稳定性和一致性。试产中发现的问题需要回到设计端修改。
量产的一致性。 确保每一台出厂设备的性能一致，而不是只有样品表现良好。这需要生产环节的严格管控。
出厂检测。 每台设备出厂前的检测项目，包括射频性能、电池、外观、功能，确保不良品不流入市场。
为什么有些改进需要很久
理解了这个流程，就能理解为什么用户的一些合理建议不能立刻实现：
改动会牵动多个环节。 一个大电池的需求，不只是换块电池——它影响体积、结构、天线布局、散热设计、重量分布，几乎要重新走一遍整个流程。
验证需要时间。 可靠性测试中的很多项目（比如电池循环、长时间运行）本身就是按周甚至月计的。
供应链的响应周期。 定制器件需要开模、打样、验证，周期以月计。
认证的约束。 涉及射频参数或安全相关的改动，可能需要重新认证。
这不是推卸责任的说辞，而是硬件产品开发的客观规律。软件可以每周迭代，硬件的改动周期天然更长。
团队的一个共识
访谈中反复被提及的一点：研发中最重要的能力不是"做出新东西"，而是**"发现问题"**。
用户反馈的"信号不好"可能对应十几种不同的原因；测试中偶尔出现一次的掉线，可能指向一个深层的时序问题。能否把这些模糊的现象定位到具体的技术原因，决定了产品能否真正进步。
这也是为什么团队非常重视真实场景的测试数据——实验室的指标再漂亮，也比不上一次真实的户外使用记录。关于户外场景的实际表现，可以参考真实使用记录中的描述。