当 AI 盯上示波器：一位工程师把 Claude 变成了硬件调试搭子
比起“让 AI 设计电路”，更聪明的办法是让它先学会看波形
过去一年，AI 进入软件开发的姿态几乎已经固定：你写一句自然语言提示，它替你补代码、写测试、修 Bug。很多人也顺着这个思路，把大模型往硬件开发里推——既然能写程序，为什么不能顺手画个电路？
德国工程师 Lucas Gerads 最近分享的一套实验，恰好说明了这条路为什么没有想象中那么顺。用他自己的话说，想用纯英文把一个复杂硬件设计的需求讲清楚，其实并不轻松。简单电路还行，稍微复杂一点，语言就开始变得含糊，模型也容易“脑补”。这和软件世界很不一样：代码的反馈回路天然短，跑一下就知道对不对；而硬件设计里，很多错误要等到仿真、测量甚至上板之后才会暴露。
所以他换了个思路，不再让 Claude Code“凭空造电路”，而是给它接上两样更接地气的工具：SPICE 仿真器，以及一台 LeCroy 示波器。于是，Claude 不再只是一个会写字的助手，而更像一个能看测试结果、能比对波形、能帮忙验证模型的调试搭子。这个转变看似朴素，实际非常关键。说白了，AI 在硬件领域最缺的从来不是“想象力”，而是传感器——它得先看到真实世界，才有资格谈理解真实世界。
这套流程好在哪里：把最烦、最容易出错的活交给模型
Lucas 展示的是一个刻意简化的 Demo，电路和 MCU 都不复杂，重点不是电路本身，而是工作流：先做 SPICE 仿真，再从示波器采真实波形，最后让 Claude 去做比对和验证。对于干过硬件的人来说，这种流程里的痛点几乎人人都懂：时间轴要归一化、曲线要对齐、测量数据格式五花八门，最后还得人工判断“看起来像不像”。很多时候，工程师嘴上说自己在做严谨验证，手上其实是在“目测差不多”。
别小看这个“差不多”。很多硬件问题就是藏在这些差一点点的细节里。比如 RC 滤波器的相位偏移、上升沿衰减、采样时钟的细微漂移，肉眼是能看出来个大概，但要真正量化、复现、留档，既费时间又容易出纰漏。Claude 在这里的价值，不是替代工程判断，而是替代那一大堆机械但烦人的数据整理活。让模型去做波形对齐、归一化、结果比较，再给出一份结构化结论，这比让它“设计一个厉害的模拟前端”现实多了。
这也是我觉得这件事有意思的地方：它没有把 AI 塑造成一个无所不能的天才工程师，而是把它摆在一个更适合的位置上——做一个反应快、执行力强、不会嫌脏活累活麻烦的实验助手。过去科技圈谈 AI for hardware，很多叙事都太飘，动不动就是“自动生成芯片”“自然语言造板卡”。Lucas 这个案例反而提醒大家，真正能立刻产生价值的，往往不是最宏大的愿景，而是最具体的流程改造。
硬件开发为什么比写代码更需要“即时反馈”
如果把这件事放到更大的行业背景里看，它踩中的其实是当前 AI 工程化的一个核心趋势：模型只有嵌入工具链，才能从“会说”变成“会做”。
软件领域已经给出答案了。GitHub Copilot、Cursor、Claude Code 这些工具之所以好用，不只是因为模型会补全代码，而是因为它们能读项目上下文、调用终端、运行测试、看到报错、再继续修改。也就是说，真正提升生产力的不是一次性生成，而是闭环反馈。硬件开发长期缺的正是这个闭环。电路图、仿真器、逻辑分析仪、示波器、烧录器、Makefile、引脚映射，这些东西长期分散在不同软件和设备里，工程师自己都得在十几个窗口之间来回切，更别说让模型理解。
Lucas 提供的几条经验，看似是小技巧，背后其实都是“如何让 AI 不犯低级错误”的工程原则。比如，别让 Claude 猜物理连接关系；别把过期测量数据留在上下文里；原始数据不要一股脑塞进聊天窗口，而是存到文件里让模型间接读取；MCU 的 pinout 和 pinmux 要明确给出；编译、烧录、擦除、连通性检查这些动作，最好通过 Makefile 暴露标准接口，而不是让模型临时拼命令。
这些建议特别像今天 AI 代理在各个行业落地时反复出现的一句老话：要把不确定性交给人，把确定性的流程交给机器。AI 可以很聪明，但它一旦对“线到底接哪了”“这个测量是不是刚刚采的”“这个引脚现在是不是复用了 SPI”产生幻想，实验台就会瞬间从实验室变成事故现场。硬件不像文档写错一段还能删，它有可能直接烧板子。
这不只是一个 Demo，它暗示了实验室工作流会被重写
这类尝试真正让人兴奋的地方，在于它不是孤立功能，而是有机会重写整个实验室工作流。想象一下未来的硬件台架：模型可以调用示波器抓波形、控制仿真参数、自动比对实测与仿真偏差、生成实验日志、甚至根据结果修改嵌入式代码后重新烧录。对资深工程师来说，这意味着从重复劳动中解放出来，把脑力留给架构判断和边界条件；对初级工程师来说，这意味着可以更快建立“仿真—实测—验证”的工程习惯，而不是靠师傅一句“你看这个波形大概就对了”。
这也解释了为什么 MCP（Model Context Protocol）最近越来越受关注。它本质上是在给大模型接外设、接工具、接数据源。Lucas 开源的两个仓库，一个面向 LeCroy 示波器，一个包装了 spicelib，本质上都是在做“实验室设备的 API 化”。今天接的是示波器和 SPICE，明天完全可能接频谱仪、可编程电源、热像仪、JTAG 调试器，甚至生产线上的ATE测试设备。到那时，AI 就不再只是坐在 IDE 里写字，而是开始进入真实仪器密布的工业环境。
当然，这里面也有争议。最直接的问题是：当模型越来越深地介入测试与验证，工程师会不会对它的判断产生过度依赖？尤其是当 Claude 给出一份看起来头头是道的波形分析报告时，多少人还会回头认真读原始数据、确认量测条件、检查示波器探头补偿是不是做对了？硬件行业向来对“黑箱”有天然警惕，因为一次误判的代价可能是几周返工，甚至一整批板子的报废。AI 能帮忙，但它还远没到可以独自签字放行的程度。
从“代码助手”到“实验助手”，AI 的下一站可能在台架边
如果非要做个判断，我会说，Lucas 这个 Demo 的价值，远大于它表面上的简单。它没有展示多复杂的电路，也没有讲什么颠覆性的理论，但它抓住了一个现实：AI 最容易落地的地方，不一定是创造，而是验证；不一定是从零到一设计，而是把工程里那些重复、琐碎、却又极其重要的环节串成闭环。
这让我想起 EDA 行业过去几十年的演进。无论是 SPICE、PCB 自动布线，还是后来的形式验证、时序分析，真正改变行业的从来不是一句“计算机会替代工程师”，而是每次把某个高频、痛苦、容易出错的环节自动化一点点。今天的大模型，也许正站在类似的位置上。它不会一夜之间变成模拟电路大师，但它很可能先成为一个不会抱怨、随叫随到的验证员。
更有意思的是，这条路比“AI 自动设计芯片”更有现实感。后者听起来性感，前者听起来像在做杂活；可科技史经常就是这样，真正留下来的往往不是最性感的口号，而是那些把工程流程磨平的工具。示波器旁边多一个会读波形、会查引脚表、会跑 Makefile 的 AI，同样可能是一个时代的开端。
至于它会不会成为硬件工程师的标配，我倾向于乐观。前提是工具设计必须足够克制：权限清晰、数据新鲜、接口标准化、每一步都可追溯。如果做不到这些，AI 只会成为实验室里另一个“看起来很懂，实际上很危险”的家伙。可一旦做到，它或许真能让硬件开发从“凭经验盯波形”迈向“让机器协助做证据链”的下一阶段。
延伸来看，这种方法对嵌入式开发、传感器标定、电源完整性分析，甚至车规和工业控制测试都有借鉴意义。因为它回答的不是“AI 能不能设计硬件”这种大而空的问题，而是一个更务实的问题：我们能不能先让 AI 成为一个合格的实验室同事？从眼下看，答案已经越来越接近“可以”。