微信AI生态的接入指引正在悄然改写小程序竞争规则。通过GUI Agent与开发者模式双轨并行，微信正将数百万小程序转化为可调度服务。从原子接口到注意力权重表，这套体系既保障了交易确定性，又保留了对话式交互的灵活性。但开发者是否买账，仍取决于微信如何平衡平台控制与生态开放。
昨天，微信发了《关于开发者接入微信AI生态的指引》。
业内还是非常关注的，我看大家都在纷纷转发。
但鲜有人真正去研究和细看那些具体接入文档，大部分都是在说微信终于动手了之类滴。
我昨晚去小程序后台看了一眼，发现这次覆盖非常广，我那个几乎没有用户量、好久不看的小程序也被灰度到了。
于是我盘了一下这些文档，通篇看下来，还是有非常多增量信息滴，值得业内深入研究——
（文档地址：https://developers.weixin.qq.com/miniprogram/dev/ai/guide.html）
先看热度——
官方有两个账号——微信公开课、微信开发者，都发了这个公告。
微信公开课那篇，阅读3.3万，点赞410，转发3533；
微信开发者那篇稍好一些，阅读6.5万，点赞660，转发5647。
这两个数放在微信官方账号的量级里，只能算普通，谈不上爆。
再看接入文档里放在GitHub上那个官方示例Demo（https://github.com/wechat-miniprogram/ai-mode-demo）的数据。
这在一定程度上代表了有多少开发者真的动手了。
截止到今天中午12点，fork11，star92，这就非常一般了。
说明绝大多数开发者还在观望，连Demo都懒得clone下来跑一遍。
当然，这也算正常。
毕竟GitHub上只是一个Demo，不是整个项目，而且文档自己都写着“当前处于内测阶段，暂未开放小程序AI开发模式的代码提审”。
但波澜不惊恰恰说明，很多开发者还停留在微信又搞了个AI功能的认知上。
这也是我要拆解这份文档的原因。
《关于开发者接入微信AI生态的指引》开篇第一句就是，在充分尊重开发者权益和自主选择的基础上。
文末的Q&A里还专门强调：是否接入由开发者自主决定，接入与否不会影响现有的小程序服务。
为啥要反复说这个？
因为微信很清楚开发者在怕什么——怕被平台强推，怕不接入就被穿小鞋。
微信赶紧把姿态摆得很低：我不强迫，你不接也不影响你现在的生意。
这种小心翼翼本身，就说明这事有多大。
在我看来，这也是微信要逻辑自洽的一种方式：
毕竟豆包手机上的时候，微信屏蔽了人家，豆包手机没经过微信同意。
平台和开发者的关系，很多时候逃不掉两种模式——店大欺客和客大欺店。
微信有时候是客（对AppStore而言），有时候是店（对小程序而言）
这次的自然原则，也是避免被业界认为是店大欺客。
它想通过自然的驱动让大家顺理成章地接进来。
这是微信AI雄心背后的耐心。
让一个AI去用一个本来给人用的小程序，技术上到底有几种姿势？
答案是两种。
第一条路，让AI像人一样盯着屏幕用手点。
这个叫GUI Agent，Computer Use走的就是这条路，豆包手机走的也是这条路。
逻辑很朴素：人怎么用手机，AI就怎么用。
好处是通用，坏处是有一定出错的概率，而且又慢又巨消耗token。（用过Claude Code和CodeX的Computer Use就知道我说的事啥）
第二条路，让小程序主动递接口给AI。
它的逻辑反过来：让开发者直接给数据和接口。好处是又稳又准，代价是开发者得动手。
自动模式基本等于第一条路（还是有点区别，后边再说），开发模式等于第二条路。
微信两个都要。
那么问题来了——
自动模式如何实现开发者零投入？
我们来看《微信AI自动模式服务条款》，很少有人认真读这个——
我来个小范围的中译中：
第一项叫页面交互技术授权——
微信AI可通过页面交互技术的方式访问或操作你开发、运营的小程序，包括但不限于获取小程序服务页面进行识别读取、分析处理，根据需要代替微信用户执行搜索、下单或者代替微信用户输入、授权服务所需的信息等操作。
翻译过来就是AI像一个真人一样，去看你小程序的页面，然后动手帮用户点击和下单。
这就是标准的GUI Agent。
当然，微信AI团队也一直在解决读屏效率的问题，大家可以去搜这两个东西：POINTS-GUI-G和UI-Oceanus。
前者在ScreenSpot-Pro这个公认业界最难的GUI定位基准上做到了59.9分，拿到同尺寸模型的SOTA。
这是微信AI技术团队通过强化学习提高读屏性能的技术成果。
为什么机器人要做成人的形状？
原因是在于物理世界的基础设施都是为人设计的，人的形状可以最大程度上复用现有的基础设施。
这也是微信AI团队强化GUI读屏技术的原因，毕竟小程序都是为人设计的界面。
扯远了，打住！
第二项授权叫小程序技能生成、调用授权。
平台会读取源码，解析页面结构和逻辑、API定义、交互流程，据此生成一个skills，之后就按这个skill走。
从读屏到读码，这就高了一个段位，也比豆包手机纯粹的GUI更高一级。
那么问题来了——自动模式有代价吗？
翻翻条款第8条——
微信AI功能可能会适当调整你的小程序的展示方式与用户交互体验，包括但不限于在后端运行小程序、仅展示部分小程序交互界面以及为用户提供快速确认或中止操作的能力等。
读懂这句话了吗？
在后端运行小程序、仅展示部分交互界面——
这意味着用户基本上是看不到你精心设计的小程序首页了。
你做的品牌门面、运营位、广告banner，在AI模式下大概率被直接跳过。
当然，针对这个问题，微信也有一定的解法：原子组件（后边会讲）。
它让商家能在AI的对话流里，渲染出自己的、带品牌的、能交互的卡片。
官方还要求，卡片右上角要提供进入小程序的入口，并配置关联的小程序页面，等于给商家在AI对话里留了一扇自己的门。
再看第6条：
微信AI在获得用户授权后的行为均视为微信用户操作的延伸和微信用户的行为，开发者无正当理由不得擅自变更、屏蔽或拒绝执行。
这就是说——
当你同意自动模式之后，AI替用户操作你的小程序，法律上算用户自己在操作，你不许拦着。
再来看开发者模式，核心就三个概念——原子接口、原子组件、Skill
原子接口，是最小执行单元，封装单一业务功能。
“查询饮品列表”是一个原子接口，“创建订单”是一个，「发起支付」又是一个。每个接口有标准化输入和输出。
原子组件，是原子接口的可视化展示单元。
你可以理解成一个卡片，是接口吐出来一堆结构化数据渲染出来的，直接显示在你跟AI的对话流里。
Skill，是把上面这些打包成的一个完整能力。
一个SKILL包含业务说明（SKILL.md）、模型可调用能力声明（mcp.json）、原子接口和原子组件的代码实现。
一个小程序最多30个Skill。
这三个东西通过小程序MCP连接起来，微信在文档里特意强调了自己的小程序MCP与标准MCP不同——
小程序MCP是向小程序AI暴露可调用能力的一套协议，与标准MCP不同，小程序MCP适应于小程序开发的特点，开发者只需要按设计提供完整的SKILL实现，小程序AI就能正确地推理及执行相应的原子接口。
个人感觉这三件套的设计哲学还挺清晰滴——简单、稳、灵活。
这套东西跑起来到底长什么样？
《运行机制》文档里有一张时序图，能帮助我们直观理解上面整个流程——
复述一遍这个点单全流程——
用户说来杯拿铁，AI推理后决定调用确认订单（confirmOrder）接口。
微信客户端启动运行环境、下载分包，执行接口代码，顺手通过wx.login拿到用户身份。
接口去请求开发者自己的第三方服务器创建订单，信息回传给AI。
AI再推理，下发渲染指令，原子组件把订单渲染成一张确认卡片。用户点确认支付，这个动作变成一条上行消息发回给AI。
AI调用payOrder接口，拉起wx.requestPayment，即微信支付收银台付款。
整个过程，用户全程没离开过那个对话框。
搜索、下单、支付、出结果，闭环全在对话流里完成。
注意：运行环境也有隔离设计，文档特别说明——
这个设计初衷是让AI能执行开发者给的工具代码，但不会把原小程序运行环境全盘暴露出来。
稳，是微信很看重的。
好，看完自动模式和开发者模式，我发现这和当年搜索引擎干的事挺像——
搜索引擎一边派爬虫去无差别地抓取全网页面，这是自动模式。
一边又鼓励站长做SEO、填结构化数据、提交sitemap，这是开发模式。
微信把这套打法原封不动搬到了AI Agent时代。
如果你仔细看接入文档，就会发现文档里反复出现卡片、半屏页面、确认按钮这种有些老派的东西。
这也是有考量的。
微信把关键步骤设计成卡片和半屏页面，核心是想给给用户足够多的确认空间。
原子组件渲染GUI卡片展示在对话流里，官方要求卡片右上角提供进入小程序的入口。
半屏页面只允许展示更多详情，不许跳出去到公众号、视频号、其他小程序、地图App。
用户在对话里说需求，但关键确认要落到卡片上。
Agent最大的问题之一就是喜欢自以为是地脑补。
比如用户说那个就猜一个，这放在聊天里是幻觉，但放在交易里，那是要出事故滴。
微信AI通过不同的确认卡片，就是想尽可能消除这种不确定性。九、注意力权重表开发者应该引起重视
再看官方的最佳实践，我觉得很有意思的是这个——
《最佳实践》里有一张注意力权重表：
原子接口返回的content，五颗星。它离当前决策点最近，模型会把它当作事实加动作来读取。
mcp.json里的description，四颗星，影响模型选不选这个接口。
inputSchema.description，四颗星，影响模型怎么填参数。
SKILL.md，三颗星，适合写业务流程编排和跨接口规则。
这就是从提示词工程拆到了产品工程。
所以，开发者一定要注意，写错位置，模型就容易跑偏。
比如ID类字段，反例是只写饮品ID。推荐做法是声明取值来源——饮品唯一标识，取自上游接口searchDrinks或getRecommendedDrinks返回。
为什么要这么写？
因为业务ID容易被模型按格式凑出来，不声明来源的话模型真的会编一个。
《能力介绍》里有句话，我觉得极其重要——
用户在此模式下的登录身份跟原小程序保持一致，开发者可以通过storage接口共享小程序内的登录凭证，也可以通过wx.login、wx.getPhoneNumber等接口完成登录流程。
这意味着AI替用户下单时，就已经在小程序里登录好的账号、地址、会员等级、优惠券，全都无缝继承。
这是豆包靠读屏极难复刻的体验。
身份的连续性，就是微信无形的护城河。
别人做Agent找来找去，想要的入口就是微信。
而微信做Agent——它本身就是入口。
对比一下你就更有感觉：
ChatGPT从今年2月开始测广告，接入了Stripe支付、Shopify电商、DoorDash外卖，铆足了劲想让用户在对话里直接成交。
结果目前只有2.1%的查询跟交易有关。
这里边就有一个技术上的尴尬——
Agent通过API完成的交易，传统归因工具根本追踪不到，没有浏览器session，没有cookie。
别家公司做Agent，最头疼的是没东西可调，得满世界求着别人接入。
而微信手里这座工具库，规模大的很：14.32亿月活体量下，点餐、打车、挂号、缴费…..几百万个，还都跟微信支付、社交、身份体系长在一起。
从这个意义上，微信AI团队对自己的优势理解得很深刻。
那么问题来了——微信AI会怎样改变小程序生态的竞争规则？
过去，小程序要争入口、争搜索词、争最近使用。
以后用户通过微信AI表达需求，AI会在可用小程序里做匹配。
开发者写在agent.skills.description、mcp.json description、page-meta.json里的文字，就会变成新的可见性资产。
文档里甚至说，小程序AI可以在回复里带上小程序短链，短链文本由模型根据聊天上下文、页面name、页面description、页面query动态生成。
这意味着小程序开发者的确要注意：一个字段写得含糊，就可能导致模型选错接口。
开发者文档里那些看起来有些枯燥的禁令和示例，得认真看。结语
2017年，小程序让很多服务不用下载App，解决了安装和分发问题。
2026年，小程序接入微信AI，想进一步解决寻找和调用问题。
以前是用完即走，现在是来都不用来就用完了。
小程序会从轻应用变成可调度服务。
对话成了新的UI，小程序会变成另一个物种。
当然，别把这事想得过于一帆风顺——
开发者积极性是一个鸡生蛋蛋生机的问题。
有人用才能有开发者接入，有足够开发者接入才能有人用。
看报道微信目前还是积极和美团、携程等头部聊接入，但撬动长尾开发者的速度到底是快还是慢，还有待观察。
然后调度本身也是地狱级难题。
几百万个小程序要协同、要排序，AI凭什么知道你说想喝咖啡时该调瑞幸还是星巴克？
最重要的也是一个习惯问题。
用户真的喜欢在对话框里打车订外卖吗，这种交互是未来最优解吗？
很难说。
比如到底有多少人通过千问下单点外卖？
路还很长，不过我相信微信团队。
本文由人人都是产品经理作者【卫夕】，微信公众号：【卫夕指北】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。