微信AI开发模式的代码提审通道正在逐步打开，但“开闸”不等于“放水”。官方评测规则里写着一组相当硬核的数字：首次提交微信团队评测，服务交付、交互体验、性能质量三项均需达到80分，场景覆盖需达到60分，任意一项未达标，提审即判定为不通过。没有“综合分够了就行”的缓冲地带，差一分，就是差一个资格。[1]
对于正在关注微信AI开发模式提审80分门槛的开发者来说，理解这四项指标各自考察什么、怎么扣分，比笼统地“优化体验”更有实际意义。
四项指标并非同一套打分方式，拆开看才能找到优化抓手。
服务交付（≥80分） 的计分方式最“颗粒化”。它的逻辑是：每个用例的每一轮Query，检查两项——文字有效性（回复是否真正解答了用户需求）和页面有效性（是否为Query配置了“账号卡片”，以及卡片对应的handoff页面与文字回复的关联强度是否足够）。服务交付得分 = 通过的检查项 ÷ 全部检查项，按比例扣分。值得注意的是，当回复仅调用知识库时，页面有效性这一项不触发评测，意味着纯知识库场景下“服务交付”的考察维度会收窄，文字质量成为唯一变量。[1]
交互体验（≥80分） 聚焦一个更窄但更直观的点：用户通过AI访问和操作小程序时，“账号卡片”对应页面的流畅度。它的评测范围不覆盖整个小程序的所有页面，而是集中在AI实际“递出去”的那张卡片所指向的页面。这意味着页面性能优化的优先级，应当向handoff落地页倾斜。[1]
性能质量（≥80分） 考察的是“接口”和“文档”两个层面：AI相关接口本身的质量，以及配套文档的质量。它是四项中与工程规范关联最直接的一项，接口的稳定性、响应结构、错误处理是否达标，会在这里体现。[1]
而场景覆盖（≥60分） 之所以门槛更低，是因为它的考察对象不同：它衡量的是AI开发模式对小程序核心功能Top 1和Top 2的覆盖程度。60分的线意味着平台允许开发者先从最核心的一两个场景切入，不要求首版就做到全功能覆盖。但这不代表可以忽视——它的扣分逻辑是“覆盖缺失”，如果Top 1或Top 2功能在AI侧完全没有对应的SKILL承接，这一项的分数会直接反映出来。[1]
一个容易被跳过的步骤，恰恰是控制提审成功率的关键。官方评测工具同时提供了开发者自测和微信团队评测两条路径，两者流程基本一致，但在门槛上有实质性差异。
最核心的差异在评测文件上。开发者自测对Intent数量的要求是≥1且≤100，且“其他检测项不通过可继续评测”；而微信团队评测要求Intent数量≥50且≤100，并且任一检测项不通过，评测就无法继续。换句话说，提审本身的“入场券”就是一份合格的评测集——Intent太少、格式不规范，可能在正式打分之前就被拦下。
评测版本的范围也不同：自测支持对最新上传的10个开发版发起，而团队评测仅支持最新的体验版和1个线上版。这意味着开发者有充足的空间在开发版上反复跑自测、修问题，把最稳定的一版放到体验版上再去提审，而不是拿提审当调试。
官方在GitHub上开源的 wxa-skills-eval 工具可以在本地或云开发环境中完成端到端质量评估，覆盖意图理解、轨迹生成和最终答案质量，并输出多维度报告。建议的节奏是：开发阶段先用自测把明显缺陷清掉，计划提交审核前再发起微信团队评测。
通过门槛靠分数，但被微信AI持续调用靠的是SKILL封装的准确度。官方《SKILL设计建议》里披露了一套明确的注意力权重体系，它揭示了一个容易被误解的事实：写在SKILL.md里的信息，优先级并不高。
| 信息源 | 注意力权重 | 实际影响 |
|---|---|---|
原子接口返回的 content |
★★★★★ | 离决策点最近，模型当作“事实+动作”读取 |
mcp.json 接口 description |
★★★★ | 决定模型“选不选这个接口” |
mcp.json inputSchema.description |
★★★★ | 决定模型“怎么填参数”，字段级约束的核心位置 |
SKILL.md |
★★★ | 适合写流程编排、跨接口规则、意图分流 |
这意味着，接口 description 写得模糊，模型就会选错接口；参数 description 缺少约束，模型就会填错值，而这些问题在 SKILL.md 里写再多“注意事项”也很难弥补。官方列出的常见错位包括：把“接口本身的功能”写进 SKILL.md，导致与 mcp.json 不一致；把“跨多接口的业务规则”塞进单个接口的 description，导致其他接口决策时模型根本读不到。[2]
优化的方向因此变得清晰：把功能描述和参数约束的精度投入到 mcp.json 的两个 description 字段上，把流程规则放在 SKILL.md，把 content 严格限定为“本次调用结果 + 下一步动作”。内容写在哪里，比写了多少更重要。
提审通过只是拿到了入场券。上线后，平台会持续监测线上表现，触发“离场”（暂停AI调用资格）需要三个条件同时满足，缺一不可：
三个条件同时命中的设计，实际上给了开发者一个缓冲带：问题率超标但会话量不足，或者分数仍然达标，都不会直接触发离场，但平台会发送告警通知，提示“若连续三次超标，可能无法被调用”。这是一个明确的优化窗口，而不是突然死亡。
一旦离场，MP后台的“线上状态”会变为“已失效”，用户无法再通过微信AI使用该小程序的开发模式服务。恢复路径是：针对问题优化代码，重新提交版本并通过微信首次评测，然后将通过评测的代码发布上线，重新走“灰度→全量”流程。
截至目前，多份官方文档和开发者社区信息仍指向开发模式处于内测阶段。有资料明确标注“当前处于内测阶段，暂未开放小程序AI开发模式的代码提审”，也有近期文章确认“开发模式目前是内测阶段，官方代码提审还没开放”。这意味着本文讨论的分数门槛和离场规则，在规则层面已经清晰，但实际提审入口的开放节奏可能因账号资质或灰度批次而异。建议开发者在动手优化之前，先确认自己MP后台的“AI能力”页面是否已经出现提审入口，再据此规划节奏。
对于以微信AI开发模式场景覆盖60分为切入点、希望先跑通核心功能的团队来说，规则本身并不苛刻。真正需要警惕的是两个惯性思维：把提审当调试，以及把SKILL.md当成万能文档。前者会在评测文件环节就被拦住，后者会在上线后以“接口选错、参数填错”的形式持续拉低问题发生率，直到离场条件被一条条填满。
参考资料：
