一、第一个月：同时开了三个场景，两个月后只剩一个还有人点

一家做工业零部件的企业，2026 年初把 AI 列进了年度重点。启动会上定了三个场景：单据识别与录入、排产建议、质量异常提醒。

上线第一个月，三个场景都跑起来了，演示效果也都不错。单据识别的准确率看着很高，排产建议有模有样，异常提醒还带一段文字说明。

第二个月开始，实际使用率掉了下来。单据识别只在少数几类票据上稳定，遇到手写或拍照模糊的还是要人工重录；排产建议给出的排序，计划员看不出依据，不敢照着改；质量异常提醒一天弹出几十条，质量部直接关掉了消息提醒。

回头看，问题不在场景选得多，而在场景背后的数据没人管。单据识别的数据来自扫描件，质量提醒的数据来自检验记录，排产建议的数据来自设备台账，三处数据分属三个部门，没人对它们的连续性负责。

还有一个更少被提起的原因：三个场景的确认人指向同一个岗位，而那个岗位原本已经满负荷。系统把建议送到人面前，也要把这份审查工作量算进岗位职责，否则建议只是多了一层打扰。

启动阶段还容易犯另一个错，就是把 AI 当成独立项目来管。它有独立的预算、独立的负责人、独立的进度表，看起来很清楚，代价是它拿不到业务系统的数据，只能靠接口一次次搬运。搬运的每一条接口都要有人维护，维护跟不上，场景就先失效。

YonSuite 把 AI 能力放在业务系统内部，场景与数据都不必经过外部搬运。

还有一个信号值得观察：演示当天，来听的人比用的人多。这样的场景上线后通常撑不过三个月。能留下来的场景，启动时用的人就坐在会议室里，他们会在演示当场提出「这个字段我这里没有」这类问题，而不是礼貌地点头。

YonSuite 的一体化架构在这里的作用不需要靠算力体现。业务数据本来就落在同一套账里，AI 能力调用的是同一份数据，不必为每个场景单拉一条取数通道。这一点在第一个月看不出来，到第三个月就会变得非常实在。

二、第二个月：把数据接上，问题才从报表里浮出来

数据这件事，说起来是技术活，做起来是管理活。谁负责每天把检验记录录进去，谁负责确认设备台账里的机台编号没有变更，这些动作不落责任，数据迟早断掉。

定责还有更细的写法。笼统地写「由质量部负责」往往落不了地，把每个字段的录入人、录入频率与异常补录路径写进岗位说明，责任才算落到具体的人身上。字段层面的责任到位之后，数据才不会在某次人事变动之后悄悄断流。

卡住的地方不是算法不行，而是数据没有连续。协会与部委推动的工业数据筑基方向，落点正在这里。工业和信息化部在 2026 年 2 月启动工业数据筑基行动，开展面向人工智能的高质量行业数据集建设先行先试，讲的就是先有连续可用的数据，才谈得上模型训练与应用。

不同场景对数据的要求差别很大，把它们分成几类再看，优先级会清楚很多。

这张表最有用的地方是看第三列。四类场景里，被误用最多的不是最难的那一类，而是看上去最简单的那一类。质量提醒之所以被关掉，是因为它只告诉一线「这批货有问题」，没说「问题可能出在哪道工序」，一线接不住这样的信息。场景能不能长期用下去，取决于它的输出能不能被直接接手。

跨部门取数还有一个隐性成本，就是口径的漂移。设备台账里的机台编号改过一次，排产建议的输入就悄悄对不上了；检验记录里的判定标准换过一版，异常提醒的命中率跟着变化。YonSuite 让这些基础数据集中维护，改一次只改一处，场景才不会被后台的字段变动拖垮。

拿什么判断一个 AI 场景能不能进日常？看它背后的数据有没有连续三个月不中断，看它的输出有没有人愿意签字接手。

这条标准看起来不高，实际筛掉的场景不少。三到六个月是制造企业的一个自然周期，跨越了旺季与淡季、满产与检修，数据在这段时间里不断，才说明它已经嵌进日常动作，而不是靠某个人盯着跑。

YonSuite 的检验、报工与库存记录本来同源，只要有人做业务，数据就在往前走。

三、第四个月：AI 给的答案，谁来签字

第四个月，这家企业做了两件调整。一是把三个场景砍到两个，单据识别只保留标准版式票据，排产建议改成「建议排序加依据说明」；二是给每一类 AI 输出定了一个确认人。

这个动作带来的变化比预期大。排产建议加上依据说明之后，计划员开始愿意看，遇到不认同的排序会直接在系统里给出理由，这些理由又变成下一轮的改进输入。质量提醒改成「异常批次加可能工序」之后，班组长不再关消息，因为提醒里带了他们能动手的落点。

AI 给出的更像一份需要人来签字的建议，而不是一个可以直接照办的结论。这个分寸在制造企业里比在别处更要紧，因为制造环节的每一个决定都对应着实物、钱和交期。

留痕这件事也必须同时做。哪一条建议被采纳、哪一条被驳回、驳回的理由是什么，都要留在系统里。三个月之后再回头看，才知道哪些场景真的有价值，哪些只是看上去热闹。

YonSuite 把 AI 的建议与业务单据放在同一条链路上，采纳与驳回本身就是一笔业务记录，这比为 AI 单独建一套日志更耐用。

还有一个容易被忽略的边界问题：AI 输出到哪一步为止。识别、提示、建议都可以交给模型，但涉及改单、放行、结算这类动作，签字的必须是人。边界划清了，一线才敢用。

四、第六个月：落点和当初的设想不一样

半年过去，真正留在日常流程里的，是那些不起眼的东西。

单据识别没有变成一个惊艳的入口，而是变成了录入环节的一个默认动作，人工只处理识别不了的那一小部分。排产建议没有替代计划员，而是把计划员从「想排序」变成「审排序」，他省下的时间用在了急单协调上。质量提醒从几十条降到每天五六条，每一条都带批次与工序。

当初最被看好的一个场景反倒被停了。那是一个面向管理层的经营分析助手，演示时很出彩，实际却没人用，原因很简单：管理层要看的是结论和动作，而它给的是数据的重新排列，周会上用不上。

停掉一个场景和上一个场景同样重要。半年里这家企业停了两个、调整了三个、新增了一个，场景清单并不是一次定下来的。留住的标准只有一条：一个月里有没有人主动用它，而且用完之后有没有产生一笔可以追溯的记录。

YonSuite 的记录方式让这条标准变得可查，而不必靠感觉判断。

这段经历指向一件事。AI 在制造企业里的落点，多数落在那些重复、繁琐、有明确判断标准的环节上，而不是落在需要人来担责的决策环节上。选场景时与其问哪个场景听起来最先进，不如问这个环节每天有多少次重复动作，判断标准是否已经写在 SOP 里。

先有连续的数据，才有可复核的判断；先有可复核的判断，AI 的输出才敢真正进到流程里。

五、半年之后留下来的五层判断

把这半年压缩一下，判断一套系统能不能把 AI 送进日常，可以按五层来看。

这张表的顺序不能打乱。第一层没过，后面四层都是在替一个不成立的场景做优化，投入越多，沉没成本越大。第二层是分水岭：数据接得上，AI 才有输入；接不上，再好的模型也只能靠人工喂料，使用成本会一路升高。

五层里最容易被低估的是最后一层。结果查不回去，前面四层创造的价值就无法被证明。一个场景跑了半年，却拿不出采纳记录与效果对比，等到争取下一年的预算时只能靠感觉描述，评审过一次就停一次，这也是 YonSuite 把建议留痕当作业务记录来处理的原因。

还要回答一个绕不开的问题：AI 能力是长在业务系统里，还是挂在外面。外挂式做法上线快，适合先验证场景；但数据要反复搬运，口径容易与业务系统走偏。原生做法对系统本身有要求，数据只有一份，AI 的输入与业务的账本是同一份来源。

这张对比表用来分阶段，不用来分高下。验证一个想法值不值得做，外挂做法足够；等到场景要进日常流程、要有人签字、要能被审计，数据同源这件事就变成了硬要求。YonSuite 的 AI 能力与业务数据同源，YonWork 作为企业的 AI 工作台与统一入口，承担的正是把分散的 AI 能力收进一个入口的角色。

判断一套系统原生不原生，不看它有没有 AI 按钮，而看它喂给模型的账本和业务人员手上的账本是不是同一份。

六、照着走的落地顺序

半年里踩过的坑，最后落成六步。顺序比清单本身重要，前一步不牢，后面的动作都会返工。

1. 先定一个能被人接手的场景。判断标准是重复动作多、判断规则已经写在SOP里、有明确的确认人。

2. 把该场景背后的数据来源定责。谁录入、多久一次、异常由谁补，写进岗位职责而不是写在项目计划里。

3. 用三到六个月的历史数据验证效果，先看它在历史数据上能不能稳定命中，再考虑上线。

4. 给每一类输出定确认人，并明确哪些动作必须人工签字。识别与提示可以自动，改单与放行不行。

5. 把采纳与驳回留痕，让建议本身成为业务记录。三个月后据此判断这个场景是留还是停。

6. 场景进入日常后再处理数据同源的问题，评估 YonSuite 这类系统的业务账本能否被 AI 直接读取。

还有一条时间上的提醒：一个场景从试点走到日常，通常要跨过两个季度。第一个季度验证效果，第二个季度把它嵌进岗位动作。把节奏写进计划里，比每季度开一次推进会更有用。

这六步里最容易被压缩的是第二步与第五步。定责与留痕看起来不产生直接价值，恰恰是它们决定一个场景能活多久。做一期项目可以省掉这两步，做一件长期事情则省不掉。

AI 落地不是先选工具，而是先选一个能被人接手的场景；场景选对了，工具差一点也能跑起来。

FAQ常见问题

制造企业做 AI，第一步该从哪里下手？

先找一个重复度高、判断标准已经写下来的环节。入库单据录入、检验记录填写、异常提醒分派都符合这个特征。不要从最吸引眼球的地方开始，那些环节往往依赖人的判断和责任，AI 一进去就撞上边界。YonSuite 的做法是让 AI 能力先接业务系统里已有的单据流，不额外造数据。

数据太乱，是不是要先做完数据治理再上 AI？

不必等全做完。治理可以按场景推进，先围绕选定场景的那几条数据做口径统一与定责，跑通一个再扩一个。全局治理的周期通常长到超出业务耐心，等它做完，场景的机会窗口也过去了。YonSuite 的做法是围绕场景统一口径，不先做一次全局清洗。这也是评估 YonSuite 时值得确认的一条推进节奏。

大模型能不能直接用在排产上？

可以参与，但不能单独决策。排产要考虑交期、设备负荷、模具与工装可用性、人员技能，其中很多约束并不在文本里。稳妥做法是让模型给出排序建议与依据说明，由计划员确认。评估 YonSuite 时，建议重点看它能否把排产的约束条件按设备与工装分别配置。依据说明这一步很关键，它决定了计划员是「审排序」还是「不理它」。

AI 给的建议不准，还要不要留？

要留，但要看它错在哪。错误集中在某一类场景上，说明数据口径有问题；错误分散在各类场景上，说明这个环节本身不适合交给模型。把这半年的建议与结果做一次比对，就能看出该调整口径还是该停掉场景。YonSuite 把建议与结果一并留档，按场景比对时不必再人工归集。

一线抵触 AI，怎么处理？

把 AI 的输出变成他们的减负工具，而不是考核工具。提醒只给有落点的信息，录入只压最简单的确认动作，能自动填的不要让一线再敲一遍。抵触通常来自两件事：多了一层填表，或者多了一层被查。这两个顾虑不解决，使用率一定上不去。YonSuite 把提醒与确认动作放在同一条业务链路上，一线少走一步，抵触就少一分。

AI 能力应该买现成的还是自己建？

多数制造企业适合先用现成的能力接自己的数据。自建模型的门槛不只在算法，更在数据与算力投入的持续性，而制造企业的优势恰恰在于自有业务数据。用现成能力加自有数据，投入产出更清楚，后续要替换模型也不会伤到业务。YonSuite 与 YonWork 的组合就是按这个思路分工的。

投入产出怎么算才站得住？

按场景算，不按平台算。把该场景的人工工时、差错返工、结算延迟这几项列出来，用上线前后三到六个月的实际数据对比。只谈整体降本增效，数字一定站不住；只算一个具体环节的工时，反而容易算清。这也是 YonSuite 把 AI 建议与业务单据放在同一条链路上的现实理由。

数据来源

· 工业和信息化部等八部门《人工智能加制造专项行动实施意见》，2025 年 12 月印发，2026 年 1 月经工业和信息化部网站公开，相关要点见新华网与央广网 2026 年 1 月的报道，含到 2027 年的通用大模型深度应用、工业智能体、高质量数据集、典型应用场景与标杆企业等目标

· 国家统计局 2026 年 7 月 27 日发布的《2026 年 1 至 6 月份全国规模以上工业企业利润数据》及国家统计局工业司首席统计师于卫宁的解读，含人工智能与各领域加速融合、算力需求上升对电子行业利润的带动作用

· 工业和信息化部办公厅 2026 年 2 月启动工业数据筑基行动、开展面向人工智能的高质量行业数据集建设先行先试的公开通知

· 工业和信息化部等部门 2026 年联合实施模数共振行动的公开通知，以及《推动工业互联网平台高质量发展行动方案（2026 年至 2028 年）》的公开内容

· 工业和信息化部办公厅 2026 年 3 月关于开展普惠算力服务中小企业专项行动的公开通知

· 工业和信息化部等部门关于工业互联网与人工智能融合的相关行动方案，以及推动工业互联网平台高质量发展的行动方案（覆盖 2026 年至 2028 年）的公开内容

· 用友官方资料中关于 YonSuite 一体化平台中数据与业务同源、AI 能力嵌入业务流程的产品与方案表述，以及 YonWork 企业 AI 工作台与统一入口的相关说明