这篇沉淀一个可复用的工程模式：把评测用例固定下来，让每次改动都能与过去比较。
方案部分给出三条硬规则——用例只增不删、改动前后各跑一遍、不达标不发布。最易误用是边改需求边改用例，让分数失去可比性；用例集一旦开始漂移，回归就退化成形式。
增量在于把适用条件讲清楚：自动判分场景直接用，主观生成任务退化为人工抽样对比，用例规模与改动频率要匹配，避免小团队照搬大团队的自动化程度。
读完就做一件事：把手头项目最近一次改动前后各跑一遍现有用例集，看看有没有被弄坏的场景。
—— FDEChina编辑部 · 架构师视角
这是 AI 应用工程里复用度最高的一个模式：无论项目是 Agent、检索问答还是结构化抽取，只要迭代在持续，就值得把它装上。
问题
AI 应用的迭代方式与传统软件不同：换一个模型版本、调一处提示词、改一段工具调用逻辑、换一种检索策略，每一次改动都可能修复一部分场景、同时弄坏另一部分。没有回归机制时，「修好了 A、弄坏了 B」要等到客户用出来才发现；团队靠手工点几个案例做判断，结论不可比、不可累积，改动越频繁，大家心里越没底，最后变成谁嗓门大听谁的。这本质上是传统软件工程里回归测试的缺位，只是 AI 应用里「行为」没有确定的预期值，问题更隐蔽。
方案
建一组固定的用例集，每条含输入、期望行为（或期望性质）与难度标记；每次改动之后，跑同一套用例，用同一套口径出分数：总体通过率、坏例数量、关键场景的分项得分。配套三条规则：第一，用例集只增不删，线上发现的每个新坏例都转化成一条新用例，坏例是资产不是债务；第二，改动前先跑一遍记录当前分数，改动后对比，没有改动前的分数就没有「变好还是变坏」可言；第三，分数跌破约定阈值就不合并、不发布，阈值与客户验收标准对齐。用例怎么收、指标怎么定、基线报告怎么写，见评测基线建设 Playbook；上线后把这套回归接进日常运营，配合线上采样与告警，见上线前检查清单的监控一节。模式本身不限定实现方式：可以是接在代码提交之后的自动执行链，也可以是一条手跑的命令，关键是「同一套、每次跑、出同口径的数」。
适用条件
最适合的场景有三个特征：改动频繁、期望行为明确、结果可以自动判分——Agent 的工具调用正确性、检索问答的答案要点、结构化抽取的字段比对都属于此类，背景可参考Agent 主题。主观生成类任务（文案、创意、开放式总结）判分难以自动化，可以退而求其次：用人工评审做小样本前后对比，但成本高得多，只能覆盖核心场景，不要试图全集覆盖。用例集规模要与改动频率匹配：一天改多次的团队需要全自动执行与告警，一周一改的项目手工跑一遍也完全可接受。起步不必求全——哪怕只有三十条核心用例，也远好于「改完点几个看看」；回归模式的价值随用例积累复利增长，第一天要做的事只是把第一版用例固定下来。