如果你最近在关注硬件开发相关的 AI 工具大概率刷到过这类演示把一句“帮我画一个 STM32 最小系统板”丢给 AI几秒钟后生成一张花花绿绿的电路板图。乍看很唬人但只要你真正做过 PCB几乎一眼就能发现里面的问题封装是错的电源网络没连上或者根本就是一张“看起来像电路板的图”。在 PiBox 的设计过程中我也有过同样的尝试结果AI 画出来的板子基本不能用。但后来换了个思路让 AI 去查错反而解决了好几个实际项目中容易漏掉的问题。这篇文章就以 PiBox 的设计日志为背景聊聊为什么 AI 不适合画电路板以及把它用在“查错”上为什么更靠谱。换句话说AI 在硬件开发里的正确位置可能不是上游的内容生成者而是中下游的“审查员”和“排错引导员”。1. 为什么“让 AI 画电路板”是一个伪需求先说结论PCB 设计不是一个“生成”问题而是一个“约束满足”问题。这个判断决定了 AI 在其中的角色边界。如果你让 AI 写一首诗它只要生成一串语法正确、意象合理的文字就行哪怕意思模糊一点人也能脑补出美感。但电路板不行。PCB 上的每一根走线宽度、过孔位置、网络连接、焊盘尺寸、间距规则都是为了满足物理约束和制造规则这些规则并不是“看起来对”就可以。具体来说PCB 设计至少包含这几类约束电气规则哪些网络必须连在一起哪些网络绝对不能短路。物理规则线宽要能承受对应电流过孔大小要匹配工艺能力器件间距要满足焊接要求。制造规则最小线距、最小孔径、板厂工艺极限、拼板与工艺边。电磁兼容高速信号的回流路径、参考平面完整性、去耦电容摆放。这些约束集合起来是一个非常严密的系统。而 AI 生成文字或图片时缺乏这类强约束下的“精准落子”能力。它可以输出一版看起来结构完整的 PCB 版图但在网络关系、封装对应、制造规则上几乎必然存在错误。更麻烦的是这些错误非常隐蔽设计者如果不够仔细反而可能被“看起来很专业”的图误导。所以当有人说“AI 能画电路板”的时候真正要问的问题是这里说的“画”是指生成一张示意图还是交付一版可以送厂打样的文件如果是后者至少在现有的技术条件下AI 还远没有准备好。PCB 设计的一整套流程从原理图到网表再到 Layout 和 DRC 检查本质上是一个工程严谨性极强的流程AI 目前更适合介入的环节是在这个流程中参与检查、分析和辅助判断。2. AI 在硬件开发里真正能提供价值的环节既然不能画板那 AI 在硬件开发里到底能干什么从 PiBox 的实践来看价值集中在四个方向2.1 第一步审查类工作AI 特别擅长从一堆信息里找矛盾和不一致。比如 BOM 里位号重复、封装缺失、连接关系前后不匹配这些都是查错场景中非常典型的问题。人眼逐行核对很容易疲劳但 AI 可以基于规则做一遍地毯式扫描再配合脚本效率提升非常明显。2.2 第二步知识问答与数据处理原理图和芯片数据手册是硬件开发中最花时间的阅读材料之一。AI 可以快速回答“这个芯片的引脚定义是什么”“这颗 LDO 的 dropout 电压是多少”“I2C 上拉电阻应该选多大”这类问题。它不一定比权威手册更可靠但能帮你快速定位到手册中的关键页减少大海捞针的时间。2.3 第三步焊接和上电调试的排查引导板子焊完不上电、上电短路、某个引脚电压不对这类问题很多人第一反应是拿着万用表到处戳。AI 可以扮演一个“有经验的同事”根据你描述的现象给出结构化的排查顺序先量电源入口、再查 LDO 输出、然后查复位时序。这种方法比盲目乱试要高效得多。2.4 第四步固件与硬件配合问题很多硬件问题其实出在软件配置和硬件不匹配上比如 I2C 地址算错、ADC 参考电压选错、引脚复用配置不对。AI 在代码审查和配置检查方面的能力已经相当可用尤其是在芯片参考手册和 SDK 资料比较完善的情况下。这些方向的共同点是AI 不负责最终决策也不负责生成最终交付物它负责提高人在查找、核对和定位问题时的效率。画电路板需要的是确定性而查错需要的是“怀疑一切”的扫描能力后者反而更适合当前 AI 的模型特性。3. PiBox 项目里的查错场景一个真实硬件设计的问题集合PiBox 是一个带有主控、传感器、显示和电源管理的硬件项目。它的设计难度不算高但正因为“不算高”反而容易在细节上翻车。这里的经验对很多做硬件原型设计的开发者都有参考价值尤其是那些从软件背景转向硬件的人。在 PiBox 的迭代过程中我们实际遇到的错误大致可以分成这几类电源树设计问题某个模块的工作电压和 LDO 输出不匹配导致上电后模块不工作。封装错位原理图里用的封装与实际采购的器件引脚不匹配焊接时才发现。BOM 数据混乱出现重复位号、缺少封装信息、数量与装配图不一致。网络连接遗漏原理图里某个引脚悬空或者连到了错误的网络上。焊接工艺问题手工焊接时热敏器件旁边放了发热严重的 LDO导致虚焊。这些问题的共同点是它们不是设计者的能力问题而是在数十个器件、上百个网络的复杂度下人工核对很难做到 100% 不遗漏。AI 的价值在这里体现得非常直接——它是一个不知疲倦的第二双眼睛。在一开始我们也试过让 AI 直接输出原理图甚至“脑补”一个 PCB 布局结果都不理想。后来调整了思路让 AI 参与审查和排错而不是生成。这个转变让整个开发流程顺畅了很多。4. 电路板查错到底在查什么四级检查法许多硬件新手拿到一块板子后不知道从哪里开始查错。这里分享一套在 PiBox 项目中用到的四级检查法从原理图到焊接上电逐级推进每一级都能对应到 AI 可以发挥价值的地方。4.1 第一级原理图检查原理图是电路板的大脑也是最容易藏问题的阶段。检查重点是电源网络命名是否统一VCC_3V3 和 3V3 是不是被当成两个网络了每个 IC 的电源引脚旁是否有去耦电容电容容值和耐压是否合适复位引脚是否有上拉或下拉电阻悬空的复位脚很容易受干扰。I2C 总线的上拉电阻是否遗漏使能引脚是否设置了正确的默认电平这个阶段非常适合用 AI 进行规则审查。你只需要把原理图的网络连接关系整理成文本或者用截图配合清晰的检查清单AI 就能找出不少问题。相比于人眼逐条读网络表AI 的处理速度要快得多。4.2 第二级PCB 版图检查版图是物理层的实现。这一阶段检查的重点是线宽是否满足电流要求例如电源走线太细会导致压降和发热。地平面是否完整有没有被信号线割裂成几块去耦电容是否靠近 IC 电源引脚放得太远等于没有。高速信号线是否有完整的回流路径过孔数量是否足够电源或地回路上的过孔太少会引入较大寄生电感。这一级 AI 的直接生成能力还不够但可以配合 EDA 工具的 DRC 报告进行分析快速解释每条 DRC 错误背后的含义并给出修改优先级。4.3 第三级BOM 与装配检查BOM 是原理图到实物之间的桥梁。很多返工都源于 BOM 错误典型问题包括位号重复或缺失。封装不匹配比如原理图用 0603实际买的是 0805。器件耐压或功率不满足应用条件。BOM 数量与 PCB 上的焊盘数量不一致。这一级非常推荐用脚本配合 AI 做自动化检查。因为 BOM 是结构化数据适合用代码做格式校验再用 AI 做逻辑判断。后面会给出一个可用的检查脚本示例。4.4 第四级焊接与上电检查板子焊完不能直接上电乱戳。一个稳妥的流程是目检用放大镜或显微镜检查焊点、桥连、虚焊。电源短路测试上电前用万用表量电源和地之间的阻值排除短路。分步上电先只给电源部分上电测量各输出点电压是否正常。模块逐个启用确认电源稳定后再逐个检查传感器、显示、通信等模块。AI 在这一级的主要作用是“排错引导”。你描述现象AI 给出排查顺序。比如“板子上电后电流异常偏大”AI 会先建议断开负载测电源再逐路排查是哪一路短路。这种引导非常实用尤其适合刚接触硬件的开发者。5. 让 AI 查错落地的第一步写一份给 AI 的“查错清单”很多人让 AI 查电路板时效果不好问题往往不是 AI 能力不够而是提示词太笼统。“帮我检查一下这块板子”这种问题AI 根本不知道从哪里入手。更好的方式是先建立一份结构化的查错清单把它作为提示词的一部分提供给 AI。这样 AI 的输出不只是“这里可能有问题”的模糊判断而是对应到具体检查项目、风险等级和处理建议。下面这份清单是 PiBox 项目里常用的一份模板可以直接复制使用你是硬件电路审查助手。请按照下面的检查清单逐项审查我提供的原理图或 PCB 描述文本输出“问题描述 / 风险等级 / 修改建议”。 检查清单 1. 电源树输入电压范围是否匹配所有器件各电源轨电压是否与器件工作电压一致。 2. 去耦电容每个 IC 电源引脚附近是否有 0.1uF 去耦电容电容耐压是否满足要求。 3. 地网络是否存在单点接地、地平面分割、模拟地与数字地处理不当的问题。 4. 信号完整性高速信号是否跨越参考平面分割差分信号是否等长是否需要端接电阻。 5. 元件位号是否存在重复位号、空封装、BOM 数量与装配图不一致。 6. 引脚方向二极管、电解电容、LDO、稳压管方向是否接反。 7. 上下拉电阻I2C 总线上拉电阻是否缺失复位引脚、使能引脚是否悬空。 8. 热与工艺发热器件是否靠近敏感器件焊盘间距和最小线宽是否满足板厂工艺能力。 9. 功率与热量电源走线是否满足电流要求是否存在过孔载流不足。 10. 结构干涉板边器件是否可能被安装螺丝或外壳压到。 注意对不确定的信息输出“需要人工确认”不要武断下结论。使用这份清单时把原理图的关键信息网络列表、器件列表整理成文本或者直接贴截图AI 就能输出比较有参考价值的检查结果。当然AI 的检查不能替代 EDA 工具的 DRC 和人工评审但可以作为一个前置筛查手段把明显问题先过滤掉。6. 用脚本 AI 做一个真实的查错示例查错不能只靠“感觉”对于 BOM 和网络表这类结构化数据脚本检查往往是性价比最高的方式。这里分享几个 PiBox 项目里实际用过的检查脚本你可以根据自己的项目格式做相应调整。6.1 BOM 检查重复位号与缺失封装BOM 表可以从立创 EDA、Altium Designer 或 KiCad 中导出格式大同小异。下面这个脚本基于 CSV 格式的 BOM检查重复位号和缺少封装的问题。# 文件路径tools/check_bom.py import csv import sys from collections import defaultdict def check_bom(csv_path): refs defaultdict(list) missing_footprint [] total 0 with open(csv_path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: ref row.get(位号) or row.get(Reference) fp row.get(封装) or row.get(Footprint) value row.get(数值) or row.get(Value) if not ref: continue total 1 refs[ref].append(value) if not fp or fp.strip() in (, unknown, 待定): missing_footprint.append(ref) dup {ref: vals for ref, vals in refs.items() if len(vals) 1} print(fBOM 总器件数: {total}) print(f缺少封装的位号: {missing_footprint}) if dup: print(f重复位号: {dup}) else: print(重复位号: 无) if __name__ __main__: check_bom(sys.argv[1])运行方式python tools/check_bom.py bom.csv这个脚本的逻辑并不复杂但能快速发现人工核对容易漏掉的问题。重复位号在原理图导入 PCB 时经常导致封装错乱缺少封装则会让采购和贴片环节直接卡住。6.2 网络表检查悬空网络与单点网络网络表是原理图连接关系的结构化表达也是 PCB 布线的基础。针对网络表做脚本检查可以提前发现悬空引脚、单点网络等风险。# 文件路径tools/check_nets.py # 输入从 EDA 导出的网络表 CSV至少包含 net_name、pin_ref、pin_name、direction 四列 import csv import sys from collections import defaultdict net_pins defaultdict(list) with open(sys.argv[1], newline, encodingutf-8) as f: for row in csv.DictReader(f): net row[net_name].strip() pin row[pin_ref].strip() direction row.get(direction, ).strip() net_pins[net].append((pin, direction)) for net, pins in net_pins.items(): unique_pins set(p[0] for p in pins) if len(unique_pins) 1: print(f[WARN] 网络 {net} 只连接了 {pins[0]}疑似悬空) elif len(unique_pins) 2: print(f[INFO] 网络 {net} 只有两个端点: {list(unique_pins)}请人工确认是否为测试点或跳线)运行方式python tools/check_nets.py nets.csv如果你的项目有多路电源建议重点关注电源网络。很多上电不工作的故障本质上是某个电源引脚在网络表里根本没连上而原理图看起来是连着的这种问题肉眼很难分辨但脚本可以精准暴露。6.3 结合 AI 做结果分析脚本输出的检查结果通常是一堆原始字符串此时可以让 AI 帮忙解读。例如将脚本输出粘贴给 AI并附上问题这是我用脚本检查 BOM 得到的结果 粘贴脚本输出 请帮我分析哪些问题是必须修复的哪些是提示性的并列出修复优先级。这种方式相当于让 AI 担任“初级审查员”先把风险分级你再根据分级结果决定是否深入处理。对开发者来说减少的是机械核对的时间而不是减少最终决策的责任。7. 常见误区与排查方法在实际应用“AI 查错”的过程中很多开发者会踩到一些坑。这里整理 PiBox 项目里遇到过的问题供参考。问题现象可能原因排查方式解决方案AI 输出的检查结果太泛化没有具体到器件的建议提示词里的检查清单不够具体AI 只能用“可能存在问题”来回答补充更明确的检查项例如“检查 U1 的 VCC 引脚是否有 0.1uF 去耦电容”使用结构化查错清单让 AI 按固定格式输出脚本检查 BOM 时报编码错误CSV 文件不是 UTF-8 编码可能是 GBK检查文件编码将 CSV 转为 UTF-8或在脚本中指定编码方式网络表检查发现大量“单点网络”原理图中存在悬空引脚或你使用的 EDA 导出了包含测试点的网络表对照原理图逐个确认如果是测试点可忽略如果是悬空引脚需要重新连接AI 给出的封装参数与实际器件不符AI 训练数据中存在过时或不准确的信息交叉核对器件数据手册以官方数据手册为准AI 结果仅作为参考上电后电流异常偏大可能存在焊接桥连、电容方向接反、电源短路用万用表测量电源与地之间的阻值观察是否接近短路先目检焊点再分步断开负载定位短路点这里要特别提醒一点AI 查错输出的是“建议”不是“事实”。尤其是在封装参数、电气规格这类数据上AI 有可能给出看起来很合理但实际上错误的答案。比较好的做法是AI 负责快速筛查和风险提示人负责最终确认。凡是涉及要修改版图、更换器件的决定都必须回到数据手册和 EDA 工具里验证。8. AI 硬件查错的工程建议与风险边界如果要把 AI 真正用进硬件开发的日常流程有几个工程层面的建议值得参考。8.1 建议一把 AI 查错固定成流程节点不要只在出了问题的时候才想起 AI而是把“AI 预审”变成项目节点的一部分。例如原理图完成后导出网络表和 BOM跑一遍脚本检查再让 AI 根据查错清单输出风险报告。这个过程通常只需要十几分钟但能有效降低后期改版次数。8.2 建议二安全边界要清晰AI 在硬件开发中真正需要警惕的是“过度信任”。一些开发者拿到 AI 的答案后不经过验证就应用于电路设计结果往往很惨。更稳妥的态度是把 AI 当作一个经验丰富但偶尔会犯错的同事。它的优势是见多识广、回答速度快但也可能把数据手册里的某个参数张冠李戴。尤其是在涉及高压、大电流、电池供电等场景时必须坚持“人工复核”的原则。任何 AI 给出的电气参数、器件选型建议都要回到官方数据手册验证涉及安全的关键电路建议请有经验的硬件工程师评审。8.3 建议三善用 EDA 工具的 DRC 与仿真AI 无法替代 EDA 工具的 DRC设计规则检查和仿真功能。DRC 能检查线宽、间距、过孔等物理规则是否满足制造要求仿真能验证信号完整性和电源完整性。AI 更适合的是解释这些检查报告告诉你某个 DRC 错误意味着什么而不是替代工具去生成版图。8.4 建议四持续维护自己的查错清单每一次项目复盘后都可以把新踩的坑补充到查错清单里。比如某个项目里发现“LDO 的散热焊盘没打地孔导致温度过高”就可以在清单里增加一条“电源芯片散热焊盘是否打过孔”。随着清单越来越完善AI 查错的质量也会随之提高。9. 回到 PiBox一个更现实的 AI 硬件工作流PiBox 项目最终沉淀下来的 AI 工作流可以概括为一个循环用脚本检查结构化数据BOM、网络表先过滤掉确定性问题。用 AI 做规则审查用查错清单驱动输出风险分级报告。对 AI 输出的风险项回到数据手册和 EDA 工具中逐条验证。把项目中遇到的真实问题补充进查错清单进入下一个迭代。这个流程不追求让 AI 直接产出最终交付物而是把 AI 嵌入到“人机协作”的查错环节。从实际效果看它比“让 AI 画电路板”要靠谱得多也更符合当前 AI 能力边界。如果你也在做硬件项目建议从今天开始做一个调整下次不要再让 AI 直接画电路板而是试试把 BOM 导出来让 AI 先查一遍。你会发现它可能不是你想象中的全能设计师但却是一个非常不错的“审查搭档”。