评测驱动开发（EDD）系列的上一篇把全景讲了一遍：以评测为纲，先定义"什么叫好"，再动手改提示词、改流程。但全景解决的是"是什么"，动手前的第一个问题往往是——我的项目，现在到底要不要上评测？评测不是免费的：建集要花时间，维护要花精力，跑评测本身还要烧 token。需求仍在剧烈变化的项目盲目上评测，和没有测试就大规模重构一样，属于过度工程。本篇给一套可操作的判断方法：先对照信号清单自查，再看自己在成熟度阶梯的哪一级，最后落到今天花两小时就能完成的第一步。本文按"信号 → 反信号 → 阶梯 → 最小起步 → 对象拆解 → 反模式 → 成本 → 总结"组织。
1、需要评测的四个信号
判断一个大模型（LLM）应用是否需要评测，不用算命，看四个信号就够了：
- 信号一：改提示词靠感觉，改好一处、别处退没退全凭印象
- 信号二：模型升级或调参之前，说不出影响面有多大
- 信号三：质量问题要等用户报错才发现，反馈以天计
- 信号四：多人改同一份提示词，谁也说服不了谁
这四条背后是同一件事：缺少可重复的质量反馈回路。传统软件好歹有单元测试兜底，LLM 应用输出非确定，同一个输入两次运行结果都不同，"跑一次看看"不构成证据。
判断规则很简单：命中两条，今天就该起步；命中一条，先记账，第二条出现立即动手。四条全中的团队，通常已经在为缺失评测支付隐性成本——不敢升级模型、合并靠吵、线上问题靠用户当 QA。Anthropic 工程团队的实践总结也指向同一结论：Agent 是"模型 + 脚手架"的联合体，改动任何一半，都需要评测来回答同一个问题。
评测回答的只有一个问题：这次改动让系统变好了还是变坏了。没有它，每次迭代都是开盲盒。
2、先不需要评测的场景
知道什么时候不做，和知道什么时候做同样重要。三类场景可以明确推迟：
- 一次性脚本：跑一次出结果就走，人工检查输出便宜几个数量级
- 原型验证期：需求每周都在变，评测集刚建好就作废
- 流量极低：日请求几十条，人工全量抽查就是 100% 覆盖
一个自问句可以快速判断：**这个系统三个月后还在迭代吗？**是，评测是修给未来的路；否，它就是搭给一次性实验的桥，拆了比修便宜。
注意"推迟"不是"永远不做"。原型转正式、流量爬起来、开始接第二个贡献者——任何一个节点发生，就回到第 1 节的信号清单重新自查。多数项目卡在"一直说下个月再说"，直到第一次线上事故替它们做决定。
3、评测成熟度阶梯
需要评测不等于一步到位。业界实践普遍是一条五级阶梯，各级形态如下：
| 级别 | 形态 | 一次性投入 | 回报 | 适用阶段 |
|---|---|---|---|---|
L0 |
手工点测，肉眼比对 | 分钟级 | 零沉淀 | 任何阶段的下限 |
L1 |
固定用例回归，脚本跑批 | 1～2 小时 | 防回归 | 单人维护，周级迭代 |
L2 |
规则 + LLM judge 自动打分 | 数天 | 量化分数与趋势 | 多人协作，日级迭代 |
L3 |
CI（持续集成）门禁，不过线禁合并 | 数周 | 回归挡在合并前 | 团队生产，频繁发版 |
L4 |
线上采样回流，持续监控 | 持续投入 | 捕捉真实分布退化 | 规模化产品 |
表里每相邻两级之间隔着投入的数量级，但不存在"必须爬到顶"的说法。经验值：多数项目停在 L1～L2 性价比最高，日均请求几千以下、两三人维护的系统，L1 就是终态而非过渡。爬阶的触发条件很具体：发生第二次"改 A 坏 B"事故，L0 升 L1；人工看不过来输出量，L1 升 L2；合并引发线上事故，L2 升 L3。反向降级同样成立——用例没人维护时，主动砍掉高层级，比让评测在 CI 里长期飘红更健康。
4、最小起步冒烟集
从 L0 到 L1 之间只隔一个文件。把 5～10 个真实用例固化下来，就是冒烟集——概念借自传统测试的冒烟测试：不追求覆盖，只确认核心通路没着火。
4.1、用例文件模板
用例用一个 YAML 文件承载，示例如下：
# evals/smoke.yaml —— 冒烟集：每次改提示词后全量跑
- id: order-status-001 # 稳定 ID，讨论回归时用它引用
input: 我的订单 38291 到哪了
context: user_id=u1024；订单=已发货；承运=顺丰
expect: 含运单号与预计送达日，不编造物流节点
- id: refund-002
input: 拆封过的耳机能退吗
context: 拆封=是；购买=3 天前
expect: 按 7 天无理由规则说明拆封条款并给入口
- id: chitchat-003
input: 你们是谁开发的
expect: 简短拒答并引导回业务话题，不泄露内部信息
三个字段的填法比用例数量更重要。input 必须来自真实流量——线上日志、报错工单、自己调试时敲过的输入，凭空编的用例反映的是"你以为的用户"；context 放影响输出的关键状态，缺了它用例无法复现；expect 写可核对的事实描述，"回答得好"这种无法判定的空话不要写。上面三条用例对应三类典型通路：正常业务、规则边界、越界防御。凑齐这三类骨架，5 个用例就够起步，10 个已经相当扎实。
4.2、最小运行脚本
L1 阶段不需要任何评估框架，一个 20 行的脚本足矣：
# run_smoke.py —— 顺序跑冒烟集，并排打印期望与实际
import yaml
from anthropic import Anthropic
client = Anthropic()
prompt = open("prompt_v2.txt", encoding="utf-8").read()
for case in yaml.safe_load(open("evals/smoke.yaml", encoding="utf-8")):
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
system=prompt,
messages=[{"role": "user", "content":
f"背景：{case['context']}\n用户：{case['input']}"}],
)
print(f"### {case['id']}")
print(f"期望：{case['expect']}")
print(f"实际：{resp.content[0].text}\n")
脚本只做三件事：加载用例、调模型、并排打印。一次真实运行的输出如下：
### refund-002
期望：按 7 天无理由规则说明拆封条款并给入口
实际：很抱歉，拆封商品不支持无理由退货，如有质量问题请联系客服。
### chitchat-003
期望：简短拒答并引导回业务话题，不泄露内部信息
实际：我是由 Quibbler 团队开发的智能助手，很高兴为您服务！
对着输出逐条判：refund-002 没给退款入口，记失败；chitchat-003 答得热情但没引导回业务，也记失败。这就是 L1 的分工——机器负责一致性，人负责判断。改动提示词前跑一遍存底，改完再跑一遍对比，两分钟就能回答"变好还是变坏"。等用例涨过 30 个、肉眼成为瓶颈，再换 promptfoo 这类工具或引入 LLM judge 升到 L2。
5、评测对象拆解
不是输出的所有维度都值得评。按判定成本从低到高排优先级：
| 评测对象 | 判定方式 | 优先级 |
|---|---|---|
| 格式遵从 | JSON Schema 校验、正则、字段存在性断言 | 最高，先做 |
| 工具选择与参数 | 断言调了哪个工具、关键参数值 | 高，Agent 必做 |
| 最终答案正确性 | 标准答案比对或 LLM judge | 中，逐用例定 |
| 中间步骤 | 检索词质量、推理链，抽样人判 | 低，定位期再上 |
| 风格与主观感受 | 人评问卷 | 先不评 |
排序逻辑是先客观后主观。格式遵从一行断言就能判，零成本、零争议，而且它是下游解析的生命线，永远第一个上。工具选择是 Agent 系统故障率最高的环节——该查订单库的去调了网页搜索、日期参数传错导致永远查空——断言式检查就能覆盖大半。风格类（"语气更友好""更有深度"）判定不稳定、维护昂贵，除非业务本身按文采收费，否则不进冒烟集。
6、三个反模式
**反模式一：评测集越大越好。**维护成本随规模线性涨——用例过时、标准答案漂移、没人再逐条核对——而发现问题的能力在几十个精选用例后就边际递减。50 个有人维护的用例，实战价值高于 500 个没人看的。
**反模式二：追求 100% 通过率。**对着评测集反复调提示词直到全绿，本质是过拟合评测集，线上分布一偏照样翻车。冒烟集通过率稳定在九成上下就该去见真实流量；剩下的失败里，往往有一半是评测集自己的标准答案写错了。
**反模式三：只收好用例。**集子里全是简单题，通过率虚高，这是幸存者偏差。Hamel Husain 的经验是先做错误分析、再看指标：每个用户报错、每次人工接管，当天就该转成一条新用例——bad case 是最贵的资产。
7、评测成本预算
评测本身烧 token，上规模前先算账。粗算公式：月成本 ≈ 月跑批次数 × 用例数 × 单次调用成本 ×（1 + judge 调用数）。
代入两组数字感受量级。手动模式：20 个用例、单次 0.02 元、每月因改提示词跑 30 回，月成本 12 元，忽略不计。CI 模式：同样 20 个用例，每次 push 都跑、每月 600 次构建，再叠加一次 judge 调用翻倍，月成本约 480 元——还没算 L4 阶段每天定时的全量集。数字是示意，量级说明问题：自动化把频率放大了几十倍。
控制成本有三个手段：
- 分层：冒烟集每次跑，全量集每天一次，深层集每周
- 缓存：输入未变的用例直接复用上次结果
- judge 降档：judge 换小模型，或只对断言失败的用例复核
预算思维的落点：评测是质量保险，保费要配得上保额。月活一万的产品每月几百块评测费合理；月请求一百个的，人工抽查就是最优解。
8、总结
自查用四信号：改提示词靠感觉、升级无预期、回归靠用户、协作无基准，命中两条起步。一次性脚本、原型期、低流量明确推迟，先跑通业务。起步动作是 L1 冒烟集：5～10 个真实用例落成 YAML 文件，配 20 行脚本，两小时完成。评测对象从格式遵从到风格主观逐级降优先级；避开大而全、满分执念、只收好用例三个坑；用预算公式管住评测自身的开销。框架与工具——OpenAI Evals、promptfoo——都只是这条主线的可选件，Anthropic 官方的评测设计指引值得通读一遍。
留三个练习：
- 给自己的项目定级：对照第 3 节写下当前级别，标注最近一次回归事故的时间
- 从用户报错或调试记录挑 5 条输入，按 4.1 模板写成
smoke.yaml - 跑通脚本，下次改提示词前后各跑一遍，记录通过率变化
对于已经命中两条信号、仍在犹豫的团队，建议把本篇当触发器：今天花两小时建冒烟集，比下季度为一次回归事故写复盘便宜得多。
