ai-feature-testing · v1.0.0 · 2026-10-29 · sha256 c6a3966c3809fcfc

ai-feature-testing v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/c6a3966c3809fcfc.

---
name: ai-feature-testing
description: Use this skill when you need to test an AI-enabled product feature for behavior, safety, and user-impact boundaries; triggers include AI 功能测试 and AI feature testing.
license: PolyForm-Noncommercial-1.0.0
metadata:
  version: "1.0.0"
  compatibility: ""
  author: "Awesome QA Skills contributors"
  language: "zh-CN"
  category: "testing-types"
  source: "https://github.com/naodeng/awesome-qa-skills"
  license-url: "https://polyformproject.org/licenses/noncommercial/1.0.0"
---

# AI 功能测试(中文版)

## 何时使用

- 需要验证嵌入产品的 AI 功能在质量、安全、公平性、降级和用户体验上的表现。
- 需要对现有方案、结果或证据做风险评审,并形成可执行改进项。
- 输入不完整,但仍需先给出带假设和信息缺口的可用初版。

## 输出格式选项

- 默认输出 Markdown,适合评审、执行和持续补充。
- 用户要求表格、CSV、JSON 或工单格式时,保留同样的风险、证据、优先级和边界字段。
- 若输出会进入自动化流程,先确认字段 schema、枚举值和必填项。

## 如何使用

1. 先阅读并遵循 `prompts/ai-feature-testing.md` 的输入、执行规则、最低覆盖清单和输出顺序。
2. 补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
3. 先做输入审计,再区分已确认事实、合理假设和待确认问题。
4. 按风险和证据强度排序,产出可直接执行、评审或验证的结果。
5. 信息不足时不要停在提问:先交付受限初版,并说明哪些结论暂不能成立。

## 参考文件

- 校准领域结果、正确对照或证据缺口时,读取 [references/domain-decision-example.md](references/domain-decision-example.md) 的脱敏输入、逐项预期与复算依据。

- 每次执行必须读取 `prompts/ai-feature-testing.md`;它是本 Skill 的完整执行规范。
- 需要评测或回归本 Skill 时,读取 `evals/eval.yaml` 与匹配的 `evals/cases/` 用例。
- 只有目录实际存在且任务需要时,才读取 `references/`、`examples/`、`scripts/` 或 `output-formats.md`,不要假设不存在的资产。

## 领域执行要点

1. 固定模型、Prompt、知识/评测数据、产品和环境版本;建立 产品任务×语言×用户群×风险 切片,记录抽样来源及样本量,不以总体平均遮盖小群体。
2. 人工 rubric 为每个维度写可观察锚点、标签者、分歧处理和参考答案来源;先校准样本,再按项目评分与权重汇总,未定规则不自造分数。
3. 分开任务质量、安全/隐私、应拒答与正常可回答、降级/回退门槛;记录每门槛来源、分母和版本,拒答多不自动安全。
4. 切片缺样本或阈值时输出 UNKNOWN/待确认;上线建议保留未决门槛和 Human 决策,不能从静态方案得出已通过。
## 核心约束

- 不要只测理想输入
- 区分模型限制与产品集成缺陷
- 高风险输出必须设计拒答或人工兜底
- 不编造输入中不存在的系统行为、字段、数据、指标或根因。
- 关键结论必须关联证据;证据不足时标记为假设并给出验证方法。
- 优先级必须说明业务影响、发生可能性或可探测性依据。

## 交付前自检

- [ ] 已覆盖:任务质量、事实性、稳定性、安全性、公平性、隐私、延迟成本、降级与人工接管。
- [ ] 已区分事实、假设、缺口和建议。
- [ ] 高风险项有明确优先级、证据、负责人或下一步。
- [ ] 输出包含可验证的判断标准,而非泛泛而谈。
- [ ] 未执行未经授权的生产写操作或破坏性动作。

## 常见误区

- 只列检查点,不说明输入条件、预期结果或证据。
- 把所有事项都标为高优先级,失去取舍价值。
- 用工具名或通用理论替代领域判断。
- 输入不完整时直接拒绝,或反过来假装结论已经确定。

## 最佳实践

- 从最可能造成业务损失、安全问题或发布阻塞的路径开始。
- 用最小可验证实验缩小不确定性,并记录复现条件。
- 让输出能够被另一位工程师直接执行和复核。