POC（Proof of Concept，概念验证）= 用最低成本验证"模型能不能做这件事"。本指南把 POC验证 四步法、Badcase分析方法论、效果评测体系 的相关部分组合成一套可直接执行的 7-10 天 POC 流程。
适用场景
| 适合 | 不适合 |
|---|---|
| 新方向立项前，需要验证模型可行性 | 已知模型可行，要验证用户买不买账 → 用 MVP验证 |
| 关键 AI 功能 PRD 前的技术摸底 | 微调式改进、A/B 测试 → 直接走 灰度发布 |
| 大成本投入前的低成本筛子 | 完全无技术风险的纯前端改造 |
核心原则：POC 不通过就换方向，不是"再调调看"。
步骤总览
| 步骤 | 名称 | 核心问题 | 主要产出 | 负责人 / 时长 |
|---|---|---|---|---|
| 1 | 定标准 | 什么算成功？ | 三大维度通过线 | PM 主导 / 0.5 天 |
| 2 | 出考题 | 用什么样本来验？ | 评测集（常规题 + 陷阱题） | PM 主导 / 2 天 |
| 3 | 搭原型 | 用最低成本跑通 | 一个能跑的脚本 | 技术主导 / 3 天 |
| 4 | 看结果 | 通过了吗？错在哪？ | 通过/不通过结论 + Badcase 分析 | 技术 + PM / 2 天 |
总时长约 7-10 天。
前置准备
- 业务目标已明确（这个方向解决什么用户问题、为什么必须用 AI）
- 大致候选模型已知（不知道用什么模型先做 模型选型方法论 的第一二步）
- 业务方对接人已对齐（出题、评分要业务方背书）
第一步：定标准
三类可行性必须同时通过
| 类别 | 含义 | 不通过怎么办 |
|---|---|---|
| 效果可行性 | 模型在目标任务上准确率、生成质量是否达到可用水平 | 换模型、换方法 |
| 工程可行性 | 延迟、并发、成本是否可承受 | 重新评估场景或换更轻量模型 |
| 价值可行性 | 相比现有方案（人工/规则）是否有显著提升 | 砍方向 |
通过线模板
填表（数值替换为你的业务实际）：
| 维度 | 通过线 | 业务理由（必须填） |
| 准确率 | ≥ ____% | ____________________ |
| 速度 | ≤ ____ 秒 | ____________________ |
| 单次成本 | < ¥____ | ____________________ |
| 价值维度 | □提效 □降本 □增收 □其他 | ____________________ |
PM 三大坑（必读）
- 标准越高越好 → 准确率 99%？人工才 95%，要求 AI 更高就是流氓。标准 = 业务能接受的最低线
- 只定效果，不定成本速度 → 准确率 99% 但要 30 秒、5 块钱一次，照样没法上线
- 标准定得模糊 → "效果还不错就行" → POC 变成无限延期的调参游戏
检查项
- 三类可行性都有量化通过线
- 每个数字配业务理由（不是拍脑袋）
- 业务方对通过线已书面同意
第二步：出考题（评测集）
评测集要求
- 总量：100 条左右（POC 阶段够用，正式产品再扩到 1000+）
- 分布：常规题 80% + 陷阱题 20%（陷阱题决定上限）
- 标注：每条都要有"正确答案"，由业务方人工标注
- 锁版本：评测集 v1 一旦定下，跑多模型对比时不能动
评测集设计表
| 题号 | 题目类型 | 输入 | 业务方标注的正确答案 | 难度（常规/陷阱） | 测试目的（你想看模型能不能做对什么）|
| 001 | ... | ... | ... | 常规 | ... |
| ... |
陷阱题怎么造
| 陷阱类型 | 例子 |
|---|---|
| 边界情况 | 输入超长、特殊符号、空输入 |
| 易混淆 | 看起来像 A 类但实际是 B 类的样本 |
| 多模态噪声 | 光线差、角度偏、有遮挡的图片 |
| 业务特殊规则 | 行业术语、内部规范、领导特别要求 |
| 一致性测试 | 同一问题问 5 次，看回答是否稳定 |
检查项
- 100 条左右样本，80/20 常规/陷阱
- 业务方已逐条标注正确答案
- 评测集已存档锁版本
- 至少 5 类陷阱题已覆盖
第三步：搭原型
POC 阶段「不做」清单
| 不做 | 理由 |
|---|---|
| 精美 UI | 浪费时间，POC 不给用户看 |
| 登录注册、支付 | 验证模型与商业逻辑无关 |
| 订单后台、数据看板 | POC 不上生产 |
| 异常处理、重试逻辑 | 数据跑通就行 |
| 版本管理、CI/CD | 一次性脚本 |
POC 阶段「只做」清单
一个 Python 脚本 → 读输入 → 调 API → 让 AI 回答 → 把答案存表格
输出格式（结果表）
技术同学给出的 POC 输出至少长这样：
| 题号 | 输入 | 模型A输出 | 模型A是否正确 | 模型A延迟(s) | 模型A单次成本 | 模型B输出 | ... |
| 001 | ... | ... | ✓/✗ | ... | ... | ... | ... |
每个候选模型一列，最后能直接做对比。
检查项
- 脚本能跑通全量评测集
- 输出包含：模型答案、是否正确、延迟、单次成本
- 至少 2 个候选模型可对比（若 POC 同时也在选型）
第四步：看结果
三大指标对比
| 维度 | 通过线 | 模型A实际 | 模型B实际 | 结论 |
| 准确率 | ≥ 90% | 88% | 92% | A 不通过 / B 通过 |
| P95 延迟 | ≤ 3 秒 | 2.5s | 4.1s | A 通过 / B 不通过 |
| 单次成本 | < ¥0.10 | ¥0.08 | ¥0.15 | A 通过 / B 不通过 |
Badcase 分析（关键环节）
跑测 100 张错了 13 条 → 不要急着说"POC 失败"，这 13 条是金矿。
按 Badcase分析方法论 三步走：
步骤 A：分类
| 错误 case | 可复现? | 错误类型 | 输入特征共性 | 题目类型 |
| 001 | 是 | 答反 | 光线暗 | 常规 |
| 023 | 偶发 | 模糊 | - | 陷阱 |
| ... |
步骤 B：归因
| 根本原因 | 占比 | 典型症状 |
|---|---|---|
| Prompt 没说清楚 | ____% | 边界情况 AI 自己猜 |
| 模型能力不够 | ____% | 模型天然处理不了该类任务 |
| 评测集/标注有问题 | ____% | "正确答案"本身标错 |
| 任务定义有歧义 | ____% | 人工审核也会分歧 |
步骤 C：决策
- 如果归因主要是 Prompt 问题 → 改 Prompt 再跑一次（每次只动一个变量）
- 如果归因主要是模型能力 → 换模型重跑
- 如果归因主要是标注错 → 修正评测集
- 如果任务定义模糊 → 回到第一步重定标准
- 如果改了也救不回来 → 砍方向，承认 POC 失败
POC 结论模板
## POC 结论：[方向名称]
### 通过状态
□ 通过 → 推进 MVP
□ 部分通过 → 修订后再跑一轮
□ 不通过 → 砍方向 / 换技术路线
### 关键数据
- 准确率：____%（通过线 ____%）
- P95 延迟：____秒（通过线 ____秒）
- 单次成本：¥____（通过线 ¥____）
- 推荐模型：____
### Badcase 主因
1. ____ （占比 __%）
2. ____ （占比 __%）
### 下一步行动
- 责任人：____
- 时间：____
- 行动项：____
检查项
- 三大指标已对照通过线得出结论
- Badcase 已分类归因
- 决策清晰（推进/重跑/砍方向）
- POC 结论已交付业务方
常见坑
| 坑 | 后果 | 规避 |
|---|---|---|
| 跳过定标准直接搭原型 | 跑完不知道算成功还是失败 | 第一步是必做项，无标准不开工 |
| 评测集只有正例 | 上线后陷阱场景翻车 | 陷阱题必须占 20% |
| 看到一两条错就改 Prompt | 数据被污染，迭代失控 | 攒够 Badcase 再分析 |
| POC 通过线和 MVP 标准混了 | POC 看到 70% 就说不行，错杀方向 | POC 看可行性最低线，MVP 才看用户满意度 |
| POC 失败硬撑"再调调看" | 沉没成本叠加 | 归因到模型能力天然不够时，敢于砍方向 |
完成检查清单
POC 开工前：
- 三类可行性都有量化通过线
- 业务方对通过线书面签字
- 评测集 100 条左右，常规 80% + 陷阱 20%
- 每条评测集都有正确答案
POC 结束时：
- 三大指标对照通过线
- Badcase 已分类归因
- 通过/不通过结论明确
- 下一步行动有责任人和时间
相关概念
→ POC验证（四步法详解） → Badcase分析方法论（第四步看结果的归因方法） → 效果评测体系（评测集设计原则） → 模型选型方法论（POC 与选型联动） → 模型选型五维度（候选模型评估维度） → MVP验证（POC 通过后的下一步） → 数据准备五环节（评测集是数据准备的一种）