从白板草图，到车间现场。

背景

工厂有 1,200 名员工、14 条产线。在我接手之前，生产执行靠的是纸质工单加 Excel： 工单跟着物料走，报工靠人写，停机靠人记。

这不只是「效率低」。真正的问题是没有人能回答关于过去的问题——这条线为什么慢了、 这批货为什么返工、昨天夜班到底发生了什么。数据在纸上，就意味着它只存在于当时在场的人的记忆里。

我们评估过所有能买到的方案。问题不在于它们不好，而在于 14 条产线各有各的工艺路线， 而通用 MES 的抽象层次假设产线之间足够相似。要贴合，就得把这家工厂的特殊性改造成 软件的通用性——那笔账算不过来。

所以我提议自己做。这不是一个显而易见的决定。

关键取舍

取舍一：工单作为聚合根，而不是「工位」

早期设计把报工建模在工位（station）上，看起来更贴近现场。但工位是物理概念， 会随产线改造移动、合并、废弃；而车间里真正稳定的东西是工单——它从下达走到完工， 穿过所有工位。

改成以工单为核心聚合根之后，报工、质检、停机都变成挂在工单上的事实事件。 好处不是「更优雅」，而是任何一次追问都能沿着一个对象回答完： 这批货经过了哪些工位、谁在什么时候报了什么、哪一步出的问题。

代价是排产模块和工位视图要做额外的投影，不能直接读主模型。

取舍二：边缘网关做缓冲，而不是让 MES 直连设备

车间网络会抖。最早的版本让 MES 直接订阅 PLC，一次网络闪断就丢一批事件， 而且没人知道丢了多少。

改成边缘网关先落本地、恢复后补传之后，事件完整率到了 99.95%。 代价是引入了「至少一次」语义：同一事件可能补传两次，所以每个事件必须携带幂等键， 消费端必须能去重。这比「不丢」麻烦，但这是唯一诚实的做法——车间数据不允许丢失。

取舍三：只写工厂特殊的那部分

「从零自研」很容易滑向「什么都自己写」。我们给自己划的线是： 只有「这家工厂怎么做生产」这件事自己写。

排产算法、看板底座、消息中间件、部署方式——全部用成熟方案。 回头看，这条线是整个项目里最重要的决定：它让四个人四年做完了本该做不完的事。

遗留问题

• 离线报工端的冲突合并仍然粗糙。 两台终端离线时都改了同一张工单，重连后按时间戳取胜者， 后到的那次修改会被丢掉并记入审计日志。真正正确的做法是让冲突可见、由人裁决， 但现场没有人愿意在交班时处理「冲突提示」，所以退回了自动合并 + 事后审计。
• 报表指标层的口径没有单一来源。 同一句「停机时长」在三个看板上曾经算法不同， 我们最后靠一份文档和约定统一，而不是靠代码强制。这是当时欠下的技术债。
• 边缘网关的固件升级靠人工。 二十多台网关，目前要人跑到现场插 U 盘。

为什么不做成标准功能

三个配送中心用的都是 Odoo 的标准出入库流程，只有两处标准模块填不上： 批次追溯的连续性，和线边仓的临时归属。

这两件事都不适合改核心。改核心意味着每次升级都要重放一遍补丁， 而仓储业务几乎没有停机窗口来做这件事。

所以我们把差异全部收敛进一个模块：Odoo 核心不动，追溯逻辑和数据挂在旁边。 结果是 14 升到 17 的时候，业务侧没有感觉到升级发生过。