微信小程序AI开发模式：SKILL别合正式提审

微信小程序AI开发模式：SKILL怎么封装，为什么千万别合进正式提审

独立开发老李｜Android / 嵌入式 / 小程序全栈
2026 热点：小程序入口正在从「打开页面」变成「模型调用能力」。热归热，内测代码合进正式提审，才是最容易把线上版本搞砸的一步。

微信已经给出两条路径（自动模式 / 开发模式）。
开发模式的核心不是再写一堆页面，而是把业务封装成 SKILL，让小程序 AI 通过小程序 MCP 选接口、出卡片、再接力回小程序页。

本文按工程通关写：概念怎么分、SKILL 怎么切粒度、内测期必须锁死的分支策略。
（官方文档仍在 beta；细则以微信当期文档为准。）

先看官方红线：现在别合进正式版

官方《小程序 AI 开发模式（beta）接入指南》写得很直白：

当前处于内测阶段，暂未开放小程序 AI 开发模式的代码提审，提审时间将另行通知。
请勿将此模式相关代码合入正式版本提交审核，以免影响正常版本发布。

独立开发 / 外包交付里，最常见翻车是：

• Demo 能聊，顺手把 AI 模式注册入口打进主包
• 正式版提审被拖累，甚至影响正常发版
• 客户以为「AI 入口已经上线」，实际官方还没放行提审

一句话：

契约、文档、分支可以先做；合包提审必须等官方开放。

两种模式：责任边界完全不同

维度	自动模式	开发模式（本文重点）
能力来源	平台读源码，分析页面/API/数据模型后生成	开发者自己抽象原子接口/组件，封装 SKILL
可控点	页面语义是否可读、状态是否可判	接口契约、参数、返回、卡片形态
适用	查询类、短链路	高频任务、多步确认的办理类
风险	文案省略、状态只靠颜色 → 模型读不懂	接口切错粒度、描述漂移、办理与查询混装

开发模式申请入口（文档口径）：

• 网页端：微信公众平台 → 基础功能 → AI 能力 → 选「开发模式」申请
• 或：微信开发者助手 → 管理 → 微信 AI 管理

调试需 微信开发者工具 Nightly Electron Build 最新版。Demo 的 appid 也要换成已申请开发模式的 appid。

五个概念：别把「页面」当成「任务」

官方基本对象可以记成一条链：

用户对话 → 小程序 MCP 选 SKILL/原子接口 → 原子组件出卡片 → 页面接力进小程序

概念	一句话
小程序 MCP	向小程序 AI 暴露可调用能力的协议（适配小程序，不等于通用 MCP 照搬）
原子接口	最小执行单元；标准化入参/出参；跑在独立 JS 环境（不是普通页面环境）
原子组件	把结构化结果渲成对话流里的 GUI 卡片（文档标注：暂不支持调试）
页面接力	卡片点进去，把结构化数据带到小程序页展示；接力页配置会影响评测与调用效果
SKILL	一个完整场景任务包：业务说明 SKILL.md + 能力声明 mcp.json + 原子接口/组件实现

登录态：与原小程序一致，可用 storage 共享凭证，也可用 wx.login / wx.getPhoneNumber。
但原子接口拿不到页面全局状态——入参必须自洽，别指望从「会话空气」里补字段。

SKILL 怎么封装：粒度比文采重要

判断标准可以分层（工程上比「写一篇漂亮说明」更管用）：

层级	建议粒度	切太细	切太粗
SKILL	用户一口气能说完的完整任务	多 SKILL 路由出错	多场景混装，意图分流不准
原子接口	一个可独立完成、有明确结果的动作	十几步串行，中断点爆炸	参数膨胀，职责不清
原子组件	一次确认一件事（规格/地址/金额分卡）	对话被切碎	单卡信息过载，用户不敢点

三类常见切错：

1. 按页面切：用户要的是「下单拿铁」，不是「打开商品详情页」
2. 按按钮切：查门店→选规格→算价→建单→支付拆成六接口，任一步缺参就断
3. 查询与办理混装：查询可重试；办理有副作用。混在一起，模型可能「只是看看」就建单

文档分工也容易写飘（对照官方最佳实践口径）：

• SKILL.md：场景说明、前置条件、跨接口业务规则
• mcp.json：模型可调用能力声明，与实现保持一致
• 接口返回 content：本次结果 + 下一步动作，不要塞成长篇说明书

可复制的「最小 SKILL 清单」（开工前先填空）：

[ ] 场景一句话：用户想完成什么（不是打开哪个页）
[ ] 办理还是查询：有无写库/下单/支付副作用
[ ] 原子接口列表：每个接口入参必填项、失败码、是否幂等
[ ] 原子组件：每张卡只确认一件事
[ ] 页面接力：每个关键接口对应的小程序路径与入参映射
[ ] 登录：无页面上下文时如何取到可用凭证
[ ] 观测：traceId、入参原文、失败原因分类

内测期工程策略：先做契约，再等提审口子

建议三条（独立开发和小团队都适用）：

1. 分支隔离

AI 开发模式相关代码与正式发版分支物理隔离。
构建产物里不要出现正式包可触达的注册入口。
演示给客户时说清楚：能力在内测通道，不等于线上已开放。

2. 契约先行

接口命名、参数、返回结构、SKILL.md / mcp.json 可以先定稿评审。
这部分不依赖提审是否开放，提前做能压缩后期返工。

3. 灰度双通道意识

上线后（官方开放后）AI 入口与原页面入口往往会并存。
登录态、订单状态、幂等键应共用同一套服务端逻辑，避免两套单据、两套库存口径。

可观测性最少留五类指标（接第二个场景前定口径）：

指标	看什么
意图覆盖率	用户说法是否命中已封装 SKILL
接口选中准确率	命中场景后是否选对原子接口
参数填充准确率	必填参数是否填对
接力率	卡片是否点进接力页
中断率	确认前放弃比例

日志最少三条：会话 traceId、原子接口入参与 content 原文、失败按「缺参 / 无结果 / 权限 / 超时」分类。

避坑清单（可直接贴评审）

[ ] 是否误把 AI 开发模式代码打进正式提审包
[ ] SKILL 是否按「用户任务」切，而不是按页面/按钮切
[ ] 查询接口与办理接口是否分离，办理是否幂等
[ ] 原子接口入参是否自洽（不依赖页面全局状态）
[ ] 关键接口是否配置了页面接力，且卡片与接力页数据结构一致
[ ] SKILL.md / mcp.json / 实现三者描述是否一致
[ ] 密钥与模型调用是否走服务端，禁止写进小程序前端
[ ] 给客户的交付说明是否写明：内测未开放提审

小结

• 小程序 AI 开发模式的关键不是「再做一个聊天页」，而是 SKILL + 原子接口/组件 + 页面接力。
• 粒度按任务切：SKILL 管场景，接口管动作，组件管一次确认。
• 内测期：契约可先写，代码勿合正式提审。
• 观测与幂等提前留，否则第二个场景上线后只能靠猜返工。

项目咨询 / 技术交流见主页。
若你正在做小程序交付，可以把「AI 模式分支隔离」写进验收清单，避免 Demo 热度直接打进生产包。