★ FEATURED ARTICLE 1. 为什么我要用 Claude 来做 eval 这件事先说清楚这个项目到底在干什么。标题里的“用 Claude 设计 eval再一轮轮把分数提上去”翻译成大白话就是我拿 Claude 当评测设计师和评测执行者让它帮我给一个 AI 应用或者一个 Agent、一个 Skill、一段提示词搭一套自动打分系统然后我根据打分结果反复改把分数从 60 分推到 85 分甚至更高。这套玩法在圈子里有个很形象的名字叫hillclimb爬山——你不是一次改到位而是每一步只比上一步好一点点靠迭代次数堆出最终效果。为什么这件事值得单独拿出来讲因为大部分人做 AI 应用卡住的地方根本不是“写不出提示词”而是根本不知道自己改完到底是变好了还是变坏了。你今天调了一版提示词感觉回答更顺了明天又调一版感觉更准了但这两版到底谁强强多少说不清。没有 eval你所有的“优化”都是凭感觉而凭感觉的优化在迭代十几次之后一定会失控——你会把 A 场景调好同时把 B 场景调崩而且自己完全不知道。这套方法适合谁三类人最该看一是正在做 Agent 或者 Skill 的开发者你手里有一堆 prompt 和工具调用逻辑需要量化效果二是做 AI 产品的人需要给团队一个“这版能不能上”的判断依据三是自己玩 Claude Code、写自动化脚本的独立开发者想让自己的小工具稳定下来。哪怕你只是写提示词的这套思路也能直接搬过去用。我自己的背景是做了几年后端和数据后来转去做 AI 应用落地踩过的最大坑就是“没有 eval 的迭代”。有一次我改一个信息抽取的 prompt改了七版每版都自我感觉良好结果上线之后发现准确率比第一版还低。那次之后我就下定决心任何要迭代的东西先有 eval 再谈优化。下面我把整套流程拆开讲包括怎么让 Claude 帮你设计 eval、怎么跑分、怎么一轮轮爬坡以及中间那些只有真跑过才知道的坑。2. 整体设计思路为什么是 Claude eval hillclimb 这个组合2.1 先想清楚 eval 到底在评什么很多人一上来就问“用什么框架跑 eval”这个问题问早了。你得先回答一个更根本的问题你要评的到底是什么能力是事实准确性是格式合规是工具调用的正确性还是多轮对话里的上下文保持不同的评测目标决定了你后面所有的设计。我一般会把评测目标拆成三层。第一层是硬性约束比如输出必须是合法 JSON、必须包含某个字段、长度不能超过多少——这类用代码就能判不需要模型。第二层是语义正确性比如抽取的实体对不对、回答有没有答到点上——这类需要模型或者人来判。第三层是体验质量比如语气是否自然、有没有 AI 味、结构是否清晰——这类最主观也最难评但恰恰是用户最能感知的。为什么强调这个分层因为如果你把三层混在一起用一个总分来评你会得到一个“什么都沾一点但什么都说不清”的分数改起来完全没方向。我的做法是分层打分、分层优化硬性约束必须 100% 通过语义正确性看准确率体验质量看人工抽检或者模型打分。这样每一轮改动你都知道自己动的是哪一层。2.2 为什么让 Claude 来设计 eval而不是自己写这里要解释一个关键选择。eval 这东西写起来其实不难难的是你想不全。你自己写测试用例一定会不自觉地只覆盖你想到的场景而漏掉那些边界情况。Claude 在这件事上的价值不是“比你聪明”而是“它没有你的思维定势”。我实测下来让 Claude 设计 eval 最大的收益是用例覆盖度。你给它一段任务描述让它生成 30 条测试用例它会自动帮你补上空输入怎么办、超长输入怎么办、输入里有歧义怎么办、输入格式不对怎么办、多语言混杂怎么办。这些用例你自己想可能要想一下午它几分钟就给你列出来了。而且它生成的用例往往带着“预期输出”和“判定标准”这正好是 eval 最需要的结构。但这里有个前提你不能让 Claude 凭空设计你得给它足够的上下文。我一般会喂给它四样东西任务的目标描述、几个真实的输入输出样例、已知的失败案例、以及我对“好”和“坏”的定义。喂得越具体它设计的 eval 越贴合实际。空手让它设计它给你的就是那种“教科书式”的通用评测看着很全实际用不上。2.3 hillclimb 的核心一次只动一个变量爬山算法的精髓在于每一步只做一个小改动然后立刻测分。这个原则听起来简单但执行起来特别反人性因为人天生想“一次改到位”。我见过太多人一轮改了五个地方分数涨了然后完全不知道是哪个改动起了作用下一轮又改五个地方分数跌了也不知道是哪个改动搞砸的。我的做法是每一轮只改一个东西。这一轮只改提示词里的角色设定下一轮只改输出格式的约束再下一轮只加一个 few-shot 例子。每改一次跑一遍完整 eval记录分数。这样你得到的是一条清晰的“改动-分数”对应关系哪些改动有效、哪些无效、哪些甚至有害一目了然。代价是什么代价是轮次多。别人改三轮可能就到目标了你可能要改十轮。但好处是你的优化过程是可复现、可解释的。当老板问你“为什么这版比上版好”你能拿出数据说“因为我把输出格式从自由文本改成了结构化 JSON格式合规率从 72% 提到了 98%”。这种确定性是拍脑袋优化永远给不了的。3. 核心细节解析eval 到底怎么搭、怎么跑3.1 让 Claude 生成第一版 eval 的完整提示词这是整个流程的起点我把实际用的提示词结构拆给你看。核心是角色 任务 输入样例 判定维度 输出格式这五块。你是一个资深的 AI 评测工程师。我要给下面这个任务设计一套自动化评测集。 【任务描述】 这里写清楚你的 AI 应用要做什么越具体越好 【输入输出样例】 输入xxx 输出xxx 给 3-5 个真实样例 【已知的失败案例】 把你踩过的坑写进去比如“模型经常把日期格式写错” 【评测维度】 1. 格式合规输出必须是合法 JSON包含字段 a、b、c 2. 事实准确抽取的实体必须和原文一致 3. 完整性不能遗漏原文中的关键信息 【要求】 - 生成 30 条测试用例覆盖正常场景、边界场景、异常输入 - 每条用例包含id、输入、预期输出、判定标准、难度等级 - 判定标准要写成可执行的规则不要写“回答得好”这种模糊描述 - 输出为 JSON 数组这个提示词里最关键的是判定标准要可执行。什么叫可执行就是“输出必须包含字段 a 且 a 的值等于输入中的日期”这种而不是“输出要准确”。前者机器能判后者只能人判。你让 Claude 写判定标准的时候一定要盯着它别偷懒写模糊描述发现模糊的就让它重写。3.2 评测执行代码判 模型判的混合架构拿到 eval 集之后怎么跑分我的架构是两层判定。第一层用代码判处理所有能规则化的东西JSON 是否合法、字段是否存在、数值是否在范围内、字符串是否匹配。这一层快、便宜、100% 确定。第二层用模型判处理语义层面的东西回答是否切题、抽取是否准确、语气是否合适。模型判这里有个坑你不能让判分的模型和被判的模型是同一个也不能让判分模型知道哪个是“标准答案”之外的偏好。我一般用 Claude 做判分给它一个明确的评分 rubric让它输出 0-5 分加理由。rubric 要写得非常具体比如“5 分完全正确且格式完美4 分内容正确但格式有小瑕疵3 分内容基本正确但有遗漏2 分部分正确1 分基本错误0 分完全错误或拒答”。为什么要有理由因为理由是你下一轮优化的线索。分数只告诉你“变差了”理由才告诉你“哪里变差了”。我每次跑完 eval 都会把低分用例的理由拉出来看一遍经常能发现一些我自己完全没想到的失败模式。3.3 分数怎么算才有意义这里要讲一个很多人忽略的点总分怎么加权。如果你把格式分和语义分简单平均会出现一种情况——格式全对但内容全错也能拿 50 分看着还行实际完全不能用。我的做法是硬性约束一票否决格式不合规直接判 0 分不进入语义评分。这样分数才有区分度。具体权重我一般这么设格式合规占 30%语义准确占 50%体验质量占 20%。但这个比例不是固定的要看你的场景。如果是给下游系统消费的输出格式权重可以提到 50%如果是给人看的回答体验权重可以提到 30%。关键是你要清楚每个维度的权重为什么是这个数而不是随便拍一个。还有一个细节分数要能对比。我每次跑 eval 都会把结果存成一个带时间戳的 JSON包含每条用例的得分、总分、以及当轮的改动说明。这样跑十几轮之后我能画出一条分数曲线清楚地看到哪一轮涨得最多、哪一轮甚至跌了。这条曲线就是你优化过程的最好证明。4. 实操过程从 60 分爬到 85 分的完整记录4.1 第一轮先跑基线别急着改我拿到任何一个任务第一件事永远是跑基线。不改任何东西先跑一遍 eval看看现在多少分。这一步的价值在于给你一个锚点。没有基线你后面所有的“提升”都是没有参照的。我最近做的一个任务是信息抽取从一段非结构化的文本里抽出人名、公司、职位、时间。第一版 prompt 就是很朴素的一句“请从下面文本中抽取人名、公司、职位和时间”。跑完 eval总分 58 分。拆开看格式合规率 65%经常输出成自然语言而不是 JSON语义准确率 71%体验分 60%。失败用例里最典型的是模型把“张三于 2023 年加入字节跳动担任产品经理”里的“2023 年”抽成了“2023”丢了“年”还有把公司名抽成了“字节跳动担任产品经理”。这一轮我什么都没改只是把失败模式记下来了。记失败模式比记分数更重要因为分数是结果失败模式是原因。4.2 第二轮只改输出格式分数涨到 68第二轮我只做一件事把输出格式从“自然语言”改成“严格 JSON”并在 prompt 里给出 JSON schema。改动很小就是加了一段输出必须是如下 JSON 格式不要有任何额外文字 { person: 人名, company: 公司名, position: 职位, time: 时间保留完整表述如 2023 年 }跑完 eval总分 68。格式合规率从 65% 直接跳到 94%语义准确率基本没动72%体验分略涨。这一轮验证了一件事格式问题用格式约束解决不要指望模型自己悟。你越明确地告诉它要什么格式它越不会乱来。但这一轮也暴露了新问题格式对了之后语义错误变得更显眼了。之前格式错的时候语义错被掩盖了现在格式全对那些抽错的内容就赤裸裸地摆在那里。这其实是好事说明你的优化方向更清晰了。4.3 第三轮加 few-shot 例子分数涨到 76第三轮我加了三个 few-shot 例子专门针对上一轮暴露的语义错误。比如针对“时间要保留完整表述”我给了一个例子输入李四 2021 年 3 月入职腾讯 输出{person: 李四, company: 腾讯, position: , time: 2021 年 3 月}注意这里 position 是空字符串因为原文没提职位。这个例子同时教了模型两件事时间要完整、缺失字段要留空而不是瞎编。跑完 eval语义准确率从 72% 提到 84%总分 76。few-shot 的关键是例子要针对失败模式而不是随便找几个正确例子。你放三个模型本来就会做的例子等于没放。你要放的是模型经常做错的那类例子而且要在例子里体现“正确做法”和“错误做法的区别”。我一般会在例子里加一句注释说明为什么这么抽。4.4 第四轮到第七轮微调与边界处理后面几轮都是小改动。第四轮加了“如果原文没有对应信息字段留空不要推测”的约束解决模型瞎编的问题分数到 79。第五轮把 prompt 里的任务描述从一句话扩展成一段带背景的说明让模型理解抽取的用途分数到 81。第六轮针对多语言混杂的输入加了处理规则分数到 83。第七轮调整了判分 rubric 里对“部分正确”的定义让评分更严格分数回落到 82——但这一轮我认为是必要的因为之前的评分太宽松虚高。这里要讲一个心态问题分数不是每轮都必须涨。有时候你为了让评分更严格分数会跌但这是好事因为你的 eval 更准了。我见过有人为了让分数好看故意放宽评分标准那是自欺欺人。eval 的目的是反映真实水平不是给你发奖状。4.5 最终结果与关键改动复盘七轮下来总分从 58 到 82严格评分下如果按宽松评分算是 87。格式合规率 98%语义准确率 89%体验分 78。最关键的三次改动是格式约束10、针对性 few-shot8、缺失字段处理规则3。其余几轮都是小修小补。我把这个过程的经验总结成一句话先解决确定性问题格式再解决语义问题内容最后打磨体验问题语气。顺序不能反。你格式都没搞定就去调语气等于房子没盖好先刷墙。5. 常见问题与排查技巧实录5.1 分数忽高忽低怎么办这是最常见的问题。同一版 prompt跑两次 eval分数差了 5 分。原因通常是模型输出的随机性。解决办法有两个一是把 temperature 调到 0让输出尽量确定二是每条用例跑 3 次取平均用平均值来对比。我一般用第二种因为即使 temperature 为 0不同批次的输出也可能有细微差异多次取平均更稳。如果调了 temperature 还是忽高忽低那可能是你的 eval 集里有歧义用例。就是那种“怎么答都算对也怎么答都算错”的用例。这种用例要挑出来重写把判定标准写死。eval 集的质量直接决定分数的可信度含糊的用例会让你的优化方向完全跑偏。5.2 模型判分和人工判分对不上模型判分和人工判分有偏差是正常的但如果偏差超过 15%说明你的 rubric 有问题。我一般的做法是先人工标 20 条然后让模型用 rubric 标同样的 20 条对比差异。差异大的用例逐条看模型给的理由找出 rubric 里模糊的地方改 rubric再测。一般迭代两三轮模型判分和人工判分的一致性就能到 90% 以上。这里有个技巧rubric 里要给出反例。比如“5 分要求输出完全正确注意如果输出包含原文没有的信息即使其他都对也只能给 3 分”。反例能大幅减少模型的误判。5.3 优化到一定程度就上不去了这是 hillclimb 的典型瓶颈。分数卡在 80 左右怎么改都不动。这时候通常不是 prompt 的问题而是任务本身的天花板。比如你的任务里有 10% 的用例是模型能力根本达不到的需要外部知识、需要多步推理那你的上限就是 90 分。这时候继续调 prompt 是浪费时间你应该做的是要么换更强的模型要么给模型加工具比如检索要么承认这部分做不到把 eval 集里的不可能用例标出来单独看。我踩过这个坑卡在 82 分卡了两天后来发现 eval 集里有 5 条用例需要模型知道一个很冷门的事实模型不知道是正常的。把这 5 条标成“已知不可达”之后剩下的用例我实际已经做到 91 分了。5.4 常见问题速查表问题现象可能原因排查方向解决动作分数波动大输出随机性 / 用例有歧义跑两次对比看哪些用例分差大降 temperature重写歧义用例格式合规率低格式约束不明确检查 prompt 里有没有给 schema加 JSON schema 和格式示例语义准确率低缺少针对性示例看失败用例的共同模式加针对失败模式的 few-shot模型判分不准rubric 模糊人工标 20 条对比改 rubric加反例分数卡住不动任务天花板看失败用例是否超出模型能力换模型 / 加工具 / 标记不可达改了反而变差一次改了多个变量回滚一次只改一个单变量迭代5.5 几个只有真跑过才知道的坑第一个坑eval 集不要一次写太多。我一开始让 Claude 生成了 100 条用例结果跑一轮要十几分钟迭代速度极慢。后来改成 30 条核心用例跑一轮两分钟迭代速度上来了效果反而更好。eval 集的关键是覆盖关键失败模式不是数量多。第二个坑判分模型的 prompt 也要迭代。很多人只迭代被测模型的 prompt忘了判分模型的 prompt 也需要调。判分不准你的优化方向就是错的。我一般会把判分模型的 prompt 也当成一个需要优化的对象定期检查它的判分理由是否合理。第三个坑记录每一轮的改动。这个听起来很基础但我见过太多人改着改着就忘了自己改过什么。我的做法是每轮改动都写在一个 changelog 里格式是“轮次 改动内容 分数变化 结论”。十几轮下来这个 changelog 就是你最好的经验总结。6. 把这套方法扩展到其他场景这套“Claude 设计 eval hillclimb 迭代”的方法不只适用于信息抽取。我后来把它用在了好几个场景上效果都不错。一个是提示词优化。你手里有一段提示词想让它的输出更稳定。做法是让 Claude 针对这段提示词生成 30 条测试输入跑一遍看输出定义评分标准然后一轮轮改提示词。我有个提示词从“能用”到“稳定”就是这么爬了六轮出来的。另一个是Agent 的工具调用。Agent 最容易出问题的地方是“该调工具的时候不调不该调的时候乱调”。你可以让 Claude 设计一批“什么情况下应该调什么工具”的测试用例然后跑 eval看工具调用的准确率。这个比测文本输出更复杂因为要 mock 工具返回但思路是一样的。还有一个是Skill 的质量评估。现在很多人写 Skill但写完不知道好不好。你可以给 Skill 定义几个评测维度触发准确性、执行正确性、输出格式让 Claude 生成测试用例跑分迭代。这套流程跑下来你的 Skill 质量会有肉眼可见的提升。最后分享一个我自己的体会eval 不是一次性的工作是持续的工作。你的应用在变用户在变失败模式也在变。我现在的习惯是每个月重新跑一遍 eval看看有没有新的失败模式出现。有时候你会发现三个月前 90 分的用例现在只有 70 分了因为模型更新了或者场景变了。这时候你就知道该重新爬坡了。这套方法的价值不在于让你一次做到完美而在于让你始终知道自己在什么位置。
阅读完成 · 觉得有帮助？
