审查并评分 Batch Test 结果
将已完成的 Batch Test 转化为可执行的审查。评分用于概括质量，而备注则保留回答为何通过或失败以及需要更改的内容。 Agent 结合了说明、面向客户的界面设置、Knowledge、目录数据和可选工具。可靠的设置会在部署前通过真实的客户问题进行测试。测试应涵盖预期答案、缺失信息、产品场景、升级处理，以及团队已启用的任何可选交互。 开始之前 访问权限： 打开一个已完成的 Batch Test 运行，并具有审查 Agent 测试...
将已完成的 Batch Test 转化为可执行的审查。评分用于概括质量，而备注则保留回答为何通过或失败以及需要更改的内容。
Agent 结合了说明、面向客户的界面设置、Knowledge、目录数据和可选工具。可靠的设置会在部署前通过真实的客户问题进行测试。测试应涵盖预期答案、缺失信息、产品场景、升级处理，以及团队已启用的任何可选交互。
开始之前
访问权限：打开一个已完成的 Batch Test 运行，并具有审查 Agent 测试的权限。
- 使用结果稳定的已完成运行。
- 确保每个案例的预期结果可供查看。
- 就团队如何区分“良好”、“可接受”和“差”达成一致。
在下文所述的最小责任范围内操作，并在准备更改时保持当前面向客户的状态可用。在点击任何最终操作之前，请确认 Humind 中显示的当前公司、Agent、商店、语言和市场。缺少某个控件可能表示只有只读权限，或表示此公司尚未配置该能力。在这种情况下，请记录预期执行的任务，并请管理员审查确切的权限或依赖项。不要通过共享账户、将数据复制到其他区域，或承诺工作区未提供的能力来绕过这一边界。
分步工作流程
审查回答和证据
阅读完整回答，而不只是开头一句。检查它是否回答了问题、遵守了边界，并依赖适当的 Knowledge 或产品信息。
- 将回答与预期结果进行比较。
- 当结果出人意料时，打开相关源材料。
应用一致的评分
对于可直接使用的回答使用“良好”，对于有非阻断问题但仍然有用的回答使用“可接受”，对于错误、无依据、不安全或实质性不完整的回答使用“差”。
- 评估对客户的影响，而不仅仅是写作风格。
- 在相似案例中使用相同标准。
添加诊断备注
记录具体原因和可能的负责层，例如 Knowledge、目录、指导内容、工具配置或不受支持的范围。备注应使下一步操作一目了然。
- 仅引用最少且相关的短语。
- 注明修正负责人或后续测试。
汇总并导出
按根本原因对差和可接受的案例进行分组，然后在需要在审查界面之外共享时导出报告。在进行有针对性的修正后重新测试。
- 优先处理重复出现且影响客户的失败。
- 保留原始运行作为更改前证据。
重要限制和操作说明
- 较高的总体评分可能会掩盖一次严重失败。
- 评分反映的是审查者商定的标准，并且需要校准。
- 在运行后更改来源不会改变已记录的回答。
- 导出的报告是证据，不是实时配置。
验证结果
- 每个关键案例都有评分和诊断备注。
- 差的案例按负责层分组。
- 导出内容包含的是已审查的运行，而不是其他数据集。
- 已为修正后的阻断性问题规划后续运行。
简要记录你测试了什么、使用了哪种客户场景，以及发生了哪些变化。这会使后续故障排查更加准确，并帮助其他团队成员在不依赖记忆的情况下复现结果。
故障排查
审查者对评分存在分歧
回到预期的客户结果并对影响进行分类。如果预期本身不明确，请先修复测试定义，再在发布决策中使用其评分。
答案看起来合理，但没有依据
明确评定证据问题，并调查来源层。不要仅因为措辞润色得很好，就接受一个看起来很有把握的回答。