从“会写代码”到“能碰硬件”：GaryCLI + GaryProbe 在工业场景中的开发作用与前景
从“会写代码”到“能碰硬件”：GaryCLI + GaryProbe 在工业场景中的开发作用与前景
工业设备开发正在进入一个很有意思的阶段：AI 已经非常会写代码，但工业现场真正缺的，往往不是“再生成一份代码”，而是有人能把需求、工程、编译、烧录、调试、信号验证和现场问题真正串起来。
这正是 GaryCLI 和 GaryProbe 组合最值得期待的地方。
GaryCLI 更像“软件侧的嵌入式工程 Agent”，负责理解需求、读取和修改工程、调用工具链、编译、烧录、读取日志并根据错误继续修复；GaryProbe 则更像“现实世界接口”，负责把板卡、GPIO、串口、总线、信号甚至后续更多测量能力接进 Agent。
如果把两者放到一起，它们的目标就不只是“AI 帮工程师写固件”，而是进一步变成：AI 可以对真实工业设备执行、观察、判断、再修复。
一、工业开发最麻烦的，从来不是那几百行代码
工业项目和普通 Demo 最大的不同，是链路长、环境杂、设备多，而且大量问题发生在“代码以外”。
比如一个现场控制器通讯异常，问题可能不是协议逻辑写错，而是波特率、终端电阻、供电波动、设备地址、线序、时序、驱动版本甚至某个寄存器配置不一致；一个传感器数据漂移，也可能不是算法问题，而是 ADC、参考电压、采样周期、接地或者硬件噪声。
传统开发里，工程师要在 IDE、烧录器、串口助手、示波器、逻辑分析仪、上位机和文档之间反复切换。AI 如果只停留在“给你一段建议”，其实只解决了链路里很小的一部分。
GaryCLI 的作用，是先把软件执行链路压缩掉：工程读取、代码修改、交叉编译、固件部署、串口反馈、错误恢复，这些可以尽量自动完成。工程师不必每轮都复制日志、再复制代码、再手动烧录。
而 GaryProbe 的意义，是进一步解决“AI 看不到现实”的问题。它可以逐步成为 GaryCLI 和真实工业设备之间的统一硬件节点，让 Agent 不只知道源码写了什么，还能获得设备实际发生了什么的证据。
二、GaryCLI 在工业研发中的价值：把大量重复工程动作自动化
工业研发里有一类工作非常消耗时间，却不需要每次都靠高级工程师手工完成。
例如修改一组 GPIO、调整 Modbus 参数、增加一个传感器驱动、替换 UART 引脚、重新编译、重新烧录、检查串口输出、定位常见构建错误、比较两版固件差异、复现一个已知故障。
这些任务真正昂贵的地方不是难，而是重复。
GaryCLI 如果把这些动作稳定工具化，就可以让工程师把注意力集中在系统架构、控制策略、安全边界和复杂故障上。对企业来说，这类效率提升不是“写代码快了 20%”，而是让一个工程师一天能少做很多机械操作。
更重要的是，工业项目通常生命周期很长。同一个设备可能维护五年、八年甚至更久。新人接手时最痛苦的往往是：为什么这里这么配？当年哪版 SDK 能编过？某个现场 Bug 怎么修过？
如果 GaryCLI 能把真实执行结果、失败日志、修复方法和硬件验证结果持续沉淀到知识库，那么它会逐渐形成“团队工程记忆”。这比单次问答更有价值。
三、GaryProbe 的关键作用：让 AI 获得工业现场的“眼睛和手”
如果说 GaryCLI 解决的是 Agent 的软件执行能力，那么 GaryProbe 最重要的价值，就是把 Agent 的边界推到现实设备。
在工业场景里，GaryProbe 可以逐步承担几类作用。
第一类是设备连接与状态采集。比如串口、GPIO、I2C、SPI、CAN、RS485 等常见接口，都可以成为 Agent 获取设备状态的入口。
第二类是自动验证。AI 修改完固件以后，不应该只看到“编译成功”，而应该继续判断目标设备是否真的产生了预期结果。例如某路 GPIO 是否翻转、某个 PWM 是否存在、串口是否出现规定帧、Modbus 是否收到正确响应。
第三类是远程执行。未来企业可以把 GaryProbe 留在实验室、产线或者设备现场，工程师不一定非要坐在板子旁边。GaryCLI 可以通过网络访问 GaryProbe，对指定板卡进行调试、烧录和基础验证。
第四类是标准化。工业公司最怕“每个工程师电脑上的工具都不一样”。如果 GaryProbe 能把一部分硬件接口、调试流程和验证动作统一起来，那么实验室环境就更容易被 Agent 理解和复用。
这也是 GaryProbe 相比单纯做一个“烧录器”的想象空间所在：它更适合被定义成AI 面向现实硬件的执行与验证节点。
四、几个非常现实的工业应用场景
GaryCLI + GaryProbe 的组合，最容易先从下面几类工业开发场景产生价值。
首先是工业控制器和网关开发。STM32、ESP32、CH32、NXP、TI 等 MCU 在大量控制器、采集器和通讯网关里使用。开发阶段经常涉及 UART、RS485、CAN、以太网、传感器和协议栈。GaryCLI 可以处理软件工程，GaryProbe 则可以帮助获取真实通信和设备状态。
其次是产线测试与返修。很多电子产品出厂前都需要烧录、读取版本、检测接口、跑基础功能。传统工装通常是固定脚本，一旦产品版本改变就要重新维护。未来 Agent 可以根据设备型号、测试结果和异常日志动态选择测试路径。
第三是实验室自动化。工程师经常需要连续验证十几个固件版本，如果每一版都人工编译、烧录、接串口、记录结果，很浪费时间。GaryCLI 可以自动执行版本迭代，GaryProbe 负责连接真实设备，把结果回传。
第四是售后和远程诊断。工业设备部署以后，很多问题很难在办公室复现。如果现场有一个标准化硬件节点，工程师就有机会远程读取状态、升级测试固件、执行诊断动作，再把结果交给 Agent 分析。
第五是机器人和智能硬件。机器人系统往往同时存在 Linux 主机、MCU、电机驱动、传感器、CAN 总线和大量执行器。单纯的 Coding Agent 只能看到代码，而 GaryCLI + GaryProbe 这种“软件 Agent + 真实硬件节点”的组合，会更接近机器人开发真正需要的形态。
五、真正的前景，不只是“提高程序员效率”
我认为 GaryCLI 和 GaryProbe 更大的前景，是让工业研发逐步出现一种新的基础设施：AI 可以调用真实设备，就像今天 AI 可以调用文件、终端和浏览器一样。
今天的软件 Agent 已经可以读取仓库、运行命令、修改代码。下一阶段，AI 会越来越多地获得真实世界工具：调试器、传感器、测试仪器、机器人、设备接口。
当这一层真正成熟以后，嵌入式开发流程会发生变化。
工程师仍然负责需求、系统架构、安全策略和最终验收，但大量重复执行可以交给 Agent。AI 不再只回答“应该怎么改”，而是自己修改、自己编译、自己烧录、自己观察结果，再根据结果继续调整。
工业场景尤其适合这种模式，因为工业研发有大量重复任务、固定工具链和明确验收标准。只要工具层做得足够稳定，AI 的价值就会比单纯代码补全高很多。
六、GaryCLI + GaryProbe 最值得坚持的方向
这套组合未来最重要的不是去和大模型比“谁更聪明”，而是持续把现实工业世界接进来。
GaryCLI 应该继续做强工程执行、芯片工具链、知识库和失败恢复；GaryProbe 则逐步增加标准化硬件接口、信号验证、协议测试和远程设备能力。
当软件 Agent 和硬件节点之间形成稳定协议以后，GaryCLI 的价值就会越来越独立于底层模型。今天可以使用一种模型，明天换成更强模型，但真实工程工具、设备网络、知识数据和工业验证经验仍然属于自己的系统能力。
这也是我最看好 GaryCLI + GaryProbe 的地方：它们不是在争“下一代 IDE 的聊天框”，而是在尝试做AI 进入真实工业硬件世界的一层基础设施。
对工业研发来说，未来最有价值的 AI，可能不是最会解释代码的 AI，而是那个真正能把板子调通、设备跑起来、问题复现出来，并且留下可追溯工程证据的 AI。
GaryCLI 负责“大脑和工程执行”，GaryProbe 负责“连接现实世界”。
这两者如果真正形成稳定闭环，工业开发、机器人、智能硬件、远程实验室和自动化测试，都有很大的延展空间。