一句话定义：概念验证（Proof of Concept，POC）是用最小的时间、数据和人手，回答一个二选一问题的短周期实验——“这件事在技术上到底做不做得成”。
它解决的问题是“能不能”，不是“好不好用”
打个比方：你想定制一套西装，POC 就是试衣间里那件样衣。它证明了“这个版型穿在你身上是合身的”，但样衣不能直接穿走——面料还没定、扣子还没缝、尺码还要改，甚至店里有没有货都是另一回事。POC 的全部意义，是把“合不合身”这个最贵的不确定性，用最便宜的方式先排掉。
所以一个健康的 POC 通常有三个特征：目标单一（只回答一个问题，比如“这份合同里能不能稳定抽出甲乙方和金额”）、规模最小（几十到几百条样本、允许人工兜底、可以写死提示词）、成功标准事先写清（“在 200 份历史单据上抽取准确率达到人工基线，就算通过”）。它有时间盒，到点就出结论：继续、换方案，还是放弃。
和相邻概念的区别
| 概念 | 回答的问题 | 数据与环境 | 典型产出 |
|---|---|---|---|
| POC | 技术上可行吗 | 小样本、清洗过、可人工兜底 | 一个结论 + 一份实验记录 |
| 原型 Prototype | 用起来顺不顺手 | 假数据也可以 | 可点击的界面与交互 |
| 试点 Pilot | 在真实业务里跑得通吗 | 真实用户、真实流程、小范围 | 运营数据与问题清单 |
| MVP | 能不能交付给真实用户并持续运行 | 生产环境、有权限与成本约束 | 可上线的最小产品 |
为什么 AI 项目最容易在这里翻车
传统软件的 POC 离生产近，AI 的 POC 离生产远。因为 demo 里那 200 条样本往往是挑过的，长尾、错别字、扫描件、多语言混排都被过滤掉了；而真正上线后，模型要面对的是分布完全不同的一百万条输入，还要接权限、日志、成本核算、评测回归和人工复核流程。于是出现经典的预期错位：业务方看完 demo 觉得“已经完成 80% 了”，工程团队心里清楚“剩下的 20% 才是 80% 的工作量”。把 demo 当成交付，是 AI 项目最常见的翻车方式。
对从业者和普通人的实际意义
做项目的人，POC 立项时就该写清三句话：要回答什么问题？什么结果算通过、什么算失败？失败之后我们决定做什么？记住 POC 的交付物不是代码，是决策。
看项目的人，见到惊艳的 demo 先问三句：这用了多少真实数据？模型答错时谁兜底？上线后谁维护、按什么口径算成本？具体指标与报价以各家官方页面为准。
一句话收尾：POC 的价值不在于证明你行，而在于让你便宜地知道自己哪里不行。