上一篇结尾留了一个问题：十二个分类任务里十一个对了，那一单错了，这套东西到底算不算合格？这个问题在原型阶段还可以含糊过去——反正只是验证假设。可一旦要回答"能不能给业务用"，含糊就不行了。你需要一个标准，而且这个标准不能是"看起来不错"。

现实里最常见的答案是准确率。"我们的模型准确率 95%。"然后呢？95% 回答不了任何一个业务真正关心的问题：错的那 5% 错在哪里、代价是什么、出错的时候系统知道吗、谁来兜。准确率先天地假设所有错误等价，而业务上错误从来不等价——把一张好图误判成缺角度，顶多重做一遍；把缺版权信息的素材放行上架，可能就是法务问题。

FDE 怎样建立判断标准：不是替业务拍一个分数线，而是把"好"拆成业务能确认、样本能检验、失败能归类的具体条目。这套标准一旦建成，评测就从"每次重新吵一遍"变成"按既定条目过一遍"——前者消耗的是会议，后者积累的是资产。

这套做法不新——商业分析里的验收与评价标准讲的就是它——但在 AI 场景里要补上三块新东西：样本的分层设计、开发与独立测试的分离、以及对"局部合格不等于整套可用"的明文处理。

一、准确率为什么回答不了能否使用

先把准确率这个数字本身拆开。

准确率 = 判对的样本数 / 总样本数

这个公式里藏着三个选择，每一个都可能让数字失去业务含义。

如果样本是开发时顺手挑的，模型在这些样本上见过类似的输入，95% 测的是记忆不是能力。

分类任务里"判对类别"算对，那类别对了但理由张冠李戴算不算对？业务动作场景里"返回了成功"算对，那动作作用在错误的对象上算不算对？

十二单里十一对一错，和一万单里九千九百对一百错，同样是"高准确率"，但那一百错的分布——集中在某一类输入上，还是随机散开——决定了系统敢不敢用。集中分布意味着存在一类系统性盲区，随机散开意味着残余噪声，前者的处置是修盲区，后者的处置是评估兜底成本，混在一个数字里全看不见。

更深一层的问题：准确率默认"系统必须给出判断"。可业务上最有价值的能力之一，恰恰是知道什么时候不该给判断——资料不全时退回、依据失效时拒答、拿不准时转人工。一个永远给出答案、准确率 95% 的系统，和一个知道在 10% 的情形下说"这个我不该自动处理"、其余 90% 全对的系统，后者对业务的价值大得多，前者的准确率数字却更漂亮。

FDE 建立判断标准的第一步，是把问题从"模型准不准"换成"业务行为可接受吗"

。这两个问题的差别，决定了后面所有评测工作的形态。

还有一个常被漏掉的维度：评测既要看回答，也要看动作结果。问答类系统看回答顺理成章，但 AI 越来越多地直接执行动作——建任务、改状态、发通知。动作类行为的"对"不在措辞里，在系统状态里：任务建在了正确的对象上吗，状态变更是不是预期的那一种，副作用有没有越界。只评回答不评动作，等于只看说了什么不看做了什么。

禾木家居的上架流程是四步：分类、选图、裁图、套版。团队给 AI 定的任务是辅助这套流程。最初的验收口径很朴素："裁图准确率要到多少多少。"跑了几次，数字不错，可上架组不买账——"图裁得再准，这套商品还是上不去。"

原因很快清楚了：上架的业务单位不是单张图，而是一整套素材。一套商品要覆盖规定视角——正面、侧面、背面、细节——要有版权信息，要有必要规格说明。单张裁切全对，缺了背面图，整套照样不合格。用单图的平均得分去评价以"套"为单位的业务结果，等于用零件合格率代替整车验收，而且默认了零件之间互不影响。

这个错位在 AI 项目里极常见，因为模型的天然处理单位（一张图、一段话、一条记录）往往小于业务的结果单位（一套素材、一次完整答复、一单走完的流程）。处理单位上做到 98 分，结果单位上可能不及格——而且没人撒谎，只是两张卷子不一样。

FDE 在这里做的第一件事，是把判据写成业务语言，请业务角色确认。禾木家居的整套可上架判据是这样的：规定视角齐全；每张图裁切符合模板；版权信息字段非空且来源可追；规格说明覆盖该品类必填项。四条全部满足，整套才算"可上架"；任何一条不满足，结论是"不合格"，并输出缺什么、由谁处理。

注意这个判据的几个特征。它是通过或不通过的，不接受"基本合格"。它按业务单位（整套）而不是处理单位（单图）组织。它的每一条都能落到一个具体检查上，不依赖"整体感觉"。它的输出不止结论，还有缺口和处理人——评测的产出不是分数，是行动依据。这四条特征，就是把"看起来不错"变成"可重复使用依据"的全部机关。

商业分析里的验收标准一直就是这么要求的：可衡量、可测试、表述为通过或不通过。

AI 场景的新增难点在于，系统的行为不像传统软件那样完全确定——同一个输入两次运行可能给出措辞不同的输出。所以判据要落在"行为"上而不是"字面"上：检出了缺背面图、指出了处理人，就算符合，至于那句话怎么说，不作为判据。判据锁行为不锁措辞，是 AI 评测和传统验收测试最实用的一条分界。

写出来之后还要做一件反直觉的事：把判据拿给业务角色逐条确认，而不是自己宣布。裁切符合模板——什么模板，第几版？规定视角——哪几个视角，谁规定的？这些追问很琐碎，但每一条都是将来评测争议的预埋点。判据没确认就跑评测，等于用一把没有刻度的尺量东西，量完再回头争论刻度在哪。

三、让样本覆盖正常、边界与拒绝

判据定了，接下来是样本。样本设计的原则一句话可以说完：样本不是来证明系统行的，是来找出系统什么时候不行的。

第一类正常样本：视角齐全、信息完整的整套素材，预期结论是"可上架"。

这类样本验证基本正确性，人人都会做，不展开。

第二类边界样本：贴着判据边缘的输入。

商品 P-08（教学编号）：单张裁切全部合格，但整套缺背面图——四条判据里三条满足、一条不满足，预期的整套结论是"不合格，缺背面图，由素材组补拍"。这类样本压的是系统会不会"四舍五入"——大部分条件满足时，把缺项含糊过去。

第三类异常样本：错误规格的图、重复图（同一视角两张、缺另一视角）、版权信息字段为空。

每一类对应判据的一条，预期的结论分别是不合格并指明缺项。这类样本压的是系统能不能区分"哪里不合格"——只会说"不行"不会说"缺什么"的系统，业务上没法用，因为缺口和处理人还是要靠人再查一遍。

第四类无依据样本：这套商品所属品类根本没有已确认的必填规格清单。

正确的系统行为不是编一份清单来检查，而是输出"该品类的规格判据未确认，转规则负责人补齐后再评"。这类样本最少见，也最重要——它检验的是系统知不知道自己的判据从哪来、什么时候判据本身缺席。

四类样本各写清楚：输入、前置条件、预期结论、判定依据。判定依据要落到判据的某一条——"不合格"是因为"规定视角齐全"这条不满足，不是因为"系统觉得不行"。依据越具体，失败时越容易归类：是判据写错了，还是系统判错了，还是样本预期标错了，三种"不一致"的处理完全不同。

这套分层不是凭空发明的。逻辑能力的测试方法论里早有类似的六分法：正常样例验证基本正确性，反例样例验证不该触发时不误触发，边界样例验证阈值附近的处理，数据缺失样例验证降级行为，历史回放把逻辑输出放回真实业务事件里检验，专家复核确认解释是否合理。

前面四类样本对应前四种；历史回放和专家复核是上线前后的另外两道保险——用过去真实发生过的上架记录回放系统判断，请上架组老员工复核系统给出的不合格理由是否说得通。六道防线各有各的用处，谁也不能代替谁。

这里有一个反例必须点名：不能默认流水线各阶段的错误相互独立，然后把各阶段成功率直接相乘得到整体成功率。分类错一张图，后面的选图、裁图可能在错误的类别上"正确地"执行——错误会沿着流程传播和变形，不是简单叠加。整体合格率只能用整套样本实测，不能从阶段数字推算。

四、区分开发、独立测试与回归

样本设计得再好，用法错了，结论照样作废。

样本有了，怎么用，纪律比样本本身更重要。同一批样本在开发、独立测试、回归里扮演完全不同的角色，混用是评测失效的头号原因。

开发期样本是调试工具。系统判错了，看输入、看提取、看判据适用，改完再跑——这个过程里样本被反复看、反复用，系统（和调整系统的人）对这些样本越来越"熟"。这没有问题，调试本来就该这样。问题在于，用这批样本跑出来的成绩不能拿去向业务报告——那是开卷考试的分数。

独立测试样本是验收工具。它不参与任何调试，判据确认后由不带开发背景的人（或至少不带"我刚改过这块"记忆的人）执行，跑完如实记录。

因为开发者天然知道自己系统的强项和盲区，会不自觉地绕着雷区走——不是故意作弊，是人类认知的常态。独立测试的价值恰恰在于测试者没有这些知识，样本怎么走、边界往哪探，全凭判据和业务常识。小团队做不到完全的岗位分离时，最低要求是把独立测试样本集封存到调试结束之后，再打开。

禾木家居的独立测试（教学设定）用了另一批合成整套素材，调试样本里的 P-08 类问题在独立测试里换成不同品类、不同缺项形态重新构造——考的是"缺项检出"这个能力，不是"P-08 这道题"。用训练或调试过的样本冒充独立测试，是这个环节常见的自欺之一。

回归样本是保险。每次修订——改了提取逻辑、换了模板版本、更新了判据——都要重跑既有样本，确认通过过的还过、失败过的按预期变化。回归的意义在版本之间可比：第二版比第一版好在哪、坏了哪，靠的不是印象，是同一批样本在两版上的结果差异。

还要盯住一个慢性病：判据本身会过时。品类上新规了、平台改了上架要求、模板换了版本，原来正确的判据就悄悄变成了错误答案的来源。判据和样本都要有版本、有负责人、有复查节奏——这一点和第 13 篇讲的知识库版本治理是同一件事：你以为在评系统，其实系统和对它的评判标准绑在一起，一起老化。

这三个区分落到纸面上，就是一张评测矩阵：输入、前置条件、预期、判定依据、实际、版本、修订。矩阵按版本累积，每一次评测都能回答三个问题：这次测的是哪一版；测的是哪批样本（开发、独立还是回归）；结果和上次的差异来自哪里。

还要给所有数字打一个预防针：少量教学样本的结果不是可靠性统计证明。十二个样本全过，说明的是"在这十二个样本覆盖的情形下行为符合预期"，说明不了"上线后 99% 的情形没问题"。样本量、覆盖范围和结论强度要匹配着写，这是评测报告的基本诚实。

五、解读结果并安排下一次验证

评测跑完，结果不会是纯粹的"过"或"不过"，而是一组带分类的记录。解读的顺序是：先按错误类型归类，再按业务后果排序，最后决定下一轮验证什么。

归类是基本功。同一个"不合格"结论，背后可能是提取错误（图没读对）、判据适用错误（判据用错了品类）、判据本身错误（判据写漏了）、样本标注错误（预期标错了）。四类错误的责任人和修法完全不同，不归类就排序，等于让所有人都去修最显眼的那一处。

评测矩阵里单条记录长什么样，看商品 P-08 这一行就清楚了：输入是 P-08 整套合成素材；前置条件是所属品类有已确认判据；预期是不合格、缺背面图、转素材组；判定依据是"规定视角齐全"这一条不满足；实际与预期相符；版本、修订记录随每次复测更新。一行就是一个可复查的判断，而不是一个孤立的分数。

禾木家居这轮独立测试的整体记录（教学设定）：十二套样本，十套符合预期；两套不符合，都是同一类——系统对"重复图"样本判了"可上架"，因为它按张数检查视角齐全，没有核对每张图的实际视角。归类：判据适用错误，不是提取错误。后果：中——会被上架组人工拦下，但浪费一次往返。处置：修订视角核对逻辑，重复图样本进回归集；同时把"按张数判断"列为已知局限写进记录，因为它可能还影响其他品类。

下一轮验证的安排由此而来：扩大独立测试样本，重点覆盖"张数对但视角错"的各种变形；修订后先回归，再独立复测；同时把一个开放问题移交——视角判定目前依赖图片文件名约定（教学设定），这个约定的可靠性属于数据治理问题，不是评测能解决的，记入第 09 篇那类口径待确认清单。

最后把这一篇的边界划清楚：它

。系统上线后跑得稳不稳、会不会随数据漂移退化，是第 19 篇运行稳定性的问题；这套东西到底给业务带来了什么，是第 20 篇业务价值的问题。三个问题共用样本和记录，但结论不能互相替代——行为合格的系统照样可能运行不稳，运行稳定的系统照样可能没有价值。

把这套方法搬回采购场景。AI 核验一张申请单，别问"准确率多少"，先把判据拆成三件独立的事——资料完整吗、依据有效吗、当前状态允许这个动作吗——分开检查、分开记录、分开下结论。能用业务任务写出可执行判据，才算学会了这一篇；只会报模型分数的，还只是会看仪表盘。

下一篇讲排障：评测发现"不对"之后，怎样沿证据找到第一处偏离——不要一出错就换模型。

AI做得好不好，FDE怎样建立判断标准

副总裁

人工智能

测试

职业发展

FDE判断标准建立方法：从准确率陷阱转向业务可接受结果，通过分四类样本（正常、边界、异常、无依据）覆盖测试场景，严格区分开发与独立测试样本，按错误类型归类解读结果，确保AI系统评测成为可积累资产而非重复争论。

数据治理

验收测试

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

AI做得好不好，FDE怎样建立判断标准

AI做得好不好，FDE怎样建立判断标准

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐