微信小程序AI模式开发者该怎么接

以前做小程序，开发者最关心的是：页面怎么排、按钮放哪里、怎样让用户少点几步。

现在，一个新的问题出现了：当用户不再主动打开页面，而是直接对AI说出需求，你的小程序能力能不能被AI找到、理解并正确调用？

微信官方已经给出一条技术路径——小程序 AI 开发模式（beta）。它不是给小程序加一个聊天框，而是让开发者把业务能力封装成 Skill，供小程序 AI 在对话中调用。

这把竞争又往前推了一步：以前比页面和入口，现在还要看业务能力能否被AI准确调用。

Skill是什么：不是提示词，而是完整能力包

按照官方定义，Skill 是“完成特定场景任务的完整能力封装”。一个小程序可以封装多个 Skill，内容包括业务说明、模型可调用能力声明，以及原子接口、原子组件的实现。

可以把它理解为一份给AI使用的“业务工具箱”：

组成	通俗理解	主要职责
mcp.json	能力目录	声明有哪些接口、参数怎么填、结果用什么组件展示
SKILL.md	业务说明书	描述跨接口流程、依赖关系和不可违反的规则
原子接口	可执行动作	完成查询、新增、修改等单一业务功能
原子组件	结果卡片	把结构化结果渲染成对话中的可视化界面

例如，待办小程序可以提供“新增待办”“查看待办”“完成待办”三个原子接口。用户说“帮我记一下明早九点交报告”，小程序 AI 根据小程序 MCP 协议分析意图、选择接口并填写参数；接口执行后，原子组件再把最新待办渲染成卡片。

这里要区分两个概念：**原子接口负责做事，原子组件负责展示。**接口运行在微信客户端独立的 JS 环境中；组件把结构化结果变成对话中的 GUI 卡片。需要进入完整小程序时，还可通过“页面接力”承接。

这不是让AI随意操控整个小程序，而是开发者先明确开放哪些能力、输入输出是什么、调用时遵守什么约束，再由AI在这个边界内编排执行。

为什么重要：小程序开始从页面走向能力

传统链路是进入小程序、寻找功能、点击操作。Skill 带来的链路则可能变成：用户表达意图，AI选择能力，接口完成任务，组件返回结果。

改变的不只是交互方式，还有产品设计重心。

接口说明开始影响服务能不能被找到。接口名称、适用场景、参数来源和缺失处理写得越清楚，AI越可能选对工具、填对参数。开发者除了优化页面路径，还得回答“AI怎样理解我的业务”。

服务也要拆得更小。查库存、建预约、看进度、改地址，都可以成为边界清晰的原子能力。AI可以围绕用户目标串联步骤，不必让用户逐页寻找入口。

对话也不等于纯文本。原子组件能把结果变成卡片，用户可以点击继续操作，小程序原有的可视化体验仍然保留。

当然，这仍是 beta 能力，当前应把它看作一个明确的产品方向和试验窗口，而不是已经覆盖所有小程序、所有用户的新流量入口。

开发者现在如何准备

第一步不是把全部业务搬进 Skill，而是挑一个高频、边界清楚、容易验证的任务做最小闭环，例如查询订单、创建待办或预约时段。

然后把大流程拆成单一职责的原子接口。每个接口都要明确：何时调用、参数从哪里来、缺少参数时如何追问、成功与失败怎样判断。尤其是 ID、金额、地址等关键参数，不能允许模型根据自然语言“猜一个”。

如果使用微信云开发，官方给出的路径会更短：原子接口可通过 wx.cloud.callFunction 调用云函数，或在只读场景直连云数据库；云函数里可以通过 cloud.getWXContext().OPENID 获取当前用户身份，无需在小程序端自行传递 OPENID，也不必重复维护一套登录态。

但要注意环境边界：目前 wx.cloud 相关 API 可用于原子接口环境，原子组件环境暂不支持。数据获取应由接口完成，再通过 structuredContent 交给组件；组件主要负责渲染和交互。

接入也不是默认开放。官方指南将该模式明确标为 beta，开发者需在网页端“微信公众平台—基础功能—AI能力”，或小程序“微信开发者助手—管理—微信AI管理”中，选择“开发模式”提交申请。开发调试需使用微信开发者工具 Nightly Electron Build 最新版本；云开发指引还列出了基础库版本不低于 3.16.1、已开通云开发环境等前置条件。能否申请和实际开放范围，应以后台展示及最新官方文档为准。

免鉴权不等于免安全：行动清单

最容易被误解的是“OPENID 自动注入”。它解决的是识别用户是谁，不是自动证明“这个用户有权操作这条数据”。

AI生成的参数仍然是不可信输入。删除、修改、支付、授权等敏感操作，不能因为来自AI就降低校验标准。云函数仍需做类型、长度、范围、状态和所有权检查；更新数据时，应同时用资源 ID 与 OPENID 限定目标，防止越权。

建议开发团队立即完成这份清单：

• □ 申请开发模式权限，确认账号是否处于开放范围；
• □ 选出一个低风险、高频场景，拆成少量原子接口；
• □ 在 mcp.json 写清参数来源、缺失处理和禁止编造规则；
• □ 用 SKILL.md 描述跨接口流程、成功条件与业务铁律；
• □ 写操作统一放到云函数，服务端再次校验全部参数；
• □ 依据 OPENID 做数据所有权校验，只读直连配置严格安全规则；
• □ 原子组件只接收必要的结构化数据，不暴露密钥与敏感字段；
• □ 对高风险动作增加明确确认、审计、限流和可撤销设计；
• □ 用 Nightly 开发者工具反复测试歧义、缺参、失败和越权场景。

这套模式的价值很具体：用户说出目标，AI理解并调度，小程序提供结构化、可执行的服务能力。

现在适合做小范围试验，不适合把全部业务一次性搬进去。先选一个低风险任务，看看AI是否能稳定选对接口、补齐参数，并在失败时给用户明确反馈。跑通以后，再决定是否扩展。

如果只能先把一个功能封装成 Skill，你最希望AI替用户调用哪项小程序服务？

参考资料：微信官方《小程序 AI 开发模式（beta）接入指南》《基于微信云开发构建小程序 Skill》。具体开放状态、申请条件与接口能力请以官方最新文档及后台为准。