企业AI落地实战·第17篇|企业AI为什么总是卡在试点阶段

上一篇，我们把第一个流程缩到一个能跑完验证循环的小场景：结果有人看，错误有人发现，发现以后有人接。

流程真的跑通了，新的问题才开始出现。

演示时，日报按时生成，缺交名单也能列出来。业务负责人点了头，项目却又停了一个月。每次问进度，答案都差不多：再优化一下，就可以推广了。

这一段是一个假设的工作场景。它要说明的是一种容易被验收表漏掉的情况：试点的成功，可能把搭建者每天的照看也算进去了。

把这部分照看拿掉之后，流程能不能继续工作，才是这一篇要讨论的事。

HIDDEN WORK · 人工照看

FIG. 01

有人照看与独立运行，是两种不同的运行条件。

用日报汇总举例。

有人换了部门，搭建者顺手改一下名单。有人把日报写在附件里，搭建者先复制出来。模型漏掉一项待办，搭建者在发出前补上。接口偶尔失败，搭建者看到日志后重新跑一次。

最后送到业务群里的那份日报很好看。

可它实际经过了一条没有写进流程图的支线：搭建者的经验、注意力，以及随时能插进去修一下的权限。

这种照看在试点阶段有价值。它能让问题尽快暴露，也能帮助我们理解业务。要紧的是把它记下来，而不是让它一直藏着。

一次手工修正，至少留下三项记录：哪里出了问题、谁做了什么、下次由谁接。暂时不能自动解决的，就明确保留人工步骤。

如果日报表面上每天只省几分钟，背后却需要一个熟悉系统的人随时盯着，那么交接的对象就包括这份照看工作。只交代码，缺了一半。

TAKE OWNERSHIP · 业务接手

FIG. 02

设备就位之后，接手的人和动作也要明确。

“业务已经认可”是一句太宽的话。

看过演示、愿意试用、愿意把它放进日常工作，是不同程度的承诺。到了推广阶段，最好把“认可”拆成具体动作。

还是这份日报：谁在每天开始工作前看它？看完以后，是安排跟进、补齐信息，还是仅仅存档？哪种错误可以等下一次汇总，哪种错误会影响当天安排？

这些答案会反过来决定技术方案。

如果负责人只需要缺交名单，就没有必要把一篇润色得很漂亮的模型摘要放在关键路径上。如果某项任务是否完成会影响后续安排，就应该保留原始记录链接，让接收者能查回去。

交接时可以只用一张短表：谁使用结果、谁接异常、谁批准规则变化、谁安排维护时间。具体姓名比部门名称更有用；允许一个人兼任，也要让他知道自己接下了哪些责任。

这张表不替代组织制度。它只是把“以后有人管”落到一个能找到的人身上。

HANDLE FAILURE · 异常接管

FIG. 03

异常要看得见，也要有人知道如何接管。

接口没返回，到底是没有新数据，还是读取失败？名单更新了一半，系统应该继续生成汇总，还是停下来等人确认？草稿提交后连接中断，应该重发，还是先查一下是否已经创建？

对使用者来说，最难处理的是一个看起来正常、实际缺了一部分的结果。

交付时至少要把状态分开：已经完成、等待处理、结果不确定、需要人工核对。具体叫什么可以不同，含义要让业务人员看得懂。

对于可能重复写入的动作，超时后应先查询已有结果，或者复用同一个业务标识来防重。不能把“没有收到成功响应”直接当成“没有执行”。

对结果还不确定的模型步骤，可以先保留人工确认。人工接管也要有完整上下文：原始输入在哪里、系统已经做了什么、还有哪一步没做。

一个实用的交接练习，是让没有参与搭建的人处理一次模拟异常。搭建者在场观察，尽量不代替操作。

如果对方只能问“接下来点哪里”，操作说明还不够；如果对方看不出该不该继续，业务边界还没讲清。

SHARED BASE · 规则差异

FIG. 04

基础能力可以共用，业务规则仍要逐个确认。

第一个部门跑通后，复制一套账号和配置，看起来就能扩围。

但两个部门对“缺交”的理解可能不同，对日报截止时间的要求也不同。一个部门按项目汇总，另一个按客户汇总。表面上都是日报，验收对象已经变了。

这时候适合共用的，是身份与权限的接入方式、日志、任务状态、防重机制和告警通道。

需要单独确认的，是名单、时间、业务口径、结果接收者，以及人工接管条件。

把前一类做成可复用的基础能力，把后一类写成能审阅的配置。新增配置仍要有人确认，也要能回到上一个版本。

如果每增加一个部门，都要重新找人解释输入、手改脚本、临时开权限，那么规模一扩大，搭建者就会变成固定的人工转接站。

PILOT EXIT · 验证出口

FIG. 05

扩围、继续验证或停止试点，都要有依据。

试点可以继续、可以扩围，也可以停止。三种结果都应该有理由。

上线前约定的业务目标，到了这里还要再看一次：结果是否真的被使用，错误是否在可接受的范围，异常是否有人能独立处理，维护所占的时间有没有被计算进去。

验证周期应覆盖实际业务节奏。日频流程和月度流程不能套同一个天数；只看一次顺利演示，也看不到人员变化和异常积压。

可以用下面这段话作为交接讨论的起点：

在约定的业务周期内，指定使用者独立使用结果；可预见的异常有处理办法，未知异常能找到负责人；搭建者的日常介入有记录；维护工作有人接。满足约定条件后再扩围，否则明确缺口与复查时间。

如果流程始终需要大量人工修正，就把这部分工作列入成本，重新判断收益。如果业务方并不使用输出，就回到需求；如果风险还不能控制，就缩小范围。

“再优化一下”可以是一项计划，但它需要说明优化什么、由谁负责，以及用什么结果判断完成。

上一篇解决的是第一个流程怎么选。这一篇往后补上的是：跑通以后，如何让它成为别人的日常工作。

本文以假设的日报汇总场景讨论交付与运营方法，不使用未经核实的项目数据。具体责任、周期与验收条件，应结合实际业务确定。配图为概念插画，不对应真实项目现场。

上一篇 · 第16篇：从日报、考勤到审批