企业级 AI 应用建设的 4 大难题：试点很成功，推广却熄火
几乎每家做过 AI 试点的制造企业，都经历过同一幕：演示时全场点头，三个月后没人打开。问题很少出在模型身上，而是卡在四件建设初期就该面对、又最容易被跳过的事上。
读这一篇能得到什么
- 四道坎依次是数据散、不懂行、不落地、算不清，顺序还不能颠倒
- AI 会把互相矛盾的口径缝成一个完整的故事——这比答不上来更危险
- 通用大模型懂语言不懂业务，8D、工序代号、客户特殊要求都得先教它，而且要能指出出处
- 判断 AI 有没有真的落地，只看一件事：它下线一周会不会有人来找你恢复
- 安全、责任、ROI 三笔账里只要有一笔算不清，项目既过不了立项，也过不了验收
难题一：数据散，巧妇难为无米之炊
一次月度质量评审，质量经理报上月的来料不良率是 2.3%，采购经理当场反驳说他的口径下是 4.1%。两个人吵了十分钟才发现都对：一个按批次算，一个按采购金额算；一个取 QMS 的检验结论，一个取 ERP 的退货记录。数据都在系统里，只是从来没有被对齐过。
这类争论在人的会议上是十分钟，在 AI 面前会被放大成一种更麻烦的形态：它不会说「你们口径不一致」，而是会把两个数字缝成一个看起来完整、读起来顺口的结论——比如取了一个中间值，再配上一段关于「整体质量稳中向好」的表述。管理人员看到的是一个自信的答案，而不是一场没吵完的架。一个自信但错误的答案，比一句「我不知道」伤害大得多，因为它会被当成依据继续用下去，一直用到某个客户投诉把它翻出来。
所以对 AI 来说，「数据散」不是可以边用边补的小毛病，而是一道准入题。制造业的数据通常散在 ERP、MES、QMS、WMS、Excel 和纸质单据之间：同一物料多个编码，同一客户多个简称，同一指标多套算法，同一份单据在不同系统里状态不同步。模型能力再强，也无法从矛盾输入里推出可信输出——它没有额外的信息源，只能在你给的素材里打磨出一个最像答案的东西。
当场自检：不看系统、不问人，能不能说清「上月来料不良率」这个数字来自哪张单、按哪个口径、覆盖哪些组织？如果回答这个问题需要三个人凑在一起对口径，那 AI 上线只是把这场争论加速了——它会把三个答案同时呈现出来，还都带着确信的语气。
务实的做法是先做两件不出彩的事：主数据的唯一来源，以及指标口径字典（谁定义、何时生效、变更留痕）。然后让 AI 只消费已经冻结的口径。这一步没有捷径，也不存在哪个模型能替你跳过。跳过它的项目，通常会在半年后绕回来补，只是那时预算和耐心都已经消耗掉一部分了。
难题二：不懂行，通用模型答非所问
把一起客诉的经过贴给通用大模型，让它「帮我分析原因」，得到的通常是一份漂亮的通用模板：先确认问题描述、再分析可能原因、最后制定纠正措施并跟踪验证。流程没错，用不上——因为你们真正需要知道的是：这是本月同一工序的第二起，上一起的纠正措施还在验证期没关闭，而客户在三个月前刚提过同类特殊要求。这三条都在你们的系统里，模型一条也不知道。
模型掌握的是语言规律，不是你的业务约束。它不知道你们厂的工序代号代表什么，不知道 8D 里的根本原因追到哪个颗粒度才算过去，不知道客户特殊要求（CSR）台账里写着什么，也不知道 IATF16949 对整改闭环在时间与证据上的审计预期。这些知识不在公开语料里，只能从企业自己的资料中来：制度文件、SOP、历史单据、不良代码字典、客户特殊要求台账、以往审核的整改记录。
关键在于注入的方式。把这些资料一股脑塞进上下文，得到的往往是更危险的东西——一个能引用专业术语、却指不出出处的回答。它比通用模板更像是内行说的，因此更难被当场质疑，也更难事后纠错。合格的行业知识注入必须可检索、可引用：回答能说出这句话依据的是哪份文件的哪一版、哪一批单据，让人可以顺着线索自己去核。
这里正好用得上一个判断原则：错误代价不对称。AI 生成一份生产资料清单，错了改一次；AI 给出一个质量判断，错了可能已经放行了一批货。所以行业场景里更稳的分工是——AI 负责把三小时的翻档案压缩到三分钟，给出候选与线索；判断与签字仍然留给人。它不替你做结论，只让你在做结论前少翻几箱纸。
当场自检：拿你们内部一个真实的术语或不良代码去问它，看它是答对了，还是编了一个听起来很合理的解释。这一问能很快分出「懂行」和「像懂行」。连这一步都答不准的话，它在评审会上帮不上忙，只会给会议多贡献一段需要被纠正的内容。
难题三：不落地，智能体停在对话框
试点阶段做了问答机器人和文档总结，反馈还不错。演示了两个月，后台访问记录掉到个位数。原因通常不是不好用，而是它不在任何人的工作路径上——要用它，得先想起来有个对话框，再切过去，再组织好怎么问。这三步中的任何一步，都足够让人回到原来那套办法去。
企业软件的使用从来是被流程推着走的：待办不办会超期，单据不审就流不下去，报工不填月结过不去。挂在流程上的功能，不用人记得它；只在对话框里等着的功能，永远排在「等等再说」那一栏。
检验标准可以非常简单：这个 AI 功能停掉一周，会不会有人来找你恢复？没人来，就说明它还没进流程。这个问题比任何使用率报表都准，因为它问的是依赖，不是兴趣。
能真正落地的形态，是嵌进既有节点，而不是另开一个入口。制造业里几个具体的例子：不合格品评审单打开时，自动带出同类历史 NCR 以及当时采用的处置方式和最终结果；来料检验录入前，带出该供应商近 90 天的不良走势与尚未关闭的 8D 单；生产报工提交时，对超出历史波动范围的数值给出提示与可能原因；变更单提交时，列出与本次变更相关联的在途变更，避免改一处漏三处。这些形态有个共同点——用户不需要「去问 AI」，AI 出现在他本来就要操作的那一步；它给出的是可核对的候选与线索，不是替他拍板的结论。
顺带划清边界：智能体是加速层，不替代组织、权限、表单、流程、报表与集成里的任何一环。它可以推待办、给提示，也可在本人权限内经业务接口创建单据、办理审核；不自动代他人审批，不改主数据，不越过行级权限，不直写数据库。把它当成第 N 个业务模块会更清楚——它有明确的输入、明确的边界、明确的责任人，而不是一个什么都能问的窗口。
当场自检：列出你最常用的三个业务动作，问自己 AI 有没有出现在其中任何一步上。如果只在第四个「不知道找谁的时候」才想起来用它，那它还没落地，只是多了一个可选的聊天入口。
难题四：算不清，三笔账过不了立项
前两道坎过了，第三道也做了，最后往往卡在会议室里。不是技术问题，是三笔账没人能当场算清。
安全账——数据能不能出企业。哪些字段允许走外部模型、哪些必须留在内网、调用外部能力时留了什么样的记录。这道题最容易拖到最后才想，而它一旦结论是「不能出」，前面按外部模型做的方案就要推翻重做。早问一个月，省下的往往是整个工期。
责任账——AI 给的建议导致一次错判，谁担责。如果回答是「AI 建议的」，这个项目就不该上线，因为那等于没人负责。可接受的设计是：AI 只在人做决定之前提供线索，决定与签字仍由人完成，并且每次生成与采纳都留痕，能够回答「谁在什么时候、依据哪份知识、做了什么决定」。留痕不是为了追责，而是为了让所有人敢用。
ROI 账——这笔账最容易算糊。把收益写成「效率提升 30%」是无法取证的，验收会上必然吵起来，而且吵到最后通常不是输在收益不够，是输在说不清。能过关的写法是把收益落到可取证的四类上：人力工时、报废与返工、审核与合规成本、交付与现金周期，每一类都说清改进前后各自的取证方式。取不到证的收益，再动人也不要写进立项材料。
| 这笔账 | 要当场回答的问题 | 算不清的后果 |
|---|---|---|
| 安全账 | 哪些数据能出去，调用记录留在哪里 | 方案中途推翻，工期与信任一起赔进去 |
| 责任账 | 出错时能否定位到人、到知识版本、到数据批次 | 出了事没人敢用，功能上线即闲置 |
| ROI 账 | 每一条收益怎么取证 | 验收会变成争论会，下期预算批不下来 |
三笔账里只要有一笔算不清，项目就过不了立项；勉强上了，也过不了验收。这三笔账还有个共同特点：它们都不在演示里，所以最容易被跳过，也最容易在结项时一次性找回来。
当场自检（安全账）：列出你们最敏感的五个字段，看现在的方案有没有明确它们能不能出境、由谁批准、记录留在哪里。
当场自检（责任账）：假设 AI 的一次错误建议导致了一批误判，你们能不能在两小时内定位到是哪个版本的知识、哪一批数据导致的？答不出来，说明留痕还没设计。
当场自检（ROI 账）：把预期收益逐条问「这条怎么取证」。凡是答不出取证方式的那几条，直接从收益表里划掉——早划掉，比在验收会上被人替你划掉要好。
顺序错了白花钱：四道坎有先后
这四道坎不是四个可以随便挑的选题，它们之间是有依赖的顺序：数据与口径不统一，喂进去的就是矛盾输入；知识不可溯源，越懂行的回答越危险；没进流程，再准也没人用；三笔账算不清，前面三条做得再好也过不了立项。任何一环跳过，后面都要回头补。
最常见的翻车姿势恰好是把顺序倒过来：先买了模型和平台，再回头补数据与口径。预算是花在看得见的部分，卡住的是看不见的部分，半年后项目被打上「AI 不成熟」的标签搁置。真实原因往往不是 AI 不成熟，而是顺序错了——而且这个错误的成本，最后会算在 AI 头上，让下一次立项更难。
| 这道坎 | 典型症状 | 跨过之后才做 | 没过时的务实动作 |
|---|---|---|---|
| 数据与口径 | 同一指标三个数，谁也说不清来源 | 让 AI 消费已冻结的口径 | 先做主数据唯一性与指标台账，AI 只辅助录入与校验 |
| 行业知识 | 回答漂亮但用不上，术语对不上 | 让 AI 参与质量与交付的判断辅助 | 先建可溯源知识源，从检索与引用做起，不急着做生成 |
| 流程嵌入 | 演示时惊艳，之后没人打开 | 把 AI 放到决策节点之前 | 从本人权限内的提示与办理起步，不自动代批、不直写库 |
| 三笔账 | 立项会被问倒，验收会变争论会 | 扩大场景范围与组织试点 | 先做一笔账最小的场景，通常是内部辅助型 |
还有一句务实的话值得放在项目章程里：四道坎没过第二道时，宁可晚半年上经营问数，也不要用一次答错消耗掉管理层的信任。信任是一次性资源，用一次错答案换来的教训，比多等三个月贵得多——而且它消耗的不只是这个项目，还有下一次申请预算时的信用额度。
顺序对了，也不用等到全部准备完毕才动。更可行的做法是让 AI 先在低代价场景里跑起来（辅助录单、相似案例检索、字段校验），用真实使用记录去暴露数据最乱的环节，反过来推动口径治理。两条线互相推着走，比等一个完美起点更接近落地。
JEDP数字化平台把这件事写在产品结构里，而不是留到方案汇报里再解释：AI 作为加速层挂在既有引擎之上，设计侧的生成必须经人确认才生效，运行态问数只消费已经冻结的口径；创建单据与办理审核只经业务接口，不超过本人权限，全程留痕，权限继承使用者本人范围而不额外放大可见数据。选型时可以直接拿这四条去对照——如果对方讲不清楚一个提问者能看到哪些数据、答错了怎么定位，那说明这四道坎他们还没走过。
想拿这四道坎体检一下自己厂里的情况？资源中心有对应的在线自测与资料模板，也可以直接约一次真实环境演示。
常见问题
围绕本篇主题的追问，先看这里；仍有疑问可联系我们
四道坎里，哪一道最难？
数据与口径。它不出现在任何演示里，也没有技术亮点，却决定了后面三步能不能做。大多数项目回头看卡住的地方，都是这一道——而且它越晚补，代价越高。
上了 AI 之后反而更乱了，是怎么回事？
常见两种情况。一是口径没统一就让 AI 直接出结论，它会把矛盾的数字缝成一个完整的故事；二是 AI 的可见范围比使用者本人还大，把不该看的数据问了出来。前者伤判断，后者是泄露，两种都要在设计阶段挡住。
我们数据本来就乱，是不是就没法用 AI 了？
可以用，但要缩小到低代价场景：辅助录入、相似案例检索、单据字段校验这类「人最后还要再核一遍」的用途。让 AI 先在这种场景里跑，反而能最快暴露出数据最乱的环节，成为治理的入口，而不是等到治理完才敢用。
能不能先私有化部署一个大模型，其他慢慢来？
不建议把顺序倒过来。模型是四道坎里最容易获得、也最容易被替换的一环。先有可信数据与可溯源知识，模型能力才有地方发挥；否则上线之后收到的差评，八成不是模型的问题，却都会算在模型头上。
怎么判断 AI 是真用起来了，还是只是试点好看？
两个硬指标：功能下线一周有没有人来找你恢复；使用是否集中在演示期之后的日常而非汇报节点。再补一条软信号——用户开始抱怨「这里怎么没有 AI」，说明它才算真的进了工作流。