前言：为什么写这个系列
我在一家大型显示终端制造企业的信息中心做 MES / OA 开发。入职 4 个半月，独立完成或推进了 16 个功能：制程破屏率自动监控、条码追溯体系、超周期发料管控、SMT 抛料数字化采集、老化测试产出自动推送、跨企业质量数据对接......
这个系列不做概念科普，只讲真实项目里怎么想、怎么做、踩了什么坑。文中所有业务参数、表名、字段名均已脱敏，涉及的人员、客户、子公司一律以角色或代号指代。
第 1 篇先解决一个前置问题：制造业 MES 开发，到底和互联网业务开发有什么不一样？ 这个认知如果没对齐，后面所有的技术决策都会跑偏。
一、先建立一个整体认知：MES 在工厂里是什么位置
制造业企业的信息系统通常是分层堆叠的：
MES 的核心使命就一句话：把生产现场发生的每一件事，变成可查询、可追溯、可统计的数据。
具体到电视整机/基板制造，MES 要管的事情大致包括：
|------|------------------|-------------------|
| 模块 | 典型功能 | 我实际做过的对应项目 |
| 工单管理 | 工单下发、结单、未结单推送 | MES 日报表增加纯贴片机型 |
| 制程管控 | 工序流转、节点卡控、防呆校验 | 前护屏加工防呆、基板节点卡控 |
| 物料管控 | 发料、退料、超周期管控、批次追溯 | 超周期发料管控重构 |
| 质量管理 | 首件检验、不良记录、CPK 分析 | 30PCS 首件 OQC 检验查询 |
| 条码追溯 | SN 生成、绑定、核对、补印 | SKD 条码核对补印、一联五式 |
| 设备采集 | 老化测试、烧录、测试工位数据 | 老化产出自动统计、IC 烧录 |
| 报表推送 | 日报、月报、异常预警 | 每日生产数据邮件推送 |
二、差异一：需求来源------没有产品经理替你把需求想清楚
互联网团队里，需求由产品经理梳理成 PRD，附交互稿和验收标准。在制造业，需求的来源是这样的：
举个真实例子。我接到的第一个核心需求，原文是："破屏率超标要自动触发 OA 奖惩流程，现在全靠人工统计，严重浪费人力。"
这句话里至少有 7 个未定义项：
- 破屏率按什么维度统计？（线体？车间？生产部？）
- 统计周期是日还是月？
- 阈值是多少？不同尺寸是否不同？
- 超标的判定是"大于"还是"大于等于"？
- 数据来源是哪张表？哪些退料类型算破屏？
- 触发给谁？罚款怎么分摊到责任人？
- 已经触发过的能不能重复触发？
这些问题，需求方在你问出来之前，往往自己也没想清楚。
我的处理方式是：先调研存量 → 再做 Demo → 拿 Demo 去问 → 再定方案。具体是：
- 找到系统里已有的类似插件（一个 SDPH 插件），看它的代码结构和调用方式
- 找到业务同事，完整走一遍现有的人工操作流程（选择明细 → 生成处罚单号 → 金额汇总 → 上传附件提交）
- 拿一份真实数据，按我想的方案跑出一张统计表，直接给业务方看："是这个意思吗？"
- 业务方看到具体数字，才会开始提出真正的需求细节
可复用经验 ：在制造业，Demo 是最好的需求文档。你给业务方看一页带真实数据的表格，比给他看 10 页方案设计文档有用得多。
三、差异二：验收标准------"产线不能停"压倒一切
互联网系统的验收标准是功能可用、性能达标。MES 系统的验收标准多了一条硬约束：
任何情况下，不能让产线停下来。
这条约束会直接改写你的技术决策。举两个我遇到的例子：
案例 1：超周期发料管控重构
原逻辑对临期物料也做拦截（设了"最低剩余缓冲阈值"）。从质量角度这没错，但从产线角度，物料明明还有 3 周才过期却被锁死，产线就开不了工。
重构时我做的第一个决策就是：取消缓冲阈值，只在真正超期时拦截。临期物料正常放行，由现场自行安排烘烤。
案例 2：新旧插件并行运行
重构后的插件不直接替换旧插件，而是部署到新菜单下，与原插件并行运行，两边数据比对一致、业务确认无异议后才下线旧的。
这在互联网开发里看起来是"浪费"，但在制造业是必须的------一旦拦截逻辑写错，整条产线的物料就发不出去。
|------|------------|--------------------|
| 维度 | 互联网业务开发 | 制造业 MES 开发 |
| 上线方式 | 灰度、蓝绿、随时回滚 | 新旧并行 + 数据比对 + 业务确认 |
| 回滚代价 | 用户看到旧版本 | 可能已经产生错误的实物操作 |
| 发布窗口 | 随时（甚至一天多次） | 停线时段、节假日、班前班后 |
| 失败影响 | 局部功能不可用 | 停线 = 按分钟计算的产值损失 |
四、差异三：失败成本------从"线上回滚"到"批量品质事故"
这是最容易被低估的一点。
我在做条码核对功能时，需求方反复强调的一个场景是：SN 码贴错，产品出货到客户手里，后面出了质量问题，整批货都追溯不回来。
类似的失败场景还有：
- 前护屏的 EPE 缓冲垫型号用错 → 批量面板损坏
- 超周期 PCB 未烘烤直接投线 → 批量焊接不良
- 老化测试未做就出货 → 客户可靠性投诉
这些失败都不可回滚。 代码能回滚，已经贴错条码的几千块板卡不能。
这就解释了为什么 MES 系统里到处都是"防呆设计"：
|------|--------------------|-------------------|
| 防呆手段 | 作用机制 | 我的应用 |
| 强制校验 | 不通过就无法进入下一环节 | 前护屏 EPE 与护屏品号绑定校验 |
| 物理反馈 | 蜂鸣器 + 红叉，噪音环境下也能感知 | SKD 条码比对不一致报警 |
| 幂等约束 | 防止重复操作造成脏数据 | SN 码禁止重复打印 |
| 节点卡控 | 工作流不允许跳过 | 基板工作流关键节点校验 |
| 台账留痕 | 事后可追溯责任人 | 条码申请台账、补印记录 |
认知转变 ：在互联网，"能用就行"是合理的最小可行性；在制造业，"错了也能拦住"才是第一优先级。
五、差异四：技术栈------不要指望用上最新框架
MES 项目的技术栈通常不是你能自由选的，而是被平台和存量代码锁定的：
|-------|---------------------|------------------------|
| 层次 | 常见技术 | 说明 |
| 业务逻辑 | SQL Server 存储过程 | 核心计算逻辑大量写在存储过程里 |
| 界面与流程 | 低代码插件平台 | 表单、工作流、报表通过配置 + 少量脚本实现 |
| 移动端 | 安卓 PDA 原生/混合应用 | 扫码、录入、现场校验 |
| 集成 | API 平台 + 定时任务 | 跨系统数据同步、消息推送 |
| 消息 | 企业微信机器人 / 邮件 | 日报、月报、异常预警 |
我在 4 个半月里实际用到的技术栈：
- MES 低代码插件开发：Browser 平台标准插件 + 移动端 PDA 插件，涉及事务对象、移动事务对象、标准元对象等多种插件类型
- SQL Server 存储过程 ：复杂聚合、跨库查询（MES ↔ OA）、自定义函数、
OUTER APPLY区间匹配、编码前缀清洗算法
- API 平台定时任务：定时触发计算、调用外部接口、失败重试
- 企微机器人 + 邮件推送：Webhook 消息卡片、HTML 邮件模板
- 接口对接 + JSON 解析：CPK 制程能力指数的计算与解析
- AI 辅助编程：用 AI 排查 API 报错、生成代码原型、生成设计文档
这里要澄清一个常见误解："存储过程 + 低代码"不等于技术含量低。
真正难的不是语法，而是：
- 在不能改平台源码的前提下，找到可插拔的扩展点
- 在数据模型不清晰、文档缺失的情况下，搞清楚一张表到底存的是什么
- 用 SQL 表达复杂的业务规则，并且让它可配置、可维护
六、差异五：价值衡量------从"转化率"到"省了几个人"
互联网看转化率、留存、GMV。制造业看的是：
|-------|-----------------|-------------------------|
| 价值类型 | 衡量方式 | 我的实际案例 |
| 人力节省 | 每天/每月节省多少工时 | 老化统计：45 分钟/天 ≈ 180 小时/年 |
| 时效提升 | 数据从 T+N 缩短到 T+0 | 破屏率监控：人工次日 → 系统每日 09:00 |
| 风险消除 | 消除了哪类人为遗漏/错误 | 条码核对：避免错码流出 |
| 库存/在制 | 降低多少在制品、缩短多少交期 | 效率奖合并：激励异常响应 |
| 合规满足 | 通过客户审厂、满足客户系统对接 | 客户条码管控、IQDS 对接 |
我养成的一个习惯是：方案阶段就写下预期收益指标，上线后对照复盘。
和工艺同事讨论报表需求时，我会追问一句："这个功能上线后，能回答'降低了多少在制率''缩短了多少交货周期'吗？"
如果回答不上来，说明这个需求的价值还没想清楚------要么继续挖，要么降低优先级。
七、结论：MES 开发者需要三种能力
把上面五个差异收拢一下，MES 开发者真正需要打磨的是这三种能力：
三种能力里，业务理解力是最难培养也最容易忽视的。写代码的能力可以迁移，但对"产线怎么运转"的理解只能靠时间堆。
好消息是，它也可以刻意练习：
- 每个需求至少要去现场看一次实际操作
- 记下车间术语和系统术语的映射关系（比如 A 面 / B 面、拉别、线体、工位）
- 上线后主动回访，问"用起来哪里别扭"
- 遇到不理解的业务规则，先问为什么，再想怎么实现
下篇预告
第 2 篇《SQL Server 存储过程实战：从破屏率统计看区间匹配与配置化设计》
下一篇进入具体的代码层面，拆解我在破屏率统计系统里的存储过程设计：
- 为什么业务阈值一定要抽成配置表，而不是写死在
CASE WHEN里
- 三种区间匹配方案（硬编码 /
BETWEEN/OUTER APPLY）的对比与选型
- 一个可复用的多维度统计存储过程模板
- 上线后误报漏报的排查过程：数据口径是怎么对齐的
- 附赠案例：超周期发料管控里的"编码前缀清洗算法"
免责声明：本文业务参数、表名、字段名均为脱敏示意，涉及人员、客户、子公司均以角色或代号指代，不代表任何企业真实数据。