用固定测试集检验 AI 工单分流

客服分流提示词在第一张工单上表现出色，可能只是因为问题足够清楚。遇到缺账号、混合诉求、声称紧急却没说明影响的真实输入，模型才会暴露出分错团队、补造事实和追问无效的问题。

作者给出的办法，是把提示词改动变成一组可复跑的测试：固定工单、分别评分、提前约定重试次数，再明确哪些错误必须阻止上线。它的价值不在提示词技巧，而在于让团队能回答：这次修改到底修好了什么，又弄坏了什么。

先固定六张工单，再讨论提示词怎么改

作者建议，先写六张合成工单，和提示词放在一起。它们分别覆盖重复请求、字段缺失、账单与技术问题混在同一条消息里、含糊的紧急声明、明确的故障报告，以及一张信息清楚的对照工单。测试样本里不要放真实客户数据。

这组输入的作用，是避免每次修改都换一道题，最后只能凭印象判断效果。

每张工单可以用一个 JSON 对象描述，包含五个字段：id、ticket、expected_route、required_facts 和 forbidden_claims。后两个数组要明确写出来，分别约束必须保留的事实和不能擅自作出的断言。

例如，客户说自己看到了两笔扣款，但找不到收据。回复需要保留「客户报告有两笔扣款」这一事实，却不能据此确认发生了重复交易，更不能承诺退款。预期去向可以是 billing，下一步则是通过获准渠道索取交易参考信息。

测试要约束事实和行为，不必规定回复逐字一致。

两种措辞不同的回复，都可能满足要求。把标准答案写成一整段固定文案，容易把语言差异误判成业务错误。

分对团队，不代表回答合格

原文把评估拆成三个维度：路由是否正确、事实是否准确、缺少必要信息时是否提出了有用的问题。

这三个维度不能揉成一个分数。工单被正确转给账单团队，但回复编造了发票日期，应该记录为路由通过、事实失败。逐条检查也比只看平均分重要，因为一次严重错误可能被其他简单样本的高分盖住。

评估器可以从小做起。模型从固定集合中返回路由时，就机械比较它与 expected_route 是否一致，同时把解析失败和路由错误分开记录。对象格式坏了，与格式正确却发错团队，需要不同的修复方式。

自由文本先交给人工审查。关键词匹配既可能漏掉换一种表达的退款承诺，也可能误伤「不能承诺退款」这样的句子。审查表应当一行对应一次运行，并记录触发失败的原句或缺失事实，让结论有据可查。

重试次数和上线红线，都要提前定

先运行基线，保存提示词全文、测试样本版本、模型标识和输出。随后只改一条指令，例如要求返回结构化字段，再用相同输入运行候选版本。

遇到含糊的失败，可以重复运行，确认问题是否稳定出现。但重复规则必须提前约定：每个候选版本跑多少次，每次输出如何编号，都应在看结果前确定。

一直重试到出现正确答案，会把不稳定伪装成改进。

如果基线本来就会对同一张工单给出不同去向，也要如实记录。候选提示词即使改善了清楚的样本，只要让故障工单的路由更不稳定，就需要继续迭代。

作者建议把编造退款、猜测账号 ID、对故障工单自信地分错团队列为上线阻断项。失败工单要保留为回归样本，再加一个相近变体，检查修复是否只能应付原题。

最后，测试结果旁边还要保存审核人和接受理由。例如，团队可以允许六个样本中出现一个非关键风格问题，同时要求所有故障工单都正确分流。这是原文举出的决策示例，并非经过验证的通用阈值。

我的判断

这套方法说得对的地方，是把「看起来回复不错」拆成了可以复查的业务要求。相比只保存几张成功截图，它更容易解释一次提示词修改为什么值得保留，也能让后续维护者接着测。

但原文没有提供实测成绩、模型对比或上线后的错误率变化，因此它是一套流程建议，不能据此声称能降低多少错误。六张工单适合作为起点，也不足以证明系统覆盖了真实业务分布。

它还有一个前提：团队已经知道工单应该去哪、哪些事实可以使用、缺什么信息需要追问。如果这些规则本身存在争议，应先把业务标准写清楚，否则评估只是把分歧搬进表格。

机械比较适合固定路由，人工复核适合初期的事实和承诺检查。原文没有证明这套人工方式能撑住大规模评测，也没有给出自动评审的替代验证结果。

能拿来做什么

• 如果你在维护客服工单分类功能，先按原文建立六张合成工单，给每张补齐预期路由、必需事实和禁止断言，再修改提示词。
• 如果用 Node 编排模型调用，可以先自动比较路由并单独记录解析失败，同时保存每次运行的编号和原始输出，供人工检查文本。
• 每次比较提示词版本时，固定输入并只改一条指令，提前写下运行次数，保留所有结果，避免只挑成功输出。
• 收到新类型的失败反馈后，先合成一个能复现问题的样本，再修提示词，并增加相近变体作为回归检查。