用WorkBuddy给大模型任务做“回归测试集”：把零散提问固化成可复跑的检查表
起因：改了一句提示词，别的地方悄悄坏了
有段时间我维护一套批量整理资料的提示词。为了修掉一个“总结写得太长”的问题，我加了一句约束，长文确实变短了，但两天后才发现：带表格的输入开始被漏掉一列。这类副作用很难靠肉眼发现，因为每次改动你只会去验证你刚修的那个点。
后来借了软件测试里的思路，用 WorkBuddy 搭了一份很小的回归测试集，问题才算收住。
它和“效果评估”不是一回事
评估回答的是“这套提示词整体好不好”，需要指标、需要打分、需要人力；回归测试集回答的是一个更窄的问题：这次改动有没有把以前能跑好的情况弄坏。所以不需要打分，只需要一组固定输入和一句“合格/不合格”的判据，跑得快、能反复跑，才有意义。
测试集怎么攒
我没有一开始就设计用例，而是从真实翻车记录里攒。每条用例四个字段：
| 字段 | 说明 |
|---|---|
| 用例编号与来源 | 从哪次实际问题来的 |
| 输入样本 | 尽量用真实材料，不自己编 |
| 合格判据 | 一句可机械判定的话，例如“输出包含 3 个字段且无额外文字” |
| 已知风险 | 这条用例当初为什么失败 |
判据必须能机械判定，这是整套东西能不能自动跑的关键。“回答要清晰”这种判据等于没写；改成“不含代码块围栏、字段数等于 3”才可用。
样本来源我用了 万象云档里几篇结构差异明显的文档：有纯叙述的、有带表格的、有分点清单的，正好覆盖不同输入形态。另外从 HTML 入门教程站 取了一份代码密集的短页，专门用来测“正文里带代码块时会不会被误处理”。
WorkBuddy 在这里承担什么
三件事：
- 按固定模板补齐用例：我给两三条示例，它按同样字段把新翻车记录转成用例，格式不会走样。
- 批量复跑并汇总：提示词每改一版，把整套用例重跑一次，输出一张“通过 / 失败 / 与上版对比”的表。
- 标记新增失败：只高亮“上一版通过、这一版失败”的用例。这一步最有价值，它把注意力直接引到副作用上。
第 3 点让整套东西从“又多了一份要维护的文档”变成了真的省时间：大部分时候表里全是绿色，扫一眼就结束。
三个踩过的坑
- 用例别贪多。 二十条以内最合适，多了就不愿意跑了。优先留那些真的翻过车的。
- 样本要固定。 输入一变，对比就失去意义；测试集里的样本应当锁版本，不要指向会更新的在线页面。
- 别让 AI 判“合格”。 判据必须是能由脚本或人一眼确认的硬条件，让模型自己给自己打分，很快就会全部通过。
小结
提示词、模型版本、工具链都会变，靠记忆和直觉维护不住。把零散的翻车记录攒成一份二十条以内、判据可机械判定的小测试集，再让 WorkBuddy 负责批量复跑和差异高亮，改动就从“凭感觉”变成了“有底”。这套方法不追求评估得多全面，只保证一件事：修好一个问题的同时，没有弄坏另外三个。