我叫程砚舟，在一家制造企业做数字化与自动化落地，日常工作就是把“能演示”的方案变成“能稳定跑”的系统。过去一年我最常被问的不是“智能技术有多先进”，而是三件更现实的问题：该从哪里切入、怎么选不踩坑、投进去的钱什么时候能回本。下面这份清单写给正在推进项目的业务负责人、IT与工艺工程师，用来对齐口径、压住风险、把收益算清楚。
我见过太多项目开场就从“上智能”“做智能工厂”开始，结果需求越写越大，验收标准越来越模糊。智能技术真正的价值，往往来自把一个具体环节的波动压下去，把一个岗位的重复劳动拿走，或者把一个决策从“拍脑袋”变成“有依据”。
我通常会让业务先把目标写成三类“可验收句子”：
1）效率类：时间、吞吐、等待例子：质检出报告从T+1缩到2小时内；换线准备时间降低到某个区间；客服平均处理时长降低多少分钟。注意别写“提升效率”，要写“减少哪段时间”。
2）质量类：缺陷率、返工率、稳定性例子：某条产线的关键缺陷率从当前水平降到目标区间；同一批次的参数波动范围收窄。质量类目标最好绑定“触发条件”，比如原材料波动、设备老化、班次差异，这样后续模型/规则才能对症。
3）风险类：合规、停机、事故与损失例子：关键设备的非计划停机次数下降；高风险作业的人工确认步骤由系统强制校验。风险类项目常被低估，但在很多行业（化工、食品、医药、能源）反而更容易拿到预算，因为它能把“不可承受”变成“可控”。
把目标写清楚后，我会再加一条“反向约束”：哪些不做。比如“不追求全厂打通”“不做端到端预测补货”“不做跨系统重构”。这条很关键，能让智能技术落地从一开始就有边界。
供应商演示通常很漂亮，真正的难点在你的现场：数据断、口径乱、流程不稳定。我的经验是，选型前把下面四件事摸透，能直接淘汰一半不合适的方案。
1）数据可用性：不是“有没有”，是“能不能持续稳定拿到”检查三点：采集频率是否满足业务节奏、关键字段是否缺失、数据是否能追溯到源头。尤其是视觉质检、预测性维护这类场景，数据的连续性和标注质量决定上限。
你可以用一个很实用的问法逼近真相：
2）流程成熟度：流程越不稳定，越不适合上来就做“智能”现场还在频繁改工艺、改检验标准、改单据字段时，模型很难稳定。更合适的路径往往是先做流程固化与可视化，再做智能优化。否则你会遇到一种很隐蔽的失败：模型本身没问题，但业务规则天天变，导致看起来“模型不准”。
3）系统边界：要明确谁是主系统，谁负责“最后一公里”很多企业同时有MES、WMS、ERP、SCADA、质检系统、工艺数据库。智能应用如果没有明确主系统，最后会卡在“谁写回、谁审批、谁背锅”。我通常在方案里写死三件事：输入数据来源、输出结果落到哪里、触发动作由谁执行（人/系统/设备）。
4）可运维性：模型上线不是终点，是开始问清楚：版本管理怎么做、漂移监控怎么做、报警怎么触发、回滚策略是什么、谁能看懂日志。智能技术在企业里最怕“只有供应商懂”，这会让你在第二年续费与扩容时失去谈判权。
谈回本周期时，我不建议用宏大叙事，也不建议把收益写成“预计提升X%”就收工。更稳的方式是把收益拆成可对账的三段，并把不确定性单独列出来。
1）硬收益：能在财务科目里找到对应项- 人工成本：减少加班、减少外包、减少重复录入
- 报废与返工：材料、能耗、工时
- 停机损失：以工时价值或订单违约成本估算这类收益要尽量能对到财务口径，否则验收时容易“都觉得有效，但谁也算不清”。
2）软收益：不一定直接入账，但能量化- 交期稳定性：延期次数、插单影响
- 客诉与罚款：次数与金额区间
- 合规成本：抽检、审计准备时间软收益可以做“区间估算”，不要写成确定数。
3）成本全景：别只算软件费我会把成本拆为：一次性（实施、集成、改造、培训）、持续性（云资源/服务器、运维人力、数据标注、传感器与相机维护）、机会成本（产线改造窗口、试运行影响产能）。很多项目ROI失真，都是因为只把采购价当成本。
为了让ROI更贴近现实，我会在立项时做两套口径：
- “保守版”：只算硬收益，软收益按0或很小区间
- “业务版”：软收益按合理区间计入当保守版也能接近回本，项目推进会轻松很多。
（关于经济与生产相关的测算口径，我建议参考国家统计局网站对工业增加值、利润等指标的公开解释，用统一口径避免各部门各算各的：来源 https://www.stats.gov.cn ）
真正让效果持续的，不是某次上线，而是持续迭代的机制。我在内部推动时会按“产品化”思路做三件事。
1）建立“可用性指标”，把体验问题显性化比如：每天成功运行次数、数据断流次数、误报漏报记录、人工复核耗时。智能技术一旦进入生产环境，体验就是生命线：误报太多，操作员会绕开系统；漏报太多，管理层会失去信任。
2）把人工复核设计成流程，而不是补丁很多场景不可能做到全自动决策，尤其涉及质量放行、停机、合规。与其追求“一步到位无人化”，不如把“人机协同”设计好：系统给出置信度、给出原因解释、给出建议动作，人工确认后形成闭环数据，反哺模型。
3）明确“谁拥有模型”：业务部门必须参与，不然很难长久如果模型只挂在IT或供应商名下，业务就会把它当外来工具；一旦效果波动，第一反应是“系统不行”。我的做法是让业务拥有验收指标与迭代优先级，IT拥有平台与稳定性指标，形成共同责任。
（如果涉及个人信息或数据合规，实践中我会对照国家网信办发布的相关合规要求与公开指引来做数据分级、脱敏与授权流程：来源 https://www.cac.gov.cn 。不同企业适用条款不同，落地前最好让法务/合规一起评审。）
我最常见的三种误区，几乎每个行业都会撞到：
误区一：数据少也能做出“很准”的预测现实是：数据质量决定下限，业务稳定性决定上限。数据不足时，更适合先做规则+监控，把数据跑顺。
误区二：买一套平台就自动长出应用平台解决的是“搭积木”的能力，应用需要场景、流程、指标、责任人。没有产品化运营，平台会变成昂贵的摆设。
误区三：追求全链路一口吃成胖子智能技术落地更像分期付款：先拿到一个可复用的能力（数据管道、身份权限、日志监控、模型发布流程），再不断复制到下一个场景。
我对智能技术的判断很朴素：它不需要被神化，也不必被妖魔化。只要目标写得可验收、数据与流程能支撑、ROI算得经得起对账、运维机制能让系统长期可用，它就能在企业里稳稳地产生价值。下一次你再听到“我们要上智能”，不妨把这四个词补全：上哪儿、解决什么、怎么验收、谁来长期负责。
