给AI一个PCB设计工具，然后闭嘴不管，会发生什么？PCBEditor作者在10月20日把Claude Code接到自家MCP服务器上，只打了一句话，就撒手让它自己跑。
那句话是：设计一块4层ESP32-S3板，带USB-C和锂聚合物充电器。整个过程约18分钟：6次设计任务、9次编辑、25次等待任务返回，最后得到一块能在浏览器里打开、再花几分钟手工修完的板子。
它先自己写了一份规格书
Claude没有把这句话原样丢过去。它第一次调用设计工具时，带的是一份自己写的完整规格：单节锂聚合物充电器要带电源路径和负载分配，插USB时由USB供电、拔掉后切到电池；充电电流约500 mA，用电阻设定；3.3V轨用至少600 mA的低压差稳压器，从电源路径输出取电。
它还要求USB线路加ESD保护、电池电压分压到ADC引脚、使能按键加RC延时、两排排针、4层叠构带完整地平面，并主动打开了更慢的额外质量检查。作者的评价很直接：这份简报比大多数人写的都好，也比他自己写的好。
服务器先掉了五次链子
第一次任务跑了44秒，结果是“运行结束，没有板子”。接下来四次一样。进度信息暴露了原因：流程在电路里发现了问题，停在“等待你就电路问题做出选择，然后进入布线”，但这个选择从没以问题的形式送到Claude面前。这是MCP层的bug。
Claude的反应是这场实验里最有意思的部分。它用取零件信息的工具查了模块和充电器的引脚图，重写描述，把每个充电器和USB引脚都按库里的名字点明，再试一次。第六次运行时，问题终于传了过来：充电器的使能引脚接法会让芯片一直关着，问它怎么继续。
Claude用自己的话列了一串修正。服务器忽略了这段自由文本，把同一个问题又问了一遍——第二个bug。于是Claude选了“带着这些电路问题继续建”，并说明之后会用编辑修掉。任务在第113秒完成：36个零件、708条走线、134个过孔、4层。
它读了网表，抓出三个DRC放过的错
这一步它真正值回票价。Claude拉取完整板级数据，拿到每一条网络和它连接的焊盘，再对照BQ24074电源路径充电器该有的接法，找出三个设计规则检查没拦下的错误——因为它们不是铜皮问题：
- ESP32-S3模块的3V3引脚被单独成网，还经过一颗1 kΩ电阻从3.3V轨取电。Claude的原话是“它会立刻掉压”。
- 充电器的温度检测引脚被10 kΩ上拉到3V3，Claude说这“会阻断充电”。
- 充电器的输入限流引脚（ILIM）挂在了未连接网络上。
作者对着它读到的板级数据逐条核过，三个都是真的。
Claude还反驳了服务器的一条检查。问题里说EN1拉低“会让芯片关着”，Claude指出EN2高、EN1低时，BQ24074从ILIM电阻取输入限流，这正是设计想要的；把EN1拉高反而会让充电器进入挂起。这与TI数据手册里的EN1/EN2表一致。检查错了，引脚保持原样。
修正以精确到焊盘的编辑指令下发：U1.2改接3V3，模块供电脚必须直接挂在3.3V轨上，原来的独立网络删除。服务器执行并重新布线，第二轮把第一次建板时留在未连接网络上的排针脚也接好了。
它知道什么时候停
最后剩两个设计规则错误消不掉：内层走线距USB-C连接器屏蔽孔只有0.151和0.156 mm，规则要求0.25 mm。Claude试了几次编辑，一次被编辑守卫拦下，理由是“会把DRC错误从2个变成4个”；另一次返回“板子没有任何变化”。第三次之后它停下来，告诉作者：还有两个DRC错误，工具试了三次没修掉，所以没有导出任何制造文件。
这正是作者想要的行为。导出工具本来也会拒绝：只要还有用户未接受的DRC错误，它就不给制造文件。但Claude没有替作者去接受这些错误。
它的总结还列了板子实际尺寸73.8 × 54.6 mm，而它当初要的是60 × 30 mm；USB差分对耦合偏松；以及提醒插电池前先确认JST引线极性。
三个结论
分工是成立的。写简报、拿网表对照数据手册、写精确的变更请求、知道何时停手，这些是语言模型擅长的事；按引脚图接线、布线、量间距，交给服务器。
检查通过不等于板子对。三个接线错误全部通过了设计规则检查，因为DRC量的是铜皮，不是意图。第一次设计结果甚至说板子是DRC干净的，而存下来的板子有两个错误。
会拒绝导出的agent是功能，不是缺陷。作者宁愿收到“没准备好，原因如下”，也不想要一个压缩包。
热门跟贴