夜雨聆风Treeify 专注把测试设计变成经验可沉淀、可持续迭代的过程——用结构化方法把问题空间拆开，再生成更少但更有覆盖的用例。
欢迎参加社区共创/免费内测：【填写问卷】进内测共创群，获得 Treeify 内测资格 / MCP Server 试用。
摘要
LLM-as-Judge 正在成为 AI 应用评测里的热门方法。很多团队开始用另一个大模型来评估 AI 输出质量，判断回答是否准确、是否有害、是否符合标准、是否覆盖关键信息。这个方向当然有价值，因为 AI 产品的输出不再适合只用固定断言判断，而人工评审又太慢、太贵、难以规模化。但测试团队不能因此把评测完全交给 AI。LLM-as-Judge 可以提升评测效率，却不能替代团队定义评估标准。真正可靠的 AI 评测，必须先设计清楚评估维度、样本集、风险边界、评分规则和人工抽检机制。否则，让 AI 评 AI，很可能只是把一个黑盒交给另一个黑盒。
正文
AI 产品越来越多之后，测试团队很快会遇到一个新问题：AI 输出到底怎么判断好坏？
传统功能测试里，很多结果可以直接判断。
登录成功就是成功，登录失败就是失败。
订单金额算对就是通过，算错就是失败。
接口返回字段符合约定就是正常，不符合就是缺陷。
但到了 AI 产品这里，事情没有这么简单。
用户问智能客服“退款怎么还没到账”，AI 可能有很多种回答方式；用户让 AI 总结一段会议记录，摘要不一定只有一个标准答案；用户用 AI 搜索内部知识库，系统返回的结果也很难只用“完全匹配”判断。
这时候，如果每一条输出都靠人工评审，成本会很高。尤其是当团队要评估上千条问答、几百份摘要、多轮对话、不同版本模型和不同 Prompt 时，人工评审很快就会成为瓶颈。
于是，LLM-as-Judge 开始变得流行。
简单说，就是让一个大模型充当评委，去评估另一个 AI 的输出质量。它可以判断回答是否准确、是否完整、是否有害、是否符合格式、是否遵守业务规则，也可以给出分数、理由和改进建议。
听起来很合理。
AI 生成内容，AI 再来评判内容。
模型产出结果，模型再判断结果是否达标。
原本需要大量人工评审的工作，现在可以自动化一大部分。
但问题也恰恰在这里。
AI 可以辅助评测 AI，但测试团队不能把评测标准交给 AI 自己决定。
否则，评测效率可能提升了，但评测可靠性并没有真正建立起来。
如果想学习更多相关测试行业内容，可以关注下Treeify 专属知识星球：
LLM-as-Judge 到底解决了什么问题？
LLM-as-Judge 之所以火，不是没有原因。
它正好解决了 AI 产品测试里的一个现实矛盾：AI 输出越来越复杂，但传统断言越来越不够用。
比如一个 AI 总结功能，用户上传一份需求评审会议记录，系统生成“会议摘要、关键结论、待办事项”。如果用传统断言，很难要求输出必须和某段固定文本完全一致，因为摘要可以有不同表达方式。
但测试团队仍然需要判断这份摘要是否合格。
它有没有漏掉关键结论？
有没有把讨论意见误写成最终决定？
有没有把不确定事项写成确定事项？
有没有正确识别责任人和截止时间？
有没有编造会议里没有出现过的信息？
这些判断很难用简单代码规则完成，但大模型可以读懂自然语言，也能按照给定标准进行评分。
这就是 LLM-as-Judge 的价值。
它可以把过去只能人工阅读和判断的内容，转化成相对自动化的评估流程。
对测试团队来说，这类能力非常有吸引力。
因为它意味着评测可以批量化。团队可以准备一批样本，把不同模型、不同 Prompt、不同版本的输出放进去，再让 LLM-as-Judge 自动打分和总结问题。
这比完全人工评审高效得多。
但高效不等于可靠。
LLM-as-Judge 能帮团队更快评估输出，却不能自动保证评估本身就是正确的。
最大的问题：评测标准到底是谁定义的？
很多团队第一次使用 LLM-as-Judge 时，容易犯一个错误：直接让模型判断“这个回答好不好”。
这个问题看起来自然，但其实非常危险。
因为“好不好”本身没有标准。
对客服场景来说，好回答可能意味着准确、礼貌、能安抚情绪、不能过度承诺。
对知识库问答来说，好回答可能意味着基于来源、引用准确、不能编造、不能泄露权限外内容。
对 AI 辅助决策来说，好回答可能意味着逻辑清楚、风险充分、不能给出未经验证的确定结论。
不同场景里的“好”，完全不是一回事。
如果测试团队没有先定义评估维度，而是直接把判断交给模型，LLM-as-Judge 就会按照自己的理解去评估。它可能偏好表达流畅的答案，可能忽略业务规则错误，可能把“看起来很专业”的回答评成高分，也可能对真正关键的安全风险不够敏感。
这时候，评测就会变成另一种黑盒。
原来是被测 AI 在黑盒生成答案，现在是评测 AI 在黑盒判断答案。测试团队看到一个分数，却不知道这个分数到底代表什么。
比如一个智能客服回答：
您的退款已提交，预计 1-3 个工作日到账，请耐心等待。
这个回答语气友好，表达清晰，看起来很合理。如果 LLM-as-Judge 只关注语言质量和用户体验，可能会给高分。
但如果业务规则规定“该订单已经超过售后期，不能直接承诺退款到账”，这个回答就是错误的。它的问题不是文案不够好，而是业务判断错了。
所以，LLM-as-Judge 的关键不在于让模型自由判断，而在于让模型按照测试团队定义的标准判断。
评测标准必须由测试团队设计，模型只是执行评测任务。
让 AI 评 AI，为什么不能完全放心？
LLM-as-Judge 有价值，但它不是万能裁判。测试团队如果完全依赖它，会遇到几个很典型的问题。
第一，评估标准可能不稳定
同一条输出，在不同模型、不同 Prompt、不同温度参数、不同评分说明下，可能得到不同评分。
今天评 8 分，明天评 6 分；换一个 Judge 模型，结果又变成 9 分。
这对测试团队来说非常麻烦。
因为评测体系如果不稳定，就很难支持版本回归。团队无法判断这次分数变化是被测模型真的变好了，还是评测模型自己的判断漂移了。
AI 产品测试最怕的不是分数低，而是分数不可解释、不可复现、不可追溯。
第二，偏差可能不容易被发现
LLM-as-Judge 本身也有偏好。
它可能更喜欢长答案，因为长答案看起来信息更充分；也可能更喜欢结构化表达，因为结构化回答显得更专业；还可能对流畅自然的错误答案过于宽容。
在很多业务场景里，答案写得漂亮不等于答案正确。
一个错误的金融建议，如果表达很完整，仍然是错误；一个医疗咨询回答，如果越过风险边界，即使语气温和，也不能通过；一个企业知识库回答，如果引用了无权限内容，哪怕总结准确，也存在安全问题。
如果测试团队不对 Judge 的偏差做抽检，就可能被“高分答案”误导。
第三，边界样本容易不足
很多团队做评测时，会准备一些标准问题，比如常见咨询、普通摘要、正常搜索、典型推荐。这些样本当然需要，但它们通常覆盖不了真正危险的边界。
AI 产品出问题，往往不是出在标准输入里，而是出在模糊表达、恶意诱导、上下文缺失、权限边界、冲突信息、低质量文档和高风险请求里。
如果评估集里缺少这些边界样本，LLM-as-Judge 再强，也只能在有限样本里打分。
评测结果看起来很好，不代表系统真的安全。
第四，业务规则可能无法仅靠模型判断
很多 AI 输出是否正确，取决于企业内部规则。
比如退款政策、会员权益、权限范围、合同条款、审批流程、风控规则、售后补偿标准。这些规则如果没有提供给 Judge，模型就只能凭通用知识判断。
更麻烦的是，有些规则不是简单文本可以直接判断的，还需要结合订单状态、用户身份、业务上下文、历史记录和系统权限。
这时候，LLM-as-Judge 只能作为评估链路的一部分，不能替代真实规则校验和人工确认。
真正重要的不是 Judge，而是评估体系
很多团队讨论 LLM-as-Judge 时，会把重点放在“用哪个模型当 Judge”。
这个问题当然重要，但不是最重要的。
更关键的问题是：你到底让 Judge 评什么？
如果评估对象没有拆清楚，样本集没有设计好，评分维度没有定义清楚，风险边界没有纳入，人工抽检机制也没有建立，那么换再强的 Judge 模型，也只是让评测看起来更自动。
一个可靠的 AI 评测体系，至少要包括五件事。
没有这套设计，LLM-as-Judge 很容易变成“自动打分工具”。
有了这套设计，它才可能成为 AI 产品测试流程中的有效评审助手。
测试团队要把 LLM-as-Judge 放在正确位置：它不是评测体系本身，而是评测体系里的执行组件。
评估维度要先拆清楚
AI 产品的输出质量不能只用一个总分概括。
一个回答可能语言很流畅，但事实错误；可能事实正确，但没有引用依据；可能引用正确，但没有回答用户真正的问题；可能回答了问题，但没有拒绝高风险请求。
所以，测试团队要先把评估维度拆开。
以企业知识库问答为例，常见评估维度可以包括：
这些维度不能全部混在一个分数里。
如果只给一个“综合 8 分”，测试团队很难知道问题在哪里。到底是事实准确性不够，还是引用不可靠，还是安全边界有问题？不同问题的严重程度完全不同。
比如语气不够自然，可能只是低优先级优化；引用不存在来源，则是可信度问题；泄露权限外信息，则可能是高风险缺陷。
所以，LLM-as-Judge 的评分最好是分维度的，而不是只给总分。
更重要的是，有些维度必须设置一票否决。
比如隐私泄露、越权访问、危险建议、编造关键事实、错误承诺资金到账，这类问题不能因为语言流畅或结构完整就被综合分数掩盖。
样本集比模型更决定评测质量
很多团队会低估样本集设计。
他们以为只要有了 LLM-as-Judge，就可以随便拿一些输入输出让它评。这样做短期可以看到结果，但很难真正发现风险。
AI 产品评测的样本集，不能只覆盖“正常用户正常提问”。真正有价值的样本集，应该覆盖不同风险层级。
以 AI 客服为例，样本集至少可以分成几类：
如果样本集里只有标准样本，LLM-as-Judge 得出的高分意义有限。
因为它证明的是系统在正常路径下表现还不错，并不代表系统在边界条件下可靠。
真正的 AI 产品风险，往往出现在那些“不像标准测试用例”的输入里。用户不会按照产品经理写的示例来提问，攻击者也不会按照正常用户路径使用系统。
所以，测试团队要把样本集当作核心资产来维护。
评估集不是一次性准备完就结束，而是要随着线上反馈、缺陷复盘、业务规则变化、模型升级持续更新。
人工抽检不是形式，而是校准机制
既然用了 LLM-as-Judge，为什么还要人工抽检？
原因很简单：Judge 本身也需要被测试。
测试团队不能假设评测模型永远正确。它也可能漏判、误判、偏向某种表达方式，或者对某类风险不敏感。
人工抽检的目的，不是把所有样本重新人工评一遍，而是定期校准评测系统。
比如团队可以抽查几类样本：
高分样本里是否存在被 Judge 漏掉的严重问题；
低分样本是否真的低质量，还是 Judge 过于严格；
安全风险样本是否被准确识别；
业务规则样本是否按照企业标准判断；
不同 Judge 模型之间是否存在明显分歧；
同一个 Judge 在不同版本里评分是否漂移。
这类抽检可以帮助团队发现评测体系的问题。
如果发现 Judge 经常把“语言流畅但事实错误”的回答评高，就需要调整评分标准。
如果发现 Judge 对越权查询不够敏感，就要增强安全维度。
如果发现 Judge 对简短但正确的回答评分偏低，就要修正长度偏好。
如果发现某类业务规则总是判断不准，就要补充规则上下文或改用规则校验。
人工抽检不是对自动评测的不信任，而是让自动评测长期可靠的必要机制。
一个成熟的 AI 评测流程，不应该追求“完全没有人参与”，而应该让人的判断进入评测系统，持续校准模型评审标准。
LLM-as-Judge 更适合做什么，不适合做什么？
LLM-as-Judge 很有用，但要用在合适的位置。
它更适合评估那些需要语义理解、质量判断和多维度比较的内容，比如回答是否覆盖问题、摘要是否忠实原文、回复是否有害、语气是否符合规范、输出是否符合某种结构要求。
但它不适合替代所有测试判断。
比如金额计算、权限校验、接口返回、数据库状态、订单流转、规则引擎结果，这些确定性问题最好仍然用程序化断言、接口测试、规则校验或数据比对来验证。
也就是说，LLM-as-Judge 不是测试体系的替代品，而是 AI 输出质量评估的一种能力。
它应该和传统测试、规则校验、日志审计、人工评审、线上监控一起工作。
对于 AI 产品测试来说，未来不是“LLM-as-Judge 替代测试团队”，而是测试团队要学会把 Judge 放进完整评测链路里。
Treeify 如何承接 AI 功能测试设计？
Treeify 过去更多被理解为帮助团队从需求中拆测试对象、测试场景和测试用例。但 AI 产品越来越多之后，测试设计的对象也在变化。
测试团队不只需要拆业务功能，还需要拆 AI 功能中的评估对象。
比如一个 AI 客服功能，不能只拆“咨询、回复、转人工”。还要拆用户输入、意图识别、知识检索、回复生成、拒答机制、安全边界、人工接管和日志追溯。
比如一个 AI 总结功能，不能只拆“上传文件、生成摘要、导出结果”。还要拆原文覆盖、关键结论、待办事项、事实忠实度、未确认事项、敏感信息、引用依据和多次生成一致性。
比如一个 LLM-as-Judge 评测流程，也不能只写“调用 Judge 打分”。还要拆评估维度、样本类型、评分标准、一票否决项、人工抽检、评测结果追溯和评估 Skill 沉淀。
这正是 Treeify 可以延伸的方向：AI 功能测试设计。
在 Treeify 里，团队可以先拆评估对象，再生成评估场景，再沉淀评估 Skills。
评估对象解决“到底评什么”。
评估场景解决“用哪些样本来评”。
评估 Skills 解决“以后遇到类似 AI 功能，按照什么标准评”。
例如，团队可以沉淀一个“AI 客服回复评估 Skill”，规定当需求涉及客服问答时，需要从事实准确性、业务规则一致性、拒答能力、情绪处理、越权风险和人工接管几个维度生成评估场景。
也可以沉淀一个“AI 总结评估 Skill”，规定当需求涉及文本总结时，需要检查摘要是否忠实原文，是否遗漏关键结论，是否把待确认事项写成最终结论，是否可追溯到原文证据。
这样，测试团队不是每次都临时想“这个 AI 功能该怎么评”，而是逐渐把评估方法沉淀成可复用能力。
Treeify 的价值不在于替团队决定评测标准，而是帮助团队把评测对象、评测场景和评测方法结构化，让 AI 产品测试从一次性经验变成可复用的测试设计资产。
结语：AI 可以做评委，但规则必须由人来定
LLM-as-Judge 会越来越常见。
因为 AI 产品的输出越来越复杂，人工评审成本越来越高，传统断言又覆盖不了语义质量、上下文一致性和安全边界。让大模型参与评测，是一个很自然的方向。
但测试团队必须清楚一件事：
让 AI 评 AI，不等于把质量判断交给 AI。
LLM-as-Judge 可以帮团队提高评测效率，可以批量判断输出质量，可以辅助发现问题，也可以让回归评测更自动化。
但它不能替代测试团队定义评估标准。
真正可靠的 AI 评测，不是选一个强大的 Judge 模型就结束，而是先把评估对象拆清楚，把评估维度定义清楚，把样本集设计清楚，把风险边界标出来，再建立人工抽检和持续校准机制。
否则，测试团队只是把一个不确定的输出，交给另一个不确定的评委。
AI 产品越智能，测试设计越不能偷懒。
未来的测试团队需要掌握的不只是怎么测功能，还要掌握怎么评估 AI 输出，怎么设计评估集，怎么校准 Judge，怎么判断哪些问题可以自动评，哪些问题必须人工确认。
LLM-as-Judge 很有用。
但真正决定 AI 评测质量的，永远不是 Judge 本身，而是测试团队有没有把规则、样本、边界和责任设计清楚。
