我平时会把 AI 用在固件、驱动和工具链开发里，但到了硬件这一侧，总有一段上下文需要自己补。
模型知道 STM32F407 有哪些外设，却不知道我这块板上的 PA4 已经接了什么；它能解释 CAN 收发器，却不知道当前工程有没有装终端电阻；它也可以画一棵漂亮的电源树，但如果没有实际网络和器件引脚，那棵树很可能只是合理猜测。
把整张原理图截成图片发过去，只适合讨论局部。工程一旦出现层级页面、多单元器件、隐藏电源脚、DNP 和核心板/底板组合，截图就很难提供完整上下文。
所以我做了 SchemCP：在本地只读解析嘉立创 EDA 专业版 .epro2 工程，再通过 MCP 把结构化、可追溯的原理图信息交给 AI。
flowchart LR
EPRO2[".epro2 原理图工程"] --> CORE["核心板上下文"]
ENET[".enet 导出网表（可选）"] --> CORE
EPRO2B[".epro2 原理图工程"] --> BASE["底板上下文"]
ENETB[".enet 导出网表（可选）"] --> BASE
CORE --> MCP["SchemCP<br/>本地只读解析"]
BASE --> MCP
MCP --> FACT["工程事实<br/>页面 · 器件 · 引脚 · 网络"]
MCP --> CANDIDATE["规则候选<br/>接口 · 电源 · 时钟 · 连接器"]
MCP --> LIMIT["证据边界<br/>诊断 · DNP · 未验证项"]
FACT --> AI["AI 工程上下文"]
CANDIDATE --> AI
LIMIT --> AI
AI --> WORK["固件规划 · 设计评审<br/>测试文档 · 故障分析"]一、SchemCP 解决的不是“看图”，而是上下文缺口
一份真正能帮助嵌入式开发的原理图上下文，至少要回答下面几类问题：
| 上下文 | AI 应该拿到什么 | 可以继续做什么 |
|---|---|---|
| 工程结构 | 页面、层级实例、器件所在功能页 | 快速定位电源、主控、通信和接口 |
| 器件身份 | 位号、型号、MPN、装配状态、完整引脚 | 查 Datasheet、BOM、DNP 和替代料风险 |
| MCU 资源 | 实际连接的 GPIO、时钟、复位、BOOT、调试口 | 规划 CubeMX、BSP 和外设初始化顺序 |
| 接口关系 | UART、I²C、SPI、CAN、USB、Ethernet、SDIO 等候选 | 建立驱动边界，检查信号是否完整 |
| 电源上下文 | 输入、保护、转换、负载开关、隔离域和负载域 | 做上电顺序、回灌、压差、热耗散审查 |
| 装配上下文 | DNP、0Ω 电阻、跳线和 Variant | 决定某个接口在当前板型上是否真的成立 |
| 多板关系 | 连接器、针数、候选针序和已确认映射 | 把核心板 GPIO 追到底板外设 |
| 证据状态 | 工程候选、网表确认、未验证项和诊断 | 防止模型把推断写成设计事实 |
这也是 SchemCP 和普通图片识别的区别。它不是让 AI “看起来懂了”，而是给模型一个可以查询、分页、交叉核对的工程数据源。
SchemCP 当前读取的是嘉立创 EDA 专业版 .epro2 原理图工程。它不读取 PCB，不修改工程，也不替代 ERC、Datasheet 核对和工程师评审。
二、它具体能提供哪些信息
1. 工程、页面和层级
SchemCP 可以先列出工程摘要、页面树和实例上下文，再按页面查询器件。这样 AI 不必一次吞下整份原理图，而是先建立地图，再进入某一页追网络。
对于层级复用工程，这一步尤其重要。同一个基础页面可能被多个实例复用，位号和属性也可能被覆盖；只看基础页面，很容易把默认对象当成实际装配对象。
2. 器件与完整逻辑引脚
查询结果会保留位号、器件标题、制造商、MPN、立创商城编号、装配状态和引脚信息。多 PART 的逻辑器件会被合并，分离电源单元和显式隐藏引脚不会因为不在主符号旁边就被丢掉。
这类上下文适合用来检查：
- MCU 电源脚、VCAP、VREF、VBAT 是否进入完整引脚清单；
- 哪些器件是 DNP，哪些属性仍然缺失；
- 同一位号的多个单元有没有被重复统计；
- 器件标题、制造商料号和商城料号是否互相冲突。
3. 接口、电源、时钟、复位和 MCU 占用
SchemCP 会根据实际接触导线的引脚整理接口候选，而不是看到 MCU 有某个复用功能就断言工程已经用了它。缺少必要信号时，接口会保留为 PARTIAL_CANDIDATE。
电源树也遵循相同原则：从明确的网络和器件引脚出发，区分输入、转换、负载和隔离域；时钟只整理外部晶振和相关网络，不猜 MCU 内部 PLL；复位和启动路径只描述板外连接，不代替芯片内部逻辑。
4. .enet 网表绑定
普通查询只提供 .epro2 也能工作；如果同时提供对应的 .enet，SchemCP 可以把几何/标签候选与导出网表端点进行比较。
这一步的意义不是把结论包装成“100% 正确”，而是让 AI 知道当前依据属于哪一层：
- 工程候选：从
.epro2的页面、图元、导线和标签编译而来； - 网表连接：某个器件引脚在已绑定
.enet中连接到指定网络； - 未验证电气真值：文件来源、版本绑定或最终硬件正确性尚未被证明。
5. 核心板、底板与扩展板装配
多个工程可以分别打开，再组成同一个装配上下文。SchemCP 会列出连接器候选，但不会只因为两个连接器都是 40Pin 就自动确认它们相连。
实际插接还需要人工确认连接器位号、1 脚方向、上下板视角和镜像关系。确认以后，AI 才适合把“核心板 MCU 引脚”继续追到“底板外设”。
三、真实案例：天空星核心板 + 筑基学习底板
为了确认上面的能力不是停留在演示数据，我使用了两套真实工程：
- 核心板：立创梁山派·天空星开发板；
- 底板：天空星·筑基学习板。
两块板各自提供 .epro2 与同日导出的 .enet。四个源文件只作为本机解析样本使用，没有复制进网站仓库。下面不铺满几百个器件和引脚，而是只保留 AI 在后续开发中最有价值的上下文。
1. 工程上下文卡
| 项目 | 核心板 | 底板 |
|---|---|---|
| 工程规模 | 9 页、7 个层级实例 | 20 个平铺功能页 |
| 主要角色 | STM32F407 最小系统、调试、存储、排针 | 电源、通信、传感、音频、电机和人机接口 |
| 带位号器件 | 103 | 619 |
| BUS | 15 组、102 个入口 | 无显式 BUS |
| DNP | 0 | 25 |
| 网表端点 | 426 个已连接引脚 | 1,879 个已连接引脚 |
| 网表比较 | 层级投影存在重复和差异 | 1,879 / 1,879 精确匹配 |
这个对照先告诉 AI 两件事：底板可以较高置信度按网表追端点；核心板虽然能读取完整 MCU 和板载资源，但涉及层级匿名网和跨页连接时必须保留疑问。
2. 核心板上下文卡
主控是 STM32F407VET6，LQFP-100。100 个逻辑引脚已经合并并绑定网表，但这里不需要在正文列出 100 行；AI 真正需要先拿到的是资源分组：
| 资源 | 已解析上下文 | 对开发的直接意义 |
|---|---|---|
| 系统时钟 | PH0/PH1 接 8 MHz 晶振；PC14/PC15 接 32.768 kHz 晶振 | 配置 HSE、LSE 和时钟源前有明确外部条件 |
| 调试 | PA13/PA14 为 SWDIO/SWCLK，PB3 为 SWO，NRST 引出 | 能生成下载、调试和日志接线说明 |
| 调试串口 | PA9/PA10 引到 H1 | 可作为早期启动日志候选 |
| USB FS | PA11/PA12 接 USB_FS_N/P | 提醒固件保留 USB 复用资源 |
| 板载 SPI Flash | PA4–PA7 接 GD25Q32 | 底板复用这些针脚时必须检查冲突 |
| 板载 TF 卡 | PC8–PC12、PD2、PD3 接 SDIO 与卡检测 | 可直接形成 SDIO 初始化资源组 |
| 启动/复位 | BOOT0、PB2/BOOT1、NRST 及 RC/按键网络 | 用于启动模式、复位源和产测设计 |
| 电源域 | +5V、+3V3、VDDA、AGND、VBAT、CHIP_VREF | 能区分数字、模拟和备份电源关注点 |
flowchart LR
MCU["U1<br/>STM32F407VET6<br/>LQFP-100"]
CLOCK["外部时钟<br/>PH0/PH1：8 MHz<br/>PC14/PC15：32.768 kHz"] --- MCU
DEBUG["调试与启动<br/>SWDIO · SWCLK · SWO · NRST<br/>BOOT0 · PB2/BOOT1"] --- MCU
FLASH["板载 SPI Flash<br/>PA4–PA7<br/>GD25Q32"] --- MCU
SDIO["TF / SDIO<br/>PC8–PC12 · PD2 · PD3"] --- MCU
USB["USB FS<br/>PA11 / PA12"] --- MCU
POWER["电源域<br/>+5V · +3V3 · VDDA · AGND<br/>VBAT · CHIP_VREF"] --- MCU
HEADER["P1 / P2<br/>双 40Pin 排针"] --- MCU这里还暴露出两个比“识别成功”更有价值的问题：
- 基准源 U3 的符号标题是
REF3033，制造商料号却是REF3030AIDBZR，BOM 前应人工确认； - SW2、SW3 和 LED1 进入了层级匿名网络，目前不应该猜它们最终对应哪个 MCU GPIO。
3. 底板上下文卡
底板 20 页可以压缩成 5 个固件功能域：
| 功能域 | 关键器件/资源 | AI 可以继续生成的内容 |
|---|---|---|
| 通信 | LAN8720A RMII、隔离 CAN、隔离 RS485、扩展 UART | 引脚规划、PHY/收发器初始化顺序、终端配置检查 |
| 存储与传感 | W25Q128、ICM-42688、AT24C02、SD3078、INA226、AHT20 | SPI/I²C 地址表、驱动清单和中断资源规划 |
| 音频 | ES8388、双路 HT6872 | MCLK/WS/数据时钟关系和音频上电流程 |
| 执行与采集 | TMC2209、双路 AT8236、编码器、HX711、ADC、舵机 | 定时器、PWM、编码器和采样资源规划 |
| 人机接口 | WS2812、按键、EC11、LCD、LED、蜂鸣器、继电器 | GPIO 安全态、消抖、显示和产测项目 |
检测器输出了 67 条活动接口记录，但它们是器件级记录，不等于 67 条独立总线。例如多个 I²C 器件共享同一组 SCL/SDA；部分 SPI 器件因为片选或时钟证据不完整，仍然只是部分候选。给 AI 时应先按总线和功能域合并，而不是直接把接口记录数当作外设数量。
4. 电源上下文卡
底板电源比接口更应该先交给 AI，因为它决定后面哪些功能可以安全上电：
DC 8–24 V
→ 开关 / 自恢复保险 / TVS / 共模滤波
→ 15 mΩ 分流器
→ XL4015 降压与输出控制
→ DCDC_OUT_VCC_5V
USB_IN+5V → MT9700 ───────────────┘
DCDC_OUT_VCC_5V
├─ EXT_+5V0_OUT
├─ ONBOARD_+3V3
├─ EXT_+3V3_OUT
├─ IPS1 隔离 5V / GND
└─ IPS2 隔离 5V / GNDflowchart TD
DC["DC1 / P3<br/>8–24 V"] --> PROTECT["SW1 · 自恢复保险<br/>TVS · 共模滤波"]
PROTECT --> SHUNT["15 mΩ 分流器<br/>INA226_VIN+"]
SHUNT --> BUCK["XL4015 降压<br/>续流 · 储能 · 输出控制"]
BUCK --> BUS["DCDC_OUT_VCC_5V"]
USB["USB_IN+5V"] --> LOAD["U14 · MT9700"]
LOAD --> BUS
BUS --> EXT5["EXT_+5V0_OUT"]
BUS --> LDO1["U8 1117 → U11"]
LDO1 --> ONBOARD3["ONBOARD_+3V3"]
BUS --> LDO2["U9 1117 → U12"]
LDO2 --> EXT3["EXT_+3V3_OUT"]
BUS --> ISO1["U15 B0505S<br/>IPS1 5V / GND"]
BUS --> ISO2["U16 B0505S<br/>IPS2 5V / GND"]
CORE3["核心板排针"] -. 独立输入域 .-> SKY3["SKYSTAR_+3V3"]这段上下文足以让 AI 提出正确的下一批问题：DC 与 USB 同时输入是否回灌、XL4015 与 LDO 的热耗散是否满足负载、隔离地有没有被其他网络跨接，以及核心板输入的 SKYSTAR_+3V3 是否与底板自产 ONBOARD_+3V3 混用。
它不能仅凭网络图回答这些问题，但至少不会漏掉问题。
5. 双板映射只保留固件真正关心的部分
核心板和底板都有 P1/P2 两个 40Pin 连接器。按相同引脚编号对齐后，可以得到下面这些高价值候选：
| MCU 资源 | 底板功能网 | 用途 |
|---|---|---|
| PA2 / PA1 | ETH_MDIO / ETH_REF_CLK | Ethernet 管理与参考时钟 |
| PD1 / PD0 | MCU_CAN_TX / MCU_CAN_RX | CAN 控制器接口 |
| PD9 / PD8 / PD15 | RS485_RX / TX / RE-DE | 隔离 RS485 |
| PB7 / PB6 | I2C1_SDA_PRE / SCL_PRE | I²C 总线预处理 |
| PC6 / PB9 | ES8388_MCLK / WS | 音频时钟 |
| PA8 | ONE_WIRE_DATA | DS18B20 等单总线设备 |
| PC0 | ADC_POT | 模拟电位器输入 |
这不是已确认互连，仍需核对实物方向。但它已经能让 AI 发现关键资源冲突：
- 核心板 PA4–PA7 已连接板载 SPI Flash，底板相同针位又进入其他功能；
- 核心板 PC8–PC12、PD2、PD3 已连接 TF 卡，底板相同针位仍可能被功能选择电路使用；
USED_BOUND_NETLIST只表示存在电气连接，不表示固件已经启用，也不表示可以同时使用。
相比把 80 个针脚全部摊在正文里，这几组资源和冲突更适合直接进入 AI 上下文。完整针脚表可以由工具按需查询，不应该长期占用模型窗口。
四、哪些结果不能让 AI 自己补全
这次实测里，底板工程候选与网表达到了精确匹配；核心板却只有 181 条端点在两侧直接匹配，并出现 10 组候选重复。核心板还有层级表、导线父级缺失等诊断。
因此，可靠的上下文不应该只有“结果”，还必须带上限制：
| 当前证据 | 可以说什么 | 不能说什么 |
|---|---|---|
.epro2 器件/页面 | 工程里存在该对象和属性 | 实物一定安装、属性一定正确 |
.enet 引脚端点 | 导出网表记录了该连接 | 当前实物与该文件完全一致 |
| 接口候选 | 信号组合像某类接口 | 固件已经启用该外设 |
| 电源路径 | 器件引脚和网络形成这条路径 | 电流、稳定性、回灌和热设计已通过 |
| 同针号连接器映射 | 两侧针号可以形成候选 | 实物方向、镜像和插接关系已确认 |
| DNP / 跳线 | 当前工程记录了装配状态 | 所有生产批次都采用同一配置 |
我宁愿让模型回答“这一步证据不足”，也不希望它凭经验把缺失部分补成一个看起来完整的方案。
五、从安装到第一次查询
本文使用 @yuanzihao/schemcp@0.2.0，需要 Node.js 22 或更高版本。
Codex：
codex mcp add schemcp -- npx -y @yuanzihao/schemcp@0.2.0
codex mcp listClaude Code：
claude mcp add --transport stdio schemcp -- \
npx -y @yuanzihao/schemcp@0.2.0其他支持 stdio MCP 的客户端，核心配置也是运行同一个 npm 包。安装后没有打开工程时返回 binding=NOT_BOUND 是正常状态，表示服务已经启动，只是尚未绑定用户提供的工程。
第一次使用可以直接这样问：
请使用 SchemCP 分别打开我提供的核心板和底板 .epro2，
并把两份 .enet 绑定到对应工程，不要串用。
先建立 AI 上下文摘要，只输出：
1. 工程页面与功能域；
2. 主 MCU、板载占用、时钟、复位、BOOT 和调试资源；
3. 电源输入、转换、隔离域和主要负载域；
4. 按总线合并后的通信与外设清单；
5. DNP、跳线、属性冲突和解析诊断；
6. 核心板/底板连接器候选和可能的引脚冲突。
所有分页必须读到 nextCursor 为空。
把网表事实、规则候选和未验证项分开表述。
不要直接展开全部器件和全部引脚，等我追问时再按需查询。这个流程比一开始就要求“分析完整原理图”更稳定。模型先得到一页左右的工程摘要，后续讨论 Ethernet、CAN、电源或 CubeMX 时，再沿对应页面和网络取细节。
六、我希望它最终沉淀成什么
SchemCP 不是自动画原理图的插件，也不是硬件设计判定器。它更像一层位于 EDA 工程和 AI 之间的只读上下文协议。
对我来说，它最实际的用途是：
- 接手陌生工程时快速建立硬件地图；
- 写 BSP 前生成 MCU 资源和外设冲突清单；
- 设计评审前检查电源域、DNP、属性和证据缺口；
- 把核心板、底板和扩展板放进同一套可追溯上下文；
- 为技术文章、测试计划、产测项目和故障分析提供事实基础。
下一步还需要继续解决核心板层级网表差异、匿名网络投影和实物连接器方向确认。等这些证据补齐后，才适合从“上下文摘要”进一步生成可进入项目的 BSP 引脚定义、CubeMX 配置建议和板级测试清单。