用 MCP 打通微信 SDK：在 Cursor 和 VS Code 中实现 AI 辅助开发

做了几年微信接口开发的朋友，多少都有过这种状态：真正花在业务上的时间其实不多，大量时间耗在签名校验、access_token 缓存、消息加解密、SDK 版本变更这些“体力活”上。即便有 Senparc.Weixin 这种成熟开源 SDK 打底，写公众号菜单、模板消息、用户画像相关代码时，还是得一遍遍翻文档确认参数。我最近把 Senparc.AI、微信 SDK 和 MCP 三样东西接在一起，在 Cursor 和 VS Code 里搭了个“微信 AI 开发助手”，实测下来确实能省下不少重复劳动——只要用自然语言描述需求，IDE 里的 AI 会自己去查 token、读接口返回、生成可直接落地的代码。这是系列第二篇，重点讲怎么把它接进 Cursor、VS Code 这类编辑器里，实现真正意义上的“自动编写”。适合正在做公众号、小程序、企业微信的 .NET 工程师，也适合准备在团队里推广 AI 辅助开发的技术负责人。

1. 整体设计：微信 SDK、Senparc.AI 与 MCP 到底怎么分工

1.1 三个组件的定位与分工

先说清楚这套东西里每个角色干什么活，别一上来就混在一起。

• 微信 SDK（Senparc.Weixin）：负责跟微信服务器打交道。你不需要自己拼请求、算签名、解 AES 消息体，SDK 把这些脏活全封装了。比如公众号自定义菜单、模板消息、用户标签，都是调用 SDK 里现成的方法就行。
• Senparc.AI：负责 AI 这一侧的调度。它把大语言模型接进来，处理 Agent 的任务规划、上下文维护、多轮对话，让 AI 不是“一问一答”，而是能自主决定“我现在需要调哪个工具”。Senparc.AI 本身支持替换不同模型供应商，这给了团队很大的灵活性。
• MCP（Model Context Protocol，模型上下文协议）：负责把“AI 的能力”和“微信 SDK 的能力”连起来。它定义了统一接口，让 IDE 里的 AI 客户端可以通过标准协议调用外部工具——也就是把微信 SDK 的方法包装成 AI 能直接“使用”的工具。

打个比方：微信 SDK 是厨房里的锅碗瓢盆，Senparc.AI 是厨师的大脑，MCP 是厨师的手。没有 MCP，大脑再聪明也够不到锅；没有 Senparc.AI，工具摆在那也没人指挥。

1.2 为什么选择 MCP 而不是普通插件

之前很多人做“AI 写微信代码”都是两种路子：一种是靠 Prompt 把 SDK 文档灌给 AI，告诉它“按这个文档写代码”；另一种是自己写一个 IDE 插件，监听编辑器事件再调用模型。这两种我都试过，问题很明显：

• 纯 Prompt 方案：AI 对 SDK 的记忆是静态的，你喂的文档版本一旦落后，它就可能编造不存在的 API 名称，写出来的代码根本编译不过。而且它拿不到真实的 access_token，很多代码只能“靠猜”。
• 自研插件方案：工作量大，要同时适配 Cursor、VS Code 各自的插件机制，还要处理跟不同模型的兼容问题，维护成本高到不值。

MCP 的价值在于它成了业界的通用标准。你只需要写一个 MCP Server 把微信 SDK 暴露成工具，Cursor 能连、VS Code 能连，以后别的 IDE 支持 MCP 了同样能连。这就像 USB-C 接口——以前每个设备一根线，现在统一了，生态里所有设备都能插。对团队来说，这意味着 AI 基础设施只建设一次，就能在所有编辑器里复用。

1.3 方案的适用场景与边界

这套东西不是万能的，我在实际落地中划了一条清晰的边界：

• 适合做：生成公众号自定义菜单配置、模板消息代码、查询用户信息、批量拉取粉丝列表、校验微信签名、生成 JS-SDK 初始化代码，这些“查询/生成”类操作非常适合走 MCP。
• 要谨慎做：真正往线上发送消息、改菜单、群发通知这类“写”操作，我建议先让 MCP 返回代码和参数预览，人工确认后再执行。直接在 IDE 里让 AI 调 MCP 把线上菜单改了，风险太大，搞不好线上事故就来了。
• 团队落地建议：查询类工具全量开放，写操作一律做成 dry-run（试运行）模式，输出 JSON 或代码给人看，而不是直接调微信 API。等团队成员都熟了，再按需放开部分可控的写权限。

2. 核心原理：MCP 怎么把微信能力递给 IDE 里的 AI

2.1 Tool、Resource、Prompt 三个核心原语

MCP 定义了三种能力类型，理解它们才能设计出好用的微信助手。

• Tool（工具）：这是用得最多的。它让 AI 能执行一个确定的函数，比如get_user_info(openid)、get_access_token()、generate_menu_json(config)。Tool 必须有清晰的参数定义，AI 会根据你的描述决定什么时候调它、传什么参数。
• Resource（资源）：可读取的数据。比如当前公众号的基本信息、access_token 缓存状态、最近几天的消息记录，AI 可以像读文件一样读这些内容，用于理解上下文。
• Prompt（提示模板）：预设好的指令片段。比如“把下面这段需求转换成一整套自定义菜单 JSON，并检查二级菜单数量是否超限”。团队可以把公司规范沉淀成模板，AI 每次执行时自动套用。

设计微信助手时，我主要用 Tool 把 SDK 接口包一遍，用 Resource 暴露一些基础配置，再用 Prompt 约束输出格式。三者配合起来，AI 才不会把技术文档写出一股“幻觉味”。

2.2 stdio 与 HTTP：两种传输方式怎么选

MCP 传输层有两种方式，做 IDE 接入时先要搞清楚选哪个：

传输方式	原理	适用场景	优点	缺点
stdio	IDE 启动子进程，通过标准输入输出通信	单机开发、个人使用	配置简单、无端口冲突、安全性高	无法跨机器共享
HTTP / SSE	独立服务，IDE 通过 HTTP 请求访问	团队共享、远程使用	可部署到服务器供多人使用	需要管理端口、鉴权、网络策略

我的建议是：开发期用 stdio，团队共享用 HTTP。stdio 模式下，出错时直接在终端窗口看日志，排查问题非常直观。HTTP 模式适合放到 CI 环境或者团队内网服务器，一个服务大家共用。不过要注意，HTTP 模式的 Server 一定要加上访问凭证，否则任何人都能调你的微信能力。

2.3 Cursor 和 VS Code 的接入差异

两者虽然都支持 MCP，但接入细节有些不同，我先说清楚，后面实操不踩坑。

• Cursor：项目根目录放.mcp.json即可，配置好之后刷新一下，AI Agent 会自动发现工具。Cursor 的 GUI 设置里也能看到 MCP 工具是否连接成功，还能单独开关。
• VS Code：需要vscode/mcp.json文件，同时要求你装了支持 MCP 的 Chat 类扩展（GitHub Copilot Chat 或 Claude Code 等）。VS Code 的字段格式在近几个版本里有过调整，有的版本用顶层servers，新版逐渐向mcpServers对齐，配置时以本地扩展提示为准。

另外，两者都支持在调用工具前弹出确认框，这个务必打开。AI 要执行有副作用的操作时，至少给你一个“刹一脚”的机会。

3. 实操：把微信开发助手接进 Cursor 与 VS Code

3.1 工程准备：创建一个轻量 MCP Server

我用的是 .NET 8 环境，过程比想象中简单。先建一个最小的 Web 项目，顺便加上微信 SDK 和 MCP 相关依赖：

dotnet new web -n WechatMcpServer cd WechatMcpServer dotnet add package Senparc.Weixin.MP dotnet add package Senparc.Weixin.MP.MVC dotnet add package ModelContextProtocol.AspNetCore

注意：以上包名以你当前 NuGet 上的最新版本为准。MCP 官方的 .NET SDK 更新很快，版本号我见过 0.3.x，使用前最好去 NuGet 确认。

为什么要建 Web 项目而不是控制台项目？因为 Web 项目既能以 stdio 方式跑，也能以 HTTP 方式跑，后面想部署到团队服务器时不用重写代码。一举两得。

3.2 核心代码：把微信 SDK 能力包装成 AI 可调用工具

核心就一件事：把 Senparc.Weixin 的方法包装成带[McpServerTool]特性的方法。AI 看到这些方法，就像看到一本“接口说明书”，会自动决定何时调用。

我在Program.cs里先注册 MCP 和微信 SDK：

var builder = WebApplication.CreateBuilder(args); builder.Services.AddMcpServer(); builder.Services.AddSenparcWeixinServices(builder.Configuration); var app = builder.Build(); app.MapMcp(); app.Run();

然后定义一个工具类，把常用的微信操作包进去。这里我举两个最典型的例子：获取 access_token 和生成自定义菜单配置。

using ModelContextProtocol; using ModelContextProtocol.Server; using Senparc.Weixin; using Senparc.Weixin.MP.AdvancedAPIs; [McpServerToolType] public static class WechatTools { [McpServerTool] public static async Task<string> GetAccessToken(string appId) { // 通过 Senparc.Weixin 的缓存机制获取/刷新 access_token var token = await AccessTokenContainer.TryGetAccessTokenAsync(appId); return $"当前 appId {appId} 的 access_token 获取成功，过期时间为 7200 秒"; } [McpServerTool] public static async Task<string> GenerateMenuJson( [McpServerToolParameter] string menuJsonConfig, bool dryRun = true) { var menuButtonGroup = JsonConvert.DeserializeObject<ButtonGroup>(menuJsonConfig); if (dryRun) { // 不真正调用微信接口，返回代码预览供人工确认 return JsonConvert.SerializeObject(new { dryRun = true, message = "以下配置请人工确认后在正式环境点击发布", config = menuButtonGroup }, Formatting.Indented); } var accessToken = await AccessTokenContainer.TryGetAccessTokenAsync("your_appId"); await MenuApi.CreateMenuAsync(accessToken, menuButtonGroup); return "菜单发布成功"; } }

注意几个设计细节，都是实际踩过坑换来的经验：

• dryRun 参数放在方法里，AI 默认走试运行，不会真的动线上菜单。这个设计让“AI 自动写代码”和“人为发布”安全分离。
• access_token 不用每次现取，Senparc.Weixin 自带缓存容器，直接调TryGetAccessTokenAsync就能拿到合法 token，比自己写缓存靠谱得多。
• 方法注释要写清楚：MCP 描述里标注“生成公众号自定义菜单 JSON”比只写“菜单”效果强很多，AI 什么时候调用这个方法，很大程度上取决于这段描述。

3.3 在 Cursor 中配置 MCP 并验证

先启动你的 MCP Server：

dotnet run --project WechatMcpServer --urls http://localhost:5100

然后在项目根目录创建.mcp.json：

{ "mcpServers": { "wechat-dev-assistant": { "url": "http://localhost:5100/mcp" } } }

Cursor 里打开 MCP 设置面板，刷新一下，如果看到wechat-dev-assistant显示 Connected，说明连接成功。

验证方式很简单：直接在 Cursor 的对话窗口里问一句“你现在有哪些工具？”，AI 会告诉你它可以通过 MCP 调用GetAccessToken和GenerateMenuJson。到这一步，IDE 就已经“长出手”了。

3.4 在 VS Code 里配置 MCP 并验证

VS Code 里步骤类似，项目根目录建.vscode/mcp.json：

{ "servers": { "wechat-dev-assistant": { "type": "http", "url": "http://localhost:5100/mcp" } } }

如果你的 VS Code 版本显示字段不认识，换成mcpServers顶层键再试一次。VS Code 近几版对 MCP 配置字段有调整，很多朋友在这一步卡住——先看官方 schema，再动手写，能省不少时间。

配好后需要装一个支持 MCP 的 Chat 扩展。GitHub Copilot Chat 支持得最完整，Claude Code 插件也不错。打开对话面板，如果你能看到 MCP 工具列表加载出来了，就说明 AI 已经准备好帮你调微信接口了。

3.5 实战演示：一句需求让 AI 自动生成菜单配置

这是我最喜欢演示的环节。在 Cursor 里我输入这么一句话：

帮我生成一个公众号自定义菜单配置，一级菜单三个，分别是“产品矩阵”“技术博客”“联系客服”，二级菜单里博客下面放“最新文章”和“历史沉淀”，每个菜单项都配上合适的 action 类型。

AI 的完整行为链路是这样的：

1. 它先判断这属于“创建菜单配置”任务，发现 MCP 里有GenerateMenuJson工具。
2. 因为 dryRun 默认是 true，它把需求转成一份结构化 JSON 作为参数传入。
3. MCP Server 返回格式化后的菜单配置，并提醒“以下配置请人工确认”。
4. AI 基于返回结果，把配置整理成可读性更好的代码/文档给用户。

实际生成的菜单 JSON（格式参考）：

{ "button": [ { "name": "产品矩阵", "type": "click", "key": "PRODUCT_MATRIX" }, { "name": "技术博客", "sub_button": [ { "name": "最新文章", "type": "view", "url": "https://yourblog.example.com/latest" }, { "name": "历史沉淀", "type": "view", "url": "https://yourblog.example.com/archive" } ] }, { "name": "联系客服", "type": "click", "key": "CONTACT_SERVICE" } ] }

整个过程中我没写一行代码，只是描述了需求。AI 因为能通过 MCP“看到”真实的 access_token 状态、SDK 结构和返回格式，生成的结果编译通过率比我之前纯 Prompt 方案高太多了——后者经常发明一些MenuApi.Create这种根本不存在的接口。

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

4.1 工具列表加载不出来或显示 disconnected

这个问题的出现频率最高，原因也最杂。先说排查顺序：

• 用浏览器或 curl 直接访问 MCP Server 地址，看服务是否真的在跑。
• 看怎么启动的。stdio 模式下，IDE 启动的是本地进程，终端日志会直接显示错误；HTTP 模式下要检查端口是否被占用、防火墙是否放行。
• Cursor 配置里如果写了command但实际服务是 HTTP 的，就会 disconnected。一个原则：用什么传输方式，就配对应的配置，别混着来。

我遇到过最怀的情况是dotnet run启动正常，但 Cursor 里一直连不上——后来发现是.mcp.json放在了一个子目录，Cursor 只认项目根目录的配置文件。

4.2 工具能列出但调用就报错

工具列出来了，说明协议层没问题，但一调用就报错，多半是参数问题。

AI 虽然会读工具描述，但不能保证它每次都能传对参数。比如你的方法是GenerateMenuJson(string menuJsonConfig, bool dryRun = true)，AI 可能把一层对象直接传进来，而不是 JSON 字符串。你需要在方法开头做防御性解析，把参数兼容做好。

另外，AI 返回的错误信息往往很敷衍，所以你自己要在 Server 把所有异常 catch 住，返回让人看的错误描述。比如“access_token 获取失败：不合法的 appId”，这样 AI 才能根据错误信息自己修正。

4.3 access_token 过期与重复获取

这个问题在微信开发里基本无解，憋着一直存在，只能靠缓存机制降低频率。用 Senparc.Weixin 自带的AccessTokenContainer，它内部做了分布式锁和缓存，多个并发请求不会重复刷新 token。

但要注意一点：如果你在 MCP Server 里自己写了个静态字段存 token，那就埋了一颗雷。这台 Server 一重启，内存里存的 token 就没了，又得重新走一遍刷新逻辑。所以一律用 SDK 的容器，别自己造轮子。

4.4 AI 编造不存在的 SDK 接口

这是最打击“用 AI 写微信代码”信心的问题。MCP 能缓解但不能 100% 解决，因为 AI 还是会根据它的“记忆”生成部分代码。我的经验是：

• 把 Tool 的描述写得像“接口清单”，并附上真实可用的代码示例。
• 通过 Prompt 模板约束 AI，让它“所有涉及 SDK 调用的代码必须基于当前工具返回的信息”。
• 关键调用（比如 MenuApi）可以做成 MCP 工具，让 AI 不要自己 new 类，而是调工具拿结果，然后基于结果做二次包装。

这样即使 AI 对细节不熟，最少核心部分不会编。

4.5 权限与安全：防止 MCP 变成破坏性入口

MCP 本质是给 AI 开了一扇“执行代码/调用接口”的门，权限控制不到位，后果很严重。

• 不要把 appSecret、微信支付 key 这些敏感信息写在 MCP 配置或代码里，必须走环境变量或专用配置中心。
• HTTP 模式不要绑定 0.0.0.0，只绑内网地址；如果必须对外开放，加一层简单的 API Key 鉴权。
• 在 IDE 里把“工具调用需要确认”关掉的人，我劝你打开。线上发布菜单、群发消息这种操作，必须人工点头。
• 内部审计别少。MCP Server 每次调用都记个日志，谁在什么时间执行了什么写操作，出了事能追溯。

5. 一些没写在文档里的体会

这套东西我实际跑了小一个月，最大的感受是：MCP 改变了 AI 编程助手的“靠谱程度”。以前它是个嘴硬的理论派，现在它是个能自己查资料、自己验结果、自己不胡编的实习生——虽然还是要你兜底，但省心太多了。

接着这个方向还有几个拓展空间：一是把企业微信、小程序的 SDK 能力也暴露成工具，不只是公众号；二是把 MCP Server 部署到团队内网，让大家共用一套“微信能力中心”，配合 CI 阶段自动做代码校验；三是结合 Senparc.AI 的 Agent 编排，做一个更完整的“微信运营助手”，不但能写代码，还能自动汇总数据、生成日报。我自己下一步准备在项目里加上一套基于 MCP 的自动化接口回归，让 AI 写完代码顺手就把微信接口的连通性也验了。这个内容后续实战跑通了再来分享，有兴趣的话可以先在本地把今天这套连接流程过一遍，感受一下“AI 帮你写微信代码”的变化有多大。