AI 客服准备上线了，谁来判断它答得对不对？

一家卖设备的小公司，把产品手册和售后说明放进了知识库。负责人试着问保修多久、配件怎么买，机器人都答得很顺。准备放到官网时，客服同事补了一句：旧型号和新型号的规定不同，促销赠品也不能按普通配件处理。

于是大家又问了几轮，开始碰到回答前后不一致的情况。技术人员说可以改提示词，业务同事却说不清改到什么程度才算能用。上线时间一再往后推。

这类项目存在一项容易被低估的工作：把业务人员的判断整理成可重复执行的验收题。对于熟悉某个行业、能读懂对话与基本日志的独立工作者，它可能成为一项服务。这里讨论的是待验证的接单方向，适合从小范围问答系统开始，不能把一份测试报告包装成对整个系统的安全保证。

验收题的第一个难点往往在客户内部。销售说旧型号可以换购，售后说活动早已结束，网站上却还保留着旧页面。外部测试者没有权力替公司选一个答案。

因此，接单前要确认业务负责人是谁。每条预期答案由谁认可，规则冲突找谁裁定，哪些问题必须转人工，都需要明确。没有这个人，你可能做出一张很整齐的题库，却永远无法判断结果。

付费者更可能是准备上线客服助手的经营者、负责项目交付的开发团队，或正在处理大量重复咨询的部门。他们支付的是一轮边界清楚的验收工作。如果项目还停留在演示阶段、没有确定的知识资料和使用场景，先做这项服务可能太早。

开发者自行测试、业务人员随手试问、采用平台现成的测试功能，都是合理替代。个人服务只有在材料整理、业务判断和复测记录上节省了客户的工作，才有单独收费的理由。

不要从搜集一百个“常见问题”开始。先选一个窄范围，例如售前型号选择，只处理资料查询与转人工，不涉及自动下单和修改订单。再从客户已有的、允许用于测试的咨询材料中整理不同问法。

一道题除了输入文字，还应记录客户问的是哪一款产品、适用哪个时间版本、依据哪份说明、允许回答哪些内容，以及什么情况下需要进一步询问。缺少型号时，正确行为可能是追问；资料没有提供承诺时，正确行为可能是说明无法确定。

例如，“这个能用多久”本身就不完整。用户可能在问保修期限，也可能在问电池续航。把它直接配上一个标准数字，会训练出看似爽快却容易误导的回答。测试要看系统能否识别信息不足，而不只看它是否输出了你预设的关键词。

还应留出一部分未用于调试的问题。开发者看过所有题目后专门修改提示词，分数上升可能只是更熟悉这份题库。保留少量未公开题，且由业务人员确认其含义，能帮助观察修改是否适用于新的问法。

[Anthropic 在 2026 年 1 月的评估文章](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)区分了运行记录与最终结果，也建议对具有随机性的系统进行多次尝试。这对客服很直接：系统说“已经转交人工”，与后台真的生成了待处理记录，是两件需要分别检查的事。

最初的服务可以只验收问答和转人工提示。若后续系统接入业务动作，就要把测试扩大到动作结果，并使用专门的测试环境与虚构订单。不能为了试验退款流程而操作真实客户的款项。

结果记录也不要只剩一个总分。一百道题里九十道回答正确，剩下十道如果涉及错误的价格承诺，业务负责人可能仍不接受上线。把影响较大的错误单列出来，比给整个机器人一个九十分更能支持决定。

对于事实明确的问题，可以检查关键内容是否出现、是否与依据矛盾；对于语气与解释是否易懂，则可以保留人工判断。不要给所有句子都打十分制分数，再把这些分数平均，制造一种并不存在的精确性。

一次回答错误，可能来自资料本身、检索过程，也可能来自生成阶段。测试者应记录输入、时间、模型与知识库版本、找到的材料片段和最终回答。能拿到哪些日志，要在报价时确认。

[Dify 的知识流水线介绍](https://dify.ai/rag)展示了独立的检索测试与中间变量检查能力。这提示了一个实用分工：先确认系统有没有找到相关资料，再判断它是否正确使用了资料。仅凭最终一句答错了，就要求更换模型，可能增加成本而没有解决原来的问题。

如果资料正确且已检索到，回答仍把两个型号混在一起，可以把该记录交给开发者复现。如果资料缺失，业务团队要补材料；如果旧规则没有标记时间，则应先整理版本。报告里写清证据与待确认部分，不必替客户把所有技术原因一次下定论。

自动评分可以帮忙筛选大量回答，但初期最好让业务人员一起审一小批。[OpenAI 的评估实践指南](https://developers.openai.com/api/docs/guides/evaluation-best-practices)强调针对实际任务设计测试，并用人工反馈校准自动评分。这里借鉴的是评估方法，无须要求客户迁移到某个海外模型或特定评测平台。

一份最小交付可以约定：一个明确业务范围、四十个经客户确认的场景、两轮执行、一份错误清单和一次复盘。题库用客户能继续编辑的表格保存，运行记录保持可追溯。修复提示词、整理全部知识库和重新开发流程分别报价。

四十个场景也不等于四十次调用。多轮追问、重复运行以及评分，都可能增加调用量。开始时把模型费用单列上限，超出前再确认；否则一份很低的固定报价可能被长文本输入消耗掉。

假设首单收费三千六百元，业务对齐三小时、整理题目五小时、执行与分析四小时、复盘两小时，共十四小时，另有两百元测试费用。扣除测试费用后剩三千四百元，约每小时二百四十三元，尚未扣其他经营成本。这组数字只是估算，实际最容易超时的是等待业务确认与反复解释分歧。

也因此，约定客户反馈期限很有必要。客户两周后才补齐产品规则，不能仍要求你在原来的交付日出报告。若每次会议都推翻上一版标准，应暂停复测，先让规则稳定下来。

欧美评估方法可以借鉴，具体题目不能照搬。中文咨询中的简称、语音转写错误、省略主语、上一句话指代哪款商品，都可能影响回答。一个只用完整书面句子的题库，未必代表实际聊天。

渠道也会改变上下文。官网问答、企业内部助手和某个电商平台里的客服，能读取的商品与订单信息不同。客户在哪个入口上线，就尽量在对应测试入口验收；平台没有提供的权限，不应在题库里假设已经存在。

面对预算有限的小公司，先把范围限定到一个产品线更容易讨论。客户也许只需要每次更新资料后做一次复测，无须购买长期顾问服务。国内已有实施团队和软件供应商会提供相似检查，独立工作者可以与他们合作补上业务验收，也必须说明自己的委托关系，不能自称独立认证机构。

资料尽量由客户先做脱敏，只接收完成测试需要的片段。处理工具和存放位置使用双方确认的环境，不因为某个海外工具方便就擅自上传原始聊天。费用按本地客户能够办理的人民币付款与票据流程约定，避免把工具订阅费、服务费和代付混成一笔不清楚的金额。

可以用两周找一个已有可运行版本的项目。第一周让业务负责人确认二十到四十个场景和判断依据；第二周跑完首轮，把最重要的几项问题交给开发者，再对修改后的版本复测。先用表格和现有测试入口，新增调用预算控制在双方确认的几百元范围内。

验收时看题目是否得到业务认可、错误是否能够复现、复测是否能说明同一个问题仍在或已经改变。一次小样本没有发现错误，不能推断上线后不会出错；报告应写明覆盖范围和未覆盖内容，帮助客户决定后续观察。

如果客户始终没有人能确认答案，或者只想拿一个高分做宣传，就不适合继续。如果每次检查都能推动一处明确修改，客户愿意按约付款，再考虑增加范围或按版本提供复测。

这项服务最后留下的，应当是客户下次改了资料、换了模型，还能拿出来重新跑的一组问题。能持续使用的验收依据，比一份写着“整体表现良好”的报告更容易解释自己的收费。