薛定谔引脚与海森堡bug

Sun, 14 Jun 2026 03:29:00 +0800

0x01 薛定谔引脚

最近在尝试Agent辅助设计PCB，于是打了一板，发回来焊完按照正常的流程测连通性、电阻电容、二极管压降都没问题。正准备烧程序的时候发现开发板始终连接不上。

最初怀疑是MacOS上的STM32 Cube Programmer有问题，因为安装的时候报有一个组件还是Intel架构的，一般这种情况下二进制兼容性不会太好。遂切到Windows下进行连接，发现还是不行。

此间继续测试开发板连接性，包括上电后静态电压，发现仍然没有问题。开始怀疑下载器的问题，从ST-Link换到JLink，仍然不行。

此时怀疑是焊接或者是元件的问题，而且这也是主包第一次用自己的回流焊焊台（后面要考），虚焊啥的也不好说。好在嘉然创打一次样发5片。刚好手上备料比较多，于是二话不说又焊了一份。

结果发现还是连不上，王德发！！！

主包此时决定正儿八经地上示波器和逻辑分析仪进行分析了。不过我用的芯片是TSSOP的封装，引脚很难夹持（我逻辑分析仪的探针比较大），刚好我连接烧录其用了 pogo pin 的设计，可以直接加载那玩意的夹具上面（后面要考）。

此时看到的信号也真是好得不能再好了……但是芯片就是不理下载器。

此时已经开始疯狂压力ChatGPT和Claude了，但是他们看完所有资料之后还是不知道病情在哪。另一边我仍在反复尝试，甚至已经在嘉立创考虑换个芯片重新画板子了。

…… 直到，突然有一次，内存读到了！这不读到我就真重新画了，读到了可令人头大，因为这个事情不能复现…

真就那么一次，我还没来得及看参数，然后手机械性地点了重连，就再也连不上了，后面试了好多次也不行。考虑到这是我第二块板子，我当时已经排除了是焊接和元件的问题（元件也都换了一次），此时真的想不出什么情况了。

但是这个月打样券用完了，于是我决定还是再死马当活马医一下，逻辑分析仪接了一个小探针，左手捏着探针戳引脚，右手去上位机点连接。因为手空不出来，所以我一次只能戳一个引脚，在测SWDIO的时候，信号正常但还是连不上，此时我真的想放弃了，但还是交换了一下，去测SWCLK。本来想看看连接失败的波形的，结果，连上了？！！！但是也不是很稳定，有时候连接不成功，有时候连接成功烧录失败，很奇怪。

0x02 问题根因

于是开始定位原因。其实到上面基本确定是这个引脚有问题，但是理论上我逻辑分析仪探针之间信号是隔离的，不可能说是逻辑分析仪给连起来了。考虑到于是把目光转向一个很边缘的可能：引脚虚焊。

但是经过定位以及分析，这两个板子都是同一个SWCLK引脚虚焊，不可能吧…真的不可能吗？回头测了一下第一块板子，用力压SWCLK发现也能连上！

罪之一：虚焊

我去两块板子同一个脚虚焊？！于是我焊了第三块板子，先做了回流焊，结果发现不压还是不行，但是连接性比第二块板子明显好了一些。

为什么连接性在第三次焊接的时候增强了呢？回想起两次焊接中间还有一个小插曲，是我给焊台配了我之前淘汰了的报废电源，结果这玩意不说功率上不去，中间加热热着热着还把电源适配器直接拉爆了。

所以前两次焊接的时候，中间恒温的时间其实是不够的……进一步降低了焊点的连接性。

罪之二：盘中孔

遂冷静下来去考察原理图，发现这个焊盘有一个特点是上面有过孔。之前画板子的时候有时候在电容焊盘上打过孔，也没啥问题，为啥这次翻车了？去查了一下，答案在嘉立创盘中孔工艺说明里面。

打在焊盘上的过孔会影响回流焊时焊锡的张力，降低焊接性能。此外，过孔会增强该位置的散热，如果回流焊温度开得比较低或者时间不够的话，可能导致过孔周围焊锡过早冷却。以前手焊的时候这个问题不会很明显

debuff刚好撞一块了……

罪之三：DFM

但是在设计过程中，我将版图给AI检查了很多遍，包括ChatGPT和Claude模型，他们都没查出来。事后我将原因告诉这些模型，他们认为前面在检查的时候，没有考虑这个方向（我没写这个提示词）。

我也回顾了一下之前的对话过程，确实很多检查落在所谓的DRC实质是连接正确性上，而DFM只是混在需求里面了，没有给他们专门画一个stage也没有拉一个checklist去检查。如果AI要检查的话，他们会把图放大，不然看不出来。作为一个只是顺便一提的需求，他们的思考过程中就没有很细致的检查这个了。

这样来看，设计这块确实需要很多硬件工程师的专家知识。

0x03 成品

最后做出来的小玩意在这，Project Leithanien，是一个无源NFC播放器。

0xF1 海森堡bug

上面这个问题差不多让我断断续续找了一个礼拜，主要是探针测试的时候它没问题，而撤掉探针之后，问题就暴露了，若不是去戳芯片引脚同时还要观察上位机，否则问题很难发现，真是一个薛定谔的引脚。

而众所周知我的研究方向是做系统结构的，这样的话绕不开和OS Kernel打交道。而在这中间，也有这么一个“臭名昭著”的“薛定谔引脚”，printk。有些问题就是，你不打印的时候就有了，添加调试信息的时候却发现问题无论如何都无法复现。

此外，在Agent设计中，很多时候你让模型输出思维链，它反而会在任务的最终目的和真实因果上出现偏差，此时强约束的提示词执行效果反而会变差；但是你不输出思维链模型也无法做思考了。

这类问题算是Heisenbug，原意是在计算机编程中，一类特殊软件错误会在试图调试或研究时自行消失或改变行为。这在许多领域都是令人头疼的事情。经此一役，在设计的时候考虑DFT，即测试与可测试性设计，将探针融入到系统设计中并降低其干扰，或许能减少/规避此类问题。

0xF2 关于Agent辅助设计PCB思路的讨论

目前立创EDA生态下已有JLC-EDA-Bridge等开源项目，对外提供 MCP Server和一系列操作原语。不过经过繁杂的测试之后，发现暴露的API存在诸多问题：例如MCP Server提供的参数说明对AI而言有歧义，连线的时候，如果两线交叉，它们默认会形成交点，而在文本推理中Agent对发给MCP Server操作的元件的几何状态几乎没有感知，导致即使连接完之后还存在诸多问题。

作者还试过直接用Computer Use + Batch & Speculative 操作优化，效果比上面还好…

然而实际上，在上述推理中，电路设计是相当快速的，特别是EDA已经有了成熟的Net/Port等抽象概念，它们都能做DRC，给Agent这种自动化设计工具岂不更容易。而真正的问题在于EDA工具（可能主要还是立创EDA，AD试了试感觉还好）其API接口设计并非最优。这导致上下文被迅速填满，而端口连接/数值计算等问题在其中没有获得其应有的注意力。

而前段时间在ChinaSys'26 Spring上刚好看到 Wolvrix 这个工作，也是考虑到Verilog等RTL语言的语法对于Coding Agent而言过于复杂而且细致，而自然语言或文档去描述一个电路设计又不够精确，于是给RTL提供一个IR。

其实确实有一些选型，例如KiCad的SKiDL，还有非常近挂在arXiv上的一个研究SchGen。不过目前用起来也是有诸多问题的。还有一类是直接生成Netlist，但是也是存在和Verilog一样的问题。