AI 功能测试看的是用户实际接触到的产品功能，而不只是模型回答。它要一起检查质量、安全、隐私、公平性、降级和反馈流程，帮助区分模型限制、产品集成缺陷与用户体验问题。
固定产品与评测上下文
记录功能目标、模型或服务配置、产品版本、环境、用户群、输入输出样本，以及业务和安全约束。按产品任务、语言、用户群和风险拆分覆盖，并保留样本来源与数量，避免总体平均掩盖未覆盖或体验较差的群体。
| 检查面 | 测试计划需要回答的问题 |
|---|---|
| 任务质量 | 功能是否解决用户任务？正确性和实用性如何判断？ |
| 安全与隐私 | 哪些输出必须拒绝、脱敏或转交人工？哪些信息可以保留？ |
| 公平性 | 哪些用户或语言需要单独检查？样本是否足够且来源清楚？ |
| 降级 | 模型不可用、不确定或被阻断时，用户会看到什么？ |
| 反馈 | 用户能否报告问题？团队能否把反馈关联到版本和证据？ |
让评分标准与上线门槛可观察
每个评分维度都写清可观察的判定锚点、标注人、分歧处理方式和参考答案来源。先用样例校准，再应用项目制定的分数和权重；没有来源的阈值不要自行编造。
把任务质量、安全与隐私、必须拒答的请求、正常可回答的对照组以及降级门槛分开。拒答率更高不代表一定更安全。如果某个切片缺少样本，或上线门槛没有来源，就标记为 UNKNOWN 或待确认。静态计划只能提出检查，不能证明实际运行通过或功能可以上线。
以一个推荐面板为说明性例子：要同时检查模型建议、页面呈现、展示给用户的解释和人工兜底。正常路径与降级路径都要验证，并将确切的功能和模型版本与结果一起保存。
报告用户影响和未决风险
交付内容可以包括测试数据集、风险场景、评分规则、各切片结果、上线门槛、监控建议、阻塞项和下一步负责人。每个场景写清前置条件、步骤、预期行为与证据。保留未知项和人工决策，不要把它们压成一个总分。
Agent 规划与运行轨迹见AI 智能体测试；模型评估细节见LLM 测试；输入攻击与安全边界见提示注入测试和安全测试。
安装命令：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/ai-feature-testing -g