别让AI画板了！AI辅助电路查错实战指南：网表、BOM与DRC审查

做硬件最怕的不是画错一根线，而是一版原理图看起来完整、投板回来却通电就冒烟。最近在推进 PiBox 这个开源硬件项目时，我们被电气规则检查、网表核对和 BOM 比对反复折磨，也顺手试了试“让 AI 直接画电路板图”的方案，结论很明确：别用 AI 画电路板了，它画出来的图看着像那么回事，实际连接关系完全不可信；真正值得做的，是拿 AI 做设计后的查错和审查。这篇文章就基于 PiBox 设计日志 02 的实践思路，把“AI 辅助电路查错”的完整流程、提示词模板、脚本化接入方法和排查边界整理出来。如果你正在画板、调板或者准备投板，建议直接收藏。

整篇文章要解决三个问题：AI 查错到底能查什么、怎么查、哪些坑不能踩。先说结论：AI 查错不能替代 EDA 工具的 DRC/ERC，也不能替代人工原理图评审，但它非常适合做网表异常识别、BOM 一致性核对、DRC 报告归类排序、经验性设计规范检查这四类工作。而且它的硬件门槛比大多数人想象的低，不需要 GPU，普通办公电脑就能跑，文本型任务占用的资源几乎可以忽略。

1. PiBox 查错方案核心能力速览

表里的分工很关键：EDA 工具负责“规则确定性检查”，AI 负责“经验性扫描和异常发现”。PiBox 项目里我们推荐的做法是先用 EDA 工具跑一遍 DRC/ERC，再把文本报告丢给 AI 做二次归类，这样错误定位效率会高很多。

2. 为什么是查错，不是画板

先解释标题里的劝退结论：为什么别用 AI 画电路板。

现在的 AI 画图工具擅长的是“像素级生成”，它知道一张电路板照片应该长什么样，知道原理图符号大概是什么形状，但它不理解引脚编号背后的电气含义。你让它画一个 STM32F103 的最小系统原理图，它可能给你画出一个看着很完整的 MCU 框图，但引脚 PA9 和 PA10 的映射、去耦电容的位置、电源网络的连接关系，很可能在视觉上“很像”，逻辑上完全错误。原因很简单：

• 电路设计本质是约束求解问题，不是图像生成问题。
• 引脚分配、上拉电阻、电源域划分、阻抗匹配，这些规则不能靠“看着像”来判断。
• AI 生成图片时没有逐网络校验能力，连“这张图里两条线是否真的电气连通”都无法保证。

所以，真实硬件项目里的正确姿势是：让 AI 回归它最擅长的领域——读文本、找异常、做核对。而电路设计过程中恰恰有大量文本化产物：网表文件、BOM 清单、DRC 报告、数据手册的引脚定义表。这些文件格式规整、信息密度高、错误模式重复性大，非常适合 AI 做模式识别和异常扫描。

PiBox 设计日志 02 里我们验证的核心观点就是：AI 画板是灾难，AI 查错是真香。同样的模型，放在“生成一张电路板图”和“读一个网表并列出异常网络”两个任务上，后者的可用性会高出几个量级。

3. 适用场景与使用边界

3.1 适合谁用

• 正在做硬件设计的嵌入式工程师、电子工程师、创客。
• 用 KiCad、立创EDA、Altium 等工具画板，但是人工 Review 时间不够的团队。
• 需要快速解读大量 DRC 错误报告的 PCB 工程师。
• 负责 BOM 备料和物料核对的生产或采购人员。
• 开源硬件项目维护者，需要批量审查社区提交的原理图修改。

3.2 能解决什么问题

• 原理图网表里出现悬空引脚、单点网络、电源短接等异常。
• BOM 中封装与原理图符号不一致、阻值容值标错、替代料参数冲突。
• DRC 报告几百行错误信息，人工阅读耗时且容易漏掉高优先级故障。
• 设计规范类问题，例如去耦电容位置不合理、晶振周围走线过长、模拟地与数字地单点连接缺失等。

3.3 不适合什么场景

• 不适合替代 EDA 工具的 DRC/ERC 做最终判据，网络开路、短路这类问题必须以 EDA 工具结果为准。
• 不适合 AI 直接生成 Gerber 文件或可投板工程，任何 AI 输出都必须经过原生 EDA 工具导入校验。
• 不适合把未公开的产品设计文件直接上传到公共 AI 平台，涉及公司保密项目时要使用本地模型或脱敏数据。

3.4 合规与安全提醒

使用 AI 做电路查错时，必须注意数据合规：设计文档、BOM 清单、引脚定义、PCB 走线信息都属于工程数据，部分还涉及商业机密。上传到外部 API 前应做脱敏处理，或者直接在内网部署本地模型。引用芯片数据手册内容做分析时，注意遵守芯片厂商的文档使用条款。所有 AI 输出的“疑似问题”必须经过人工复核才能进入修改流程，避免误判引入新故障。

4. 环境准备与前置条件

PiBox 的这次查错流程，本质上是一个“文本格式工程化”过程，所以环境要求非常低。

4.1 基础环境清单

4.2 Python 依赖

核心依赖只有两个：requests用于调用 API，pandas用于处理 BOM 表格，openpyxl或xlsxwriter用于 Excel 读写。

# 安装依赖，Windows 下同样适用 pip install requests pandas openpyxl xlsxwriter

4.3 导出网表

以 KiCad 为例：

1. 打开原理图，点击菜单文件 -> 导出 -> 网表。
2. 选择格式为KiCad或Spice格式。
3. 导出后得到.net后缀的文本文件。
4. 用文本编辑器打开确认内容可读，通常包含元件声明和网络连接两部分。

立创EDA 的操作路径类似：在原理图编辑器里点击导出 -> 网表，选择文本格式导出即可。

4.4 导出 DRC 报告

PCB 编辑器中运行设计规则检查后，KiCad 会生成.rpt报告文件，立创EDA 会生成文本或 PDF 报告。建议统一导出为.txt或.csv格式，方便后续交给 AI 分析。

4.5 文件组织

推荐建一个统一的审查目录，每个 PCB 版本一个子目录：

pibox_review/ ├── v1.0/ │ ├── netlist.net │ ├── BOM.csv │ ├── DRC.txt │ └── review_notes.md ├── v1.1/ │ ├── netlist.net │ ├── BOM.csv │ ├── DRC.txt │ └── review_notes.md └── scripts/ ├── ai_review.py ├── prompts/ │ ├── netlist_check.txt │ ├── bom_check.txt │ └── drc_classify.txt └── outputs/

这样做的目的是让每次 AI 查错都能追溯：输入是什么版本、输出哪些问题、人工复核结果如何。

5. AI 电路板查错功能测试与效果验证

这一节是文章重点，按“测试目的、输入、步骤、预期、判断标准、失败排查”六个要素拆解。

5.1 测试 1：网表异常审查

测试目的：确定 AI 能否从原理图网表文本中识别悬空引脚、单点网络、电源短接、命名不一致等异常。

输入素材：KiCad 导出的.net网表文件。以下是一段脱敏后的示例结构：

(version 20211014) (comp (ref "U1") (value "STM32F103C8T6") (footprint "LQFP48")) (comp (ref "C1") (value "100nF") (footprint "0603")) (comp (ref "R1") (value "10k") (footprint "0603")) (net (code 0) (name "GND")) (net (code 1) (name "VCC")) (net (code 2) (name "PA9")) (node (ref "U1") (pin "30") (net "PA9")) (node (ref "U1") (pin "31") (net "PA10")) (node (ref "R1") (pin "1") (net "PA9")) (node (ref "C1") (pin "1") (net "GND")) (node (ref "C1") (pin "2") (net "VCC"))

操作步骤：

1. 准备netlist_check.txt提示词模板。
2. 将网表内容作为文本输入。
3. 让 AI 输出问题清单，格式要求：问题类型、网络名/元件位号、可能影响、建议动作。

提示词模板示例：

你是一名资深硬件设计评审工程师。下面是一份原理图网表，请检查并列出所有可疑问题。 关注点： 1. 只连接了一个节点的网络（单点网络）。 2. 元件引脚是否出现悬空（在网表中没有任何连接）。 3. 电源网络 VCC/GND 之间是否出现直接短接风险。 4. 网络命名是否不一致，例如有时叫 VCC_3V3，有时叫 VCC，导致预期外断开。 输出格式： ### 问题 1 - 问题类型： - 网络/元件： - 风险等级：高/中/低 - 详细说明： - 建议处理方式： 网表内容如下： {这里粘贴网表内容}

预期结果：AI 能列出网表中等价网络的连通关系，指出像R1的 pin 2 未在任何 network 中出现这类问题。

判断成功标准：

• 至少能发现一个人工容易被忽略的悬空引脚或单点网络。
• 输出中的位号、引脚编号能对应到原始网表。
• 误报控制在 30% 以内，超过这个比例说明网表格式不适合直接投喂，需要做预格式化。

常见失败原因：

• 网表格式包含过多二进制或非标准数据，模型无法解析。
• 网表太大，超出模型上下文窗口，这时需要分段。
• 提示词没有限定输出格式，导致结果散乱，难以读取。

5.2 测试 2：BOM 一致性核对

测试目的：让 AI 检查 BOM 中存在阻值、容值、封装、耐压、精度等信息冲突。

输入素材：CSV 格式的 BOM 文件。示例：

位号,元件名称,规格参数,封装,数量 C1,陶瓷电容,100nF 50V X7R,0603,1 C2,陶瓷电容,100nF 50V X7R,0603,1 R1,贴片电阻,10k 1%,0603,1 R2,贴片电阻,10k 1%,0805,1 U1,微控制器,STM32F103C8T6,LQFP48,1

操作步骤：

1. 读取 BOM 的 CSV 内容。
2. 将其转换为 Markdown 表格，再交给 AI。
3. 要求 AI 对比同一网络或同一电路模块的元件规格，指出异常。

提示词模板示例：

以下是一份电子料 BOM，请检查并输出潜在错误。 检查项： 1. 同类位号（例如同为去耦电容）的封装是否不一致。 2. 电阻阻值标注是否与常见电路用法一致（例如上拉电阻写成 10k 但丝印阻值误标为 1k）。 3. 电容耐压值是否过低，如果电路中有 12V 电源，请检查是否有 6.3V 耐压的电容被用于该电源域。 4. 数量是否与位号数量匹配，缺失位号或重复位号。 5. 替代料之间的温度等级、精度、封装是否兼容。 BOM 内容： {这里粘贴 BOM 的 Markdown 表格}

预期结果：AI 能识别出R1和R2都是 10k 电阻但一个封装 0603、一个封装 0805 这种不一致，并提醒确认是否有意设计。

判断成功标准：

• 位号和参数对应关系正确。
• 建议是否合理可执行。
• 特别要注意 AI 可能会把“封装不一致”误报为错误，实际上双封装可能是设计需要，人工复核时要核实原理图封装是否确实不同。

5.3 测试 3：DRC 报告解读与优先级排序

测试目的：DRC 报告往往有几十上百条告警，AI 负责去重、归类、排序。

输入素材：KiCad 导出的.rpt报告文本。

操作步骤：

1. 将 DRC 报告全文粘贴给 AI。
2. 让 AI 按“短路类、间距类、钻孔类、丝印类、未连接类”分类。
3. 要求 AI 按照“可能导致断板/短路”高优先级在前输出。

提示词模板示例：

下面是一份 PCB 设计规则检查 DRC 报告，请完成以下任务： 1. 去除重复条目。 2. 按故障类型分类：短路/间距/钻孔/丝印/未连接/其他。 3. 按风险等级从高到低排序。 4. 对每一条用一句话解释为什么会触发，方便新手工程师理解。 输出格式： | 序号 | 类型 | 风险等级 | 位置/网络 | 原始信息摘要 | 可能原因 | 输出内容： {这里粘贴 DRC 报告}

预期结果：AI 能输出一张分类排序表，优先展示短路和未连接问题，弱化丝印层误报。

判断成功标准：

• 分类数量准确，无漏项。
• 风险等级排序接近 EDA 工具自带过滤的默认结果。
• 解读文字简洁，适合放进评审记录。

常见失败原因：

• DRC 报告包含坐标数据过多，上下文被无关信息占满。
• 模型分不清“warning”和“error”，需要在提示词里强调“error 优先”。
• 报告是 PDF 或图片格式，需要先转成文本。

5.4 测试 4：经验性设计规范检查

测试目的：EDA 工具不会告诉你晶振下面不要走数字信号线、去耦电容要靠近电源引脚，这些经验性规则靠 AI 补位。

输入素材：一份简要的板卡设计说明，包括电源拓扑、主要芯片布局、关键信号走向。

操作步骤：

1. 将设计说明整理为 Markdown 文本。
2. 配置“设计规范检查”提示词。
3. AI 输出建议清单和风险提示。

提示词模板示例：

你是一名 PCB 设计资深专家。请根据下面的设计说明，结合常见硬件设计规范，列出可能存在的设计风险。 重点关注： 1. 电源部分去耦电容是否靠近负载引脚。 2. 晶振、时钟线附近是否有高频数字信号干扰风险。 3. 模拟地与数字地是否采用单点连接。 4. 功率器件散热焊盘和过孔设计。 5. 接口防护器件（ESD/TVS）是否靠近连接器。 设计说明： {这里粘贴设计说明文本}

预期结果：AI 给出“该设计在 MCU 晶振下方存在高频信号线，建议调整走线层”等可执行建议。

判断成功标准：建议合理、有依据、不泛泛而谈。这个测试主观性较强，建议多人复核后再采纳。

6. 接口 API 调用与批量任务

查错流程要真正落地，不能每次复制粘贴。建议写一个 Python 脚本，自动读取网表和报告文件，调用 AI API，输出 Markdown 审查报告。

以下是一个通用模板，实际调用时需要按你使用的模型接口调整。

import requests import json import os import glob API_URL = "https://api.example.com/v1/chat/completions" API_KEY = "your-api-key" MODEL_NAME = "your-model-name" def read_file_text(file_path): with open(file_path, "r", encoding="utf-8", errors="ignore") as f: return f.read() def run_ai_review(prompt, content, max_tokens=4000): headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一名严谨的硬件设计评审工程师。"}, {"role": "user", "content": prompt + "\n\n" + content} ], "temperature": 0.3, "max_tokens": max_tokens } response = requests.post(API_URL, headers=headers, json=payload, timeout=120) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"] def review_directory(review_dir, output_dir): os.makedirs(output_dir, exist_ok=True) for netlist_path in glob.glob(os.path.join(review_dir, "*.net")): print(f"正在审查网表: {netlist_path}") netlist_content = read_file_text(netlist_path) prompt = read_file_text("prompts/netlist_check.txt") result = run_ai_review(prompt, netlist_content[:30000]) output_path = os.path.join( output_dir, os.path.basename(netlist_path) + "_review.md" ) with open(output_path, "w", encoding="utf-8") as f: f.write(result) print(f"审查结果已保存: {output_path}") if __name__ == "__main__": # 按实际目录调整 review_directory("D:/pibox_review/v1.0", "D:/pibox_review/v1.0/outputs")

批量任务建议：

• 每个文件单独调用一次接口，避免上下文过长导致截断。
• 请求之间加time.sleep(1)或time.sleep(2)限速，避免触发 API 频率限制。
• 每次调用完成后立即保存结果，防止服务异常导致数据丢失。
• 增加失败重试机制，捕获requests.RequestException后随机延迟重试最多 3 次。

import time def call_with_retry(prompt, content, retries=3): for attempt in range(retries): try: return run_ai_review(prompt, content) except requests.RequestException as e: print(f"请求失败，第 {attempt + 1} 次重试: {e}") time.sleep(5 * (attempt + 1)) raise RuntimeError("AI 接口调用多次失败")

接口调用注意事项：

• 不要直接把原始网表传上去，建议先截断无关注释信息。
• 上下文窗口有限，大网表要按模块拆分分析。
• 生产环境建议使用本地模型或私有化部署，避免关键设计资料外泄。

7. 资源占用与性能观察

PiBox 查错方案在资源占用上非常克制，这是它区别于图像生成类 AI 应用的最大优势。

• CPU 和内存：处理几 MB 的网表、BOM、DRC 文本，普通办公本完全能胜任，即使使用本地 7B 量化模型，内存占用也以“GB”为单位，但通常不会像图像模型那样吃掉十几 GB 显存。
• 显存占用：如果你调用云 API，本机显存占用为 0；如果本地部署模型，显存占用取决于模型规格，跟“电路板查错”本身无关，属于模型运行开销，需按实际环境观察。
• 速度：API 调用一次分析通常在几秒到三十秒内，取决于文本长度和模型负载。
• 性能瓶颈：大网表、长 DRC 报告会受上下文长度限制。建议控制单次输入在 20KB 到 30KB 文本以内。
• 成本：文本类任务 token 消耗远低于图像生成，一次网表审查大约消耗几千 token，成本可以忽略，但涉及超大工程时仍需控制输入长度。

观察方法：任务管理器里看 CPU 和内存占用，API 调用看返回耗时。没有突然飙高、没有内存溢出，就算正常。

8. 常见问题与排查方法

如上表所示，AI 查错最大的问题不是“能不用”，而是“输出稳定性”和“格式适配”。解决思路就是两条：把输入文件规范化，把提示词模板固定化。

9. 最佳实践与使用建议

9.1 让 AI 当第二评审人，而不是第一评审人

流程建议：EDA 工具先跑 DRC/ERC → 人工快速浏览关键错误 → AI 做网表和 BOM 的二次扫描 → 人工复核 AI 输出 → 修改后重新跑规则。这样 AI 的价值体现在减少人工漏检，而不是替代 EDA 流程。

9.2 提示词模板版本化

建议把提示词文件纳入 Git 管理，每次修改都提交一次。提示词是 AI 查错效果的核心，一旦调好了格式，就不要频繁改动。模板不稳定的项目，输出质量波动会非常明显。

9.3 不要直接传未脱敏的设计文件

对外部 API 服务，建议先把元件名和网络名做脱敏处理。例如将STM32F103C8T6替换成MCU_A，将PA9替换成NET_1。脱敏后的模板仍然保留连接关系，AI 照样能找异常，但敏感信息不会外传。

9.4 AI 输出和原始文件分目录管理

建议每个版本目录下同时保存原始网表、AI 输出报告、人工复核签字表。这样如果后发现设计问题，可以快速回溯是哪一轮评审漏掉。

9.5 第一次使用先做小样本验证

不要在完整五层板项目上直接跑全套 AI 查错，先拿一个简单的最小系统板跑通流程，确认提示词、脚本、输出格式都没问题，再扩展到完整项目。

9.6 涉及版权和授权问题

如果你想把某个开源硬件项目的原理图、网表、DRC 报告交给 AI 分析，先确认该项目许可证允许你复制、修改和处理这些设计文件。对于受版权保护的芯片数据手册内容，不要整本投喂给 AI，只提取必要段落，避免侵犯版权。

10. 总结与后续方向

PiBox 设计日志 02 想传达的核心经验就一句话：AI 在电路设计领域的价值重心，不在“画”，而在“查”。AI 画板，你会得到一张好看的图；AI 查错，你能得到一份按优先级整理好的风险清单。真正高效的硬件开发流程，是先画板、再跑规则、然后让 AI 做交叉审核。

下一步的扩展方向，是在 PiBox 项目里继续完善这几个部分：一是把网表预处理器做成通用工具，支持 KiCad、立创EDA、Altium 三种格式自动转换；二是把 AI 审查结果通过 GitHub Actions 接到 CI 流程，每次提交原理图变更后自动生成审查评论；三是沉淀一份更完整的“AI 硬件查错提示词包”，把运放、电源、MCU、接口防护这几类常见电路模块的检查项单独拆出来。如果你也在折腾硬件设计，建议先拿自己最近的一块板子跑一遍这套流程，看看 AI 能不能发现你漏掉的那根线。