# 评测指南

评测工具是微信面向小程序 AI 开发模式的开发者提供的质量检测工具。开发者完成 SKILL 开发后，可使用评测工具自行发起评测，发现并优化代码缺陷，同时为微信 AI 调用开发者服务提供质量参考。本文档介绍评测工具的核心能力、使用流程以及评测报告的阅读方法。

# 一、评测介绍

# 1.1 评测工具介绍

小程序开发者完成 AI 开发模式代码开发后，平台和开发者需要针对 SKILL 的质量进行评测，帮助开发者发现问题并优化体验，同时给微信 AI 调用开发者的服务提供质量分参考。现面向开发者提供「评测工具」，支持开发者在微信开发者工具中的评测插件中自行发起评测。

评测工具当前在内测阶段，已支持开发者自测，向微信团队提交提审评测暂未开放。

开发者全流程示意图：

• 开发者自测与微信团队评测的能力差异如下：

评测工具全流程示意图：

# 1.2 核心价值

1）高效省时：自测支持选择指定的 SKILL 评测，避免长时等待

2）模拟真实对话场景：基于 SKILL，自动模拟用户与微信 AI 的交互过程，还原实际运行环境，发现问题

3）支持人工轨迹核验：可以在自动生成轨迹之后人工核验，对于问题轨迹重新人工对话更新

4）全流程可视化：全部功能集成于开发者工具，对比原先的评测 SKILL，整体操作更流畅

5）问题精准定位：评测完成后自动生成多维度评测报告，清晰呈现问题所在及优化方向，包含：服务交付、体验交互、场景覆盖、性能质量

# 二、评测工具使用指南

# 2.1 打开评测工具

# 2.1.1 下载微信开发者工具

1）下载安装 最新版本微信开发者工具

2）在「编译模式」入口切换到「小程序 AI 编译」，调试基础库切到 3.16.2 及以上

# 2.1.2 打开评测插件

1）点击评测插件入口

2）点击评测按钮后将拉起新窗口，此时在新窗口点击「信任并运行」，后续评测将在新窗口进行

# 2.2 自测（已支持）

# 2.2.1 环境配置

1）开启服务端口

2）配置模型（评测插件内测期间，开发者不需填写模型信息，微信团队承担此部分成本）

# 2.2.2 参数配置

# 关于「评测文件」的特别说明

评测文件是开发者基于自身开发的 SKILL 提交的自定义 Intent 集，Intent 集需包含简单 Query 和复杂 Query 两种类型。平台会基于评测文件生成评测用例，并在生成用例前对评测文件检测。提交微信团队评测时，评测文件必须通过全部检测项才可继续。

注意：自测建议评测文件先以 20 个用例为起步，而后逐步增加，最多可 3 个微信开发者工具账号同时跑。后续提审评测预计的用例数量要求至少 50 个。

评测文件检测要求

如何准备基础评测文件

1）下载并参考评测文件官方示例。官方示例中包含了示范用例和对应的业务对象信息：

评测用例编写规范

1）用真实用户语言填写 intent

• intent 应写成用户会真实说出的话，例如「帮我看一下满杯百香果有没有小杯或者中杯可选，有的话帮我下一杯冰的正常糖中杯」。
• 不建议写成接口调用说明，例如「调用 searchDrinks 接口查询商品，再调用 selectDrink 下单」。

2）覆盖主要业务能力

• 可对照当前 SKILL 能力和 mcp.json 中的工具，检查主要查询、筛选、对比、下单、修改订单、取消订单、保存地址等能力是否都有对应的自然语言用例。
• 不要只写大量相似句式，例如「买一杯 A」「买一杯 B」「买一杯 C」，也不要只围绕少数查询入口编写。

3）适当加入复杂用例

• 复杂用例不是把多个无关需求拼在一起，而是在同一个用户目标下包含多个相关步骤或条件。例如：先查询商品，再根据价格或规格选择；对比两个商品后选择其中一个；在某个条件满足时下单，不满足时选择替代方案；先确认订单或设备状态，再执行后续操作。

4）避免用例高度重复

• 同一类对象、同一句式或同一具体实体不要反复出现。
• 建议通过不同品类、不同条件、不同状态、不同业务阶段提升多样性，避免只是替换商品、设备、地点、数字来堆数量。

5）合理填写 entities

• entities 用于补充和本次请求相关的业务对象，例如商品名称、价格、规格、订单状态、收货地址等。同时用于了解评测文件的实体应该调用哪个原子接口，可以提升评测效率。
• entities 不是标准答案，也不是完整数据库。只需填写和当前用例理解相关的关键信息，并确保与 intent 能对应上。

6）source 填写工具名

• 如果填写 source，应填写 mcp.json 中定义的工具名，例如 searchDrinks、selectDrink。
• 不要填写接口说明、HTTP 地址或调用步骤。

上传前建议确认：

• 每条 case 都有清晰的 intent。
• 包含一定比例的多条件、多步骤、查询后操作或状态判断类用例。
• entities 与 intent 能对应上。
• source 中的工具名与 mcp.json 保持一致。

2）生成你的评测文件。对照 1）的说明及模板，可人工或用模型生成评测文件。

3）对评测文件检测。上传评测文件后，平台会对评测文件检测，检测结果会在下方展示。自测时，评测文件检测不通过不影响继续评测；提交微信团队评测时，评测文件检测必须全部检测通过才可继续。

「未注册场景」评测说明

当小程序部分服务需要用户先同意协议或登录才能使用时，对于未授权或登录的新用户，开发者当前容易忽视，因此新增此专项评测。

问题举例： 文案回复已经跳到点单页面，点开卡片实际为登录页或隐私授权页

1）评测文件：提供未注册场景用例，在评测文件中增加 tags 标记：

{
  "cases": [
    {
      "intent": "查一下我的历史订单和会员积分，帮我看看有没有能用的优惠券",
      "tags": ["unregistered"]
    }
  ]
}

2）未注册用例提供标准和数量

a. 未注册用例包含两种类型：

注：需要提供同意和拒绝两种情形的测试用例并自行测试。

b. 用例数量

注：

1. 如果开发者提供了多种授权能力，建议提供多条新用户用例。
2. 用例上限 5 个。

c. 用例举例：以咖啡小程序为例，搜索或推荐商品或服务意图的用例为「帮我点一杯冰美式」「有什么好喝的推荐一下」；私有数据查询意图的用例为「帮我查一下我之前点了什么喝的」「帮我看看我的会员积分有多少」。

3）评测工具未注册场景用例说明

• 对于标记了 tags: ["unregistered"] 的用例，平台不会按普通用例直接执行自动轨迹，必须人工核验。
• 点击「人工核验」后直接拉起切换测试号面板，需切换无业务数据的空白测试号（清空登录、授权等相关数据），对该用例进行人工核验生成人工轨迹。

注：

• 普通用例：建议准备包含对应业务流程信息的测试号，例如登录权限、订单、会员或其他业务数据，并提前在微信开发者工具中完成必要准备。
• 未注册用例：如果 case 标记了 tags: ["unregistered"]，请使用未登录授权且没有用户数据的账号，并通过人工核验补充该用例轨迹。不要将普通登录态账号的轨迹作为未注册用例的人工轨迹。

4）未注册用例评分说明

预期结果如下：

「位置标签」评测说明

为提升小微用户的本地服务体验，开发者提交的评测文件中需包含含有「位置标签」的 Intent。

1）评测文件要求

至少 3 条通过「位置标签」校验的有效 Intent，且这些有效 Intent 需合计覆盖以下三类位置维度：

• 空间副词：如附近、周边、旁边、离我、当前位置、这儿、那里等。示例：附近有啥餐厅推荐、我这旁边有公交站吗
• 具体地理实体：如城市、区、街道、地铁站、POI、地标等。示例：广州天气如何、打车去客村地铁站
• 含起终点关系或空间动作/范围：从 A 到 B、去某地、导航、路线、距离、配送范围、去 X、到 Y、怎么走、飞 Z、服务半径、服务地域范围等。示例：明天飞上海机票价格怎么样、从客村到白云机场 T2 坐什么地铁、这个保险能保我这边的三甲医院吗、看看 xx 餐厅的配送范围

2）如何提交「位置标签」评测文件

在相关 case 的 tags 中填写 location：

{
  "cases": [
    {
      "intent": "附近有哪些门店可以自提？",
      "tags": ["location"]
    },
    {
      "intent": "广州天河区的门店有生椰拿铁吗？",
      "tags": ["location"]
    },
    {
      "intent": "从广州南站到最近的门店怎么走？",
      "tags": ["location"]
    }
  ]
}

请只标注确实需要位置参与查询、筛选或履约的自然语言用例。仅提到地名、但答案固定且不随用户位置变化的知识问答，不建议标注 location，例如「上海有哪些景点」。平台会校验 location 标注是否与 Intent 的位置语义或服务行为相符；校验不成立的标签会被移除，该 Intent 不计入「位置标签」预检的数量和覆盖贡献度。

3）评测对象

经平台判定需提供「位置标签」Intent 的小程序（最近一段时间小程序有调用过 getLocation 接口且 SKILL 最新描述有涉及地理位置相关的服务）。

4）评分说明

命中「位置标签」的用例不通过时，和其他用例保持同等权重的计分逻辑。

「时间标签」评测说明

为提升小微用户的服务体验，开发者提交的评测文件中需包含有「时间标签」的 Intent。

1）评测文件要求

至少 2 条通过「时间标签」校验的有效 Intent，且这些有效 Intent 需合计覆盖以下两类维度：

2）如何提交「时间标签」评测文件

在评测文件对应 case 的 tags 数组中填写时间标签：

• 相对时间填写 relative-time
• 绝对时间填写 absolute-time

{
  "cases": [
    {
      "intent": "帮我看一下最近三天的订单，把最常点的那杯再下一单",
      "tags": ["relative-time"]
    },
    {
      "intent": "查一下9月8日下午3点的订单，帮我复购同样的饮品",
      "tags": ["absolute-time"]
    }
  ]
}

3）评测对象

经平台判定需提供「时间标签」Intent 的小程序（小程序有涉及时间相关的功能或 SKILL 最新描述有涉及时间的服务）。

4）评分说明

命中「时间标签」的用例不通过时，和其他用例保持同等权重的计分逻辑。

餐饮行业评测文件说明

为提升小微用户体验，平台指定了「外卖点餐服务」和「外卖到店自提」两类服务必须用 SKILL 和原子接口承载的流程，开发者须知：

1）提交微信评测时，「评测文件」中 Intent 需要覆盖到所有指定流程，且用例需要标注是自提或外卖，否则将不能继续评测。

外卖配送点餐

到店自提点餐

2）评测运行轨迹时，如开发者的 SKILL 未提供对应流程，Agent 无法完成任务，则「服务交付」分对应扣分，最终分数会影响综合评分。

3）评测对象：经平台分析，认为小程序核心功能命中「外卖点餐服务」或「外卖到店自提」，则针对对应小程序进行该项服务的服务完整性评测。

# 2.2.3 生成用例

1）支持查看、排序、删除、反馈用例

请你仔细检查每个用例，将需要登录、退登等操作的用例放到最后，避免因测试号登录等问题对轨迹生成造成影响。

# 2.2.4 生成轨迹

1）评测工具会先根据用例自动生成一轮轨迹，自动生成轨迹结束后，有两种情况需要开发者人工核验替换自动轨迹：

• 因评测环境或工具原因导致用例轨迹出现异常，平台会对该轨迹进行标记并提示开发者
• 开发者自行查看轨迹，认为自动化轨迹不符合预期

2）人工核验步骤：

# 2.2.5 执行评测 & 查看报告

可预览、下载评测报告，根据报告建议，进行优化后重新评测

# 2.2.6 更新功能

自测已支持重跑失败用例。点击历史评测按钮，拉起历史页面，选择对应报告重新评测，重跑失败用例

生成用例与轨迹阶段支持切换测试号与地理位置

# 2.3 微信团队评测（开放小程序 AI 开发模式的代码提审后提供）

该功能后续开放