企业 AI 项目 PoC 该怎么设计

先定义问题，再谈技术

在制造、金融、零售等行业的 AI 项目里，一种常见的现象是：演示效果不错，但半年后仍然没有进入生产系统。复盘时往往会发现，问题不在模型本身，而在于立项时没有人把"这件事做成什么样才算成功"写清楚。

一个能通过业务评审的 PoC，通常具备三个特征：问题边界窄、数据可得、结果可判断。以下三类题目相对容易做成，也容易说服管理层：

1. 有明确输入输出的重复性任务，例如单据信息提取、工单分类、合同要素抽取。
2. 有现成历史样本的任务，例如过去若干年的质检记录、客服会话、售后工单。
3. 错了也不造成严重后果的任务，可以由人工复核兜底，例如知识检索、文档草稿生成。

相对而言，下列题目不太适合作为起步阶段的项目：目标本身还在讨论中的战略级项目、涉及跨部门权责重新划分的流程改造、以及缺乏历史数据支撑的预测类任务。它们不是不能做，而是不适合用来验证技术是不是走得通。

把验收标准写成一句话

我们建议在立项文档里加一条"可被证伪的验收命题"，格式大致是：在什么条件下，由谁判断，达到什么程度算通过。

例如：

在抽取最近三个月的采购订单要素时，由财务共享中心的复核人员独立判断，抽取结果经人工修正后即可入账，且需要人工修正的比例低于人工录入时的工作量。

这句话里包含了三样东西：数据范围、判断主体、判断依据。它的价值在于，即使最终结论是"不通过"，团队也知道是哪一环没有达到要求，而不是笼统地说"效果不好"。

要避免把技术指标直接当成验收标准。检索命中、字段准确率、响应耗时这些指标应当作为约束条件写进方案，而不是作为成功定义。业务方关心的是复核工作量是否下降、是不是可以少一次转述、能不能把某个环节从两天压到半天——这些才是判断标准。

数据边界要在动手前画好

PoC 阶段最容易被低估的是数据准备。常见的做法是先确认四件事：

• 范围：用哪个时间段、哪个工厂或哪个业务线的数据。
• 可用性：字段是否齐全、历史记录是否存在缺失或口径变化。
• 合规：是否包含个人信息，是否需要脱敏处理，脱敏后是否还够用。
• 成本：标注、清洗、对齐口径需要投入多少人力。

如果数据需要经过脱敏才能出内网，那么时间预算要单独列出，不要默认它能在几天内完成。若历史数据分布与当前业务差异较大，建议在 PoC 报告里明确写出这一限制，避免结论被过度外推。

用"双轨盲评"控制主观偏差

评估环节的常见问题，是参与开发的团队给自己的成果打分。一种可行的做法是双轨盲评：

• 让业务同事在不知道哪份结果由模型产出的前提下，对模型输出和人工结果分别打分；
• 评分维度固定为若干项，例如完整性、正确性、可直接使用程度，每项给出简短的口径说明；
• 预留一部分"故意难"的样本，用来观察系统在边界情况下的表现；
• 把失败案例完整记录，不要只保留成功样例。

失败样例的价值往往高于成功样例：它们决定了上线后需要配多少人工复核，也决定了后续迭代的优先级。

设好决策门，别让 PoC 拖着

建议在 PoC 开始时就约定三个出口，并在结项会上明确走哪一个：

1. 通过，进入试点：明确试点范围、责任人和下一阶段预算。
2. 有条件通过：列出必须补齐的条件，例如数据质量、权限体系、流程调整。
3. 不通过：写明原因，并说明在什么条件下值得重新评估。

结项材料建议控制在一份文档内，包含：命题与结论、数据范围说明、评估方法与样本构成、失败模式清单、后续建议。同时把可复用资产沉淀下来——测试集、标注规范、接口封装、失败模式库，它们在下一个项目里通常还能继续用。

PoC 的目标不是证明技术可行，而是在投入规模化资源之前，用较小的成本获得一个可以判断的结论。一次"说清楚为什么不成立"的验证，比一次"看起来很成功"的演示更有价值。