评测指南

评测工具是微信面向小程序 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）下载并参考评测文件官方示例。官方示例中包含了示范用例和对应的业务对象信息：

注：填写未注册场景用例时，unregistered 表示用未登录、无用户数据的测试号核验该用例，并不表示用户的问题不涉及个人数据。请根据用例内容同时选择一个类型标签：查询我的历史订单、积分、已保存地址等既有个人数据，填写 private_data；搜索或推荐公开商品、服务等，填写 product_service。对“退款我的历史订单”这类请求，还应核对操作对象是否为用户既有数据；涉及既有个人订单时，填写 private_data。平台会校验 private_data 标注是否成立；如校验不成立，对应未注册场景标注可能被移除，该用例不再计入未注册场景数量。提交前请查看最终检测结果。

评测用例编写规范

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", "private_data"]
    }
  ]
}

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

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

注：评测文件中每条请求填写一条未注册用例，标注 unregistered 及对应的类型标签。平台为每条用例分别生成同意和拒绝两种执行情形；开发者须分别完成人工核验，保存两种情形的完整轨迹。用例类型与执行情形是两个不同维度：“私有数据类”和“商品或服务类”用于说明测试什么，“同意”和“拒绝”用于说明测试时用户怎样选择。

b. 用例数量

注：

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

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

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

• 对于标记了 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）评测对象：经平台分析，认为小程序核心功能命中「外卖点餐服务」或「外卖到店自提」，则针对对应小程序进行该项服务的服务完整性评测。

「负例标签」评测文件说明

为提升小微用户体验，平台指定需进行负例评测，开发者须知：

（1）评测文件要求

开发者针对负例需要单独打标，并在微信评测时，需要通过评测文件预检才能继续。

• 数量要求：8个 ≤ 负例数量 ≤ 10个
• 负例主要包含的类型和预期结果如下：

注：负例允许不调用工具下发卡片

（2）如何提交「负例标签」评测文件

在评测文件对应 case 的 tags 数组中填写负例标签"negative"：

{
  "cases": [
    {
      "intent": "帮我点2.5杯生椰拿铁",
      "tags": ["negative"]
    },
    {
      "intent": "帮我点一份香辣鸡翅",
      "tags": ["negative"]
    }
  ]
}

（3）评测对象

全部小程序

（4）评分说明

评测运行轨迹时，若未按预期结果呈现或者标注的负例不是真正有效的负例时，命中「负例标签」的用例不通过，和其他用例保持同等权重的计分逻辑

2.2.3 生成用例

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

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

2.2.4 生成轨迹

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

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

2）人工核验步骤：

2.2.5 执行评测 & 查看报告

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

2.2.6 更新功能

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

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

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

该功能后续开放

文档变更日志（1条）

2026 年 10 月 14 日

未注册场景 用例新增 private_data 、 product_service 类型标签；新增对未注册场景用例的轨迹执行评测打分