POC（概念验证）的目的不是证明技术可行，而是用最短时间回答一件事：这个项目值不值得继续投。能真正推动决策的 POC 契约，通常写清了 7 个要素——场景边界、验收指标、数据权限、时间盒、双方投入、失败判据、下一步触发条件。缺了任何一项，POC 都会退化成一场演示。
为什么大多数 AI 项目停在 POC
项目卡在 POC 阶段，原因通常不在模型能力，而在三件没提前说清楚的事：
- 验收标准写的是功能而不是指标。「做一个质检功能」做完了，但没人定义漏检率要降到多少——于是既不能说成功，也不能说失败。
- 数据权限没提前谈。POC 阶段才发现要用的数据拿不到、或者需要先走三个月的合规流程。
- 没人负责推广上线。系统跑通了但没有人在业务侧推动使用，最终变成一个没人打开的页面。
POC 契约的 7 个要素
| 要素 | 要写清什么 | 常见坑 |
|---|---|---|
| 场景边界 | 只做一个具体场景、一条具体流程，不写「全厂智能化」 | 范围太大，两周做不出任何可判断的东西 |
| 验收指标 | 基线值、目标值、统计口径、统计周期、数据来源，五项齐全 | 只有目标值没有基线，事后无法判断改善幅度 |
| 数据权限 | 哪些数据可用、谁批、多久能拿到、脱敏要求 | 临开工才发现数据要跨部门审批 |
| 时间盒 | 2–4 周，到点必须出结论 | 无限期延长，POC 变成小项目 |
| 双方投入 | 业务方出谁、每周投入多少、交付方出谁 | 只有交付方在推进，业务方全程旁观 |
| 失败判据 | 什么情况下判定不值得继续 | 没有判据，谁都不敢说停 |
| 下一步触发条件 | 验收通过后怎么扩到全量、谁签字 | POC 成功但没人负责下一步预算 |
这 7 项里最常被漏掉的是「失败判据」。没有它，POC 就没有退出机制，项目会以「再优化一下」的形态无限延期。
验收指标怎么写才不会扯皮
一个能用来验收的业务指标必须写全五项：基线值（现在是多少）、目标值（要改善到多少）、统计口径（怎么算）、统计周期（取哪段数据）、数据来源（系统还是人工台账）。举例：
- 漏检率：基线 3.2%（2026 年 Q2 人工抽检台账），目标 ≤1%，口径为「抽检批次中漏检件数 / 总件数」，按月统计。
- 响应时长：基线 4 小时（工单系统记录），目标 ≤30 分钟，口径为「从告警产生到首次人工处理的时间中位数」。
- 人效：基线每人每天处理 45 单，目标 ≥70 单，口径取自业务系统导出，排除测试单。
把口径写进契约，项目结束时就不用争论「到底算不算达成」。这也是 FDE 模式与传统外包最实质的差别：验收单上写的是这类数字，不是功能清单的打勾。
从 POC 走到全员使用的五步
- 描述问题：不用写需求文档，说清楚现在怎么干、卡在哪就行。
- 初步判断：交付方给出能不能做、大概怎么做、多少成本的初步判断。
- 免费现场诊断：FDE 到现场看真实流程，输出诊断结论与可行路径。
- 小步 POC 验证：用 2–4 周做出可运行的最小闭环，验证价值再谈整体。
- 驻场交付上线：确认价值后扩到全量，驻场陪跑至业务指标达成。
整条路径典型 6–12 周，远短于传统软件项目普遍 6 个月起的周期。压缩的关键不在于加班，而在于第 3 步——跳过它，后面的每一步都会建立在想象的流程上。
什么时候该在 POC 阶段说不
- 数据根本拿不到，或者拿到的成本高于收益——先解决数据治理，不要硬做模型。
- 规则稳定、输入输出可穷举——用规则引擎或小型模型更稳更省，不必上大模型。
- 业务方无法指定一个固定的对接人——没人配合诊断，POC 必然失真。
- 目标指标无法被客观统计——凡是不能取数的指标，最后一定变成扯皮。
关于这篇文章的常见问题
POC 一般要多久？＋
2–4 周。时间盒是契约的一部分：到点必须出结论（继续、调整、或停止），不能无限延长。
POC 没达到目标怎么办？＋
这正是要在契约里提前写「失败判据」的原因：达到什么情况判定不值得继续、双方各自承担什么、留下什么资产。提前约定，结束时才不会互相指责。
POC 和试点（Pilot）是一回事吗？＋
不是。POC 回答「能不能做、值不值得做」，通常在受控环境里跑一个最小闭环；试点回答「在真实环境里能不能规模化」，重点是稳定性、推广成本与组织适配。先 POC 后试点，顺序反了会浪费大量预算。
POC 阶段一定要驻场吗？＋
建议驻场。POC 的价值来自真实流程，而真实流程几乎不可能通过会议问出来——必须到现场看人怎么操作、在哪里绕开系统。