同一批验收样例
先写十到二十条验收样例，覆盖正常、异常与边界，双方用同一批数据。为什么：样例不同，做出来的东西无法比较。边界是样例要由业务方出，不能由参评方提供，否则会偏向自己擅长的部分，结论也不可信。
记录工时返工
内部团队按人天记录，供应商按其投入记录，双方都要写清返工原因。怎么用：把工时折算成成本，与功能完成度并列比较。边界是内部工时常被低估，建议按实际打卡或任务系统统计，而不是事后回忆。
比较维护文档
验证结束时检查设计说明、接口文档与部署脚本是否齐全。为什么重要：文档决定后续维护成本，尤其自研方案容易忽略。怎么做：把文档列为验收项，缺项扣分，而不是只看功能是否跑通，也不要事后补写。
决策门与止损
验证前约定通过条件，例如完成度、工时上限与文档要求。怎么用：到期按条件判定，未通过就停止，不追加预算。边界是验证期不宜反复延长，否则会变成事实上的立项，决策反而更难，沉没成本也更高。
适用与不适用
适合谁
- 在两套方案之间难以取舍的业务与技术负责人
- 需要向上级提交可比数据的项目组
不适合谁
- 需求尚未稳定、无法写出验收样例的团队
- 已经签约、只想补一份材料的项目组
典型场景
某集团要做一个合同要素抽取工具，内部团队与两家供应商各做一版。评审组用同一批二十份合同与十五条验收样例测试，记录完成度、工时与返工原因；内部方案完成度高但文档缺失，最终选择采购加自研后处理，验证报告一并归档。
可执行步骤
- 由业务方写十到二十条验收样例，覆盖正常、异常与边界，并冻结版本，形成测试记录
- 双方用同一批数据开发，按人天或任务系统记录工时与投入，由复核人签字确认
- 逐条测试并记录失败原因、返工次数与修复时长，形成测试记录，纳入项目计划表
- 检查设计说明、接口文档与部署脚本是否齐全，缺项扣分，并留档备查，同时指定负责人
- 按决策门判定通过或停止，形成书面结论与依据并留档，同时指定负责人
常见坑
- 验收样例由参评方提供，偏向自己擅长的场景，比较结果失真，评审也无法判断真实能力，最后只能凭印象。
- 内部工时靠事后回忆，普遍偏低，自研方案显得更划算，决策被误导，后续预算难以支撑，团队也吃力，审计时也说不清。
- 只看功能是否跑通，不看文档，交接时才发现无人能维护，系统只能停在当前版本，升级也无从下手，客户体验明显下降。
自检与验收清单
- 验收样例是否由业务方出并冻结版本，纳入验收清单
- 双方工时是否按同一口径记录并复核，定期复查留档
- 返工原因与次数是否分类统计并归档，指定负责人
- 文档是否列为验收项，并逐项检查、签字确认并存档
常见问题
并行验证要花很多钱吗？
取决于范围。把样例控制在十五条以内、周期两到四周，投入通常小于一次错误选型的返工。若预算紧张，可只做内部验证加供应商试用，但验收样例与工时口径仍要一致，否则比较没有意义。
内部团队会不会觉得被比较？
有可能，需要提前说明目的：不是评判个人能力，而是确认哪种方式更适合长期维护。建议让内部团队参与设计验收样例，并把验证结果用于排期与资源申请，而不是只用来做取舍，否则配合度会下降。
验证结果和预期相反怎么办？
按决策门执行，不为已投入的时间找理由。若结果显示采购更合适，就把自研资源转到差异化环节；反之亦然。关键是把结论与依据写清楚，供下一次选型参考，而不是束之高阁。