我开发了PCBEditor，一款浏览器端PCB工具，能根据描述设计电路板，所以请带着这个背景来读本文。我们刚在它前面加了一个MCP服务器，写文档之前，我想看看没人引导时AI助手实际会怎么用它。于是10月20日，我把Claude Code连接到服务器，输入一句话，然后放手让它自己跑。带每个工具及其返回响应的分步版本见pcbeditor.com/mcp/guide。
环境搭建
一条命令即可添加服务器：
claude mcp add --transport http pcbeditor https://api.robodib.com/mcp
Claude Code 随后看到 16 个工具：design_board、get_job、answer_question、edit_board、route_board、run_drc、review_board、get_board、export_board、import_kicad，另有几个用于元器件和设计。设计在服务器上以任务形式运行：design_board 返回任务 ID，get_job 每次调用最多等待 45 秒，看任务是否有进展。
我输入的内容：
设计一块 4 层 ESP32-S3 板，带 USB-C 和 LiPo 充电器。
Claude 先写了一份规格说明
它没有直接拿我这句话去执行。第一次调用 design_board 时，它带上了一份自己写的完整规格。节选如下：
充电：单节 LiPo 充电器，带电源路径／负载共享，使板子在充电时由 USB 供电，拔掉后由电池供电（例如 TI BQ24074，或 MCP73831 加一个 P-MOSFET 和肖特基负载共享电路）。充电电流约 500 mA，由电阻设定。[...] 3.3V 电源轨：低压差稳压器，额定电流至少 600 mA，静态电流低（例如 AP2112K-3.3 或 RT9080/ME6211 一类），由电源路径输出供电
它还要求 USB 线路加 ESD 保护、电池电压分压接到 ADC 引脚、使能按钮加 RC 延时、两排排针，以及带完整接地层的 4 层叠层，并开启了更慢的额外质量检查。这份需求比大多数人写的都好，也比我的好。
然后我们的服务器卡了五次
第一个任务在 44 秒后结束，提示“运行结束，未生成板子”。接下来四次也一样。进度信息说明了原因：流水线在电路里发现了问题，正“等待你就电路问题做出选择，然后再进行布局……”，但这个选择从未作为问题传给 Claude。这是我们 MCP 层的 bug，已经列入待办。
Claude 的反应才是有意思的地方。它用 get_part 查了模块和充电器的引脚图，重写描述，按库里的名称逐一写明充电器和 USB 的每个引脚，然后重试。第六次运行时，问题终于传了过来：
按当前接线，电路无法工作：[...] U2（带电源路径的 LiPo 充电器）引脚 4（~{CE}）被拉高（网络 VBUS），这会使 U2 关断：该引脚为低电平时它才工作；U2（带电源路径的 LiPo 充电器）引脚 6（EN1）被拉低（网络 GND），这会使 U2 关断：该引脚为高电平时它才工作。我该如何继续？
Claude 用自己的话回复了一份修改清单。服务器没有理会这段自由文本，又把同一个问题问了一遍（第二个 bug），于是 Claude 选了“带着这些电路问题继续构建”，并表示之后会用编辑操作修复这些问题。任务在第 113 秒完成：36 个元件、708 条走线、134 个过孔、四层板。
Claude 读了网表
它的价值就体现在这里。它调用 get_board 并传入 detail: full，拿到每个网络及其连接的焊盘，再对照 BQ24074 电源路径充电器所需的条件逐一比对。它找出了三个错误——我们的设计规则检查放过了它们，因为这些不属于铜箔层面的问题：
- ESP32-S3 模块的 3V3 引脚单独成了一个网络，通过 1 kΩ 电阻（R12）从 3.3 V 电源轨取电。用 Claude 的话说，“它会立刻掉电复位。”
- 充电器的温度检测引脚通过 10 kΩ 上拉到 3V3，Claude 说这“会阻止充电”。
- 充电器的输入限流引脚（ILIM）接在了未连接网络上。
我对照它读取的板卡数据逐项核实，三个问题都属实。
它还对我们的某项检查提出了异议。问题描述里说 EN1 拉低“会让 U2 保持关断”。Claude 指出，当 EN2 为高、EN1 为低时，BQ24074 的输入限流由 ILIM 电阻决定，这正是设计意图；而把 EN1 拉高反而会让充电器进入挂起状态。这与 TI 数据手册中的 EN1/EN2 真值表一致。我们的检查错了，Claude 保持了引脚原样。
修复以精确的 edit_board 指令逐焊盘下发：
按以下对应关系重新分配这些焊盘的网络（焊盘 -> 网络），然后重新布线受影响的网络：
- U1.2 -> 3V3（模块供电引脚必须直接接在 3V3 电源轨上）。删除网络 U1_3V3。
服务器执行了这些指令并重新布线：“重新分配网络的引脚：U1.2 → 3V3、U1.4 → SIG_IO4、U2.7 → GPIO2、U2.12 → U2_ILIM、R4.1 → U2_ILIM、R4.2 → GND，另有 8 个。”第二轮把首次构建时留在未连接网络上的排针引脚接好了。随后它调用 review_board 逐引脚检查充电器布线。评审中由 AI 撰写的部分是整个会话里最不可靠的内容：它把 12 Mbps 的 USB 链路说成 480 Mbps，还说充电器的散热焊盘没有散热过孔；而当 Claude 要求补四个过孔时，服务器回答说四个都已经在了。
Claude 修复后的电路板，在 PCBEditor 编辑器中打开：73.8 × 54.6 mm 上排布 35 个元件，四层板，所有网络均已布线。Claude 最后一次编辑请求显示在右侧聊天面板中。
卡在哪里
有两个设计规则错误始终消不掉：内层走线距离 USB-C 连接器屏蔽孔分别为 0.151 和 0.156 mm，而规则要求是 0.25 mm。Claude 尝试了几次修改。我们的编辑守卫驳回了一次，理由是“会让 DRC 错误从 2 个变成 4 个”。另一次返回的结果是“电路板没有任何变化”。第三次之后，Claude 停下来告诉我：
还有两个 DRC 错误，工具试了三次也没能修复，所以我没有导出任何制造文件。
这正是我希望 Agent 在一块还没准备好的板子上做的事。export_board 本来也会拒绝：只要存在用户尚未接受的 DRC 错误，它就不会交出制造文件。但 Claude 并没有替我去接受这些错误。
它的总结里还列出了板子尺寸——73.8 × 54.6 mm，而当初要求的是 60 × 30 mm；USB 差分对耦合松散；以及一条提醒，让我在插上 JST 电池线之前先确认极性。整个会话大约花了 18 分钟：6 个设计任务、9 次编辑、25 次等待 get_job，最后得到一块我能在浏览器里打开、再花几分钟手工修好的板子。
我的收获
分工是有效的。Claude 擅长语言模型该擅长的事：写需求简报、对照数据手册检查网表、写出精确的修改请求，以及知道什么时候该停。服务器则负责它不该插手的事：按引脚映射连线、布线、测量间距。
检查通过，板子照样是错的。三处接线错误全都通过了设计规则检查，因为 DRC 量的是铜，不是意图。第一次 design_board 的结果甚至说板子 DRC 干净，而保存下来的板子却有两个错误。如果你的 Agent 不读网表，那就只能你自己读。
我们的 MCP 层还有缺口。电路问题导致的停顿没有以提问形式呈现、自由文本回答被忽略、某项检查误读了 BQ24074 的使能引脚、板子明明有两个错误却报“DRC 干净”、板子比要求的大。这些现在都进了待办清单——让一个 Agent 按它自己的方式使用产品，一个下午就全找出来了。
拒绝导出的 Agent 是加分项。我宁愿收到“还没准备好，原因如下”，也不想要一个压缩包。
想自己动手试一遍的话，这份指南完整走了一遍流程：连接 Claude、ChatGPT 或 Gemini，发出第一条提示词，回答设计师提出的问题，检查、修改并导出，还列出了每一步你会看到什么回应：pcbeditor.com/mcp/guide。
