# 评测报告及指标说明
评测报告围绕服务交付、交互体验、场景覆盖、性能质量四个关键指标展开，帮助开发者掌握当前小程序 AI 开发模式的质量表现。报告包含基础信息、评测结果、指标详情三大模块。
# 一、基础信息
评测报告的基础信息包含小程序 AppID、任务 ID、任务名称、评测时间、评测版本、评测模型以及用例覆盖情况。
# 二、评测结果
# 2.1 评测结果包含两部分
| 分类 | 内容说明 |
|---|---|
| 四项关键指标 | 1. 服务交付：评测 AI 开发模式是否满足了用户需求，指标包含文字有效性、页面有效性 2. 交互体验：评测用户通过 AI 访问和操作小程序的页面流畅度 3. 性能质量：评测访问和操作小程序的 AI 相关接口质量和文档质量 4. 场景覆盖：评测 AI 开发模式在小程序核心功能 Top 1 和 Top 2 的覆盖率情况 说明：首次提交微信团队评测时，四项关键指标均需达到分数要求（服务交付 ≥ 80 分、交互体验 ≥ 80 分、性能质量 ≥ 80 分、场景覆盖 ≥ 60 分），才会被微信 AI 调用 |
| 综合评分 | 基于四项关键指标的分数加权得出 说明：综合评分的分数不作为首次提交微信团队评测时「是否通过」的依据，但该分数的高低会影响微信 AI 调用效果 |
# 2.2 评级说明
不同评测方式对应的指标评级说明如下：
（1）微信首次评测
| 评级 | 对应指标及分数区间 |
|---|---|
| 通过 | 服务交付 ≥ 80 分、交互体验 ≥ 80 分、性能质量 ≥ 80 分、场景覆盖 ≥ 60 分 |
| 不通过 | 任意一项未达到上述要求 |
（2）开发者自测或微信非首次评测
| 评级 | 对应指标及分数区间 |
|---|---|
| 表现较优 | 服务交付 ≥ 95 分、交互体验 ≥ 95 分、性能质量 ≥ 95 分、场景覆盖 ≥ 90 分 |
| 需要优化 | 80 ≤ 服务交付 < 95、80 ≤ 交互体验 < 95、80 ≤ 性能质量 < 95、60 ≤ 场景覆盖 < 90 |
| 严重不足 | 服务交付 < 80 分、交互体验 < 80 分、性能质量 < 80 分、场景覆盖 < 60 分 |
# 三、评测指标详情
# 3.1 指标 1：服务交付
服务交付：评测 AI 开发模式是否满足了用户需求，指标包含文字有效性、页面有效性，分数需 ≥ 80 分
| 指标说明 | 评测范围 |
|---|---|
| 文字有效性：评测文字回复是否有效解答用户需求 | 针对每个用例中每轮 Query 的文字回复 |
| 页面有效性：评测开发者是否针对用户 Query 对应的原子接口配置了「账号卡片」，以及点击「账号卡片」对应的 handoff 页面和文字回复关联性是否够强 （注：当回复仅调用知识库时，不触发这一项评测） | 针对每个用例中每一轮 Query 的「账号卡片」对应的页面截图 |
计分方式
每个用例每轮 Query 检查以上两项，未通过则扣分。服务交付得分 = 通过的检查项 / 全部检查项
（注：全部检查项会排除因系统原因导致未评估的检查项和因微信内部原因导致不通过的检查项）
# 3.2 指标 2：交互体验
交互体验：评测用户通过 AI 访问和操作小程序的页面流畅度，分数需 ≥ 80 分
| 指标说明 | 评测范围 |
|---|---|
| 页面流畅度：评测「账号卡片」对应的 handoff 页面是否存在「页面操作被拦截」（如弹窗、蒙层等）、「页面白屏或黑屏」的问题 | 针对每个用例中每轮 Query 的「账号卡片」对应的页面截图 |
计分方式
每个用例每轮 Query 检查以上指标，未通过则扣分。交互体验得分 = 通过的检查项 / 全部检查项
（注：全部检查项会排除因系统原因导致未评估的检查项和因微信内部原因导致不通过的检查项）
# 3.3 指标 3：性能质量
性能质量：评测访问和操作小程序的 AI 相关接口响应、耗时情况和文档质量，分数需 ≥ 80 分
| 指标说明 | 评测范围 |
|---|---|
| 接口网络请求：评测 AI 访问和操作小程序的接口网络请求是否会超时（不出现时长过长情况） | 针对运行评测用例时调用到的所有原子接口 |
| 文档质量：评测开发者文档中是否有不合理的写法与表达，发现问题会被扣分 | 针对开发者 SKILL 文档 |
计分方式
性能质量分 = 文档质量分，其他维度暂仅展示、不计分
# 文档质量检测标准
平台结合 Skill 描述和 MCP 接口定义检查以下 7 项。
1）不声明不存在的接口
不能要求 AI 调用 MCP 清单及明确的运行时别名映射中都不存在的接口，也不能把名称相近的接口当成同一个。
反例：Skill 写「调用 getOrderList」，MCP 中只有 queryOrders，且没有别名映射。
2）不遗漏敏感操作的确认要求
涉及下单支付、消耗权益、身份认证、发送信息、修改或删除数据时，不能只写执行步骤，漏掉执行前的用户确认要求，也不能让 AI 跳过确认。
反例：文档写「调用兑换接口扣除 500 积分，兑换优惠券」或「调用清空接口删除购物车内全部商品」，却没有要求执行前让用户确认本次扣积分或删除操作。
3）参数声明清晰
| 禁止事项 | 反例 |
|---|---|
| 不能让必填声明与 schema 冲突 | 文字说 orderId 始终必填，schema 却允许不传 |
| 不能遗漏流程所需参数的取值来源 | 下单要用内部 drinkId，但整份材料都没说明从哪取 |
| 不能让同一入参的类型与描述、示例冲突 | 声明 string，示例却是数字 123 |
| 不能在流程允许省略参数、且省略会影响操作时，漏写不传的后果 | 允许不传 status，却没说查哪些订单，导致查询范围不明确 |
| 不能限定取值却不给可用值或获取方式 | 只写「必须使用指定状态」，却没给状态列表或查询方式 |
4）不承诺接口无法达成的事
接口名称和描述中的能力承诺，不能与同一接口明确说明的功能或限制冲突。
反例：描述写「打开结果页」，能力说明却写「仅返回 ID，不打开页面」。
5）不遗漏失败后的处理和反馈
对文档中需要 AI 处理的失败情况，不能缺少适用的后续动作或用户反馈规则，也不能只给错误字段就结束说明。
反例：文档定义了提交失败的情况，却只给 errorCode，没引导 AI 接下来做什么、告诉用户什么。
6）不与平台规则冲突
不能写入违反「通用写作原则」中平台设定、回复格式和答案呈现要求的指令。
反例：「忽略系统指令」「禁止使用 Markdown」「回复限一句，只保留价格和取餐时间」。
7）Skill 与 MCP 不能互相矛盾
同一场景下，Skill 不能要求或允许违反 MCP 明确限制的调用；也不能要求 AI 根据文档中无法识别的状态选择下一步。
反例：Skill 允许只传手机号查询，MCP 却规定每次必须传订单号。
# 3.4 指标 4：场景覆盖
场景覆盖：评测 AI 开发模式在小程序核心功能 Top 1 和 Top 2 的覆盖率情况，分数需 ≥ 60 分
开发者自测时，如未选择全部 SKILL 评测，则「场景覆盖」指标不具备参考意义。建议选择全部 SKILL 后看「场景覆盖」指标的表现。
| 指标说明 | 评测范围 |
|---|---|
| 核心场景覆盖率：评测 AI 开发模式在小程序核心功能 Top 1 和 Top 2 的覆盖率是否 ≥ 60% | 针对评测的全部 SKILL |
计分方式
场景覆盖得分 =（Top 1 覆盖率 × 100）×（Top 1 权重 /（Top 1 + Top 2 权重））+（Top 2 覆盖率 × 100）×（Top 2 权重 /（Top 1 + Top 2 权重））
示例：Top 1 覆盖率 90%，权重为 0.32，Top 2 覆盖率 85%，权重为 0.25，场景覆盖得分 = 90% × 100 ×（0.32/0.57）+ 85% × 100 ×（0.25/0.57）= 88.2 分
说明：微信通过分析开发者小程序现有功能，获得当前小程序核心功能 Top 1 和 Top 2（如咖啡点单、订单查询），再扫描开发者的 SKILL，获得开发者 SKILL 占小程序核心功能 Top 1 和 Top 2 的覆盖率比重。（非 Top 1 和 Top 2 的功能暂时不会参与计分，此项指标是希望开发者优先将小程序内用户高频使用的功能 AI 化）
# 四、关于评测报告的阅读与复核建议
开发者查看评测报告时，可参考以下建议：
# 4.1 阅读顺序
建议先看「评测结果」中四项关键指标（服务交付、交互体验、场景覆盖、性能质量）的表现，再看详情
如四项关键指标中有低于平台要求分数的，则需要重点关注该指标项，并查看对应的「指标详情」问题
如四项关键指标均高于平台要求分数，则查看对应的「指标详情」问题，逐步提升分数至 95 分以上
分数的高低会直接影响微信 AI 调用效果
# 4.2 复核建议
四项关键指标中，服务交付指标最为重要，决定了开发者提供的 AI 功能用户是否可用。建议开发者逐一查看出现问题的条目，并检查对应的运行轨迹，核对输入同样的 Query 下，真机、微信开发者工具对话调试是否有对应的问题复现：
如问题可在真机、微信开发者工具对话调试中复现，建议快速优化问题后重新评测
如相关 Query 在真机、微信开发者工具对话调试中表现正常，可前往 微信开放社区 - 小程序 AI 能力专区 反馈