-
工业AI最大的谎言：必须上云
我在工业物联网行业待了几年，听过最多的一句话是：“边缘算力不够，AI必须上云。”说这话的人，要么是卖云服务的，要么是没在工厂待过的。先看一组真实数据 我统计了我们部署过的37个工业AI场景，推理任务分布是这样的：任务类型 占比 算力需求 异常检测（振动/温度/电流） 52% 极低，ONNX模型<10MB 趋势预测 21% 低，ONNX模型<50MB 视觉检测 18% 中，需NPU或GP
-
JT/T 808 校验码总算错？90% 的人卡在这 3 个地方
做 JT/T 808 开发，校验码算错是最高频的问题。我见过有人查了一整天，最后发现是转义处理漏了消息头。也见过有人把 BCD 高低位搞反，终端手机号解析出来全是乱码。今天把最常见的 3 个坑列出来，你对号入座。坑一：转义处理只做了消息体，没做消息头。JT/T 808 用 0x7E 作为帧头帧尾，0x7D 作为转义字符。很多人写转义处理时，只对消息体做了 0x7D02 和 0x7D01 的替换，忘
-
公司禁用开源工具，我用半年证明了什么
去年入职一家做车联网平台的公司，第一天开技术会，CTO 明确说了一句：“公司项目禁止使用来源不明的开源工具，出了问题谁负责？”我理解他的顾虑。商业工具有人兜底，自研工具可控，开源工具确实存在维护风险、安全风险、合规风险。但问题是，我们当时做 JT/T 808 联调，商业工具报价六位数，自研来不及，团队只能靠手写脚本硬扛。我偷偷下载了 JT-Simulate。为什么敢用？因为它开源，代码就在那里。我
-
我测了5个边缘AI平台，最后选了最“寒酸”的那个
上个月帮一个做设备运维的朋友选边缘 AI 平台。他的需求很朴素：工厂里有 200 台设备，装了振动和温度传感器，想做个异常告警，预算不高，不想换硬件，不想数据上云。我陪他测了 5 个平台，结果挺意外的。测试对象和结果平台部署耗时最低内存断网可用多模型编排本地 LLM硬件绑定AWS Greengrass2 天1GB+部分❌❌倾向 AWSAzure IoT Edge1.5 天1GB+❌❌❌倾向 Azu
-
我花 3 天写的 808 解析器，被一条真实报文打崩了
前年接了一个道路运输平台的项目，需要解析 JT/T 808-2019 的位置上报报文。我当时的想法很简单：协议文档又不复杂，自己写一个解析器，可控、可定制、不依赖第三方。于是我花了 3 天，写了转义处理、校验码计算、BCD 解码、大小端转换，还写了一套单元测试。本地跑了几十条构造报文，全部通过。我当时觉得自己挺牛。然后真实终端接进来了。第一条报文就把我的解析器干崩了。终端手机号解析出来是乱码。我查
-
车联网平台用微服务，是我见过最大的技术笑话
这句话会得罪很多人。但我还是要说。一个真实项目去年，一个客户找我做技术咨询。他们的车联网平台上了微服务，拆了30多个服务。我问他：为什么拆这么多？他说：微服务架构啊，高内聚低耦合，独立部署，技术异构。我说：你们多少终端？他说：5000台。5000台终端，30个微服务。平均每个服务承载166台终端。微服务在车联网的典型问题第一，网络开销。微服务之间通过HTTP或gRPC通信。一次位置上报，网关服务要
-
“开源工具能用在生产项目里吗？”我用 JT-Simulate 做了半年部标联调后的真实感受
每次在团队里推荐开源工具，总会有人问：“开源的东西，出了问题谁负责？”“代码质量能保证吗？”“会不会有安全风险？”我做部标协议开发六年，用过自研工具、商业工具、开源工具。说实话，没有哪个工具是完美的。商业工具支持好，但贵，而且定制困难。自研工具可控，但维护成本高，人员一流动就没人管了。开源工具免费，但需要自己判断质量。JT-Simulate 是我半年前开始用的。当时项目要做 JT/T 808 和
-
“JT/T 808 已经过时了？”——当我同时对接 808 和 GB/T 32960 时，才发现工具选错了
这个问题在车联网圈子里几乎每年都要吵一次。做道路运输的坚持 JT/T 808，做新能源的力推 GB/T 32960。去年我接了一个混合项目：既要对接道路运输车辆，又要接入新能源车。两个协议都要支持，而且要在同一个平台上调试。一开始我们想得简单：JT/T 808 和 GB/T 32960 各写各的解析器，各调各的设备。结果调试阶段直接崩溃。JT/T 808 用 7E 转义，GB/T 32960 用
-
“压测必须用真实设备？”我用仿真工具模拟 100 台终端后，发现了平台的致命 bug
前年做一个部标平台项目，甲方要求：“上线前必须做 500 台终端并发测试，而且必须用真实设备。”采购 500 台终端是什么概念？硬件成本、SIM 卡、流量费、场地、电源，加起来六位数。更麻烦的是，真实终端型号杂，行为不一致，压测结果根本不可控。有的终端心跳间隔 30 秒，有的 60 秒；有的注册完立刻鉴权，有的要等 5 秒。团队吵了一周。一派说真实设备才靠谱，另一派说仿真工具足够。最后折中：先用
-
我给工业网关装了个“大脑”：512MB内存跑通边缘AI推理全链路
某工厂产线振动传感器已经部署了3年，数据一直在采集，但从未被实时分析。工人靠经验判断异常，一次轴承故障导致停机8小时，损失超过50万。为什么不加AI？因为老板说“换硬件太贵，上云不安全”。这是工业现场的真实困境。传统云端AI方案面临四大痛点：网络延迟高、断网即瘫痪、数据隐私合规、推理成本贵。而EdgeAgent Hub将AI推理能力下沉到边缘侧，让每一台工业网关都拥有自主决策的“大脑”。我们在一台
-
别再劝新人学Wireshark了，那是劝退
我带过的 3 个新人 第一个新人，我让他装 Wireshark，抓包看 REGISTER。他抓了一天，问我：“这些报文我看得懂每个字，但不知道哪行是错的。”第二个新人，我给他一份 401 认证失败的抓包。他对着 RFC 3261 看了两天，最后问我：“realm 和 nonce 到底哪个是密码？”第三个新人，直接说：“哥，我能不能不学 Wireshark，你告诉我怎么查就行。”三个新人，零个靠 W
-
我为什么劝你别用Kubernetes做车联网网关
上个月，一个做车联网的兄弟找我，说他们网关上了K8s，结果终端批量掉线。我问他：你网关怎么部署的？他说：Deployment，三个副本，Service做负载均衡。我说：TCP长连接，你用什么负载均衡？他说：K8s Service啊。我沉默了。K8s Service做TCP长连接负载均衡的致命问题K8s Service默认是iptables模式。iptables做四层负载均衡，是基于连接跟踪的。什么
-
“手写 JT/T 808 报文才是真本事？”——一个车联网老兵的反思
去年做某省级网约车平台对接时，团队里一位老架构师坚持：“JT/T 808 报文必须手写，用工具生成的都是花架子，出了问题你连字节在哪都不知道。”我承认，手写报文确实能逼你理解协议。但现实是，我们对接 7 个终端厂商，每个厂商的 0x0200 位置上报都有细微差异。有人把报警标志位少移了一位，有人把经纬度精度搞错，还有人时间格式用本地时间。手写解析代码写到第三周，团队已经开始互相甩锅。最典型的一次：
-
JT/T 808 联调实战：用 JT-Simulate 一键跑通注册、鉴权、心跳、位置上报
开发 JT/T 808 平台或终端时，最典型的联调流程就是：终端注册；平台回复注册响应；终端鉴权；终端发心跳；终端上报位置；平台下发指令。如果没有真实终端，手动模拟这些流程非常痛苦。JT-Simulate 提供了一个更省事的方式：创建仿真设备，让它自动连接目标平台，自动走完整个上线流程。操作步骤打开 JT-Simulate，进入「设备管理」；填写终端手机号，比如 013800001234；填写目标
-
存储过程迁移自动化率深度分析
一、一个反直觉的数据 数据库迁移中，DML 查询的自动转换成功率接近 100%。但存储过程、函数、触发器等过程性对象的自动转换成功率，规则引擎只能做到 3.8% 到 31.2%-1。同一个工具，同样的语法解析引擎，为什么差距这么大？二、语法树能解析的，和业务逻辑能理解的，是两回事 存储过程的核心问题在于：它不只是语法，它是业务逻辑的容器。一个 500 行的 PL/SQL 存储过程里，可能包含：嵌套
-
Go车联网网关：从0到100万连接，我踩过的坑
车联网网关的核心指标只有一个：能扛多少终端连接。一台货车一个终端，一个终端一条TCP长连接。10万台车就是10万连接，100万台车就是100万连接。听起来不多，但每条连接都要处理心跳、位置上报、报警、鉴权、参数下发。写不好，几万连接就把内存打满。我们做JTE的时候，目标很明确：单机100万连接。这篇文章讲清楚我们怎么做到的，以及踩过的坑。第一版：一个连接一个goroutineGo最舒服的地方就是g
-
为什么我不用AI做服务器自愈——一个反面案例的思考
前言 2026年，AI运维（AIOps）是个热词。大模型能写代码、能分析日志、能做决策。很多人问我：ServerGuard为什么不用AI？今天不绕弯子，直接回答：我用过，然后我放弃了。先说一个真实的反面案例 去年我尝试把GPT接进告警处理流程。思路很直接：告警触发时，把系统指标、日志、进程列表打包发给模型，让它判断“该不该自动修复”。第一周，效果很好。磁盘告警，模型说“清理/tmp目录下的临时文件
-
【Go】开源hertz-admin：面向信创与内网交付的 Go 后端脚手架
项目已开源：下载地址Go 后端项目从零起步，真正花时间的从来不是业务代码。分层怎么划、错误码从哪个号段开始、权限在哪一层拦、日志怎么切分、配置从哪里读、版本号怎么注入、镜像怎么打小——这些决定项目长期可维护性的决定，每个新项目都要重做一遍，而且每个项目做得都不一样。做的时候不觉得，半年后回头看，自己都嫌乱。信创和内网交付又会额外压上三件事：服务器不出外网，go mod download 直接卡死；
-
为什么我放弃了自研JT808网关，改用开源底座
做了三年车联网，我做过一个决定：放弃自研JT808网关。这个决定不容易。团队花了半年写的代码，说扔就扔。但后来证明，这个决定是对的。自研网关的三年我们的JT808网关，最开始是2019年写的。当时的需求很简单：接收终端位置上报，存到MySQL，提供查询API。第一版很快上线，跑了几百台车，没问题。然后问题来了。2020年，接了某厂商的终端，发现附加信息ID编码不一致。 标准里附加信息ID是1字节，
-
我抓了3天包，最后发现是DeviceID大小写
摘要 一个县级平台项目，12 台摄像头，注册全通，目录只显示 3 台。厂家互相甩锅，我抓了 3 天包，最后发现问题藏在一个字母的大小写里。这篇文章复盘全过程，以及我现在怎么用工具 3 分钟定位同类问题。正文 第一天：所有人都说不是自己的问题 项目现场，12 台摄像头，品牌混装：海康 6 台、大华 4 台、宇视 2 台。平台是县里统一采购的国标平台。设备注册全部成功，平台能看到 12 台设备在线。但
