如果我想转做agent评测，应该先补哪方面的能力? 评测岗位和普通QA、数据标注有什么实质区别? 怎么判断一个评测项目是在练能力还是在走流程?

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

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

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

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

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

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