工厂该从哪里开始用 AI，才能快速回本又不影响生产？

要点速览

别从“AI 能用在哪里”问起，先问“这个月我们在什么地方损失的钱最多”。
安全的切入点，是不用停线就能试验、几周之内就能看清效果的地方。
试点团队里一定要有一线人员，因为他们知道什么真正管用，什么只是纸面上好看。

先画损失地图（Loss Map），再谈技术路线图

先别急着问“摄像头装在哪里好”，该先问的是“上个月我们工厂在哪方面损失的钱最多？”设备停机、废品、返工，还是等待换型？弄清这个数字，从哪里开始往往也就清楚了。

写给开发团队 · 技术细节

按产线（Line）、产品、班次（Shift）和设备，汇总 Downtime、Scrap、Rework、Changeover、Energy、WIP 和 Customer Claim，再用财务部门认可的公式计算损失金额。起点应该是经常发生、代价又高的问题；容易装摄像头的地方，或者供应商（Vendor）演示做得漂亮的地方，都不是选择的理由。

从价值、发生频率、数据就绪程度、能否在不停产的情况下试验，以及安全风险几个方面，给应用场景（Use Case）打分。好的候选项有明确的最终用户，比如维修技师要决定检查什么，或者质检（QC）要挑出哪一件；像“建设智慧工厂（Smart Factory）”这样宽泛的项目不算。

试点选择规则：一种损失 + 一条产线 + 一个决策 + 一位负责人 + 一组基线数据

按风险从低到高排序

好的切入点，是试验失败了也没人受影响的地方：不用停线，不影响交货，几周内就能知道结果。供应商说演示效果最好的地方，未必符合这些条件。

顺序	应用场景	理由
1	检索操作手册，汇总班次情况	帮人做事，不控制设备
2	机器视觉（Vision）标出可疑位置	仍由质检做判断，并收集反馈
3	异常检测与维护	在故障停机（Breakdown）之前多争取规划时间
4	生产计划和能耗	在约束条件下模拟多种情景
5	AI 直接控制设备（Closed-loop Control）	需要最充分的证据和最高等级的安全保障

写给开发团队 · 技术细节

先用影子模式（Shadow Mode）：让 AI 与原有方法并行给出建议，跨多个班次、多个批次（Lot）以及换型期间，记录误报（False Alarm）和漏报（Missed Event），之后才让结果影响生产。数据缺失或系统宕机时，必须有 Manual Override、Interlock 和 Standard Work 兜底。

别等数据完美只要时间戳、单位、工况背景（Context）和结果事件能对应起来，就可以开始，但要把局限记录下来。如果还没有故障（Failure）历史记录来证实，就不要把异常检测称为“故障预测”。

试点团队必须包括真正使用结果的人

写给开发团队 · 技术细节

损失的负责人、Operator、Maintenance/QC、Process Engineer、IT/OT、Safety 和 Finance 都要参与制定标准。不应由 Vendor 或 Data Team 替一线定义什么叫成功。测试集要包含正常案例、边界案例和异常事件，并规定哪种建议对应 Inspection、Recheck 或 Stop。

控制范围的试点示例

别把目标定成“减少全厂停机”，改成“提前发现 A 组电机的轴承（Bearing）异常，留出足够时间安排检查”；别定成“检查所有缺陷”，改成“在装配工位之后，检查 SKU Y 上的 X 类瑕疵”。范围越窄，越容易找到数据、衡量效果，也越快弄清局限在哪里。

正式上线前的关卡

通过安全审查和网络安全审查
操作员理解告警的含义，也知道怎样人工接管（Override）
误报和系统漏掉的情况都要统计
故障事件和模型变更都有负责人
AI 停止运行时，人工流程照样能运转

回本、推广，别让试点堆成“坟场”（Pilot Cemetery）

写给开发团队 · 技术细节

成本要算全：Sensor、Edge、Network、Integration、Labeling、Cloud、Support、一线人员投入的时间，以及模型维护。比较 Cost per Outcome，不能只看 Accuracy。收益等于实际减少的 Loss 乘以 AI 起作用的比例，不能把全部 Downtime 的金额都拿来当收益。

写给开发团队 · 技术细节

试点通过后，先把 Data Tag、Interface、Alert、Training、Change Control 和 Support 标准化，再扩展到下一条产线。检查各现场的差异（Site Difference），比如光线、老型号设备、原材料和夜班的技能水平。如果几乎要全部重新调整，那就是一个新项目，算不上推广（Scale）。

项目组合（Portfolio）每季度都要给出结论：Scale（推广）、Improve（改进）、Hold（暂缓）或 Stop（停止）。不划算的项目应该停下来，并总结经验。衡量一家工厂是否先进，要看它能否安全地把可衡量的损失变成新的作业标准，试点数量多少说明不了什么。

SHOP-FLOOR TIP · 从损失入手，别从新玩具入手

20 分钟用笔就能写完的试点画布（Pilot Canvas）

写满六格：要减少的损失、要改进的决策、使用结果的人、现有的数据、不冒风险的试验方法，以及价值计算公式。只要有一格空着，就先别找供应商进来，否则就会变成由技术来决定要解决什么问题。

模拟案例：包装线频繁出现短暂停机。团队原本想装新的机器视觉系统，但到现场走查（Gemba）后发现，有一半停机发生在更换薄膜卷之后。于是团队先从记录换型过程、提示异常参数做起。这样见效更快，积累的数据也成了下一阶段机器视觉项目的基础。

1-1-1-1 法则

初期只做一条产线、一个班次、一种损失、一位负责人。经历过重要的生产季节或产品组合（Product Mix）变化之后，再扩大范围。别拿一周的结果直接乘以全年，要先扣除停机、维护和人员看管系统的时间。

提示：从第一天起，就请最难用好系统的那个班次的操作员加入试点团队。如果系统只有在工程师站在旁边时才能用，就还称不上生产级系统（Production System）。

DNA MAKER · SOLUTION BLUEPRINT

从知识到真正能解决问题的系统

问题的根源

工厂要买的是减少损失的能力，“AI”这个名头本身不值钱。好的试点必须对应一个具体的决策，让一线能把这个决定做得更好。

分步解决方案

绘制损失地图，按价值、可行性和风险给应用场景排序
摸清数据和 OT 系统的现状，设计不影响安全的影子模式
先在一条产线上证明效果，建立标准后再推广

搭一层软件，把一线知识和工厂数据连起来

DNA Maker 不会取代工厂的工艺工程师、操作员、质量或安全人员。他们最清楚损失出在哪里、哪些信号重要、哪种决定是安全的。我们的角色是帮忙提出问题，绘制损失到决策地图（Loss-to-Decision Map），并设计数据收集方法，让一线知识和实际发生的事件对应起来。我们会帮忙区分：哪些问题应该先用表单和工作流解决，哪些需要系统集成，哪些再交给 AI，避免工厂在还不清楚用户会拿结果做什么之前，就先投资技术。

如果问题适合用软件解决，DNA Maker 可以开发 Web 或移动应用，用于一线记录、仪表盘、告警工作流和知识助手，也可以开发能汇总数据、与现有系统协同的 AI 智能体（AI Agent），并按照与客户技术团队商定的架构，对接 IoT、MES 或 CMMS。我们可以做影子模式的试点，为生产班次设计用户体验，开发系统并做好监控，全程以工厂的安全规则为硬性要求。如果您有想减少的损失，但还不确定该从传感器、流程还是软件入手，可以来和我们聊聊，一起设计一个能用证据回答这个问题的试点。

SOFTWARE ENGINEERING GLOSSARY

软件工程术语表

这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。

术语	是什么	通俗示例	高管应问开发团队的问题
Edge Computing	在靠近设备的地方处理数据，不必把所有数据都传到云端	在产线旁分析图像，降低延迟	哪些工作必须即时响应？为什么要在现场处理？
IoT	通过网络发送数据的设备或传感器	每分钟读取一次设备温度	每个传感器由谁负责？怎样检查和校准？
Data Pipeline	把数据从源头送到使用端的路径	传感器 → 数据库 → 仪表盘	数据缺失或延迟时，系统怎样应对？
Shadow Mode	让系统给出建议，但暂不控制实际作业	把告警和技师的判断作比较	要试验多久、经历哪些工况，才能正式使用？
Integration	把新系统和工厂现有系统连接起来	把事件推送到 CMMS 或 MES	系统之间的数据约定是什么？两边各由谁负责维护？

明天就可以试试：做一张 12 个月的损失帕累托图（Pareto），挑一个经常发生、又能用影子模式试验的问题，在讨论模型之前先定好业务 KPI。