第 10 章：PoC、Demo 与客户验证
本章目标
设计可验证的 PoC 和有说服力的 Demo。
概念讲解
PoC 是为了验证可行性，不是为了交付完整产品。
PoC 要定义：
- 范围。
- 数据。
- 成功标准。
- 时间。
- 交付物。
Demo 是为了让客户理解价值，不是展示所有功能。
业务案例
企业服务 PoC：
- 范围：解决 3 类常见订单咨询。
- 数据：20 条真实历史工单。
- 成功标准：自动解决率、正确率、人工接管率。
- 时间：2 周。
教育 Demo：
- 场景：学生上传一道错题。
- 展示：检索讲义、分步解释、引用来源。
- 风险：回答不确定时转教师。
技术对应关系
PoC 要复用技术项目中的：
- Mock LLM 或真实模型。
- 工具注册。
- 会话日志。
- 权限审批。
售前/产品视角
产品视角：
- PoC 用来验证需求假设。
售前视角：
- PoC 用来降低客户决策风险。
- Demo 用来建立信任。
示例模板
PoC 计划：
text
目标：
范围：
数据：
成功标准：
时间：
负责人：
风险：
验收方式：面试追问
问：PoC 和完整交付有什么区别？
回答要点：
- PoC 范围小、时间短。
- PoC 验证价值和可行性。
- 完整交付需要生产级安全、运维和监控。
问：Demo 如何避免过度承诺？
回答要点：
- 使用真实场景。
- 展示失败处理。
- 明确边界。
- 不隐藏人工接管。
问：PoC 成功但上线失败可能是什么原因？
回答要点：
- 数据质量变化。
- 权限和集成复杂。
- 真实流量规模。
- 缺少持续评估。
练习任务
为企业服务案例写 PoC 计划和 5 分钟 Demo 脚本。
本章产出
- 企业服务 PoC 计划。
- 企业服务 Demo 脚本。
验收标准
能清楚说明 PoC 的目标、步骤、成功标准和边界。