深度：别把概念验证做成迷你产品，POC只负责回答一个关键问题
从关键假设、最小证据、预算时间盒到继续与停止条件，建立一套投资人和客户都能读懂的概念验证方法。
作者：天使投资人雷欧
一、POC不是缩小版成品
很多团队把概念验证做成一个功能不全、界面粗糙的产品，然后用‘还没做完’解释所有问题。这样的POC既不能回答技术是否可行，也不能回答客户是否愿意采用。
好的POC只对一个决策负责：在限定时间和预算内，取得足够证据，让团队决定继续、调整或停止。
二、先找最贵的未知数
不是所有未知都值得先验证。优先选择一旦错误就会推翻商业模式、造成重大合规风险或吞掉大量资金的假设。
- ✓ 技术：核心性能在真实约束下能否达到门槛？
- ✓ 需求：目标客户是否愿意投入时间、数据或付费？
- ✓ 交付：团队能否在约定周期内稳定完成？
- ✓ 经济：完成一次交付的全部成本是否可能被价格覆盖？
三、把假设写成可被否定的句子
‘用户会喜欢’无法验证。更好的写法包含对象、场景、动作和门槛，例如：目标岗位在限定流程中，能否用该方案完成任务，并达到双方事先约定的验收要求。
具体数值必须来自客户约定或真实基线，不能为了显得专业凭空写一个百分比。
四、设计最小证据，而不是最多功能
先问什么证据足以改变决定，再决定做什么。可能是一段接口、一组人工辅助流程、十次客户任务或一个付费承诺，不一定是完整软件。
- ✓ 验证对象与样本来源
- ✓ 当前基线与通过标准
- ✓ 时间和预算上限
- ✓ 哪些部分由人工临时完成
- ✓ 失败、异常与未完成项怎样记录
五、设置时间盒，阻止POC无限长大
POC最常见的失控不是技术失败，而是每收到一个意见就加一个功能。时间盒到期后必须评审证据，新增需求进入下一轮，不偷偷改变本轮问题。
如果客户要求的每个功能都必须完成才能验收，这更像定制项目，应重新谈范围、费用、知识产权和交付责任。
六、成功标准要包含商业下一步
技术指标通过只是开始。POC结束时还应回答：谁签验收、是否愿意进入付费试点、正式采购还缺什么、部署和支持成本是多少。
- ✓ 继续：证据达到门槛，进入MVP或付费试点。
- ✓ 调整：部分成立，缩小场景或改变方案后再测。
- ✓ 停止：关键假设被否定，保存记录并关闭投入。
- ✓ 待核实：样本或数据不足，不把不确定写成成功。
七、投资人怎样看POC
投资人不只看演示是否顺利，还看团队是否选择了真正关键的问题，是否诚实记录失败，是否能把技术证据接到客户、成本和规模化路径。
一个小而清楚的实验，往往比功能很多却无法验收的演示更有信息价值。
八、自检表与今天就能做的事
复制这张POC决策卡：
- ✓ 关键假设：___
- ✓ 为什么现在必须验证：___
- ✓ 对象与样本：___
- ✓ 当前基线与通过标准：___
- ✓ 预算/截止日：___
- ✓ 继续、调整、停止条件：___
- ✓ 今天行动：删掉一个不会改变决策的功能，把省下的时间用于跑第一批真实样本。
九、结语与风险提示
轻资产不是永远少花钱，而是在关键证据出现前保持投入可逆。POC的使命，是用小成本换来更好的下一次决定。
本文为一般创业与产品方法，不构成技术、法律、融资、投资或收益建议。涉及数据、合同、知识产权和行业准入时，应结合实际取得专业意见。©天使投资人雷欧
常见问题
POC、原型、MVP和试点有什么区别？
POC回答关键假设是否可行；原型帮助理解交互或形态；MVP让真实用户使用最小版本；试点在限定客户与场景中验证实际交付。实践中可能重叠，但决策问题不同。
POC应该做多少功能？
只做足以验证最关键假设的部分。若某功能不改变继续、调整或停止的决定，它通常不应进入这一轮。
POC成功后可以直接规模化吗？
不能自动推导。还需验证真实客户、稳定交付、单位经济、合规、供应链和组织能力。
失败的POC有没有价值？
如果事先定义了假设、方法和失败条件，失败能避免更大投入并帮助缩小问题；没有记录的失败则容易重复。
信息来源与核实边界
- 2026-09-03 每日商务英语 proof of concept：当日本地稿给出的释义与创业场景
- Y Combinator：YC's Essential Startup Advice：第一方创业方法参考：尽快推出、与用户沟通、围绕真实需求迭代
- SBA：Market Research and Competitive Analysis：客户、问题与竞争替代的通用研究框架；不构成中国统计或监管口径
- 雷欧原创POC决策卡：一般创业实验设计方法，不保证技术、商业或融资结果