试验展开概述 Skill

使用场景

• 方向定界已完成，需要进入试验展开阶段
• 需要设计一套可验证、可比较、可放弃、可继承的实验体系
• 需要理解能力实验、产品实验、商业实验三层关系

核心概念

• 能力实验：验证某项 AI 能力在真实任务中是否成立
• 产品实验：验证用户是否愿意以某种交互或流程使用这项能力
• 商业实验：验证客户是否愿意为这类能力投入预算或试点资源
• 评估（Evaluation）：用样本、对照和失败案例判断能力是否成立

三层实验关系

能力实验（技术上限）
  → 产品实验（用户接受度）
    → 商业实验（价值密度）
      → 实验结论报告

能力实验是基础：先确认 AI 能力能否做到，再验证用户是否愿意用，最后验证客户是否愿意付费。

第一步：资料准备评估

试验前必须确认四类资料：

资料类型	内容	评估标准
外部资料	行业知识、公开规则、产品文档	覆盖度 > 80%
内部业务资料	SOP、历史工单、对话记录	代表性样本 > 200条
样本集	正例、负例、边界案例、长尾问题	边界案例 > 20%
评估标准（Rubric）	什么算对、什么算错、什么算可接受	已明确定义

资料不足时，应先补充资料，而非直接开始实验。

第二步：能力实验设计

原则：先用最强模型看能力上限，再压缩成本

1. 用最强模型（GPT-4o/Claude Opus）测试能力天花板
2. 确定能力上限足够高后，再用更便宜模型测试能否保住目标效果
3. 如果最强模型也无法达到可接受水平，应放弃或重新定义问题

能力实验要验证的问题

• AI 到底能做到什么深度
• 哪些场景能够稳定成立
• 哪些场景只能做到辅助，不能做到自动化
• 哪些场景即使技术可行，也没有足够高的价值密度

第三步：产品实验设计

验证用户是否愿意以某种交互或流程使用这项能力：

• 用户如何表达目标
• 系统如何展示状态和建议
• 用户如何纠偏或确认
• 任务完成率和满意度

第四步：商业实验设计

验证价值密度：

• 客户是否愿意付费试点
• 续期意愿如何
• 场景扩展可能性
• 与现有解决方案的成本对比

第五步：建立评估 Rubric

评估不是看主观感觉，必须量化：

• 准确率：正确输出 / 总输出
• 边界案例通过率：长尾问题中正确处理的比例
• 采纳率：用户接受 AI 建议的比例
• 效率提升：相比纯人工的时长缩短比例

输出物：试验展开总体方案

1. 资料准备清单：四类资料的覆盖度和缺口
2. 能力实验方案：实验批次、模型选择、成功标准
3. 产品实验方案：交互形式、验证指标
4. 商业实验方案：定价假设、试点设计
5. 评估 Rubric：定义明确的量化指标
6. 实验节奏：各层实验的时间安排

与其他 Skill 的关系

• 前置：@ai-native-direction-framing（提供 Direction Brief）
• 后置：@p2b-product-form-exploration、@p2c-process-redesign、@p2d-convergence-decision、@p2e-shadow-validation（覆盖5个子阶段）
• 协同：@ai-native-experiment-engine（整体包覆版，仍可独立使用）

示例

用户输入

"我们已完成方向定界，Direction Brief 是 AI 客服协同系统，需要设计试验展开方案"

Skill 执行

资料准备评估:
  已有: 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 时需深入理解：

• 实验即产品定义：试验展开不是技术团队先去"试试看"，而是产品、工程、领域团队共同定义产品边界的过程。很多真正重要的产品决策，都是在实验阶段做出来的，而不是在 PRD 阶段做出来的。
• 四要素框架（Data → Model → Method → Evaluation）：Data 决定实验贴近真实任务的程度；Model 决定能力上限、成本结构和推理特性；Method 决定用提示词、RAG、工作流、智能体还是组合；Evaluation 决定如何判断结果是否真正成立。缺少任何一项，实验都会变成不可复用的偶然成功。
• 先看能力上限再压缩成本：先用最强模型（如 GPT-4o / Claude Opus）验证问题有没有机会被解决；等任务定义、资料供给和评估方式基本稳定后，再测试更便宜、更快的模型。团队不会因为一开始就选了便宜模型而误判方向不可行。
• 资料供给是实验前提：真正决定实验质量的，往往是资料是否足够——包括外部资料（行业知识、法规、竞品材料）和内部业务资料（SOP、历史工单、规则说明、失败案例）。资料必须经过脱敏、权限分层、结构化和场景打包。
• 实验必须产出可继承结论：好的试验展开要输出：哪些任务已可做（含边界）、哪些暂时不能做（失败在哪）、哪些虽能做但价值密度不足、哪些值得进入产品化、哪些资料和评估条件必须保留到下一阶段。

分步执行指南

基于书稿方法论，本 Skill 的完整执行分为 6 步：

步骤 1：资料准备评估与缺口分析

• 盘点四类资料：外部资料、内部业务资料、样本集、评估标准
• 评估覆盖度：外部资料覆盖度 > 80%、内部资料代表性样本 > 200 条、边界案例 > 20%
• 资料预处理：脱敏（去除隐私和敏感字段）、权限分层（区分通用实验与受控环境）、结构化（转为可检索可对比材料）、场景打包（按任务场景整理成实验包）
• 资料不足时必须先补充，而非直接开始实验

步骤 2：能力实验设计与执行

• 原则：先用最强模型看能力天花板，再压缩成本
• 第 1 批：用最强模型测试核心场景（目标 > 85% 准确率）
• 第 2 批：边界案例测试（目标 > 70% 通过率）
• 第 3 批：成本压缩测试（换更便宜模型，看能否保住目标准确率）
• 记录每个场景的能力上限、稳定性和失败模式

步骤 3：产品实验设计与执行

• 设计用户如何进入能力入口（问答 / Copilot / 工作台 / 自动流程 / Agent）
• 设计系统如何展示状态和建议
• 设计用户纠偏和确认机制
• 在真实工作流中测试，记录任务完成率、采纳率和满意度

步骤 4：商业实验设计与执行

• 设计试点方案（至少 2 个部门 / 3 个月）
• 定义价值锚点（首响时间缩短、培训周期缩短、人力成本降低）
• 收集续期意愿和场景扩展可能性
• 与现有解决方案做成本对比

步骤 5：建立量化评估 Rubric

• 定义准确率、边界案例通过率、采纳率、效率提升等指标
• 定义什么算对、什么算错、什么算可接受
• 建立对照组和失败案例库
• 确保评估标准可复现、可比较

步骤 6：汇总试验展开总体方案

• 整理资料准备清单（覆盖度和缺口）
• 整理能力 / 产品 / 商业三类实验方案
• 制定实验节奏（各层实验时间安排）
• 输出试验展开总体方案文档
• 判断是否满足进入下一阶段的闸门条件

示例一：AI 客服协同系统完整试验方案

用户输入

"我们已完成方向定界，Direction Brief 是 AI 客服协同系统，目标是缩短客服首响时间和培训周期。目前有 FAQ 500 条、工单样本 1000 条、物流规则文档。需要设计完整试验展开方案。"

Skill 执行

资料准备评估:
  已有资料:
    - 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%）
  - ✅ 资料供给足够、可控、可复现
  - ✅ 失败边界已初步识别
  - ✅ 用户使用方式和价值信号开始出现

示例二：AI 运维故障分析系统试验方案（对比案例）

用户输入

"方向定界已完成，Direction Brief 是 AI 运维故障分析系统，帮助运维工程师更快理解告警和定位根因。目前有历史告警日志 5000 条、处理记录 800 条、基础设施架构文档。需要设计试验方案。"

Skill 执行

资料准备评估:
  已有资料:
    - 历史告警日志: 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%（真实工单验证）
  - ⚠️ 若准确率不稳定，延长影子验证而非直接工程化