一、先判断场景，再谈技术
一个环节适不适合用AI，可以用三个问题筛选：这个任务是否高频重复？规则是否可以用大量例子说清楚？做错的代价是否可控、有人工兜底？三个问题的答案都是肯定，才值得立项。常见的误区是把低频、高代价的决策交给模型，比如一次性采购决策或重大合同审批——这类任务的样本少、错了难挽回，即使技术可行，投入产出也不划算。另一个误区是把流程混乱当成AI问题：如果一项工作连数据都没记录下来，先做数字化记录比直接上模型有效得多。
二、数据准备比想象中更重要
大多数AI项目的瓶颈不在算法而在数据。启动前请盘点：相关环节留下了多少历史数据？数据存在哪个系统里、能不能导出？标注一份样本需要多少人工时间？以视觉质检为例，每类缺陷通常需要数百份覆盖不同光照与批次的样本；数据零散在各处时，整理本身可能占用项目三分之一以上的时间。建议把数据盘点作为合同的第一阶段，产出物是一份数据清单与缺口说明，之后再谈建模。
三、自建还是外包
两条路线没有绝对优劣，取决于持续投入的意愿。下表对比关键差异：
| 维度 | 自建团队 | 外包实施 |
|---|---|---|
| 启动速度 | 慢，招聘与磨合需数月 | 快，数周内可启动试点 |
| 长期成本 | 持续的人员薪酬投入 | 按项目与运维付费 |
| 知识沉淀 | 留在内部，可复用 | 依赖合同约定的移交条款 |
| 适用情形 | AI是长期核心能力 | AI是局部效率工具 |
多数企业的现实选择是混合模式：首个项目外包实施，同时在合同中要求文档与代码移交，由内部工程师跟进维护，逐步建立自己的判断力。如果走这条路，签约时就要把移交清单写进合同。
四、合同里必须写清楚的条款
AI项目合同与普通软件合同不同，以下条款建议逐条确认：一是数据条款，明确数据的所有权、使用范围与项目结束后的处理方式；二是验收标准，写清测试集的构成与指标定义，避免用模糊的“效果好”替代可测量的口径；三是移交清单，代码、文档、模型文件与标注数据分别归属谁；四是运维边界，上线后谁负责监控、迭代周期与响应方式如何约定；五是变更流程，范围变化须书面确认。缺了这些条款的项目，后期出现争议时几乎无法厘清责任。
五、验收与上线后的管理
验收不应只在交付当天做一次。建议约定上线后一到三个月的观察期，用生产环境的真实数据回测指标，并与供应商约定衰减处理机制。内部管理上，指定一名业务负责人对效果负责，而不是把系统交给IT后就无人问津——模型衰减被发现得越晚，修复成本越高。上线第一年内安排至少两到三次复盘，是多数项目维持效果的下限投入。