小微灰度的第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 暂时用不了。 谁先真正行动了？ 不过，动作最快、牌桌最里侧的一批人，动手比指引还早。 据了解， 携程