服务台试点一周后，团队准备更换模型，并改进投屏指引的切分方式。演示对话看起来更自然了，小林的问题却可能出现新错误：原来会先追问连接方式，现在直接推荐不适用步骤；原来会在建单前确认，现在把“帮我处理”误当成同意。没有固定的测试集，每一次“优化”都可能悄悄破坏已经做对的事。本篇把小林的故事变成可重复的评测流程。测试集不仅检查答复文字，还检查动作顺序、资料出处、权限边界、工具调用、失败恢复和成本。评测不能保证所有真实请求都正确，但可以让版本变化造成的回退尽早暴露，避免用几段挑选过的漂亮演示代替业务验收。文章目录从真实求助提炼测试样本回归评测的流程图指标要对应真实业务，而不是只看总分一个可运行的动作回归示例让评测结果指导修复总结从真实求助提炼测试样本一条好样本要写出输入、初始状态、可用资料、预期动作和判定证据。只写“用户问投屏问题，期望回答准确”太笼统；测试失败时无法知道是追问、检索还是表述出了问题。小林的原始求助可以拆成多个阶段，每个阶段分别验证。样本初始状态期望结果不允许发生的事未说明连接方式只有 A301 与无画面追问连接方式猜测设备原因或直接建单线缆连接、指引有效事实齐全，未检索查询正确指引并给出出处引用旧版资料指引仍无法解决已给建议，员工反馈失败整理建单草稿并等待确认未确认写入员工重复确认写入结果已存在返回同一工单号新建第二张单问“刚才的工单”任务卡有真实工单号查询本人可见状态编造进度或泄露内部备注资料冲突/