状态稳定
类型原子 Skill
领域软件测试
生命周期测试设计
适合角色QA / DEV
语言中文 / 英文
评测有评测 ✓
同步日期2026-09-15
解决什么问题
它把当前 Skill 的方法整理成可以直接执行、评审和复用的质量输入。
- 避免只用精确字符串断言
- 固定并记录模型参数
- 对非确定性结果采用重复和分布判断
- 只列检查点，不说明输入条件、预期结果或证据。
适用场景
推荐使用
- 需要测试大语言模型应用的任务质量、鲁棒性、安全性、事实性和版本回归。
- 需要对现有方案、结果或证据做风险评审，并形成可执行改进项。
- 输入不完整，但仍需先给出带假设和信息缺口的可用初版。
常见误区
- 只列检查点，不说明输入条件、预期结果或证据。
- 把所有事项都标为高优先级，失去取舍价值。
- 用工具名或通用理论替代领域判断。
- 输入不完整时直接拒绝，或反过来假装结论已经确定。
输入
最低输入
- 当前任务范围、目标和待处理对象。
推荐输入
- 项目目标
- 测试范围
- 约束条件
可选上下文
- 相关代码或配置
- 历史结果
- 日志与指标
输出
输出会围绕该 Skill 的方法形成可执行结果，并明确事实、假设、风险和下一步。
不安装也能判断输出价值
- 01已覆盖：指令遵循、事实性、鲁棒性、安全、偏见、上下文长度、多语言、随机性、成本延迟。
- 02已区分事实、假设、缺口和建议。
- 03高风险项有明确优先级、证据、负责人或下一步。
- 04输出包含可验证的判断标准，而非泛泛而谈。
查看完整输出结构
- 05未执行未经授权的生产写操作或破坏性动作。
工作原理
- 01先阅读并遵循 prompts/llm-testing.md 的输入、执行规则、最低覆盖清单和输出顺序。
- 02补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
- 03先做输入审计，再区分已确认事实、合理假设和待确认问题。
- 04按风险和证据强度排序，产出可直接执行、评审或验证的结果。
- 05信息不足时不要停在提问：先交付受限初版，并说明哪些结论暂不能成立。
安装与快速开始
安装命令 / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-testing
-gllm-testing.prompt
@skill llm-testing
结合当前项目上下文，按该 Skill 的要求给出可执行结果。
补充上下文：
[粘贴项目背景或需求]---
name: llm-testing
description: Use this skill when you need to test LLM behavior, failure modes, and evidence-based quality boundaries; triggers include LLM 测试 and llm testing.
---
# LLM 测试（中文版）
## 何时使用
- 需要测试大语言模型应用的任务质量、鲁棒性、安全性、事实性和版本回归。
- 需要对现有方案、结果或证据做风险评审，并形成可执行改进项。
- 输入不完整，但仍需先给出带假设和信息缺口的可用初版。
## 输出格式选项
- 默认输出 Markdown，适合评审、执行和持续补充。
- 用户要求表格、CSV、JSON 或工单格式时，保留同样的风险、证据、优先级和边界字段。
- 若输出会进入自动化流程，先确认字段 schema、枚举值和必填项。
## 如何使用
1. 先阅读并遵循 `prompts/llm-testing.md` 的输入、执行规则、最低覆盖清单和输出顺序。
2. 补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
3. 先做输入审计，再区分已确认事实、合理假设和待确认问题。
4. 按风险和证据强度排序，产出可直接执行、评审或验证的结果。
5. 信息不足时不要停在提问：先交付受限初版，并说明哪些结论暂不能成立。
## 参考文件
- 每次执行必须读取 `prompts/llm-testing.md`；它是本 Skill 的完整执行规范。
- 需要评测或回归本 Skill 时，读取 `evals/eval.yaml` 与匹配的 `evals/cases/` 用例。
- 只有目录实际存在且任务需要时，才读取 `references/`、`examples/`、`scripts/` 或 `output-formats.md`，不要假设不存在的资产。
## 核心约束
- 避免只用精确字符串断言
- 固定并记录模型参数
- 对非确定性结果采用重复和分布判断
- 不编造输入中不存在的系统行为、字段、数据、指标或根因。
- 关键结论必须关联证据；证据不足时标记为假设并给出验证方法。
- 优先级必须说明业务影响、发生可能性或可探测性依据。
## 交付前自检
- [ ] 已覆盖：指令遵循、事实性、鲁棒性、安全、偏见、上下文长度、多语言、随机性、成本延迟。
- [ ] 已区分事实、假设、缺口和建议。
- [ ] 高风险项有明确优先级、证据、负责人或下一步。
- [ ] 输出包含可验证的判断标准，而非泛泛而谈。
- [ ] 未执行未经授权的生产写操作或破坏性动作。
## 常见误区
- 只列检查点，不说明输入条件、预期结果或证据。
- 把所有事项都标为高优先级，失去取舍价值。
- 用工具名或通用理论替代领域判断。
- 输入不完整时直接拒绝，或反过来假装结论已经确定。
## 最佳实践
- 从最可能造成业务损失、安全问题或发布阻塞的路径开始。
- 用最小可验证实验缩小不确定性，并记录复现条件。
- 让输出能够被另一位工程师直接执行和复核。