1. 从“对话”到“执行”的范式转移过去两年大多数人对AI的认知还停留在“聊天机器人”阶段——你问它答它帮你写邮件、改文案、解释概念。但如果你最近半年真正在工业现场或终端设备上折腾过AI落地就会发现一个明显的拐点AI正在从“Chat”走向“Do”。这个转变不是简单的功能叠加而是底层节奏的彻底改写。我所在的团队从去年开始接触工业视觉检测项目最初的想法很朴素用大模型做缺陷描述人工再复核。但实际跑下来发现真正产生价值的环节根本不是“描述”而是“决策执行”。比如一条产线上的工业相机拍到异常AI不仅要判断“这是划痕”还要直接触发分拣机构把不良品吹走同时把异常数据回写到MES系统。整个过程没有人工介入从触发到执行完毕控制在200毫秒以内。这才是工业场景真正需要的AI——不是陪你聊天而是替你干活。这个转变涉及三个层面的重构交互层从自然语言对话变成指令级执行部署层从云端集中式推理变成端侧边缘协同数据层从静态知识库变成实时流式处理。对于做终端开发、工业自动化、边缘计算的朋友来说理解这个节奏变化比追任何一个具体模型都重要。因为模型会迭代但“AI必须能做事”这个方向不会变。这篇文章我会从实际项目经验出发拆解AI从“Chat”到“Do”的底层逻辑重点讲清楚工业场景和终端设备上怎么落地、踩过哪些坑、哪些方案真正跑得通。适合正在做AI应用开发、工业自动化改造、终端智能升级的从业者参考也适合刚入行想了解真实落地情况的朋友。2. 为什么“能聊天”和“能干活”是两码事2.1 从概率生成到确定性执行的鸿沟聊天场景下AI输出一段文字用户自己判断对不对、用不用。但工业场景下AI输出一个指令设备直接执行。这中间的容错空间从“人类可纠正”变成了“物理不可逆”。我见过一个真实案例某工厂用视觉AI做零件计数模型把“重叠的两个零件”识别成“一个”导致机械臂抓取时撞机维修停了半天。问题出在哪聊天模型可以容忍5%的错误率但执行环节要求99.99%的确定性。这个鸿沟的根源在于大语言模型的本质是概率生成而工业执行需要确定性逻辑。你让模型输出“抓取零件A”它可能生成“抓取零件A”也可能生成“抓取零件 A”多一个空格在聊天里无所谓在指令解析里就是失败。所以从Chat到Do的第一步是在模型输出和执行器之间加一层“确定性适配层”——把自然语言指令转成结构化JSON再做schema校验最后才发给PLC或机械臂控制器。2.2 延迟敏感度差了三个数量级聊天场景对延迟的容忍度大概是2-5秒用户等得起。但工业场景里传送带上的零件从相机视野到分拣口可能只有300毫米按1米/秒的速度算留给AI的时间窗口只有300毫秒。这300毫秒要完成图像采集、预处理、推理、后处理、指令下发。如果用云端大模型光网络往返就超了。所以工业AI检测这类场景单机部署是刚需云联网只能做辅助。我实测过某国产工业相机搭配边缘盒子跑轻量检测模型从触发到输出IO信号可以压到80毫秒以内。但如果把图像传到云端跑大模型再返回稳定在400毫秒以上产线速度一快就跟不上。这也是为什么现在工业现场越来越多看到边缘计算盒子、AI加速卡这类硬件——不是赶时髦是物理定律逼的。2.3 数据闭环的节奏完全不同聊天AI的数据闭环是“用户反馈-模型迭代”周期以周甚至月计。工业AI的数据闭环是“检测-执行-结果回写-模型微调”周期以小时计。因为产线上的缺陷样本是持续产生的今天出现的新缺陷类型明天可能就批量出现。如果模型不能快速吸收新样本漏检率会迅速上升。我们现在的做法是边缘端保留最近24小时的疑似样本每天凌晨自动触发一次增量训练新模型验证通过后灰度推送到产线。这个节奏在聊天场景里不可想象但在工业场景里是常态。AI在工业里的角色不是“一次性部署的工具”而是“持续进化的产线成员”。3. 工业场景落地从检测到执行的完整链路3.1 工业视觉检测的典型架构选型先讲一个我们实际交付过的项目某汽车零部件产线需要检测表面划痕、凹坑、脏污三类缺陷检测到不良品后触发吹气分拣。产线速度每分钟60件即每件1秒留给检测的时间窗口约400毫秒。架构选型上我们对比了三种方案方案推理延迟部署成本维护难度适用场景云端大模型API300-800ms低低低速抽检边缘服务器GPU50-150ms中中多相机产线工业相机内置AI20-80ms高低单相机高速产线最终选了边缘服务器方案原因有三一是产线有4个工位需要同时检测边缘服务器可以集中处理二是后续要加新缺陷类型边缘服务器方便更新模型三是成本比换4台智能相机低。这里的关键决策点是不要盲目追求端侧推理如果产线工位多、模型更新频繁边缘服务器反而是更务实的选型。3.2 模型选型的核心考量不是越大越好工业异常检测算法和通用视觉大模型是两条路线。我们试过用某开源视觉大模型做零样本缺陷检测效果在实验室还行到现场就崩了——光照变化、相机抖动、产品批次差异都会导致误检率飙升。后来换成专门训练的轻量检测网络基于YOLO系列改进参数量只有大模型的百分之一但在特定产线上的准确率从82%提升到97%。这里有个经验工业场景的AI模型领域适配比通用能力重要得多。你不需要模型认识猫和狗你只需要它认识这个零件上的划痕。所以选型时优先考虑是否支持小样本微调、是否支持增量学习、推理框架是否支持目标硬件加速。大模型在工业里的角色更多是“辅助标注”和“异常描述”而不是直接做检测决策。3.3 从检测结果到执行指令的转换检测出缺陷只是第一步真正难的是把检测结果变成设备能执行的指令。我们踩过的坑包括坐标系不统一相机像素坐标到机械臂世界坐标的转换、时序不同步检测完成时零件已经过了分拣口、指令格式不兼容不同品牌PLC的IO信号定义不同。解决方案是加一层“执行适配中间件”核心做三件事坐标转换用标定板做手眼标定把像素坐标映射到物理坐标再根据传送带速度做位置补偿。时序对齐用光电传感器触发相机同时记录编码器位置确保检测结果和零件位置一一对应。指令封装把“吹气”“推杆”“报警”等动作封装成标准接口底层适配不同PLC协议。这层中间件看起来不起眼但它是“Chat”到“Do”的关键桥梁。没有它AI输出再准也执行不了。4. 终端设备上的AI执行从终端复用说起4.1 终端工具链的AI化改造“终端复用”这个词最近在开发者社区很热但很多人理解偏了。终端复用的本质是让一个终端会话同时承载多个AI Agent的执行流。比如你在调试一个嵌入式设备一个Agent负责监控串口日志一个Agent负责分析异常一个Agent负责自动执行修复命令。这三个Agent共享同一个终端会话但互不干扰。我目前在用的方案是Tabby终端工具配合自定义插件把AI Agent的执行输出和人工操作输出分流到不同的pane。这样做的好处是AI执行的命令有完整审计日志人工操作不受干扰而且可以随时接管AI的执行流。实测下来调试效率比纯人工操作提升明显尤其是重复性的日志分析和参数配置。4.2 ESP32等嵌入式终端的AI执行实践ESP32这类微控制器上跑AI听起来不现实但实际有可行路径。我们的做法是ESP32只做数据采集和指令执行推理放在边缘网关。比如一个温湿度监测终端ESP32每5秒采集一次数据通过MQTT发给边缘网关网关上的轻量模型判断是否异常异常时下发指令让ESP32触发继电器。这里的关键是通信协议要足够轻。我们试过用HTTP延迟和功耗都太高换成MQTTProtobuf后单次通信数据量从2KB降到200字节电池续航从3天延长到3周。对于终端设备来说AI执行的代价不只是算力还有通信功耗。选型时一定要把通信开销算进去。4.3 Linux终端下的AI命令执行在Linux终端里让AI直接执行命令目前最成熟的方案是Claude Code这类工具。它的工作模式是你描述任务它生成命令你确认后执行。但工业场景下我们更激进一些——对于低风险命令如查询状态、读取日志配置白名单后允许AI直接执行对于高风险命令如修改配置、重启服务强制人工确认。这个分级策略很重要。我见过有人把AI Agent的权限开到最大结果模型误判执行了rm -rf虽然是在测试环境但也够吓人的。AI执行力的边界应该由风险等级决定而不是由技术能力决定。5. 多AI协作与执行编排5.1 为什么需要多AI协作单Agent的能力边界很明显一个模型很难同时擅长视觉检测、日志分析、指令生成。我们的做法是拆成多个专职Agent通过消息队列协作。比如工业检测场景视觉Agent负责图像推理决策Agent负责根据检测结果生成执行策略执行Agent负责把策略转成PLC指令。三个Agent通过Redis Stream通信每个Agent可以独立更新模型不影响其他环节。这种架构的好处是容错和可解释。如果检测结果异常可以回溯是哪个Agent出了问题而不是面对一个黑盒。而且每个Agent的模型可以针对特定任务优化整体效果比单一大模型好。5.2 执行编排的节奏控制多Agent协作最大的坑是“节奏不一致”。视觉Agent推理用了50毫秒决策Agent用了30毫秒执行Agent用了20毫秒加起来100毫秒但产线节拍是80毫秒就超时了。解决方案是给每个Agent设超时阈值超时则走降级策略。比如决策Agent超时直接走预设的保守策略全部判为不良品宁可误杀不可漏杀。这个降级策略在工业场景里是必须的。聊天场景可以等工业场景不能等。AI执行的节奏必须匹配物理世界的节奏而不是反过来。6. 常见问题与排查技巧实录6.1 工业AI检测的典型故障排查现象可能原因排查方法解决方案误检率突然升高光照变化/镜头脏污检查光源亮度和镜头清洁度加装遮光罩定期清洁推理延迟增大边缘盒子温度过高降频监控CPU/GPU温度和频率改善散热限制并发数指令执行失败坐标偏移/时序错位重新标定检查编码器信号增加位置补偿算法模型效果下降产品批次变化对比新旧样本分布触发增量训练6.2 终端AI执行的避坑经验第一个坑终端复用时的会话隔离。多个AI Agent共享终端时如果环境变量和工作目录不隔离会出现A Agent改了PATH导致B Agent命令找不到的情况。我们的做法是用容器或命名空间隔离每个Agent的执行环境。第二个坑命令注入风险。AI生成的命令如果直接拼接用户输入可能被注入恶意指令。必须做参数化处理禁止字符串拼接执行。第三个坑日志淹没。AI执行产生的日志量是人工操作的几十倍如果不做分级和轮转磁盘很快爆满。建议AI执行日志单独存储保留7天关键操作日志永久保留。6.3 模型选型的常见误区很多人问“工业AI检测用什么大模型足够”这个问题本身就问错了。工业检测的核心不是大模型而是领域数据轻量模型工程化部署。大模型在工业里的最佳角色是辅助生成标注数据、辅助分析异常日志、辅助生成测试用例。直接拿大模型做实时检测目前性价比不高。7. 我个人的实操体会从Chat到Do的转变本质上是从“信息处理”到“物理执行”的跨越。这个跨越里技术只占三成七成是工程化——怎么保证确定性、怎么控制延迟、怎么做降级、怎么审计执行。我见过太多团队在模型精度上死磕结果卡在指令下发环节。如果你正在做工业AI或终端AI的项目我的建议是先把执行链路跑通哪怕用规则引擎先顶着再逐步替换成AI决策。因为执行链路的工程问题坐标转换、时序对齐、协议适配比模型问题更难解决也更值得提前投入。另外终端设备的AI化不要追求“全本地推理”合理的边缘协同架构往往更务实。ESP32负责采集和执行边缘网关负责推理和决策云端负责训练和更新各司其职整体节奏才稳。最后分享一个小技巧在AI执行的关键节点加“人工确认钩子”初期可以频繁触发随着信任建立逐步减少。这样既保证了安全又不会因为过度保守而失去AI执行的价值。我在实际项目里用这个策略从每天确认几十次降到每周确认几次团队对AI执行的信任是逐步建立起来的急不得。
1. 从“对话”到“执行”的范式转移过去两年大多数人对AI的认知还停留在“聊天机器人”阶段——你问它答它帮你写邮件、改文案、解释概念。但如果你最近半年真正在工业现场或终端设备上折腾过AI落地就会发现一个明显的拐点AI正在从“Chat”走向“Do”。这个转变不是简单的功能叠加而是底层节奏的彻底改写。我所在的团队从去年开始接触工业视觉检测项目最初的想法很朴素用大模型做缺陷描述人工再复核。但实际跑下来发现真正产生价值的环节根本不是“描述”而是“决策执行”。比如一条产线上的工业相机拍到异常AI不仅要判断“这是划痕”还要直接触发分拣机构把不良品吹走同时把异常数据回写到MES系统。整个过程没有人工介入从触发到执行完毕控制在200毫秒以内。这才是工业场景真正需要的AI——不是陪你聊天而是替你干活。这个转变涉及三个层面的重构交互层从自然语言对话变成指令级执行部署层从云端集中式推理变成端侧边缘协同数据层从静态知识库变成实时流式处理。对于做终端开发、工业自动化、边缘计算的朋友来说理解这个节奏变化比追任何一个具体模型都重要。因为模型会迭代但“AI必须能做事”这个方向不会变。这篇文章我会从实际项目经验出发拆解AI从“Chat”到“Do”的底层逻辑重点讲清楚工业场景和终端设备上怎么落地、踩过哪些坑、哪些方案真正跑得通。适合正在做AI应用开发、工业自动化改造、终端智能升级的从业者参考也适合刚入行想了解真实落地情况的朋友。2. 为什么“能聊天”和“能干活”是两码事2.1 从概率生成到确定性执行的鸿沟聊天场景下AI输出一段文字用户自己判断对不对、用不用。但工业场景下AI输出一个指令设备直接执行。这中间的容错空间从“人类可纠正”变成了“物理不可逆”。我见过一个真实案例某工厂用视觉AI做零件计数模型把“重叠的两个零件”识别成“一个”导致机械臂抓取时撞机维修停了半天。问题出在哪聊天模型可以容忍5%的错误率但执行环节要求99.99%的确定性。这个鸿沟的根源在于大语言模型的本质是概率生成而工业执行需要确定性逻辑。你让模型输出“抓取零件A”它可能生成“抓取零件A”也可能生成“抓取零件 A”多一个空格在聊天里无所谓在指令解析里就是失败。所以从Chat到Do的第一步是在模型输出和执行器之间加一层“确定性适配层”——把自然语言指令转成结构化JSON再做schema校验最后才发给PLC或机械臂控制器。2.2 延迟敏感度差了三个数量级聊天场景对延迟的容忍度大概是2-5秒用户等得起。但工业场景里传送带上的零件从相机视野到分拣口可能只有300毫米按1米/秒的速度算留给AI的时间窗口只有300毫秒。这300毫秒要完成图像采集、预处理、推理、后处理、指令下发。如果用云端大模型光网络往返就超了。所以工业AI检测这类场景单机部署是刚需云联网只能做辅助。我实测过某国产工业相机搭配边缘盒子跑轻量检测模型从触发到输出IO信号可以压到80毫秒以内。但如果把图像传到云端跑大模型再返回稳定在400毫秒以上产线速度一快就跟不上。这也是为什么现在工业现场越来越多看到边缘计算盒子、AI加速卡这类硬件——不是赶时髦是物理定律逼的。2.3 数据闭环的节奏完全不同聊天AI的数据闭环是“用户反馈-模型迭代”周期以周甚至月计。工业AI的数据闭环是“检测-执行-结果回写-模型微调”周期以小时计。因为产线上的缺陷样本是持续产生的今天出现的新缺陷类型明天可能就批量出现。如果模型不能快速吸收新样本漏检率会迅速上升。我们现在的做法是边缘端保留最近24小时的疑似样本每天凌晨自动触发一次增量训练新模型验证通过后灰度推送到产线。这个节奏在聊天场景里不可想象但在工业场景里是常态。AI在工业里的角色不是“一次性部署的工具”而是“持续进化的产线成员”。3. 工业场景落地从检测到执行的完整链路3.1 工业视觉检测的典型架构选型先讲一个我们实际交付过的项目某汽车零部件产线需要检测表面划痕、凹坑、脏污三类缺陷检测到不良品后触发吹气分拣。产线速度每分钟60件即每件1秒留给检测的时间窗口约400毫秒。架构选型上我们对比了三种方案方案推理延迟部署成本维护难度适用场景云端大模型API300-800ms低低低速抽检边缘服务器GPU50-150ms中中多相机产线工业相机内置AI20-80ms高低单相机高速产线最终选了边缘服务器方案原因有三一是产线有4个工位需要同时检测边缘服务器可以集中处理二是后续要加新缺陷类型边缘服务器方便更新模型三是成本比换4台智能相机低。这里的关键决策点是不要盲目追求端侧推理如果产线工位多、模型更新频繁边缘服务器反而是更务实的选型。3.2 模型选型的核心考量不是越大越好工业异常检测算法和通用视觉大模型是两条路线。我们试过用某开源视觉大模型做零样本缺陷检测效果在实验室还行到现场就崩了——光照变化、相机抖动、产品批次差异都会导致误检率飙升。后来换成专门训练的轻量检测网络基于YOLO系列改进参数量只有大模型的百分之一但在特定产线上的准确率从82%提升到97%。这里有个经验工业场景的AI模型领域适配比通用能力重要得多。你不需要模型认识猫和狗你只需要它认识这个零件上的划痕。所以选型时优先考虑是否支持小样本微调、是否支持增量学习、推理框架是否支持目标硬件加速。大模型在工业里的角色更多是“辅助标注”和“异常描述”而不是直接做检测决策。3.3 从检测结果到执行指令的转换检测出缺陷只是第一步真正难的是把检测结果变成设备能执行的指令。我们踩过的坑包括坐标系不统一相机像素坐标到机械臂世界坐标的转换、时序不同步检测完成时零件已经过了分拣口、指令格式不兼容不同品牌PLC的IO信号定义不同。解决方案是加一层“执行适配中间件”核心做三件事坐标转换用标定板做手眼标定把像素坐标映射到物理坐标再根据传送带速度做位置补偿。时序对齐用光电传感器触发相机同时记录编码器位置确保检测结果和零件位置一一对应。指令封装把“吹气”“推杆”“报警”等动作封装成标准接口底层适配不同PLC协议。这层中间件看起来不起眼但它是“Chat”到“Do”的关键桥梁。没有它AI输出再准也执行不了。4. 终端设备上的AI执行从终端复用说起4.1 终端工具链的AI化改造“终端复用”这个词最近在开发者社区很热但很多人理解偏了。终端复用的本质是让一个终端会话同时承载多个AI Agent的执行流。比如你在调试一个嵌入式设备一个Agent负责监控串口日志一个Agent负责分析异常一个Agent负责自动执行修复命令。这三个Agent共享同一个终端会话但互不干扰。我目前在用的方案是Tabby终端工具配合自定义插件把AI Agent的执行输出和人工操作输出分流到不同的pane。这样做的好处是AI执行的命令有完整审计日志人工操作不受干扰而且可以随时接管AI的执行流。实测下来调试效率比纯人工操作提升明显尤其是重复性的日志分析和参数配置。4.2 ESP32等嵌入式终端的AI执行实践ESP32这类微控制器上跑AI听起来不现实但实际有可行路径。我们的做法是ESP32只做数据采集和指令执行推理放在边缘网关。比如一个温湿度监测终端ESP32每5秒采集一次数据通过MQTT发给边缘网关网关上的轻量模型判断是否异常异常时下发指令让ESP32触发继电器。这里的关键是通信协议要足够轻。我们试过用HTTP延迟和功耗都太高换成MQTTProtobuf后单次通信数据量从2KB降到200字节电池续航从3天延长到3周。对于终端设备来说AI执行的代价不只是算力还有通信功耗。选型时一定要把通信开销算进去。4.3 Linux终端下的AI命令执行在Linux终端里让AI直接执行命令目前最成熟的方案是Claude Code这类工具。它的工作模式是你描述任务它生成命令你确认后执行。但工业场景下我们更激进一些——对于低风险命令如查询状态、读取日志配置白名单后允许AI直接执行对于高风险命令如修改配置、重启服务强制人工确认。这个分级策略很重要。我见过有人把AI Agent的权限开到最大结果模型误判执行了rm -rf虽然是在测试环境但也够吓人的。AI执行力的边界应该由风险等级决定而不是由技术能力决定。5. 多AI协作与执行编排5.1 为什么需要多AI协作单Agent的能力边界很明显一个模型很难同时擅长视觉检测、日志分析、指令生成。我们的做法是拆成多个专职Agent通过消息队列协作。比如工业检测场景视觉Agent负责图像推理决策Agent负责根据检测结果生成执行策略执行Agent负责把策略转成PLC指令。三个Agent通过Redis Stream通信每个Agent可以独立更新模型不影响其他环节。这种架构的好处是容错和可解释。如果检测结果异常可以回溯是哪个Agent出了问题而不是面对一个黑盒。而且每个Agent的模型可以针对特定任务优化整体效果比单一大模型好。5.2 执行编排的节奏控制多Agent协作最大的坑是“节奏不一致”。视觉Agent推理用了50毫秒决策Agent用了30毫秒执行Agent用了20毫秒加起来100毫秒但产线节拍是80毫秒就超时了。解决方案是给每个Agent设超时阈值超时则走降级策略。比如决策Agent超时直接走预设的保守策略全部判为不良品宁可误杀不可漏杀。这个降级策略在工业场景里是必须的。聊天场景可以等工业场景不能等。AI执行的节奏必须匹配物理世界的节奏而不是反过来。6. 常见问题与排查技巧实录6.1 工业AI检测的典型故障排查现象可能原因排查方法解决方案误检率突然升高光照变化/镜头脏污检查光源亮度和镜头清洁度加装遮光罩定期清洁推理延迟增大边缘盒子温度过高降频监控CPU/GPU温度和频率改善散热限制并发数指令执行失败坐标偏移/时序错位重新标定检查编码器信号增加位置补偿算法模型效果下降产品批次变化对比新旧样本分布触发增量训练6.2 终端AI执行的避坑经验第一个坑终端复用时的会话隔离。多个AI Agent共享终端时如果环境变量和工作目录不隔离会出现A Agent改了PATH导致B Agent命令找不到的情况。我们的做法是用容器或命名空间隔离每个Agent的执行环境。第二个坑命令注入风险。AI生成的命令如果直接拼接用户输入可能被注入恶意指令。必须做参数化处理禁止字符串拼接执行。第三个坑日志淹没。AI执行产生的日志量是人工操作的几十倍如果不做分级和轮转磁盘很快爆满。建议AI执行日志单独存储保留7天关键操作日志永久保留。6.3 模型选型的常见误区很多人问“工业AI检测用什么大模型足够”这个问题本身就问错了。工业检测的核心不是大模型而是领域数据轻量模型工程化部署。大模型在工业里的最佳角色是辅助生成标注数据、辅助分析异常日志、辅助生成测试用例。直接拿大模型做实时检测目前性价比不高。7. 我个人的实操体会从Chat到Do的转变本质上是从“信息处理”到“物理执行”的跨越。这个跨越里技术只占三成七成是工程化——怎么保证确定性、怎么控制延迟、怎么做降级、怎么审计执行。我见过太多团队在模型精度上死磕结果卡在指令下发环节。如果你正在做工业AI或终端AI的项目我的建议是先把执行链路跑通哪怕用规则引擎先顶着再逐步替换成AI决策。因为执行链路的工程问题坐标转换、时序对齐、协议适配比模型问题更难解决也更值得提前投入。另外终端设备的AI化不要追求“全本地推理”合理的边缘协同架构往往更务实。ESP32负责采集和执行边缘网关负责推理和决策云端负责训练和更新各司其职整体节奏才稳。最后分享一个小技巧在AI执行的关键节点加“人工确认钩子”初期可以频繁触发随着信任建立逐步减少。这样既保证了安全又不会因为过度保守而失去AI执行的价值。我在实际项目里用这个策略从每天确认几十次降到每周确认几次团队对AI执行的信任是逐步建立起来的急不得。
