上篇文章发出去之后，评论区有粉丝让我分享我的搭建评测集的思路和坑点，应粉丝要求。

正好，这两个月我在美的干的活里，最重的就是这件事。从零搭了一个业务Agent的评测集，中间返工三次。今天不聊岗位感受，专门把这摊活摊开讲：思路是什么，坑在哪，多少钱花在了不该花的地方。

先交代背景。我34岁，之前在银行做了六年Java后端，风控方向，去年底被裁，三个月转型，今年九月入职美的做Agent开发。评测集这个东西，我在银行做过最接近的版本是风控的回归样本集——模型可以换，样本和标签不能丢。所以上手不算完全抓瞎，但真做起来，还是交了不少学费。

先说一个动手前就想错的事。

第一版评测集，我是照着教程搭的：找模型生成了两百条测试问题，跑一遍，算个准确率，百分之九十多，汇报了。

leader看完只问了一句：这准确率是站在谁的角度算的？

我当场卡住。因为那两百条问题，是模型自己生成的——模型给自己出题，再答给自己看。看着像模像样，其实一行真实数据都没碰。

后来我才想明白这里面的分层：教程里的评测集是让你学概念用的，生产里的评测集是让你判断"这次改动能不能上线"用的。前者错了无所谓，后者错了，是把坏版本放上去，或者把好版本摁下来。

这两个月趟出来的第一条原则：评测集的第一百条题，永远比第一条题值钱。题不在多，在真实。真实的问题来自客服日志、工单记录、用户输入框的原始文本——那些带错别字、带上下文缺失、带着"问了一半就不问了"的残缺输入。我自己生成的那两百条，一条没留。

后来leader教了我一个笨办法，但管用：把客服日志按周抽一批，人工挑出"Agent答错过"或者"用户明显不满意"的case，一条条改写成测试题。两周攒下来一百一十条，我管它叫真实题库。这批题跑出来的分数，第一次让业务方点头——因为他们在里面认出了自己见过的真实对话。

第二个思路，也是我返工最狠的一次：评测集要先搭骨架，再填题目。

第一版我是想到什么写什么，东一条西一条，两百条看着挺多，做完一次模型升级就露馅了——模型整体变好了，评测分数却跌了，因为题目分布跟真实流量对不上。

后来leader让我先别加题，先把场景切干净。我们花了一个下午，把线上四万多条会话按意图归类，切成了五类场景：常规问答、多轮追问、敏感问题、指令执行、还有一类最麻烦的——用户表达和系统理解对不上的那种。

每一类定了两个数：占线上流量的比例，和"答错的代价"。

这个分类后来救了我好几命。模型每次升级，我看总分之外必须看分项——有一版总分涨了两个点，但敏感问题那档掉得厉害，这版就不能上。总分是给人看的，分项是拿来做决定的。

对应到银行那边：风控的策略上线，从来不看整体拦截率，看的是各风险档位分别的误杀率。同一个道理，换个行业而已。

第三条，是判分标准这一步。业务方一开始给我的标准是四个字："答得准确。"

准确是什么？问一个字段值，答对了算准确。问一个流程怎么办，回答覆盖了三个关键步骤算准确吗？还是措辞也必须跟标准答案一致？

我们在这个问题上卡了两天，最后定下来的做法是分三种题型各定各的判法：事实型问题，精确匹配关键词，机器直接判；流程型问题，把标准答案拆成几个必须覆盖的要点，覆盖到就算过；还有开放型问题，机器先粗筛，分低的直接不过，分高的抽出来人工复核。

这一步做完我才理解，为什么leader说"评测集是攒出来的资产"。判分标准不是技术问题，是业务共识——什么叫对，业务方说了算，评测集只是把这个共识固化成了机器能执行的东西。共识吵清楚一次，往后每一次模型迭代都在吃它的红利。

再说说坑。这些坑每一条都真花过我的时间。

坑一：评测集跟业务版本脱钩。业务方改了话术口径，评测集没跟着改，跑出来的分数全是错的。我们踩过一次实打实的：业务侧把一类问题的标准答案改了，评测集不知道，那周起评测分数连着三天往下掉，我还以为模型出了问题，排查了半天才发现是"标准答案"先变了。后来我们把评测集进了版本管理，业务侧任何涉及口径的变更，同步评审评测集改哪几条。评测集不是一次性的工程，它是活文档。

坑二：只测对错，不测成本和延迟。有一版模型评测分数更高，上了灰度，结果单次调用成本涨了四成，平均响应慢了两秒。业务方根本不关心你的准确率涨了三个点，他关心的是成本表和用户投诉。现在我们每次评测跑三个维度：准确、成本、延迟，一个不过就不上。

坑三：评测集太大，迭代跟不上。有人觉得题越多越好，我们一度堆到八百条，每次评测要四十多分钟，改一版prompt要等大半天才能看到结果。等评测的时间比改prompt的时间还长，迭代节奏就废了。后来拆了两层：核心回归集一百条，十分钟跑完，改一次prompt就能验一遍；全量集留着，发布前跑。就像单元测试和全量回归的关系，写过程序的都懂。

坑四，也是我最意外的一个坑：评测集本身也需要评测。我们抽查过一批机器判"通过"的案例，发现大概百分之七判错了——判分prompt对某类表述存在系统性偏严，把正确的回答打了低分。这批题目在评测集里拖了半个月后腿，模型一直被"冤枉"。从那以后每两周抽一轮人工复核，机器判分自己也要接受质检。

这两个月干下来，我对评测集这件事的最终理解是三句话。

第一句，评测集不是测试工具，是团队的沟通语言。加不加兜底、换不换模型、这版能不能上，以前靠吵，现在拿分项数据说话。

第二句，它攒的不是题目，是你业务里所有踩过的坑。每出现一次线上事故，修完之后把对应的case写进评测集——这样同一个坑就不会掉进去第二次。三个月前这个评测集是零，现在它比很多我写的代码都值钱，因为代码这次不用，下次还能写；这些case是花钱买来的。

第三句，以后面试Agent岗，如果面试官问"你的效果怎么保障"，别答"多调调prompt"。你能把"评测集怎么搭、判分标准怎么定、线上case怎么回流"这条线讲清楚，比你会十个框架都有说服力。

照例泼点冷水。

评测集这件事听着枯燥，也正是它的门槛所在——它不性感，没有"调一调效果就变好"的爽感，前期搭骨架的一个月基本看不到产出。如果你的团队现在连线上日志都没有打通，别急着搭评测集，先把日志和trace补齐，那是地基。

反过来，如果你已经是后端，手头维护过任何一种"版本迭代要验证"的系统——单测、回归、灰度——那评测集这件事对你来说几乎是无缝平移。这也是我转型之后感受最深的一点：这个岗位上真正值钱的活，大半都在吃后端的老本。

我把这两个月搭评测集的过程整理成了一份资料，里面有五类场景的切分方法、三种题型的判分标准模板、还有线上case回流的完整流程。如果你也是Java后端，我最近也整理了一套《程序员转Agent开发完整学习路线》，里面包括大模型应用基础、RAG知识库搭建、Agent架构设计、企业级项目案例、面试重点以及程序员如何转型AI应用开发的方法，需要的朋友，评论区留「11」，我把这套 Agent 学习路线和项目资料发给你，帮助你找到更清晰的转型方向。