做过提示词工程的人都懂这种痛：上周还好好的回复，今天改了一段系统提示，某个边角场景突然开始胡来，而你根本不知道。解法不是更小心，而是把评测变成自动化测试。本文用 DeepEval 把 LLM 评测写进 pytest，接进 CI。
一条 DeepEval 用例长什么样？
DeepEval 把评测指标封装成断言：用一个样例，包含输入与期望输出，配上一个或多个指标，例如答案相关性、事实一致性、严格匹配。写起来和普通 pytest 几乎一样：定义样例列表，循环调用被测智能体，断言指标不低于阈值。逻辑上就是：对黄金集里的每条用例，跑一遍被测流程，再断言相关分数高于你设的红线。
黄金集该怎么一步步攒起来？
别一开始就建几百条。先从线上真实工单里挑三五十条「最容易出错」的典型问题，人工标注期望行为。每次线上翻车，就把这个案例补进黄金集——它就会变成一条永远不许再犯的回归用例。黄金集是长出来的，不是设计出来的。
把评测接进 CI 有多大成本？
评测要调模型，比普通单测慢且花钱。做法是：提交请求级别只跑子集做冒烟，合并到主干才跑全量。再给评测成本设个上限，避免半夜 CI 跑飞烧掉一大笔 API 费。
大模型评测分数该怎么正确看待？
DeepEval 这类「用大模型评大模型」的指标不是绝对真理，它更像一个报警器：分数掉了说明有变化，值不值得修要人判断。别把它当成精确的质量分，要把它当成「改动有没有让事情变坏」的护栏。
指标一开始该选几个才合适？
一开始别把七八个指标全挂上，每加一个指标，评测成本和噪音都涨。先选两个最贴你业务的：答案相关性和事实一致性。跑稳了，再按需加。指标是手段不是目的，你要的是「改动没让事情变坏」这一条报警线，不是一张看着漂亮却没人看的仪表盘。
为什么提示词也需要回归测试？
提示词和智能体代码和软件一样需要回归测试。把几十条黄金用例用 DeepEval 写进 pytest，你就拥有了一张安全网——下次再改提示词，心里有底，而不是靠玄学。
去论坛讨论
这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：DeepEval回归