前几篇讲怎么造工具：骨架搭起来、Prompt链串起来、API接进去、四个实战工具跑通。但你有没有想过一个问题：你的工具到底好不好？

别急着回答"好用"。我猜你的评测方式是这样的：找两三个真实输入，跑一遍，看看输出，觉得"不错"——然后就算过了。

这不是评测，这叫"跑几次看看"。传统软件测试好歹还有个测试用例集和预期结果，AI工具连"预期结果"都定义不了——同一个输入，AI每次输出的措辞都不一样，你怎么判断对错？

《造一个测试用例生成器：从需求文档到结构化用例》的用例生成器、《造一个测试数据工厂：按规则批量生成+脱敏》的数据工厂、《造一个失败分析助手：日志扔进去，根因出来》的失败分析助手、《造一个需求评审Copilot：PRD扔进去，风险点出来》的需求评审Copilot——这四个工具我造完之后，都经历了同一个阶段：技术上跑通了，但我不知道它到底好不好。后来花在"评测"上的时间，比造工具本身还长。

第一个坑：用"跑几次看看"当评测

造完用例生成器那天，我找了3份PRD喂进去，输出一看——格式工整、维度齐全、用例标题也像那么回事。我心里说：成了。

第二周，同事用它评一份"用户注销"功能的PRD。输出里赫然出现一条用例："验证用户注销后能否正常登录。"——注销了还怎么登录？这种逻辑矛盾，我之前测的3份PRD里根本没暴露。

3份PRD不够，30份也不一定够。因为你测的不是"AI能不能处理这份输入"，而是"AI会不会在某种特定输入上犯蠢"。这种边缘情况，你手动挑3份是挑不出来的。

后来我建了一个评测集——从过去半年的PRD里挑了50份，按功能类型标注（登录/支付/退款/权限/文件……），每份手动标注了"期望输出应该包含哪些维度"和"绝对不能出现的错误"。

50份跑下来，正确率61%。我之前以为"成了"的那个工具，三分之一以上的场景会出问题。你看到的"不错"，只是你碰巧没喂到它犯蠢的输入。

第二个坑：用"准确率"当指标——但什么算"准确"？

建了评测集，下一个问题来了：怎么打分？

传统软件测试有"预期结果"，pass或fail。AI工具的输出是自然语言，你没法做精确匹配。用例生成器输出的20条用例，哪些算"对"哪些算"错"？

一开始我试着用"准确率"——每条用例人工标注对错，算比例。但很快发现"对"和"错"之间有巨大的灰色地带：

用例标题写"验证密码强度校验"，步骤是空壳——算对还是错？

用例写了"测试大文件上传"，但团队的标准是"超过10MB"——算对还是错？

用例逻辑没问题，但跟团队Excel模板格式对不上——算对还是错？

"准确率"这个指标在AI工具评测里几乎没法用。因为输出不是非黑即白的。

后来我换了思路，按工具类型定义不同的指标：

注意一个共同点：没有一个指标叫"准确率"。全是任务特定的、可量化的、有实际业务含义的指标。

拿失败分析助手举例：我关心的是"真实根因出现在AI给出的前3个候选中"。AI给出5个候选根因，第1个是错的（连接超时），但第2个是对的（序列化异常）。如果按"第一个对不对"算，它失败了；但按"Top3命中"算，它成功了——而且AI给的支持证据确实有价值，即使结论不完美，排查方向是对的。

评测指标的定义，比评测本身更重要。指标定错了，你优化了半天可能在优化错误的方向。

第三个坑：没有基线，所有数字都没有意义

指标定好了，跑出来"Top3命中率72%"——这个数字好吗？

不知道。因为你没有基线。

72%是高是低，取决于你跟什么比。跟"随机猜"比，那当然高；跟"一个有3年经验的测试工程师"比呢？跟"对话式AI（不做成工具，直接贴日志问ChatGPT）"比呢？

我做失败分析助手评测时，设了三条基线：

人工基线：5个测试工程师，同样的日志，平均Top3命中率68%

对话式基线：直接把日志贴进ChatGPT，Top3命中率55%

工具基线：《造一个失败分析助手：日志扔进去，根因出来》第三版工具，Top3命中率72%

72% vs 人工68%——只高了4个百分点。单看这个数字，工具好像没什么优势。但还有一个指标：平均分析时间。人工平均23分钟，工具平均90秒。

4%的准确率提升 + 15倍的速度提升——这个组合才是工具的真正价值。如果只看准确率，你会觉得"白造了"；加上时间维度，结论完全不同。

没有基线的数字是孤立的，没有意义。"72%"本身不说明任何问题，"比人工快15倍且准确率略高"才说明问题。

第四个坑：Prompt改一行，回归跑一遍

工具上线后，你会不断改Prompt。用户反馈"这里输出太啰嗦"，你改一句Prompt；发现"这里经常漏边界条件"，你又改一句。

每改一次Prompt，都可能把别的地方搞坏。

《造一个测试用例生成器：从需求文档到结构化用例》用例生成器上线两周后，同事反馈"用例步骤太简略"。我在Prompt里加了一句"每个用例的测试步骤至少写3步"。改完，步骤确实详细了——但覆盖率从61%掉到48%。因为AI把token都花在写步骤上了，维度覆盖反而缩水。

这就是AI工具的回归测试问题：Prompt是非确定性的，你改一个字，行为可能完全变。

传统软件回归测试有"预期结果精确匹配"。AI工具不能这么干——同一个输入，改了Prompt后输出措辞变了，但内容可能一样好。你不能因为"输出文本变了"就判定fail。

我的解法是属性测试（property-based testing），不查精确输出，查输出是否符合特定属性：

用例生成器：输出是否包含期望维度？每条用例是否有标题+步骤+预期？有没有逻辑矛盾？格式是否符合模板？

数据工厂：生成的数据是否违反业务约束？手机号是否都是有效号段？去重是否成功？

失败分析：是否输出了Top3候选？每条是否有支持/反对证据？置信度是否标注？

每次改Prompt，自动跑50条评测集，检查这些属性。属性测试不能保证输出"好"，但能兜住"别搞坏"的底线。

说实话，回归测试是AI工具维护成本最高的一块。造工具花了两周，维护回归测试集花了一个月，而且每次改Prompt都要更新。但如果不做，你的工具会在不知不觉中退化——用户不会告诉你，他们会默默不用了。

评测不是一次性的事

四个坑走过一遍，最大的感悟是：评测不是工具开发完之后的"验收环节"，而是贯穿工具生命周期的持续行为。

建评测集、定指标、设基线、跑回归——这四件事缺一不可。而且评测集要持续更新：用户反馈的新问题，加进评测集；业务变化导致旧用例失效，从评测集剔除。

如果你只能做一件事，做这个：建一个30-50条的评测集，定义3-5个任务特定指标，每次改Prompt都回归跑一遍。这比任何花哨的评测框架都管用。

一句话总结：AI工具评测四个坑——"跑几次看看"不是评测（建30-50条评测集）；"准确率"不能当指标（按工具类型定义覆盖率/命中率/误报率等任务特定指标）；没有基线所有数字都没意义（跟人工比、跟对话式比、加上时间维度）；Prompt改一行回归跑一遍（用属性测试不查精确输出，查是否符合特定属性）。评测不是验收环节，是贯穿工具生命周期的持续行为。