中小企AI项目为何失败：六个反复出现的模式

问题极少出在模型本身，几乎全部出在项目结构。

过去两年，以独立AI工程师身分为企业交付自动化工具，同时营运自己的LLM平台。接触过的导入案例中，失败的项目有一个共通点：问题极少出在模型本身，几乎全部出在项目结构。以下六个模式，在不同企业身上反复出现。

一、目标定义在「导入AI」，而非「解决哪个流程」

失败项目的起点常常是一句「我们也要用AI」。这句话缺少受词——用在哪个流程、取代哪段人力、以什么标准算成功，全部未定义。可行的起点是一个具体问题：「同事每天花两小时整理邮件附件里的报告」。这句话自带范围、自带成功标准、自带投资回报的计算基础。

二、范围在进行中不断膨胀

「既然做了A，顺便加B吧」——每一次「顺便」都在延后交付日，并稀释原有预算。按时计费的合作模式会放大这个问题。预防方法是在动工前把交付物写成清单，清单以外的需求进入「第二期」讨论。关于计价模式的完整分析，见固定范围计价与按时计费一文。

三、资料尚未准备好

AI自动化的原料是企业自己的资料。常见情况是资料散落在个人电脑、多个云端账号、纸本与扫描文件之间，格式互不相容。在签约前先回答一个问题：这个流程的输入资料，现在放在哪里、谁能取用、格式是否一致。

四、期望「全自动、零错误」

大型语言模型的输出带有概率性质，偶发错误是系统特性，并非工程失误。成熟的设计把这个特性纳入流程：高风险环节保留人工覆核，低风险环节全自动，错误发生时系统主动标示。驗收标准应该定义「错误如何被发现与处理」，而非「错误不存在」。

五、被Demo牵引选型

展示用的demo与生产环境之间有一段距离。判断方法很简单——要求对方用你自己的资料跑一次，并且同一份输入跑多次，观察输出是否稳定。完整的评估方法，见如何评估AI服务商的提案。

六、交付后无人接手

工具上线那天，项目才走到一半。API费用谁付、系统出问题谁处理、供应商倒闭或转行了怎么办——原始码移交与知识转移是这个问题的结构性解法。

小结

六个模式的共通解法，是把「AI项目」还原成「流程改造项目」：先定义流程与成功标准，再谈技术。技术选型是第五步，而多数失败项目把它当成第一步。

常见问题

问：项目做到一半发现资料太乱，应该停吗？

先缩范围。挑资料最完整的一个子流程先交付，其余列入第二期。停损点应该以「里程碑」为单位，而非以「整个项目」为单位。

问：如何判断一个流程适合自动化？

三个条件：重复发生、输入输出可以用文字描述清楚、偶发错误的代价可承受（或可用人工覆核拦截）。三者齐备，自动化的成功率会高很多。