当所有软件都在开放CLI给AI,嵌入式的机会在哪?

前阵子，看到好多个软件开源了CLI。

当时没太在意，觉得就是个开发者工具嘛。但后来发现飞书开源的CLI的星涨得很快。

越想越不对劲，因为顺手翻了一下，发现在飞书之前，很多工具都开源了CLI，比如Github等等。

几乎所有主流平台，都在做同一件事。

把自己的能力，通过命令行暴露出来。

你可能会觉得，这不就是给开发者多一个工具嘛，有啥大不了的。

但如果你把时间线拉长一点看，这件事其实挺有意思的。

就在两三年前，CLI还只是程序员的小众偏好，普通人根本碰不到这东西。但现在，几乎所有人都在做。

为啥呢？

因为AI。

飞书CLI开源的时候，官方说了一句话，原生支持Claude Code、Codex、Cursor、Trae这些AI编程工具，AI Agent安装后可以直接操作飞书，读消息、查日历、写文档、建表格、发邮件。

2500多个API，19个AI Skill，11个业务域，全部通过命令行暴露给AI。

你想想看，这事有多大。

因为这些公司开放CLI，表面上是给开发者方便，实际上是在说一句话，我们接受AI作为用户。

你不开CLI，AI就用不了你的产品。

回头看，每一次计算范式的转移，都伴随着一个类似的信号。早期互联网时代，企业做网站，是在说，我们接受浏览器作为入口。移动互联网时代，企业做App，是在说，我们接受手机作为入口。

现在，开放CLI，是在说，我们接受AI agent作为入口。

三层递进。

从人直接操作，到人通过手机操作，到AI代替人操作。每一层都比上一层多了一个中间人，但每一层都让效率跳了一个量级。

说到这里，我就开始想一个事了。

嵌入式行业呢？

软件世界在疯狂开放CLI，给AI铺路，嵌入式行业是否也有自己的CLI？

为啥我会这样想？自然是从嵌入式研发的痛点出发，现在唯一的卡点，就是硬件调试闭环了。

昨天我用串口作为数据反馈，让AI从零自己写代码，自己修复BUG，自己调试，直到调通NBIot到Onenet云数据交互。

全程花了大概42分钟，我拿到手以后直接就跑通了，真的把我惊到了。

这大概是工程师一周的工作量。

我之前看到网上有些评论说，AI写的程序，你敢用在产品上？出现BUG找起来比写代码时间还长。。

作为工程师，我倒希望是这样。。。但现实比咱想得还要残酷。。

下面代码全是AI写的，我发誓，我没写过一行代码，AI嵌入式先锋队的群友可以给我作证，哈哈。

包括工程搭建，文件架构创建，新建的。c/.h文件，编译，下载等全是AI自主完成，我就守在硬件旁边，负责上下电和验证功能。

我直接说答案吧，这代码规范和质量吊打大多数工程师。。

以前我和很多人一样，用错误的方法，得到不理想的答案，从而低估了现在AI的能力。

其实现在AI已经进入Harness Engineering阶段了，也就是如何给AI配置恰到好处的环境，工具，约束，让它更好地完成任务。

我上篇文章聊了AI辅助MCU开发，搭工程、写代码、编译下载，跑通了挺多环节。但有一个环节，AI始终伸不进去手。

硬件调试。

你板子上的硬件没反应，AI能帮你查代码，但它没法拿万用表去量一下那个引脚有没有电压。你串口收到的数据是乱码，AI能帮你分析波特率对不对，但它没法拿逻辑分析仪去抓一下波形看时序。你ADC读数不对，AI能帮你检查配置寄存器，但它没法拿示波器去看一下输入信号长什么样。

这些东西，都需要人拿着探头去夹，眼睛盯着屏幕看。

这是目前AI辅助嵌入式开发里，最大的一个死角。

然后我就想到一个问题。

万用表、示波器、逻辑分析仪，这些测量设备，有没有类似于CLI的东西？有没有标准化的接口，能让外部程序读取测量数据？

我花了一些时间去查，发现这块其实比我预想的走得远。

SCPI，Standard Commands for Programmable Instruments，可编程仪器标准命令。这玩意已经存在几十年了，大多数正经的示波器、万用表、逻辑分析仪都支持。Rigol、Keysight、Tektronix这些牌子，基本都带USB口或者网口，能用SCPI命令去控制。

还有一个叫VISA的，Virtual Instrument Software Architecture，虚拟仪器软件架构。Python有PyVISA库，几行代码就能跟仪器通信，读取测量数据。

逻辑分析仪有个开源项目叫Sigrok，自带CLI工具sigrok-cli，可以直接从命令行抓取和解码信号。支持100多种协议解码器，SPI、I2C、UART、CAN都有。

讲真，看到这些的时候我是有点兴奋的。

因为基础设施是现成的。示波器能接电脑，万用表能接电脑，逻辑分析仪能接电脑，而且都有标准化的通信协议。

AI不需要长出手来拿探头。

它只需要能读懂仪器吐出来的数据。

但兴奋完之后我又冷静下来想了想，现在差的是什么。

差的是两层东西。

第一层，这些SCPI命令和VISA库，是给人写自动化脚本用的，不是给AI用的。

你让一个嵌入式工程师写Python脚本来控制示波器，他觉得挺方便。

但你让AI直接去拼SCPI命令字符串，就有点勉强了。

AI需要一个更抽象的接口，比如帮我测一下PA5脚的PWM频率和占空比，而不是自己去写什么*IDN??

第二层，测试环境本身还是需要人来搭。探头往哪夹，触发条件设什么，量程选多少，这些物理操作AI干不了。

但如果你把探头夹好、环境配好，剩下的读取数据和分析判断，AI估计完全能做。

所以这件事的分工其实挺清晰的。

人负责物理世界的搭建和连接。

AI负责数字世界的读取和分析。

中间的桥梁，是仪器本身的标准接口。

回到开头那个CLI的话题。

飞书开放CLI，是在给AI打开办公世界的门。GitHub开放gh命令，是在给AI打开代码世界的门。那SCPI和VISA这些仪器标准，是不是就是给AI打开物理世界的门？

我一直觉得一个事。

AI的能力边界，不是由AI自己决定的。

是由它能接触到的接口决定的。

它能接触CLI，就能操作软件。它能接触API，就能调用服务。它能接触SCPI，就能读取物理世界的测量数据。

每一次新的接口被接通，AI的能力就向外扩展一圈。

而仪器自动化这个接口，基础设施已经在了，只是还差一个AI友好的封装层。谁来做这个封装层，我不知道。可能是一个开源项目，可能是一个小团队，也可能就是某个嵌入式工程师周末闲着没事搞出来的。

但我觉得这个方向，值得被看见。

如果你是做嵌入式的，或者做仪器自动化的，可以去研究下，如果能实现，硬件调试闭环可能将彻底被打通。