大模型能力很强，但不够稳定。同一个问题换种问法，答案可能就不一样；输入里加一些诱导，输出可能就偏离预期。要把 Skill 真正用到生产环境，必须建立一套评测体系，用数据和规则来证明它是可靠的。
功能评测：Skill 是否完成了任务
功能评测关注的是「输入 → Skill → 输出」的正确性。评测指标包括：任务完成率、输出格式合规率、关键信息准确率、用户问题理解率。
建立功能评测需要准备三类测试数据：正常 case（典型用户问题）、边界 case（极端但合法的输入）、对抗 case（试图诱导 Skill 出错的输入）。建议从真实业务日志中抽样，而不是凭空编造。
| 评测类型 | 关注点 | 示例指标 |
|---|---|---|
| 正常 case | 典型场景下的表现 | 任务完成率、关键信息准确率 |
| 边界 case | 极端输入的处理 | 是否拒绝越界请求、是否给出合理提示 |
| 对抗 case | 安全与稳定性 | 是否被诱导泄露信息、是否生成有害内容 |
功能评测最好自动化，每次更新提示词或知识库后都能快速跑一遍，防止回归。
安全评测：防止越权和泄露
安全评测是 Skill 上线前的必修课。需要验证：Skill 是否会越权访问数据？是否会泄露敏感信息？是否会被提示注入攻击？是否在输出中包含歧视、违法或有害内容？
常见的安全措施包括：输入过滤（识别并拦截敏感指令）、权限校验（根据用户身份决定可调用的 Skill 和数据范围）、输出审查（对生成内容进行敏感信息检测）、审计日志（记录所有调用和输出以备追溯）。
性能评测：响应与并发
性能评测关注的是 Skill 在实际使用中的体验。核心指标包括：平均响应时间、P99 响应时间、并发承载能力、错误率、资源消耗。
性能问题往往在 demo 阶段被忽略，但在生产环境会直接影响用户满意度。建议在上线前做压测，并设置超时、降级、限流等保护机制。
一个成熟的 Skill 团队会把 40% 的评测精力放在功能、30% 放在安全、30% 放在性能，三者缺一不可。
常见问题
Skill 评测为什么要分三个维度？
因为大模型的不确定性同时影响功能正确性、安全合规性和服务性能，单一维度无法保证生产可用。
评测数据从哪里来？
优先从真实业务日志、客服记录、用户反馈中抽样，再补充边界 case 和对抗 case。
Skill 更新后需要重新评测吗？
需要。每次提示词、知识库、接口变更都可能影响输出，建议把自动评测加入 CI 流程。
