提示词测试 Skill：从 Prompt 变更中识别多轮行为漂移
一个提示词偶尔给出好答案，不等于它在真实输入、语言和边界条件下可靠。提示词测试需要把“感觉不错”变成可重复比较的样本和标准。
提示词测试 Skill 定义用例、量表和失败样例，使提示词变更可被当作行为变化评估。
本文以一个协作场景为例，拆解判断过程，说明如何把不同信号转化为可沟通、可追踪的行动。
提示词测试 Skill 用来做什么
提示词测试适合频繁迭代 Prompt、又需要保护多轮行为和安全边界的 AI 产品团队。它保存版本、会话状态和基线差异，让一次改文案不再靠感觉验收。
先回到源 Skill
这个 Skill 的完整执行规则在 提示词测试 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。
它要求特别注意：
- 不要只测一个样例
- 固定模型与参数
- 对语义结果使用 rubric 而非脆弱的逐字匹配
用一份项目材料开始
先把现有材料列出来。缺口可以保留，但状态要说清楚。
| 材料 | 这次填什么 | 缺失时的处理 |
|---|---|---|
| 目标与范围 | 验证订单助手 Prompt 在指令遵循、事实引用、边界拒答、多轮一致性与版本回归上的表现 | 标出不在本轮判断内的链路 |
| 版本与环境 | 模型版本、系统 Prompt、检索索引、温度和对话轮次 | 版本未锁定时只比较行为样本 |
| 证据 | 测试集、响应原文、评分、延迟、安全过滤和会话 ID | 缺少原始响应时不写通过率结论 |
| 决策边界 | 通过阈值、拒答边界、回归范围和评审人 | 把内容质量与安全门禁分开判定 |
可以这样调用：
请使用 prompt-testing Skill。
任务：验证订单助手 Prompt 在指令遵循、事实引用、边界拒答、多轮一致性与版本回归上的表现
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]
先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。提示词测试要把版本变化和行为变化连起来
| 产物 | 要回答的问题 | 最低证据 |
|---|---|---|
| Prompt 版本 | 这次改了什么约束或上下文 | diff、版本号和变更原因 |
| 预期行为 | 正常、边界和拒答分别应怎样输出 | 断言、格式和参考答案 |
| 多轮稳定性 | 前一轮状态是否改变后一轮结果 | 会话脚本、状态和重放记录 |
| 回归证据 | 哪些行为变好、变坏或没有变化 | 基线对照、分项结果和阈值 |
没有固定 Prompt 版本和可重放会话时，只能写一次性观察，不能说明回归结果。
在项目里跑一轮
先从一个边界清楚的小回合开始：验证订单助手 Prompt 在指令遵循、事实引用、边界拒答、多轮一致性与版本回归上的表现。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
Prompt 改动要使用固定任务集和明确评分规则，避免靠主观印象判断变好。这一轮至少要留下可复查的证据索引、仍然成立的假设，以及下一位同事可以直接执行的动作。
进阶使用：把一次分析变成持续机制
每次提示词测试都保存 Prompt、模型参数、输入集和会话状态。改动后重放关键对话，并把单轮改善与多轮退化分开记录。
三段式 Skill 链
prompt-testing → llm-evaluation-design → llm-testing
| 交接 | 传递内容 | 接收方要检查什么 |
|---|---|---|
| 上游到 prompt-testing | 来源版本、范围、风险、未决项 | 输入是否过期，冲突是否标记 |
| prompt-testing 到下游 | 判断、证据索引、残余风险、待办 | 产物是否可执行，Owner 是否明确 |
| 下游回写 prompt-testing | 执行结果、缺陷、事实变化 | 是否更新基线与回归范围 |
交接时同时传摘要、证据索引和原始材料的位置。这样即使结论出了问题，也能回到来源。
团队门禁
| 门禁 | 检查内容 | 未满足时 |
|---|---|---|
| prompt-testing 输入门禁 | 版本、环境、证据来源和 Owner | 停止生成，列出缺口 |
| prompt-testing 产物门禁 | 关键结论带依据、状态和影响 | 退回补证据 |
| prompt-testing 执行门禁 | 命令、查询或验证路径可复现 | 标记基础设施或测试问题 |
| prompt-testing 决策门禁 | 残余风险有接受人与日期 | 不进入下一阶段 |
容易踩的坑
- 只测一轮问答，漏掉上下文累积和状态污染。
- 用主观“更好”代替可复核的评分标准。
- 修改 Prompt 后没有保存旧版本，无法解释回归来源。
- 只测正常问题，漏掉边界、拒答和多语言输入。
相关 Skill
提示词测试要把 Prompt 变化和模型、Agent 的实际行为连接起来：
交付前复核：把判断落到证据
拿到 Skill 输出后，先核对四件事：输入版本是否明确、范围是否完整、每条结论能否回到证据、下一步由谁执行。缺一项，报告就容易变成漂亮的猜测。
| 项目 | 需要留下 | 缺失时 |
|---|---|---|
| 输入边界 | 版本、环境、时间窗口和本次范围 | 标记假设，不写成事实 |
| 证据索引 | 日志、报告、Trace、截图或命令输出 | 标记 evidence_pending |
| 结论状态 | verified、assumption、blocked 或 pending | 停止扩大结论 |
| 后续动作 | 最小验证命令、负责人和截止时间 | 交付为待办，不进入门禁 |
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，否则下一次复核时无法解释结论为何变化。
安装与调用
安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/prompt-testing -g安装后，直接使用上面的 prompt-testing 调用词，并附上本次的真实材料。
常见问题
输入还不完整，能开始吗？
能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。
什么时候需要人工确认？
范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。
先用一份真实材料跑通提示词测试，并把输入、产物、人工修改和验证证据留在同一条工作链上。这样下一次发生变化时，才有东西可以复用。
参考
- 提示词测试 提示词：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/prompt-testing/prompts/prompt-testing.md
- Awesome QA Skills：提示词测试 Skill 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/prompt-testing
- Awesome QA Skills GitHub 项目：https://github.com/naodeng/awesome-qa-skills
- 提示词测试 Skill 详情页：https://inaodeng.com/zh-cn/qaskills/prompt-testing/