样本与评测集先定
样本必须由客户提供，覆盖常见与边界情况，评测集在看结果前封存。怎么定评分规则：先约定通过标准与失败类型，例如格式错误、事实错误、越权回答，再让双方按同一张表打分，避免事后解释与扯皮。
双盲评分与失败复盘
怎么评：由客户方两名以上评审独立打分，供应商不在场，分数汇总后再公开。失败案例比成功案例更有信息量，要求逐条说明失败原因与改进办法；能讲清原因的团队，上线后出问题也更可能兜住。
端到端链路验证
怎么验：在客户测试环境跑通一条完整链路，包括取数、调用、回写、日志与权限校验。只验证模型输出不算通过；很多项目卡在单点登录、网络策略与日志缺失上，这些必须在 POC 阶段暴露，别拖到上线。否则返工代价更高。
结论接合同
POC 通过后，把评测集、验收指标、接管机制与失败处理写进合同附件，并据此设里程碑。边界是 POC 只证明这一段流程可行，不证明全场景可用；扩展新场景要重新评估，不能顺延原有的承诺，也不能当作通用能力证明。
适用与不适用
适合谁
- 已把候选缩小到一到两家、需要最终定标的企业
- 有真实样本与测试环境可供验证的团队
- 希望用验证结论支撑决策与预算的负责人
不适合谁
- 没有样本、也无法提供测试环境的单位
- 希望用 POC 替代正式验收的采购
典型场景
某银行在两家服务商之间做选择，POC 范围限定为开户资料审核。客户提供三百条历史样本，评测集提前封存；两家在同一测试环境各跑两周，由三名评审双盲打分，失败案例逐条复盘，最终按结果签订里程碑合同。整个过程由风险部门派人旁听。
可执行步骤
- 划定一个流程作为 POC 范围，写明通过标准与失败类型清单，并确定评审人
- 由客户提供三百条分层样本，评测集在看结果之前封存并由双方留档
- 在客户测试环境跑通取数、调用、回写与日志的完整链路，含权限校验
- 双盲评分后逐条复盘失败案例，结论要写进合同附件与付款里程碑中
常见坑
- 样本由供应商挑选，覆盖不到边界情况，POC 结论过于乐观，上线后落差明显。返工又要重排工期。
- 只看模型输出，不验证取数与回写，上线时才发现接口根本不通，工期被迫重排。预算也随之超支。
- 评分规则在结果出来后才定，双方对通过与否各执一词，POC 反而制造分歧。评审结论无法签字。
- POC 成功后直接扩到全场景，未重新评估，问题成倍放大且难以定位根源。只能整体回退。
自检与验收清单
- POC 范围与通过标准是否事先书面确定并签字
- 样本是否由客户提供并覆盖边界情况，并覆盖常见与边界情况
- 是否在测试环境跑通端到端的完整链路，由客户提供环境
- 评分是否双盲，并留下失败案例的逐条复盘记录
- POC 结论是否写入合同附件与里程碑付款
常见问题
POC 要不要付费？
建议付费并限定范围与周期。付费能让双方投入真正的人手，也便于约定交付物与保密条款；免费 POC 常见的结果是只做演示级验证，样本与评审都不到位，结论参考价值有限。
多少样本才够？
取决于任务复杂度，一般两百到五百条可覆盖主要类型与边界。关键是分层抽样：常见情况、长尾情况、明显异常各占一定比例；样本少但分层合理，比数量多却同质更有说服力。
POC 不通过怎么办？
按事先约定终止，保留评测记录与失败原因，作为下一轮的输入。不建议为了不浪费投入而勉强上线；把不通过的原因写清楚，往往比勉强签约更有价值，也能避免重复踩坑。