做了几年微信接口开发的朋友多少都有过这种状态真正花在业务上的时间其实不多大量时间耗在签名校验、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 三个组件的定位与分工先说清楚这套东西里每个角色干什么活别一上来就混在一起。微信 SDKSenparc.Weixin负责跟微信服务器打交道。你不需要自己拼请求、算签名、解 AES 消息体SDK 把这些脏活全封装了。比如公众号自定义菜单、模板消息、用户标签都是调用 SDK 里现成的方法就行。Senparc.AI负责 AI 这一侧的调度。它把大语言模型接进来处理 Agent 的任务规划、上下文维护、多轮对话让 AI 不是“一问一答”而是能自主决定“我现在需要调哪个工具”。Senparc.AI 本身支持替换不同模型供应商这给了团队很大的灵活性。MCPModel 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 里的 AI2.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 接入时先要搞清楚选哪个传输方式原理适用场景优点缺点stdioIDE 启动子进程通过标准输入输出通信单机开发、个人使用配置简单、无端口冲突、安全性高无法跨机器共享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 Code3.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 和微信 SDKvar 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 Taskstring GetAccessToken(string appId) { // 通过 Senparc.Weixin 的缓存机制获取/刷新 access_token var token await AccessTokenContainer.TryGetAccessTokenAsync(appId); return $当前 appId {appId} 的 access_token 获取成功过期时间为 7200 秒; } [McpServerTool] public static async Taskstring GenerateMenuJson( [McpServerToolParameter] string menuJsonConfig, bool dryRun true) { var menuButtonGroup JsonConvert.DeserializeObjectButtonGroup(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 Serverdotnet 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 的完整行为链路是这样的它先判断这属于“创建菜单配置”任务发现 MCP 里有GenerateMenuJson工具。因为 dryRun 默认是 true它把需求转成一份结构化 JSON 作为参数传入。MCP Server 返回格式化后的菜单配置并提醒“以下配置请人工确认”。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 帮你写微信代码”的变化有多大。