微信开发者昨日推送了一封通知，里面有一句话读起来分量不小：未完成接入的小程序，将无法被微信 AI 调用。
这也意味着微信 AI 生态的接入窗口已经打开，开发者自主选择接不接，不接就等于放弃被 AI 推荐和调用的资格。
在cursor编程工具出来时，那个时候也做了个工具类小程序，核心功能是拍照识别单词，画面里的物品弹出对应单词，意思，读音，底层调用的是还是当时多模态最好的阶跃星辰API（听说正在冲刺港股IPO）。
这个小程序上线后我基本就没怎么动过，一直处于能跑就行的状态。直到这个通知才把它翻出来，重新申请了 AI 能力，开启了自动模式。
微信官方的开发文档和一些开源示例项目的源码都在下面，不管你是第一次听说，还是已经想动手试试，都能找到有用的东西。。
01.
微信接入AI
先搞清楚这回事
官方目前提供了两种模式。
自动模式下，你授权微信平台在提审时读取小程序源码，平台自动分析页面结构，生成 AI 可以直接操作的能力。
开发者不需要写任何额外代码，代价是 AI 能调用的深度和精度完全由平台决定，开发者没有控制权。
除此之外，有几个细节值得提前知道。
平台会根据小程序的主体资质、适用类目、代码质量、功能合规性等因素，自行判断是否允许你的小程序被微信 AI 调用，开了自动模式不等于一定会被推荐，平台有最终决定权。
并且每次你更新小程序代码提审，平台都会重新读取代码并同步更新技能，技能会跟着版本迭代走，不需要单独维护。
生成的技能内容你可以在后台查看，知道平台基于你的代码生成了什么。如果中途关掉自动模式，已生成的技能会停止调用，平台有权删除相关数据，再次开启的话需要重新提审才能生成新技能。
开发模式下，开发者自己动手，把小程序的功能封装成标准化的 Skill，经过平台评测和审核后被微信 AI 精确调用。
开发成本更高，但你能完整定义 AI 能做什么、不能做什么、每一步的流程是什么。不过你可以将整个微信开发工具路径丢给codex等智能体，使用cli.bat的命令行方式进行开发。
这两种模式不互斥，可以同时开启。目前先开了自动模式，开发模式正在研究怎么改造。
官网入口在微信公众平台的基础功能 → AI 能力，或者在微信开发者助手小程序里的微信 AI 管理。
而在理解 Skill 之前，先想一下传统小程序的交互逻辑。
用户进入首页，找到功能按钮，跳转页面，填写表单，提交。每一步都需要用户主动操作，整条链路完全依赖页面导航。
Skill 把这个起点提前到了对话里。用户在小程序的 AI 对话框说一句"帮我记个待办，买牛奶"，AI 理解意图，自动找到对应的功能，把参数填好，执行逻辑，最后把结果以卡片的形式展示在对话里。
用户甚至不需要知道背后调用了什么接口。
这套机制底层是小程序 MCP 协议，微信客户端运行时与小程序 AI 后台按照这个协议交互。开发者不需要理解协议细节，按规范把 Skill 实现完整就行。
对于Skill 的基本结构，会将一个 Skill 放在独立分包里，有五个核心文件。
mcp.json 负责向 AI 声明有哪些函数、参数怎么填、用哪张卡片展示。apis 目录下放的是原子接口，真正做事的函数就在这里。
index.js 负责把函数注册给运行时。components 目录放的是原子组件，用来把结果渲染成对话里的卡片。
SKILL.md 是可选的业务 SOP，告诉 AI 这个场景的完整流程。
有一个底层限制必须提前知道。原子接口、原子组件、实时动态组件各自跑在三个完全隔离的 JavaScript 执行上下文里，全局变量不共享。
数据只能通过原子接口返回的 content、structuredContent、_meta 三个字段在各层之间流动。很多开发者在这里踩坑，用全局状态传数据是行不通的。
02.
封装成Skill
官方完整路径拆解
说完概念，直接进源码。
微信官方开源了一个咖啡点单的完整 Demo（ai-mode-demo），以及一个覆盖 11 个行业场景的示例库（awesome-miniprogram-skills）。
把这两个项目从头到尾拆了一遍，下面以咖啡点单为主线，完整走一遍封装流程。
第一步，确定业务边界，拆出原子动作。
咖啡点单这个场景，传统小程序的流程是进首页、浏览菜单、选饮品、选规格、填地址、确认订单、支付。封装成 Skill 之后，这条流程要被拆成一个个独立的原子动作。
在官方咖啡点单 demo 里，这个场景拆出了 10 个原子接口。
分别负责推荐饮品、搜索饮品、查看详情和规格、确认规格生成订单、调起地址选择、保存地址、重新展示订单、发起支付、查询门店状态、获取全量饮品列表。
拆接口的核心原则是每个接口只做一件事，接口之间通过业务状态流转来衔接，整个流程不依赖 AI 的记忆。第二步，写给AI看的业务说明书 SKILL.md
SKILL.md 经常被开发者忽视，以为是个可选项随便写写。
实际上这个文件是整个 AI 理解业务边界和执行顺序的重要上下文，它决定了 AI 会不会按你期望的流程执行。
它的定位是给 AI 看的业务 SOP，要写清楚两件事。
第一件是执行顺序约束。
咖啡点单的说明书里明确写了，AI 不能跳过查看规格直接确认订单，不能跳过确认订单直接发起支付，支付没有成功返回之前禁止告诉用户支付成功。
这些约束非常关键，AI 如果只看功能名称，可能为了省步骤直接跳到支付，导致业务状态错乱。把流程约束写进说明书，相当于给 AI 装护栏。
第二件是数据来源声明。
饮品的唯一编号必须来自推荐或搜索功能返回的结果，订单编号必须来自下单功能的返回值，不能由 AI 自己编造。
第三步，接口契约 mcp.json 的写法细节
这个文件是 Skill 的功能清单，它决定了 AI 能不能选对功能、填对参数。有几个写法细节直接影响 AI 的表现质量。
每个功能的描述要写触发条件，而不是功能说明。
写"查询推荐饮品"效果很差，写"当用户表达想喝点什么、推荐几款、随便来一杯等模糊意图时触发"效果好得多。
AI 根据这段描述来决定调哪个功能，写触发条件比写功能说明有效。
功能执行完之后的返回内容也有讲究，分三层。
第一层是给 AI 看的文字提示，建议先说清楚执行结果，再告诉 AI 下一步该做什么，比如"已根据所选规格生成订单，请展示订单确认卡片，并引导用户核对后下单"。
第二层是给 AI 继续使用的结构化数据，比如饮品编号、订单编号、当前状态。
第三层是给卡片渲染用的私有数据，比如图片地址、完整价格明细，这部分不会被 AI 误读误用。
第四步，原子组件如何驱动下一步流程
原子组件的设计在整套机制里相当关键。它不是普通的展示组件，而是 AI 对话流程里的一个交互节点。
用户在推荐饮品卡片上点了一款咖啡，卡片不会直接跳转页面，而是把用户的选择作为一条消息发回给 AI，同时告诉 AI 下一步要触发哪个功能、带上什么参数。
用户看起来是在点卡片，底层其实是在向 AI 发送消息，触发下一个原子接口的调用。卡片就是流程节点，点击就是意图表达，这是整套设计的核心交互逻辑。
第五步，半屏页面承接复杂交互
AI 对话卡片的空间有限，宽度固定随屏幕宽度，高度最小 4:1 最大 1:1，不支持竖向滚动。
复杂的表单或长列表放不进卡片里，这时候用半屏页面来承接。比如选择温度、糖度、杯型、加料这种多维规格，就放在独立的半屏页里。
用户完成选择后，页面把规格数据发回给 AI，继续推进后续流程。半屏页相当于 AI 对话里的补充交互容器，用完自动回到对话流。
有两个限制要注意，半屏页不允许跳转到另一个半屏页，也不能作为小程序主功能的唯一入口，否则审核会视为导流行为。
以上这套范式可以迁移到任何业务。
看完咖啡点单之后再看那个 11 个场景的示例库，会发现无论是排队取号、医院挂号、打车出行、生活缴费，还是外卖点餐，背后的封装路径是完全一样的。
用户说出业务意图，AI 调原子接口，接口返回结构化结果，原子组件渲染成卡片，用户点卡片触发下一步，直到状态闭环。
而电商和餐饮类小程序会是最快落地的场景。点单流程天然适合对话驱动，支付链路也已经跑通（近期微信也在内容AI付）。
可以想象一下类似美团点外卖、淘宝千问购物助手那种体验，微信这次做的事是把这个能力开放给所有小程序开发者。
工具类和内容类的小程序需要多想一步，找到适合对话的那个业务切口。
03.
三个工具链
从生成到评测的开发闭环
光靠手写 Skill 代码效率很低，写完也不知道 AI 真的会不会用。
微信官方配套提供了三个skill工具，组成了一条从代码生成到质量评测的流水线。
其中wxa-skills-generate，让AI帮你生成 Skill。
这个工具读取你已有的小程序项目，扫描页面、接口、登录态、云函数、网络请求和 JSAPI，然后自动生成 Skill 的代码结构。
它会先判断业务边界，找到源页面，追踪点击事件，分析接口依赖，再决定生成哪些原子接口和组件。
你可以对它说帮我把商品检索和订单管理做成Skill，它会在写代码之前先走一遍完整的澄清和扫描流程。对于已有小程序的开发者，这个工具是最快的起点。
这第二个wxa-skills-validate，会把validate 工具负责证明生成出来的 Skill 是否真的合格，校验分三层。
静态校验检查文件结构是否完整、接口是否都是 async function、返回值是否符合 outputSchema、组件取值是否来自接口返回、setData 和 WXML 绑定是否一致、app.json 里的 description 是否存在且非空，规则非常具体，覆盖了开发者最容易犯的低级错误。
编译校验接入微信开发者工具 CLI，调用真实环境执行原子接口，验证接口能不能真正跑通。
组件渲染验证则确认接口返回的数据能不能成功渲染成卡片截图。
Skill 的失败经常是路径不对、分包没注册、组件字段取错、CSS 不被宿主环境支持这些具体问题，而非语法问题。validate 专门抓这些问题，把代码从草稿状态推到可交付状态。示例库里咖啡点单 Demo 跑出来的结果是 257 passed、0 failed、0 errors、0 warnings，这是对外展示的标准。
第三个wxa-skills-eval，前两个工具解决的是技术上能不能跑，eval 解决的是用起来好不好用。
它的评测流程有 12 个串行节点，连接开发者工具、分析 API 依赖、让 LLM 探索页面、收集业务实体、生成测试意图、模拟多轮对话轨迹、生成打分标准、对话质量打分、失败归因，最后生成完整的 HTML 评测报告。
报告会给出通过率、缺陷详情、接口覆盖率、文档质量评分。
打分用三档制，1.0 是完全通过，0.5 是部分通过，0.0 是不通过。你可以自定义 checklist，精确定义每种结果对应的标准。
官方建议每个 Skill 至少跑 30 条测试 case，这是保证覆盖率的最低门槛。
使用前需要自己配置一个 OpenAI 兼容的 LLM 服务，模型信息微信团队不会获取。建议用真实的微信测试号来跑，里面要有完整的业务数据。涉及支付的测试要关闭免密支付，避免真实扣费。
目前整个 AI 开发模式还在内测阶段，但有几个重要限制需要提前了解。
真机预览目前只支持 iOS，而且需要微信 8.0.74 以上版本，安卓近期会上线。提审工具也还没开放，评测结果只能用于自测，不能直接用于提审。代码提审也暂未开放，Skill 相关代码别合进正式版本去提审。
此外，uni-app 项目有一个兼容问题，uni-app 会替换全局的 wx 对象，导致 wx.modelContext 变成 undefined，需要用 patch-package 手动给 @dcloudio/uni-mp-weixin 里补上 modelContext 字段。
如果想直接看代码，TencentCloudBase/awesome-miniprogram-skills 是 11 个行业场景示例库，找自己业务最接近的那个参考。wechat-miniprogram/ai-mode-skills 是三个工具链的仓库，generate、validate、eval 都在这里。
地址：https://github.com/wechat-miniprogram/ai-mode-skills
地址：https://github.com/TencentCloudBase/awesome-miniprogram-skills
地址：https://github.com/wechat-miniprogram/ai-mode-demo
不管你的小程序是什么类型，先把自动模式开了是成本最低的起点。平台会分析你的小程序页面，让微信 AI 能直接操作。
往大了看，这件事和GEO的逻辑是一样的。
GEO是Generative Engine Optimization的缩写，意思是针对AI生成式引擎做优化，让自己的内容或服务更容易被AI推荐和调用，和过去做SEO抢搜索排名是同一个底层逻辑，只是战场换了。
微信这套Skill机制本质上就是在小程序生态里建了一套GEO规则，mcp.json里的接口描述写得越准确，SKILL.md里的业务流程越清晰，你的小程序被微信AI选中的概率就越高。
从“让搜索引擎读懂你”到“让AI读懂你”，开发者该做的事从来没变过。
