门槛项不参与打分
部署位置、数据能否出内网、必须打通的系统属于前置门槛。做法是：立项会上让法务、安全与业务各写一条否决条件，超线的方案直接出局，避免用高分掩盖硬伤。边界是不宜超过三条，否则短名单会空。
样本要挑最难的
用长尾问题、跨部门流程与脏数据做测试集，而不是厂商准备的演示数据。怎么抽样：从近三个月真实工单里抽三十到五十条，按难度分层并去标识，同一批分别喂给两家，记录通过率与人工接管次数。
同口径的两周对照
给每个方案相同的时间盒、任务与评审人，避免一方做深度演示、另一方只看录屏。怎么做：第一天要求打通一条真实接口的读取与写入，第三天跑样本，第十天出对照表；跑不通就记为否决，并写明原因。
三年账与退出演练
订阅的席位与调用量按业务增长外推，定制的维护工时按年度上限估算，两边都加集成与培训。怎么算：用过去十二个月的峰值月份做压力测试。退出演练别省，导出后由业务方抽查十条记录与附件。
适用与不适用
适合谁
- 已锁定两三家候选、需要定案依据的项目组
- 担心上线后集成不通的 IT 与业务团队
- 要向管理层提交选型报告的责任人
不适合谁
- 还没梳理业务问题、只想看演示的单位
- 希望用一次测试替代合同谈判的采购
典型场景
选型会上，两款订阅产品与一家定制团队并列在候选清单里。项目组定了三条否决项，抽四十条工单做测试集，要求每家在第一周打通工单系统的写入接口。两周后一家在限流下失败，一家导出缺附件，只剩定制团队与一款订阅产品进入终选。
可执行步骤
- 立项会上确定三条以内的否决条件，并写清每条的判定标准与责任人
- 从近三个月的业务记录里抽取样本，按难度分层并去除敏感标识信息
- 统一测试脚本、时间盒与记录表，并指定同一批固定的评审人全程执行
- 要求候选方现场打通一条真实接口的读取与写入，并记录失败原因与耗时
- 做一次全量数据的导出演练，并由业务方抽查附件与字段能否完整还原
常见坑
- 用厂商准备的演示数据测试，结果全是顺利路径，上线后长尾问题集中爆发，返工反复两轮。
- 两家测试的时间与人力不对等，结论反映的是投入差异，不是产品本身的差异，容易误判。
- 只测功能不测接口，签约后才发现写入需要额外中间件，工期与预算同时被拉长，成本失控。
自检与验收清单
- 否决条件是否不超过三条，且每条都有判定标准
- 测试样本是否来自真实业务并做过去标识处理
- 两家是否使用同一脚本、同一时间盒与记录表
- 真实接口的读取与写入是否都在现场跑通留痕
- 导出演练是否抽查过附件与字段的实际还原情况
常见问题
验证做到什么程度才算够？
够用的标准是三条硬约束都有结论：接口能通、样本结果可比、数据能导出。功能细节可以留到实施阶段确认，但这三条只要有一条没结论，决策就仍然靠猜，评审记录也留不住。
两周时间会不会太短？
两周足够验证可行性与主要风险，不足以验证长期稳定性。把目标限定在能否进入实施，而不是能否上线；长周期问题用合同里的试运行期与退出条款兜底，别用演示替代判断。
厂商不配合接口测试怎么办？
这本身就是结论。接口打通是实施前提，连测试环境都不愿开放的方案，上线后的排障会更难。把接口测试写进询价文件作为参与条件，提前筛掉不配合的候选方，减少后期扯皮。