客户问小程序能不能被微信AI调用，我们把他的后台开关从头拨了一遍

上周一个做本地家政的客户发来一张截图：他在微信里问「附近有没有今天能上门擦玻璃的」，答案里直接跳出了同行的小程序卡片，他家的没有。我们打开他家小程序后台，把 AI 能力那一栏从头看了一遍——开关是关的，页面结构也压根没给 AI 留接口。

变化发生在六月，很多人还没反应过来

2026 年 6 月 8 日，微信开放平台发了《关于开发者接入微信 AI 生态的指引》。这份文件说的不是新功能，是调用关系的改变：过去小程序靠用户搜索、点进去、一步步操作；现在可以让微信 AI 先搞懂你的小程序能干什么，在用户说出需求那一刻直接匹配、调起。

据 10 月中旬的公开报道，微信官方已明确：未完成接入的小程序将无法被微信 AI 调用。这不是「接入了有好处」，而是「不接入就没有」。

两种模式，先分清楚再动手

• 自动模式：后台开关一开，平台自己读源码、分析页面，一行代码不用写。门槛几乎为零，代价是理解得粗。
• 开发模式：自己改造，把功能抽象成原子接口和原子组件，封装成 SKILL，通过小程序 MCP 协议暴露给 AI。理解得准，但要写代码。

两种可以同时开。建议是：自动模式今天就开，开发模式等开放提审再上，但接口怎么拆、字段怎么命名现在就得想。

该模式官方标注仍是 beta，内测期暂未开放代码提审，别把相关代码合进正式版。

写在哪，比写了什么更重要

开发模式的核心是 SKILL 封装：mcp.json 声明函数和参数，apis 放原子接口，components 放原子组件，SKILL.md 写流程。官方最佳实践里有张「注意力权重」表，我们给每个客户都念一遍：

• 原子接口返回的 content：五颗星，离决策点最近，模型当事实读。
• mcp.json 的接口 description、参数的 inputSchema.description：四颗星，决定模型选不选你、参数怎么填。
• SKILL.md：三颗星，适合写跨接口的流程编排，别指望它纠正字段。

坑就出在这。有个饮品客户把「饮品 ID」的描述只写了四个字，模型自己按格式编了一个；改成「饮品唯一标识，取自 searchDrinks 接口返回」才正常。

接口返回建议用「事实 + 动作」两段式：先说发生了什么，再说下一步做什么。只写动作，AI 容易把「展示卡片」当成「准备调下一个接口」，跳过用户确认——交易场景要出事。

登录态这块，是微信的护城河

客户第一反应是：AI 替用户下单，那用户是谁？官方文档说得很清楚，该模式下登录身份跟原小程序一致，账号、地址、会员等级、优惠券全都继承下来，不用再登录一遍。这也是这件事值得做的理由。

我们给客户跑过的六步清单

• 第一步：后台开自动模式。零成本、当天生效，先把「能不能被调用」的资格拿到。
• 第二步：列功能清单。把小程序能独立完成的事按场景拆成 3 到 5 个，比如预约、查单、改地址、问价、售后。
• 第三步：每个场景写一个原子接口，输入输出写死，字段名别用拼音缩写，模型猜不出来。
• 第四步：description 写成给陌生人看的一句话，取值范围、来源、单位全写进去。
• 第五步：配原子组件卡片和接力页面，卡片右上角留进入小程序的入口，接力页配置会影响调用效果。
• 第六步：自己当用户在对话框里问 20 句人话，看它选不选对接口、有没有跳过确认。这步省不掉。

三条边界：半屏页面只许展示详情，不许跳去公众号、视频号、别的小程序或地图 App；参数标了「可选」却不给默认值，AI 会自己填；一个小程序可以封装多个 SKILL，别全塞进一个。

最后客户问的一句话

那个家政客户问我，现在做是不是太早。我说不早，因为这件事改的不是代码，是别人怎么描述你的服务。能被 AI 说清楚，才有机会出现在答案里。