之前用AI 直接连上立创 EDA Pro**，读我的原理图、分析设计电路，但是如果我还想让他翻我自己的知识库、然后告诉我哪里可能有问题。大模型跑在本地，知识库是自己维护的 LLM Wiki，数据全程不出内网。
效果就是：我切到飞书说一句「帮我读一下 yt_iomcu 页的元件」，十秒后 AI 把 82 个元件全部列出来------主控芯片、缓冲器、晶振、LED、阻容，型号、位号、封装一清二楚。
先看这套工作流跟传统方式的差别：
| 对比项 | 传统人工方式 | 飞书 + AI Agent 方式 |
|---|---|---|
| 读一页原理图元件 | 手动逐个点开属性，约 1 小时 | 一句话，30 秒出全表 |
| 8 页原理图整理 BOM | 半天起步 | 几分钟 |
| 芯片设计规则核对 | 翻数据手册 + 人工比对 | AI 自动查本地 Wiki 交叉验证 |
| 阻抗参数计算 | 手算 + 跟板厂来回确认 | AI 从 Wiki 读参数直接填工具 |
| 知识沉淀 | 散落在脑子和文件夹里 | 结构化存进 LLM Wiki，可检索 |
| 数据安全 | --- | 全程本地，原理图不出内网 |
这篇文章把整个搭建过程拆开讲：为什么选 Hermes、框架怎么搭、踩了哪些坑、最终能做什么。
一、为什么用 Hermes，而不是直接调大模型
原因就一条：Hermes 有一套完整的本地知识库系统，而且有持久记忆。
普通的 AI 对话，关了窗口就忘了你说过什么。Hermes 不一样，它有三层「记忆」：
| 能力 | 作用 | 实际例子 |
|---|---|---|
| LLM Wiki 知识库 | 资料自动结构化、建索引、交叉引用 | STM32 电源规范、去耦要求、阻抗参数、6 层板叠构方案 |
| Memory 持久记忆 | 记住环境配置、路径、偏好 | Bridge 路径说一次，之后它自己知道去哪查 |
| Session 会话检索 | 翻历史对话记录 | 「上次那个阻抗结果是多少」直接查 |
AI 来查资料的时候，不是去网上搜通用答案，而是翻你自己整理的知识库。答案的可信度完全不同。
另外 Hermes 本身是多平台网关，飞书、Telegram、Discord 都能接。对我来说最顺手的是飞书------平时工作消息就在飞书上，切过去说句话就能让 AI 干活。
二、框架：三层结构串起飞书和立创 EDA
整个链路分三层，各层职责如下：
| 层 | 组件 | 跑在哪 | 干什么 |
|---|---|---|---|
| ① | 飞书 + Hermes Gateway | Ubuntu 虚拟机 | 收消息 → 调 AI → 回复 |
| ② | Bridge Server（Node.js） | 端口 49620 | 纯透传：AI 的 JS 代码 ↔ EDA 的返回数据 |
| ③ | LCEDA Pro + API Gateway 扩展 | Windows 宿主机 | 执行 eda.* API，120+ 个接口可调 |
第二层的 Bridge 做的事情很纯粹：把 AI 的意图「翻译」成立创 EDA 能执行的 JS 代码。比如 AI 说「读原理图元件」，Bridge 就把 await eda.sch_PrimitiveComponent.getAll() 透传过去，把返回的 JSON 原样传回来。Bridge 本身不做任何数据处理，几百行代码就能跑，出问题也好排查。
启动 Bridge 就一条命令：
node scripts/bridge-server.mjs启动后能看到端口、API 地址、health 检查端点全部列出来：
Bridge 跑起来后，立创 EDA 里的 API Gateway 扩展会自动扫描 49620-49629 端口，连上后「关于」窗口显示 Connected (port 49620)：
连接活跃时，Bridge 日志里持续有 Ping/Pong 心跳：
到这一步就打通了。在飞书里说「读一下工程里的原理图」，AI 通过 Bridge 调 API，返回完整元件清单。比如我的 8 页原理图工程，AI 读出了电源页的全部 71 个元件------DC-DC、LDO、降压模块、阻容，一个不落：
三、踩坑记录：四个坑一个没跑掉
桥搭通是结果，坑才是干货。四个坑全记录：
| 坑 | 现象 | 根因 | 解决方案 |
|---|---|---|---|
| 虚拟机网络不通 | Windows 连不上 VM 里的 Bridge | NAT 模式下绑 127.0.0.1 外部不可达 | Listen Host 改 0.0.0.0 + VBox 端口转发，后来直接换桥接网卡 |
| 双 Bridge 打架 | 另一个 AI 工具的 Bridge 端口冲突 | 两个 AI 共用一份 Bridge | 目录整个复制一份物理隔离，端口自动错开 |
| 沙箱切页失效 | openDocument 返回成功但读的还是旧页 |
API Gateway v1.0.5 沙箱绑定首个打开的文档 | 手动在 EDA 里点页面标签刷新上下文 |
| 字段名对不上 | 返回全是空对象，以为 API 坏了 | 位号字段叫 designator 不是 designation |
先打一个样本看 Object.keys() 再写解析 |
第四个坑多说一句：立创 API 还有几个容易忽略的版本细节，官方文档有但分散------
| API | 3.2.149 版本行为 | 注意点 |
|---|---|---|
create() |
同步，不加 await | ≥3.3.x 变异步 |
search() / getByLcscIds() |
异步，必须 await | 忘了 await 返回 Promise 空值 |
getAll() |
异步，须 await | 只返回当前激活文档的数据 |
console.log |
沙箱里不可靠 | 用 sys_ToastMessage 或直接返回值调试 |
四、现在能做什么
打通之后的实际产出：
| 能力 | 之前 | 现在 |
|---|---|---|
| 单页原理图元件扫描 | 手工 1 小时 | 30 秒 |
| 全工程 BOM 整理 | 半天 | 几分钟 |
| 电气语义检查（VCAP 电容数量、去耦距离、CAN 终端电阻） | 靠人脑记忆，容易漏 | AI 对照 Wiki 逐条核对 |
| 六层板阻抗计算（50/90/100/120Ω 五组） | 手算 + 板厂确认 | AI 读 Wiki 参数填工具，连叠构编号一起出 |
重点说下电气语义检查------这是官方 DRC 做不到的。DRC 只看间距、孔径、丝印重叠这些物理规则，它不知道「这颗芯片的 VCAP 引脚需要 2 颗 2.2µF」「去耦电容要距引脚 5mm 以内」。这种检查必须结合芯片专属知识，而知识就存在本地 Wiki 里。
五、数据不出门
整套方案里我最看重的一点：所有知识和设计数据全程本地。
芯片电源规范、PCB 设计规则、阻抗参数存在本地 LLM Wiki；大模型调用走自己的 API；原理图数据在内网里流转。还没发布的板子原理图，不可能上传给云端通用大模型------但你又确实需要 AI 帮你翻资料、做比对。本地化方案恰好解决这个矛盾。
最后泼盆冷水：工具在进化，但板子最后还是要人来定。AI 查出来的是「疑似问题」，不是「判决书」，人工复核这一步永远不能省。
转载请联系作者 | AI的探索之旅 | 让技术发挥最大价值