本文给一套能直接照着用的验收视角，不聊具体某家产品，只讲"该盯着哪几条看"。
一、先分清楚：PoC验的是能力，不是演示
很多PoC变成了"看演示"。演示是可以准备的，用的数据、问的问题、跑的流程，都能提前排好。验收的价值，恰恰在于打乱这套预排。
所以头一条原则是：验收要用你自己的真实数据、真实问题。拿一个财务上个月真实的经营问题去问，比让厂商拿演示数据跑十个花哨场景，有说服力得多。
二、要盯着看的几条
下面这几条，按重要程度排。
1.答得准不准，且能不能说清为什么
不只看答案对不对，还要看能不能追溯。一个结论出来，能不能点到"数据从哪张表来、按什么口径算的"。答对了但说不出依据，和答错同样危险，因为你没法判断它这次对，下次还对不对。
2.用你的真实数据，而不是演示数据
这一条再强调一遍。真实数据才有真实的问题，口径不一、字段缺失、权限复杂。演示数据是干净的，验不出真章。
3.数据安全边界是不是真的落在执行层
问一个关键问题：能不能做到"哪个角色只能问哪个范围的数据"。这个边界不能只靠"我们建议这样用"来口头约定，要落到系统的权限设置里。尤其要看，能不能限制到具体的字段、具体的部门范围。
4.出错了能不能找到原因
故意问一个边界外的问题，或者给一个口径模糊的问题，看它怎么反应。理想情况是明确说"这个数据不在授权范围"，或者"这个口径需要先确认"，而不是硬编一个数出来。
5.业务的人自己能不能用起来
让一个不懂技术的业务同事来试，看他在没人指导的情况下能不能问出一个数。如果每一步都要IT在旁边翻译，说明它还没过"真正交给业务"这一关。
三、验收时容易漏掉的三个地方
除了上面几条，还有三处常被忽略：
响应和延迟。演示环境快，不代表接入真实数据量后还快。要按真实数据规模估一次。
私有化版本和云版本的差距。如果你要的是私有化部署，PoC一定要用私有化版本测，不能用云上的功能演示"代表"私有化能力。两者可能存在版本和能力的落差。
运维成本。上线后谁维护、要不要专人、出了问题找谁。这些在PoC阶段就该问清，别等签完合同才发现。
四、一条能直接用的验收清单
把上面这些，收成一张清单。验收时逐条打勾：
用真实数据问过真实问题
每个结论能追溯到数据来源和口径
权限能落到具体字段、具体部门范围
故意问边界外的问题，能明确拒绝而不是编数
不懂技术的业务同事能独立问出一个数
按真实数据规模估过响应速度
私有化需求的话，用的是私有化版本测的
问清了上线后的运维责任和响应机制
小结
PoC的目的不是"确认厂商靠谱"，而是"把上线后可能踩的坑，提前在可控的环境里踩一遍"。所以验收要盯的是真实数据、可追溯、权限边界、出错处理、业务可用性这五条，而不是演示的流畅度。
一条朴素的判断：如果一场PoC全程没有暴露任何问题，那这场PoC大概率没有验到点子上。
常见问题
Q：PoC一般要测多久？
A：没有固定时长，取决于你要验证的场景数。宁可测一个场景测透，也不要十个场景各碰一下。测透一个真实场景，比走马观花更有价值。
Q：厂商不肯用私有化版本测怎么办？
A：这本身就是一个信号。如果你确实需要私有化部署，验收就必须用私有化版本，用云版演示来"替代"是不成立的。这一条可以作为硬性要求。
Q：验收时该谁来当"测试员"？
A：除了IT，一定要拉一个真实的业务用户。很多问题只有业务用户用自己的真实需求去问，才会暴露出来。