做硬件最怕的不是画错一根线而是一版原理图看起来完整、投板回来却通电就冒烟。最近在推进 PiBox 这个开源硬件项目时我们被电气规则检查、网表核对和 BOM 比对反复折磨也顺手试了试“让 AI 直接画电路板图”的方案结论很明确别用 AI 画电路板了它画出来的图看着像那么回事实际连接关系完全不可信真正值得做的是拿 AI 做设计后的查错和审查。这篇文章就基于 PiBox 设计日志 02 的实践思路把“AI 辅助电路查错”的完整流程、提示词模板、脚本化接入方法和排查边界整理出来。如果你正在画板、调板或者准备投板建议直接收藏。整篇文章要解决三个问题AI 查错到底能查什么、怎么查、哪些坑不能踩。先说结论AI 查错不能替代 EDA 工具的 DRC/ERC也不能替代人工原理图评审但它非常适合做网表异常识别、BOM 一致性核对、DRC 报告归类排序、经验性设计规范检查这四类工作。而且它的硬件门槛比大多数人想象的低不需要 GPU普通办公电脑就能跑文本型任务占用的资源几乎可以忽略。1. PiBox 查错方案核心能力速览能力项说明项目背景PiBox 开源硬件设计日志系列本文为第 02 篇重点讨论 AI 在电路板设计查错环节的落地方式核心定位AI 不作为画板工具而是作为设计评审辅助工具定位是“第二双眼睛”主要功能网表异常审查、BOM 一致性核对、DRC 报告解读归类、经验性设计规范检查支持输入原理图网表KiCad/立创EDA/Altium 导出的 netlist 文本、BOM 表格、DRC 报告文本、设计说明文档硬件要求CPU 8GB 内存即可不需要独立显卡API 调用模式下本机几乎无算力负担运行方式本地命令行 Python 脚本、Jupyter Notebook 分析或直接调用大模型 API是否支持 API支持OpenAI、Claude、本地 Qwen 等模型均可通过通用接口接入是否支持批量任务支持可批量读取多个网表/DRC 文件按目录遍历并输出问题清单是否需要 GPU不需要文本类任务对显存无明确依赖如果使用本地大模型则以所选模型规格为准适合场景PCB 投板前自检、硬件设计评审、BOM 备料核对、DRC 报告长篇人工阅读替代不适合场景代替 EDA 工具做精确电气规则检查、代替人工做最终签字放行、AI 直接生成可投板原理图表里的分工很关键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 基础环境清单项目要求操作系统Windows / Linux / macOS 均可CPU双核以上推荐四核普通办公本足够内存8GB 以上16GB 更稳视网表文件大小而定GPU非必需如果本机部署 7B 级大模型再单独考虑显卡规格Python3.9 及以上EDA 工具KiCad 或立创EDA用于导出网表和 DRC 报告AI 模型OpenAI / Claude / 本地 Qwen 等任一支持文本对话的模型API Key使用云端 API 时需要本地模型不需要4.2 Python 依赖核心依赖只有两个requests用于调用 APIpandas用于处理 BOM 表格openpyxl或xlsxwriter用于 Excel 读写。# 安装依赖Windows 下同样适用 pip install requests pandas openpyxl xlsxwriter4.3 导出网表以 KiCad 为例打开原理图点击菜单文件 - 导出 - 网表。选择格式为KiCad或Spice格式。导出后得到.net后缀的文本文件。用文本编辑器打开确认内容可读通常包含元件声明和网络连接两部分。立创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))操作步骤准备netlist_check.txt提示词模板。将网表内容作为文本输入。让 AI 输出问题清单格式要求问题类型、网络名/元件位号、可能影响、建议动作。提示词模板示例你是一名资深硬件设计评审工程师。下面是一份原理图网表请检查并列出所有可疑问题。 关注点 1. 只连接了一个节点的网络单点网络。 2. 元件引脚是否出现悬空在网表中没有任何连接。 3. 电源网络 VCC/GND 之间是否出现直接短接风险。 4. 网络命名是否不一致例如有时叫 VCC_3V3有时叫 VCC导致预期外断开。 输出格式 ### 问题 1 - 问题类型 - 网络/元件 - 风险等级高/中/低 - 详细说明 - 建议处理方式 网表内容如下 {这里粘贴网表内容}预期结果AI 能列出网表中等价网络的连通关系指出像R1的 pin 2 未在任何 network 中出现这类问题。判断成功标准至少能发现一个人工容易被忽略的悬空引脚或单点网络。输出中的位号、引脚编号能对应到原始网表。误报控制在 30% 以内超过这个比例说明网表格式不适合直接投喂需要做预格式化。常见失败原因网表格式包含过多二进制或非标准数据模型无法解析。网表太大超出模型上下文窗口这时需要分段。提示词没有限定输出格式导致结果散乱难以读取。5.2 测试 2BOM 一致性核对测试目的让 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操作步骤读取 BOM 的 CSV 内容。将其转换为 Markdown 表格再交给 AI。要求 AI 对比同一网络或同一电路模块的元件规格指出异常。提示词模板示例以下是一份电子料 BOM请检查并输出潜在错误。 检查项 1. 同类位号例如同为去耦电容的封装是否不一致。 2. 电阻阻值标注是否与常见电路用法一致例如上拉电阻写成 10k 但丝印阻值误标为 1k。 3. 电容耐压值是否过低如果电路中有 12V 电源请检查是否有 6.3V 耐压的电容被用于该电源域。 4. 数量是否与位号数量匹配缺失位号或重复位号。 5. 替代料之间的温度等级、精度、封装是否兼容。 BOM 内容 {这里粘贴 BOM 的 Markdown 表格}预期结果AI 能识别出R1和R2都是 10k 电阻但一个封装 0603、一个封装 0805 这种不一致并提醒确认是否有意设计。判断成功标准位号和参数对应关系正确。建议是否合理可执行。特别要注意 AI 可能会把“封装不一致”误报为错误实际上双封装可能是设计需要人工复核时要核实原理图封装是否确实不同。5.3 测试 3DRC 报告解读与优先级排序测试目的DRC 报告往往有几十上百条告警AI 负责去重、归类、排序。输入素材KiCad 导出的.rpt报告文本。操作步骤将 DRC 报告全文粘贴给 AI。让 AI 按“短路类、间距类、钻孔类、丝印类、未连接类”分类。要求 AI 按照“可能导致断板/短路”高优先级在前输出。提示词模板示例下面是一份 PCB 设计规则检查 DRC 报告请完成以下任务 1. 去除重复条目。 2. 按故障类型分类短路/间距/钻孔/丝印/未连接/其他。 3. 按风险等级从高到低排序。 4. 对每一条用一句话解释为什么会触发方便新手工程师理解。 输出格式 | 序号 | 类型 | 风险等级 | 位置/网络 | 原始信息摘要 | 可能原因 | 输出内容 {这里粘贴 DRC 报告}预期结果AI 能输出一张分类排序表优先展示短路和未连接问题弱化丝印层误报。判断成功标准分类数量准确无漏项。风险等级排序接近 EDA 工具自带过滤的默认结果。解读文字简洁适合放进评审记录。常见失败原因DRC 报告包含坐标数据过多上下文被无关信息占满。模型分不清“warning”和“error”需要在提示词里强调“error 优先”。报告是 PDF 或图片格式需要先转成文本。5.4 测试 4经验性设计规范检查测试目的EDA 工具不会告诉你晶振下面不要走数字信号线、去耦电容要靠近电源引脚这些经验性规则靠 AI 补位。输入素材一份简要的板卡设计说明包括电源拓扑、主要芯片布局、关键信号走向。操作步骤将设计说明整理为 Markdown 文本。配置“设计规范检查”提示词。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, encodingutf-8, errorsignore) as f: return f.read() def run_ai_review(prompt, content, max_tokens4000): headers { Authorization: fBearer {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, headersheaders, jsonpayload, timeout120) 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_okTrue) 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, encodingutf-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, retries3): 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 胡编引脚编号网表格式不标准或提示词缺少约束检查原始网表是否为人可读文本先做格式转换把网表整理成 Markdown 表格再投喂输出问题清单无法看懂没有限定输出格式检查提示词里是否定义了结构固定使用“问题类型 / 元件位号 / 风险等级 / 建议”格式每次结果不稳定temperature 设置过高查看 API 参数配置降低 temperature 到 0.2 或 0.3网络超时或者返回 429撞上 API 频率限制查看响应头和日志增加 sleep 间隔和重试逻辑大网表被截断上下文长度超限统计输入 token 数按模块拆分网表分段审查很多误报AI 对非标准格式理解不足对比原始标准格式建立网表预处理器转成统一模板本地模型效果差模型参数量小或未量化调优评估生成质量优先用 API 做高难度审查本地模型做简单分类DRC 报告导入后乱码原文件编码不是 UTF-8检查文件编码在 Python 里用encodinggbk或errorsignore读取投板后仍存在 AI 未发现的问题AI 只做经验性扫描不保证覆盖全部物理规则对照 EDA 的 DRC/ERC 结果投板前必须跑完整 EDA 规则AI 结果只参考如上表所示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 能不能发现你漏掉的那根线。