这是一次完整复盘：从零研究一个陌生行业（中小注塑厂的排产），到把它做成一个能跑的东西。 里面有三处判断被我自己改写，也一并写了下来。
先说三条结论
陌生行业的答案基本都已经存在，难点不在"想出来"，而在"找得到、认得出、判断得准"。开工前我把"该去哪找"排成了一张表，大部分格子在电脑前就能填完。
两天之后交出来的不是一份行业综述，而是三件能用的东西：一份写清了"不做什么"的需求判断、一套可以算的约束、一个能跑起来并且迭代了两轮的模块。
词义的错位比事实的缺失更危险。 这个行业里"排产"和"排班"经常被混着说，但它们回答的是两个问题——看清这一点，我才知道自己该站哪一边。
一、开工前先做两件事：把假设写下来，把"去哪找"排出来
1.1 先写下我进场时的判断
进陌生行业最容易犯的错不是无知，而是把已有的猜想当成需求——猜想一旦变成需求，就没有人会再去质疑它。
所以我的第一个动作，是把自己进场时脑子里已有的判断逐条写下来，每条后面留两栏：怎么核实、核实之后的结论。
这张表是整个研究里最省时间的工具。写出来的判断可以被检验，没写出来的判断只能等别人事后提醒你。
1.2 再排一张"该去哪找"的表
我没有先去看行业综述，而是把"需要搞清楚什么"列出来，给每一项配一个最接近源头的载体。术语分好几类，每一类的最佳渠道完全不同——用错渠道，看再多视频也补不上：
这些格子，大部分在电脑前就能填完。这就是"信息差"的位置——不是别人把答案藏起来了，而是大多数人找的地方不对。
我还给自己排了一条入门路径：看动画建立概念 → 读参数页钉死术语 → 看换模实操理解节奏 → 翻缺陷图解捡黑话 → 读 JD 做检验。注意最后一步是检验不是学习——能不能对着一张车间照片，把每台设备的名字和用途说出来。说得出，才算进了场。
二、第一天结束时，这个行业在我脑子里长什么样
下面这些是调研的产物。它们不是结论陈列——后面每一条方案判断，都挂在这一节上。
2.1 三种接单模式在同一个车间里同时跑
直接后果：代工订单按客户交期排、来料加工受客户送料节奏限制、自有产品要配合销售节奏——一套优先级规则套不住三种订单。
2.2 十步流程里，最脆弱的是第二步
接单评审 → 计划 → 备料备模 → 上模调机 → 试模首件 → 批量生产 → 巡检 → 下机 → 后工序 → 出货。
整条链路里，计划是唯一由单个人承担全局判断的环节，也是最脆弱的：排产员请假，计划就停摆。这是一个几乎所有人都忽略的单点故障。
2.3 现状工具是"四件套"，而且互不相通
计划在 Excel、执行靠 微信群、现场靠 白板、检验靠 纸质表单。四个载体之间不互通，于是：数据靠人录，忙起来就不录；异常靠人发现，处理靠老师傅经验，人走经验走。
2.4 约束有七类，但真正卡产能的常常不是机台
外行最容易漏的是辅机——几乎所有排产系统都不建模这一层。
另有两条可以当场校验客户自述的比例：在用模具 : 机台 ≈ 2–5 : 1，在排工单 : 机台 ≈ 3–8 : 1（两周时域）。如果一家厂说"20 台机、手上 400 张工单"，那要么是口径不对，要么有别的故事。（量级估算，需现场核实）
2.5 成本结构决定了话该怎么说
材料占一家注塑厂成本的一半以上，机时与能耗其次，人工再次（量级估算，需向工厂财务核实）。
结论很直接：老板对报废和料耗的敏感度，远高于对机台利用率。所有关于"提升效率"的论证，都要先换算成钱——"换模次数减少"要说成"省了多少停机、多少废料、多少人工"，才有人听。
2.6 异常的共同特征
绝大多数异常靠人发现，而不是系统发现；发现即滞后——通常已经做了一批；处理靠老师傅经验，没有沉淀；重排靠人脑，而且往往只重排受影响的那台机——救了一张单，拖了三张单。
最后一条，就是"异常重排"这件事的价值来源。
2.7 几个不显眼、但很关键的细节
颜色由深转浅必须清机，浅转深不用——切换代价不对称，这一条直接改变任务的排序规则；
换模时间不是固定值：和模具重量、是否要接水路、是否用行车、机台间距都有关系，同一副模在不同机台上可能差一倍；
排产的真正起点常常是"料什么时候到"，不是"机台什么时候空"；
"上模后不愿意换下来"不是懒，是理性凑批：换一次模的停机时间可能等于做掉半张订单。
三、三处判断被我自己改写
这三条是复盘里我认为最值得写下来的部分——它们都不是靠推理得到的，而是在核实过程中被改写的。
3.1 排产 ≠ 排班：这是最重要的一处词义错位
调研已有方案时我撞见一个事实：不少叫"排产"的东西，实际做的是人员排班——谁上哪个班、人岗匹配、工时合规。另一个独立的证据来自一套开源 ERP：它企业版里那个叫"计划"的模块，做的也是人员排班，不是机台排产。两个来源互不相干，结论一致。
它回答的是"谁上哪个班"。而我关心的是"哪副模上哪台机、几点开工、要不要换模"。
这两个词在行业里经常被混着说，但它们回答的不是同一个问题。看清这一点之后，我的定位从"再做一个排产功能"，变成了明确自己站在机台这一侧——正是这个定位，后来引出了第七节那个衔接点。
3.2 主角不一定是行业名字里的那个工艺
我按行业名把注意力放在注塑环节上，直到有人问我"这类产品的主工艺是什么"，才知道：这类软管产品的主工艺其实是挤出，注塑只做接头和配件。
这不是细节修正——它决定了该盯哪台设备、该问哪个瓶颈。行业名是标签，标签不告诉你这家厂靠哪道工序吃饭。
3.3 我一开始最想做的那部分，被我排到了最后
进场时我判断"要接设备、要有现场感知"。核实之后发现：排产的价值用人工记录的数据就能验证，而设备接入投入大、周期长、依赖硬件施工。先做接入的项目，最常见的死法是前三个月全在接硬件，业务侧看不到任何变化，预算被砍。
所以一期不碰它。顺带一个发现：设备数据其实有一档成本是零——很多厂不知道自己车间里已经有一半机器支持标准通信协议。该先做的不是"建采集能力"，而是"盘清已有资产"。
四、核事实的三条纪律
第三节那三处改写，不是坐在那里想出来的，是被三条纪律逼出来的。这一节是我认为最可复用的部分。
4.1 找一手，别找转述
写报告时要准确列出注塑机的通信标准编号。凭记忆写下的一个编号，去标准组织官网核对后发现是错的——原以为是温控设备的标准，实际是"注塑机 ↔ 机器人"，温控在另一个编号上。
既然要核，就把整个标准体系核了一遍。然后撞见一个原本没在找的发现：
模具相关的几份标准（模具本体、模具数字孪生、注塑机技术数据），全部集中在 2024–2026 年发布。
也就是说，"模具数字化"正在成为这行标准化的热点。这个判断不是推出来的，是核事实时撞见的——核一手来源不只是纠错，它还会产生新信息。
4.2 查能力边界，去看仓库，不看宣传
我需要判断一套开源 ERP（社区版）到底能做到什么程度。当时掌握的"常识"是：工序级工单、主生产计划、质检、设备接入都是企业版，连维护模块也是。
我没有看官网营销页，也没有看第三方博客，而是直接打开这个项目的代码仓库，逐个模块探测存不存在。结果和常识相反——维护模块在社区版里是有的，缺的是工序级工单、主生产计划、质检与设备接入。
结论因此变得很硬：它适合当数据底座，不能当排产引擎。它能回答"哪个订单哪天做"，回答不了"哪台机、哪副模、几点上模"。
一句可直接拿走的方法：营销页说"我们能做什么"，代码仓库说"我们实际有什么"，两者冲突时信后者。
4.3 核不到就写"待核实"，并写明该找谁核
不写含糊的"大约""大概"，而是写"向计划员核实""向工厂财务核实"。承认边界比假装知道更省事——写着"待核实"的地方，进厂之后是带着问题去的。
五、最后收敛出的方案边界
5.1 不做通用排产算法
有限产能排程是一个成熟的工程问题，开源求解器已经够用。这类项目失败的主因几乎从来不是算法不行，而是主数据不准、现场不执行。
在成熟问题上做边际优化，收益低；失败的高发区在它前面的那几步。这是我判断"该往哪投入"的依据。
顺带得到一个判断工具：识别一个排产系统是不是真排程，只需要问一句话——它会不会拒绝一个不可行的方案？如果结果里同一副模具能同时出现在两台机上，那它不是排程，只是把需求按日历摊开。
5.2 要做的三件事
数据整合：先把机台、模具、工单、实际状态汇总到一处。一期只要求"记录"，不要求"实时"——排产的输入是"这台机今天还能用多久"，不是"这一秒在不在跑"。
异常重排：已经开工的任务不动，只对未开工的部分重排，并输出变更清单。现场不会接受"已经上模的活被挪走"。
可解释建议：每个任务都能说清"为什么排在这台机"。说不出理由，计划员就会回到 Excel——这一条是"人愿不愿意用"的分水岭。
5.3 明确不做什么
说"不"是要承担成本的，所以这张表比"要做什么"更能说明判断。
5.4 分期与验收标准
一期把数据和理由做出来——验收标准是"计划员愿意拿它的建议当参考，并且能说出系统为什么这么排"；二期做异常重排闭环——验收标准是"重排建议的产出从半天压缩到十分钟，且变更范围可解释"；三期再上设备数据采集。
一期站不稳，就不要做二期——这类项目几乎都死在"一期还没被接受就扩张"。
六、做出来：一个模块，两轮迭代
判断写完只是纸面。我把它做成了一个能跑的模块——目的不是证明我会写代码，而是验证"我以为的约束"到底是不是真约束：描述得对，它能跑通；跑不通的地方，通常就是我理解错的地方。
先交代边界：这个模块跑的是内置的模拟数据，还没有进过真实车间，目前唯一的用户就是我自己。所以它能证明的是"链路完整、约束可算、结果可解释"，证明不了真实收益——那是进厂之后的事。但即便只有自己用，两轮迭代也改出了不少东西，每一处的起因都写在下面。
第一版：一个临时搭的 demo。
机台、模具、材料、工单四类数据，五条硬约束（模具独占、机台独占、吨位匹配、状态可用、换模耗时），支持急单插单与模具故障两类异常重排，配上"机台 × 时间"的排产甘特图、基线与系统双方案对比、以及每个任务的排产理由。数据是种子随机生成的，只读，跑一遍看个效果。它要回答的问题只有一个：这套约束能不能被算出来。
迭代一：从 demo 转正为模块。
跑通之后我觉得这条路可行，于是决定把它从 demo 转成一个真正的功能模块。转正的第一步是数据：不再由生成器临时造数，换成一份固定的、由 SQL 脚本导入的初始模拟数据集——可读、可改、可版本管理。因为车间天天在变，机台会停、模具会修、人员会缺，只读的数据从排出来那天起就是错的。同时新增"人员可用性"这一类，并补上第六条硬约束：同一时刻的换模并发，不能超过当日到岗的换模工与调机员人数——人手少的日子，系统自己会少排换模。
异常重排也改了，起因是我自己试着插了一张急单：系统给了一个数学上更优的方案，代价是带动了一大片任务位移。这样的变更单发到车间，没人会执行。于是把重排目标改成"最小变更"：在保证换模次数和交期不变差的前提下尽量少动，已开工的一律不动。顺手把初始数据的规模也按第二节那两个比例校准了一遍，让工单与机台的比例落在真实区间里。
到这里，这个模块长成了现在的样子：四类主数据（机台、模具、材料、人员可用性），六条硬约束，两类异常重排。
迭代二：从"能维护"到"能用"。
此前功能散在九个菜单里。功能都在，但我自己验收走位的时候，都要停下来想一下该点哪一个——功能全在，入口却是反的。这轮把入口收敛成三个——排产工作台、注塑工单、主数据维护，二级功能收进页内页签。入口结构就是产品本身，菜单越多越没人用。
同一轮还改了另一个细节：原来打开页面是空的，要手动点一下"生成"才有数据。我自己点的时候都觉得别扭——已经排过的计划，打开就该在那里。于是改成打开就加载当前计划，方案对比页也自动取最近一次的对比结果，不再每次重新生成。
这些发现都不需要很多用户——自己觉得别扭的地方，别人大概率也别扭。一个功能做出来了，和人愿不愿意用，中间隔着一段不长、但很容易被忽略的距离；自己当第一个用户，是缩短这段距离最便宜的办法。
七、一个衔接点：排人的和排机的，中间有条接缝
做完上面这些东西之后，我发现机台排产和人员排班之间，有一条很具体的接口。
迭代一加的那条硬约束——"换模并发 ≤ 当日到岗的换模工与调机员人数"——需要的输入是"当天有几个人可用"。
而这个输入，不是排产系统自己能产出的。它正好是人员排班系统的输出。
调研时我见过做人员排班的应用，当时只是留意到它和我想做的事不是一回事；直到给自己的模块加上这条约束，才意识到两者的关系不是"各做各的"，而是上下游：人员排班把"人"放对位置，机台排产把"机"排成序列，前者的产出恰好是后者的输入，中间能接上。
（这条接缝目前是设计上的推断，需要两边系统真的对上字段之后才算成立；届时最需要确认的是"当日可用人数"的粒度——是按天、按班次，还是按小时。）
八、边界：这些事查资料解决不了
一份陌生行业的报告，最后比的不是结论漂亮，而是缺口列得准。下面这些我查不到，也不打算假装查到：
缺口能列得准，是因为整个过程守着一个规矩：每条结论要么有出处，要么写明"这是我的推断"；核不到的，写明该找谁核。这个规矩能保证没有遗漏，保证不了没有偏差——偏差往往来自我一开始最确信的那几句"我觉得"。
进厂第一天，我打算先做三件事：清点辅机与机台的数量比；跟着计划员走完一遍完整的排产；给一次真实换模计时。
这三件事做完，上面那张表里的六个问号，有一半能变成数字。
评论区