微信和支付宝反击豆包：把小程序做成Skill
微信和支付宝几乎同时做出同一个选择：将十年积累的百万小程序改造成AI可调用的Skill，以应对豆包带来的纯AI原生入口威胁。
微信和支付宝反击豆包：把小程序做成Skill
核心速览
2026年6月中旬，中国互联网最大的两个流量平台几乎同时做了一个方向一致的决定。先是6月2日微信被曝内测AI Agent连接小程序，6月8日即公开了小程序接入AI的Skill技术规范；紧随其后，支付宝于6月15日内测"AI版"，让用户一键切换到一个以对话驱动的全新支付宝。二者不约而同地将过去十年积累的数以百万计的小程序改造成AI可调用的Skill——这是对
豆包三亿月活带来的"AI原生入口"威胁最直接的回应。
从分发资产到调用资产
微信和支付宝在应对的第一步上做了同一个选择：把过去十年沉淀下来的小程序，从"分发资产"改造成"调用资产"。
| 资产类型 | 逻辑 | 值钱的原因 |
|---|---|---|
| 分发资产（旧） | 用户主动点开 | 能被入口、九宫格、搜一搜分发到用户面前 |
| 调用资产（新） | AI主动选择调用 | AI听懂需求后直接调起，补齐参数、完成下单 |
🔑 核心转移：用户不再"看见"它，AI"调用"它。所有人都正在争夺的就是这种"调用资产"的定义权——过去沉淀的商家服务能力归谁定义、按谁的标准打包、最后在谁那里收单。
微信的"小程序版MCP"
微信在官方AI开发文档中制定了极为细致的调用规范：
- 📋 AI最该优先看接口返回的内容，其次是接口描述
- 📋 接口返回要用"事实+动作"两段式——先告诉AI发生了什么，再告诉它下一步能做什么
- 📋 参数尽量传
storeId、drinkId这样的ID，避免让模型从自然语言中猜测
更关键的是，微信明确表示它做的不是通用MCP。这套Skill的原子接口是注册在小程序里、跑在微信客户端隔离环境中的函数，微信之外的AI客户端根本连不上。外形上沿用了MCP的约定，骨子里却是一个只在微信内生效的"小程序版MCP"。
微信还附加了一长串限制：
| 限制项 | 说明 |
|---|---|
| Skill 打包 | 必须装进独立分包 |
| 数量上限 | 一个小程序最多 30 个 |
| AI 卡片交互 | 不能上下滚动 |
| 导流兜底 | 用户导回小程序的"文字链"被明确定义为兜底手段，用多了会被降权 |
尽管支付宝尚未公开相关开发文档，但逻辑一致：谁抢先立起规范、拉进更多供给端，就更有概率把供需两端绑在自己的生态中。
微信的包袱与支付宝的激进
二者的焦虑虽同，处境却截然不同。
微信的底牌最稳，包袱也最重。
- 它的小程序本就"用完即走"，加之对自家生态近乎"上帝视角"的掌控——每个小程序从提交、审核到运行都在它手里，审核阶段即可自动将源码扫描成Skill，开发者一行代码不用写
- 但它的AI入口在负一屏，必须小心翼翼地兼顾既有的社交关系与克制理念
- Agent调用Skill大概率不会主动推送服务——它要延续小程序"用完即走"的属性，而不是变成一个时时打扰的 proactive agent
🐘 微信困境：能力它都有，但每一步都得迁就存量。
支付宝可以更激进。
- 没有社交包袱，它干脆做"一键切换"把整个 App 换成对话版
- 但其挑战在于，支付宝长期被用户定义为"付钱时才打开"的工具
- 从2024年发布"支小宝"折戟，到2025年放弃独立App调头回主端，它反复试验的就是如何让一个工具变成值得对话的服务入口
Skill的"反超级App"悖论
这些动作背后是同一种情绪：慌。慌的源头是豆包——或者说豆包代表的纯AI原生入口路线。字节用做消费App的方法论，靠学习辅导、语音陪伴、影像创作把豆包养到了三亿多月活。这条路一旦走通，用户需求将越来越多地在一个与微信支付宝无关的全新入口里被接住。
对微信和支付宝而言，真正的威胁不是"豆包会不会写Skill"——写Skill是技术问题，谁都能学。真正的威胁是时间：谁能抢在豆包这类纯AI挑战者养成用户习惯之前，把自己十年攒下的服务模块改造成AI可调用的层。
💡 存量优势：豆包的短板恰恰在于没有这些存量，要从零接服务；而微信和支付宝最不缺的就是这个。它们的Skill化是一场抢跑——用存量优势把服务能力这道护城河在挑战者补齐之前先AI化。
这也解释了一个细节：为什么今天放出来的Skill看起来都像是"给AI写的SOP、操作手册"——一份告诉AI"这家店有什么、怎么点、怎么付"的说明书，而不是让商家按照全新逻辑重做。因为它们要的就是快，Skill被定位成一个"再打包层"：底下的服务不动，上面套一层AI接口。
但这个用Skill守住入口的故事里藏着一个深层矛盾。小程序的分发逻辑是"用户主动点开"，Skill的分发逻辑是"AI主动选择调用"。过去流量分配权在"平台+用户"手里，现在则转移到了模型的意图理解中——入口第一次不再是"用户必须经过的那扇门"，而退化成了"模型可以选择经过的其中一条路"。
更要命的是Skill的标准化、可组合、可跨端调用特性，天然不绑定于任何一个超级App。瑞幸已经做出了选择，它没有满足于只做微信和千问的"店内Skill"，而是上线了AI开放平台，把点单能力做成MCP、CLI、Skill三种形态——这意味着任何支持这些协议的AI工具都能直接调起点单。肯德基官方也已支持MCP。
⚡ 范式冲突：当一个商家想明白"我的服务能力可以变成一个谁都能调的标准件"时，就没有理由把自己锁死在某一个超级App的店内。微信和支付宝想用"把小程序变Skill"守住入口地位，但Skill的可组合性和跨端性恰恰是反"超级App入口"的。
后续值得关注的方向：
- 📋 Skill规范开放进度——微信和支付宝的开发者采纳率
- 🔄 豆包的回应——是否会推出自己的服务调用标准
- 🔗 跨端Skill标准化——微信的"小程序版MCP"会与通用MCP形成标准竞争，还是最终走向兼容
用户评价