刚拿到这个标题的时候，我就在想，这不就是我这两年一直在琢磨的东西吗？硬件设计这个圈子，说老实话，比软件行业要“保守”得多，很多工程师还在靠翻Datasheet、手动敲坐标、一遍一遍检查封装过日子。可另一边，AI圈子的工具链已经卷到飞起，大模型都能写代码了，凭啥就不能帮我们画板子？

这阵子我把MCP协议从头到尾捋了一遍，又在Altium Designer里折腾了好几周，终于把这条“AI+EDA”的路给走通了。今天就拿我自己的实战经历，跟大伙儿好好聊聊，怎么用MCP协议把Altium Designer和一个AI助手深度绑定，让AI真的能听懂你的设计需求，还能帮你干活。

这篇内容不是什么高不可攀的学术研究，就是一套已经在跑的真实方案。硬件工程师、PCB设计爱好者，或者单纯对AI工具链感兴趣的朋友，看完都能照着搭一套出来。我先说结论：这个方案的核心思路，是把AD的能力通过MCP协议暴露给大模型，让AI既拥有自然语言理解能力，又拥有操作AD的“手”。原理不复杂，但细节是真的多。

1. 整体设计思路：为什么选择MCP协议作为AI与AD之间的桥梁

1.1 一个硬件工程师每天都在经历的痛点

先说个我自己的场景。上个月做一块六层板，BOM表里有三百多个元器件，其中有十几个料是标准库没有的，需要手动建库。光是整理封装、检查引脚定义、核对3D模型，就花了我大半天时间。好不容易把库建完，又开始画原理图，画到一半发现有个网络标号出了问题，又得一个一个去排查。

这些工作繁琐吗？非常繁琐。有技术含量吗？其实不高。但它们就是占据了硬件工程师大量时间。我当时就在想，如果有个智能助手能听懂我说的“帮我把这颗芯片的封装改成QFN-32”，然后自动去库里找到对应封装、检查引脚兼容性、把原理图符号更新一遍，那该多省事。

传统的方案也不是没有。Altium Designer本身有脚本系统，也开放了API接口，但问题是这些接口的学习成本高、使用门槛不低。一个硬件工程师能熟练画板子，但让他去写一套完整的API调用脚本，那是真有点强人所难。

1.2 为什么不是AD插件直连，也不是纯脚本

在动笔之前，我认真比较过三种方案：插件直连、独立脚本、MCP桥接。这里直接说我的结论，三种方式的差异非常明显。

插件直连的问题在于，AD的API虽然功能强大，但那是给程序员用的。而且写出来的功能模块往往绑定在AD这个特定的软件上，想迁移到别的EDA工具就全部报废。这就好比你专门为某款手机写了一个App，换了手机就完全不能用了。

独立脚本比插件灵活一些，但依然绕不开一个问题：脚本调用完AD之后，返回的数据格式五花八门，大模型很难直接理解。比如AD返回的是几个坐标点、一串位号列表，AI看着这些内容并没有办法形成上下文，也就做不到真正“听懂”你的话。

MCP协议的出现把这个局面彻底改变了。它相当于给AI加了一个“万能遥控器”，AI通过MCP协议去调用外部工具，就像我们人类打开手机App一样自然。MCP协议里规定了一套标准的工具调用方法，AI只需要按照协议格式发请求，就能拿到结构化的结果。

1.3 MCP在AD集成中的关键角色

用大白话解释一下MCP（Model Context Protocol）到底干了什么事。你可以把它理解成一个标准化的“插座”，AI是电器，外部工具是电源，MCP协议就是那个把两者连接起来的接口标准。在传统流程里，AI模型只能处理文本，你给它一份BOM表，它能帮你分析，但没法替你打开AD去操作。MCP让AI具备了这些能力。

在这个集成方案里，角色分配很明确：

• AD客户端：被操作对象，负责提供原理图、PCB、元件库等数据
• MCP Server：连接AI和AD的桥梁，接收AI的指令，翻译成AD能懂的API调用
• AI助手：大脑，负责理解用户的自然语言，拆解任务，调用MCP Server上的工具
• 用户（你）：发出指令，微调AI的输出结果

所以这个架构本质上就是：用户面对的是AI，AI面对的是一堆标准化的“工具”（通过MCP封装），每个工具对应AD的一种能力。工具我起了几个典型的名字，比如get_component_list、check_net_connectivity、generate_netlist、query_manufacturer等等。AI不需要懂AD的API底层实现，它只需要知道有哪些工具可用，每个工具接收什么参数、返回什么结果就行。

2. 搭建开发环境：MCP Server的从零实现

2.1 工具链准备与版本选择

这个方案的开发环境搭建其实没有想象中那么复杂，我先列个清单。我目前用的是Python 3.10，因为MCP的官方SDK对3.10+支持得最好，太老版本的Python在类型注解和异步处理上会有点别扭。

• Altium Designer：我用的AD20，后面测试了AD21和AD23，API接口基本一致
• Python 3.10+：开发MCP Server的主要语言
• MCP官方SDK：pip install mcp，目前最新版本已经原生支持FastMCP这种语法糖
• AI客户端：我先是用了Claude Desktop做测试，后面嫌它不够灵活，直接写了一个Python客户端，用OpenAI接口对接本地部署的Qwen模型
• win32com库：pip install pywin32，这是让Python和AD通信的关键组件

有一点要多说一句，很多人问要不要单独装一个AD的版本。我的建议是如果你手头有工作电脑在用的版本，直接用那个就行，不用专门装新的。AD的API体系很稳定，这些接口从AD17到AD23基本没有大改动，不像某些国产软件天天改API。

2.2 深入理解MCP协议的核心概念

动手写代码之前，有几个概念必须得先吃透，否则后面调试起来会被各种报错搞到怀疑人生。

MCP协议里有三个核心原语：Tools（工具）、Resources（资源）和Prompts（提示）。Tools是让AI可以主动执行的动作，比如“打开文件”、“获取元器件列表”；Resources是让AI可以读取的数据，比如当前的原理图内容、PCB的层叠结构；Prompts是预先定义好的对话模板，帮助AI理解特定任务的上下文。

在实际的AD集成里，最常用的是Tools和Resources。比如我定义一个工具叫get_component_list，AI收到用户“看看板子上有哪些元器件”的请求时，就会自动调用这个工具。工具返回的是一段结构化的JSON，里面包含位号、封装、值、坐标等信息。AI拿到这个JSON之后，再组织成自然语言回答给用户。

这套机制的妙处在于，AI不需要预先“记住”AD里的数据，而是按需实时获取。就好比你请了一个高级助理，这个助理不需要把公司所有文件都背下来，他只需要知道每个文件放在哪、怎么查，要用的时候去拿就行。这样信息永远是最新的，也不会因为数据太多把AI的上下文窗口撑爆。

2.3 一个最小可用的MCP Server代码骨架

理论铺垫得差不多了，直接上代码。我先把最核心的框架贴出来，这个框架能跑通的最小案例。

import json from mcp.server.fastmcp import FastMCP import win32com.client import pythoncom # 初始化MCP服务器 mcp = FastMCP("altium-mcp-server") class AltiumManager: """负责管理Altium Designer的COM通信""" def __init__(self): self.app = None self.project = None self.pcb = None self.sch = None def connect(self): """连接正在运行的Altium Designer实例""" pythoncom.CoInitialize() try: # 尝试获取已运行的AD实例 self.app = win32com.client.GetActiveObject("Altium.Application") except: # 如果没有运行，则创建新实例 self.app = win32com.client.Dispatch("Altium.Application") self.app.Visible = True self.app.WindowManager.MainWindow.Visible = True return self.app def get_current_document(self): """获取当前活动的工作区""" ws = self.app.Workspace doc = ws.CurrentDocument return doc def get_components(self): """从当前PCB或原理图中提取元器件信息""" doc = self.get_current_document() components = [] # 这里是核心操作，后面详细展开 return components # 定义一个MCP工具：获取元器件列表 @mcp.tool() def query_components() -> str: """获取当前打开的Altium Designer设计文件中的所有元器件信息，包括位号、封装、坐标、值等""" manager = AltiumManager() try: manager.connect() comps = manager.get_components() return json.dumps(comps, ensure_ascii=False, indent=2) except Exception as e: return json.dumps({"error": str(e)}) finally: pythoncom.CoUninitialize() # 启动MCP服务器 if __name__ == "__main__": mcp.run()

任何一个MCP Server大概都是这个骨架：初始化服务器、定义各种工具函数、启动监听。关键在于工具函数内部的实现——怎么从AD里拿到数据，这才是真正需要精雕细琢的地方。

测试这个最小框架也简单，直接命令行启动：

python altium_mcp_server.py

启动之后，MCP服务器就挂在本地端口上等待AI来调用了。我建议第一次跑的时候先用客户端连一次试试，确认工具能被正常发现。如果工具列表里出现了query_components，那说明MCP的基础链路已经通了。

3. 打通Altium Designer：核心功能实现细节

3.1 AD API的基础：COM接口怎么玩

Altium Designer底层有一个庞大的COM组件库，通过Python的win32com可以访问。这个体系有点像Windows COM那套东西，AD把内部对象模型暴露出来，比如Workspace代表工作区、PCBDocument代表PCB文件、SchDocument代表原理图文件。

我一开始也很头疼，因为AD的API文档不太友好，好多接口都是意大利面式的命名。后来我找到了一个很高效的学习方式：AD里自带脚本编辑器，可以直接写DelphiScript脚本来调用API，把脚本逻辑跑通之后，再翻译成Python。这个方法比对着文档啃效率高多了。

给兄弟们一个建议，入门AD API可以从这几个核心接口开始：

• Application：最顶层，管理整个AD应用
• Workspace：管理所有打开的项目和文档
• PCBDocument：PCB文档对象，里面有板子上的所有对象
• SchDocument：原理图文档对象，管理元器件符号、连线等
• IntegratedLibrary：集成元件库

3.2 元器件列表读取：AI理解设计的关键一步

元器件列表是整个集成方案里最重要的数据源。AI能不能理解你的板子，很大程度上取决于它能不能拿到一份结构化的元器件清单。

这里的关键不是简单的For Each遍历，而是要注意数据过滤和字段规整。AD里一个PCB文件包含的东西太多了：铜箔、走线、过孔、丝印、板框……如果一股脑全读出来，AI会被海量数据淹没。所以我的策略是：只提取元件相关的信息，其余对象全部过滤掉。

def get_components(self): """提取PCB或原理图中的元器件信息""" doc = self.get_current_document() components = [] if "PCB" in str(doc.DM_ObjectKind): # 从PCB文档中提取 pcb = doc iterator = pcb.BoardIterator_Create() iterator.AddFilter_ObjectSet(MkSet(ePCBComponent)) iterator.AddFilter_LayerSet(AllLayers) comp = iterator.FirstPCBObject() while comp: component_data = { "designator": comp.Identifier.Text, # 位号 "layer": str(comp.Layer), "x": round(comp.X * 0.01, 2), # AD内部单位是10um，转成mm "y": round(comp.Y * 0.01, 2), "rotation": comp.Rotation, "footprint": comp.Pattern, # 封装名称 "comment": comp.Comment.Text, # 注释/值 "part_number": getattr(comp, 'MfrPartNumber', '') # 料号 } components.append(component_data) comp = iterator.NextPCBObject() pcb.BoardIterator_Destroy(iterator) elif "SCH" in str(doc.DM_ObjectKind): # 从原理图文档中提取 sch = doc iterator = sch.SchIterator_Create() iterator.AddFilter_ObjectSet(MkSet(eSchComponent)) comp = iterator.FirstSchObject() while comp: component_data = { "designator": comp.Location.Text, "x": round(comp.Location.X / 10, 2), # 单位换算到mm "y": round(comp.Location.Y / 10, 2), "rotation": comp.Orientation, "footprint": comp.Footprint, "comment": comp.Description } components.append(component_data) comp = iterator.NextSchObject() sch.SchIterator_Destroy(iterator) return components

这个函数我写的算比较完整了，可以通过CurrentDocument判断当前打开的是原理图还是PCB，然后分别用不同的迭代器去提取。需要特别注意的是单位换算，AD内部使用的单位是10um（PCB）和1/10mil（原理图），如果不在源头转好，后面AI读到的数据全是乱的。

3.3 把AI的“双手”接到AD上：定义高价值工具集

元器件列表只是一个开始。要让AI真正称得上“助手”，手里得有足够多的工具。我在自己的MCP Server上已经挂了十几个工具函数，这里我列几个最有代表性、也最能体现“深度集成”价值的：

工具一：查询元器件详细信息

@mcp.tool() def query_component_details(designator: str) -> str: """根据位号查询单个元器件的详细信息，包括坐标、封装、值、网络连接等""" # 实现类似上面的查询，但只返回单个元件 ...

这个工具让AI可以针对性地了解某个细节。比如你问“U3芯片的电源引脚接了哪些电容”，AI先调用query_component_details("U3")拿到U3的引脚信息，再结合网络表内容找到与之相连的电容。

工具二：检查未连接的引脚

@mcp.tool() def check_unconnected_pins() -> str: """检查当前原理图中所有未连接的引脚，返回未连线引脚列表和位置信息""" # 遍历所有元件，检查每个引脚的连接状态 ...

这个工具非常实用。原理图里漏画一条线、忘记放一个电源符号，AI一眼就能扫出来。实现原理不算复杂，遍历原理图里每个元件的每根引脚，检查是否有一个以上的连接点即可。如果没有连接点，就记录下这个引脚的位号和引脚名。

工具三：元器件库模糊搜索

@mcp.tool() def search_component_library(keyword: str) -> str: """搜索Altium Designer元件库中的元器件，返回匹配的库条目""" # 遍历AD自带的库文件，按关键词匹配 ...

布线的时候集成库检索很烦人，我在现网用的时候发现这个工具特别受用。比如你想找一颗适合做Buck电路的电源芯片，一句“帮我找一颗输入电压20V以上、输出电流3A、带EN使能的DC-DC芯片”，AI就能自动去AD库里面匹配。

工具四：布局密度热力图分析

这个工具稍微高级一点，需要结合PCB文件里的元件坐标来计算。原理是先对板子区域做栅格化处理，再统计每个栅格内元件的数量，最后把密集区域标记出来，给出拥挤度排名。AI有了这个分析结果，就能给出合理的布局调整建议。

这些工具的背后，都是AD本身就能完成的动作。MCP协议的作用是让AI能够“学会”调用它们，而且调用完之后能理解返回结果。

3.4 配置AI客户端连接MCP Server

写完了MCP Server，接下来要做的就是让AI客户端连上来。我用的客户端是Claude Desktop，在它的配置文件claude_desktop_config.json里加上MCP Server的配置就行。

{ "mcpServers": { "altium-mcp-server": { "command": "python", "args": ["D:/workspace/altium_mcp_server.py"], "env": { "PYTHONIOENCODING": "utf-8" } } } }

注意这个PYTHONIOENCODING: utf-8，别看它不起眼，没有这行配置，中文输出到客户端的时候大概率会乱码，尤其是当库名、位号里有中文的时候。

连接成功后，在对话框里直接说“打开我桌面上那个PMIC电源板的原理图，帮我检查一下有没有漏连的引脚”，AI就会自动完成操作。如果你的AD还没打开对应的工程文件，也可以再加一个open_project工具，让AI直接调用来打开文件。

我试过用OpenAI接口对接本地部署的Qwen2.5-7B来跑这套MCP协议，效果也挺不错。因为所有工具调用的指令格式都是标准的JSON结构，只要模型的能力足够强，就能理解“什么时候该调用工具”这个逻辑。

4. 深度集成玩法：从查数据到改设计

4.1 原理图审查：让AI当你的“第一道质检员”

我现在日常使用频率最高的功能，就是让AI做原理图审查。以前画完原理图，全靠自己瞪大眼睛一条线一条线地过。现在我把这个工作交给了AI。

AI审查的维度相当丰富，我注入了不少硬件工程领域的审查规则。比如检查ERC（电气规则检查）标志物，AD在原理图里有一个ERCWarning对象，专门记录电气规则违规。AI可以通过MCP工具读取这些默认标记，然后给出解释和修正建议。

另一个更有意义的检查项是检查网络命名规范。很多公司内部的原理图规范，要求电源网络的命名必须带电压等级（比如VCC_3V3、VCC_5V0），地网络必须有明确的标识（GND、AGND、PGND），差分对必须有固定的前后缀。

我把这些规则写成JSON配置，挂到MCP Server里，AI在做设计审查的时候会自动加载这些规则。实测效果不错。有一回检查一块接口板的原理图，AI居然发现了一个我完全没注意到的问题：一个I2C的上拉电阻被接到了PWR_FLAG网络上，而没有真正连到电源。这种问题人眼极难分辨，因为原理图上两个网络的标号看起来就是相近的，但实际上一个接的是电源层，一个是测试点。

4.2 BOM管理与替代料建议

BOM表的管理也很占工程师时间。以前整理BOM都是手动复制到Excel里，再根据供应商网站判断是否缺货、有没有替代料。这套AI+EDA的方案也把这个流程打通了。

MCP Server里定义了一个parse_bom工具，从当前原理图直接生成BOM数据。关键是可以直接对接供应商API或本地的现货表，拿实时库存和价格数据。我在自己的方案里对接的是本地Excel库存表，里面记录了常用料的价格、库存、最小起订量等。AI会把这些信息整理成一份报告：这颗料库存紧张，建议提前备货；这颗料单价太高，可能有成本更低的替代方案。

最精华的地方在于：AI返回的报告不是冷冰冰的表格，而是带着分析逻辑的完整建议。它会告诉你，为什么替换成某颗料是合理的，因为封装兼容、电气参数相近，而且库存更充足。

4.3 布局走线评估：AI不是替代工程师，而是辅助决策

这个方向我不建议一上来就“全自动布局”这种危险选项，但确实可以做评估辅助。比如你完成一版布局后，可以让AI检查几个关键维度：

• 高速信号走线有没有跨分割
• 去耦电容和芯片电源引脚之间的距离是否合理
• 差分对的等长情况如何
• 热敏元件是否靠近了功率发热源

MCP Server端的工具主要是读取PCB数据，做规则分析后返回违规项列表。AI在这里扮演的角色是“评审专家”：帮你发现常见问题、给出修改优先级建议，而不是替你画走线。原因很简单，AI对信号的完整性和板子物理结构的理解，还没达到能独立完成专业布局的程度。在可预见的未来，它更适合做“审查者”而不是“设计者”。

这种AI辅助的模式，实际用起来的体验就很不一样了。以前我画完板子，得自己盯着每一个模块反复检查；现在更像是多了一个助手在旁边帮你过检，虽然不会完全替代你的判断，但确实能帮你把明显的问题先挑出来。

5. 常见问题与排查技巧实录

5.1 MCP Server启动失败的常见原因

这套流程里最容易出问题的环节，就是MCP Server的启动和连接。很多朋友第一次接触，按配置写完，启动报错就不知道怎么办了。我把自己的排查经验整理成了表格。

我见过不少人是卡在环境变量上的。如果你用了虚拟环境，记得在MCP Server配置里把python改成虚拟环境里Python的绝对路径，否则客户端会默认用系统Python去启动，导致依赖缺失直接起不来。

5.2 AD的API权限问题：一个让人抓狂的坑

AD的API权限系统很变态，默认情况下，外部程序能访问的AD功能是受限的。有些接口必须通过AD的Configure Platform菜单里的权限设置才能启用。

我踩过最深的坑，是用来读取PCB板框的接口，在未授权的情况下，AD直接返回空对象，代码不报错，但数据就是拿不到。那个时候排查了很久，几乎怀疑是代码逻辑出了问题。后来才知道，需要在AD的Preferences -> System -> Platform -> Permissions里面手动勾选允许外部程序访问板框数据。

如果你也碰到类似情况：脚本跑起来不报错、不崩溃、但返回的数据很诡异，就先去检查AD的权限设置。宁可多花几分钟在权限设置上，也不要浪费时间在代码里瞎调试。

另外一个经验是，使用GetActiveObject方式连接AD时，如果同时打开了多个AD实例，连接的是哪一个是不确定的。我的建议是：用这套系统之前先关掉所有AD窗口，只打开一个工程。否则AI读取到的可能是完全错误的文档。

5.3 模型上下文窗口不够用怎么办

AI能处理的上下文是有限的，这是所有基于大模型方案都要面对的问题。如果你把整个PCB文件的几千个元件全部塞给AI，再让它分析，它会直接拒绝，或者回答一些无关紧要的内容。

我的解决方案是“分级加载”。第一层只是让AI知道“板子上有哪些元件类别”，传输的是统计信息，比如电阻多少个、电容多少个、IC多少个、总元件数是多少。第二层才是详细数据，当用户问“找到U3旁边的所有去耦电容”时，AI才按需去加载那部分详细信息。

这个方法其实很像用户用户用地图App的体验：一开始看到的是概览图，放大了才能看到街道。

5.4 性能瓶颈：AD操作慢导致AI响应超时

AD的COM接口操作是同步的，读取一个大型PCB文件可能需要十几秒。而AI客户端调用外部工具的默认超时时间往往只有30秒。如果你连续调用了多个工具，很容易就把时间耗光了。

针对这个问题，我做了一个线程池的优化。把耗时的AD数据读取操作放到后台线程里，MCP工具先返回一个任务ID，AI轮询查询任务状态。这个方案的响应速度快很多，用户体验也更好。

但这里有一个新的问题：AD的COM接口在后台线程里调用，会出现线程模型不兼容的问题。解决方案是确保所有的AD操作都在同一个线程里串行执行，用队列把多个任务排队。我这边的代码是维护了一个ThreadPoolExecutor(max_workers=1)，强制单线程执行。

其实大多数情况下，不需要这个复杂的优化。只要保证工具粒度设计合理（每次只做一件事），并且控制一次会话中调用的工具次数，就不会触发超时。这里给个参考：一次完整的“原理图审查”会话，AI大概会调用6-9个工具，总耗时通常在30秒左右，不会超过你心里的舒适上限。

6. 扩展思路与落地场景：这套方案的想象力边界

6.1 企业级设计规范自动审查

如果你在一家有一定规模的公司里做硬件，一定知道企业设计规范这东西。一份好的设计规范通常有几十页，规定的都是细节：元件位号字体、丝印大小、走线最小线宽、阻抗控制要求、安全间距……这些规则让老工程师把新人的错误扼杀在摇篮里。

MCP协议这套方案，天然适合做这种规范检查的自动化。可以把企业的设计规范翻译成一条条规则，加载到MCP Server的检查工具里。AI在审查设计的时候，不光是检查AD自带的DRC规则，还会加载企业自定义的规范。哪个元件位号丝印太小、哪条走线间距不符合标准，AI直接列出修正清单。

这个方法我已经在一个朋友的公司试过，效果非常好。他们原来每次发板子给PCB厂之前，都要手动走一遍规范检查流程，耗时半天到一天。现在这个工作量缩短到了大约20分钟，而且由AI完成的。唯一的遗憾是目前只覆盖了大部分常用规则，还有一些需要人眼判断的检查项暂时无法替代。

6.2 跨团队协作的“AI翻译官”

硬件工程师和采购、生产、测试之间的沟通成本极大。随手举一个例子：工程师把PCB设计文件发给采购，采购看不懂原理图，只能拿到BOM表之后用Excel挨个查料。这个流程里，信息传递的损耗非常大。

我在MCP服务器上加了一个generate_report工具，可以自动生成面向不同角色的设计报告。给采购看的报告主要是BOM、价格、库存状态；给生产看的报告是装配图、标注了特殊工艺要求；给测试看的报告是测试点列表、背板信号定义。

AI在这里起到了一个“翻译官”的作用，把设计数据翻译成不同角色能快速使用的信息格式，面向不同的人给不同的输出。这个思路比起简单的“图纸自动化”来说，更贴近真实工作流里宕机的那一环节。

6.3 团队内AI协作模式：共同进化

最后说一个比较前瞻，但我已经在尝试的方向：让AI方案在团队里持续积累经验。我把每一次AI辅助设计的过程都记录下来，保存为Session记录。这些记录包含：用户提的问题、AI调用了哪些工具、用户后续手动做了哪些修正。

这些Session记录最终会沉淀成一个知识库。用这个知识库做一个RAG（检索增强生成）应用，后续其他工程师再遇到类似问题，AI就能参考之前的处理经验给出更准确的建议。本质上就是让这套系统越用越“懂”你们团队的做事风格和产品需求。

我已经跑了一段时间，目前这套MCP桥接方案最关键的价值反而不是“AI代替人干活”，而是“AI让人更愿意处理设计中的数据问题”。以前要做数据分析和规则检查，得专门写脚本、跑脚本、看日志，现在就是跟AI聊几句话的事，这种体验的变化才是能真正让硬件工程师接受AI的根本原因。

回头聊几句实操心得。这套方案里，最花时间的不是MCP本身，而是把AD的API接口摸清楚，尤其是那些数据类型的细节，不同版本的AD在返回数据的数值精度甚至字段名称上都有微妙差异。所以如果你准备落地，建议先固定AD版本，再动手写MCP工具，不然排查问题需要反复横跳，累感不爱。

最后再分享一个小技巧：你给MCP工具起的名字和写的描述，决定AI能不能正确用它。描述写得太笼统，AI不知道什么时候调；写得太窄，概率匹配不到。我自己琢磨出来的经验是，一个工具描述控制在80字以内，说明清楚功能、输入参数、返回数据格式，以及最常见的应用场景。这种打磨工具参数的功夫，跟当年调AI提示词是一个道理，工具即是“提示词”，命名和描述到位了，效果自然就出来了。