微信AI这招挺有意思的

6月8号，微信开放平台放出一个不大不小的消息：小程序开发者们，现在可以主动授权，让自己的小程序接入微信AI了。

两种模式。一种是「自动模式」——提审的时候，平台直接读你的源码，自动生成AI能调用的能力，开发者什么都不用干。另一种叫「开发模式」，按规范自行适配，目前还在内测，用户暂时体验不到。

如果你是小程序开发者，这事儿跟你有直接关系。建议在「自动模式」四个字上多看几眼，别急着跳过去。

已经有人实测发现，小程序管理后台确实上线了「微信AI自动模式」的服务条款页面，定义写得一清二楚：

允许微信用户通过微信AI调用、访问、操作小程序，以及根据小程序代码自动生成、调用技能的自动化技术服务。

注意最后一句话——根据小程序代码自动生成、调用技能。你交出去的是代码，微信拿回来的是「技能」；你的源码进去，出来一个能被微信AI理解和操控的能力模块。说白了，平台在做的事情，是把你的小程序翻译成AI能听懂的语言。

翻译只是第一步，AI听懂之后还得会动手。它得知道你的下单按钮在哪儿，搜索框长什么样，点了确认之后跳到哪个页面。

要知道，几百万个小程序，界面千差万别。同样一个「下单」按钮，在不同小程序里，位置、样式、交互逻辑都完全不同。

翻一下微信AI团队过去一年发的论文，把它们串起来看，一条完整的技术路线清晰可见。

微信团队在自己的多模态模型POINTS基础上，专门做了一个GUI定位模型，叫POINTS-GUI-G。名字够长，活儿也很硬。给它一张小程序截图，外加一句指令，比如「找到下单按钮」，它就能告诉你这个按钮在屏幕上的坐标，精确到像素级别。这个模型在ScreenSpot-Pro上直接屠榜，是目前公认最难的GUI定位基准，分数最高。论文自己说的：在「找到按钮」这件事上，全球第一。

人点一个按钮之前，大概知道会发生什么：页面跳转、弹窗确认、购物车数量变化。AI没有这种直觉。怎么办？微信团队给小程序生态造了一个「世界模型」，项目叫UI-Oceanus。它自动模拟各种操作和页面变化，生生造出500万个样本、32亿token的合成训练数据。效果呢？在Agent从没见过的新小程序上冷启动测试，导航成功率提升了21.9%。「冷启动」三个字是关键——不需要任何预先了解，面对一个完全陌生的小程序，自己摸索着就把任务干了。

这一步有个项目叫DiffSpot，专门训练模型识别操作前后界面上的细微变化。不过论文自己也承认，主流视觉模型在这类任务上还是很吃力，三个环节里，这个最拉胯。

现在把公告和这几篇论文串起来看，链条很清楚：你的源码交给平台，平台分析出页面结构和交互逻辑，转成AI能调用的「技能」——POINTS-GUI-G负责看懂界面，UI-Oceanus负责预判操作结果，DiffSpot负责确认执行对不对。源码提供的是「这个小程序长啥样、怎么运转」，三篇论文背后的技术提供的是「怎么操控任意小程序」。两边一合，微信AI就有了替你操作小程序的全部家当。所以「自动模式」这个名字起得挺准的——对开发者来说，确实是自动的，你什么都不用干；但这个「什么都不用干」的另一面，是这事儿也不需要你参与了。

平台读完你的代码，自己就把你的小程序变成AI的一个可调用模块。你省掉的开发成本，换来的是你的小程序从「用户自己打开来用的产品」，变成了「微信AI替用户调用的一项技能」。不一定是坏事，但好歹得知道自己交出去的是什么。

……

公告里有句话，很容易一眼滑过去：

是否接入由开发者自主决定，接入与否不会影响现有的小程序服务。

听着挺体面。翻译乘人话：你不来，也没人为难你。

开发者真有选择吗？技术层面，这句话完全成立。今天不授权，你的小程序明天照常运行，用户该怎么用还怎么用，一行代码都不会动。微信没说错。但它保护的是你的存量，你的增量呢？公告同时写得明白，开发者需要「主动授权接入微信AI」——反过来说，不接入的小程序，就不会被微信AI调用。

今天这事儿无所谓，微信AI还在内测，用户还用不上。可一旦正式上线呢？14亿月活用户开始习惯用一句话让AI帮他们点咖啡、查快递、订机票，那些没接入的小程序，AI可能根本不知道你的存在。用户不是不能手动打开你的小程序，但旁边那个竞品已经被AI直接调用了，你还要用户自己搜索、自己打开、自己一步步点。这不叫「不影响」，是你的小程序被默默绕过去了。

更值得看的是时间线。

回到半年前，今年1月，微信推了个「AI应用及线上工具小程序成长计划」，激励期覆盖2026全年。给的东西确实不含糊：免费云开发环境，最长给半年；1亿token的混元大模型额度；1万张文生图额度；免费We分析专业版；「发现-小程序」里给你专属推荐入口。连广告变&现都安排好了，有个「免开发智能接入模式」，平台自动在合适位置插广告，个人和企业都能参加。

1月，给资源给流量给变&现工具，大门敞开请你进来；6月，请你授权源码，让AI能操控你的小程序。两步串一块看，味道就出来了：先把你养在生态里，再让你把钥匙交出来。每一步单独看都很合理——送资源有什么不好？自愿授权有什么不对？但两步走完，开发者对微信生态的依赖又深了一层。

有人可能会说，苹果不也这样吗？Siri要调用你的App，你也得按Apple的App Intents框架适配。没错。但有一个关键区别：苹果不需要读你的源码。App Intents是一个本地框架，开发者自己声明自己的App能干什么，Siri在用户设备上调用。而微信的自动模式，要求你把源码交给平台，能力由平台侧生成。

你适配的是一个平台的AI。

需要强调的是，这里不是在说微信平台在做坏事。平台搭台、开发者唱戏，历来如此。2017年小程序刚出来的时候，也是「自愿接入」，后来变成了线下商家的标配。这一轮的故事也许会重演，也许不会。但有一件事值得记住：当一个平台告诉你「你可以不来」时，先看看不来的代价是什么。

……

这个博弈之所以不太容易一眼看穿，还有一个更隐蔽的原因：微信在描述这整套体系时，用的全是开发者已经很熟悉的词——Skill和MCP。如果你过去一年用过AI编程工具，这两个词不会陌生。

MCP，全称Model Context Protocol，是Anthropic在2024年底搞的一套开源协议标准。它要解决的问题很直接：让任何AI模型都能用同一套规范去连接任何外部工具和数据源。不绑定厂商，不绑定模型，协议开源，社区驱动。在AI开发者圈子里，它的地位有点像当年的HTTP——不属于谁，但谁都在用。

Skill，在Claude Code、OpenClaw这些AI编码工具的体系里，是一个模块化的「技能包」概念。给AI装一个Skill，它就多了一项专业能力，比如UI设计、数据库查询、某个框架的最佳实践。Skill是开放的，开发者自己写、自己装，跨工具通用。

这两个词，过去一年在中文AI开发者社区里已经有了明确的共识：MCP是连接标准，Skill是能力模块。两者都是开放生态的基础设施。

然后微信来了。

翻微信的官方开发者文档，会发现一个叫「使用Skill / MCP辅助小程序开发」的页面，白纸黑字写着：MCP负责连接环境与调用工具，Skill负责补充小程序、云函数、数据库等场景规则。再翻腾讯文档开放平台，Skill的定义是：AI智能体跟大规模协作办公生态之间的通信与作业协议层，后面还跟了一句「通过MCP标准框架」运行。话说得挺大，但往下看更有意思。微信支付搞了个「基础支付接入Skill」，直接手把手教你怎么在Cursor的Skill配置目录里用；小程序Skyline渲染引擎，有个开源仓库名字就叫skyline-skills；小程序云测那边，整了个「skill能力」功能，让大模型自己决定啥时候调哪个技能。

如果你最近在开发者论坛里逛过，可能已经看到有人在吐槽了：Skill和MCP这两个词，在中文世界里快要不是原来的意思了。

为什么？微信确实在用MCP这个协议，也确实在用Skill这个词。但问题出在：它把一套跨平台、跨模型的开放标准，嵌进了一个只对微信AI生效的封闭生态里。开放世界里的MCP，解决的是「任何AI都能连任何工具」；微信里的MCP，解决的是「微信AI能连微信里的工具」，仅此而已。

还记得之前那句条款吗？「根据小程序代码自动生成、调用技能」。现在你知道了，那个「技能」在微信的技术文档里对应的英文就是Skill。你的源码交上去，出来一个能力模块，在微信的体系里就叫Skill——一个只在微信花园里生效的Skill。

这事儿比术语之争大多了。说重一点，一场认知基础设施的替换，正在悄悄发生。14亿月活的平台，开始用「Skill」和「MCP」来描述自己的封闭接口，而大多数中文开发者第一次看到这两个词，恰好就是在微信的开发者文档里。很多人认知里的Skill就是「小程序被AI调用的接口」，MCP就是「微信云开发的连接工具」。至于这些词原本在开放世界里是什么意思，反而成了需要额外解释的冷知识。

这招挺高级的：用熟悉的词，消解警惕，让你觉得你在对接行业标准，其实走进一个只有一个出口的房间。平台锁定，就发生在毫无察觉的时候。

没有说微信做错了什么。AI引领的变革面前，各家平台做平台的事。那个词变没变味，也不重要。关键在于：谁在把路修宽，谁在把墙垒高？

注：文中提及的微信AI团队相关研究——
[1]. Zhao, Z. et al. POINTS-GUI-G: GUI-Grounding Journey. arXiv:2602.06391, 2026；
[2]. Wu, M. et al. UI-Oceanus: Scaling GUI Agents with Synthetic Environmental Dynamics. arXiv:2604.02345, 2026；
[3]. DiffSpot: Can VLMs Spot Fine-Grained Visual Differences in Web Interfaces? arXiv:2605.29615, 2026.