当 AI 控制硬件时，我们拿什么兜底？（电路硬件限位）——一次电解电容爆炸后的反思

AI 操控设备，出事了

昨天（2026年6月1日，挺有意思的一天，我们上午还在做消防演练），出了一件事，趁着还记得赶紧写下来。

起因是同事要移植一套台体控制程序，手头有我这边测试用的 DLL 库，就直接丢给 AI 去做。移植本身不算难，但坏就坏在给 AI 的权限放得太开了——不只是让它生成控制逻辑，还让它直接输出完整工程、补全默认参数，甚至用 Python 直接调用 DLL、串口接上控制台，另一头连着一台标称 380V 的电表，就这么跑起来了。

据说当时我正在会议室开会，现场是一声闷响，然后电路板方向飘出一缕青烟，那种电容炸开后特有的焦糊味。所有人心里都咯噔一下。赶紧断电检查，两颗耐压不低的电解电容直接炸壳了。回读日志，清楚记录着电压被推到了 400 大几，远超额定范围。万幸没伤到人，设备也还能修复。

---

问题出在哪

我们这边提供的 DLL 库，接口本身预留了安全上下限的参数，但默认调用时如果不显式设置限幅，是完全开放的。我自己的习惯是上电前必做软限位，先空载跑一轮，再慢慢带载。但 AI 哪里知道这些？它只是在语法和逻辑上完成了"控制电压输出"这个任务，对它来说 0 和 1000 都是合法数字，只要不报错就行。你给它开门，它就敢开到最大。

说到底，这颗电容扛不住，根本原因不在 AI，而在于我们把"自觉"当成了防护。以前人写程序，哪怕再不严谨，潜意识里也知道 380V 的设备顶多到 420V 附近就离谱了，调试时会盯着看。AI 没有这个物理世界的感觉，它不会觉得某个数字"不对劲"。这次爆炸，是一次非常直白的警告：当 AI 开始实际参与硬件控制，靠人的小心谨慎维持的那条安全线，瞬间就失效了。

---

以前觉得可有可无，现在觉得是必须的

以前和同事聊到硬件保护——自动断路器、过压过流切断这些——我总有一种"做了更好，不做也问题不大"的心态。那时候整个链路里都是人，出了岔子基本能在酿成大事之前被拦下来。

但这次彻底改变了我的想法。未来 AI 介入日常工作只会越来越深，越来越多的代码、配置、甚至实时决策会被交给模型去生成和执行。如果底层的硬件安全还停留在"靠人兜底"的阶段，下一个炸的可能就不只是电容了。

---

后续打算怎么做

事后的总结会上，我们定了两件事。

一是给每一路台体输出加上独立的硬件保护模块，类似自动断路器的设计，但要能依据所接设备的具体标准自动调整保护阈值——检测到接的是 380V 电表，就自动把过压保护点锁在 420V，硬切断，不依赖软件。

二是在 DLL 和上层控制软件之间，强制插入一层无法被 AI 绕过的限幅逻辑，不管 AI 生成了什么离谱的指令，到执行层都会被钳制在安全范围内。说白了，就是不再给"裸奔"留机会。

这种设计，放在今天看可能有些大动干戈。但如果把目光放到一两年后，当 AI 辅助甚至主导的硬件操作成为常态，它就不是可选项，而是必需品。我们能容忍人偶尔犯错，因为有培训、有规程、有人互相盯着；但对于一个能力很强、却完全不具备物理常识的 AI，能限制它的只有设计时就嵌进去的硬规则。

---

希望这次炸掉的电容能变成一个有用的教训。你可以大胆地把代码交给 AI，但安全的最终决定权，请一定握在自己和硬件保护电路手里。