管理中台篇三：配方版本、工序主数据和设备绑定

配方连接现场运行和历史追溯。在产线系统里，配方不是一个“当前参数表”。它要回答几个具体问题：这份配方属于哪道工序，绑定哪台设备，当前启用的是哪一版，现场运行时使用的是哪一版，生产数据归档后还能不能追到当时的参数。

如果配方只按名称保存，现场短期运行能用，长期追溯会出问题。设备改过参数以后，历史生产数据看到的就可能是新参数；同名配方在不同工序里含义不同；同一工序不同设备的参数边界也会混在一起。管理中台把设备、工序、配方和版本关系固定下来，就是为了解决这类问题。

配方管理页证明的是管理中台的工艺参数口径。这里关注的不是把参数字段展示出来，而是把设备、工序和版本关系放到同一个后台入口里。现场上位机读取配方、上传数据、后台追溯历史，都依赖这套关系。

新版配方页延续这条规则：新建配方时必须选择归属工序和归属设备，升级版本时显示当前版本并重新维护参数，详情抽屉里同时展示工序、设备、版本和参数。前端的重点不是把 JSON 参数摊开，而是让后台操作人员始终看到“这份配方属于哪道工序、哪台设备、哪一版”。

工序管理页是配方和生产数据的云端落点。它让上位机侧的 Stacking、Injection、Homogenization 这类 profile，在管理中台里有对应的工序主数据，后续设备、配方和过站数据才能按同一口径归属。

配方归属：设备和工序

业务规则里明确：配方归属于具体设备，也归属于具体工序。

这个规则和上位机平台的工序 profile 对应。匀浆、注液、叠片在上位机侧是不同的 profile 和插件；在管理中台侧，则是不同工序下的设备、配方和生产数据归属。两边实现方式不同，但业务口径需要一致。

flowchart LR Process["MfgProcess 工序主数据"] --> Recipe["Recipe 配方"] Device["Device 设备"] --> Recipe Recipe --> Version["RecipeVersion"] Version --> Edge["上位机运行引用"] Edge --> Data["生产数据归档"]

云端代码里，工序主数据落在 IIoT.Core.MasterData.Aggregates.MfgProcesses.MfgProcess，配方聚合落在 IIoT.Core.Production.Aggregates.Recipes.Recipe。Recipe 中保留 ProcessId 和 DeviceId，说明配方不是独立参数块，而是挂在工序和设备下面的业务对象。

如果配方不绑定工序，后续新增工序时就会失去查询口径。匀浆的参数、注液的参数、叠片的参数不能混成一张没有工序上下文的表。管理中台先把工序主数据维护好，再让配方、设备和生产数据挂到这个口径下。

配方版本：不能覆盖旧记录

配方修改采用版本化管理，而不是覆盖旧记录。

业务规则里写明：配方修改不是覆盖旧记录，而是版本化管理，初始配方版本从 V1.0 开始。代码里 RecipeVersion.Initial 也是 V1.0。Recipe.CreateNextVersion 会基于原配方创建新版本，保留配方名称、工序和设备归属，再写入新的版本号和参数。RecipeArchivedDomainEvent、RecipeVersionUpgradedDomainEvent 这些领域事件也说明配方版本变更是业务动作，不是简单 update。

版本化以后，后台能回答这些问题：

• 当前设备正在使用哪一版配方。
• 某个时间点生产时使用的是哪一版配方。
• 参数变更前后的生产结果是否发生变化。
• 某条过站或生产数据关联了哪份工艺口径。

配方版本管理把“当前配置”和“历史追溯”分开，让现场运行和后台分析保持一致。历史记录引用版本，当前运行读取当前有效配置，两者不互相覆盖。

和上位机的关系

上位机侧通过 MachineProfile 和插件区分工序。Launcher 的 profile 卡片决定启动哪个工序运行目录，Shell 根据 Shell__MachineProfile 加载对应配置，插件再处理自己的业务数据和页面。

管理中台侧通过工序主数据和配方版本承载业务归属。上位机上传数据时，数据本身要能回到设备、工序和配方。管理中台查询时，也按这些维度检索。

这就是云端和边缘的配合关系：边缘负责现场运行，云端负责主口径和归档。新增工序时，云端补充字段、校验、DTO、Command、查询接口和前端页面；边缘新增对应插件、profile 和运行配置。人员、设备、bootstrap 等主链路不需要重开。

新工序扩展的边界

匀浆当前落地最完整，但配方体系不能只为匀浆写死。

注液和叠片接入时，工序自己的字段、单位、校验规则、采集来源、上传目标都要进入插件和云端接口设计。管理中台保持设备、工序、配方版本和归档主线不变；插件负责工序差异。

这条边界能让系统持续扩展。新增工序不会改变“设备、工序、配方、版本、归档”的主链路，只是在这条链路上增加新的工序参数和插件实现。

版本化解决的是运行之后还能追溯

配方在现场看起来只是参数，但到了历史归档阶段，它会变成生产结果的一部分。某台设备在某个时间段用了哪一版配方，后续产能波动、质量问题或工艺复盘都要能查回来。直接覆盖旧参数会让历史数据失去上下文，后台只能看到最新参数，却无法还原当时现场实际使用的参数。

版本化不是为了保存更多记录，而是为了保留时间线。V1.0 作为初始版本，新版本创建后旧版本归档保留，生产数据引用当时的配方口径。这样配方修改不会抹掉历史，也不会影响已经归档的数据解释。

工序主数据让插件扩展有云端落点

上位机侧通过 profile 和插件区分匀浆、注液、叠片；管理中台侧需要用工序主数据承接这些差异。工序主数据不是页面下拉框，它决定配方属于哪道工序，生产数据按什么口径归档，后续查询按什么维度过滤。

当前匀浆插件落地最完整，但平台不能把配方体系写死成匀浆专用。注液、叠片后续会有自己的业务字段、单位、采集来源和上传映射。管理中台保留设备、工序、配方版本这条主线，新增工序只扩展自己的字段和规则，不重新改设备身份和上传主链路。

设备绑定让配方不会漂移

同一道工序下，不同设备可能有不同参数边界。配方绑定设备后，现场读取和后台查询都有明确归属。设备 A 的配方不会误用到设备 B，某条生产数据也能回到具体设备和具体版本。

这个边界和权限规则也能衔接。人员要修改设备相关参数，需要同时满足设备分配和功能权限；配方属于设备和工序，后台维护时自然能进入设备维度的授权判断。配方、设备、工序和权限在管理中台里连起来，现场运行才不会只剩一个孤立参数文件。

后续新增工序怎么接

新增工序时，配方体系不应该被重新发明。先确认工序名称、设备范围、参数字段、单位、校验规则和上传口径，再把这些内容放到当前设备、工序、配方版本链路里。云端只补必要字段和查询能力，上位机插件只补自己的模型、页面和上传映射。

这个方式能避免两类问题：一类是每个工序都做一套自己的配方表，后续无法统一查询；另一类是把所有工序强行塞进同一套参数模型，最后字段含义被稀释。管理中台保主链路，插件保差异，工序扩展才有清晰位置。

配方版本还会影响 AI 端分析。AI 以后解释某个生产结果时，不能只看当前配方，而要知道历史数据当时关联哪一版配方。版本化让这种分析有依据，也让后台复盘不会被当前配置误导。