误区一：先演示后合同
为什么先合同后演示：演示阶段信息最少、气氛最好，容易让人先形成印象再找理由。正确顺序是先看验收标准、变更流程与退出条款，再看演示；合同写不清时，演示越精彩，后续争议越大，也越难改条款。
误区二三：POC 当交付
POC 只验证技术可行，不验证组织可用；很多团队把 POC 通过当成上线依据。怎么区分：POC 结束后要有评测集、接管机制与运维文档，缺一项就仍在试验阶段，不能按交付验收，也不能对外承诺上线时间。否则验收时无法界定范围。
误区四：只看模型
模型只是链条一环，接口、权限、日志、灰度与回滚决定能不能上线。只看评测分数，常在上线前才发现单点登录不通、日志缺失、并发撑不住；怎么避免：把集成清单当成必答题，让服务商逐项给出实现方式与工期。
误区五：无人负责
服务商再强，客户侧没有产品负责人、数据负责人与验收人，项目就会停在会议里。怎么补：开标前指定三个角色并写进项目章程，否则需求变更无人决策、数据拿不出来，进度只能靠一次次催办往前推。
适用与不适用
适合谁
- 正在选型、已收到多家演示的企业
- 上一次项目延期、想复盘原因的管理者
- 需要向决策层解释为何不选最低价的负责人
不适合谁
- 只看价格、不做验收设计的采购人员
- 希望服务商承担全部落地责任的组织
典型场景
某制造企业上一次项目拖了半年，复盘发现是 POC 通过后就按交付推进。这次选型改了两处：合同先于演示评审，验收指标与接管机制写进附件；同时在客户侧指定产品、数据与验收三个负责人，每周对一次进度。整个过程由项目办统一记录，作为下一轮复盘的输入。
可执行步骤
- 把评审顺序改成先看合同条款与验收标准，再看产品演示，条款评审通过后再安排产品演示
- 要求 POC 结束时提交评测集、接管机制与运维文档三项交付物
- 列出必须打通的系统接口、权限与日志清单，逐条确认责任方与工期
- 在客户侧指定产品、数据与验收三个负责人，姓名写进项目章程附件
常见坑
- 演示现场由销售主讲，技术问题一律回答可以，签约后换人对接，问题集中爆发且无人认账。
- POC 只跑通三条样例就宣布成功，评测集与异常处理都没准备，上线后只能靠人工兜底维持。
- 方案默认绑定厂商自有平台，数据与提示词无法导出，第二年议价空间几乎为零。想换也只能继续用下去。
- 客户侧没有指定负责人，需求变更靠群里确认，出了问题找不到能拍板的人，进度反复停摆。
自检与验收清单
- 评审顺序是否已改为合同优先于产品演示条款
- POC 是否附带评测集与人工接管机制结束时
- 接口、权限与日志清单是否逐项确认了责任方
- 客户侧三个负责人是否已经书面指定到具体的人
- 数据与配置能否导出、退出条款是否写清，条款要逐条看
常见问题
不先看演示，怎么判断能力？
用同一份真实材料让对方做一次小任务，比看演示可靠。演示看的是准备好的剧本，小任务看的是临场拆解与纠错能力；两者结合，再对照合同里的验收标准，判断会更稳，也不容易被话术带走。
POC 一般做多久合适？
多数场景两到四周足够，关键是范围只覆盖一个流程、样本由客户提供。拖到一个季度以上，往往说明目标不清或数据没准备好，此时应先解决前置条件，而不是继续加人加时间。
闭源方案一定不能选吗？
不一定，但要把退出成本写进合同：数据、配置、提示词与评测集能否导出，迁移需要多少工作量。若供应商拒绝约定导出格式，等于把后续选择权交了出去，议价能力也会随之下降。