// AI Native 产品方法论——试验展开概述的实操 Skill。 用户提供 Direction Brief，Skill 自动执行试验展开框架设计： 资料准备评估 → 三层实验体系设计 → 评估Rubric建立 → 实验节奏规划 → 输出试验展开总体方案。 基于《AI Native 产品方法论》第06章（试验展开-概述）。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | p2a-experiment-overview |
| description | AI Native 产品方法论——试验展开概述的实操 Skill。 用户提供 Direction Brief，Skill 自动执行试验展开框架设计： 资料准备评估 → 三层实验体系设计 → 评估Rubric建立 → 实验节奏规划 → 输出试验展开总体方案。 基于《AI Native 产品方法论》第06章（试验展开-概述）。 |
| tags | ["ai-product","methodology","experiment","evaluation","book-skill"] |
| author | Max |
| source_book | AI Native 产品方法论 |
| source_chapter | 第06章 试验展开-概述 |
| version | 1 |
| stage | p2a |
| homepage | https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p2a-experiment-overview |
能力实验（技术上限）
→ 产品实验（用户接受度）
→ 商业实验（价值密度）
→ 实验结论报告
能力实验是基础：先确认 AI 能力能否做到，再验证用户是否愿意用，最后验证客户是否愿意付费。
试验前必须确认四类资料：
| 资料类型 | 内容 | 评估标准 |
|---|---|---|
| 外部资料 | 行业知识、公开规则、产品文档 | 覆盖度 > 80% |
| 内部业务资料 | SOP、历史工单、对话记录 | 代表性样本 > 200条 |
| 样本集 | 正例、负例、边界案例、长尾问题 | 边界案例 > 20% |
| 评估标准（Rubric） | 什么算对、什么算错、什么算可接受 | 已明确定义 |
资料不足时，应先补充资料，而非直接开始实验。
原则：先用最强模型看能力上限，再压缩成本
验证用户是否愿意以某种交互或流程使用这项能力：
验证价值密度：
评估不是看主观感觉，必须量化：
"我们已完成方向定界，Direction Brief 是 AI 客服协同系统，需要设计试验展开方案"
资料准备评估:
已有: FAQ(500条)、工单样本(1000条)、物流规则文档
缺口: 边界案例(仅8%)、情绪问题样本(缺失)
建议: 补充100条边界案例和50条情绪问题样本后再开始实验
能力实验方案:
第1批: GPT-4o 测试订单查询/物流解释/售后政策（目标>85%准确率）
第2批: 边界案例测试（目标>70%通过率）
第3批: 压缩成本测试（GPT-4o-mini，目标保住85%效果）
产品实验方案:
形式: Copilot 影子模式（建议+人工确认）
指标: 采纳率>60%、满意度>80分
商业实验方案:
试点设计: 2个部门3个月试点
定价锚: 首响时间缩短X分钟，培训周期缩短Y天
实验节奏:
第1-2周: 补充资料
第3-4周: 能力实验
第5-6周: 产品实验
第7周: 商业验证
第8周: 汇总实验结论报告
基于书稿第06章，以下概念在执行本 Skill 时需深入理解：
基于书稿方法论，本 Skill 的完整执行分为 6 步：
"我们已完成方向定界，Direction Brief 是 AI 客服协同系统，目标是缩短客服首响时间和培训周期。目前有 FAQ 500 条、工单样本 1000 条、物流规则文档。需要设计完整试验展开方案。"
资料准备评估:
已有资料:
- FAQ: 500条（覆盖度约 65%）
- 工单样本: 1000条（含订单查询、物流咨询、售后申请）
- 物流规则文档: 完整
缺口分析:
- 边界案例: 仅占 8%，需补充至 20%+（目标 100 条）
- 情绪问题样本: 完全缺失（需 50 条）
- 售后政策文档: 过时版本，需更新
- 评估标准（Rubric）: 未定义
资料预处理:
脱敏: 移除客户姓名、手机号、订单号后四位
权限分层: 售后赔付类仅在受控环境使用
结构化: 工单按场景分类打包（查询/物流/售后/投诉）
场景打包: 每个场景含正例10条、负例5条、边界5条
能力实验方案:
第1批（第3周）: GPT-4o 测试
场景: 订单查询、物流解释、售后政策
样本: 每场景 50 条
目标: 准确率 > 85%
第2批（第4周）: 边界案例测试
场景: 多轮上下文、跨场景切换、模糊表述
样本: 100 条边界案例
目标: 通过率 > 70%
第3批（第4周）: 成本压缩测试
模型: GPT-4o-mini
目标: 保住 85% 效果，成本降低 50%+
产品实验方案:
形态: Copilot（侧边栏建议 + 人工确认）
交互原型:
入口: 工单进入时自动触发
输出: 候选回复 + 风险标记 + 规则引用
反馈: 一键采纳 / 快速编辑 / 标记不准确
降级: 高风险场景强制人工
验证指标:
采纳率目标 > 60%
满意度目标 > 80 分
首响时间缩短目标 > 40%
商业实验方案:
试点设计: 2 个部门 × 3 个月
价值锚点:
- 首响时间: 从 X 分钟缩短到 Y 分钟
- 培训周期: 从 X 天缩短到 Y 天
- 人力成本: 减少 Z 名初级客服
续期意愿: 试点结束后问卷收集
评估 Rubric:
准确率: 正确输出 / 总输出
边界案例通过率: 长尾问题中正确处理的比例
采纳率: 客服接受 AI 建议的比例
效率提升: 相比纯人工的时长缩短比例
风险漏过率: 高风险场景中 AI 未标记的比例（目标 < 5%）
实验节奏:
第1-2周: 资料补充（边界案例、情绪样本、更新售后文档、建立 Rubric）
第3周: 能力实验第1批
第4周: 能力实验第2、3批
第5-6周: 产品实验
第7周: 商业验证
第8周: 汇总实验结论报告，判断是否进入下一阶段
进入下一阶段闸门:
- ✅ 能力在关键场景稳定成立（准确率 > 85%）
- ✅ 资料供给足够、可控、可复现
- ✅ 失败边界已初步识别
- ✅ 用户使用方式和价值信号开始出现
"方向定界已完成，Direction Brief 是 AI 运维故障分析系统，帮助运维工程师更快理解告警和定位根因。目前有历史告警日志 5000 条、处理记录 800 条、基础设施架构文档。需要设计试验方案。"
资料准备评估:
已有资料:
- 历史告警日志: 5000 条（覆盖主要告警类型）
- 处理记录: 800 条（含根因和处理步骤）
- 基础设施架构文档: 完整
缺口分析:
- 复合故障样本: 仅 3%（需补充至 15%+）
- 跨系统关联案例: 缺失（需 50 条）
- 误报告警样本: 不足（需补充 100 条）
- 评估标准: 未定义
资料预处理:
脱敏: 移除 IP 地址、域名、内部服务名称（替换为代号）
权限分层: 生产环境日志仅在受控环境使用
结构化: 按故障类型打包（基础设施/应用/网络/安全）
场景打包: 每场景含正常案例、边界案例、复合故障
能力实验方案:
第1批（第3周）: 单一故障根因分析
模型: Claude Opus
场景: CPU 异常、内存泄漏、磁盘满、网络超时
样本: 每场景 30 条
目标: 根因识别准确率 > 80%
第2批（第4周）: 复合故障与跨系统关联
样本: 80 条复合故障
目标: 能正确识别至少一个根因 > 60%
第3批（第4周）: 成本压缩
模型: Claude Sonnet
目标: 保住 80% 效果，延迟 < 5 秒
产品实验方案:
形态: 工作台（告警面板 + 根因分析面板 + 建议处理步骤）
交互原型:
入口: 告警触发时自动展示分析面板
输出: 疑似根因列表 + 置信度 + 关联日志 + 建议操作
反馈: 确认根因 / 标记不准确 / 补充信息
降级: 低置信度时提示"建议人工排查"
验证指标:
采纳率目标 > 50%（运维场景保守）
平均排障时间缩短目标 > 30%
满意度目标 > 75 分
商业实验方案:
试点设计: 1 个运维团队 × 2 个月（运维团队更谨慎）
价值锚点:
- 平均排障时间（MTTR）: 缩短 X%
- 误处理率: 降低 Y%
- 运维人力: 高峰期减少 Z 人值守
风险: 运维场景出错代价高，需严格限制自动化范围
评估 Rubric:
根因识别准确率: Top-3 命中率
关联分析准确率: 跨系统关联是否正确
建议操作采纳率: 运维人员接受建议的比例
MTTR 缩短比例: 相比纯人工排障的时间缩短
误报过滤率: AI 正确识别误报告警的比例
实验节奏:
第1-2周: 资料补充（复合故障、跨系统案例、误报样本）
第3周: 能力实验第1批
第4周: 能力实验第2、3批
第5-6周: 产品实验
第7周: 商业验证
第8周: 汇总结论
进入下一阶段闸门:
- ✅ 单一故障根因识别准确率 > 80%
- ✅ 复合故障至少识别一个根因 > 60%
- ✅ 运维人员采纳率 > 50%
- ✅ MTTR 缩短 > 30%（真实工单验证）
- ⚠️ 若准确率不稳定，延长影子验证而非直接工程化