企业官网建设流程全解析

如果你最近也在纠结“能不能让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 电气规则检查（ERC）

ERC查的是原理图层面的逻辑问题。比如引脚有没有悬空、电源和地有没有短接、同一个网络名有没有被错误复用、芯片的使能脚是不是没接、输出引脚之间有没有直接打架。这类错误如果在原理图阶段不解决，后面布PCB时会全部带进去，最终烧板。

常见的ERC错误类型包括未连接引脚、单端网络、输入引脚驱动冲突、电源短路、重复位号等。在KiCad、Altium Designer、立创EDA里都会在每次原理图保存或编译时自动跑一遍ERC，但很多人会忽略红色标记，或者不知道怎么看报告。

2.2 设计规则检查（DRC）

DRC查的是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项目里主要用到以下工具：

如果你用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_pcb

DRC报告里常见的错误类型有：

这些错误一般都要修到清零，尤其是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", encoding="utf-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="", encoding="utf-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 Errors，Warnings逐步清零或确认合理；
• DRC报告0 Errors，0 Warnings；
• 网表一致性检查输出[OK] 网络集合完全一致；
• BOM检查输出[OK] 未发现重复位号或缺失封装。

但实际中很少一次通过。常见的流程是：先修复ERC错误，再进入PCB布线，布线后再处理DRC冲突，最后同步网表和BOM。整个过程是反复迭代的，不要想着一步到位。

5. 常见问题与排查思路

这一节把我在PiBox设计过程中遇到过的，以及周围朋友项目中常见的几类检查问题整理成一个表，方便你对照排查。

遇到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布局，重点把电源完整性、信号完整性和接口防护这几个部分落实到位。如果你也在做类似的小型嵌入式项目，希望这篇日志能帮你少走一点弯路。有问题欢迎在评论区交流，我会尽量回复。