小微灰度的第130天：小程序正在被拆成零件，交给微信的AI

十月上旬，一些用户发现，微信“发现”页里的小程序主页换了版式：顶部是搜索框，往下是最近使用、我的常用，再往下是小游戏、短剧、生活服务、AI服务各自占位，这个页面同时容纳了搜索框、分类栏目和推荐位。

大约十年前，张小龙在微信公开课 PRO 上首次完整阐释小程序时表示，微信不会做小程序商店，也不会对小程序作分类、排行和推荐。十年间，移动互联网走到存量时代，AI 又在应用层叠了上来，分发这件事的形态和理由都发生了不可预知的变化。

版式变化只是表层，微信在做的是把 AI 嵌入小程序服务的整条链路，从意图识别、服务匹配到下单履约，原本由用户完成的路径选择，部分转由 AI 判断。从 6 月 21 日首次灰度算起，微信原生 AI 助手“小微”上线已是第 130 天。微信官方披露的唤起入口已达 16 处，第三方实测盘点数到 28 处，覆盖聊天、搜索、公众号、视频号、PC 端。

不过，入口铺得再多，解决的也只是找得到；能不能办得成，取决于几百万个小程序愿不愿意把自己的业务拆开、交给AI。这一点眼下还没有答案。

小微入口铺到28处

一个普通用户的一天，可能与小微有这样的几次交集：早上在聊天列表左上角点开绿色图标，问一句“今天有什么值得看的公众号”，它推送来几篇摘要。中午在搜索框长按，说“帮我点一杯少冰美式”，它调起一个小程序，直接跳到确认页。晚上在 PC 端微信里右键一份文件，菜单里多了一项“问 AI”。

这些动作发生在不同位置，四个多月里，小微从零星几个入口，扩展到几乎覆盖微信所有主要场景。首页左上角那个主入口仍在灰度，其余位置的可见范围也因用户而异，微信官方还没有公布过覆盖比例。

这个密度在微信的历史上并不常见，过去给一个服务放入口，微信通常很节制。支付在钱包入口，视频号在发现页占一个格子，小程序十年里主要靠开发者自己扫码引流。28 个位置，这个开放尺度上不言自明。

但入口多，不等于能办事，唤醒小微只要两秒，难的是唤醒之后：听懂用户说的话，以及决定把任务交给谁。在正常链路中，小微负责理解用户意图，模型底座是微信团队自研的 WeLM，遇到部分复杂问题则会调用 DeepSeek，两家配合，负责调度。至于接单、制作、派车、订房这些履约动作，得由小程序的主人来做。

履约层是这套生态里唯一必须依靠外部的部分，因为它由小程序的主人来做。但“由主人来做”有一个前提：微信得先知道，一个小程序到底能做什么事。微信给这套东西起的名字是“小程序 AI”：用户发起对话时，它分析并选择合适的原子接口和原子组件，完成数据处理和任务执行，再把结果整合给用户。

过去这件事不需要想，用户打开小程序，看见首页、菜单、按钮，自己完成操作。但对于AI来说，它需要知道哪家店、哪款饮品、用什么参数下单、最后把什么卡片递到用户面前。这些信息如何被获得，是后续小微“能办事”的关键所在。

AI零件“大改造”

6 月 8 日发布的《关于开发者接入微信 AI 生态的指引》，就是让开发者把这些信息补上。

指引给了两条路，官方的说法是两种模式可以同时开。其中，自动模式几乎零门槛：开发者勾一下授权，微信在提审时读取源码，自己分析页面结构，让 AI 直接操作。可以理解成微信派一名店员进店查看动线，之后替用户走一遍流程。确实省事，但代价是交出产品的解释权：AI 如何理解其功能、如何将其呈现给用户、同一需求下优先调用谁，开发者无法干预。

开发模式则要开发者自己动手，把小程序拆成更小的单元，拆到“查门店”“查饮品”“下单”各自独立。微信给这些单元起了名字，叫原子接口和原子组件，可以粗略理解成乐高积木：过去用户点一个“立即下单”，背后是一整套页面跳转。现在开发者得把每一步单独拆出来，标清楚输入什么、输出什么，让 AI 能一块一块地拼。拆完还需配一份说明书，告诉 AI 这个业务分几步走、每步先拼哪一块、参数从哪里来。这份说明书就是 SKILL。

写这本手册的规则近乎苛刻，核心只有一条：不许让 AI 猜。比如参数不能是自然语言，门店、饮品都得传编号，不能因为用户说了“橙C冰美式”，就指望模型知道是哪一款。接口返回给 AI 的内容也有固定格式：先讲清楚发生了什么，再告诉它下一步做什么。不能只写“展示卡片”这样的指令，要写“已查到订单数据，请展示订单确认卡片，并等待用户点击确认”。只有动作没有事实，AI 可能会直接跳过用户确认那一步。

另外，这些规则写在哪里也有讲究：接口返回的内容模型最信，参数描述次之，流程说明排最后。同一条约束，写在不同位置，AI 给的注意力不在一个量级。

落到开发者的日常，最麻烦的不是写代码，是那些过去“用户自己会点、不用写进代码”的隐性规则，现在一条条都得翻出来。接口简单的小程序，几行描述交代完。一套跑了几年的交易系统，要把老员工脑子里“这个号从哪来、取不到时回头调哪个接口”的经验，全写成 AI 能读懂的格式。

此外，开发动手之前，开发者工具要切到 Nightly 版本，编译模式改成“小程序 AI 编译”，基础库也要升级到指定的新版本。这些名词平时不在多数小程序团队的日常工具链中。

拆还是不拆？

既然要不要拆由不得自己，开发者能做的只剩下核算得失。

不拆的代价，指引中如此表述：“未完成接入的小程序，将无法被微信 AI 推荐及调用。”用词是“调用”，没有设期限，也没有说惩罚。但文件里的另一句话也透露：“接入后，你的小程序将有机会被微信 AI 推荐和调用。”

但拆也有成本，工具链要换，每个原子接口要单独封装、单独声明。不过，这些确定性的成本都还好，真正的问题是，这些改造做完之后，至少在当前状态下，自己的小程序会不会被调用并不是一件极其“确定”的事。

开发模式的 SKILL 要通过平台的评测，评测围绕服务交付、交互体验、性能质量、场景覆盖四项指标展开，前三项要 80 分以上，场景覆盖要 60 分以上，才具备被微信 AI 调用的资格。标准是公开的，但评测之后的调用排序规则尚未公开。如果哪天排序依据也能像评测标准一样亮出来，开发者的这道算术题会好解很多。开发者能做的，是把 SKILL 写好、把接口描述写清楚，然后等一个结果。

更麻烦的是归因，用户是 AI 调用进来的，还是自己点开的，成交算谁的，没有一条清晰的归因路径。

对以广告和页面转化为主要收入的中小团队，还要多算一层：自动模式下，是 AI 替用户操作小程序，用户可以自始至终停在对话里、一次也不打开页面，广告曝光的机会就没了。AI 如果跳过了中间的页面，转化归因也断了链条。开发者社区里有人提问表示：AI 直接操作页面，现有的埋点和广告展示逻辑会不会失效。眼下没有人给出明确答案。

所以最可能的结局是一次筛选，接入的门槛低到人人都会接，认真拆的门槛高到只有少数人会拆。能力储备充足的头部团队已经顺势把生意拆成了零件；缺乏储备的团队有零成本的退路，自动模式勾一个授权，也算完成了接入。夹在中间、认真权衡的团队反而无处使力，截至目前，提审尚未开放，官方文档明确提醒这部分代码不要合入正式版本，以免影响正常版本发布；评测工具也在升级中，评测 SKILL 暂时用不了。

谁先真正行动了？

不过，动作最快、牌桌最里侧的一批人，动手比指引还早。

据了解，携程曾向《财经》确认，今年 4 月中旬已通过开发模式接入微信 AI，后续将围绕酒店预订、机票查询、旅游度假、出行服务等核心场景做适配。这个时间点比 6 月 8 日那份指引早了近两个月。到 6 月首批公开披露的内测名单里，京东、美团、滴滴、携程、同程旅行、得物、肯德基等多家企业已经列在里面。

名单内的企业走的应该是与微信共建的通道，不走公开提审。这一点可以从时间点上倒推：指引 6 月 8 日才发布，携程 4 月中旬就完成了接入。

京东围绕电商、外卖、物流接入 AI Agent，其 AI 购物助手此前已经对接了多家手机厂商。美团有自研的 LongCat 模型（6 月开放测试的版本为 LongCat-2.0-Preview），总参数突破万亿，训练和推理全程依托国产算力集群，基于这套模型的 AI 助手“小美”已经在做跨场景决策。

滴滴把核心网约车服务融进去，用户通过微信内的 AI 交互就能直接唤起快车、专车、特惠，不需要跳转。同程本来就是腾讯生态的深度合作方，接入之后用户可以用自然语言完成行程规划和预订。

这些能力本来就在建设之中，接入微信只是顺带完成对接。无论指引是否发布，它们都会朝这个方向走。

头部之外，多数小团队的选择是开自动模式，等平台解析。但这套规则对所有人都是新的，被选中靠什么，也在变。

过去比的是 SEO、投放和社交裂变，看谁能让用户主动点开。往后要看接口描述的质量和履约的稳定性，看谁能被机器选中。新规则里没有“历史积累”这一栏。运营了多年、有稳定用户的老小程序，和刚上线但 SKILL 写得干净的新小程序，在调用池里是平等的。被削弱的还有品牌：用户不再需要打开某个小程序，甚至不一定知道最后调用的是谁。

这套规则不是开发者选的，供给过剩成了中心化分发最直接的推力，AI 调度取代了推荐位，但被机器挑中的权力依旧不在开发者手里，只是用户没看见推荐位，只拿到了一个结果。

改造门槛的出现，催生了中介服务。6 月 10 日，微盟作为首批内测团队接入微信 AI 生态，按其说法，未来商家可以通过微盟小程序便捷接入，重点覆盖电商、零售、本地生活等多类商家。中介的出现本身就是一个信号：改造确实有门槛。商家愿意付费委托改造，说明其清楚改造的必要性，却不具备自行完成的能力。“接入”，就这样成了一门生意。

瓶颈不在模型，在零件供给

名义上的接入多了，真能被调用的零件却不会因此变多，小微的实际表现也就参差不齐。多家媒体的实测给出了样本。

短链路、高频、边界清晰的场景，如点一杯咖啡、查一个订单，完成度相对较高。复合指令和超过三步的任务明显下滑。如果落差成立，根源更多在零件供给，不在模型能力。

这也解释了为什么三家巨头走的是三条不同的路，腾讯押微信入口，字节押独立 App，阿里押模型与全栈：千问 6 月初宣布将向第三方 Agent 和 Skill 全面开放，肯德基等品牌已在千问测试 Agent 服务。

三条路径其实回答的是同一个问题，用户把一句话交给 AI 之后，谁来把它办完。腾讯的路径成本最低，因为履约层已经现成，几百万个在微信里跑着交易的小程序，不需要重建，只需要改造。瓶颈不在模型、不在算力，而在改造能推进多快。

把时间拉长，这套模式能不能走通，还要看两件事。一件是小程序 MCP：这是微信 AI 调度小程序能力时遵循的调用协议，AI 通过它识别一个小程序有哪些原子接口可以调用、每个接口需要什么参数，再把任务派发下去。其底层是 Anthropic 2024 年底提出的开放标准 MCP，阿里、字节的智能体平台都在向这套标准靠拢，微信却在其上另做了一层。

微信官方文档的说法是，小程序的接口形态和网页服务差别很大，标准的 MCP 没法直接套用，所以小程序 MCP 按小程序的特点做了定制：开发者必须按规范提供完整的 SKILL 实现，小程序 AI 才能正确推理，执行相应的原子接口。这个定制的代价是，这个说明书只能在微信用，如果日后其他平台也各自加一层，同一个小程序，就得对着每个平台写一份说明书。

另一件是合规。据行业媒体报道，智能体安全强制性国家标准《智能体应用安全基本要求》已经立项，行为留痕、授权清晰、可追溯这些要求，迟早要计入开发成本。再往后，小程序的价值衡量标准可能从“被打开的次数”变成“被调用的概率”。

开发模式开放提审后的三个月，是一个可作判断的观察窗口。届时若接入的小程序中开发模式占比仍不足一成，“认真拆的只有头部”即成定论；若出现一批中小开发者自发改写 SKILL，且能拿出可归因的调用增量，这一判断就需要修正。决定走向的或许不是微信的决心，而是开发者的实际投入。

即便改造最终没有形成规模，这套规范本身也会沉淀下来。能力如何描述、参数如何传递、返回采用何种格式，这些约定一旦经过几百万开发者的实践检验，就会成为行业的事实标准，其价值不依赖本次改造的成败。

微信在这 130 天里完成了它的事，入口已经铺开规范已经写就，剩下的不确定项有两个，一是几百万个小程序主人的改造意愿，二是认真改造者能否获得对等回报。前者的答案在开发者社区，后者的答案在微信。这两个变量的兑现速度，决定这套生态未来两年的规模上限。（本文首发钛媒体APP，作者 | AGI-Signal，编辑 | 贾雨微）