嵌入式加LLM这个组合最近在技术社区里讨论度极高。我在嵌入式一线干了十余年2024年开始认真把大模型往板子上塞踩过的坑比走过的桥还多。今天的核心观点很明确做这件事的正确姿势就是标题里那六个字——约束、构建、硬件闭环。嵌入式不是玄学LLM也不是悬空概念两者之间差的不只是算力而是一整套工程方法。这篇文章想跟你聊聊我实际项目里的方案、参数、踩坑记录以及为什么我坚定认为硬件闭环才是嵌入式AI的真正价值终点。1. 先说清楚为什么嵌入式LLM是伪命题也是真命题1.1 两个世界的基本盘很多人一听到嵌入式加LLM第一反应就是板子上跑个ChatGPT。这个直觉对但方向错得离谱。嵌入式世界的基本盘是MCU、SoC、RTOS、Linux、C/C资源以KB和MHz计讲究的是确定性和实时性。LLM世界的基本盘是Transformer、Token、上下文窗口、权重资源以GB和GHz计追求的是拟合和生成质量。两者的数量级差距有多大我做个不太严谨但直观的对比一颗STM32F407168MHz主频、192KB RAM这是嵌入式里很常见的芯片。一颗训练用的A10080GB显存、几十T算力。差了大约五个数量级。这个差距意味着我们不可能直接把大模型搬到传统单片机上而是要先回答三个问题什么能跑怎么跑跑完干什么这三个问题刚好对应标题里的约束、构建和硬件闭环。我见过太多人一上来就想在STM32上跑7B模型结果自然是卡死、内存溢出、连工程都编不过。这就像想用一辆自行车拉集装箱不是自行车不行是目标定错了。真正的问题不是能不能跑LLM而是在哪个硬件层级上跑什么规模的模型、做什么推理、怎么形成闭环。1.2 热词里的约束到底指什么你去看现在和约束相关的热门内容——XDC约束、时钟mux约束、IO约束、CP-SAT约束求解器、算力约束下的资源配置建模——会发现这个词在嵌入式和LLM两个语境下有完全不同的含义但底层逻辑高度一致。在硬件设计里约束是物理规定。引脚分配、时钟频率、时序关系这些不满足板子就上不了电、代码就跑不起来。这是硬约束没有商量余地。在系统层面约束是资源边界。CPU算力、内存带宽、功耗、电池容量、实时性要求这些决定了你在硬件上能部署多复杂的算法。在LLM层面约束变成了语义边界。Token数量限制、上下文窗口长度、知识截止时间、回答范围这些都是软性的但突破了一样会出问题。把这三层约束统一看待你会发现嵌入式加LLM的本质是一个多层约束下的优化问题。既然是多层约束那就得用到正经的约束求解工具比如CP-SAT这类约束求解器来做资源调度和任务规划。后面我会展开讲。1.3 硬件闭环为什么是价值终点我在项目里反复验证过一个判断单机跑一个LLM聊天机器人价值有限但如果在嵌入式硬件上形成感知-决策-执行-反馈的闭环价值会完全不一样。嵌入式硬件天生适合形成闭环。它本身就带传感器接口、通信总线、GPIO、PWM、电机驱动天然连接物理世界。LLM加入之后闭环变成了这样传感器采集数据经过边缘推理生成结构化的环境描述LLM根据描述做出决策再通过硬件接口控制执行器动作执行结果通过传感器反馈回来形成新一轮决策。这个闭环的价值在于LLM不再是一个被动的问答机器而是变成了系统的决策引擎。而且闭环里的真实运行数据可以回流到训练端持续微调模型模型再部署回硬件这就是一个完整的数据飞轮。没有硬件闭环LLM只是一朵云有了硬件闭环LLM才是真正长在物理世界里的智能体。2. 约束先从硬件设计里的硬约束说起2.1 XDC约束、IO约束与时钟mux约束不满足就上不了板我做FPGA相关项目时很多编译问题根本不是逻辑写错而是约束没写对。XDC约束是Xilinx FPGA的约束文件标准里面最关键的就是IO约束和时钟约束。IO约束看起来很简单比如把某个信号分配到指定引脚写一行就行set_property PACKAGE_PIN AB12 [get_ports clk_in] set_property IOSTANDARD LVCMOS33 [get_ports clk_in]但真正难的是时序约束。你要告诉工具链时钟频率是多少、哪些信号在同一个时钟域、哪些是跨时钟域的比如时钟mux切换时到底算哪个域。这就像装修时先确定每个插座的功率和位置水电阶段不规划好后期改动成本极高。我踩过最典型的坑是代码仿真怎么跑都对一旦综合布局布线时序报错一片红。原因就是忘了在XDC里为关键路径添加set_max_delay约束。那种仿真通过、上板翻车的体验做过FPGA的都懂。所以我的原则是约束文件不是到最后调板时才补的而是在写设计的第一天就同步维护。每一次新增接口、每一条跨时钟域路径都要立即反映到XDC里。这个习惯帮我避开了大量后期返工。说到底硬约束的哲学就是——先接受规则再谈优化。2.2 系统软约束算力、内存、功耗、实时性怎么算如果说XDC约束是设计期约束那系统级软约束就是运行期约束包括算力、内存、功耗和实时性。这四个指标在做硬件选型时就得算清楚不能靠拍脑袋。算力预算怎么算举个例子假设你有一块搭载Cortex-A53四核的板子运行一个300M参数的小模型做文本分类。一次推理大约需要3G次浮点运算。如果NPU算力是1 TOPS那就是每秒1万亿次操作推理延迟约3毫秒完全能接受。但如果你换成一个7B模型一次推理大约需要14G次浮点运算即使有8 TOPS的NPU延迟也接近2秒这就不适合做实时控制任务了。内存预算更容易忽略。7B模型用FP16存储权重就是14GB加上激活值和框架开销整机内存少于16GB根本跑不动。而很多嵌入式板子内存只有1GB、2GB你得量化成INT4权重压缩到3.5GB再配合内存映射和分页加载才能勉强跑起来。功耗预算则决定了整个方案能不能落地为产品。我做过一个手持设备项目电池只有2000mAh如果推理时平均功耗超过2W续航就撑不过一个班次。所以每次模型更新后我都会实测满载推理功耗和待机功耗差0.5W都要重新评估方案。实时性预算同样重要。工业控制场景里从传感器采样到执行器响应整个闭环通常要求100ms以内。留给LLM推理的时间可能只有30ms这要求模型极小、推理极快还不能被系统调度卡顿影响。我的经验是实时性不是优化出来的而是预算出来的——先划定时间片再决定每个环节能花多少时间。2.3 LLM侧的约束Token、上下文窗口与知识边界LLM这一侧的约束最基础的是Token机制。大家聊得火热的LLM的Token三个点——Key我是谁、Query我在找什么、Value我能提供什么本质是注意力机制里三个向量的角色分工。放到嵌入式的场景里理解Query就是我现在需要什么信息比如传感器数据异常时系统问这个温度突变可能是什么原因Key是知识库或上下文里每个条目的标签用于匹配哪些内容与我相关Value是匹配到的具体内容比如某个故障案例的详细处理步骤。三个角色配合决定了模型在生成回答时注意力落在哪里。在嵌入式部署中上下文窗口就是一道硬墙——模型能记住的Token数量有限超过就截断。窗口越大内存占用越高、推理越慢。所以我们在边缘端做LLM时通常把上下文压得很小甚至只保留最近几轮对话或最近一段传感器历史。知识边界是另一道墙。纯靠模型内部参数记住的专业知识尤其是我做过的设备故障诊断、农业环境监测这类场景经常出现一本正经胡说八道。正确的做法是先把知识边界画清楚这个模型允许回答什么、不允许回答什么、遇到超出边界的问题该怎么回。然后把边界内的知识做成结构化库通过检索去约束模型的生成范围这就是RAG检索增强生成的底层逻辑。2.4 约束求解器与资源配置建模当约束太多、互相冲突时人工调配就会顾此失彼。比如一张板子只有一个NPU多个任务都在排队或者一个嵌入式Linux系统里CPU核既要跑控制逻辑又要跑推理调度怎么分配合理这时候就该上约束求解器了。CP-SAT是Google OR-Tools里的约束求解器专门解决这类组合优化问题。它的思路是把需求建模成变量和约束再用搜索算法找最优解。举个例子假设有K个推理任务每个任务需要特定时长的NPU时间和截止时间问怎么安排才能不超时这是典型的时间窗口调度问题。用CP-SAT写一个简化模型大概是这样的from ortools.sat.python import cp_model model cp_model.CpModel() # 任务时长和截止时间 tasks [(3, 10), (2, 8), (4, 12), (1, 5)] # 创建每个任务的启动时间变量 starts [] for i, (dur, deadline) in enumerate(tasks): start model.NewIntVar(0, 20, fstart_{i}) starts.append(start) model.Add(start dur deadline) # 截止约束 # 资源冲突同一时刻只能有一个任务占用NPU intervals [] for i, (dur, _) in enumerate(tasks): intervals.append(model.NewIntervalVar(starts[i], dur, starts[i] dur, finterval_{i})) model.AddNoOverlap(intervals) # 互斥约束 # 求最早完成时间 makespan model.NewIntVar(0, 30, makespan) for i, (dur, _) in enumerate(tasks): model.Add(makespan starts[i] dur) model.Minimize(makespan)这个模型跑起来很快几毫秒就能给出一套排班方案。我在边缘网关项目里就用过它做任务调度器当多个传感器数据同时触发LLM请求时谁先推理、谁排队、把哪个任务分给NPU、哪个跑CPU全部自动排好实时性得到明显改善。算力约束下提升大语言模型能力的资源配置建模这个方向本质就是这个思路。不要盲目堆硬件而是把现有算力当作约束条件通过优化调度把每一份算力用在刀刃上。这是我推荐的工程化路径成本低、见效快。3. 构建从交叉编译到知识库装配3.1 嵌入式Linux的构建内核、rootfs与交叉工具链构建在嵌入式Linux世界里是一套成熟但反直觉的流程。你在一台x86的电脑上写代码但目标系统是ARM所以要用交叉编译工具链。工具链的版本、C库、内核头文件必须匹配否则编译出来要么跑不起来要么行为诡异。我见过最典型的坑主机GCC太新交叉编译工具链用的还是老版本glibc编译时链接到了主机库部署到板子上直接报version GLIBC_2.34 not found。解决方法是严格使用工具链自带的sysroot编译时指定--sysroot链接时别让主机路径混进来。构建内核也有讲究。menuconfig配置内核选项设备树描述硬件结构这两步错了系统起不来。我习惯在改硬件配置时先编译设备树单独验证再全量编译内核不然一个错误要等二十分钟。rootfs可以用BusyBox手搓也可以用Buildroot或Yocto自动化生成。我项目里一般选Buildroot因为它配置简单、产出可控适合中小型产品。这里要强调的是嵌入式Linux的构建不是一个命令跑完就结束的工序它是一种随时可能出问题的系统工程。配置项之间相互依赖有些内核选项没开驱动的编译就过不了。所以我的原则是构建脚本必须版本化、可复现任何一次构建都要记录工具链版本、内核版本、配置文件的哈希值不然别人接手时根本没法复现。3.2 通信协议与LLM网关让嵌入式数据变成LLM能读懂的文本嵌入式和LLM之间要打通通信协议是第一道关卡。嵌入式领域最常见的5种通信协议是UART、SPI、I2C、CAN、Ethernet。它们各有各的适用场景协议速率量级典型场景与LLM对接的方式UART115200bps~几Mbps调试、低速传感器串口转Wi-Fi/网关再对接SPI几十MbpsFlash、屏、高速传感器本地采集后汇总传输I2C几百Kbps温湿度、加速度计本地采集后汇总传输CAN1Mbps~几Mbps汽车、工业控制CAN网关转MQTT/HTTPEthernet百兆/千兆工业以太网、网关直接走TCP/HTTP/WebSocketLLM本身不认识UART帧也不认识CAN报文。你需要一个LLM网关把底层设备的二进制数据转成模型能理解的文本或JSON结构。比如CAN总线上一帧报文是ID8字节数据网关解析之后可以变成{source:engine_temperature, value: 87.5, unit:celsius, timestamp: 2025-06-11T10:30:00Z}再喂给LLM做诊断分析。LLM网关的实际作用不止是协议转换还包括鉴权、路由、限流和上下文管理。为什么有些团队选择用Go写这类网关因为Go在并发连接和网络吞吐上的表现好部署又是一个静态二进制放到嵌入式Linux板子上很省心。我个人在网关项目里用过Go真香。3.3 知识库构建LLM Wiki与图谱化RAG现在大家常聊的LLM Wiki知识库一开始是Andrej Karpathy建议的把自己的LLM知识按主题像Wiki一样持续记录、互相链接而不是零散地记碎片笔记。这个思路放在企业级嵌入式项目里同样适用——你可以为设备故障、环境规则、操作手册分别建立知识主题然后通过检索把相关知识抽取出来。知识库构建的完整链路我总结为五步采集、清洗、切分、向量化、装配。采集是收集文档、日志、传感器历史数据、故障案例清洗是去重、去噪、格式化切分是把长文本切成适当大小的chunk一般按段落或语义边界做太短会丢失上下文太长则检索不精准向量化是用embedding模型把chunk变成向量装配则是把向量索引和知识结构组织起来。要不要上neo4j这类图谱数据库取决于业务结构是否强关联。我做农业知识库时把作物-病害-环境条件-防治措施建成了图谱这样LLM在回答黄瓜叶片黄化可能是什么病时能沿着关系链找到病害节点、关联环境因素比单纯向量检索精准得多。如果只是零散FAQ那普通向量库就够用。3.4 构建方式跨界C/C与Maven的通用逻辑构建这个词在软件工程里的含义远比编译一行命令丰富。Java开发者用Maven或Gradle管理依赖、编译、打包、发布C/C嵌入式开发者用CMake加Makefile完成类似工作。两者的底层逻辑是一样的依赖管理、编译顺序、产物校验、版本一致。我经常跟团队里年轻人说别觉得自己写C就比写Java的低级构建系统的复杂度不比任何框架低。一个典型的嵌入式CMake工程要处理交叉工具链、静态库链接、条件编译、头文件路径任何一个环节错位产物就不能用。编码规范约束也是构建的一部分。C/C工程可以接入clang-format和clang-tidy在构建时自动检查命名、缩进、潜在内存问题。这样做的好处是把规范约束变成机器执行的规则而不是靠人肉眼review。Java侧的Checkstyle干的是同一件事。构建系统还承担不参与构建的检查——我踩过一个坑某个源文件忘了加进CMakeLists.txt代码改了根本没编译进去调试时奇怪为什么行为不变最后发现是个旧二进制。从那以后我坚持构建产物要打上源码哈希。4. 硬件闭环把大模型塞回小芯片4.1 模型压缩三件套量化、剪枝、蒸馏模型再大真正部署到嵌入式硬件时都得过压缩这一关。最有效的是量化。FP32权重转成INT8体积直接变四分之一转成INT4体积变八分之一。7B模型FP16占14GBINT4量化后大约3.5GB配合内存映射和按需加载一部分高端边缘设备就勉强能跑。速度同样受益同样的算力INT8的推理吞吐大约是FP16的两倍以上。量化的代价是精度损失。分类任务感受不明显生成任务却可能明显变差。我用llama.cpp加载量化模型时Q4_K_M这种混合量化格式是性价比比较高的档位质量下降可控尺寸压缩明显。剪枝是把不重要的权重直接删掉结构化剪枝能减少计算量但需要重新微调恢复效果。蒸馏则是用大模型教小模型让一个几百M的小模型尽量逼近大模型的输出能力。我的建议是先量化再看效果不行就微调蒸馏最后才考虑剪枝。顺序别搞反因为剪枝的操作复杂度最高、收益不确定性最大。4.2 边缘推理与NPU加速如果只是CPU推理很多嵌入式设备是扛不住的。好在现在的SoC基本都集成NPU比如瑞芯微的NPU算力从0.8 TOPS到6 TOPS不等跑轻量模型足够了。NPU的使用要遵循它的数据格式偏好。很多NPU对INT8有优化你的模型部署前得先做校准把动态范围映射到INT8。有些NPU只支持特定算子集合不支持的算子会落到CPU上执行性能断崖下跌。所以选模型时我会优先选那些算子简单、在目标NPU上验证过的架构比如MobileNet、轻量YOLO、TinyBERT这类。CPU和NPU的分工也值得设计。我的做法是实时性要求高的控制逻辑留在CPU裸跑或RTOS里NPU专心跑推理两者共享内存通过环形缓冲区通信避免拷贝延迟。交互类AI任务才把模型放进LLM链路里。4.3 感知-决策-执行闭环的实现硬件闭环的关键是把感知-决策-执行-反馈设计成一条完整链路。我做过一个工业设备异常监测项目链路是这样的传感器侧振动、温度、电流传感器以1kHz采样边缘端的MCU负责数据采集和特征提取比如计算振动频域特征、温度变化率。提取后的特征以1Hz的频率传给Linux侧的推理服务。推理服务先跑一个轻量异常检测模型如果发现异常再调用LLM做诊断LLM结合知识库给出可能的故障原因和建议动作。动作层的执行器接受LLM生成的结构化指令比如降低转速20%、开启散热风扇由MCU转换为PWM信号控制。这个闭环里我最看重的是反馈回路。执行动作后传感器继续采样如果异常指标没有改善LLM会在下一轮决策中调整策略。这样系统就具备了自我纠错的能力。单靠一个固定阈值模型做不了这种自适应因为规则没法穷举所有场景LLM的常识和推理能力补上了这块短板。4.4 一个可落地的闭环架构示例给你一个我在温室大棚环境控制项目里实际使用的架构可供参考。硬件端是STM32负责传感器采集和继电器控制经RS485总线或Ethernet连接一颗RK3588边缘网关。网关跑嵌入式Linux上面部署了向量检索服务和轻量LLM推理服务。数据流是STM32每30秒上报一次温湿度、土壤湿度、光照强度。网关先把数据写入本地时序库然后触发一次判断如果数值都在正常范围内不调LLM只做记录如果有越界或突变立即从知识库检索对应作物、对应阶段的管理规则连同最近一小时传感器历史一起打包成Prompt发给LLM。LLM输出结构化的JSON指令网关解析后通过MQTT下发给STM32执行比如开启滴灌、调整遮阳网。延迟预算我卡得比较死传感器采集到网关入库1秒内检索加Prompt组装200msLLM推理在本地NPU跑个小模型500ms内指令下发到执行器100ms。整个闭环在2秒以内完成对温室环境调控来说完全够用。如果推理放到云端网络抖动就会让这个闭环松散所以我坚持本地推理兜底、云端训练迭代这是硬件闭环的工程底线。5. 常见问题与排查技巧实录5.1 构建与约束冲突的典型问题做这套东西我攒了一堆疑难杂症挑几个高频的给你。XDC约束冲突最常见的报错是multiple drive on net。意思是同一个信号被多个驱动程序驱动。排查方法很简单在综合日志里搜网络名看是不是把某个输入信号误接到了输出引脚或者同一根线在两个模块里都有赋值。另一个高频问题是时序不收敛setup time违例。大部分情况是时钟约束不完整尤其是跨时钟域路径没写set_clock_groups或set_false_path。这不是代码问题是约束缺失。交叉编译的坑前面提到过版本不匹配。这里多讲一个工具链的字节序不对。ARM默认小端但有些工业处理器支持大端编译时没加-mlittle-endian整个系统就是跑不起来而且报错很隐蔽。排查方法是先用file命令看编译产物架构再确认目标平台端序。模型加载内存溢出是部署LLM的日常。我的排查顺序是先看权重格式是不是FP32是的话先量化成INT8再看是不是一次性加载了完整上下文试试分页加载或减小上下文窗口最后看是不是框架的临时缓冲区开太大调低KV cache。实测很多跑不起来并不是算力不够而是内存被白白浪费了。5.2 推理与知识库侧的问题LLM推理慢是最容易被吐槽的点。排查首Token延迟时我会先确认模型是否真的跑在NPU上你可以看推理日志里的device字段然后检查上下文长度是不是被Prompt里的历史数据撑爆了。有些检索结果动辄几千Token模型还没开始生成光解析输入就耗了半秒。解决方案是对检索结果做重排只保留最相关的几段或者在Prompt里限制引用长度。知识库召回质量差多半是切分和向量化的问题。我遇到过一个案例设备操作手册里严禁在通电状态下拆机这种警告句因为跟前后段落切分到了不同chunk导致检索时召回失败。解决办法是采用语义切分先按标题层级切再把每个段落里的警告、注意事项单独拆出来作为独立条目。embedding模型也要选场景匹配的中文技术文档就别用英文为主的模型。还有一个我反复强调的坑板子过热降频。嵌入式设备散热条件差推理持续满载CPU/NPU温度飙到85度后会主动降频推理延迟瞬间翻倍。排查时不要只看CPU占用率还要看温度曲线。我项目里给NPU加了主动散热控制温度到70度就提高风扇转速延迟就稳定了。下面的速查表是我贴在工位上的你也能用问题现象大概率原因先说一句排查计划上板时序报错XDC缺失或跨时钟域未约束查综合日志、补set_false_path程序运行后行为不变源文件没进构建系统核对构建文件、核验产物哈希模型加载崩溃内存不足/格式不对量化、降上下文、检查端序推理越来越慢发热降频或缓存膨胀看温度曲线、调KV cache检索答非所问chunk切分或embedding不匹配重切、换embedding模型指令下发无响应网关JSON解析失败打印原始报文、核对字段名5.3 关于应用层开发是不是嵌入式的一点看法这个问题被反复讨论我也说说我的判断。应用层开发比如嵌入式Linux上的业务逻辑、网关服务、协议解析确实属于嵌入式系统的一部分但它只是其中一层。硬件驱动、内核裁剪、板级移植、RTOS实时性设计这些硬核内容才是嵌入式的根基。如果你只会应用层开发也能做出产品但遇到底层问题会抓瞎。我见过不少做上位机的同事一碰到设备树、中断、寄存器映射就无从下手这就是基础不牢。反过来如果你只懂底层寄存器不懂应用层数据结构、网络协议、AI推理做出来的系统也笨重难用。我的建议是应用层和底层都要碰。不要求精通每一层但至少要能看懂上下游在干什么。尤其在做嵌入式加LLM的项目后我的感受更深了LLM正好卡在应用层你要懂它才能把它嵌入到业务流程里但你也得懂底层约束否则部署就是纸上谈兵。6. 学习路线与工程化建议给想入场的你6.1 嵌入式学习路线怎么走如果你零基础想入嵌入式我给出的路线是C语言打底然后做单片机裸机开发再学RTOS再走嵌入式Linux最后接触AI部署。C语言是绝对的基本功指针、内存管理、结构体这些不熟练没法继续。单片机阶段用STM32或ESP32做几个小项目把GPIO、定时器、中断、UART和I2C调通这是硬件感觉的来源。RTOS阶段理解任务调度、信号量、队列这是应对实时性的基础。嵌入式Linux阶段去折腾根文件系统、设备树、内核模块能跑起来就算入门。最后才是AI部署先把TensorFlow Lite Micro或ONNX Runtime在开发板上跑通再做量化再上NPU。竞赛和开源项目是很好的加速器。蓝桥杯嵌入式这类竞赛至少能逼你完整走一遍项目链路省赛题目大多涉及传感器采集、显示、控制覆盖面很对。开源项目则建议找活跃的嵌入式Linux项目读代码你能看到工程化是怎么实践的。6.2 工程化建议宁可笨方案不要野路子我把这几年最深刻的经验浓缩成三条建议直接说人话。第一先把约束写在纸面上再动工。项目启动时按算力、内存、功耗、实时性、Token预算五个维度列一张表填入数字后续所有选型都拿这张表来对照。没有这张表方案一定会失控。第二构建系统从第一天就认真对待。交叉工具链、构建脚本、依赖版本全部进入版本控制。确保任何一个人在新环境里clone代码后一条命令就能构建出和线上一致的镜像。做不到这一点团队成员越往后协同成本越高。第三小步闭环先跑通再优化。别企图一步到位把大模型横向部署到全系统。选一个最小的场景比如只做传感器异常诊断先跑通采集到推理到执行的完整闭环稳定运行两周后再扩展。这个节奏让我避免了整套系统推翻重来的风险。结尾我的一点真实体会如果只总结一句话我会说嵌入式加LLM不是把模型文件复制到板子上而是把物理世界的约束翻译成模型的边界再用构建和闭环把两者焊接在一起。我做这个方向的时间不算长但已经明显感觉到真正有壁垒的不只是懂LLM也不只是懂嵌入式而是能同时驾驭两侧约束的人。最后再分享一个我个人的小习惯每次部署完一个新的边缘LLM任务我都会在板子上保留一个最小的冒烟测试脚本用一条真实传感器数据触发完整链路记录延迟和结果。这样每次改完代码、换完模型花两分钟就能确认整个闭环还是通的。这看似笨但在现场救过我太多次了。如果你也在做类似的事建议直接抄走这个习惯。