企业官网建设流程全解析

1. 一场正在发生的算力迁移

这几年搞工业自动化的朋友应该都发现了一个明显的变化：以前客户要工控机，开口就是“i5够不够”“能不能跑组态软件”“通讯接口全不全”，最近半年到一年，需求重点开始变成“能不能跑AI模型”“支持不支持GPU”“算力能达到多少TOPS”。项目标题里那句“边缘算力升级，工控机站上AI风口”，我理解下来就是这句话的行业化表达——工控机正在从传统的数据采集与运动控制上位机，逐步升级为边缘AI推理的主力载体。

先说清楚一个容易被混淆的概念：工控机（IPC）和我们日常用的商用电脑、服务器不是一回事。工控机强调的是工业级可靠性，宽温工作、抗振动、防尘、7×24小时不间断运行，接口也是为现场设备准备的，比如串口、CAN口、DIO、多网口。过去它主要跑的是PLC逻辑、组态界面、运动控制卡驱动、数据采集程序，CPU占用率根本跑不满，四核八线程都嫌多。但现在要在工厂车间里跑机器视觉质检、设备预测性维护、安全帽检测这类AI应用，情况就完全变了。

为什么AI一定要跑到工控机上来，而不是继续依赖云端服务器？这里有个很现实的问题：工业现场的反馈链路要求毫秒级延迟。比如高速产线上的缺陷检测，产品通过相机视野的时间可能只有几十毫秒，你把图片传上云端、等推理结果返回，这个往返时延在公网环境下根本不可控。而且很多工厂车间网络条件并不好，甚至出于数据安全考虑不允许数据出园区。在这种约束下，把AI推理能力直接放到工控机上、部署在生产线旁边，是唯一合理的方案。云端负责模型训练和迭代，现场工控机负责实时推理，这个“云训练、边推理”的分工模式，正在成为主流架构。

适合读这篇文章的朋友，我大约分成三类：一类是做工业自动化集成项目的工程师，需要搞清楚边缘AI工控机到底怎么选型；一类是做算法或软件开发的工程师，刚接到把深度学习模型部署到工控机上的任务，需要一份能直接照着做的实操指南；还有一类是工厂设备管理或信息化负责人，需要理解供应商拿来的方案靠不靠谱、成本为什么这么高。三类读者，我都尽量兼顾。

2. 边缘算力升级：硬件选型的几个关键决策

2.1 算力形态的三种主流路线

AI算法本质上是大量矩阵运算，传统CPU虽然能做，但效率太低。边缘算力升级的第一步，就是给工控机引入专用算力单元。目前主流的路线大致有三条。

第一条是NVIDIA方案，包括Jetson系列嵌入式模组和桌面级RTX显卡。Jetson Orin系列在工业场景里用得非常多，因为它本身就是为边缘AI设计的，功耗低、算力密度高，而且还带着丰富的I/O接口。RTX显卡的优势则是CUDA生态成熟，PyTorch、TensorFlow的模型几乎不用改代码就能在上面跑，适合算力需求更大、又不想太折腾部署流程的项目。

第二条是Intel方案，包括Arc系列独立显卡、Movidius VPU以及第12代以后Core处理器自带的核显。Intel的优势在于和工控机原有的生态匹配度极高，很多传统工控方案就是Intel平台，直接在主板上加一张Arc显卡，软件层面用OpenVINO推理引擎，CPU和GPU可以协同工作。实测下来，对于轻量级视觉模型，这个搭配的成本控制非常好。

第三条是国产NPU方案，比如瑞芯微RK3588系列、算能BM1684系列、地平线旭日系列。这类芯片集成专用神经网络加速单元，单位功耗下的算力非常出色，而且国产化要求高的项目基本都会指定这类方案。但代价是软件生态相对封闭，模型需要转换成特定格式（比如RKNN），部分算子支持会有坑，调试经验需要积累。

我个人的选型习惯是这样的：项目国产化要求不明、团队又熟悉PyTorch，优先NVIDIA方案；算力需求不大、项目预算敏感、且开发周期紧的，走Intel方案；有明确国产化约束的，直接切国产NPU方案，尽早开始适配。

2.2 参数解读：TOPS、功耗、宽温与接口

很多刚接触边缘AI的工程师一看TOPS就开始选型，这是个容易被带偏的误区。TOPS（Tera Operations Per Second）是理论算力指标，实际环境下受制于芯片热设计功耗、散热条件、推理框架优化程度，真实跑出来的通量往往只有理论值的几成。我见过一个项目，采购时只看标称100TOPS的算力，结果现场温度偏高，机器降频之后推理速度只有预期的一半，最后只能换更大散热方案。

筛选硬件时，建议重点看这几个参数：第一是功耗和散热方式，无风扇工控机通常TDP上限在10W到30W之间，带风扇设计能到60W以上，这直接决定了整机尺寸和现场噪音；第二是工作温度范围，常规工控机是0到50摄氏度，爬产线靠近热源还需要宽温版本；第三是扩展接口，尤其是PCIe插槽数量和PCIe信道数，GPU、采集卡都要从这里走；第四是存储可靠性，工业级SSD和普通消费级SSD在长时间写入场景下寿命差距非常大。

做个简单对比表格能看得更明白：

顺便说一句，TOPS里的算力精度通常分FP16和INT8，两者数值差距大，跨芯片对比时要注意口径一致。INT8量化的算力数据看着漂亮，实际部署时模型精度是否达标，得靠实验验证。

2.3 工业级可靠性：别拿商用硬件拼现场

边缘算力升级不等于简单地把商用主机塞进机柜。AI工控机和普通NUC（迷你主机）虽然外观相似，内部设计差距很大。工业级主板的PCB板材、走线、元器件选型都按工业标准执行，抗电磁干扰能力经过严格测试，电源模块支持宽压输入和反接保护，关键时刻可以防止现场供电不稳定导致系统重启。商用NUC在这种环境下一个星期死机两次，就足够让人崩溃。

真正要关注的是几个平时容易忽略的点：BIOS级看门狗、掉电保护、系统盘冗余。看门狗功能在无人值守场景是刚需，程序跑飞或者系统假死时能主动复位，保证产线在线率。掉电保护在工厂里尤其重要，车间大功率设备启停瞬间电压波动严重，系统盘如果用的不是掉电保护型SSD，一次异常断电就可能造成文件系统损坏。我处理过一台AI工控机，现场断电后SSD出现大量坏块，后来换成带掉电保护的工业SSD之后再也没出过问题。

3. 软件栈搭建：把AI模型塞进工控机

3.1 操作系统与容器环境的选择

硬件选完之后，软件栈的搭建是决定项目成败的关键环节。很多传统工控工程师习惯用Windows + 组态软件的方案，但边缘AI部署目前的主流选择仍然是Linux，原因很简单：绝大多数AI推理框架和GPU驱动在Linux下的支持最好，稳定性也更高。我建议直接上Ubuntu 20.04或22.04长期支持版本，配合Docker容器化部署。

为什么一定要用Docker？工控机现场环境复杂，算法工程师交付的模型依赖PyTorch、TensorRT、opencv-python等各种库，版本稍有错位就可能导致重启后服务起不来。容器化之后，整个推理服务连同依赖一起打包，换一台机器跑，结果一致。更进一步，多套环境隔离也方便，比如同一台工控机同时跑视觉检测和振动信号分析两个服务，依赖互不干扰，某一套崩溃也不会影响另一套。

GPU在Docker环境里默认不被容器访问，需要安装NVIDIA Container Toolkit。安装步骤很简单：先装好GPU驱动，然后安装nvidia-container-toolkit，重启Docker服务后用docker run --gpus all参数启动镜像。注意，驱动版本和容器内调用的CUDA版本不一定要完全一致，容器里装CUDA的时候可以装不带驱动的runtime版本，避免冲突。

3.2 模型转换与量化：ONNX是中间枢纽

在实际项目中，模型从训练到部署通常要经过一个转换链条：训练框架（PyTorch/TensorFlow）导出为ONNX通用格式，再用各平台的推理引擎转换为最终的部署格式。比如NVIDIA平台是TensorRT的engine文件，Intel平台是OpenVINO的IR文件，国产NPU平台则是各自的专用格式。

这里有个非常关键的细节：模型格式转换不是简单复制粘贴，每一步都可能引入精度损失。PyTorch模型导出ONNX时，如果遇到动态尺寸或者某些特殊算子，导出的模型可能和原始模型行为不一致。量化到INT8时，权重从FP32的32位浮点压缩到8位整数，信息必然损失，但合理选择校准集（calibration set）可以把精度损失控制在可接受范围内。

校准集的选择是很多人容易犯的错误。有些工程师图省事随便挑了百来张图片做量化校准，部署后才发现模型在太阳光直射环境下识别率明显下降。量化校准集应该尽可能模拟现场真实数据分布，把各种光照、角度、遮挡情况都覆盖到。如果现场数据采集困难，至少用测试集的多类样本拼凑一个校准集，宁多勿缺。

3.3 ONNX导出与TensorRT转换的实际操作

对于PyTorch模型，导出ONNX的核心代码是torch.onnx.export，里面有三个参数细节决定成败：输入张量的尺寸不能写死，要么用dynamic_axes声明动态维度，要么把尺寸设置为固定值，但要在部署时保持一致；第二个是opset_version，TensorRT不同版本支持的算子版本不同，不匹配时会报错；第三个是导出模式，training=torch.onnx.TrainingMode.EVAL，确保dropout和batchnorm层处于推理状态，这个尤其容易忘记。

导出后的检查也同样重要。用onnxruntime跑一遍同一张输入图片，和PyTorch原始模型的输出做对比，最大误差超过1e-3就要怀疑导出环节出了问题。然后再用trtexec工具转TensorRT引擎：

trtexec --onnx=model.onnx --saveEngine=model.engine --fp16

如果显存足够，建议加上--fp16使用半精度推理，速度提升明显且精度损失可控。--fp16在某些算子不支持时会自动回退到FP32，不会导致转换失败，可以放心使用。转换完成后用TensorRT自带的profiler工具测一下单张图片推理延迟，和ONNX Runtime的预测结果比对，就能看到TensorRT优化后的提升幅度。实测常见的YOLO系列目标检测模型，TensorRT FP16推理速度比原始PyTorch能快3到5倍。

3.4 OpenVINO与RKNN平台的部署差异

如果走Intel平台路线，模型转换使用的是OpenVINO Model Converter，它将ONNX模型转换成一个XML描述文件和一个BIN权重文件。推理调用的是OpenVINO Runtime的Python API，CPU和GPU之间的设备选择只需在代码里改一个字符串参数。OpenVINO的特点是在Intel CPU上跑得很稳，尤其适合处理多路摄像头视频流，因为它在解码、预处理、推理一整条流水线上有完整优化。

国产NPU平台则要额外注意算子限制。以瑞芯微RK3588为例，模型先要转换为RKNN格式，转换工具是rknn-toolkit2，PyTorch模型导出ONNX是必须的前置步骤。RKNN转换过程中如果遇到不支持的算子，转换工具会报错或者自动替换成性能较低的算子，这些问题通常要手写自定义算子或者修改模型结构来解决。我建议在选择模型时优先考虑轻量化结构，比如MobileNet、ShuffleNet系列，以及YOLOX-S等中小规模模型，它们在边缘NPU平台的适配性普遍更好。

3.5 容器内的运行时环境配置

推理服务运行在容器里，几个系统参数要提前配好。首先是内存：深度学习推理虽然不像训练那样吃显存，但多路视频模型在CPU上的中间张量还是很耗内存，32GB起步、64GB更稳妥。其次是CPU隔离：在Docker里可以用--cpuset-cpus参数把推理进程绑定到特定核心，避免和采集程序抢CPU导致推理延迟抖动。第三是共享内存：--shm-size=2g是经验值，太小会导致多线程数据拷贝时进程崩溃。

GPU驱动的安装要格外细心。笔记本或工控机上的显卡安装驱动，一定先看Linux内核版本是否在驱动的官方支持列表里，内核版本过高或过低都会导致安装失败。用nvidia-smi确认驱动识别正常后再装nvidia-container-toolkit，顺序颠倒会莫名其妙报错。这里有个小技巧：Docker容器里不需要装驱动文件，只需要装CUDA的runtime版本，把--gpus all加上去就能正常调用GPU。

4. 一个容易被忽视的坑：工控机时间不准

4.1 单机时间漂移的现象与影响

聊完算力和部署，来说一个很多团队踩过坑，却经常被忽视的问题——工控机的时间准确性。标题里的热搜词有一条“没有联网的工控机时间不准确”，我在现场见过太多次了。单机工控机只要不连外网NTP服务器，系统时间就会慢慢漂移，快的时候一天能差出几分钟，慢的时候一个月差十几秒。

为什么工控机会频繁掉时间，原因大致有三个：主板上的实时时钟芯片（RTC）依赖一颗纽扣电池供电维持计时，电池电量不是无限可持续的；工控机使用的晶振精度本身就有一定误差，温度波动会加剧频率漂移；另外，操作系统层面的时间同步服务默认依赖NTP服务器，一旦网络不通，整个时间校准时序就会陷入无人管理状态。

时间不准看着是个小毛病，实际影响非常严重。最直接的是日志文件的时序错乱，产线数据的时间戳也是错的，一个质量为0的次品明明发生在14:03，日志里记录成14:07，追溯责任时整个时间链全乱。更隐蔽的问题是TLS证书校验：边缘工控机很多场景需要和云端服务器建立加密连接，证书有效期校验依赖本机时间，如果工控机时间比真实时间超前几分钟甚至几小时，云端就会直接拒绝连接或者证书验证失败，服务异常断开。调度任务也会被时间不准搞崩，比如定时上传数据、定时切换模型版本，全部错位执行。

4.2 排查思路与处理方案

排查工控机时间不准，先确认硬件层和系统层各自的差异：

1. 进入BIOS看硬件时间，用手机对一下，如果BIOS时间就不准，说明RTC芯片或电池有问题。
2. 如果BIOS时间准，但系统启动后时间逐渐偏移，则要检查系统时间同步服务的状态，以及是否配置了NTP服务器。
3. 检查纽扣电池电压是否正常，CR2032电池正常电压在3.0V到3.3V之间，低于2.7V就该换了。
4. 长期单机运行的工控机，建议直接把时间同步方案做成静态配置，而不是指望现网偶尔开一次外网。

解决手段分几层。第一层是有条件联网的场景，配置NTP服务，用靠谱的时间服务器源，同时缩短校准间隔，比如minpoll 6表示每64秒到4096秒之间自动校准一次。第二层是完全离线场景，最实际的方案是外接GPS/北斗授时模块，通过串口给工控机提供标准时间，成本不高、精度很高。第三层是硬件层面更换带温补晶振的RTC方案，或者至少换一块新电池，把晶振误差从几十ppm降低到数个ppm级别，一天偏差能控制在1秒以内。

还有一个特别容易被忽视的操作：修改工控机BIOS里的时间设置后，一定要重启进入系统生效，同时确认timedatectl的状态是NTP synchronized。我遇到过一台设备，BIOS时间明明改对了，重启后系统又自动恢复了错误时间，排查半天发现系统的systemd-timesyncd服务还在运行，旧的错误时间被缓存住了，需要先停掉服务再改时间。

4.3 我在现场的处理步骤

现场处理过一次典型故障：一台负责质量检测的AI工控机，系统时间比真实时间慢了两个小时，造成检测数据时间戳错位，MES系统那边对不上账。我当时按下面的步骤处理的：

1. 先用date命令查看系统时间，再对比当前真实时间，确认误差范围。
2. 执行systemctl status systemd-timesyncd检查时间同步服务状态，发现服务处于无网络可用的状态。
3. 进入BIOS查看RTC时钟，发现硬件时间本身就慢了1小时47分钟，判断纽扣电池老化导致RTC走时不准。
4. 换掉主板纽扣电池，重新在BIOS里设置当前时间，保存重启。
5. 系统内安装chrony作为NTP客户端，准备了一个内网时间服务器地址（局域网里搭一个挺简单），配置自动校准。
6. 在系统启动脚本里加一条chronyc makestep命令，确保开机3秒内完成首次时间校正，避免服务启动时序导致时间窗口错位。
7. 运行一周后复查，误差控制在几十毫秒以内，问题不再复发。

这套流程其实还有一个更省事的小技巧：在工控机旁边放一台支持NTP的智能电表或者网关设备，如果这类设备本身能获取授时信号，就可以直接作为时间源给网段内的工控机授时，省掉单独部署GPS模块的成本。

5. 实战场景拆解：从选型到上线的完整闭环

5.1 场景一：高速产线外观缺陷检测

这是边缘AI最典型的应用案例。一条每小时生产数千个零件的高速产线，检测工位部署高分辨率工业相机，要求对每个零件完成外观检测，不合格品自动剔除。这类项目算力规划的核心指标是“拍一张图的处理预算时间”，假设产线节拍是每秒两个零件，那么单张图片从采集到推理完成的时间预算就是500毫秒，留出相机触发和剔除以外的余量，推理时间最多能分到300毫秒。

我用过一个实际项目做参考：使用Jetson Orin Nano，算法模型是YOLOX-S，输入尺寸640×640，TensorRT FP16推理，单张耗时约38毫秒，完全没有压力。如果生产成本敏感，甚至可以同时跑两个模型，一个做大范围粗检、一个做细节精检，总耗时控制在100毫秒内，留出充裕余量。

这类项目的部署细节里，有两个容易被忽略的点：一是相机触发信号和推理程序的同步机制，推荐走硬触发，相机曝光结束立即给工控机一个脉冲信号，程序收到信号后再去取图推理，这样能保证时间一致性；二是模型更新策略，产线换规格时往往需要换模型，如果支持A/B分区切换，备用模型在后台热加载，切换对产线几乎是零影响。

5.2 场景二：复杂系统预测性维护

设备预测性维护方面，大部分企业落地的第一步是振动信号异常检测。在电机、泵、风机等关键旋转设备上安装加速度传感器，采集振动波形数据，工控机对波形做FFT变换提取频谱特征，然后用轻量级神经网络模型判断是否存在异常。

这类场景对算力的要求相对低，但对采集通道和实时性要求高。工控机需要多通道同步采集能力，一般扩展一张USB或PCIe采集卡，采样率至少10kHz以上。振动信号的特征提取是CPU密集任务，建议用多核处理器方案配合Intel的MKL数学核心库加速FFT计算，实测四核工控机单通道FFT分析耗时在10毫秒以内，八通道并发也只要40毫秒。

很多团队踩过振动数据与工况数据不同步的坑。振动波形采集时，现场设备转速、负载等信息没有同步记录，后期无论做频谱分析还是故障特征匹配，都缺了关键变量。解决方法是让工控机同时采集转速计信号，以转速作为角度域周期采样的基准，分析结果才稳定可靠。

5.3 场景三：多路视频流行为识别与安全监测

施工现场或厂区安全风险行为识别是边缘AI落地最快的场景之一，核心需求是同时解析多路摄像头画面，实时检测人员是否佩戴安全帽、进入危险区域、出现倒地等异常行为。这类项目对视频解码能力的要求甚至超过对AI推理算力的要求，多路1080P视频解码本身就会占满CPU，导致推理速度严重下降。

实测数据参考：一台Intel Arc A380工控机，OpenVINO执行YOLOX-S模型，最大并发能力在四路1080P视频同时推理时，每路稳定30FPS以上。解锁更高并发的方法是把视频解码任务委派给GPU硬件编解码单元，Intel平台上qsv硬解、NVIDIA平台NVDEC硬解，CPU占用率大幅下降，推理才有足够的算力余量。

这类部署做得稳，要做到三件事：网络规划要按路数算带宽，百兆交换机在四路1080P并发时就开始丢包了，千兆是底线；存储只保留异常报警前后的视频段，用预录像回绕的环形缓冲区方案，避免磁盘写满影响系统；远程运维通道要提前规划，边缘盒子分布在厂区各处，没有带外管理功能会浪费大量现场维护时间。

6. 常见问题与排查技巧实录

6.1 容器内调用GPU失败的排查

现象描述：同一台工控机，宿主机执行nvidia-smi正常，但进入Docker容器后看不到GPU设备，或者报错could not select device driver with capabilities: [[gpu]]。

排查步骤：

1. 执行docker run --rm --gpus all nvidia/cuda:11.8-base nvidia-smi确认容器是否能调用GPU。
2. 如果报错，先重装NVIDIA Container Toolkit，命令是apt-get install -y nvidia-container-toolkit。
3. 检查/etc/docker/daemon.json里是否配置了"runtimes": {"nvidia": {"path": "nvidia-container-runtime","runtimeArgs": []}}。
4. 修改配置后务必重启Docker守护进程：systemctl restart docker。
5. 部分工控机因为BIOS里开启了虚拟化技术影响GPU透传，出现异常时还要去BIOS关闭IOMMU相关的分支选项。

6.2 推理延迟突然飙升的表现

现象描述：模型部署初期延迟正常，运行两周后推理耗时从30毫秒涨到300毫秒，产线报警频繁。

可能出现的原因和排查方向：

我踩过一次典型的坑：部署完模型后加了个日志轮转脚本，每天凌晨3点打包压缩前一天的日志文件，正好和夜班产线高峰重叠，那段时间凌晨的推理延迟一路飙到400毫秒。后来把日志清理时间改到白班换班间隙，问题立即消失。

6.3 模型精度不达标的复盘路径

边缘AI项目验收阶段最尴尬的情况是现场准确率低于实验室。复盘时按下面几个方向排查：

1. 检查模型输入前处理是否和训练时完全一致，包括曝光、白平衡、对比度、图像缩放方式。很多算法工程师在实验室处理的是Photoshop导出的干净图片，现场工业相机输出的图片发灰、偏色，模型效果自然打折扣。
2. 检查是单张图片识别错误还是连续视频流识别错误。单张错果大概率是模型问题，连续视频流错果可能涉及视频丢帧、丢帧补偿逻辑缺陷。
3. 查看推理引擎的精度设置，ONNX Runtime默认FP32，TensorRT配置FP16时部分模型精度确实会下降，可以在engine转换时保存一份FP32版本对照试验。
4. 最关键的是要做数据回流。把现场推理错误的图片定期收集起来，重新训练模型，形成“数据回流→重新训练→模型下发”的闭环，现场准确率才能持续提升。

6.4 现场运维的三个小习惯

先说远程管理，边缘AI工控机分布在车间不同位置，一台台跑现场调试效率极低，一定要提前部署SSH跳板机和设备监控面板，系统状态、GPU显存、温度、推理延迟全部可视化。

再说备份，AI工控机的系统盘里既有操作系统又有模型文件、配置文件，一次性备份整个磁盘镜像是最稳妥的方案。用Clonezilla做整盘镜像，恢复时直接还原到新硬盘，比重新装系统少踩一半的坑。

最后说固件升级，工控机主板的BIOS、GPU驱动、容器运行时这些基础组件，如果没有明确的安全补丁或性能提升需求，尽量保持版本不变。现场出问题时版本升级是最难排查的隐性变量，固定版本能极大降低排障复杂度。

7. 一些实际操作后的心得体会

搞了这么多边缘AI工控机项目，最大的感受就是：真正让项目成败的往往不是模型精度，而是选型、部署、运维这条完整链条上那些不起眼的细节。

选型阶段，最忌讳拿着PPT上的算力参数直接下单。同一个型号在不同散热条件下的表现差距很大，最好租一台或者借一台样机，在接近现场的环境下跑一次完整的模型推理测试，用数据验证再定采购配置。我记得有个项目初期选了无风扇方案，实测模型对CPU多核压力太大，芯片温度直接飙到90度以上，整机被迫降频，后来换了一台带风扇的准系统才稳定下来。

部署阶段，有两件事值得多花一天时间做好：一个是把所有系统配置、依赖版本、启动脚本全部固化成一个标准的镜像模板，之后每台新设备直接刷镜像，配置再也不会出错；另一个是设计好日志和告警机制，工控机现场崩溃是常态，没有完善的告警就只能等产线停线了才发现问题。日志不光要记录错误，还要记录关键操作，至少要能在出事后恢复出前5分钟的完整上下文。

运维阶段，我的经验是不要迷信“全自动”，边缘算力的运维本质上是个平衡问题：自动化的部分要足够可靠，手动操作的部分要足够简单。比如模型更新，手动SSH上去改文件并不是什么问题，但前提是升级流程每一步都有回滚方案，万一新模型精度不行，一条命令切回旧模型，产线不中断，这才是真正的可用性。

写这篇文章时，我脑子里一直在回想那些现场处理故障的画面。边缘AI这个方向有个迷人的特点：它的技术栈横跨硬件、系统、算法、运维，每一个环节都有人踩坑，每一个坑都蕴含着真金白银的教训。希望这篇文字能帮后来者少走一些弯路，让工控机站上AI风口这件事，从概念真正落到能赚钱、能提效率、能稳定运行的生产线上。到最后，你会发现，做边缘AI落地的核心能力，其实就一句话：把一个技术问题，彻彻底底地解决在现场。