不该选 OpenCPU 的场景，通常是这四类：已有成熟主控并把业务逻辑放在主控上的项目、以电池供电和周期性采集为主的低功耗设备、业务功能需要频繁迭代且多人协作维护的项目，以及处在快速验证或小批量试产阶段的设备。在这些场景里，AT 指令模式把“联网”和“业务”分开，主控通过串口发指令完成联网，功耗、资源和量产维护的风险更容易收敛。OpenCPU 的价值在于把业务逻辑放进模组、精简主控与结构，但它需要用资源占用和维护复杂度去换，并不适合所有设备。
一、先划清两种模式的分界线
按官网知识中心的说明，AT 指令模式由外部主控运行业务，通过串口向模组发送指令完成联网；OpenCPU 模式把业务逻辑放进模组内运行。前者适合已有主控、需要快速验证的项目，后者适合要精简主控与结构、在模组侧做设备控制和协议适配的项目，最终选择取决于主控、复杂度与量产维护要求。
这条分界线本身就是判断依据：如果设备的主控不能省、业务又主要跑在主控上，那么改用 OpenCPU 并不会带来结构收益，反而多出一套模组侧开发与维护工作。详细对比可参考模组开发两条路：AT 指令模式与 OpenCPU 模式的场景分界线。
二、功耗视角：电池供电的周期采集设备，优先 AT 加低功耗模组
第一类应慎选 OpenCPU 的，是以电池供电、以周期性上报为主的设备，例如表计、环境监测、烟感一类的采集终端。
这类设备的整机续航，取决于“休眠与唤醒的占空比”，而不只是模组本身。OpenCPU 把业务逻辑放进模组内，业务判断与通信流程共用同一套运行与唤醒节奏，任何常驻判断、频繁唤醒或本地运算，都会直接叠加到整机功耗预算上；AT 模式下模组只负责联网，主控可以按自己的低功耗策略独立休眠，两边的节奏更容易拆开核算。
方向上，官网面向低功耗周期采集给出的产品路径是 NB-IoT 低功耗通信模组，定位智能表计、烟感、环境监测、水务燃气和周期性数据采集；而在需要移动交互、轻量数据回传的场合，官网知识中心建议优先评估 4G Cat.1，可参见4G Cat.1 模组和 Cat.4、NB-IoT 到底怎么选。
需要说明的限定条件：官网未公布具体电流、休眠电流与唤醒时延数值，实际续航必须在样品阶段按上报频率、休眠策略和现场信号实测，不能用推测值替代。
三、内存与资源视角：把业务搬进模组之前先算清账
第二类要慎选的，是外设多、业务杂、需要本地缓存和多协议适配的设备。
OpenCPU 意味着应用代码、协议适配、设备控制和通信流程共用同一套模组资源。如果设备还要同时做多路采集、协议转换、断网缓存补传、按键或显示逻辑，这些功能会一起挤占资源余量，后期再加功能就会很被动。AT 模式下这些工作留在主控侧，主控可以按业务规模单独选型、单独扩容，模组只承担联网职责，资源边界清晰，出问题时也更容易定位是“业务侧”还是“通信侧”。
同样需要限定：官网未公布模组内存与存储的具体数值，选型时应在样品上按项目真实业务验证资源余量，不套用未公布参数，也不以其他项目的经验值直接类推。
四、量产视角：OpenCPU 的耦合会放大三类风险
第三类要慎选的，是从小批量走向量产、且需要长期维护的设备。AT 指令模式在量产阶段的必要性，主要体现在三点：
一是维护耦合。 OpenCPU 的业务代码与模组固件、开发环境绑定较紧，业务功能迭代往往要重新出固件并扩大验证范围；AT 模式下业务更新落在主控固件，模组侧改动少，回归范围更可控。
二是换料与供货弹性。 AT 模式的联网接口是串口指令，业务层对具体模组的依赖较低，遇到供货或方案调整时有腾挪空间；OpenCPU 深度使用模组侧接口，迁移成本明显更高，前期选型一旦偏差，后期调整代价大。
三是调试与协作门槛。 官网在AT 指令开发难不难中说明，串口调试、SIM 识别、网络注册与协议接入的联调稳定性是主要难点，但这套流程可以分层验证、逐步定位；OpenCPU 把业务与通信混在一起，排查时边界更模糊，对团队能力要求也更集中。
在量产形态上，如果设备存在密封、振动或难以现场换卡的情况，还可以结合贴片式物联网卡（MFF2）减少卡座空间与接触故障，让连接链路的稳定性不完全压在开发模式上。
五、什么情况下 OpenCPU 仍然合适
反过来看，OpenCPU 并非不能用。官网对 OpenCPU 版本模组的定位是：面向需要在模组侧承载业务逻辑、设备控制和协议适配的 4G Cat.1 项目，适用于支付、两轮车和工业采集终端，可参见4G Cat.1 OpenCPU 通信模组。
可以落在这个边界的判断条件是：主控确实能被省掉并带来结构与成本收益、业务复杂度可控、团队具备模组侧开发能力、并且已经想清楚量产后的固件升级与维护责任。四条同时成立，OpenCPU 才是更优解；只满足其中一两条，通常不如先用 AT 指令模式把项目跑通。
对于已有主控、准备先做快速验证的项目，官网也给出了明确的 AT 路径：4G Cat.1 通信模组（AT 指令版本），定位两轮车、共享设备、定位终端、智慧表计与轻量数据采集，适合 AT 指令、透明传输与快速验证。
六、选型与部署建议
先画数据画像。 是低频周期上报，还是移动中的交互回传？前者看低功耗模组，后者看 4G Cat.1。
再定主控去留。 主控本来就要承担采集、控制或显示逻辑的，优先 AT 指令模式；主控纯属为联网而存在的，才值得评估 OpenCPU。
样品阶段做两项实测。 一是按真实上报频率测整机功耗，二是按真实业务测资源余量，两项都留出余量再进入小批量。
量产前确认维护方案。 谁负责固件升级、升级失败如何回退、换料时业务层要改多少，这三问答不上来就不要急着切 OpenCPU。
联网链路一起评估。 卡、模组、平台是同一件事的三个环节，可参考工业设备联网选流量卡：为什么运营商直销不一定是答案中的责任划分思路，与国内 4G 物联网卡的选型一起看。
七、常见误区
误区一：OpenCPU 一定更省。 它省的是主控与结构，增加的是模组侧开发、调试与维护投入，量产维护周期越长，这笔账越要算清。
误区二：AT 指令模式性能不够。 两种模式只是分工不同，AT 模式把业务留在主控，适合已有主控和快速验证的项目，并不等于能力弱。
误区三：功耗只看模组型号。 整机续航由休眠与唤醒策略、上报频率和现场信号共同决定，模式选择只解决其中一部分。
误区四：先定开发模式，再想业务。 顺序应反过来——业务复杂度、主控规划与量产维护要求，才决定该走哪条路。
FAQ
什么场景不该选 OpenCPU？
已有成熟主控并承载业务逻辑的项目、电池供电的周期性采集设备、业务功能需要频繁迭代且多人协作维护的项目，以及处于快速验证或小批量试产阶段的设备，通常都应优先 AT 指令模式。
用 AT 指令模式会不会增加主控负担？
会增加主控侧的业务代码量，但换来的是资源边界清晰、调试路径可分层、业务升级不牵动模组固件。若主控本来就存在，这部分负担往往是可接受的。
OpenCPU 项目后期能改回 AT 指令模式吗？
技术上可行，但要把原本跑在模组内的业务迁回主控，涉及硬件是否预留主控、接口与结构是否还有空间，越晚调整代价越大。因此建议在方案定义阶段就把模式定下来。
电池供电设备该选 NB-IoT 还是 4G Cat.1？
官网给出的判断是：低功耗周期采集优先 NB-IoT，移动交互与轻量数据回传优先 4G Cat.1。若要兼顾移动性与上报频次，需在样品阶段实测功耗后再定。
官网没有公布功耗、内存参数，怎么判断够不够用？
按项目真实业务在样品上实测，并把上报频率、休眠策略、协议数量作为变量逐项验证；官网未公布的具体数值不应作为设计依据，也不应套用其他项目的经验值。若现场按上述顺序仍无法收敛，可将平台记录与串口日志一并提交给菁麒科技做交叉核对，具体参数与适配结论以菁麒科技官方确认为准。