好产品和烂产品的分水岭，往往不在功能多不多，而在车间主任愿不愿意用。功能是猜出来的，好用是问出来的。
在很多制造业工厂里，车间SOP（作业指导书）原本是散着放的。一份文件对应一堆料号，谁适用、在哪个工序看，全凭老师傅记，版本更新了也未必传达到工位。这个问题不解决，MES和WMS上了再多模块，现场该按老习惯走的还是按老习惯走。我们在做MES产品设计时，就遇到了这个典型的场景——如何把“SOP在哪”这个问题，从人的经验里搬到系统里。
一份SOP到底该管哪些产品？
这是产品设计首先要回答的问题。在做需求调研时，我们发现产线调用工单SOP接口时，最怕推错。如果系统只是把文件简单挂上去，操作工点开发现不是这个料号对应的版本，那系统就成了负担。
所以在设计上，我们采用了“文件清单+关联明细”的主从结构。上面是文件清单，列出编号、名称、类型、当前版本、关联产品数；选中某行，下方展示这份文件已配置的关联明细。这中间有一条上下文栏，始终提示当前文件、编号和版本，避免操作错对象。把SOP文件和产品真正绑起来，页面上的动作是配置一份文件清单的适用范围——这份SOP对哪些料号或物料组、在哪个工序上生效。
为什么匹配规则要设计成“四层优先级”？
配置的时候不是随便选的，规则背后是现场的生产逻辑。我们把关联类型分成了四种：料号+工序、料号级、物料组+工序、物料组级。前两种按具体料号绑定，后两种按物料组绑定；带“工序”的类型只管某一道工序，带“级”的类型对整个产品生效。
这四种类型同时也是匹配优先级。产线取SOP时，系统按“料号+工序 → 料号级 → 物料组+工序 → 物料组级”的顺序依次找，同一份文件只按最高优先级的命中去推送。这样做的好处是，一条SOP不会因为配了多条而产生重复结果，产线拿到的指令永远是唯一且可解释的。
规则靠弹窗内的联动来保证。选料号的类型只出现料号选择框，选物料组的类型只出现物料组框，两者互斥；工序是否必填跟着类型走——料号+工序、物料组+工序必须指定工序，另外两种直接按“全部工序”处理，工序框置灰不可选。用户中途切换类型时，之前选好的料号、物料组、工序会一并清空，避免带着上一次的残值提交。保存前再校验一遍：该选的没选就提示，不该传的字段一律不传，保证落到库里的是“料号与物料组二选一”的干净数据。
历史版本预览踩过的坑：为何不能用主表当前的文件ID？
在多文件上传和版本管理环节，为了不给业务库增加负担，文件存储交给了系统统一的文件服务，SOP这边只做登记。上传分两步：先传文件服务拿ID和路径，再登记到SOP业务表。业务表里存的只有文件编号、名称、文件ID、路径和大小，真正的文件内容始终在文件服务里。这样既不用在业务库里塞二进制，也方便其他地方复用。
但这中间有个坑值得单独说：历史版本预览必须用该版本自己的文件ID，不能顺手用主表当前版本的ID。每个版本是独立的物理文件，拿错了就会出现“打开1.1版却显示1.3版内容”这种看起来很玄的问题。解决办法是版本弹窗不自己处理预览，把整行数据交回主页面，由统一的预览入口识别这是主表行还是版本行，再取对应的ID。下载也走同一个口径，一处逻辑管两条入口，少了很多对不上的可能。
少做花哨的功能，多做现场离不开的设计
在交互细节上，我们也做了一些取舍。比如关联明细保存成功后，主表的关联产品数要刷新，但直接刷新会把选中行和下面的明细一起清空，用户刚配完就“跳走”了，体验很差。所以刷新做了区分：保存明细后保住当前选中的文件，只更新数据不重置选中；整表刷新时则老老实实回到初始状态。
另一条原则是不要抢后端该做的事。文件编号、版本号、状态这些都由后端生成和判定，前端只负责展示和传参；接口返回的业务错误也原样透出，比如文件不存在、组合重复、上传结果不完整，直接提示给用户，而不是前端自己拼一句“操作成功”盖过去。在MES和WMS这类复杂系统里，产品设计的克制往往比堆功能更重要。
这也是精工智能数字化工厂做产品的方式——产品功能从一线场景反推出来，而不是会议室里设计出来。少做一个没人用的功能，多做一个现场离不开的功能。把SOP适用范围的维护从老师傅的记忆搬到系统里，让逻辑文件与物理文件分离，让版本迭代只替换内容、不牵动适用边界——这些设计取舍看似不显眼，但正是制造业数字化升级在车间落地时最需要的支撑。
