基础油配伍追溯的数据对象：供应批次、小试、调和与成品结果

直接答案

从对象关系与状态流转看，基础油合格只说明单项指标在控制范围内，不代表原有添加剂配伍一定适用。业务侧应把供应批次对象、COA与自检、小试条件、添加剂批次对象、调和批次对象和成品结果关联起来，再由技术与质量人员决定是否追加验证。

主数据、批次对象与现场事件怎样对应

从数据对象看，氧化安定性也是同一逻辑。基础油组成、硫含量、挥发性等条件改变后，抗氧体系的响应会发生变化。某些批次对象在出厂检测时看不出明显异常，但储存或使用过程中的表现已经开始拉开差距。

在事件流中，现场因此经常出现一个尴尬局面：采购拿得出COA，质量找不到超限项，技术执行的也是原配方，可成品结果就是和前几批不同。这说明业务侧真正缺的，不是一张检验单，而是一条能够“基础油批次对象属性—添加剂配伍—试验结果—成品表现”连接起来的数据链。只看单项是否合格，很难解释为什么相同配方在不同批次对象上会出现不同结果。 对应数据要保留对象标识、发生时间、来源和当前状态，避免只剩汇总值。

落到系统边界时，很多润滑油业务侧的配方经验，仍然保存在技术人员的个人经验里。某个来源的基础油，降凝体系要稍作调整；某类基础油与某种抗泡体系搭配时要谨慎；某家供应商一段时期内的某项指标经常贴近业务侧内部关注线。这些判断如果没有和批号、试验结果、成品表现绑定，人员一变，过去做过的试验就很容易重新做一遍。

这里的SRM并不是代替配方系统做配方，而是把供应端的基础油批次对象数据，与后续试验、生产和成品结果建立关联。前端批次对象能够被识别，后面的配伍经验才有对象可追。

状态流转、双向查询与接口责任

基础油到厂后，供应商、产地、牌号、批号、COA数据以及业务侧自检结果进入同一批次对象档案。系统不只判断“有没有超标”，还会把当前批次对象与过去运行稳定的批次对象进行比对，识别哪些指标正在偏离业务侧长期形成的控制区间。比如，某批基础油40℃运动黏度仍在采购范围内，但已经靠近业务侧内部关注线，同时倾点、挥发性也与近期常用批次对象出现变化。此时，技术人员应看的就不只是这张COA，而是历史上物性接近的基础油曾经采用过什么添加剂组合、做过哪些小试、配方怎样调整、成品结果如何。

落到系统边界时，AI在这里承担的是数据归集和历史关系识别：从过往批次对象中找出相近条件，把曾经出现过的配伍方案、试验结果和异常事件记录调出来。系统算数据，人来审核。当前批次对象能否沿用历史规则、是否应追加小试、能不能进入正式调和，仍由技术和质量人员按业务侧规则判断。

如果要求双向查询，试验一旦发生，基础油批号、添加剂批号、加剂量、混合温度、时间、检测结果与后续生产批次对象继续绑定。下一次遇到相近基础油，技术人员不必再从零排查，过去做过的试验也不再只是实验室里的一次事件记录，而会成为后续判断的依据。 对应数据要保留对象标识、发生时间、来源和当前状态，避免只剩汇总值。

从状态同步角度看，这套关系对采购同样重要。过去评价基础油供应商，往往盯价格、交期、合格率；现在还可继续往后看：某家供应商的基础油进入生产后，是否频繁触发小试，是否经常应调整配方，是否更容易出现复检、占罐或延迟放行。原料单价低一点，如果后面多出几轮试验、一次占罐和一批延期，采购账面上的节省未必能留下来。

基础油来源不可能永远固定。供应紧张、价格波动、炼厂检修、供应商调整，都可能让业务侧面临替代来源。若业务侧只能依赖少数熟悉批次对象来维持成品稳定，采购空间会越来越窄；但如果频繁切换来源，又没有配方验证和批次对象追溯，风险就会被推到生产、质量和客户交付端。

可回查的数据来源

系统需要把供应商批次、COA、自检记录、小试任务、配方版本、添加剂批次、调和批次和成品结果建成可关联对象。批次关系既要支持从成品向前追溯，也要让计划在投料前知道某批基础油对应的验证状态。

系统分工与接口边界

从对象关系与状态流转看，SRM用于识别供应批次对象并连接后续试验和结果，AI用于寻找物性接近的历史批次对象与已有配伍事件记录；系统不自动生成或批准配方，是否小试、怎样调整和能否投产仍由技术、质量和生产岗位审核。

建议的验证链路

从对象关系与状态流转看，可从一种基础油和一套成熟配方开始，准备近几批COA、自检、小试、添加剂批号、调和批次对象和成品检测事件记录，由采购、技术、质量、实验室共同验证相近批次对象能否回查；通过条件是新批次对象进厂后能快速找到可参考的历史试验并保留审核结论。