把提示词回归检查接入 CI

改一行提示词，演示还正常，上线后却答错了。dev.to 的一篇文章针对这种回归提出了一个轻量方案：从真实流量整理 10—30 条固定用例，每次 PR 都运行检查，输出通过率低于已知良好基线时，让 CI 失败，把问题拦在合并前。

目前能确认什么

方案的核心是把「好答案」变成可检查的约束。每条用例保存输入，以及答案必须包含、禁止出现的内容，还可以限制长度、检查 JSON 合法性。先跑这些简单规则，有需要再增加模型评分。

这里的黄金数据集（golden dataset），可以理解为一组固定的参考用例。LLM 对同一个问题可能给出多种合格回答，因此检查重点是业务要求，而非逐字匹配。作者还提出，每次用户反馈错误回答，都应补进数据集，让旧问题进入后续检查。

作者维护的 Litmus 是这套思路的运行工具。节选展示了它对比基线、报告用例从通过变为失败，并以非零退出码让 CI 失败的过程；另有 JUnit XML 输出和离线 mock provider，可用于检查 CI 接线。

我的判断

最值得借鉴的是，把已经出过的问题变成每次 PR 都会重跑的用例。

对客服回复、结构化输出这类有明确约束的功能，这比临时试问几次更容易发现退步。但关键词命中只能证明词出现了，不能证明答案正确；合法 JSON 也可能装着错误内容。涉及语义正确性的要求，仍需更合适的评分方式。

节选没有说清重复运行次数、输出波动如何处理，以及基线怎样更新。这些会直接影响阻断合并是否可靠。另外，整体通过率相同，也可能发生旧用例退步、新用例通过的抵消，仍要看逐条变化。

**规则检查便宜，不代表整套评测没有模型调用成本。**离线 mock 能验证流程，真实输出质量仍要靠实际运行检查。