微信和支付宝反击豆包：把小程序做成Skill

作者 ｜ 黄小艺
邮箱 ｜ huangxiaoyi@pingwest.com

中国互联网的两大流量盘，几乎是挤在同一个时间窗口，做了同一个方向的大动作。

先是6 月 2 日，英国《金融时报》曝出微信正在内测内嵌 AI Agent，能连接小程序帮用户办事；6 月 8 日，微信公开了小程序接入 AI 的 Skill 技术规范，京东、美团、滴滴等当即宣布接入。

而后，6 月 15 日，蚂蚁释放出信号，在内测“AI 版支付宝”，让用户一键切换，进入一个全新的、以对话驱动的支付宝，可调用百万生态内小程序。

在具体的接入方式上，支付宝和微信小程序AI相似，一边推动有意愿的商户主动接入，把自己的服务做成 AI 可直接调用的 MCP/Skill；一边在用户授权下，由 AI 通过对界面的 “读屏” 操作，兼容尚未改造的小程序。

至此，一个社交超级 App，一个支付基础设施，都在这个时刻将小程序Skill化了。

两者的动作都不小，背后的焦虑也很明显。当豆包已经杀到门前，随着用户量的激增，对微信和支付宝的基本盘已经开始产生直接的冲击，人们使用微信和支付宝的方式，微信和支付宝为人们提供服务的方式，以及这两大国民级平台与它上面数以亿计的服务商之间的关系，都会迅速改变。

怎么办？

微信和支付宝在应对的第一步上，做了同一个选择，就是直接利用过去十年沉淀的数以百万计的小程序，把这些庞大的自家存量资产就地翻译成 Skill。

1

把小程序做成Skill，借此留住对服务单元的定义权

这件事的底层动作，可以用一句话概括：把一个分发资产，改造成一个调用资产。

分发资产的逻辑是“用户主动点开”。

过去十年，一个小程序值钱，是因为它能被微信的入口、支付宝的九宫格、搜一搜、服务通知分发到用户面前，用户看见、点开、使用。平台是渠道，小程序是货。

调用资产的逻辑完全不同：它值钱，是因为 AI 在听懂你一句“帮我点杯不太甜的拿铁”之后，能直接把它当成一个工具调起来，补齐参数、完成下单。用户不再“看见”它，AI“调用”它。

所有人正在争夺的就是这个“调用资产”的定义权，即过去十年沉淀下来的小程序、商家、服务能力，这些会被 AI 调用的服务单元，归谁定义、按谁的标准打包、最后在谁那里收单。

而定义权落到实处，就是各自制定一套调用标准。

以微信位为例，在微信官方小程序AI开发文档里，它的规范写得很细：AI 最该优先看接口返回的内容，其次是接口描述，Skill.md 反而排在最后；接口返回要用“事实 + 动作”两段式，先告诉 AI 发生了什么、再告诉它下一步能做什么；参数尽量传 storeId、drinkId 这样的 ID，别让模型从自然语言里自己猜。

更关键的，是微信提到，它做的不是通用 MCP。这套 Skill 的原子接口，是注册在小程序里、跑在微信客户端一个隔离环境里的函数，微信之外的 AI 客户端根本连不上；外形上它沿用了 MCP 的约定，骨子里却是一个只在微信内生效的“小程序版 MCP”。

围着它，微信还加了一长串限制：Skill 必须装进独立分包、一个小程序最多 30 个，AI 卡片不能上下滚动，想把用户导去小程序原页面的“文字链”被明确定义成兜底手段、用多了还会被降权——一切都要在它的 AI 对话里闭环。

尽管支付宝目前还没有相关的开发文档，但和微信一样，谁抢先把规范立起来，把更多的供给端拉进来，就更有概率把供需两端绑在自己的生态中。

与此同时，它们各自的处境，也很不一样。

微信的底牌最稳，包袱也最重。

它的小程序本就是“用完即走”，加上它对自家生态有近乎“上帝视角”的掌控——每个小程序从提交、审核到运行都在它手里，它能在审核阶段直接把源码扫成 Skill，开发者一行代码不用写。

但它的 AI 入口在负一屏，要小心翼翼地兼顾那套已经很牢固的旧秩序：社交关系、一以贯之的克制。比如，微信的 Agent调用Skill，大概率不会主动给用户推送服务——因为它要延续小程序“用完即走”的属性，而不是做一个时时打扰你的 proactive agent。能力它都有，但每一步都得迁就存量。

支付宝可以更激进。

它没有社交的包袱，干脆做“一键切换”，把整个 App 换成对话版。但它也面临挑战：支付宝长期被用户定义成“付钱时才打开”的工具，从 2024 年发布“支小宝”折戟、到 2025 年放弃独立 App 调头回主端，它反复试的就是怎么让一个工具变成值得对话的服务入口。

1

长期挑战：Skill本身是“反超级入口”的

这些动作背后有同一种情绪：慌。

慌的源头有个原因——豆包。或者说豆包代表的那条路线：纯 AI 原生入口。

字节用做消费 App 的方法论，靠学习辅导、语音陪伴、影像创作，把豆包养到了三亿多月活，它代表的是“AI 作为独立入口”——训练用户主动来找 AI。

这条路一旦走通，意味着用户的需求会越来越多地在一个全新的、跟微信支付宝无关的入口里被接住。

对微信和支付宝来说，真正的威胁不是“豆包会不会写 Skill”，写 Skill 是技术问题，谁都能学。真正的威胁是时间：谁能抢在豆包这类纯 AI 挑战者养成用户习惯之前，把自己十年攒下的现成服务模块，改造成 AI 能调用的层。

豆包的短板恰恰是它没有这些存量，它要从零接服务。而微信和支付宝最不缺的就是这个。它们的 Skill 化，本质是一场抢跑：用存量优势，把“服务能力”这道护城河，在挑战者补齐之前先 AI 化。

这也解释了一个细节：为什么今天这些放出来的 Skill，看起来都像是“给 AI 写的 SOP、操作手册”——一份告诉 AI“这家店有什么、怎么点、怎么付”的说明书，而不是让商家真正为了AI的新基础设施而按照新的逻辑重做。因为它们要的就是快，Skill 在这里被定位成一个“再打包层”：底下的服务不动，上面套一层 AI 接口。

但这个用Skill守住入口的故事里，还藏着一个很难解的矛盾——Skill能不能、应不应该被绑定在入口里？

小程序的分发逻辑是“用户主动点开”，Skill 的分发逻辑是“AI 主动选择调用”。 这两个逻辑，指向的流量分配权，在两个完全不同的人手里。

过去，一个小程序能不能火，取决于平台运营怎么给它分发位、用户愿不愿意点。流量分配权，握在“平台 + 用户”手里。

现在，一个 Skill 会不会被用上，取决于模型在理解了用户意图之后，从一堆能力里挑了谁、怎么编排。流量分配权，从平台运营和用户的手，转移到了模型的意图理解里。入口第一次不再是“用户必须经过的那扇门”，而退化成了“模型可以选择经过的其中一条路”。

更要命的是 Skill 这个形态本身的一个属性：它可组合，可跨端调用。 一个标准化的 Skill，天生就不独属于任何一个 App。

哪怕今天诸多厂商在配合着两大平台的skill化改造而快速上线说明书式的skill，但依然有很多厂商已经开始做打破边界的它们自己的skill。比如瑞幸，它没有满足于只做微信和千问的“店内 Skill”，而是自己上线了一个 AI 开放平台，把点单能力做成标准的 MCP、CLI、Skill 三种形态放出去——这意味着任何支持这些协议的 AI 工具，codebuddy、Claude Code、Codex、Kimi Code，都能直接调起瑞幸点一杯咖啡。肯德基官方也已经支持 MCP。

当一个商家想明白“我的服务能力可以变成一个谁都能调的标准件”时，它就没有理由把自己锁死在某一个超级 App 的店内。

微信、支付宝想用“把小程序变 Skill”这一招，守住自己作为入口的地位。但 Skill 这个东西的本质是标准化、可组合、可跨端的，它恰恰是反“超级 App 入口”的。这个深层的矛盾，注定会变成接下来微信和支付宝与豆包们越来越短兵相接的AI竞争里的一个最大变量。

点个“爱心”，再走 吧