很多企业想验证一个 AI 场景，但不知道从哪下手，一谈就是三个月、几十万。其实大部分场景用两周就能得到明确结论：值得做，或者不值得做。
下面这份清单是我们自己做驻场验证时用的流程，可以直接照着执行。
开始之前，三个条件必须满足
条件不满足就别开始，做了也是白做。
- 有一个能拍板的人。不需要是老板，但必须是这个业务环节的负责人，能决定「这个流程可以改」。
- 有一个具体的岗位和一段具体的流程。不是「提升生产效率」，而是「质检员每天要看 300 张照片，找出其中划伤的」。
- 有可访问的历史数据。哪怕只有三个月、只有一张表。没有数据就没有验证，只有演示。
第 1–2 天：场景筛选
产出物是一页场景卡片，写清楚四件事：现在谁在做、一天做多少、卡在哪一步、做完能省多少时间。
筛选的标准只有一条：这个环节是不是「高频 + 有判断规则 + 结果可验证」。
- 高频：一天至少几十次，不然省下来的时间不值得投入
- 有判断规则：老师傅能说出「我是怎么看出来的」，AI 才有机会学
- 结果可验证：对错能被明确判定，不然没法算准确率
同时要主动排除掉一类场景：结果好坏取决于人脉、谈判、临场应变的。这类事情目前还做不了。
第 3–5 天：数据与系统摸底
产出物是一份数据可用性清单，逐项标注：数据在哪、谁有权限、格式是什么、缺失率多少、更新频率多少。
这一步最容易出意外，也最值得早做。常见的坑有三个：
- 数据在某个已经离职的工程师搭的系统里，没有文档
- 字段名是拼音缩写，含义要靠问老员工
- 数据能导出，但导出要走审批，两天才能拿到一次
摸底完成之后，如果发现关键数据拿不到，就要立刻停下来重新选场景——这就是这两天的价值。
第 6–10 天：做出最小可用版本
目标是跑通一条完整的业务链路，不是做一个漂亮的原型。
完整的链路指的是：真实数据进来 → 系统处理 → 结果给到一线 → 一线能用它做决定 → 结果被记录下来。
这五步缺任何一步，验证都不成立。很多 POC 只做到第三步就结束了，然后拿一个演示页面去汇报——这种演示支撑不了决策。
这个阶段要克制的一件事：不要加功能。所有「顺便也能做」的想法都记下来，放到下一阶段，这一阶段只验证那一条链路。
第 11–14 天：验证与决策
产出物是一份验收报告，包含三块内容：
- 用真实数据跑出来的指标，和启动会上确认的基线值对比
- 一周的真实使用记录，谁在用、用了多少次、在哪里放弃
- 一个明确结论：值得继续投入，或者不值得，以及理由
结论是「不值得」也算成功。两周时间换来一个明确的否定答案，比三个月后才发现要好得多。
什么时候该停
出现下面任何一种情况，建议直接停，不要硬撑：
- 到第 5 天还拿不到可用的历史数据
- 业务方说不清「怎么判断对错」
- 跑出来的效果需要人工兜底超过一半的量
- 一线明确表示「就算做好了我们也不会用」
最后一条最容易被忽略，但它往往是最准的信号。
客户方需要投入什么
两周的验证，客户方大概需要投入这些：
| 角色 | 投入时间 | 做什么 |
|---|---|---|
| 业务负责人 | 约 4 小时 | 确认基线值、参加启动会和验收会 |
| 一线骨干 | 约 6 小时 | 讲清判断规则、试用、反馈哪里不好用 |
| IT / 信息中心 | 约 4 小时 | 开通数据权限、确认接口方式 |
加起来不到 15 个小时。如果连这个投入都安排不出来，说明这个场景目前的优先级还不够，不如先放一放。
小结
两周 POC 的价值不在于做出一个能用的系统，而在于用最低成本回答一个问题：这件事值不值得做。
愿意先用两周给答案、再谈整体合作的团队，通常也更愿意对最终结果负责。这也是我们做 FDE 驻场的默认起点。
如果你有一个具体场景想验证，可以把场景描述发给我们，我们会在一个工作日内回复是否可以安排。