2026年6月8日，“微信公开课”公众号发布了一份看似低调的公告——《关于开发者接入微信AI生态的指引》。这份公告没有发布会的排场，没有刷屏的传播，但它对小程序的底层逻辑进行了一次根本性的重构。微信正在将小程序从“用户主动打开的入口”变成“AI主动调用的服务”——小程序开发者第一次有了将自身业务能力封装为AI可直接调用的“Skill”的标准化路径。
早在2026年一季度财报电话会上，腾讯管理层就明确表示：“小程序作为AI skills是会推进的方向”。6月8日的指引发布，正是这一战略的具体落地。对小程序开发公司而言，这不仅是技术升级，更是一次产品逻辑的重构——从为“人”设计界面，转向为“AI”设计接口。
一、两种模式：自动模式与开发模式的选择逻辑
微信给开发者提供了两条完全不同的AI化路径。
自动模式：零代码接入，适合快速占位
自动模式下，开发者只需在“小程序管理后台-AI能力”中主动授权，平台在提审时读取小程序源码，自动分析页面结构和功能，让微信AI能够直接操作小程序。开发者无需投入额外开发，平台会深度接管应用的AI逻辑，开发者能干预的空间很小。
这一模式的核心价值在于极低的接入门槛。对于缺乏AI开发能力的中小团队，自动模式是快速接入微信AI生态、抢占流量入口的最短路径。
开发模式：深度定制，适合复杂业务场景
开发模式下，开发者可基于小程序业务特性自主个性化开发，将功能抽象为原子接口和原子组件，封装成SKILL，供小程序AI调用。通过平台评测与审核后，可被微信AI调用。
开发模式适合有复杂业务逻辑、追求高精度AI调用体验的团队。代价是研发成本更高、审核周期更长，但控制权完全掌握在开发者手中。
两种模式不互斥，可同时开启。一个成熟的小程序可以先开自动模式快速接入，再逐步用开发模式打磨核心业务的Skill化封装。
二、Skill封装的技术规范：从“功能”到“可被AI调用的能力”
如果自动模式是让AI“看”懂你的小程序，那么开发模式就是让你主动告诉AI“我的小程序能做什么”。Skill封装的核心，是把传统“用户点按钮→跳页面→填表单”的流程，重构为“用户对话→AI理解意图→AI调用原子接口→返回结果”的对话式交互。
底层协议：微信版MCP
微信开放文档中公开的Skill技术规范，架构本质上就是MCP（模型上下文协议）。mcp.json声明每个原子接口的功能和参数，SKILL.md描述整个业务流程。微信没有另起炉灶，而是直接采用了行业正在收敛的标准。
一个小程序SKILL包含四个核心文件：
| 文件 | 作用 |
|---|---|
| mcp.json | 向AI声明有哪些函数、参数怎么填、用哪张卡片展示 |
| apis/*.js | 原子接口——真正执行业务的函数 |
| index.js | 把函数注册给运行时 |
| components/ | 原子组件——展示结果的卡片 |
| SKILL.md（可选） | 业务流程SOP，告诉AI这个场景的流程编排 |
注意力权重体系：写在哪里比写了什么更重要
微信官方文档给出了一套清晰的“注意力权重”体系。AI在决定调用哪个接口、生成什么参数时，不同信息源的优先级完全不同：
| 信息源 | 注意力权重 | 说明 |
|---|---|---|
| 原子接口返回的content | ★★★★★ | 离决策点最近，模型会把它当作“事实+动作”读取 |
| mcp.json里的接口description | ★★★★ | 影响模型“选不选这个接口” |
| mcp.json里的inputSchema.description | ★★★★ | 影响模型“怎么填参数” |
| SKILL.md | ★★★ | 适合写业务流程编排、跨接口规则 |
这意味着：同样的一条规则，写在接口返回里和写在SKILL.md里，AI给的权重完全不同。 最关键的指令应放在接口返回的content中，而非SKILL.md的长文描述中。
“事实+动作”两段式规范
接口返回有一条核心规范：先告诉AI“发生了什么”，再告诉它“下一步做什么” 。如果只写动作不写事实，AI可能把“展示卡片”理解成“准备调下一个接口”而跳过用户确认。
正确示例：先返回“已成功为您创建待办：买牛奶”，再返回“是否需要设置提醒时间？”——AI会基于事实做出下一步决策。
参数传递：优先用ID而非自然语言
参数传递优先用ID而非自然语言。比如门店传storeId而非省市街道，饮品传drinkId而非饮品名称。这直接减少了AI的推理负担和参数歧义。
三、UI设计如何适配AI调用
当小程序的主要交互对象从“人”变成“AI”时，UI设计的逻辑也需要随之调整。微信官方文档以WeStoreCafe点单SKILL为参考案例，梳理了核心设计点。
对话承接模糊意图
用户表达“想喝点清爽的”“最近有什么推荐”这类非结构化需求时，由AI完成理解和推荐，再引导至原子组件完成确认和下单。这意味着小程序需要设计“可被AI理解并推荐”的商品/服务数据结构，而非仅依赖用户主动搜索。
自然语言修改内容
用户无需跳出对话，可直接对话修改规格、时间、地点等字段。例如用户说“换成大杯”“改到明天下午”，AI应能识别并调用对应接口更新参数。
历史数据可查询、可操作
“再来一杯上次喝的”“用积分兑换一张优惠券”这类指令应可被执行。高频消费场景下，用户的核心诉求是效率——AI应能访问用户历史数据并完成操作。
按钮文案的AI化适配
传统UI中，按钮文案是为“人”设计的——“确定”“取消”“提交”。但在AI调用场景下，按钮文案的功能是向AI传递状态信号。例如，“确认下单”比“确定”更能让AI明确当前步骤已完成、可进入下一环节。按钮状态变化（如“已支付”“已完成”）也应通过接口返回的content准确传递，让AI能基于“事实”做出下一步决策。
四、开发者行动指南
第一步：去后台开自动模式。 路径：“小程序管理后台-AI能力”。目前处于内测阶段。自动模式零成本，先让AI能“看懂”你的小程序。
第二步：梳理核心业务场景，决定是否需要开发模式。 如果你的小程序有复杂的交易、预约、查询等流程，建议启动开发模式，将核心功能封装为Skill。
第三步：按Skill规范完成封装。 重点关注：mcp.json的接口描述要清晰（四星权重）、接口返回的content要遵循“事实+动作”两段式（五星权重）、参数优先用ID传递。
第四步：关注微信AI智能体的正式上线时间。 指引补上的是“小程序这一侧”的拼图。据多家媒体报道，腾讯正在测试微信内置的AI智能体原型，入口设在微信主界面，用户右滑即可调出对话窗口。当微信AI智能体正式上线，这场变革才真正开始。
五、结语
微信AI Skill化改造的本质，是小程序从“为人类设计的界面”向“为AI设计的接口”的范式转移。当微信把数百万个小程序变成AI可调用的Skill，当用户获取服务的方式从“搜索”变成“对话”，小程序的开发逻辑正在被重新定义。
微信拥有一种独特的“上帝视角”——每一个小程序的代码，从开发者提交、到微信审核、到最后在用户手机上运行，全程都在微信的技术体系内。这个架构优势，苹果没有，Google也没有。它让“自动模式”能够成立——开发者一行代码不用写，开个开关，微信自己就能把你的小程序翻译成AI可以调用的工具。
对小程序开发公司而言，这不是“要不要接”的问题，而是“不接就会掉队”的问题。当AI成为新的流量分发入口，那些率先完成Skill化改造、抢占AI调用优先级的小程序，将在下一阶段的流量分配中获得不可逆的先发优势。
