# 评测指南
评测工具是微信面向小程序 AI 开发模式的开发者提供的质量检测工具。开发者完成 SKILL 开发后，可使用评测工具自行发起评测，发现并优化代码缺陷，同时为微信 AI 调用开发者服务提供质量参考。本文档介绍评测工具的核心能力、使用流程以及评测报告的阅读方法。
# 一、评测介绍
# 1.1 评测工具介绍
小程序开发者完成 AI 开发模式代码开发后，平台和开发者需要针对 SKILL 的质量进行评测，帮助开发者发现问题并优化体验，同时给微信 AI 调用开发者的服务提供质量分参考。现面向开发者提供「评测工具」，支持开发者在微信开发者工具中的评测插件中自行发起评测。
评测工具当前在内测阶段，已支持开发者自测，向微信团队提交提审评测暂未开放。
开发者全流程示意图：
- 开发者自测与微信团队评测的能力差异如下：
| 主要差异点 | 开发者自测（已支持，内测中） | 微信团队评测（后续开放小程序 AI 开发模式的代码提审后提供） |
|---|---|---|
| 评测目标 | 自主核查小程序 AI 开发模式代码，针对性优化缺陷问题 | 评测结果是直接影响开发者服务被微信 AI 调用效果的重要依据 |
| 环境配置 | 开发者自行配置模型，并承担模型资源成本 | 微信团队承担模型资源，无需开发者配置 |
| 参数配置 | - 可选择 SKILL - 可选择接口黑名单 | - 不支持自主选择 SKILL，默认全选 - 不支持配置接口黑名单 |
| 评测时机 | 任意时间想要评测时即可发起 | 建议在版本提审前完成，或在提审后尽快发起 |
| 评测版本 | 支持对最新上传的 10 个开发版评测（包含体验版） | 仅支持对最新的体验版进行评测 |
| 评测文件 | 需提交评测集并检测，Intent 数量需 ≥1 个且 ≤100 个，其他检测项不通过可继续评测 | 需提交评测集并检测，Intent 数量需 ≥50 个且 ≤100 个，任一检测不通过都不可继续评测 |
| 生成用例 | - 即时生成，无需排队 - 用例数可开发者自定义（不超过100个/次） - 支持删除用例，对用例正负反馈并调整顺序 | - 需要排队 - 用例数统一为 50 个/次 - 不支持删除用例，支持对用例正负反馈并调整顺序 |
| 评测耗时 | 根据用例数、模型质量等决定。参考时长：50 个用例耗时 2 小时左右（填写配置 10 分钟 + 生成用例 30 分钟 + 生成轨迹 1 小时 + 生成评测 30 分钟） | 一般需耗时 2 小时/次（生成用例 30 分钟 + 生成轨迹 1 小时 + 生成评测 30 分钟，具体时间根据平台正在进行的任务数量上下浮动） |
| 并发规则 | 一个小程序同一时间可多个评测任务并行，需要使用不同的 PC 端微信开发者工具 | 一个小程序同一时间仅支持一个评测任务 |
评测工具全流程示意图：
# 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 参数配置
| 步骤 | 说明 |
|---|---|
| 1）选择评测版本 | 自测将默认拉取最近上传的 10 个版本，仅支持对已上传的版本进行评测。你可选择需要评测的版本，评测结果仅对所选版本有效 |
| 2）选择评测指标 | 自测支持分指标评测 |
| 3）选择评测 SKILL | 后续评测文件检测将基于选择的 SKILL 进行 |
| 4）屏蔽接口 | 勾选的 SKILL 或接口将不参与评测，勾选 SKILL 会连带其下全部接口 |
| 5）添加评测文件 | 添加自定义评测集，你可下载模版，按照模版格式上传评测文件 |
| 6）进行评测文件检测 | 工具将对你所上传的评测文件在格式规范、Intent数量、原子接口覆盖度、用例意图复杂度、用例多样性进行可用性检测，检测通过后可继续后续流程 |
| 7）评测任务名称备注 | 可备注评测任务信息，如评测人昵称或版本号或其他需要备注的信息 |
# 关于「评测文件」的特别说明
评测文件是开发者基于自身开发的 SKILL 提交的自定义 Intent 集，Intent 集需包含简单 Query 和复杂 Query 两种类型。平台会基于评测文件生成评测用例，并在生成用例前对评测文件检测。提交给微信团队评测时，评测文件必须通过全部检测项才可继续。
⚠️ 注意事项：自测建议评测文件先以 20 个用例为起步，而后逐步增加，最多可 3 个开发者工具账号同时跑。后续提审评测预计的用例数量要求至少 50 个
1.评测文件检测要求
1）格式规范：校验上传文件的格式是否符合规范（可下载模版查看格式要求）
2）Intent 数量：Intent 数量不能超过 100 个
- 自测时，Intent 数量需 ≥ 1个
- 微信评测时，Intent 数量需 ≥ 50个
3）原子接口覆盖度：评测文件中的意图，覆盖所选评测 SKILL 的原子接口比例 ≥ 85%
- 举例：
- Query 1：帮我查下从上海到北京 6 月 20 号的机票
- Query 2：帮我查询一下 MU5928 航班
- 说明：以上两个 Query 覆盖了查询机票和查询航班 2 个接口；开发者一共支持了 10 个接口（下单、支付、查询机票、查询航班、查询舱位等），那么 原子接口覆盖度就是 2/10 = 20%
4）用例复杂度：「复杂用例」占全部 Intent 比例 ≥ 30%（「复杂用例」：模型判定每条用例的覆盖需求指标数 ≥ 4个）
- 举例：
- Query：帮我查下从上海到北京 6 月 20 号的机票。我要往返的，回来大概 6 月 25 号。另外看看这个航班有什么舱位可选，要含税的价格。
- 指标1：查机票
- 指标2：看看舱位可选
- 指标3：上海到北京
- 指标4：6 月 20 日出发6 月 25 日返回
- 指标5：往返
- 指标6：含税的价格
- Query：帮我查下从上海到北京 6 月 20 号的机票。我要往返的，回来大概 6 月 25 号。另外看看这个航班有什么舱位可选，要含税的价格。
5）用例多样性：要求 Intent 提到 80% 的实体出现次数占总实体数量的比例 < 5% （实体信息：如同一部电影名、同一个车次、同一种咖啡、同一个咖啡规格、同一个地名等等）
2.如何准备评测文件
（1）下载并参考评测文件官方示例
下载 评测文件官方示例
官方示例中包含了示范用例和对应的业务对象信息：
| 字段 | 是否必填 | 说明 |
|---|---|---|
| cases | 必填 | 评测用例列表，用于填写用户真实可能提出的问题或请求 |
| cases[].intent | 必填 | 单条用户请求，应使用自然语言描述用户想完成的目标 |
| entities | 可选 | 请求中涉及的商品、订单、地址、设备、会员等业务对象信息 |
| entities[].type | 填写 entities 时必填 | 使用一个英文词汇描述实体类别，例如 drink、order、address、device |
| entities[].content | 填写 entities 时必填 | 实体的若干个关键属性，例如名称、价格、规格、状态、地址等。 |
| entities[].source | 可选 | 实体信息来源，对应 mcp.json 中定义的工具名 |
评测用例编写规范
编写注意事项：
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）对评测文件检测
- 上传评测文件后，平台会对评测文件检测，检测结果会在下方展示。
- 自测时，评测文件检测不通过不影响继续评测；提交微信团队评测时，评测文件检测必须全部检测通过才可继续。
# 2.2.3 生成用例
1）支持查看、排序、删除、反馈用例
请你仔细检查每个用例，将需要登录、退登等操作的用例放到最后，避免因测试号登录等问题对轨迹生成造成影响。
# 2.2.4 生成轨迹
1）评测工具会先根据用例自动生成一轮轨迹，自动生成轨迹结束后，有两种情况需要开发者人工核验替换自动轨迹：
- 因评测环境或工具原因导致用例轨迹出现异常，平台会对该轨迹进行标记并提示开发者
- 开发者自行查看轨迹，认为自动化轨迹不符合预期
2）人工核验步骤：
# 2.2.5 执行评测 & 查看报告
可预览、下载评测报告，根据报告建议，进行优化后重新评测
# 2.3 微信团队评测（开放小程序 AI 开发模式的代码提审后提供）
该功能后续开放