让 AI 直接操作 EDA 工具有两条路：让模型生成 .kicad_sch 文本再手工导入，或者让 Codex 通过 MCP 实时驱动正在运行的 KiCad。前者是一次性产物，后者才是真正的"协同工作流"。这篇基于 kicad-mcp 仓库整理后者的完整配置，重点讲清链路结构和最容易失败的连通环节。
链路结构与三个易混点
整条链路：Codex（MCP 客户端）→ STDIO/JSON-RPC → kicad-mcp（本地 Python 进程）→ 本地 IPC → 正在运行的 KiCad 编辑器。
三个容易误解的点先澄清：Codex 不控制鼠标，调用的始终是 MCP 服务器暴露的工具；kicad-mcp 不是 KiCad 的一部分，它是把工具调用翻译成 KiCad IPC 请求的翻译层；IPC API 面向正在运行的 GUI 实例，目标编辑器必须先打开——启动顺序不是细节，是前提。
还有一个兼容性边界值得写进认知：kicad-mcp 当前用的连接地址格式与 KiCad 官方 IPC 文档描述的机制并不完全相同，第三方项目与 KiCad 版本需要配套验证。原版连不上时先查仓库 README 和 Issue，而不是反复改 Codex 配置——问题通常在翻译层。
环境准备与配置清单
KiCad 10.x 稳定版，装好后三件事：打开目标工程并进入原理图或 PCB 编辑器；在编辑器首选项的 Scripting 设置里启用 IPC API；保持编辑器窗口开着。
Python 侧用 uv 隔离运行，不污染系统环境：
winget install --id=astral-sh.uv -e
Codex 的 MCP 配置在 ~/.codex/config.toml 里加一段 mcp_servers 条目，command 指向 uvx kicad-mcp。配置完 codex mcp list 确认服务出现在列表且状态正常。
连通验证：五步判定
配置完不等于能用，按五步验：
codex mcp list显示 kicad-mcp 在列。- 编辑器已打开且 IPC 开关已启用（MCP 能启动但所有工具失败时，这是第一检查项）。
- 让模型执行一个只读操作：列出当前工程的元件清单。
- 对照 KiCad 编辑器实际状态核对返回结果——返回的器件数量和位号与界面一致才算通。
- 试一次写操作（放置一个测试元件），确认实时反映在画布上。
安全边界与工程纪律
两件事必须写进流程。第一是数据面：工具返回给模型的器件、网络信息会进入所用 AI 服务的上下文，涉密工程先核对数据策略和工具权限。第二是质量闸：AI 生成的修改不代表通过了 ERC/DRC 和实物测试，正式设计里每次 AI 改动都要人工复核，且优先在测试工程或版本控制分支上操作。
实用建议
这条链路的最佳适用场景是批量性、重复性的 EDA 操作：批量改封装位号、按规则重排丝印、生成 BOM 检查报告。原理图的电路设计决策本身仍属于工程师——AI 负责的是"手"，不是"脑"。把高频 TCL 式操作沉淀成团队自己的 MCP 工具描述，是比反复调 prompt 更有效的路径。
评论0