AI Agent实战：从零开发嘉立创局部网表分析插件

在硬件设计领域，原理图分析长期依赖工程师的经验积累。而随着 AI Agent 能力的成熟，越来越多的开发者开始尝试用 AI 来辅助 EDA（电子设计自动化）工作流。这篇文章将介绍一位 B 站 UP 主如何借助 AI Agent 从零开发出一款嘉立创 EDA 的「局部网表 AI 分析」插件，以及背后完整的 Agent 驱动开发流程。

在展开之前，有必要先厘清 EDA 究竟指什么。EDA（Electronic Design Automation，电子设计自动化）指利用计算机软件辅助完成集成电路和 PCB 设计的整套工具链，涵盖原理图绘制、仿真、布局布线、网表生成等环节。原理图是电路设计的起点，用符号化的方式描述元器件之间的电气连接关系；而网表（Netlist）则是原理图的机器可读表达，记录了每个网络（Net）连接了哪些元器件的哪些引脚。传统上，工程师需要依靠经验逐一核对连接关系、判断电路功能，这既耗时又容易出错。嘉立创 EDA 是国产免费在线 EDA 工具，凭借与嘉立创 PCB 打样、元器件商城的深度整合，在国内创客和硬件工程师群体中拥有大量用户，其开放的扩展广场也为第三方插件开发提供了土壤。

局部网表分析插件解决了什么痛点

嘉立创 EDA 官方虽然提供了 KeyMe 助手，但存在明显局限——它只能使用 KeyMe 自家模型，且分析对象往往是整张原理图。对于复杂设计而言，把整张图一次性丢给 AI 分析，既浪费 token，也容易让 AI 抓不住重点。

这款插件的核心创新在于局部网表分析：用户可以在原理图上用鼠标框选需要分析的范围，插件会自动生成提示词，并提取对应区域的网表信息交给 AI。这种「按需分析」的方式，让 AI 能更精准地聚焦于设计者真正关心的电路模块。

更重要的是，插件支持自定义任意 AI 模型。在设置界面中，用户可以配置 API 自定义地址、API Key 以及模型名称，摆脱了官方助手只能用单一模型的束缚。这一设计背后，是当前 AI 应用普遍采用的 OpenAI 兼容 API 规范——大多数主流模型服务商（如 DeepSeek、通义、Kimi 乃至各类本地部署方案）都提供了与 OpenAI 接口格式一致的调用方式，因此只要暴露出「地址 + Key + 模型名」三个配置项，插件就能对接几乎所有主流模型，用户可以根据成本、速度和分析质量灵活切换。

插件的实际分析效果

从演示来看，插件的识别准确度相当不错。在一个 ESP32 最小系统板的案例中，AI 准确识别出：天线上有 LED 和电容、晶振旁配置了 12pF 电容、USB 部分的 D+/D- 直接接到 Type-C 连接器，以及启动引脚 GPIO 通过上拉电阻接到 3.3V 电源。这些判断与实际设计完全一致。这里之所以能识别得如此精准，正是因为网表提供了明确的电气连接结构：晶振旁的负载电容（如常见的 12pF、20pF）、启动引脚（如 ESP32 的 GPIO0）通过上拉电阻接高电平以决定芯片启动模式，这些都是嵌入式硬件设计中的经典模式，AI 在拿到结构化网表后能够将其与已知设计范式相匹配。

除了局部分析，插件也保留了分析整张原理图的选项。在另一个案例中，AI 正确识别出该电路是「利用光传感器检测气体质量，经 ESP32-C3 读取数据后上传到上位机」的完整功能链路。

值得一提的是，插件还解决了嘉立创 EDA 的一个原生短板：官方导出网表时只能导出整个网表，无法单独导出选中区域。而这款插件可以自动保存选中区域的网表，并下载为 JSON 文件。

网表 JSON 的结构

生成的 JSON 文件结构清晰：首先指明元器件，然后列出该元器件上对应的网络和引脚编号，将选中的每一个元器件逐一读取出来。此外还附带了制造商信息、参数信息等元数据，这些都能作为上下文交给 AI 进行更深入的分析。之所以选择 JSON 而非传统的网表文本格式，是因为 JSON 的层级结构天然适合大模型解析——键值对形式明确标注了每个字段的语义，模型无需额外推断字段含义，能显著降低理解成本、提升分析准确率。这也是当下 AI 工程中「结构化数据优于纯文本」这一经验的典型体现。

插件的安装与配置

插件已经上传到嘉立创 EDA 的扩展广场，用户可直接下载安装。安装完成后，需要在菜单的「高级 → 扩展管理器」中找到它。

要让插件在菜单中正常显示，还需要进入配置界面，将相关选项全部勾选，这样功能入口才会出现在菜单栏中。

Agent 驱动的插件开发流程

这篇内容真正有价值的部分，其实是作者用 AI Agent 从零开发插件的完整方法论。整个插件的代码几乎都是让 AI 写的，但过程中踩了不少坑，也总结出了一些关键经验。

MCP + 浏览器自动化闭环

在理解这套工作流之前，先要认识其中两个关键技术。MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底推出的开放标准，目的是为大语言模型与外部工具、数据源之间建立统一的通信接口。在此之前，每个 AI 应用调用外部能力都需要自定义对接，碎片化严重；MCP 则像「AI 世界的 USB 接口」，让模型可以标准化地调用文件系统、数据库、浏览器乃至本地软件。作者正是借助 MCP 让 AI 直接安装插件、控制浏览器，把大模型从「只会聊天」升级为「能操作真实环境」的 Agent。

作者搭建了一套相当完整的 Agent 工作流：

• 构建工具：使用 GitHub（3.0 版本工具链）来构建插件；
• 安装部署：通过 MCP（Model Context Protocol）直接安装构建好的插件；
• 界面操作：让 AI 使用 Playwright 打开嘉立创 EDA 网页并登录，自动化操作浏览器；
• 效果验证：借助多模态模型 MiniMax（M3）配合 Playwright 截图，让 AI「看」到浏览器当前状态，判断操作是否成功。

这里的 Playwright 是微软开源的浏览器自动化框架，支持 Chromium、Firefox、WebKit 等主流内核，能够模拟真实用户的点击、输入、截图等操作，广泛用于 Web 自动化测试。在 AI Agent 场景中，Playwright 充当 AI 的「双手」，让模型可以真正操作网页界面。而多模态模型（能同时理解文字和图像的模型）则充当 AI 的「眼睛」——通过对 Playwright 抓取的截图进行视觉分析，AI 得以判断操作是否达到预期效果。

这套闭环的核心思路是：让 AI 不仅能写代码，还能自己安装、自己操作、自己截图验证，形成完整的「写—跑—看—改」迭代循环。这种「操作—截图—理解—修正」的机制，正是 Agent 自主完成复杂任务的核心，也是文中开发流程能够跑通的技术基础。

用 AI 开发插件踩过的坑

作者坦诚分享了几个关键教训，对想用 AI 做工程开发的人很有参考价值：

第一，一定要让 AI 查官方文档。 AI 在写代码时经常「凭记忆」编造 API，导致大量报错。这种现象在业界被称为「幻觉」（Hallucination）——模型基于训练语料的统计规律生成看似合理实则不存在的内容，尤其在面对特定框架、小众 API 时最为明显，因为这些内容在训练数据中出现频率低。解决办法是在提示词中明确要求「请直接查看嘉立创插件 API 的官方文档」，让模型基于真实检索到的文档而非记忆来生成代码，这样能少走很多弯路。

第二，长对话会导致上下文丢失。 随着对话进行，即使做了上下文压缩，AI 仍会忘记之前大部分对话信息。这源于大模型的「上下文窗口」（Context Window）限制——模型一次能处理的 token 数量有上限，当对话超出窗口时，工具往往会通过摘要压缩来保留大意，但压缩过程不可避免地丢失细节。有时它会突然重新从头阅读代码，导致开发过程出现「割裂感」——前后逻辑对不上。

第三，遇到卡死要果断重启。 当 AI 操作浏览器无法继续时（比如无法获取选中原理图信息），最有效的办法是关闭浏览器，让 Agent 通过 MCP 重新打开一次。

第四，让 AI 自己截图验证效果。 作者强调，效果验证要靠 AI 自己截图对比，不满意就持续迭代，这是保证质量的关键环节。

一个值得警惕的细节

作者还提到一个遗憾：最开始打基础的那些对话现在都看不到了，而那些恰恰是最重要的经验积累。他推测这可能是开发工具的一个 bug——对话历史往上滚动时滚不到最早的记录，会话开头之前其实还有历史信息，但界面上无法查看。

这个细节其实提醒我们：在用 AI 做长周期开发时，主动归档关键对话和决策记录非常重要，不能完全依赖工具自身的历史保存机制。事实上，业界已经开始探索用「记忆」（Memory）机制来缓解这一问题——将关键决策、项目约定、踩坑经验沉淀为持久化的知识文件（如项目根目录下的规则文档），让 Agent 在每次会话开始时自动加载，从而在跨会话、跨窗口的场景下保持一致性。

总结

这款局部网表分析插件本身解决了嘉立创 EDA 的两个实际痛点——局部分析能力和自定义 AI 支持，而且代码完全开源。更有意思的是它背后的开发方式：一个非专业插件开发者，借助 MCP、Playwright 和多模态模型搭建的 Agent 闭环，完成了从需求到上线的全流程。

对于硬件工程师而言，这类 AI 辅助 EDA 工具正在降低电路理解和调试的门槛；对于开发者而言，这套「Agent 自动写代码 + 自动验证」的实践，也提供了一个可复用的工程范式。当然，AI 开发的可靠性、上下文管理等问题仍有待成熟，但方向已经相当清晰。

核心要点