转做 agent 评测，最该先练的是把模糊需求变成可判断的标准：这个 agent 做到什么算对、哪些失败可以接受、错在哪一层。这类能力对应的是判断、评估、诊断这些“动词”，而不是记住某个框架或名词，名词层面的东西会越来越不值钱，真正值钱的是任务怎么组织⁠1。一个可试的做法是：拿一个你熟悉的 agent 任务，先自己写下“我认为它应该做到什么、哪里可能出错”，再去看实际结果对照，卡住的地方就是还没练到的地方⁠2。这样练的是撤掉帮助后还能不能判断，而不只是这一次跑通了⁠3。

普通 QA 和标注通常面对的是已经确定好的标准和标签，执行得准就是合格；评测要回答的是标准本身对不对、这个取舍值不值得。有访谈观点把评测称为最重要的环节，并指出一旦评测被污染或过拟合，会得到“我们在进步”的幻觉，实际只是学会了钻空子⁠4。另一处讨论也强调，质量最难判断，所以要用自己的业务任务持续建设测试集，先拿最好的方案看清上限，再决定怎么省钱⁠5。差别就在这里：标注是给数据打标签，评测是给方案定方向。

一个评测项目如果只是照着现成流程跑一遍、结果由工具或教程替你判断，那多半是在走流程，因为它替你完成了最关键的建模、拆解、验收和诊断⁠6。检验办法是换条件：换一批数据、加一个约束、换一个用户，看关键判断还在不在⁠2。落到评测上，可以看这个项目有没有留下你自己定义的验收标准、有没有分层抽样、有没有区分结构问题和成稿质量问题；如果只有“任务成功退出”这一条，就很难说在练判断⁠7。走流程不是没价值，但它练的是执行，不是评测岗真正稀缺的那部分。

单一通过率把不同性质的失败压成一个数：格式错了、内容漏了、语言不通顺，都会算作“没过”，于是你无法判断该改流程还是改标准。更可用的做法是分层抽样，同时看源材料、中间产物和最终成稿，并把结构问题和成稿质量问题分开记录。这样一次失败能定位到具体环节，而不是只能重跑一遍。这套分层验收在批处理翻译里被明确提出，但它针对的是“结果由多步生成”的通用情形，任务只有一步时不必照搬⁠1。

可用的标准是能逐条回答的问题：是否满足某个条件、是否避免了某类错误、是否覆盖了关键边界情况、是否符合预期格式与风格。写成这样，AI 才能在输出前先自检，形成一道质量闸门；人也能据此判断失败属于哪一类，而不是“再换个 prompt 试试”。这套做法针对的是需要稳定交付的任务，如果只是探索性尝试，标准可以更松⁠2。

验收标准负责判断“行不行”，诊断负责回答“为什么不行”，两者配合才有用。常见的几类根因性质不同：上下文缺失导致编造、上下文塞满导致信息丢失、指令歧义导致方向偏、任务本身超出模型当前稳定能力。它们的修法不一样，补信息、压缩拆分、改写目标、换模型或降低复杂度，各治一种。如果验收只给一个通过率，你就只能靠运气试；分层记录失败类型，才能把每次失败变成对流程的修正⁠2。

验收标准模糊时，失败往往表现为“感觉不太对”，说不清哪里不对，只能换 prompt 再试。把标准写成可判断的条件——是否满足某个要求、是否避免了某类错误、是否覆盖关键边界——再跑一遍，结果会分岔：如果模型在标准明确后仍反复在同一类输入上出错，更可能是任务超出当前模型的稳定能力；如果写标准的过程中发现自己根本说不清“什么算好”，那问题在标准，不在模型。诊断失效原因时也要区分几类本质不同的问题：上下文缺失、上下文过载、指令歧义、模型能力边界，它们的修法不一样，用一套动作去套所有失败只能靠运气⁠1。

AI 给的东西常常结构完整、逻辑通顺、格式漂亮，每一项看起来都没问题，但你就是觉得不对。如果说不清哪里不对，别人会当成主观偏好，AI 也会继续追问你想改哪里，于是你不断补指令、加标准、写更复杂的 prompt，却发现有些东西不是靠规则能说清的。这种“看一眼就知道对或不对”的能力是 taste，它本身可以提高，但它不是靠堆验收条款堆出来的。所以标准模糊有时不是懒，而是你还没形成对这类产出的判断；这时先补判断，比先补规则更有效⁠2。

判断“模型能力不够”之前，先问不用它时最合理的做法是什么。发布者展示的指标、演示里较短的输入让模型处在更有利的位置，都不等于它在你的任务上够用。真正该看的是：它改善的指标是不是你当前的瓶颈，以及和已有方案的合理用法比，它是否还有额外价值。这个顺序同样适用于区分标准和能力：先明确任务要什么、替代方案能做到什么，再判断失败是标准没写清还是模型确实做不到⁠3,4。