在硬件设计领域，仿真与实测的对比验证一直是工程团队面临的痛点。传统工作流中，工程师需要在 SPICE 仿真软件、示波器控制软件、波形分析工具之间频繁切换，手动导出数据、归一化时间轴、比对仿真曲线与实测曲线。这种碎片化的操作不仅效率低下，还容易引入人为误差。Lucas Gerads 在其博客中展示了一种基于 MCP（Model Context Protocol）的创新方案：通过赋予 Claude Code 直接控制示波器和调用 SPICE 仿真引擎的能力，实现设计 - 仿真 - 验证的自动化闭环。
架构设计与核心组件
该方案的核心思路是将 Claude Code 作为协调层，利用 MCP 协议连接两类关键工具：SPICE 仿真引擎和数字示波器。Claude Code 不再仅仅是一个生成代码的对话式 AI，而是具备了实时获取硬件状态、执行仿真、 分析数据的能力。这种设计解决了传统硬件验证流程中的信息孤岛问题 —— 仿真工程师和测试工程师往往使用不同的工具链，缺乏统一的数据交换层。
具体实现上，该方案包含三个主要组件。首先是 lecroy-mcp，这是一个面向 LeCroy 示波器的 MCP 服务器，提供了获取波形数据、设置采集参数、查询设备状态等能力。其次是 spicelib-mcp，它封装了 Python 的 spicelib 库，使 Claude Code 能够直接调用 SPICE 引擎执行仿真并解析输出。第三个组件是 Claude Code 本身，它作为协调者，根据用户指令调度上述两个 MCP 服务器，完成从仿真到验证的全流程。
这种架构的优势在于其模块化特性。不同的示波器厂商可以通过实现各自的 MCP 服务器接入同一框架，而 SPICE 仿真后端同样可以灵活替换。对于工程团队而言，这意味着可以根据现有设备选择合适的实现，无需大规模重构整个验证流程。
实践中的关键经验
Lucas Gerads 在实践中总结了若干重要教训，这些经验对于构建类似的 AI 驱动验证流水线具有直接参考价值。
第一项经验涉及 Claude Code 对物理环境的感知边界。在当前技术条件下，Claude Code 无法直接 “看到” 用户的物理实验 setup，它不知道哪根探针连接到了哪个节点，也不清楚示波器的通道配置。因此，使用者必须明确告知 Claude 每一根信号线的连接关系，以及示波器通道与电路节点的映射。如果让 Claude 自行推测这些信息，验证结果的准确性将难以保证。这一教训提示我们：在 AI 辅助的硬件验证场景中，清晰的拓扑描述是所有后续分析的前提。
第二项经验关于数据的时效性。在传统的硬件调试中，工程师有时会忘记刷新示波器屏幕，导致基于过时数据进行判断。对于 AI 驱动的验证系统，这一问题更加突出 ——Claude Code 可能会基于缓存的旧波形数据进行分析，得出的结论将与实际电路行为不符。解决方案是确保每次验证任务前都显式获取最新的测量数据，并在系统设计中加入数据时间戳校验机制。
第三项经验涉及上下文管理的工程实践。在早期实验中，开发者尝试将原始波形数据直接注入 Claude 的上下文窗口，这种做法很快遇到了两类问题：一是大量原始数据消耗了宝贵的上下文额度，导致对话频繁中断；二是原始波形格式往往是二进制或紧凑的数值数组，Claude 难以直接解析其中的物理含义。正确的做法是将示波器导出的数据保存为中间文件（如 CSV 或 JSON），然后让 Claude 通过文件交互方式读取和分析。这样做既节约了上下文资源，也便于引入数据预处理步骤 —— 例如时间轴归一化、多通道对齐、噪声滤波等。
在嵌入式固件层面，类似的最佳实践同样适用。向 Claude 提供明确的引脚复用（pinmux）映射表，准备包含 build、flash、ping、erase 等常用操作的 Makefile，可以显著降低 Claude 执行固件相关任务时的认知负担。Claude 应当调用这些预定义的构建目标，而不是自行构造命令字符串，这既提高了可靠性，也便于团队标准化开发流程。
可落地的工程参数与监控要点
将上述架构投入实际使用时，以下参数和监控点值得关注。
在仿真配置方面，SPICE 仿真的时间步长（tstep）和终止时间（tstop）需要与示波器的采样率和存储深度匹配。对于 MHz 级别的信号，建议将仿真时间步长设置为信号周期的百分之一至千分之一，以确保仿真曲线能够捕捉到必要的细节。示波器的采样率通常应至少是信号最高频率成分的十倍，以满足奈奎斯特采样定理并留出裕量。
在数据比对环节，推荐设置阈值来判断仿真与实测的一致性。对于模拟电路，常用的指标包括峰值电压偏差（建议阈值 ±5%）、上升时间偏差（建议阈值 ±10%）以及稳态误差。对于更严格的应用场景，可以引入波形相似度指标如相关系数或均方根误差（RMS error），具体阈值需根据电路类型和设计裕量确定。
在系统监控层面，需要关注三类指标：首先是 MCP 服务器的响应时间，正常情况下获取单通道波形数据的延迟应在百毫秒级别；其次是仿真任务的执行时间，复杂电路的 SPICE 仿真可能耗时数秒至数分钟，应设置合理的超时阈值（如 60 秒）并提供进度反馈；第三是数据一致性校验结果，每次比对完成后应生成报告，记录各项指标的偏差值以及是否通过预设阈值。
在错误处理方面，建议实现三层防御机制：第一层是通信层的心跳检测，确保 MCP 服务器与示波器或仿真引擎的连接处于活跃状态；第二层是数据有效性校验，检查返回的波形数据是否完整、是否存在异常值；第三层是业务层的结果验证，比对结果是否符合物理常识（例如输出是否在电源电压范围内）。
资料来源
本文技术细节主要参考 Lucas Gerads 的博客文章 "SPICE simulation → oscilloscope → verification with Claude Code"，该文详细记录了作者构建 LeCroy 示波器 MCP 服务器和 SPICE 仿真集成的工作流程与实践经验。相关开源项目包括 lecroy-mcp 和 spicelib-mcp，均托管于 GitHub 平台。