企业 AI 选型清单：从 POC 到招标要准备哪些材料

选型阶段的材料，作用不是给评审堆材料。它的作用是让需求、边界与验证方式在项目开始前固定下来。这三件事如果只在会上口头说过，进入实施阶段后往往各说各话，返工的成本远高于前期准备的成本。

需求侧要写清任务与边界

需求材料的起点不是功能清单，而是任务清单。要处理的是哪几类任务，每类任务现在的处理方式、处理量、耗时如何，这些是后续评估的基础。

比任务更重要的是边界。数据能不能出本地、能否接入现有账号体系、是否要求离线运行，这些属于约束条件，直接决定可选方案的范围。很多项目在选型后期才发现约束不兼容，前面几轮的比较工作等于白做。

还有一类容易被漏掉的边界：不能做什么。例如某些环节不允许自动决策，必须保留人工确认。这类要求提前写明，可以避免方案在验收阶段被推翻。

验证侧要定义通过标准

POC 要有明确的通过标准，否则结果无法解释。标准需要在 POC 开始前确定，而不是结束后根据结果补写。

通过标准应当与业务指标挂钩，而不是只看模型指标。例如可自动处理的单据占比达到多少，比模型准确率达到多少更贴近使用效果。同时要规定测试数据来源：是历史数据回放，还是现场实测，两种方式得到的结论不同。

还要约定不通过怎么办。POC 不通过不等于项目终止，可能只是方案调整。把这个环节写进材料，可以让供应商更愿意暴露问题，而不是把风险藏到上线之后。

商务侧要与技术条款对应

招标文件里的技术条款，往往和后面的验收标准是两份文档。两者不一致时，责任划分就成了争议点。

可行的做法是让验收指标直接引用 POC 阶段确定的通过标准。同样的口径、同样的测试方法、同样的数据来源，从 POC 一路沿用到验收。这样供应商在报价时能算清成本，采购方在验收时也有依据。

交付物清单需要写具体。除了软件本身，还应包括部署文档、运维手册、接口说明、模型与配置的版本管理方式。这些内容不写清楚，交付时容易出现系统能用但没人会维护的情况。