POC验证

POC = Proof of Concept，概念验证。是对某个想法或方法的初步实现，以证明其可行性。

在 AI 产品中，POC 的核心目的是用最低成本验证"模型能不能做这件事"——如果 POC 不通过，立即换方向。

步骤总览

三类可行性

POC 不是只看效果，要同时回答三类可行性：

• 效果可行性：模型在目标任务上的实际表现如何？准确率、召回率、生成质量是否达到可用水平？
• 工程可行性：延迟、并发、成本是否可承受？（一个调用要 15 秒、单次成本 5 块钱的方案，再好也没法上线）
• 价值可行性：即使技术跑通了，相比现有方案是否有显著提升？（AI 准确率 85%，人工 95%，且替代成本不低，则 POC 失败）

第一步：定标准

先定好"什么算成功"，标准必须是业务目标、用户体验和商业成本的平衡点：

PM 三大坑：

• 坑 1：标准越高越好 → 准确率 99%？人工才 95%，要求 AI 更高就是流氓
• 坑 2：只定效果指标，不定成本和速度 → 准确率 99% 但要 30 秒、5 块钱一次，照样没法上线
• 坑 3：标准定得模糊 → "效果还不错就行" → 整个 POC 变成无限延期的调参游戏

第二步：出考题

准备评测集，正确做法是拍真实照片 + 让业务人员标注答案（不能拿 2-3 张照片说"AI 很厉害"）。

评测集分布：常规题 80% + 陷阱题 20%（陷阱题是质量上限的关键）。

第三步：搭原型

POC 阶段不做：精美 UI、登录注册、支付集成、订单后台、数据看板。

POC 阶段只做：一个 Python 脚本 → 读图片 → 调 API → 让 AI 回答 → 把答案打印/存表格。

"够用就行"原则：不做 UI、不做工程优化、不做异常处理、不做版本管理。

第四步：看结果

跑测 100 张，三大指标对比达标线。

关键认知：别因为一两个 badcase 就急着判"POC 失败"，先去归因那些错的 case——它们才是金矿。系统性归因方法见 Badcase分析方法论。

PM 此阶段职责

1. 定标准：把业务目标翻译成可量化的三大维度通过线，警惕"标准越高越好"
2. 造评测集：拉真实样本、组织业务方标注、设计陷阱题
3. 看结果：不是看通过/不通过，而是从 Badcase 里挖系统性问题，决定下一步是改 Prompt、换模型、还是放弃方向
4. 决策放行：POC 通过才进入 MVP验证；POC 失败要敢于砍方向，避免沉没成本

协作对象：算法工程师（搭原型）、业务方/标注员（出考题）、技术负责人（看结果）

相关页面

→ POC验证操作指南（执行版） → MVP验证 → 效果评测体系 → Badcase分析方法论 → 模型选型方法论 → 数据准备五环节 → AIPM课程 Day2