我们见到的企业AI落地失败原因，集中在选题、数据、接入和验收四个环节

企业AI落地失败原因，在我们接触的项目里集中在四个环节：选题时没有定下一个具体结果，数据阶段没有摸清系统里到底有什么，接入阶段停在演示，验收阶段只看局部任务是否完成。这篇文章写给正在做或做过 AI 落地的企业负责人，读完可以对照每一环的信号，判断项目卡在哪里，也可以判断要不要找人看一眼。依据是我们在企业项目里留下的记录与方案，包括需求沟通、一次 ERP 取数实测、一次改稿测试和陪跑课堂，以及 Flowness 内部一次改造的追溯审计。这些是单个团队的经验归纳，不是行业统计，文中不给失败率。

我们的经验是，企业负责人通常知道 AI 很强，却说不出它在自己的业务里具体能做什么。缺的是一句话：某个时刻，某个人，看到什么，得到什么。选题阶段没有这句话，后面的数据、接入和验收都没有可以对照的目标。

第一次沟通常常同时摆出好几个部门的诉求，从经营报表、日常单据处理到和主业无关的自动化都有。每一类都合理，放进同一个项目，就没有一个能验收。

我们的做法是把场景设计成一张闭环清单，每个场景写方案之前先走一遍。第一项是“老板在什么时刻、看到什么、得到什么”；中间有现状与痛点、数据来源、规则与逻辑、人工确认节点、输出怎样回流；最后有老板的选择题，用业务语言问，不问技术。判断标准有两条：能说出这个业务里只有做过的人才知道的细节，老板才相信我们懂；老板看得到第一步做什么、最后拿到什么、怎么用，才敢点头。清单之外的诉求，我们在第一次沟通时就说明不承接，避免范围悄悄长大。

选题阶段的信号有三个。需求里找不到一个具体的人和时刻；一次沟通里的诉求数量超过一个团队能同时验收的量；验收标准是“感觉它很聪明”。出现其中任何一个，先回到选题，再谈技术。

有的企业在找我们之前自己试过：把 ERP 导出的大表交给聊天模型，结果漏数、每次答案不同。商品描述压成一个文件，模型一次读得进，这本身没有问题；难在每天重复跑、每个数对上单据、老板追问时接着答，而且数据里除了商品还有大量账目和噪音。我们在方案里把数值交给代码和查询全量计算，让每个数追到单据，模型负责选择口径、组合和解读。

数据阶段最容易被低估的，是系统字段和业务含义之间的距离。在一次 ERP 取数实测里，我们看到几类常见的情况。

读取数量要对账。我们沿后台页面实际使用的接口分页读取物料主档，读出的记录数与页面显示的总数一致，唯一主键数也一致。这一步决定后面所有分析建立在完整数据上。

更新时间字段不能指望。ERP 主档里的更新时间字段绝大多数是空的，方案写成“按更新时间同步变化”就会失效。实测报告据此建议改为定期读取主档、比较字段指纹，只对变化的记录重建索引。

规格字段不等于规格。抽查的成品里，规格字段填的是型号式编码，尺寸字段没有填，真正的尺寸、材料和公差写在 BOM 子件里。只对成品型号做相似检索，找不出“尺寸材料保持一致”的旧产品。

同规格文本相同的成品，可能出现在不同编号下，其中一个已经被禁用。这类旧号如果不保存核对结论，会一次又一次被推给工程师，方案因此要求保存新旧编号的关系和核对结论。

范围要覆盖业务对象。产品之间常有上下级关系，成品和配套的半成品、子件分在不同编号下，随机截取一部分做样本，工程师会找到某个旧款，却找不到它的另一半。我们的判断是，这比没有系统更伤信任，所以方案范围按业务对象划，覆盖全部成品。预算收窄时，先减少资料来源和特殊格式，保住主档的检索覆盖。

数据阶段的信号是：结果不稳定，数字对不上单据，字段含义要靠口头解释，样本量是拍脑袋定的。

演示可以用一份导出的样例，正式使用不行。接入阶段要回答的问题，在演示里全都不会出现。

先看取数路径。实测的 ERP 能直接给出结构化数据，走的是后台页面使用的接口，没有厂商声明长期兼容的公开 API。浏览器里的登录状态可以用于验证路径，不能当作长期认证。实测报告建议把服务侧认证、会话续期、权限控制和失败重试在报价中单独列项，不并进“接入 ERP”一行。

再看业务语义。多账套的制造企业 ERP 里，常见这几种情况：库存里有多种未过账状态，不能把所有在库量当成可用量；销售价格带数量档位和有效期，只按料号取一个价格会算错；账套不同的数据不能直接合并，跨公司汇总必须保留账套维度；生产领料属于出库业务，修改和过账不能误写成入库。演示里看起来正确的“可用库存”，常常缺这些判断。

写回更要小心。取数和计算出了错，可以重算；写回出了错，会改动正式业务单据。方案把项目拆成三层：先取数，再做各类计算和出表，最后才是确认之后写回。写回层要单独完成权限校验、重复提交处理和中断恢复。

接入点的选择也会决定项目能不能活下来。我们的做法是把接入点选在客户本来就有的动作上：比如文件原本由员工在聊天工具里收，就请员工存进固定目录，系统只处理这个目录，不接入个人聊天账号。客户不用为系统改变习惯。

接入阶段的信号：演示数据来自手工导出；没人能回答账号归谁、登录过期怎么办；“写回”被当成一个按钮，没有人设计它的审批流程。

验收出问题，常见两种形态。

第一种发生在 Flowness 自己身上。Flowness 是我们自己开发的 Harness 项目，用来组织多个 AI Agent 持续协作，管理任务、上下文、工具调用与工作记录。2026 年 9 月 2 日，我们对一次采访系统的改造做了追溯审计，把需求、设计、工程方案、冻结概念和任务包排在一张表上。32 个任务里有 29 个报告成功，24 个冻结概念和 11 件机制看起来覆盖完整，但最初要求的几项关键效果没有到达这些任务。例如“从过去的问题改进下一次采访”，设计里有四件事：识别相关事件、把历史问题反推成必问清单、给清单一个稳定的归宿、让下一场采访开场前读到它。到了任务阶段，它变成了一个问题类型枚举、几个消费方和一个统计接口。代码可以照任务正确实现，这条任务链却已经无法保证下一场采访会读到清单。每一棒都做了一次看似合理的收窄，最后只剩下容易确认的产物。这次审计没有重新运行实验，上面是对设计与任务的追溯结论。完整经过见文章：全局目标怎样在多次合格交接中丢失。

对企业项目来说，“每个功能点都验收通过”不等于“老板想要的结果出现了”。所以我们在方案里，局部验收之外另设一次整体验证，直接看最初那个时刻有没有发生，比如老板打开日报，里面的数字能不能追到单据。

第二种是用看起来对的结果代替逐项核对。我们在一个工程文档改稿测试里，用几组真实产品、几百个字段逐项比对。每组由人工做出的成品抄出字段级答案，评分脚本拿它做钥匙，参与测试的技术路线读不到它。多条路线在同一批字段上比分，目的是选出要产品化的那条。改稿还有一层区别：尺寸文字改对了，图形几何不一定跟着改对，所以方案里的验收分字段和文件两级，改稿由工程师复核后签核。答案钥匙和评分脚本留在项目里，谁来评价都能复算。

交付之后还有一环：业务口径会变，数据会变，使用者也会变。如果只有我们的团队能改，客户用得越久，越被动。所以我们做陪跑时，把力气放在让客户自己具备明确需求的能力上。课堂上我们先向客户完整介绍开发过程：采访、设计、工程、共识、规划、派发、执行，以及修复、回流和监测。接着从采访开始，用现场采访示范，让客户经历“表达、追问、澄清、形成需求定义、本人点评修正”的过程。课后布置两项作业：做出自己的采访 skill，让 AI 在我们不在场时也能持续把需求问清楚；再交一份详细需求书。

这一环的信号是：问题出现时只有外部团队知道该改哪里；业务人员发现“这个数不对”，不知道该找谁，也没有地方登记。

拿四个问题检查一遍：

1. 能不能用一句话说出，谁在什么时刻看到什么，得到什么？
2. 同一个问题问两次，答案一致吗？每个数能追到单据吗？
3. 演示里的数据，是不是正式运行时系统会自己拿到的那一份？
4. 整体效果有没有人单独验过？业务人员发现问题后，知道找谁吗？

四个都能答上，至少说明这四个环节没有明显缺口。卡在哪个环节，就先补哪个环节，不必重做整个项目。

如果你对我们的多 Agent 框架本身感兴趣，可以从 Flowness 项目页了解。作者这样描述这个系列：“烧了粗略估计 1400 亿 Claude token，持续运行超过六个月并真实使用在生产交付的系统中所遇到的问题”。

部分项目可先免费诊断，入口在 https://towow.net/inquiry。

作者：Nature（natureblueee）。