AI辅助硬件开发的实战教训

事情是这样的。

最近一直忙着用AI做以前项目的重构，感兴趣可以看看之前几篇文章，A330飞机的滑梯线缆测试仪这个项目，其实2019年就有个老版本——一个旋钮开关式的硬件测试盒，手动转开关逐根测线。七年过去了，我想用ESP32做个自动化的版本。逻辑简单得不能再简单。

说起来，v1.5的代码框架还是从另一个项目（inductor_meter，一个电感接近开关测试仪）迁移过来的。OLED显示、电池管理、卡尔曼滤波这些现成的代码框架直接搬过来用，但测量核心完全不同——一个是测电感变化，一个是测GPIO通断。我当时觉得框架都一样，换掉测量逻辑就行，应该挺简单的。

我寻思了一下，这种活交给AI干正合适，就让它帮我写固件。它写得也确实快，第一版代码结构清晰逻辑通顺。我心想这不就完了吗。

结果从v1.6改到v1.9.3，改了8个版本，折腾了两天。

每次我跟AI说「改一下这个」，它就改。改完我拿板子一测，不对。再改。再测。又不对。最后发现问题根本不在AI身上。是我自己没把需求想清楚，一直在变。

· · ·

测试仪的原理很直白，6根线接到连接器上，GPIO读电平。通了就是0，断了就是1。全断开等于PASS，有导通等于FAIL。

AI写的v1.6跑起来逻辑是对的，PASS和FAIL显示正常。我心想这不就成了吗。

然后我手贱，把线拔了。

没插线，测试仪显示PASS。

？？？

我当时的反应是，这玩意连有没有线都分不清，测个锤子。

原因很简单：没插线的时候GPIO全是浮空状态，读出来的值是随机的。随机值碰巧全是1，测试仪就报PASS，但其实根本没测到东西。

我跟AI说：「没插线的时候应该报No Sig。」

AI说好的，加了。怎么加的呢，它去数短路数量，超过3个就认为没插线。

逻辑上好像说得通，线没插的时候6根线之间全断开，短路数应该是0。但问题是，没插线的时候短路数就是0，0不满足「大于3」这个条件。

所以没插线它照样不报No Sig，直接跳到测试环节，随机读出一堆1告诉你PASS。

我告诉AI「没插线应该报No Sig」，AI理解成了「短路数太多的时候报No Sig」。但我没说清楚怎么判断没插线，它就自己瞎琢磨了一个方案。

这是第一个坑。我的需求描述有歧义。AI不会读心术，你不说清楚「怎么判断」，它就按自己的理解来。

· · ·

数短路数行不通，那就换个思路。线缆里有一对K-H引脚之间接了二极管，插线后能测到0.6V左右的正向压降。用这个来判断「线插了没」。

我跟AI说，K和H之间有个二极管，驱动K输出低电平读H就行。

AI写了，我烧进去，板子一测——No Sig一直显示，线明明插着。

我掏出万用表量了一下。

K到H方向，1.35V。反向截止。

H到K方向，0.579V。正向导通。

我把二极管方向说反了。

跟AI说改过来，驱动H输出低电平读K。它改了，好了。

这个坑更蠢。我知道二极管有方向，但我没量就告诉了AI一个错误的方向。AI不会质疑你给的参数，你说K→H正向导通，它就老老实实按这个写。

所以硬件参数别凭印象说。万用表量一遍再告诉AI。你错了，它就错。

· · ·

二极管方向改对了，测试逻辑也跑通了。但发现一个新的问题，JD=0，GJ=0，线没插的时候这两项测试显示导通。

一开始我以为是线缆的问题，换了好几根线，结果一样。

后来仔细看了代码，发现测试结束后所有引脚被设成了INPUT模式。

INPUT不带上拉。ESP32的内部上拉电阻大概45kΩ，不算强。引脚悬空的时候电平完全取决于环境噪声，可能是高也可能是低。

所以每次测试之前得把所有引脚先设成INPUT_PULLUP，确保空闲时读到的是确定的HIGH。

改了一行代码，问题消失了。

这个坑是ESP32的基础知识，但我一开始没告诉AI需要这样做。AI不知道引脚会被悬空，它按我给的逻辑走，用INPUT模式在逻辑上是对的，只是不适合这个硬件环境。

你想想看，软件工程师和硬件工程师脑子里装的东西完全不一样。AI默认是软件思维，你不说「引脚要上拉」，它根本不会想到这茬。

· · ·

浮空引脚的问题修完之后，我重新审视了一下整个测试逻辑。之前v1.6的方案太简单了，就一轮，Blu拉LOW读其他5根线。但实际上这个测试仪要检测的东西比这复杂得多。

首先得加个D-E测试，检测压力开关，正常状态下应该是断开的。然后要加G-J测试做交叉验证。还得加短路检测，看看有没有不该通的线对通了。

这些需求不是AI自己冒出来的，是我一点点补充的。每补充一个，AI就改一次。改到最后，测试逻辑从一轮变成了三轮交叉检测。

第一轮Blu拉LOW测主测试，第二轮D拉LOW测D-E，第三轮G拉LOW测G-J。每轮之间还得把所有引脚恢复成INPUT_PULLUP避免浮空。

代码量翻了一倍多，一个简单的测试盒从120行改到600行，但这个过程其实很自然。就像你做着做着发现，哦原来还有这个需求，哦原来那个也要测。

说白了，需求是长出来的，不是一次想完的。但长出来的过程如果只有我自己知道，AI就跟不上。

· · ·

测试仪终于稳定了，PASS和FAIL显示正常。我松了口气，觉得可以收工了。

换了全新A330 飞机的另外一种版本的线缆。

我顺手拿万用表量了一下。H→K，30MΩ。K→H，0.4MΩ。双向都能导通，但数值差了两个数量级。跟之前测的二极管型完全不是一回事——之前那个是单向导通0.579V，反向截止1.351V。

这就是个电阻，不是二极管。新飞机的线缆完全不通。

之前写的检测逻辑只测了一个方向。电阻型线缆在那个方向上也能导通，但GPIO的驱动能力有限，45kΩ上拉加400kΩ电阻，读出来的电平处于临界状态，有时候判HIGH有时候判LOW。

No Sig又开始抽风。

解决方案是Round 0做双向检测。先驱动H读K，再驱动K读H，任一方向判LOW就算有缆。这样二极管型和电阻型线缆都能兼容。

改完之后两种线缆都能正确识别了。

但问题还是那个，我从头到尾没提过还有第二种线缆。AI不会问你「还有没有别的线缆」，它不知道这个问题存在。

· · ·

现在v1.9.3的代码大概长这样。

测试分三轮走。Round 0做K-H双向检测判断有没有缆，Round 1到3做交叉检测看各线对的通断。每轮测试前所有引脚先恢复INPUT_PULLUP，避免浮空干扰。LED逻辑也改了，全是1说明全断开是PASS，有0说明有导通是FAIL。

整个流程大概200毫秒一轮，OLED实时显示每对线的通断状态，底部还有电池电压和充电状态。串口同时输出调试信息。

回头看这个版本的每一行逻辑都是对的。双向检测、上拉初始化、三轮交叉——如果一开始就给了完整需求，AI大概率一次就能写对。

但从v1.6到v1.9.3，8个版本，折腾了两天。差在哪？

· · ·

回过头看，每次「AI写错了」的背后，都是我没把需求说清楚。

我以为AI该知道「没插线应该报No Sig」，但我没说怎么判断没插线。我以为「K-H有二极管」就够了，结果方向还说反了。「引脚初始化」我觉得不用多说，AI老老实实用了INPUT，浮空引脚就炸了。「测试逻辑很简单」——嗯，两种线缆我一种都没提。

每一次我以为「这还用说吗」的地方，都是AI踩坑的地方。

AI不会主动问你「这个引脚要不要上拉」「二极管方向是什么」「还有没有别的线缆」。它不知道这些问题存在。你给它什么约束，它就在什么约束里找最优解。约束不完整，出来的代码就有漏洞。参数给错了，结果就是错的。

我一直觉得AI写代码的瓶颈在于「AI够不够聪明」。折腾完这8个版本才发现，瓶颈在我自己。

· · ·

教训挺朴素的。硬件参数别凭印象说，万用表量一遍再告诉AI。二极管方向、电阻值、引脚电平，这些数据AI没法替你测。你错了它就错，而且它错得理直气壮，因为它完全按照你的描述来的。

你觉得「这还用说吗」的地方，恰恰是AI最容易出错的地方。「没插线报No Sig」这句话里，「怎么判断没插线」就是那个你觉得不用说但其实必须说的东西。ESP32引脚浮空行为、上拉电阻阻值、GPIO驱动能力限制，这些对AI来说都不是默认知识。

还有就是，别以为只有一种情况。线缆有多种型号，K-H之间可能是二极管也可能是电阻。你不说，AI根本不知道要问。

不是AI不行

是需求提不清楚，一直在变

AI写出来的代码

就是你脑子里想的东西的精确投影，脑子里模糊，代码就模糊

下次用AI写代码之前，硬件先确认量一遍，x把边界条件列出来

需求清楚了，AI一次就能写对

需求不清楚，改到天亮也白搭

原文首发 | AI辅助硬件开发的真实踩坑经历