M40G 三路合并装配线模拟器：从 Excel 手算到能对账的交期

新能源 M40G 阀体要上三路合并装配线。目标：11,000 只 / 6 个生产日 / 3 条线。

三路（1号活塞线、2号主体线、3号点胶线）并行，到合并点汇合，再走透气检测、防爆检测、外观检测打包。

原来的做法是拿 Excel 手算：一个工位一个工位算节拍，取最大值，乘上每天工作小时数，再乘天数。

一、报出去的数字经不起追问

Excel 只算理想状态：机器不停、件件合格、新线一开就满产。可实际情况是设备会故障、产品会有不良、新线前两周根本跑不满。老板一句"你说的 6 天是理论上还是实际上"，就答不上来。

二、找瓶颈靠手改数字

"到底拆到第几个工位才够"这个问题，每次都要手改十几处数字再重算，改一次半小时，试错成本高得离谱。

三、换产品等于重来

一条线 13 个工位，换产品就要重新敲一遍。没有批量导入，只能一个个填。

四、汇报只能截图

截个屏贴 PPT，数据没法二次加工；发给客户也不体面。

第一步：先把口径定死，再写代码

这一步比写代码重要得多。口径不统一，后面每个数字都站不住。

单站有效节拍 = 周期 ÷ 批量 ÷ 并行工位数        （烘烤除外，单位秒/只）
段节拍       = 该段所有非烘烤工位的最大值
全线节拍     = max(1号, 2号, 3号, 合并后段)     ← 三路并行，不是相加
有效节拍     = 全线节拍 ÷ (可用率 × 良率)
每班产量     = ⌊3600 × (班时 − 固定损失/60) ÷ 有效节拍⌋
爬坡         = 前 N 天按 60% / 85% 折产
达成天数     = 逐日累加（含爬坡）≥ 订单量 的第一天

最容易错的一条：三路并行时全线节拍取最大值，不是相加。这一步错了后面全错。

第二步：三代迭代

1. v1 —— 能把节拍和产能算出来。解决"算得对不对"。
2. v2 —— 加设备台数（按日产能反推）、人员装箱（一人兼顾多道、合计不超过一个节拍）、逐日排产表。
3. v3 —— 加四件事：

• 交期三档区间：乐观（可用率+5%、良率+2%）/ 基准 / 保守（可用率−8%、良率−3%）
• 敏感性扫描三组：瓶颈拆并行、班时增减、产线增减，能达标的那行标绿
• 工艺表从 Excel 直接粘贴导入，自动识别表头、预览校验、替换或追加
• 一键导出：1680×1250 汇报图（PNG）+ 9 段完整数据（CSV）

第三步：工程上的关键选择 —— 单文件、零依赖

不做前后端分离，不引框架，不装环境。所有 CSS 和 JS 内联进一个 HTML，双击就能用。

理由很实际：车间电脑、客户会议室电脑、临时借的笔记本，装不了开发环境。 能打开就能用，这个工具才活得下去。

代价是单文件 86 KB，改起来要靠构建脚本把 6 个源码片段拼起来。值得。

默认参数（11,000 只 / 6 天 / 3 线 / 可用率 95% / 良率 98% / 爬坡 2 天）下算出来：

按现在的配置——不可行。

6 天只能产 10,248 只，缺口 752 只；实际需要 7 个生产日，交期区间 6–8 天。

然后给了三条能走的路，每条都算出了结果：

1. 装配1/2/5 各拆 2 工位 → 节拍 60→30 秒，日产 1,881→3,765 只，4 天达成（人员 8→10 人/线）
2. 班时 ×1.1（13.2 小时/天）→ 日产 2,082 只，6 天达成
3. 产线加到 4 条 → 5 天达成（加到 5 条仍是 5 天，说明还有瓶颈卡着）

这样一个结论，能直接拿去跟老板说："6 天做不到，7 天是基准，最坏 8 天。要 6 天的话有三条路，各自是这个代价。"

验收：19 个用例，用无头浏览器跑真实 DOM 事件（不是读代码），控制台 0 异常。覆盖首屏渲染、改工时、改批量、预设切换、工艺表导入、坏行拦截、方案存档、导出 PNG/CSV、工位增删改、跨段调序、删空工位、项目改名等。

在线使用：https://hdyong.cn/tools/m40g

一、口径必须先定死，再写代码

这是整个项目最值钱的一条经验。

一开始我想先做界面，边做边想公式。结果做了两天发现"全线节拍"的定义自己都没统一——三路并行的时候到底取最大值还是相加？烘烤算不算节拍？有效节拍乘在哪个环节？

返工了一次之后定规矩：先在纸上把 7 条公式写清楚，逐条确认，再动第一行代码。

后面所有争议都变成"对照口径看是哪个环节理解不一致"，而不是"我觉得应该是这样"。

推广到任何测算类工具：先把口径写成能给人看的公式表，再谈实现。口径就是契约。

二、只给一个数没有说服力，要给区间

第一版只输出一个"6 天能产多少"。拿去汇报，第一个问题就是"如果设备坏了呢"。

后来改成三档区间：乐观 / 基准 / 保守，分别调整可用率和良率。

一个数是承诺，一个区间是判断。 承诺做不到了要担责，判断留了余地反而可信。

现在我给任何测算结论都带区间，这条成了习惯。

三、依赖越少，活得越久

这工具要在车间电脑、客户会议室、临时借的笔记本上跑。装 Node、装 Python、装浏览器插件，任何一步卡住，工具就废了。

所以做成单文件 HTML：零外部引用、零构建依赖、双击即用。

代价：源码要拆成 6 段，用构建脚本拼回单文件；改了要重新 build。

收益：两年后拿出来还能打开。不会因为某个库升级、某个 CDN 挂了而报废。

判断标准很简单：这个工具是给"愿意装环境的人"用，还是给"只想看到结果的人"用？ 后者居多，就选零依赖。

四、国产浏览器会静默拦截下载

踩过的坑。点「导出汇报图」没反应，没有任何提示——不是报错，是浏览器静默拦截了 a[download] 的 blob 下载。QQ、360、搜狗、遨游都有这个行为。

教训：凡是涉及文件下载的功能，必须有兜底。

我加了三层：

1. 导出后右下角固定弹面板，里面放「保存文件」「新窗口打开」「复制内容」三个手动退路
2. 汇报图改用 data: 内联 SVG 再画到 canvas，避开 file:// 下的跨域污染
3. 启动时识别浏览器，QQ/360/搜狗/遨游就给黄条提示，附一个「用Chrome打开.bat」

通用原则：不要假设浏览器的默认行为。关键路径上宁可多给一条退路。

五、用无头浏览器跑真实事件，比读代码可靠

一开始我是读代码验证的——看着逻辑对，就认为对。

后来改用无头 Chromium 跑真实 DOM 事件：真的去改输入框、真的点按钮、真的读渲染结果。19 个用例跑下来，抓出了 3 个"看代码看不出来"的问题：

1. 烘烤工位在流程图里根本不显示（只在负荷条里出现）
2. 烘烤时长有两个数据源打架（输入框和工序表）
3. 预设方案"在当前位置上乘"，连续点会累积偏移

这些读代码都发现不了，因为代码本身"看起来"没错——错在交互序列上。

结论：有 UI 的东西，验收必须走真实事件，不能靠读代码自证。

六、一句话总结

它不是计算器，是论证工具。

计算器给你一个数；它给你一个能站得住的结论——数据从哪来、口径是什么、风险在哪、最坏会怎样。

附：配套文件

• 在线使用模拟器（网页版）
• 下载项目报告（DOCX，22KB）

报告内容包括：项目背景与目标、口径定义、三代迭代说明、默认参数测算结果、三种解法对比、19 项验收记录、已知限制。