给客服退款答复打分的一页记录

测试模型时，我们很容易凭感觉判断：这次回答挺顺，那次似乎更可靠。但文字流畅，不代表事实正确；回答很长，也不代表解决了问题。一份简单的评分标准，可以把“感觉不错”变成能够解释、记录和重复检查的判断。

先不用搭建复杂的评估系统。选一个具体任务，准备几条固定问题，再用同一把尺子给回答打分，就能开始。下面以客服退款答复为例。

§ 先写清楚什么算答对

假设商店的规则是：“商品签收后七天内，且未使用，可以申请退款；其他情况需要人工核实。”顾客问：“我三天前收到商品，已经用过一次，还能退款吗？”

在调用模型前，先写下参考要点：顾客满足时间条件，但不满足未使用条件；不能直接承诺退款；应说明需要人工核实，并给出联系客服的下一步。参考要点不必是一篇标准范文，它只需说明哪些内容必须出现，哪些结论不能出现。

这一步很重要。如果评分的人自己也没确定规则，后面的数字只会让模糊判断看起来更精确。

§ 用四项标准，各打零到两分

初次评估可以只保留四项，每项零到两分，总分八分。尽量让每项检查不同的问题，避免同一个错误被反复扣分。

• 规则理解：两分表示正确识别时间和使用状态两个条件；一分表示只识别其中一个；零分表示误读或忽略关键条件。
• 结论可靠：两分表示明确说明需要人工核实，不擅自承诺；一分表示结论含糊；零分表示直接保证退款，或断言绝不可能退款。
• 下一步完整：两分表示说明联系人工客服，并建议准备订单信息；一分表示只说联系客服；零分表示没有可执行的下一步。
• 表达清楚：两分表示简洁、易懂且礼貌；一分表示能理解但有冗余或歧义；零分表示明显混乱，或带有指责语气。

这些分数不是通用真理，而是这项任务的工作约定。换成代码生成或资料摘要时，应重新定义标准，而不是照搬客服场景。

§ 给一条实际回答试打分

模型回答：“您在七天内提出申请，可以退款。请提供订单号，我来为您处理。”

按照上面的标准，规则理解得一分，因为它只检查了时间；结论可靠得零分，因为它忽略已使用这一条件并承诺退款；下一步完整得零分，因为没有引导人工核实；表达清楚可以得两分。总分是三分，但更重要的记录是：遗漏使用状态，导致错误承诺。

不要只保留总分。两条回答即使同分，也可能分别存在事实错误和表达冗长，修复方法完全不同。对于错误退款承诺这类严重问题，可以单独设为“不通过”，不让其他项目的高分抵消它。

§ 固定题目，再比较修改结果

先准备十到二十条问题，覆盖常规情况、边界情况和信息不足的情况。例如：签收超过七天、尚未使用，以及顾客没有说明签收日期。缺少信息时，好的回答应先追问，而不是自行补全事实。

每次修改提示词，都用同一组问题复测，并尽量保持模型版本、生成参数和输入材料一致。记录题目、回答、各项得分和扣分理由。比较时可以隐藏回答来源，减少对某个版本的偏好。

通过 Vana API 测试时，可以用兼容 OpenAI 的调用方式访问统一端点 https://api.vanaapi.com，保留评估流程，只调整所需的模型配置。你可以创建一个 Vana API 账户，从这组小样本开始；按实际令牌用量计费、没有月费，也方便控制试验规模。

§ 把评分当作检查工具

先由人工试评几条。如果不同的人经常给出不同分数，先修改评分描述，补上正反例，再扩大测试。需要让模型辅助评分时，也应给它相同的规则，并抽查它的判断，尤其是涉及政策、金额和承诺的回答。

最后看两个结果：整体表现是否改善，严重错误是否减少。八分不代表任何场景都安全，少量样本也不能证明长期稳定。简单评分标准的价值，是让你知道回答错在哪里，以及下一次该改什么。