微信小微灰度130天：小程序正被拆成AI零件

微信“发现”页中的小程序主页迎来新版式：顶部是搜索框，其后依次是最近使用、我的常用，以及小游戏、短剧、生活服务与AI服务等独立展位。

十年前，微信公开课上曾明确表示不会做小程序商店，不对其做分类、排行和推荐。但在移动互联网进入存量阶段的当下，AI在应用层的叠加让服务分发逻辑彻底转变。版式调整只是表象，微信的核心动作是将AI嵌入小程序全链路：从意图识别到下单履约，原本由用户手动点击的操作，正交由AI判断。

从首次灰度算起，微信原生AI助手“小微”上线已达130天。其唤起入口已扩展至聊天、搜索、公众号、视频号及PC端等共计28处。但在入口铺开后，决定系统能否高效运转的关键，在于数百万小程序能否被顺利拆解为AI可调用的底层能力。

入口铺设28处：从唤醒到履约的断层

在目前的微信生态中，小微已覆盖多种日常场景：早间在聊天列表唤起获取公众号摘要，中午通过搜索框调起小程序点咖啡，晚间在PC端对文件右键发起AI问答。这种密度在强调克制的微信产品历史上极为罕见。

然而，唤醒只需两秒，核心难点在于后续任务调度。小微的底座由腾讯自研的WeLM大模型驱动，复杂场景协同调用DeepSeek。大模型负责理解意图并指派任务，真正的商品制作、派车、订房等履约环节，依然必须依赖外部小程序。

为了让AI获知小程序能提供何种服务，微信推出了“小程序AI”机制，要求将业务拆分为独立的“原子接口”和“原子组件”。

两种改造路线：自动授权与深度重构

微信发布的接入指引为开发者提供了两条路线：

1. 自动模式：门槛极低，开发者仅需勾选授权，微信在提审时解析源码页面结构，让AI直接模拟用户操作。代价是开发者让渡了产品解释权，无法干预AI的调用逻辑与展示形式。
2. 开发模式：开发者需自行把小程序拆分成乐高积木般的原子单元，明确输入与输出参数，并编写对应的业务说明书（SKILL）。

SKILL手册对格式要求极为苛刻：严禁AI进行模糊推断，门店、商品等参数必须使用标准ID；接口返回数据需同时包含事实依据与后续动作指令，以防AI直接跳过用户确认环节。此外，开发者工具需切换至专用Nightly版本与特定的基础库支持。

商业考量：拆与不拆的算术题

未接入的小程序将无法被微信AI调用，但主动拆解也伴随着高昂成本。在开发模式下，SKILL必须通过涵盖服务交付、交互体验、性能质量与场景覆盖等多项维度的严苛评测，才具备被调用资格，而最终的流量排序规则尚未完全透明。

商业归因也是中小团队的核心顾虑。当AI直接在对话流中替用户完成操作时，用户无需打开具体页面，传统的广告曝光机会和埋点转化逻辑面临失效风险。

行业目前呈现分化趋势：京东、美团、滴滴、携程、同程旅行等头部企业已提前完成核心业务的Agent化对接；缺乏资源的小团队则倾向选择自动模式兜底；大量处于中游的服务商陷入观望，并催生出如微盟等代接入的第三方中介服务。

决胜点在零件供给与生态标准

对比各巨头在AI时代的布局，腾讯依托成熟的微信生态小程序履约网络，试错成本相对较低，核心瓶颈在于小程序组件化改造的推进速度。

长期来看，微信AI调度遵循基于Anthropic提出的MCP协议改造而来的“小程序MCP”。由于针对小程序特性进行了定制，开发者编写的SKILL具有排他性，难以直接复用到其他平台。

微信已搭建好入口与规范，未来这套生态能走多远，取决于几百万小程序运营者的改造意愿，以及他们能否在AI调度重构的流量池中获得对等回报。