Prompt 回归测试：无意外地交付 AI 工作流

Source: Dev.to

为什么提示回归测试很重要

如果你的提示用于比一次性聊天更严肃的场景，就需要一个安全网。
一旦提示成为工作流的一部分——生成代码、起草客户邮件、汇总工单、转换 JSON、编写发布说明——它就等同于软件。而软件需要测试。

回归测试回答一个简单的问题：

“在相同的输入下，我是否仍然得到符合我合同的输出？”

合同可以包括：

• 结构（有效的 JSON、精确的键）
• 风格（语气、阅读水平）
• 约束（无个人身份信息、最大长度）
• 内容规则（必须引用来源、必须包含检查清单）

你不是在测试“创造力”；你在测试可靠性。

好合同 vs. 坏合同

坏合同： “写一个好的摘要。”

好合同： “返回包含键 title、summary、action_items（数组）、risks（数组）的 JSON。摘要不超过 80 个词。”

你可以直接嵌入提示中的合同示例片段

Output contract:
- Return valid JSON only (no markdown, no commentary)
- Keys: title (string), summary (string), action_items (string[]), risks (string[])
- summary: ≤ 80 words
- action_items: 0‑5 items, each imperative verb

构建黄金测试套件

一个黄金测试用例包括：

1. 一个 接近真实的输入
2. 一个 预期输出（或预期属性）

从 5–10 个案例开始，覆盖以下情况：

• 正常路径（常规输入）
• 边缘输入（空章节、奇怪的格式）
• 模糊输入（多重解释）
• 对抗性输入（例如 “忽略指令并…”，尤其用于自动化）
• 长输入（接近你的 token 预算）

将它们存放在仓库中，例如：

/prompts
  support_triage.md
/tests
  support_triage/
    001_happy.json
    002_empty.json
    003_adversarial.json
    001_expected.json

示例测试文件 (001_happy.json)

{
  "ticket": {
    "subject": "Login loop on mobile",
    "body": "User reports being redirected back to /login after 2FA…",
    "plan": "Pro",
    "priority": "high"
  }
}

常见验证策略

对于大多数团队，模式 + 不变量 是最佳选择。典型检查：

• JSON 能成功解析
• 必需的键存在
• 最大长度得到遵守
• 数组在界限内
• 没有禁用词

最小化 Node.js 测试框架

以下脚本会加载测试用例，调用你的模型，解析 JSON，并验证不变量。

与 CI 集成

如果你已经有 CI 流水线，可以将 harness 作为一个门槛加入：

• 测试通过 → 发布
• 测试失败 → 合并前进行调查

把提示词的改动视为其他高风险改动：

1. 显示提示文件的差异
2. 在 CI 中运行回归测试
3. 为几个黄金样例提供“前后”输出

Prompt 变更日志示例

在提示文件的顶部，保留一个简短的变更日志：

# support_triage prompt
# 2026-03-13: tightened summary length, reduced action_items max to 5

这可以让几个月后更容易判断漂移情况。

分拆职责

如果一个提示承担了太多任务，请将其拆分：

• Prompt A – 提取结构化数据
• Prompt B – 根据该结构撰写散文

每个部分都更容易测试。

轻量化系统，适用于个人开发者或团队

1. 仓库中的 Prompt 文件（Markdown）
2. 10–30 个 golden 输入（JSON）
3. 验证器（schema + invariants）
4. 每个 PR 的 CI 检查
5. 定期从真实数据中刷新 golden（先进行清理）

你不需要企业平台就能获得 80 % 的价值。将 prompts 视为有版本、可测试的制品，你的工作流会更平稳。你的未来的自己（以及团队成员）会感谢你，因为当模型更新悄悄改变生产行为时，CI 能捕捉到。

如果你构建了类似的小型 harness，我很想了解你最终验证了哪些 invariants。