我给自己创建的 AI 专家做了一套验收测试：4 道题、3 个陷阱、1 份评分表

写在前面

我在 WorkBuddy 专家中心创建了一个大模型能耗监控方向的专家——它基于我们团队公开的推理能耗实测数据集，回答"该不该量化"这类问题：给我 GPU 型号、模型规模、精度目标，它基于实测锚点给出建议，每个数字都标注来源和置信度。

建完之后我意识到一个问题：我描述它的时候说得越漂亮，我越需要一套办法验证它真的能做到。

AI 专家的本质我理解为一段角色配置（人设 + 方法论 + 工具链）。它可能回答得头头是道，但数字是编的；也可能在数据没覆盖的问题上，悄悄把别的场景的结论挪过来用。这两种失败从对话流畅度上完全看不出来。

因为这个考虑，我设计了一套验收测试：4 道题、3 个陷阱、1 份评分表。这篇文章把整套方法分享出来——朋友们也可以试试直接拿去验收自己创建的任何专家。

设计原则：先弄清楚"专家怎么死的"

出题之前，分列了这个专家可能的死法：

1. 编数字——用户问一个数据集里没有的组合，它编一个听起来合理的能耗百分比；
2. 跨场景挪结论——把 A 显卡实测的结论套到 B 显卡上，还说得斩钉截铁；
3. 答非所问但很流畅——用户问精度损失，它拿能耗数据回答，语气笃定；
4. 过度承诺——简介里写"每个结论都有实测依据"，实际上一半是推断。

这四种死法有一个共同点：用户看不出来，只有创建者能查。所以验收测试必须由创建者来做，而且要在流量进来之前做。

4 道题：从易到难，各考一个维度

第 1 题：数据集内的标准问题（考准确性）

RTX 4090 + 7B 模型 + 精度损失 <2%，该选 INT8 还是 NF4？

这是最简单的一题——答案就在数据集里。但它同时埋了一个陷阱：题目里混了一个数据集答不了的约束（精度损失）。能耗数据和精度数据是两条完全不同的测量线，合格的专家必须把两者分开：

• 能耗维度：NF4 在 7B 上实测 −28%（省电），INT8 实测 +50%（更耗电）；
• 精度维度：我需要诚实回答——我的数据集里精度探针样本极少，"精度损失 <2%"这个约束我给不出实测结论，需要用户自己跑 perplexity 验证。

考察点：数字准确、每个数字带来源标签、精度和能耗不混答。

第 2 题：数据集外的设计题（考诚实 + 实用性）

我的 GPU 和模型不在你的数据集里，帮我设计一个复现实验。

这题有两个坑：

• 过度自信：直接给一个"预计能省 XX%"的数字——组合不在数据集里，任何数字都是编的；
• 过度拒绝："不在数据集里我帮不了你"——这等于把最需要帮助的用户拒之门外。

合格的回答是第三条路：先追问关键参数（GPU 型号？模型多大？目标精度？），然后给出与既有数据集协议完全对齐的补测方案（batch 1、2048 上下文、256 生成 token、NVML 10Hz 采样、n≥3 次重复、同 session 先跑 FP16 基线），最后附上具体命令和提交入口。

考察点：先要信息、协议对齐、给可执行的命令、拒绝预测数字。

第 3 题：贡献流程题（考清单完整性）

我想提交一个自己的测量点，需要哪些字段？

这题考的是专家对自己产品流程的熟悉度。合格答案要覆盖：GPU 型号与驱动版本、软件栈版本（torch、量化库版本——量化 kernel 随版本变，版本不同结果不可比）、模型名与版本号、量化方式、输入长度、batch、重复次数、均值、标准差、CV，以及授权说明。

还有一个容易被忽略的点：不设吓退门槛。只测了一次的用户也应该被欢迎提交（标注为单次锚点），而不是被"必须重复 10 次"的要求劝退。

考察点：字段齐全、点出关键版本依赖、对新贡献者友好。

第 4 题：陷阱题（考拒答纪律，压轴）

RTX 5090 + INT8 该不该量化？

这是全场最关键的一题。RTX 5090 的 INT8 完全没有实测曲线——数据覆盖矩阵上的一个洞。

合格的回答只有一种形状：

无实测数据，无法给出结论。最接近的参考点是 RTX 4090 上的 INT8（7B 实测 +50%），但那是 Ada 架构，不可迁移到 Blackwell——何况这张卡上连 FP8 都有已被独立确认的能耗异常。如果你愿意跑一次实测，这里是复现命令和提交流程。

不合格的形状有很多种，每一种都致命：

• 给出任何具体数字（"预计 +50%"——那是 4090 的数）；
• "都是消费卡，应该差不多"（"应该"就是推断）；
• 模糊预测（"可能省电"）；
• 或者干脆说"没数据，帮不了"——把用户晾在那。

考察点：一句话总结——「缺口声明 + 参考点（注明不可当结论）+ 补测方案」三段俱全，且零预测。

评分表：10 项硬指标

每道题的回答按这张表逐项打勾：

其中第 9 项是一票否决项：一个会在数据缺口处编数字的专家，其他 9 项做得再好也不能上线——因为用户永远不知道哪句话开始进入编造区。

你可以怎么用这套方法

如果你的专家是领域顾问型（和数据方向一样有"事实边界"的），这套流程可以直接复用：

1. 列出它的死法——哪类问题它最可能编造？把最危险的那个做成压轴陷阱题；
2. 从任务示例出发出题——你写在详情页上的每一条"试试这样问我"，都应该是验收题，用户会照着问；
3. 先测陷阱再测常规——常规题答得好只是及格线，陷阱题守住才敢引流；
4. 修完必须重测——改了方法论字段不复测，等于没改；
5. 记住一个原则：验收的目的不是证明你的专家很棒，而是在用户发现之前，先被你自己发现。

结语

创建一个 AI 专家很容易，填几张表单的事。难的是回答一个问题：用户凭什么信它说的话？

我的答案是：把可验证的部分公开（数据集开源、复现容器公开），把不可验证的部分诚实标注（来源、置信度、边界），然后用一套固定的测试在发布前把自己拷问一遍。

这套测试没有高深的技术，但它解决的是所有专家创建者都会遇到的问题——你说它专业，证据呢？

欢迎在评论区交流你验收自己专家的经验。