如果你最近也在纠结“能不能让AI直接帮我画一块电路板”并且想搞清楚AI在硬件设计里到底能做什么、不能做什么那这篇文章应该能给你一个比较完整的答案。这篇是 PiBox 设计日志的第 02 篇。PiBox 是我手头正在做的一个小型开源嵌入式盒子项目用来跑一些传感器采集和边缘计算实验。上一回我定下了整体功能框图这一回的核心任务是把“板子画完之后怎么确保它是对的”这个环节梳理清楚。我的结论先说在前面用AI去生成完整的、能直接投产的原理图和PCB布线现阶段非常不靠谱但把AI放到“电路板查错”这个环节里作为一个辅助分析工具反而是现在性价比很高的用法。接下来我会结合 PiBox 的实际排查流程把原理图检查、DRC规则检查、网表比对、BOM核对这些环节完整拆解一遍并给出可复用的脚本和检查清单。1. 背景与核心概念AI画电路板和AI查电路板到底是两回事1.1 为什么“AI画电路板”会让人心动最近AI工具渗透得确实很猛AI编程、AI建站、AI做视频、AI画图几乎每个领域都在被重新刷一遍。于是很多人会自然想到既然AI能写代码、能写文章那是不是也能直接生成一块电路板输入需求描述AI返回原理图、PCB文件甚至直接提交打样听起来确实很诱人。这种想法并不奇怪。硬件设计里确实有大量重复劳动比如选型、算参数、连引脚、排布局、走线、调丝印每一件都耗时。再加上PCB设计软件本身学习成本不低新手很容易产生“让AI替我干”的冲动。但这里有一个根本性误区写代码和画电路板虽然都叫“设计”但它们的验证闭环完全不同。代码写错了编译器会报错跑测试用例能发现问题电路画错了很多时候要等到板子打样回来焊完元件、上电之后才暴露甚至会因为一个引脚连接错误直接把芯片烧掉。硬件设计的错误成本比软件高一个数量级这意味着AI的自由发挥空间必须被严格压缩。1.2 AI在PCB设计里的真实能力边界现阶段AI在电路设计里能做的事情大致可以分成三类。第一类是对话式方案咨询比如你问“MCU选型要考虑什么”“LDO前面要不要加TVS管”AI可以给出有条理的经验性回答。这类内容是LLM的强项因为它们本质上是语言组织和对已有知识的重新排列。第二类是辅助生成电路描述比如让AI生成一个传感器的接口电路说明、一段Arduino初始化代码、一张引脚连接表。这些东西做出来看起来像模像样但依然停留在“文本描述”层面距离能生产的原理图还缺少一整套约束信息。第三类是直接生成原理图或PCB文件比如某些云平台提供的AI辅助布线、自动扇出功能。这类功能确实存在也有一定实用性但它们解决的是“在设计师设定好约束之后把活干完”的问题而不是从零开始替你完成设计。换句话说AI在电路设计里的真实定位是“副驾驶”不是“驾驶员”。一个合格的PCB设计流程核心是围绕网表、封装、规则、约束来展开的AI当前的推理能力还无法稳定处理这几类信息的强一致性问题。让AI自由画出的电路很容易出现“看起来合理、实际不可生产”的情况。1.3 查错环节为什么更适合引入AI辅助既然AI画板不靠谱那“查错”为什么更靠谱关键在于查错是一个有明确输入、明确规则、明确输出的过程。查错的输入是原理图文件、PCB文件、网表、BOM规则是电气连接规则、间距规则、线宽规则、封装规范输出是一份错误清单。这个过程不需要AI“创造”只需要它“判断”。而判断恰好是现在AI工具相对能做好的事情尤其是当你把DRC/ERC报告丢给AI去归纳、分类、解释的时候表现会超出预期。我自己在PiBox里的实际体验是AI直接画板我要花大量时间逐项复查但AI辅助解读检查报告能快速帮我定位哪些错误必须修、哪些可能是规则设置过严导致的误报还可以根据错误描述给出修复建议。这才是目前最顺手的用法。2. 电路板查错到底查什么从原理图到PCB的完整检查链条很多人以为查错就是“用眼睛看一遍原理图”其实正规的检查链条比这长得多。以PiBox为例我在投板之前至少要过四道检查电气规则检查、设计规则检查、网表一致性检查、BOM与封装核对。2.1 电气规则检查ERCERC查的是原理图层面的逻辑问题。比如引脚有没有悬空、电源和地有没有短接、同一个网络名有没有被错误复用、芯片的使能脚是不是没接、输出引脚之间有没有直接打架。这类错误如果在原理图阶段不解决后面布PCB时会全部带进去最终烧板。常见的ERC错误类型包括未连接引脚、单端网络、输入引脚驱动冲突、电源短路、重复位号等。在KiCad、Altium Designer、立创EDA里都会在每次原理图保存或编译时自动跑一遍ERC但很多人会忽略红色标记或者不知道怎么看报告。2.2 设计规则检查DRCDRC查的是PCB布局布线层面的几何与工艺问题。包括线宽是否满足电流需求、导线间距是否足够、过孔到焊盘的距离、丝印是否压到焊盘、铺铜是否形成孤岛、钻孔尺寸是否符合板厂能力。这部分是投板前最重要的一环。因为即使你的原理图逻辑完全正确器件之间电气连接全部一致只要有一根走线间距小于板厂工艺极限板子回来就可能短路或者断线。DRC就是要靠软件把这些肉眼很难盯住的问题全部筛出来。2.3 网表比对与BOM核对网表是原理图和PCB之间的桥梁。原理图更新到PCB之后软件会重新生成网表并做比对确保原理图里每一个连接都在PCB上有对应走线PCB上每一个焊盘都能追溯到原理图的引脚。但网表比对做完还不够。我见过很多工程问题出在BOM上比如选了一个封装很大的电容在PCB上占位没问题但实际采购回来的物料引脚间距跟PCB封装不匹配又比如原理图里用的电阻封装是0603但BOM里目标物料只有0805贴片时直接翻车。所以要把BOM里的物料编码、阻值容值、封装名称逐项核对一遍。2.4 PiBox里我实际要盯的几类问题回到PiBox这个项目。因为盒子内部空间有限我在布局时要特别注意电源模块和传感器接口的信号隔离避免数字地、模拟地、功率地在中间交叉。还要关注接口器件比如USB座、天线座、排针的封装丝印方向和安装方向防止反插或焊反。一般我盯的最紧的是这几条电源网络是否在PCB入口做好滤波和防反接MCU的每个电源引脚是否都有去耦电容且电容靠近引脚复位电路、启动配置引脚是否按手册要求连接高速信号线是否有参考地平面有没有跨越分割区域连接器座子的1脚方向是否清晰标注。这些检查很多并不能完全靠自动规则覆盖需要结合设计规范来做一次人工复核。3. 环境准备搭一套可复用的查错与验证流程3.1 工具选型说明我自己的习惯是用开源工具链因为版本可控、规则文件可以用文本管理、也方便写脚本做二次检查。平时在PiBox项目里主要用到以下工具工具用途说明KiCad原理图绘制与PCB设计开源EDA规则引擎可配置kicad-cli命令行检查可以执行ERC/DRC导出报告Python网表/BOM二次校验读取报告和表格做定制化检查Git版本管理管理原理图、规则文件和检查脚本如果你用Altium Designer或者立创EDA思路也完全一样只是菜单路径和导出格式不同。工具不决定你能不能查错规则和态度才决定。3.2 安装与版本说明这部分不写死具体版本号因为KiCad的版本迭代比较快命令行参数在不同大版本之间也有调整。本文写作时以KiCad 8.x为参考你安装时直接去官网下载当前稳定版即可。安装完成之后建议确认一下kicad-cli是否可用。在命令行里执行kicad-cli version如果能正常输出版本号说明命令行工具已经就绪。如果提示找不到命令需要把KiCad的bin目录加入系统PATH不同系统的路径不太一样这里重点演示思路不纠结具体路径。3.3 准备一个最小示例工程为了说明查错流程我这里用一个最小示例来演示而不是直接用PiBox完整工程。示例里包含一个MCU最小系统一个LED指示灯电路一组排针接口。这个示例麻雀虽小但足够覆盖ERC、DRC、网表比对、BOM核对四类检查。实际PiBox电路会比这个复杂但检查流程完全一致。到这一步我们有了一个可以跑的工程下面进入核心环节完整的查错闭环。4. 实战从原理图到PCB的完整查错闭环4.1 第一步原理图ERC检查在KiCad里打开原理图之后通常会用菜单“检查 - 电气规则检查”在GUI里跑一遍。这个方法适合日常快速看结果。但为了把检查动作纳入脚本和CI我更推荐用命令行。以KiCad 8.x为例在项目目录下执行# 对原理图执行电气规则检查并输出报告文件 kicad-cli sch erc --output erc_report.rpt PiBox.kicad_sch如果当前项目里还没有原理图文件或者文件命名不同需要把命令里的文件名替换成实际路径。不同版本的命令行参数可能略有差异如果提示参数不正确可以用kicad-cli sch erc --help查看当前版本支持的参数。执行完之后打开erc_report.rpt你会看到类似这样的内容ERC Report - 2025-01-12 21:30:00 Errors: 3, Warnings: 2 ErrType(2): Pin not connected - R1 pin 2 (passive) on net N$14 ErrType(4): Input pin not driven - U1 pin 7 (input) on net N$22 WarnType(1): Unconnected wires - Sheet 1, wire at (52, 63)这里最重要的是区分Errors和Warnings。Errors是必须修复的比如引脚没有连接、输入引脚没有驱动源Warnings可能是可疑设计比如单端网络、悬空引脚需要人工判断是否合理。如果你用的是Altium Designer对应操作是“Project - Compile Document”然后在Messages面板看编译结果。立创EDA则是在原理图编辑页面点“设计 - 检查”。4.2 第二步PCB布线后DRC检查原理图ERC通过之后接着做PCB布局布线。布完线、铺完铜一定要跑一遍DRC。同样用命令行# 对PCB执行设计规则检查并输出报告 kicad-cli pcb drc --output drc_report.rpt PiBox.kicad_pcbDRC报告里常见的错误类型有错误类型含义常见原因Clearance violation间距违规两条走线太近Short circuit短路网络被错误连接Hole size钻孔过小过孔尺寸低于板厂工艺Unconnected item未连接对象存在断开走线或孤岛Silkscreen over pad丝印压焊盘丝印被放置在焊盘区域这些错误一般都要修到清零尤其是Short circuit和Clearance violation。如果DRC报告里仍有未连接对象说明布线没布完不能投板。在Altium Designer里DRC对应操作是“Design - Board Rules Check然后勾选需要检查的规则点击Run Design Rule Check”。立创EDA的DRC入口在PCB编辑器顶部工具条点“设计规则检查”即可。4.3 第三步用Python脚本做网表一致性校验很多EDA工具在原理图更新到PCB时会自动做网表同步但我在PiBox里遇到过一个隐藏问题PCB里存在一个没被原理图定义的无源网络看起来像地网络实际上和系统地没有连起来导致铺铜出现孤岛信号参考地不完整。这种问题靠肉眼很难发现所以我习惯在投板前再用脚本对比一次。网表文件的格式在不同工具里差异很大KiCad的网表是netlist格式或sexpr格式Altium则可以用“File - Export - Netlist”导出成文本。这里给出一个思路示范核心是读取PCB网表和原理图网表比对网络集合是否一致。# -*- coding: utf-8 -*- 网表一致性检查脚本演示思路 需要根据实际导出的网表格式调整解析逻辑 import re from collections import defaultdict def parse_netlist(filepath): 简易解析从网表文本中提取网络名和引脚列表 nets defaultdict(list) current_net None pin_pattern re.compile(r\(ref ?([^ ])?\)\s*\(pin ?([^ ])?\)) with open(filepath, r, encodingutf-8) as f: for line in f: net_match re.search(r\(net\s?([^ ])?\), line) if net_match: current_net net_match.group(1) continue pin_match re.search(r\(node\s\(ref\s?([^ ])?\)\s\(pin\s?([^ ])?\), line) if pin_match and current_net: ref, pin pin_match.group(1), pin_match.group(2) nets[current_net].append((ref, pin)) return nets def check_consistency(sch_nets, pcb_nets): 对比原理图网表和PCB网表的网络集合 sch_net_names set(sch_nets.keys()) pcb_net_names set(pcb_nets.keys()) missing_in_pcb sch_net_names - pcb_net_names extra_in_pcb pcb_net_names - sch_net_names print( 网表一致性检查 ) if missing_in_pcb: print([ERROR] 以下网络在PCB中缺失:) for net in sorted(missing_in_pcb): print(f - {net}) if extra_in_pcb: print([WARNING] 以下网络在PCB中额外存在:) for net in sorted(extra_in_pcb): print(f - {net}) if not missing_in_pcb and not extra_in_pcb: print([OK] 网络集合完全一致) if __name__ __main__: sch_nets parse_netlist(sch_netlist.txt) pcb_nets parse_netlist(pcb_netlist.txt) check_consistency(sch_nets, pcb_nets)这段代码是演示思路不是直接可以套用到所有格式的成品脚本。实际使用时你需要查看自己工具导出的网表结构调整正则表达式。但核心逻辑是一样的把原理图里的网络集合和PCB里的网络集合做一次差集运算多的网络和少的网络都能直接暴露出来。4.4 第四步BOM与封装核对网表没问题之后我还会把BOM导出来和PCB封装库做一次交叉检查。常见的错误是原理图里选的元件封装和BOM采购物料实际封装不一致或者部分器件在PCB上有位号但BOM里遗漏。下面是一个简单的CSV比对脚本示例用于检查BOM中是否存在缺失封装或重复位号# -*- coding: utf-8 -*- BOM与封装核对脚本演示思路 假设BOM是CSV格式包含列Reference, Value, Footprint, Moq import csv import sys from collections import Counter def load_bom(path): refs [] footprints [] with open(path, newline, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: ref row.get(Reference, ).strip() footprint row.get(Footprint, ).strip() value row.get(Value, ).strip() if not ref: continue refs.append(ref) footprints.append((ref, footprint, value)) return refs, footprints def check_bom(path): refs, footprints load_bom(path) dup [item for item, count in Counter(refs).items() if count 1] missing_fp [item for item in footprints if not item[1]] print( BOM检查 ) if dup: print([ERROR] 重复位号:) for ref in dup: print(f - {ref}) if missing_fp: print([ERROR] 缺失封装的器件:) for ref, fp, val in missing_fp: print(f - {ref} ({val})) if not dup and not missing_fp: print([OK] 未发现重复位号或缺失封装) if __name__ __main__: if len(sys.argv) 2: print(用法: python check_bom.py bom.csv) sys.exit(1) check_bom(sys.argv[1])这份脚本可以直接保存为check_bom.py然后传入你自己导出的BOM CSV文件来运行python check_bom.py bom.csv注意CSV第一行必须是表头并且表头里至少包含Reference和Footprint两列。如果你的BOM导出软件用的是中文表头需要把代码里的列名改成对应的中文名称。4.5 预期输出与检查结果怎么看跑完上面四步理想的输出状态是ERC报告0 ErrorsWarnings逐步清零或确认合理DRC报告0 Errors0 Warnings网表一致性检查输出[OK] 网络集合完全一致BOM检查输出[OK] 未发现重复位号或缺失封装。但实际中很少一次通过。常见的流程是先修复ERC错误再进入PCB布线布线后再处理DRC冲突最后同步网表和BOM。整个过程是反复迭代的不要想着一步到位。5. 常见问题与排查思路这一节把我在PiBox设计过程中遇到过的以及周围朋友项目中常见的几类检查问题整理成一个表方便你对照排查。问题现象常见原因解决思路ERC报大量未连接引脚网络命名不统一引脚标签没有对齐检查网络标签和全局标签统一命名ERC报输入引脚没有被驱动遗漏上拉电阻或前级驱动电路对照芯片手册确认每个输入引脚连接DRC报Clearance violation默认间距规则设置过严或走线过密根据板厂工艺能力调整最小间距DRC报Short circuit铺铜或走线误连到其他网络高亮短路的两个网络逐段检查走线DRC报Unconnected item布线未完成或标记为不连接的焊盘没设置要么完成布线要么用规则排除该焊盘网表比对发现额外网络PCB上存在手动添加的铜皮或测试点确认该网络是否有意添加并补充到原理图BOM里存在重复位号复制粘贴时没有重新标注位号统一使用工具的重标注位号功能封装缺失新建元件时没分配Footprint在原理图库和PCB库之间关联封装遇到DRC报错时不要直接放宽规则了事。先看报错的位置和对象判断是真实问题还是规则设置不合理。如果是真实问题必须修如果是因为规则设置过严比如板厂明明支持4mil间距但软件默认设为6mil那可以调整规则文件而不是强行把走线间距拉到标准之上。6. 最佳实践与工程建议6.1 不要跳过ERC和DRC我知道很多初学者习惯性忽略ERC和DRC报错理由是“看着不太严重”或者“上板能亮”。但电路设计里的很多隐藏问题正是藏在被忽略的warning里。尤其是DRC投板厂之前必须清零Error级别的检查项。如果你是做小批量DIY至少也要做到没有短路、没有间距违法、没有未连接引脚。6.2 把规则文件纳入版本管理这一点很多人容易忽略。KiCad的设计规则可以写成独立规则文件Altium的规则设置也有对应文件。我建议把这些规则文件交给Git管理这样每次改动规则、更新间距、调整过孔尺寸都能知道是谁、在什么时候、为什么改的。对于团队协作或者长期维护的项目这一步能省下大量沟通成本。6.3 AI工具的安全用法回到本文的主题。AI不是不能用而是要放在合适的环节。我目前觉得比较安全、可靠的AI辅助用法有两种。第一种是让AI解释检查报告。把DRC报告或ERC报告原文贴给AI让它帮你把错误分类、按严重程度排序并给出每一种错误的可能修复方向。因为报告本身是结构化文本AI理解起来比较准确不容易出现幻觉。下面是一个我常用的提示词模板你是一名资深PCB设计工程师。下面是一份电路板DRC检查报告请帮我对错误进行分类 1. 按严重程度分成“必须修复”、“建议修复”、“可以忽略”三类 2. 对每一类错误给出可能的成因 3. 对必须修复的错误给出具体的排查顺序。 报告内容如下 [在这里粘贴你的DRC报告全文]第二种是让AI辅助生成检查脚本比如辅助解析网表、比对BOM。AI在这个场景里相当于一个熟练的Python助手能快速帮你写出脚本骨架然后你再根据实际格式去调整。这类任务是LLM的舒适区生成结果可以快速验证也不会造成硬件损坏。反过来不要让AI直接生成完整的原理图更不要让AI自动完成PCB布线。除非你用的是厂商自带的、经过大量验证的自动化布线工具并且设置了非常完整的约束。6.4 可制造性检查DFM除了自检投板厂一般会再做一次可制造性检查。常见DFM项包括最小线宽、最小线距、最小钻孔尺寸、铜厚要求、阻焊桥宽度、板边距离等。不同板厂的工艺能力不一样最好在投板前把目标板厂的工艺参数导入到DRC规则里这样DRC跑完就跟工厂要求完全对齐避免打样回来发现过孔孔径不达标或者线路被蚀刻断掉。6.5 查错通过不等于能生产最后提醒一句查错流程全部通过只代表设计文件本身没有低级错误不代表板子功能一定正确也不代表元器件一定选型合理。电路设计最终还需要通过仿真、焊接、上电测试来验证。在PiBox项目里我投板前一定会先检查器件供货情况再做一些电源、串口、GPIO的初步测试规划确保板子回来之后能快速验证。7. 小结与下一步计划这一篇设计日志主要把“查错”这个环节完整梳理了一遍。我的核心观点是AI在硬件设计里的应用重点不是“生成”而是“检查与辅助分析”。用AI画电路板现阶段风险远大于收益但把AI用在解释检查报告、辅助编写校验脚本、整理BOM这些环节能明显提升效率也更符合工程落地的需求。从流程上我建议任何PCB设计项目在投板前至少跑完四步原理图ERC、PCB DRC、网表一致性比对、BOM与封装核对。前两步用EDA软件自带功能后两步可以用Python脚本辅助完成整个过程是完全可以自动化的。下一阶段我会继续推进PiBox的原理图细化和PCB布局重点把电源完整性、信号完整性和接口防护这几个部分落实到位。如果你也在做类似的小型嵌入式项目希望这篇日志能帮你少走一点弯路。有问题欢迎在评论区交流我会尽量回复。 
长河君 · 2026/9/4 8:04:02 · 阅读 1.2k AI辅助电路板查错：从ERC到BOM的完整PCB检查指南
如果你最近也在纠结“能不能让AI直接帮我画一块电路板”并且想搞清楚AI在硬件设计里到底能做什么、不能做什么那这篇文章应该能给你一个比较完整的答案。这篇是 PiBox 设计日志的第 02 篇。PiBox 是我手头正在做的一个小型开源嵌入式盒子项目用来跑一些传感器采集和边缘计算实验。上一回我定下了整体功能框图这一回的核心任务是把“板子画完之后怎么确保它是对的”这个环节梳理清楚。我的结论先说在前面用AI去生成完整的、能直接投产的原理图和PCB布线现阶段非常不靠谱但把AI放到“电路板查错”这个环节里作为一个辅助分析工具反而是现在性价比很高的用法。接下来我会结合 PiBox 的实际排查流程把原理图检查、DRC规则检查、网表比对、BOM核对这些环节完整拆解一遍并给出可复用的脚本和检查清单。1. 背景与核心概念AI画电路板和AI查电路板到底是两回事1.1 为什么“AI画电路板”会让人心动最近AI工具渗透得确实很猛AI编程、AI建站、AI做视频、AI画图几乎每个领域都在被重新刷一遍。于是很多人会自然想到既然AI能写代码、能写文章那是不是也能直接生成一块电路板输入需求描述AI返回原理图、PCB文件甚至直接提交打样听起来确实很诱人。这种想法并不奇怪。硬件设计里确实有大量重复劳动比如选型、算参数、连引脚、排布局、走线、调丝印每一件都耗时。再加上PCB设计软件本身学习成本不低新手很容易产生“让AI替我干”的冲动。但这里有一个根本性误区写代码和画电路板虽然都叫“设计”但它们的验证闭环完全不同。代码写错了编译器会报错跑测试用例能发现问题电路画错了很多时候要等到板子打样回来焊完元件、上电之后才暴露甚至会因为一个引脚连接错误直接把芯片烧掉。硬件设计的错误成本比软件高一个数量级这意味着AI的自由发挥空间必须被严格压缩。1.2 AI在PCB设计里的真实能力边界现阶段AI在电路设计里能做的事情大致可以分成三类。第一类是对话式方案咨询比如你问“MCU选型要考虑什么”“LDO前面要不要加TVS管”AI可以给出有条理的经验性回答。这类内容是LLM的强项因为它们本质上是语言组织和对已有知识的重新排列。第二类是辅助生成电路描述比如让AI生成一个传感器的接口电路说明、一段Arduino初始化代码、一张引脚连接表。这些东西做出来看起来像模像样但依然停留在“文本描述”层面距离能生产的原理图还缺少一整套约束信息。第三类是直接生成原理图或PCB文件比如某些云平台提供的AI辅助布线、自动扇出功能。这类功能确实存在也有一定实用性但它们解决的是“在设计师设定好约束之后把活干完”的问题而不是从零开始替你完成设计。换句话说AI在电路设计里的真实定位是“副驾驶”不是“驾驶员”。一个合格的PCB设计流程核心是围绕网表、封装、规则、约束来展开的AI当前的推理能力还无法稳定处理这几类信息的强一致性问题。让AI自由画出的电路很容易出现“看起来合理、实际不可生产”的情况。1.3 查错环节为什么更适合引入AI辅助既然AI画板不靠谱那“查错”为什么更靠谱关键在于查错是一个有明确输入、明确规则、明确输出的过程。查错的输入是原理图文件、PCB文件、网表、BOM规则是电气连接规则、间距规则、线宽规则、封装规范输出是一份错误清单。这个过程不需要AI“创造”只需要它“判断”。而判断恰好是现在AI工具相对能做好的事情尤其是当你把DRC/ERC报告丢给AI去归纳、分类、解释的时候表现会超出预期。我自己在PiBox里的实际体验是AI直接画板我要花大量时间逐项复查但AI辅助解读检查报告能快速帮我定位哪些错误必须修、哪些可能是规则设置过严导致的误报还可以根据错误描述给出修复建议。这才是目前最顺手的用法。2. 电路板查错到底查什么从原理图到PCB的完整检查链条很多人以为查错就是“用眼睛看一遍原理图”其实正规的检查链条比这长得多。以PiBox为例我在投板之前至少要过四道检查电气规则检查、设计规则检查、网表一致性检查、BOM与封装核对。2.1 电气规则检查ERCERC查的是原理图层面的逻辑问题。比如引脚有没有悬空、电源和地有没有短接、同一个网络名有没有被错误复用、芯片的使能脚是不是没接、输出引脚之间有没有直接打架。这类错误如果在原理图阶段不解决后面布PCB时会全部带进去最终烧板。常见的ERC错误类型包括未连接引脚、单端网络、输入引脚驱动冲突、电源短路、重复位号等。在KiCad、Altium Designer、立创EDA里都会在每次原理图保存或编译时自动跑一遍ERC但很多人会忽略红色标记或者不知道怎么看报告。2.2 设计规则检查DRCDRC查的是PCB布局布线层面的几何与工艺问题。包括线宽是否满足电流需求、导线间距是否足够、过孔到焊盘的距离、丝印是否压到焊盘、铺铜是否形成孤岛、钻孔尺寸是否符合板厂能力。这部分是投板前最重要的一环。因为即使你的原理图逻辑完全正确器件之间电气连接全部一致只要有一根走线间距小于板厂工艺极限板子回来就可能短路或者断线。DRC就是要靠软件把这些肉眼很难盯住的问题全部筛出来。2.3 网表比对与BOM核对网表是原理图和PCB之间的桥梁。原理图更新到PCB之后软件会重新生成网表并做比对确保原理图里每一个连接都在PCB上有对应走线PCB上每一个焊盘都能追溯到原理图的引脚。但网表比对做完还不够。我见过很多工程问题出在BOM上比如选了一个封装很大的电容在PCB上占位没问题但实际采购回来的物料引脚间距跟PCB封装不匹配又比如原理图里用的电阻封装是0603但BOM里目标物料只有0805贴片时直接翻车。所以要把BOM里的物料编码、阻值容值、封装名称逐项核对一遍。2.4 PiBox里我实际要盯的几类问题回到PiBox这个项目。因为盒子内部空间有限我在布局时要特别注意电源模块和传感器接口的信号隔离避免数字地、模拟地、功率地在中间交叉。还要关注接口器件比如USB座、天线座、排针的封装丝印方向和安装方向防止反插或焊反。一般我盯的最紧的是这几条电源网络是否在PCB入口做好滤波和防反接MCU的每个电源引脚是否都有去耦电容且电容靠近引脚复位电路、启动配置引脚是否按手册要求连接高速信号线是否有参考地平面有没有跨越分割区域连接器座子的1脚方向是否清晰标注。这些检查很多并不能完全靠自动规则覆盖需要结合设计规范来做一次人工复核。3. 环境准备搭一套可复用的查错与验证流程3.1 工具选型说明我自己的习惯是用开源工具链因为版本可控、规则文件可以用文本管理、也方便写脚本做二次检查。平时在PiBox项目里主要用到以下工具工具用途说明KiCad原理图绘制与PCB设计开源EDA规则引擎可配置kicad-cli命令行检查可以执行ERC/DRC导出报告Python网表/BOM二次校验读取报告和表格做定制化检查Git版本管理管理原理图、规则文件和检查脚本如果你用Altium Designer或者立创EDA思路也完全一样只是菜单路径和导出格式不同。工具不决定你能不能查错规则和态度才决定。3.2 安装与版本说明这部分不写死具体版本号因为KiCad的版本迭代比较快命令行参数在不同大版本之间也有调整。本文写作时以KiCad 8.x为参考你安装时直接去官网下载当前稳定版即可。安装完成之后建议确认一下kicad-cli是否可用。在命令行里执行kicad-cli version如果能正常输出版本号说明命令行工具已经就绪。如果提示找不到命令需要把KiCad的bin目录加入系统PATH不同系统的路径不太一样这里重点演示思路不纠结具体路径。3.3 准备一个最小示例工程为了说明查错流程我这里用一个最小示例来演示而不是直接用PiBox完整工程。示例里包含一个MCU最小系统一个LED指示灯电路一组排针接口。这个示例麻雀虽小但足够覆盖ERC、DRC、网表比对、BOM核对四类检查。实际PiBox电路会比这个复杂但检查流程完全一致。到这一步我们有了一个可以跑的工程下面进入核心环节完整的查错闭环。4. 实战从原理图到PCB的完整查错闭环4.1 第一步原理图ERC检查在KiCad里打开原理图之后通常会用菜单“检查 - 电气规则检查”在GUI里跑一遍。这个方法适合日常快速看结果。但为了把检查动作纳入脚本和CI我更推荐用命令行。以KiCad 8.x为例在项目目录下执行# 对原理图执行电气规则检查并输出报告文件 kicad-cli sch erc --output erc_report.rpt PiBox.kicad_sch如果当前项目里还没有原理图文件或者文件命名不同需要把命令里的文件名替换成实际路径。不同版本的命令行参数可能略有差异如果提示参数不正确可以用kicad-cli sch erc --help查看当前版本支持的参数。执行完之后打开erc_report.rpt你会看到类似这样的内容ERC Report - 2025-01-12 21:30:00 Errors: 3, Warnings: 2 ErrType(2): Pin not connected - R1 pin 2 (passive) on net N$14 ErrType(4): Input pin not driven - U1 pin 7 (input) on net N$22 WarnType(1): Unconnected wires - Sheet 1, wire at (52, 63)这里最重要的是区分Errors和Warnings。Errors是必须修复的比如引脚没有连接、输入引脚没有驱动源Warnings可能是可疑设计比如单端网络、悬空引脚需要人工判断是否合理。如果你用的是Altium Designer对应操作是“Project - Compile Document”然后在Messages面板看编译结果。立创EDA则是在原理图编辑页面点“设计 - 检查”。4.2 第二步PCB布线后DRC检查原理图ERC通过之后接着做PCB布局布线。布完线、铺完铜一定要跑一遍DRC。同样用命令行# 对PCB执行设计规则检查并输出报告 kicad-cli pcb drc --output drc_report.rpt PiBox.kicad_pcbDRC报告里常见的错误类型有错误类型含义常见原因Clearance violation间距违规两条走线太近Short circuit短路网络被错误连接Hole size钻孔过小过孔尺寸低于板厂工艺Unconnected item未连接对象存在断开走线或孤岛Silkscreen over pad丝印压焊盘丝印被放置在焊盘区域这些错误一般都要修到清零尤其是Short circuit和Clearance violation。如果DRC报告里仍有未连接对象说明布线没布完不能投板。在Altium Designer里DRC对应操作是“Design - Board Rules Check然后勾选需要检查的规则点击Run Design Rule Check”。立创EDA的DRC入口在PCB编辑器顶部工具条点“设计规则检查”即可。4.3 第三步用Python脚本做网表一致性校验很多EDA工具在原理图更新到PCB时会自动做网表同步但我在PiBox里遇到过一个隐藏问题PCB里存在一个没被原理图定义的无源网络看起来像地网络实际上和系统地没有连起来导致铺铜出现孤岛信号参考地不完整。这种问题靠肉眼很难发现所以我习惯在投板前再用脚本对比一次。网表文件的格式在不同工具里差异很大KiCad的网表是netlist格式或sexpr格式Altium则可以用“File - Export - Netlist”导出成文本。这里给出一个思路示范核心是读取PCB网表和原理图网表比对网络集合是否一致。# -*- coding: utf-8 -*- 网表一致性检查脚本演示思路 需要根据实际导出的网表格式调整解析逻辑 import re from collections import defaultdict def parse_netlist(filepath): 简易解析从网表文本中提取网络名和引脚列表 nets defaultdict(list) current_net None pin_pattern re.compile(r\(ref ?([^ ])?\)\s*\(pin ?([^ ])?\)) with open(filepath, r, encodingutf-8) as f: for line in f: net_match re.search(r\(net\s?([^ ])?\), line) if net_match: current_net net_match.group(1) continue pin_match re.search(r\(node\s\(ref\s?([^ ])?\)\s\(pin\s?([^ ])?\), line) if pin_match and current_net: ref, pin pin_match.group(1), pin_match.group(2) nets[current_net].append((ref, pin)) return nets def check_consistency(sch_nets, pcb_nets): 对比原理图网表和PCB网表的网络集合 sch_net_names set(sch_nets.keys()) pcb_net_names set(pcb_nets.keys()) missing_in_pcb sch_net_names - pcb_net_names extra_in_pcb pcb_net_names - sch_net_names print( 网表一致性检查 ) if missing_in_pcb: print([ERROR] 以下网络在PCB中缺失:) for net in sorted(missing_in_pcb): print(f - {net}) if extra_in_pcb: print([WARNING] 以下网络在PCB中额外存在:) for net in sorted(extra_in_pcb): print(f - {net}) if not missing_in_pcb and not extra_in_pcb: print([OK] 网络集合完全一致) if __name__ __main__: sch_nets parse_netlist(sch_netlist.txt) pcb_nets parse_netlist(pcb_netlist.txt) check_consistency(sch_nets, pcb_nets)这段代码是演示思路不是直接可以套用到所有格式的成品脚本。实际使用时你需要查看自己工具导出的网表结构调整正则表达式。但核心逻辑是一样的把原理图里的网络集合和PCB里的网络集合做一次差集运算多的网络和少的网络都能直接暴露出来。4.4 第四步BOM与封装核对网表没问题之后我还会把BOM导出来和PCB封装库做一次交叉检查。常见的错误是原理图里选的元件封装和BOM采购物料实际封装不一致或者部分器件在PCB上有位号但BOM里遗漏。下面是一个简单的CSV比对脚本示例用于检查BOM中是否存在缺失封装或重复位号# -*- coding: utf-8 -*- BOM与封装核对脚本演示思路 假设BOM是CSV格式包含列Reference, Value, Footprint, Moq import csv import sys from collections import Counter def load_bom(path): refs [] footprints [] with open(path, newline, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: ref row.get(Reference, ).strip() footprint row.get(Footprint, ).strip() value row.get(Value, ).strip() if not ref: continue refs.append(ref) footprints.append((ref, footprint, value)) return refs, footprints def check_bom(path): refs, footprints load_bom(path) dup [item for item, count in Counter(refs).items() if count 1] missing_fp [item for item in footprints if not item[1]] print( BOM检查 ) if dup: print([ERROR] 重复位号:) for ref in dup: print(f - {ref}) if missing_fp: print([ERROR] 缺失封装的器件:) for ref, fp, val in missing_fp: print(f - {ref} ({val})) if not dup and not missing_fp: print([OK] 未发现重复位号或缺失封装) if __name__ __main__: if len(sys.argv) 2: print(用法: python check_bom.py bom.csv) sys.exit(1) check_bom(sys.argv[1])这份脚本可以直接保存为check_bom.py然后传入你自己导出的BOM CSV文件来运行python check_bom.py bom.csv注意CSV第一行必须是表头并且表头里至少包含Reference和Footprint两列。如果你的BOM导出软件用的是中文表头需要把代码里的列名改成对应的中文名称。4.5 预期输出与检查结果怎么看跑完上面四步理想的输出状态是ERC报告0 ErrorsWarnings逐步清零或确认合理DRC报告0 Errors0 Warnings网表一致性检查输出[OK] 网络集合完全一致BOM检查输出[OK] 未发现重复位号或缺失封装。但实际中很少一次通过。常见的流程是先修复ERC错误再进入PCB布线布线后再处理DRC冲突最后同步网表和BOM。整个过程是反复迭代的不要想着一步到位。5. 常见问题与排查思路这一节把我在PiBox设计过程中遇到过的以及周围朋友项目中常见的几类检查问题整理成一个表方便你对照排查。问题现象常见原因解决思路ERC报大量未连接引脚网络命名不统一引脚标签没有对齐检查网络标签和全局标签统一命名ERC报输入引脚没有被驱动遗漏上拉电阻或前级驱动电路对照芯片手册确认每个输入引脚连接DRC报Clearance violation默认间距规则设置过严或走线过密根据板厂工艺能力调整最小间距DRC报Short circuit铺铜或走线误连到其他网络高亮短路的两个网络逐段检查走线DRC报Unconnected item布线未完成或标记为不连接的焊盘没设置要么完成布线要么用规则排除该焊盘网表比对发现额外网络PCB上存在手动添加的铜皮或测试点确认该网络是否有意添加并补充到原理图BOM里存在重复位号复制粘贴时没有重新标注位号统一使用工具的重标注位号功能封装缺失新建元件时没分配Footprint在原理图库和PCB库之间关联封装遇到DRC报错时不要直接放宽规则了事。先看报错的位置和对象判断是真实问题还是规则设置不合理。如果是真实问题必须修如果是因为规则设置过严比如板厂明明支持4mil间距但软件默认设为6mil那可以调整规则文件而不是强行把走线间距拉到标准之上。6. 最佳实践与工程建议6.1 不要跳过ERC和DRC我知道很多初学者习惯性忽略ERC和DRC报错理由是“看着不太严重”或者“上板能亮”。但电路设计里的很多隐藏问题正是藏在被忽略的warning里。尤其是DRC投板厂之前必须清零Error级别的检查项。如果你是做小批量DIY至少也要做到没有短路、没有间距违法、没有未连接引脚。6.2 把规则文件纳入版本管理这一点很多人容易忽略。KiCad的设计规则可以写成独立规则文件Altium的规则设置也有对应文件。我建议把这些规则文件交给Git管理这样每次改动规则、更新间距、调整过孔尺寸都能知道是谁、在什么时候、为什么改的。对于团队协作或者长期维护的项目这一步能省下大量沟通成本。6.3 AI工具的安全用法回到本文的主题。AI不是不能用而是要放在合适的环节。我目前觉得比较安全、可靠的AI辅助用法有两种。第一种是让AI解释检查报告。把DRC报告或ERC报告原文贴给AI让它帮你把错误分类、按严重程度排序并给出每一种错误的可能修复方向。因为报告本身是结构化文本AI理解起来比较准确不容易出现幻觉。下面是一个我常用的提示词模板你是一名资深PCB设计工程师。下面是一份电路板DRC检查报告请帮我对错误进行分类 1. 按严重程度分成“必须修复”、“建议修复”、“可以忽略”三类 2. 对每一类错误给出可能的成因 3. 对必须修复的错误给出具体的排查顺序。 报告内容如下 [在这里粘贴你的DRC报告全文]第二种是让AI辅助生成检查脚本比如辅助解析网表、比对BOM。AI在这个场景里相当于一个熟练的Python助手能快速帮你写出脚本骨架然后你再根据实际格式去调整。这类任务是LLM的舒适区生成结果可以快速验证也不会造成硬件损坏。反过来不要让AI直接生成完整的原理图更不要让AI自动完成PCB布线。除非你用的是厂商自带的、经过大量验证的自动化布线工具并且设置了非常完整的约束。6.4 可制造性检查DFM除了自检投板厂一般会再做一次可制造性检查。常见DFM项包括最小线宽、最小线距、最小钻孔尺寸、铜厚要求、阻焊桥宽度、板边距离等。不同板厂的工艺能力不一样最好在投板前把目标板厂的工艺参数导入到DRC规则里这样DRC跑完就跟工厂要求完全对齐避免打样回来发现过孔孔径不达标或者线路被蚀刻断掉。6.5 查错通过不等于能生产最后提醒一句查错流程全部通过只代表设计文件本身没有低级错误不代表板子功能一定正确也不代表元器件一定选型合理。电路设计最终还需要通过仿真、焊接、上电测试来验证。在PiBox项目里我投板前一定会先检查器件供货情况再做一些电源、串口、GPIO的初步测试规划确保板子回来之后能快速验证。7. 小结与下一步计划这一篇设计日志主要把“查错”这个环节完整梳理了一遍。我的核心观点是AI在硬件设计里的应用重点不是“生成”而是“检查与辅助分析”。用AI画电路板现阶段风险远大于收益但把AI用在解释检查报告、辅助编写校验脚本、整理BOM这些环节能明显提升效率也更符合工程落地的需求。从流程上我建议任何PCB设计项目在投板前至少跑完四步原理图ERC、PCB DRC、网表一致性比对、BOM与封装核对。前两步用EDA软件自带功能后两步可以用Python脚本辅助完成整个过程是完全可以自动化的。下一阶段我会继续推进PiBox的原理图细化和PCB布局重点把电源完整性、信号完整性和接口防护这几个部分落实到位。如果你也在做类似的小型嵌入式项目希望这篇日志能帮你少走一点弯路。有问题欢迎在评论区交流我会尽量回复。