微信AI助手要来了，小程序正在变成微信AI的Skill

今天微信公开课发了一条对小程序开发者非常重要的更新：开发者可以主动授权接入微信 AI 生态。

这件事表面看只是小程序后台多了一个「AI能力」入口，但我觉得它背后的信号非常大。

过去小程序的使用路径是：用户看到入口、点击小程序、自己找功能、自己完成操作。

但这次之后，小程序可能会进入一个新阶段：

用户只需要对微信 AI 说一句话，AI 就能理解需求，然后帮用户调用合适的小程序完成任务。

这才是这次更新真正值得开发者重视的地方。

以前是“小程序接入 AI”，现在是“微信 AI 接入小程序”

过去我们讲小程序做 AI，更多是开发者自己在小程序里接入大模型能力。

但这次微信的更新，方向变了。这次不是让你在小程序里加一个聊天框，而是让微信 AI 未来可以理解你的小程序，调用你的小程序，甚至帮用户操作你的小程序。

这个变化很像从「人找服务」变成「AI 找服务」。

也就是说，小程序未来不只是一个被用户打开的应用，而可能变成微信 AI 的Skill（技能）。

用户说“帮我点一杯热拿铁”，AI 可以调用咖啡小程序。

用户说“帮我查一下订单”，AI 可以调用电商小程序。

用户说“帮我创建一个 AI 智能体”，AI 可以调用智能体创建工具。

用户说“帮我记录今天吃了什么”，AI 可以调用热量记录工具。

这才是我觉得微信小程序开发者最大的机会。

AI能力模式解读

这次微信提供了两种模式：自动模式和开发模式。

自动模式比较简单，开发者授权后，平台在提审时读取小程序源码，分析你的小程序页面，让微信 AI 能直接操作。

这对中小开发者很友好，因为不需要额外开发。但自动模式的本质是：让 AI 尝试看懂你已经做好的页面，所以它对小程序页面设计提出了新的要求。

以前我们做页面，只要用户能看懂就可以。以后可能还要考虑：AI 能不能看懂？

比如按钮文案不能太抽象，最好是明确动作：不要只写“确定”，而是写“确认下单”，不要只写“下一步”，而是写“选择规格”，不要只写“完成”，而是写“支付完成”或者“保存地址”。

页面状态也要清楚：有没有地址？订单是否确认？支付是否成功？是否需要用户补充信息？当前流程能不能继续？

这些以前是用户自己判断，现在变成 AI 也要判断。

所以自动模式虽然低成本，但它其实会倒逼开发者重新整理小程序的页面结构、按钮语义和流程状态。

自动模式不是不用优化，而是把“小程序页面是否清晰”变成了 AI 能不能调用你的前提。

如果说自动模式是“让 AI 看懂页面”，那开发模式就是“你主动告诉 AI，我的小程序能做什么”。

微信官方开源的 ai-mode-demo就很值得看。

这个 Demo 是一个 WeStoreCafe 点单场景，官方 README 里写得很清楚：它演示的是如何把小程序业务封装成 SKILL，让 AI 完成饮品推荐、饮品详情查看、规格选择、地址选择、订单确认、支付、门店状态查询等流程。

这个结构非常关键。

它不是简单做一个页面给 AI 点，而是把业务拆成三层：

第一层是 SKILL 业务说明，告诉 AI 这个业务怎么走。 第二层是 原子接口，比如推荐饮品、搜索饮品、选择饮品、确认规格、保存地址、支付订单。 第三层是 原子组件卡片，把每一步结果展示成可操作的卡片。

官方 Demo 的项目结构里，skills/drink-skill下面包含 SKILL.md、mcp.json、index.js、apis和 components，同时还有 packageDetail半屏页面分包，用来承接更复杂的选择规格、浏览饮品、编辑地址等操作。

这说明微信 AI 的开发模式，不是单纯“让大模型自由发挥”，而是一个更工程化的体系：业务流程要写清楚，接口要结构化，组件要卡片化，复杂交互再跳半屏页面。

未来接入微信 AI 生态，不只是前端开发，也不只是接口开发，而是一次“业务能力结构化”。

小程序开发者最大的机会

我觉得这次更新的重要性在于，微信终于开始把小程序生态和 AI Agent 连接起来了。微信有大量真实服务场景：点单、购物、预约、查询、客服、支付、会员、内容、工具、企业服务。

这些服务过去都藏在一个个小程序里，用户需要自己找到、打开、理解、操作。

但微信 AI 助手出来后，用户的路径可能变成直接说：

“帮我订一杯咖啡。”

“帮我预约明天下午的理发。”

“帮我查一下会员积分。”

“帮我生成一份公众号封面。”

“帮我创建一个陪伴 AI 角色。”

“帮我把这个智能体发布到微信。”

用户不再关心这是哪个页面，也不关心按钮在哪里。用户只关心一件事：我的需求能不能被完成。

这就是小程序开发者的新机会。以前你要抢首页入口、抢搜索排名、抢分享传播。以后你还要抢一个新入口：你的能力能不能被微信 AI 调用。

这有点像过去网站做 SEO。未来小程序可能要做 AIO：AI Invocable Optimization，也就是“AI 可调用优化”。

谁的小程序能力更清楚，谁的业务链路更稳定，谁的卡片组件更好用，谁就更容易被 AI 调用。

对开发者来说，现在最应该做什么？

第一，先开自动模式，看看自己的小程序能不能被 AI 理解。

尤其是工具类、内容类、查询类、测评类、简单表单类小程序，可以先低成本接入。

第二，重新梳理核心任务链路。

不要从页面出发，而要从用户意图出发。

比如：用户想买东西、用户想查信息、用户想创建内容、用户想完成测试、用户想绑定服务、用户想支付订单。

每一个意图，都要拆成一个清晰流程。

第三，把核心业务拆成原子接口。

不要让 AI 直接猜页面，而是明确告诉它：这个接口什么时候调用、需要什么参数、参数从哪里来、返回什么结果。

第四，设计 AI 卡片组件。

不是把原来的页面缩小，而是重新设计适合对话场景的卡片。卡片只做一件事：让用户快速理解当前状态，并完成下一步动作。

第五，给复杂操作准备半屏页面。

比如选择规格、填写地址、编辑资料、上传文件，这些不适合全在对话里完成，就用半屏页面承接。官方 Demo 也是这样做的：主流程在 AI 对话和卡片里完成，复杂的饮品浏览、规格选择、地址编辑放到 packageDetail半屏页面里。

最后

这次微信更新，我觉得开发者不要只把它看成一个后台开关。

它真正代表的是：微信小程序正在从“用户主动打开”变成“AI 主动调用”。

以前，小程序是一个个独立应用。

以后，小程序可能是微信 AI 的一个个能力模块。

以前，我们做页面，是为了让用户看懂。

以后，我们做能力，是为了让 AI 能懂、能调、能安全执行。

这会改变小程序的开发方式，也会改变小程序的分发方式。

对普通开发者来说，这是一个重新入场的机会。

对有业务积累的小程序来说，这是一次新的流量入口。

对 AI 工具开发者来说，这是一个新的基础设施方向。

我自己的判断是：微信 AI 助手一旦真正开放，小程序生态里最先受益的，不一定是页面做得最复杂的产品，而是能力最清晰、流程最稳定、最容易被 AI 调用的产品。

未来的小程序，不只是给人用。

还要给 AI 用。