原理图不该只是给人看的：我怎样让 LLM 参与一次真实的软硬件协同设计

设计新 PCB 板的那段时间，我的桌面上经常同时开着嘉立创EDA、几份 datasheet、固件工程和一个 LLM 网页对话框。每画一个功能块，我就把 datasheet 发给 LLM，请它再核对一遍。它读手册很快，也很愿意列检查项；真正拖慢讨论的，反而是我必须不断维护一长串 prompt，解释“这个项目是做什么的”“这个芯片的设计指标是什么”，有时还得补充：“这个 EN 在另一页”“那组 I²C 属于受控电源域”“这两个地只应该在这里汇合”。

我很快意识到，问题不是模型不够强，而是它看不到当前原理图的完整连接。我需要从原理图导出一份文本清单，逐项写明器件、引脚、网络和功能分区。它既要能搜索，也要能比较两版之间的变化。后文把它简称为“连接清单”。

讲一下项目背景：DexSense_Verify 是 UltimateCollectionBT 的后续验证平台；UltimateCollectionBT 则是我们在 RoboPocket 工作中使用的磁编码器—手机接口。到了这一代，我想重点验证 BQ 系列电量计、低静态电流（Iq）的常开电源、可编程 Buck-Boost 和 nRF 超低功耗平台能否可靠地组合在一起，并把可编程输出、状态采集、低功耗蓝牙（BLE）控制和自动测试接进同一套系统。

结果比我预想得还顺利：第一版 PCB 回来后，电量计、常开电源、Buck-Boost、nRF 主控、状态采集和 BLE 通信这些主要链路都跑了起来。

下面想讲的，就是我怎样把原理图整理成 LLM 能搜索的连接清单，再用它检查原理图和 PCB、开发固件、安排测试，尽量在打样前多发现一些问题。

这次开源的工具组就叫 SchematicLens。这个名字像是给 LLM 戴了一副近视眼镜，让它过滤掉 EDA 原始文件的噪声，看清楚原理图的每一条连接。

传统流程中，工程师平时是怎么画原理图的

我以前也是按最标准的流程画板：先读芯片手册和参考设计，把系统拆成电源、主控、采样、通信几个功能块；再去 EDA 里放器件、连网络、补阻容、选封装，最后跑 ERC，自己从头到尾检查一遍。

真正做起来当然没有这么线性。画到一半发现某个引脚不能耐受当前电压，要回头加电平转换；布 PCB 时发现元件不合适，又要去查手册、改原理图；等板子打样回来，才发现因为没仔细读完 datasheet，少加了几个下拉电阻或者去耦电容，无力回天。

当然，最累的还是脑子里必须一直维护一份没有写出来的项目文档：

这个 EN 必须默认拉低，因为主控复位期间输出不能自行开启；
这两条地最终相连，但连接点必须可追踪，不能让大电流回流经过采样参考；
这个 0 Ω 电阻表示电源域边界，不只是为了凑 BOM；
这个器件虽然挂在 I²C 上，却属于受控电源域，关电前要先反初始化；
这个封装方向是为背面装配准备的，不能只看原理图引脚编号。

EDA 很擅长保存“哪里接到哪里”，却不会自动保存“为什么这样接”。这些理由会散在网络名、原理图上的功能分区、datasheet、评审记录、固件引脚表，以及我的记忆里。板子小的时候还能靠记忆；页面、电源域和器件一多，每次和别人——或者和 LLM——讨论，都得先重新讲一遍背景。

人工检查也一样。我会放大页面看导线连接、搜索元件位号（例如 U3、R12）、去 PCB 里高亮网络，再切回手册查引脚。但是看出一个局部错误不难，难的是一遍看完整张板子：哪些未上电器件还吃着高电平，哪些 EN 没有确定的上电状态，哪些所谓的“地”其实经过了大电流回流但是仅仅用了 8 mil 线宽，哪一份固件定义又落后于最新原理图。

这一段工作很适合交给 LLM：它读资料快，也不会嫌逐个检查几十个元件、几百个网络烦。问题只有一个——在开始检查之前，它必须先拿到一份准确、完整、可以全文搜索、也可以像代码一样做 diff 的电路连接清单。

传统原理图流程里，很多设计理由只存在于工程师脑中

LLM 能分析电路，EDA API 也能读，但中间还少一步

我最早的做法，就是直接对 LLM 说：“这个 IC 的外围电路是这么连的，有没有问题？”检查单个芯片时很好用，但问题一旦跨页、跨电源域，我要补充的背景就会成倍增加。

而且局部电路没问题，不等于全局没问题。页面外的跨页网络标签可能才决定最终连接；这种口头说明也没法做 diff，每次修改后还要重新解释一遍。

后来我又试着让 Agent 直接读 EDA API。连接虽然准确了，但它拿到的是图元、坐标、属性、引脚、导线和一堆内部 ID。为了回答“这条受控电源线上挂了哪些器件”，Agent 得先逐页查询组件、引脚和网络标签。查询结果很快占满一次对话能容纳的信息；还没真正开始检查，前面读过的内容就可能丢失，只好重新查询。

低层 EDA 对象与可读器件、引脚、网络清单的上下对比

很多人会直接让 LLM 一步到位生成电路图，这是错误的

这里很容易走到另一个极端：给 EDA 接上 MCP Server 或 API Gateway，马上让 Codex 放完器件、拉完整张图。问题不在 MCP。它解决的是“模型怎样调用 EDA”，不会自动补上对网络、吸附点、连接结点和原理图排版的可靠理解。一次任务同时要求模型决定电路、生成图元、处理坐标，还要把页面画得便于工程师阅读，已经超出了当前 LLM 适合一次完成的能力边界。

我见过一个很直接的反例：Agent 看起来已经把导线全部接好，几根本应独立的网络却落在同一个连接点，EDA 因此把它们并成了同一网络，电气上已经短路。从截图看，这可能只像一次普通交叉。视觉模型可以辅助发现明显的文字重叠和混乱走线，却不能仅凭像素证明 EDA 内部是否存在连接结点，也不能证明网络标签最后解析到了哪里。

图面本身也可能失去可读性：文字压在线上，长导线穿过多个功能块，网络标签散落在页面各处。即使没有立刻产生短路，人也很难继续评审和维护。

所以，正确的做法是把“操作 EDA”和“理解、验证连接”分开。Agent 先读取当前工程并生成连接清单，再围绕明确约束提出范围有限的修改；修改后重新导出并比较网络，运行相应的 ERC / DRC。MCP 或者 EDA 提供的 API 只提供操作入口，连接清单、回读和验证负责确认实际结果。

基于这种思路，我们的工具分为两部分：

嘉立创EDA Skill 与 API Gateway 负责连接正在打开的工程、读取当前文档；经我授权后也可以修改，并在修改后重新读取，确认实际结果；
可读网表工具 负责把器件、引脚和网络关系整理成一份人和 LLM 都能搜索的 Markdown / JSON 文本。

“可读”不是把 JSON 缩进得漂亮一点。第一个转换器保留嘉立创EDA .enet 中的真实连接：有哪些器件，每个引脚接到哪条网络，器件的型号和值是什么。第二个提取器读取原理图上的矩形框和标题，把器件归入“常开电源”“模拟设定”等功能区。最终文档既不丢真实连接，也保留了我在图面上做的分组。比如图中的“SoC”“SCB_3V_AON”和“Type-C & Protection”几个模块，让 LLM 检查的时候可以抓主要矛盾。

原理图上的矩形框和标题为导出的连接补上功能分区语义

它读起来更像下面这样。AON 指待机时也有电的常开区域，RUN 指设备工作时才上电的区域：

模块：AON 电源与系统控制
  Ux / MCU
    VDD  -> AON_3V3
    SDA  -> AON_SDA
    SCL  -> AON_SCL
    EN3V -> RUN_ENABLE

模块：受控运行域
  Uy / 可编程电源
    VIN  -> SYSTEM_IN
    EN   -> RUN_ENABLE
    SDA  -> RUN_SDA
    SCL  -> RUN_SCL

约束：
  RUN_ENABLE 上电默认低
  关闭 RUN 区域供电前，先停止总线通信并关闭输出
  短接符和 NetTie 两侧的原始网络名都保留
  0 Ω 电阻两端分别接到哪条网络也保留

至此，模型可以直接搜索一条网络接到了哪些引脚，也可以按功能区检查供电，并把原理图连接和固件引脚定义逐项对上。

从当前嘉立创EDA工程生成连接清单，再交给 Agent 检查的流程

这套分工听起来只是一个实现细节，实际却改变了我提问的方式。过去我会问：“这里的电路这么画，有没有问题？”后来我可以问：“找出所有 RUN 区域的器件，检查它们断电后是否仍可能被 AON 区域的信号线灌电，并按 datasheet 逐项核对每个 I/O 是否允许这种情况。”后一个问题具体得多，也更容易验证。

LLM 辅助外围电路设计：以 DexSense_Verify 为例

在这个工作中，我要把单节电池充电、BQ 电量计、低 Iq 常开电源、受控运行电源、可编程 Buck-Boost、模拟量设定与采集、状态检测和 nRF BLE 主控塞进同一块验证板里。大部分都是全新的体验：电量计、常开电源、DC-DC 转换器和 ADC 我以前都没用过，甚至连 nRF54L15 所在的 nRF 开发平台也是第一次用。我比较贪心，想用第一版板子就搞清楚，这些东西能不能一起低功耗、稳定地工作。

刚开始还只是普通的 LLM 网页对话：我给它目标，它帮我找元件；我给它 datasheet，它帮我计算外围电路、找出手册里的限制。问题也正如开头所说，每画一个新模块，我都要把旧背景重新贴一遍。连接清单和 EDA 接口接上以后，这个节奏才变了：图一更新，Agent 自己读取当前连接，再围绕这一版做检查。

最先省下时间的是外围电路设计。它们看起来不复杂，却很擅长让一块板在上电以后毫无反应。比如 USB-C 输入的 CC1、CC2 要各接一个 5.1 kΩ 下拉电阻，让上游 USB-C 电源识别这块板是用电设备并提供 5 V；SWD 接口的 VTref 应连接目标 MCU 的 I/O 电源，只供调试器判断逻辑电平，不是目标板的电源输入；受控电源的 EN 需要有硬件下拉，不能指望固件启动以后再把它拉低；DC-DC 的电感选择是否合适，能否承载满载的大电流，电容使用 X5R 还是 X7R、耐压多少，等等。

这些问题单独看都不难。麻烦在于它们散在不同手册的角落，甚至藏在零散的标准里（顺便吐槽一句：现在还有不少 USB-C 设备不加 5.1 kΩ 下拉，最后只能换 USB-A 转 USB-C 线才正常工作）。LLM 对这些常见规范比较熟，也适合批量核对 datasheet 中分散的限制。

基于这些需求和 LLM 的能力边界，我们形成了一种朴素的分工：凡是可以穷举、可以进入 LLM context 的，尽量让 Agent 做；凡是要摸板子、看空间、承担风险的，最后还是我来定。

评审不只发生在原理图

到了 PCB 阶段，我最先盯的是开关回路、输入输出电容和大电流铜皮。Agent 接着会追问一些我容易在赶进度时略过的问题：这个 0 Ω 电阻的封装真的能承受主要回流吗？电流采样电阻（RSense）两端单独引出的 Kelvin 采样线，有没有绕开大电流回流区域？MOSFET、电感和采样电阻产生的热，最后准备往哪片铜、哪组过孔散？

DRC 并没有能力发现这样的问题。DRC 能发现线宽低于预设规则，却不知道它是不是主要回流；两个点在电气上都叫 GND，也不代表中间那段铜适合作为精密采样参考。让 Agent 同时看到焊盘属于哪条网络、走线和过孔怎么走、这个区域负责什么，它就会不断追问：“电流从哪里来，最后又从哪里回去？”

因此，在这部分，我和 LLM 形成了又一种有趣的分工：Agent 先根据连接清单和当前 PCB 列出需要检查的大电流路径，再从 EDA 导出相关铜皮和过孔，建立 PCB 的直流导电模型，用有限元法求电流密度和电势分布，寻找电流拥挤和压降瓶颈。这里做的是 PCB 直流电流场与压降 FEM，不是热 FEM；温升仍然要结合损耗、材料、边界条件和实测另行判断。仿真指出可疑位置后，我负责修改 PCB，再让 Agent 重新导出复查。

PCB 直流电流场与压降 FEM 用于定位电流拥挤和电阻瓶颈

第一次打样跑通了，示波器还是要接

DexSense_Verify 第一版 PCB 上电后，BQ 电量计、低 Iq 常开电源、可编程 Buck-Boost、nRF 主控、状态采集和 BLE 通信都能工作。采用 OPA333 和 10 kΩ 栅极驱动电阻时，控制环路没有出现振荡，效率、调节精度和重复性也达到了这次验证的目标。

但是，第一次使用较小的栅极驱动电阻时，控制环路出现了振荡。LLM 从板载 ADC 读回的电压和电流并不能体现这个问题，是我在用示波器复测时才发现的。

这就是现在 LLM 的局限性：它无法代替人类完成实际调试和动态分析。电源纹波和硬件时序，仍然要由我们来判断。

让固件开发 Agent 直接读取同一份连接清单

以前让 LLM 写硬件相关固件，第一步总是我手工整理引脚表，再解释哪条 I²C 上挂了谁、哪个 EN 反相、哪个外设会先掉电。原理图一改，这份“给软件看的版本”又要重新抄。

这次我没有再抄一份。固件 Agent 直接读取设计阶段使用的同一份连接清单，从中确认：

常开区域和运行区域各有哪些电源和总线；
各使能、中断、数据就绪和温度采样信号接到哪个 MCU 引脚；
DAC 设置的是什么量，ADC 测量的是什么量，程序读回的电压或电流分别代表什么；
哪些器件必须等供电稳定后再初始化，关机前又要先停止哪些通信；
关机时怎样依次把输出归零、关闭前级电源，并确认输出电容已经放电。

这次我把范围、接口和安全状态说清楚后，当时使用的 GPT 5.6-Sol Ultra 不到四小时就完成了第一版代码，代价是消耗了我大约三分之一的周额度。设备驱动、BLE 控制、状态上报、电脑端界面和自动测试都跑起来了。

这套工具组最后应该包含什么

做完以后，我把这套工具组整理成了五项：

组件	作用
只读网表导出器	通过 API Gateway 从当前嘉立创EDA原理图导出 `.enet` 快照
可读网表转换器	将器件、引脚、网络和属性整理为 Markdown / JSON
功能分区提取器	根据原理图上的矩形框和标题，判断每组元件属于哪个功能区，并记录短接符和 NetTie 两侧的网络名
合并工具	把真实引脚连接和功能分区合成一份文档，供电路检查、固件开发和测试使用
`design-from-readable-circuits` Skill	规定 Agent 怎样只读连接当前工程、怎样核对 datasheet、哪些修改需要授权、改完后怎样重新读取确认，以及怎样把引脚和开关机顺序交给固件

这套工具做三件事：从当前 EDA 工程读取最新连接，把连接整理成容易检查的文档，再规定 Agent 何时只读、何时查手册、哪些修改需要授权，以及改完后怎样确认。它不是“自动画板神器”。SchematicLens 仓库里还放了一份示例和转换测试，别人可以先拿自己的 .enet 文件离线试用，不必一开始就允许 Agent 修改 EDA 工程。

PCB 直流电流场与压降 FEM 会放在独立配套仓库 SchematicLens PCB，其中包括几何处理、求解、可视化代码和示例。

最后拍板的仍然是我

Agent 可以把网络逐条追完、把手册读完、把测试再跑一遍，但最后拍板的仍然是我。API 可能读错页面，EDA 工程也可能落后于桌上的实物；直流电流场模型可能漏掉实际铜厚、过孔和连接器接触电阻，温升判断还会受装配与散热边界影响。凡是涉及默认状态、限流、温升和故障关断，我都会回到 datasheet、PCB 和测量结果上确认。

结语

这次真正省下来的，不是我在 EDA 里拖动几根线的时间，而是我反复向 LLM 解释同一块电路的时间。线还是得自己拉。不过，如果借助 LLM 的辅助，能让我有“照这个办法画板，第一版就有机会跑通”的预期，画板子的心情就不一样了。

以前，每换一个对话、每开始一段固件、每出现一个异常，我都要从“这个项目是做什么的”重新讲起。现在，同一份连接清单既能用来检查原理图，也能核对固件引脚和生成测试项目；需要确认最新状态时，Agent 再从当前 EDA 工程重新导出。

LLM 还是会猜错，我也还是要接示波器。但下一次讨论，不必再从“这根线到底接到哪里”开始。对我来说，这就等于直接和电路对话。

关于本文的复盘依据

为了核对本文中的时间线和实际效果，我让 Codex 交叉检查了对话记录、嘉立创EDA的自动保存记录和本地缓存。

作者与引用

作者：周方圆，上海交通大学 / 上海创智学院
ORCID：0009-0006-0747-7671
联系邮箱：[email protected]

项目谱系相关论文：Junjie Fang, Wendi Chen, Han Xue, Fangyuan Zhou, Tian Le, Yi Wang, Yuting Zhang, Jun Lv, Chuan Wen, and Cewu Lu. “RoboPocket: Improve Robot Policies Instantly with Your Phone.” arXiv:2603.05504v2 [cs.RO], 2026.

本文地址：https://uimicro.com/blog/schematic-lens/

请通过以下方法引用本文：

周方圆（Fangyuan Zhou），“原理图不该只是给人看的：我怎样让 LLM 参与一次真实的软硬件协同设计”，UIMicro Blog，2026，https://uimicro.com/blog/schematic-lens/。

或者使用 BibTeX 条目：

@misc{zhou2026schematiclens,
  author       = {Fangyuan Zhou},
  orcid        = {https://orcid.org/0009-0006-0747-7671},
  affiliation  = {Shanghai Jiao Tong University; Shanghai Innovation Institute},
  email        = {[email protected]},
  title        = {原理图不该只是给人看的：我怎样让 LLM 参与一次真实的软硬件协同设计},
  year         = {2026},
  howpublished = {UIMicro Blog},
  url          = {https://uimicro.com/blog/schematic-lens/},
  note         = {Accompanying projects: https://github.com/UIMicro/schematic-lens and https://github.com/UIMicro/schematic-lens-pcb}
}