菜单
当用户需要设计 LLM 评测方案、构建测试集、进行模型质量保障时使用此技能。触发关键词：LLM 测试、模型评测、提示词工程、回归测试、红队测试、幻觉检测、RAG 测试、Agent 测试、A/B 测试、LLM-as-a-Judge。适用于模型开发和应用落地的质量保障场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Weekly Focus Engineering analysis using ActivityWatch data. Use when analyzing app usage patterns, detecting context switching problems, identifying "death loops" (repetitive app switching), calculating focus scores, or creating weekly productivity reviews.
WCAG 2.2 AA conformance auditor. Systematically verifies success criteria through automated, interactive, and manual testing methods.
Implement features from spec documents (context/doc required)
PR review for bugs, security & quality (requires PR URL)
Brutally honest roasts of your code with fixes
Accessibility improvement planning support. Generates organizational maturity assessment, phased roadmap, KPI design, and stakeholder persuasion materials.
| name | llm-testing-expert |
| description | 当用户需要设计 LLM 评测方案、构建测试集、进行模型质量保障时使用此技能。触发关键词：LLM 测试、模型评测、提示词工程、回归测试、红队测试、幻觉检测、RAG 测试、Agent 测试、A/B 测试、LLM-as-a-Judge。适用于模型开发和应用落地的质量保障场景。 |
提供 LLM 测试方案设计、测试集构建、自动化评估和安全红队测试建议，确保模型在功能、性能、鲁棒性和安全性上满足生产要求。
{
testTarget: {
type: string // 测试对象类型(base-model/fine-tuned-model/rag-system/agent/prompt-template)
modelInfo?: {
name: string // 模型名称(如 gpt-4, claude-3.5-sonnet)
version?: string // 版本号
deployment?: string // 部署方式(API/self-hosted)
}
applicationContext?: string // 应用场景(如客服问答、代码生成、文档摘要)
}
testObjectives: {
functional?: boolean // 功能正确性测试
performance?: boolean // 性能测试(延迟、吞吐、成本)
robustness?: boolean // 鲁棒性测试(对抗样本、边界用例)
safety?: boolean // 安全性测试(越狱、注入、PII泄露)
userExperience?: boolean // 用户体验测试
}
constraints: {
budget?: string // 测试预算(API调用成本/人工标注成本)
timeline?: string // 测试周期
existingTestAssets?: string[] // 现有测试资产(测试集、标注数据)
complianceRequirements?: string // 合规要求(GDPR、行业监管)
}
riskAreas?: string[] // 已知风险点(如幻觉、偏见、隐私泄露)
existingMetrics?: string // 现有评估指标和基线
}
{
testStrategy: {
scope: string // 测试范围定义
approach: string // 测试方法(黑盒/白盒/灰盒)
testLevels: {
unit?: string // 单元测试(单个Prompt/单个工具调用)
integration?: string // 集成测试(多轮对话/工具链)
system?: string // 系统测试(端到端场景)
acceptance?: string // 验收测试(用户场景覆盖)
}
}
testPlan: {
functional: {
testCases: {
id: string
scenario: string // 测试场景
input: string // 输入样例
expectedOutput: string // 期望输出(可用模糊规则)
passCriteria: string // 通过标准
}[]
coverage: string[] // 覆盖维度(指令遵循/格式输出/推理能力等)
}
performance: {
metrics: {
name: string // 指标名称(latency/throughput/token-cost)
target: string // 目标值(如 p95 < 2s)
measurement: string // 测量方法
}[]
loadProfile: string // 负载模型(并发用户数、请求模式)
}
robustness: {
adversarialCases: string[] // 对抗样本设计
edgeCases: string[] // 边界用例
stressScenarios: string[] // 压力场景(超长输入、极端参数)
}
safety: {
redTeamScenarios: {
type: string // 攻击类型(jailbreak/injection/data-extraction)
technique: string // 攻击技术
expectedDefense: string // 期望防御措施
}[]
harmfulContentCategories: string[] // 有害内容类别(暴力/歧视/隐私)
}
}
testDataset: {
sources: string[] // 数据来源(公开基准/领域数据/合成数据)
composition: {
positive: number // 正向用例占比
negative: number // 负向/对抗用例占比
edge: number // 边界用例占比
}
sampleSize: string // 样本量(按统计显著性计算)
labelingStrategy: string // 标注策略(人工/自动/混合)
}
evaluationMethod: {
automated: {
metrics: string[] // 自动化指标(BLEU/ROUGE/exact-match/regex)
tools: string[] // 评估工具
}
humanEval: {
criteria: string[] // 人工评估标准
raterGuidelines: string // 标注员指南
interRaterAgreement: string // 一致性要求(如 Kappa > 0.7)
}
llmAsJudge?: {
judgeModel: string // 评判模型
rubric: string // 评分规则
calibration: string // 校准方法(与人工标注对齐)
}
}
regressionPlan: {
triggerConditions: string[] // 触发回归的条件(模型更新/Prompt变更)
baselineVersion: string // 基线版本
comparisonMetrics: string[] // 对比指标
reportFormat: string // 报告格式
}
cicdIntegration?: string // CI/CD 集成方案
specializedTests?: {
rag?: {
retrievalQuality: string // 检索质量测试(召回率/排序)
citationAccuracy: string // 引用准确性测试
faithfulness: string // 忠实度测试(是否仅基于检索内容)
}
agent?: {
toolCallCorrectness: string // 工具调用参数正确性
planningRationality: string // 规划合理性
errorRecovery: string // 错误恢复能力
}
}
}
在开始执行前，复制以下清单，并在每一步完成后显式标记状态。
反馈闭环: 若测试目标不明确或冲突(如既要全面覆盖又要极低成本)，必须与用户对齐优先级。
测试金字塔原则:
反馈闭环: 若用户预算或时间极其有限，优先设计高优先级的冒烟测试集，而非追求全面覆盖。
用例设计原则:
反馈闭环: 若现有测试资产不足，优先从生产日志中采样真实用例，而非完全合成数据。
评估方式选择:
反馈闭环: 若自动化指标与人工评估不一致，必须重新校准或调整指标权重。
反馈闭环: 若 RAG/Agent 测试暴露系统性问题(如检索质量差、工具调用失败率高)，应返回系统设计层面优化，而非仅调整测试。
回归测试原则:
反馈闭环: 若回归测试发现性能退化，必须分析根因(模型问题/Prompt 问题/测试集问题)，而非直接回滚。
红队测试方法:
反馈闭环: 若红队测试发现严重漏洞，必须优先修复并重新测试，而非掩盖或忽略。