当前，已经不只是“ChatGPT 帮你写写原理图说明”这么浅了。到 2026 年，KiCad 10 + ChatGPT/Codex 桌面端的组合，已经可以做到相当接近“AI 辅助硬件设计 Agent”的程度。

KiCad 当前稳定版本已经到 10.0.6，而从 KiCad 9 开始引入的官方 IPC API，在 KiCad 10 中已经更成熟，可以让外部程序直接连接正在运行的 KiCad；与此同时，Codex 桌面端可以访问本地工程目录、运行终端命令、修改文件，并在支持的配置下操作桌面应用。(KiCad)

先说结论

我会把 KiCad + Codex 的能力分成四个层级：

层级	能力	当前成熟度
L1	读工程、分析原理图、解释 PCB	很成熟
L2	修改工程文件、生成脚本、ERC/DRC、BOM、Gerber	很成熟
L3	直接调用 KiCad API，增删器件、布线、布局	已经可用
L4	从自然语言需求自动完成整块 PCB	可以做原型，但还不能完全无人值守

真正值得尝试的是 L2 + L3。

---

1. 最基础：Codex直接“读懂”KiCad工程

KiCad 工程本身非常适合 AI。

典型文件包括：

project.kicad_pro
project.kicad_sch
project.kicad_pcb
sym-lib-table
fp-lib-table

其中原理图、PCB 文件本质上都是结构化文本格式。

所以 Codex 可以直接打开整个工程目录，例如：

MyBoard/
 ├─ MyBoard.kicad_pro
 ├─ MyBoard.kicad_sch
 ├─ MyBoard.kicad_pcb
 ├─ docs/
 ├─ datasheets/
 └─ firmware/

然后你可以直接问：

分析这块板的电源架构。

或者：

检查 STM32 的所有电源脚是否都有去耦电容。

或者：

找出所有没有连接的 MCU GPIO。

甚至：

根据原理图，生成 MCU Pin Assignment 表。

Codex可以结合：

原理图 + PCB + datasheet + firmware

进行交叉分析。

这已经非常有价值。

---

2. 可以自动做 ERC / DRC

KiCad 自带：

kicad-cli

这是非常关键的一点。

KiCad 官方 CLI 可以自动处理原理图、PCB、符号、封装以及制造文件生成等工作。(KiCad Docs)

因此 Codex 可以运行类似：

kicad-cli sch erc MyBoard.kicad_sch

或者：

kicad-cli pcb drc MyBoard.kicad_pcb

于是工作流变成：

Codex修改设计

↓

运行 ERC

↓

发现错误

↓

分析错误原因

↓

修改设计

↓

再次 ERC

直到通过。

PCB 也是同样过程：

PCB修改 → DRC → 分析 → 修改 → DRC

这其实已经非常接近软件开发里的：

写代码
↓
compile
↓
test
↓
fix
↓
test

也就是说：

KiCad 正在开始具备一种“Hardware CI/CD”的可能性。

---

3. 自动生成生产文件

这一部分现在已经非常适合 Codex。

例如你一句：

给这个版本生成 PCB 制造文件。

Codex可以自动运行 KiCad CLI，生成：

Gerber
Drill
BOM
Pick & Place
PDF schematic
SVG
3D / STEP

并自动建立：

release/
 └─ v1.3/
     ├─ gerber/
     ├─ drill/
     ├─ bom/
     ├─ pick_place/
     ├─ schematic.pdf
     └─ README.md

甚至可以自动生成：

CHANGELOG.md

比如：

V1.3

- 将 U3 由 AMS1117 改为 TPS62160
- 增加 CAN 总线 TVS
- R23 从 10k 修改为 4.7k
- 调整 USB D+/D- 走线
- 增加 3 个测试点

ERC: Pass
DRC: Pass

这类工作特别适合 AI。

---

4. 更有意思的是：Codex可以直接“控制KiCad”

这是和以前最大的区别。

KiCad 从 9.0 开始引入官方 IPC API。

官方对它的定位就是：

让外部应用控制正在运行的 KiCad。

API 使用独立进程与 KiCad 通信，并且设计目标是比过去基于 SWIG 的 Python 接口更加稳定，也支持不同编程语言。(KiCad 开发文档)

架构可以变成：

Codex
   │
   │ MCP / Python
   ▼
KiCad IPC API
   │
   ▼
KiCad

这时就不只是“修改 .kicad_pcb 文件”。

而是：

AI → 调 API → KiCad UI 立即变化

---

5. 于是可以做什么？

例如你告诉 Codex：

把所有 100nF 去耦电容移动到对应 IC 电源脚附近。

Agent 可以：

读取 PCB

↓

找到 MCU

↓

识别：

VDD
VDDA
VDDIO

↓

找到对应：

C12
C13
C14
C15

↓

读取 PCB 坐标

↓

计算新的放置位置

↓

通过 IPC API：

move_component()

↓

KiCad画面里元件直接移动。

---

另一个例子：

给所有 IC 增加 Pin1 标记。

AI可以：

读取 PCB

↓

识别 IC footprint

↓

找到 Pin1

↓

添加丝印三角形

↓

自动运行 DRC。

---

再比如：

把这块 PCB 改成 100 mm × 80 mm。

AI可以：

修改：

Edge.Cuts

↓

重新调整安装孔

↓

调整接口位置

↓

重新铺铜。

---

6. 甚至已经有人在做 KiCad MCP

目前社区已经出现了多个：

KiCad MCP Server

其目的就是：

LLM
 │
MCP
 │
KiCad IPC
 │
KiCad

其中一些项目已经实现了：

创建工程

添加元件

移动元件

增加 Net

走线

增加 Via

Copper Pour

Zone Fill

查询 Net

查询元件

运行 DRC

生成 Gerber

导出 PDF / SVG / 3D

部分项目还加入了原理图创建和符号库搜索。不过这些实现目前主要仍属于第三方社区项目，部分 IPC 功能仍标记为 experimental，因此更适合作为工程工具链基础，而不是完全不经人工复核的生产系统。(GitHub)

甚至已经有 KiCad 10 的 AI Assistant 插件，把 LLM 聊天界面直接嵌入 KiCad，并通过 MCP 暴露原理图和 PCB 工具。(GitHub)

---

7. Codex桌面端还有一个特别有意思的能力

现在 Codex Desktop 不只是：

terminal
+
file editing

在支持的配置中，它还具备 Computer Use，可以看到、点击和输入 Windows/macOS 桌面应用。OpenAI 的企业版本说明已经明确支持在 Windows 应用中进行此类桌面操作。(OpenAI Help Center)

于是理论上还有第三条路径：

Codex
↓
Computer Use
↓
KiCad GUI

比如：

打开 PCB Editor。

打开 3D Viewer。

切换到 F.Cu。

打开 DRC。

导出 Gerber。

都可能直接通过 GUI 完成。

不过我的建议是：

不要把 GUI 自动点击作为核心方案。

可靠性排序应该是：

IPC API
↓
kicad-cli
↓
直接修改工程文件
↓
GUI Computer Use

GUI 更适合补充。

---

8. 一个非常现实的应用：从需求生成一块简单控制板

假设你告诉 Codex：

设计一块 24V 工业传感器采集板。
MCU 使用 STM32G0。
4 路 4–20mA 输入。
2 路 RS485。
CAN。
24V 输入。
PCB尺寸 100×80mm。

AI可以先生成系统架构：

24V
 │
 ▼
DC/DC
 │
5V
 │
LDO
 │
3.3V

        STM32G0
        │
 ┌──────┼───────┐
 │      │       │
ADC   RS485    CAN
 │
4-20mA

接下来继续：

需求 → 器件选型 → 原理图 → ERC → PCB → DRC → BOM → Gerber

其中很多环节都可以交给 Codex。

---

9. 尤其适合标准电路模块

目前 AI 最适合做：

模块	AI适合程度
MCU最小系统	★★★★★
RS485	★★★★★
CAN	★★★★★
USB	★★★★☆
GPIO	★★★★★
ADC输入	★★★★☆
DC/DC	★★★★☆
LDO	★★★★★
EEPROM	★★★★★
SD Card	★★★★☆
Ethernet PHY	★★★☆☆
DDR	★★☆☆☆
RF	★★☆☆☆
高速SerDes	★☆☆☆☆

也就是说：

工业控制板 / IoT / Edge AI控制板

会是非常合适的场景。

---

10. AI还能把“硬件”和“软件”连起来

这个反而可能是 KiCad + Codex 最有价值的地方。

比如修改：

PA9 → UART1_TX
PA10 → UART1_RX
PB6 → CAN_RX
PB7 → CAN_TX

Codex随后可以自动更新：

STM32Cube配置
firmware
device tree
pinmap.h
硬件说明书
测试程序

也就是说：

KiCad schematic
        │
        ▼
Pin Definition
        │
 ┌──────┼─────────┐
 ▼      ▼         ▼
Firmware DeviceTree Documentation

传统硬件开发里一个非常常见的问题是：

原理图改了，但软件没改。

Agent非常适合解决这种同步问题。

---

11. 还有一个非常值得做的功能：Datasheet Agent

把 datasheet 放在：

datasheets/

例如：

STM32G0.pdf
TPS5430.pdf
ISO1042.pdf
ADS8688.pdf

然后问：

检查当前设计是否符合芯片厂商 Recommended Application。

AI可以对照：

Datasheet
       ↓
Reference Design
       ↓
KiCad Schematic

检查：

去耦电容

Bootstrap电容

反馈电阻

晶振电容

上拉电阻

终端电阻

TVS

电源时序

这会非常实用。

---

12. 但是最需要警惕的是“看起来像对的”

硬件 AI 最大的问题和写软件不同。

软件错误通常：

程序报错

PCB错误可能：

PCB可以生产
PCB可以焊接
PCB甚至可以开机

但：

EMI超标

ADC噪声大

DC/DC不稳定

USB偶发掉线

RS485抗干扰差

MOSFET发热

ESD测试失败

这些错误 ERC / DRC 根本检查不出来。

所以不能认为：

ERC PASS
DRC PASS

等于：

Design PASS

---

13. 目前AI仍然比较难替代的部分

主要是：

电源完整性 PI

信号完整性 SI

EMC / EMI

模拟前端

RF

高速PCB

热设计

爬电距离

安规

机械约束

以及：

PCB Layout经验。

例如：

Buck 的 SW node 到底应该多小？

ADC AGND 怎么处理？

Ethernet PHY magnetics 应该怎么布局？

DDR 等长到底怎么规划？

这些往往不是简单规则能够完全决定。

---

14. 所以我认为最好的架构不是“AI自动画PCB”

而是：

                 Engineer
                    │
                    ▼
             Natural Language
                    │
                    ▼
              ChatGPT / Codex
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
      Datasheet   KiCad      Firmware
                    │
             ┌──────┴──────┐
             ▼             ▼
          IPC API       kicad-cli
             │             │
             └──────┬──────┘
                    ▼
                 KiCad
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
        ERC/DRC            Gerber/BOM
          │
          ▼
      Human Review

也就是：

AI Native Hardware Engineering

而不是：

AI Auto PCB。

---

15. 如果你在 Windows 上实际搭，我建议这一套

结合你过去做上位机、FPGA、Edge AI 硬件这些应用，我更建议直接走：

Windows 11

KiCad 10.0.x
        │
        ├── kicad-cli
        │
        └── IPC API
                │
                ▼
           kicad-python
                │
                ▼
          KiCad MCP Server
                │
                ▼
       ChatGPT / Codex Desktop

工程目录全部放 Git：

hardware/
 ├─ pcb/
 ├─ datasheet/
 ├─ simulation/
 ├─ firmware/
 ├─ scripts/
 ├─ docs/
 └─ AGENTS.md

然后在 AGENTS.md 里规定：

所有设计修改后必须运行ERC
所有PCB修改后必须运行DRC
禁止修改认证器件
禁止自动更换footprint
所有datasheet参数必须注明来源
任何电源拓扑修改必须人工确认
生产文件只能由release脚本生成

这样 Codex 就不是聊天机器人，而是真正被约束在一个硬件工程 Harness中的 Agent。

---

我对目前能力边界的判断

如果目标是：

“一句话生成一块可以直接批量生产的复杂PCB。”

还不现实。

但如果目标换成：

“让AI承担60%以上重复性的原理图、PCB修改、检查、版本管理、文档和制造文件工作，由硬件工程师负责关键架构和最终Review。”

那么现在已经非常值得落地。

尤其对于：

MCU控制板、工业采集板、Edge AI外围板、传感器接口板、RS485/CAN/以太网控制板、电源/IO板

这类标准化程度比较高的硬件，我认为 KiCad + Codex 已经进入真正有工程价值的阶段。

更进一步说，它很像你之前关注的 AI-native PLC Engineering：

Requirements
↓
Intermediate Representation
↓
Schematic
↓
PCB
↓
ERC / DRC
↓
Verification
↓
Human Approval

只是对象从 PLC Logic 换成了 Electronic Design。

如果把 KiCad 10 + Codex Desktop + IPC API + MCP + Git 真正组合好，已经可以构成一个相当完整的 AI-native EDA / AI Hardware Engineering 技术框架。(openai.com)